Bolt.new Cloud Guide: Database, Hosting, Domains and Supabase

Bolt Cloud is the backend and hosting layer built into Bolt.new (Bolt), and on most apps you never switch it on yourself. The moment a prompt adds a login form, Bolt creates a database, wires up sign-in and lets you publish to a free bolt.host address. Every plan gets this, including Free at $0 a month. The paid layer starts with Pro at $25 per month billed monthly or $18 per month billed yearly ($216 a year) for 10M tokens a month, and it adds custom domains, private sites, hosting analytics, higher traffic limits and the option to run on your own Supabase ^[1]. Learn one rule before anything else. Restoring an earlier version rolls back code, never data.

Let the first login form create your database

Bolt Database is built on PostgreSQL and runs on Supabase infrastructure managed by Bolt, so your records sit in an open-source engine rather than a proprietary store. It is the default on every plan, and the pricing cards list unlimited databases on Free and Pro. Bolt normally creates one as soon as a build needs it, a sign-up page for example; a static site needs none, and you can tell Bolt not to add one. Inside the project, the database icon gathers seven panels: Authentication, File Storage, Logs, Secrets, Server Functions, Tables and User Management.

The Tables panel is where most day-to-day data work happens. Rows can be edited by hand, copied or exported as CSV or JSON, and the Query tool runs any SQL while showing up to 100 rows at a time. Viewers only read tables; Editors, Co-owners and team Admins change rows. Tables created from late October 2026 on start private, so the app needs explicit read and write permissions, which Bolt normally sets for you. Plan for quiet weeks too. An unpublished project whose database sees low use for six days or more may be paused automatically and restored later, while published projects are never paused.

Sign-in, files, server functions and secrets

Authentication needs a database, and Bolt sets one up if it is missing. Sign-up is on by default, anonymous sign-ins are off, and the email templates for confirmation, invitations, address changes and password resets are editable. Google sign-in works, but test it on the published site, because Google blocks its login inside the preview frame. New Bolt databases check fresh passwords against known breach lists by default. The weak spot is mail volume: default auth emails are capped at 2 per hour for the whole project, a level meant for testing. Custom SMTP lifts that to 30 per hour, but only after you claim the database into your own Supabase account.

Server functions, also called edge functions, are the part that runs on a server: payments, webhooks, outgoing email and calls to outside AI services. Bolt deploys and updates them on its own. They expect authenticated requests, so a webhook function you add yourself (from Stripe or GitHub, for example) fails until you turn off JWT verification for that function and add another check in its place; the built-in Stripe integration handles its own webhooks. App emails usually go through Resend with your own API key, and sending from your own domain needs a published project with a custom domain attached.

Keys belong in Secrets. They work only with server functions and never reach browser code or the published site, whereas variables in a .env file are part of the code and visible to Editors and Co-owners. On shared projects only the Owner or a Co-owner can view or add secrets. File storage uses buckets, and Bolt creates private ones protected by Row Level Security by default; you can see the buckets, but managing individual files there is not supported yet. User Management shows a sign-ups graph and recent users, and it lets permitted roles invite, create or delete accounts.

Run both security checks before you publish

Row Level Security decides who reads and changes each table. Bolt turns it on for tables it creates, but a table you add by hand needs checking, since without it anyone can read and change the data. On sites without sign-in, Bolt may write policies that let any visitor read, edit and delete, and the scan flags them as always true. The database Security Audit runs on every plan, uses the same checks as the Supabase Security Advisor and looks at the database only ^[2].

Paid plans add a whole-project audit in the Publish menu. It reviews code and data together, covering access control, authentication, business logic, database policies, information disclosure, secrets, injection and XSS, and it fixes most issues itself. The button costs no tokens. Asking Bolt to audit does. You get up to 30 audits a day, reset at midnight UTC, and Bolt calls the result a first pass rather than a replacement for enterprise tooling. When something breaks after launch, remember that the Logs page shows only the past hour of activity.

Publishing on bolt.host and the traffic you can serve

Every project publishes to a free bolt.host subdomain whose prefix you can change, with no third-party account. The Publish and Update buttons spend no tokens, and the live site changes only when you click Update. Only the owner, Editors and Co-owners can publish, and a project must stay under 100MB of combined file size, or the deploy stops with a project-too-large error. Hosting limits belong to the whole Bolt account, not to one project.

Every site on one account draws from that single allowance, which matters once you publish several side or client projects. Bolt estimates Free hosting at around 10,000 to 15,000 monthly visits and Pro often at 100,000 or more, depending on page size; treat that as the vendor's guess. The pay-as-you-go rate is not published, so set a cap you can live with. Analytics count crawlers and bots with no way to split them out. Want cleaner numbers? Embed Google Analytics or Matomo tracking code. Netlify remains an optional host, but only for browser-only sites with no database or backend, and custom domains must be added again there. The plan math behind these limits sits in our Bolt.new pricing guide.

Buying or connecting a custom domain

Custom domains need a paid plan, and a domain attaches only to a published site. To connect one you already own, point a www CNAME and a root ALIAS, ANAME or flattened CNAME at site-dns.bolt.host, with an A record as the fallback. External DNS can take up to 24 hours, while a domain bought inside Bolt usually connects in 5 to 10 minutes. SSL is automatic. Behind Cloudflare, set Bolt's records to DNS only or the certificate fails. A site on a custom domain can only be public, and extra domains can point at it as aliases.

Buying through Bolt is quicker but stricter. Purchases are final and non-refundable ^[3], the domain is locked for 60 days, and auto-renew is on by default at the renewal cost shown at checkout; Bolt publishes no domain prices. The card is charged 1 month and 5 days before the renewal date, with a retry 5 days before it, and auto-renew must be on at least 6 days before expiry. Turning it off takes a support request. An account starts with up to 10 purchased domains, .ai names need a two-year registration, and WHOIS privacy is included where the extension supports it.

Two account events catch owners out. After a downgrade to Free, your domains stay in the account and live sites stay online, but you cannot republish to the custom domain or reconnect it. A project transfer also leaves custom domains behind, and a Bolt-bought domain cannot be reconnected after the transfer until it expires, which is why Bolt advises against transferring such projects. Remove or plan around the domain before you hand a project to someone else.

Supabase, Stripe and the data outside version history

When your own Supabase project is worth it

Bolt Database covers most apps. Running on your own Supabase makes sense when you want outside management tools, direct SQL editing, advanced monitoring or custom SMTP, and it needs Pro or Teams ^[4]. Three routes exist: start a new project on Supabase, connect an existing Supabase database, or claim a Bolt database into your Supabase account, which requires being a Supabase org owner.

The constraints are tight. A Bolt account connects to one Supabase organization and can never change it. Connecting Supabase to a project that already has a Bolt database replaces the connection and may lose data, and there is no flow from Supabase back to a Bolt database, so decide at project start. Claiming into a Free Supabase account switches off leaked-password protection unless you hold Supabase Pro or higher. Disconnecting leaves your data and code intact but cuts Bolt's access, and deleting a Bolt project removes its Bolt database while an external Supabase database survives.

Payments with Stripe, and what restores leave alone

Bolt's Stripe integration handles one-time payments, subscriptions, trial periods, prorations and multiple tiers. It needs Bolt Database or Supabase with authentication and edge functions, and it does not work with Firebase. Payments run server-side, Bolt handles webhooks and signature checks, and you should test with Stripe's sk_test keys first. A custom Stripe build cannot migrate to the integration, though it keeps working. Duplicating a project copies the Stripe keys, so both copies charge into the same Stripe account.

Version history is the trap. Restoring a version costs no tokens and rolls back code, but never the database, whether Bolt Database or Supabase. Export rows before risky changes. Duplicates copy tables and starter data, not users, user data, uploaded files or secrets. Since November 2026, Bolt bills plans and purchased domains through Link by Stripe, which adds VAT or sales tax where the region requires it.

The bottom line

Bolt Cloud removes the separate backend account from a first app: database, sign-in, server functions and a bolt.host address all come with Free. The money questions arrive at launch. Custom domains, private sites, analytics and your own Supabase need a paid plan, Free traffic stops hard at the account-wide limit, and domain purchases cannot be refunded. Decide between Bolt Database and Supabase before the first table, keep data backups outside version history, and read our full Bolt.new review before you commit.