Bolt.new Hosting: Limits, Pricing, and When to Move Your App to Your Own Cloud

You prompted the app into existence in Bolt, clicked Publish, and it is live at a bolt.host address. Now a client wants it on their domain, or the traffic counter is climbing, or someone asked where the data actually lives. The question is not "how do I publish" — Bolt's docs cover that in a page — but what Bolt.new hosting gives you, exactly where it stops, and how much work it is to deploy the same Bolt.new app to production somewhere you control. This guide answers those three things with Bolt's published plan limits, a plain list of what Bolt Cloud can and cannot do, and the steps to get the app out when you outgrow it.

All prices and limits below were read from bolt.new/pricing and support.bolt.new on 2026-09-25. Bolt changes them often; check the linked pages before you decide anything on a number.

What Bolt.new hosting is, and what each plan includes

Since August 2025 every new Bolt project publishes to Bolt's own hosting by default (the earlier Netlify integration is still there as an option). Publishing takes about a minute and gives you a random bolt.host URL you can rename. Hosting is one part of what Bolt calls Bolt Cloud; the other parts are the built-in database, authentication, file storage and "server functions", which is where any backend code runs.

Two things are easy to miss in that table. The request cap counts requests, not visits, and a single page view of a modern app can easily be ten or more requests once fonts, images and API calls are counted, so the "visits" estimate is generous for anything interactive. And on the free plan the cap is a wall, not a bill: the site goes offline. The hosting plans page and bolt.new/pricing are the sources for all of the above.

What actually runs on Bolt hosting

Bolt's published position is that it supports JavaScript-based web technologies with Node.js for the backend; its docs state plainly that PHP or Python backends are not compatible. In practice the front end is served as a static site and backend logic lives in server functions (Bolt also calls them edge functions) that talk to the database, check permissions or call third-party APIs. The docs do not publish function timeouts, memory limits, scheduling, or persistent-disk behaviour, which is itself the useful signal: if your app needs a process that stays running, a cron job, a queue, or files written to disk, you are past what the hosting is documented to do.

When Bolt hosting is the right answer

Stay on Bolt if all of the following are true:

• The app is a marketing site, a prototype, a demo or an internal tool with a known audience.
• Traffic sits comfortably inside the plan's request and bandwidth numbers, with room for a good day.
• The backend is a handful of server functions and a database, not a long-running service.
• Nobody has asked which account it runs in or where the data lives.
• You are still changing it daily in Bolt and want publish to stay one click.

For that shape of app, Bolt hosting is genuinely good and the price is hard to argue with. Moving hosting is work; the point of a builder is to postpone that work until it pays for itself.

Five signs you have outgrown it

1. You have started watching the request counter. A launch, a newsletter mention or a bot can spend a month's requests in a day. On Free the site simply goes dark; on Pro you are choosing between a spending cap that pauses the site and an open-ended pay-as-you-go line. Either way, uptime now depends on a number you do not control.
2. The backend is not a function any more. Websockets, a worker that processes a queue, a scheduled job that runs every night, a video or PDF pipeline, anything that must stay running between requests: none of that is a server function, and Bolt does not document a home for it.
3. A client wants it in their name. Agencies build client sites in Bolt and then hit the ownership question: the project, the hosting and the database sit in the agency's Bolt workspace. Handing the client the keys means moving the app to an account the client owns.
4. Someone asked for the data in their own cloud. Bolt's Enterprise tier advertises deployment into your own AWS or Azure tenant; below that tier there is no setting for it. The moment a buyer says "this has to run in our account," you are in bring-your-own-cloud territory and the builder's hosting was never designed for it.
5. The stack stopped being JavaScript. The first time the honest answer to a feature is "this should be a Python service" or "this needs a real Postgres with extensions," Bolt's JavaScript-only backend is a hard limit rather than a preference.

Railway's own comparison page describes Bolt hosting as offering "limited observability" with "no support for multi-service architecture, managed databases, private networking, persistent volumes, or cron jobs." That is a competitor's framing, but it matches what Bolt's docs do and do not document.

How to get your app out of Bolt

The good news: a Bolt project is a normal JavaScript project, and Bolt has made the exit easy. The export has four parts, and the order matters.

1. Put the code in a GitHub repository you own

Click the GitHub icon in the top-right of the Bolt workspace, choose Log in to GitHub, authorize, and Install the GitHub App on the repositories you want Bolt to see. From then on Bolt commits every non-breaking change to the repo automatically and pulls in changes made on GitHub about every 30 seconds. Two details worth knowing before you rely on it: if Bolt and GitHub change the same thing at once, Bolt's version wins; and branches can be created in Bolt but only merged on GitHub.

If you would rather not connect accounts, the manual route works too: click the project title in the top left, then Export > Download. You get a ZIP of the source that runs locally with:

npm install && npm run dev

Either way, do the search every AI-built app needs before the code leaves Bolt, because generated code sometimes has keys pasted straight into it:

git grep -nE "(sk-[a-zA-Z0-9]{20,}|AKIA[0-9A-Z]{16}|-----BEGIN)"

Anything that turns up gets rotated at the provider and moved to step 2.

2. Collect the secrets

Bolt keeps API keys and database passwords in the Secrets tab (behind the database icon at the top of the project), where server functions read them. They are not part of the code, so they will not travel with the repo. Bolt hides the values as you type and its docs do not describe a way to read them back out, so plan on this being a re-entry exercise: list every secret name, fetch each value from the provider that issued it (Stripe, OpenAI, your email service), and enter them into the new host's secret store. Never commit them to the repository.

3. Decide what happens to the database

This is the step that differs most from other builders. If your app uses Supabase (available on Pro and Teams), the database already lives in your own Supabase account, and the exported app keeps talking to it; you copy the Supabase URL and keys into the new host's environment and nothing moves. That is the easiest migration in this whole category.

If your app uses Bolt Database, the data lives inside Bolt Cloud, and the authentication users, file storage and server functions that go with it are Bolt features rather than code in your repo. On Pro or Teams, Bolt's documented way out is Claim your Bolt Database in Supabase, in the database's Advanced tab: it moves the database into a Supabase project you manage, and from there you have a normal Postgres connection string and the Supabase path above applies. On Free there is no documented export, so verify in the Cloud settings what you can pull out before you plan the move. Either way, budget for rewriting the parts of the app that leaned on Bolt's built-in auth, file storage and server functions. If that sounds like a lot, it is the strongest argument for switching to Supabase before you grow, while the tables are still small.

4. Redeploy from the repo, then move the domain

Connect the GitHub repo to the new host, enter the secrets from step 2 with the new database details, deploy, and test on the host's temporary URL. Only then change DNS. If you connected a custom domain on Bolt you already have the records: a CNAME on www and an ALIAS or flattened CNAME on the root, both pointing at site-dns.bolt.host. Moving means changing those targets to the new host and waiting for propagation (Bolt's own docs quote a few hours, up to 24). The full walk-through of domains, TLS and database moves is the same for any builder export and is written up in our Lovable export guide.

Where to run it instead: three destinations compared

For a front end plus server functions, Netlify or Vercel is the natural next step and Bolt's own Netlify integration or Vercel's zip-drop import get you there in an afternoon. Once there is a real backend, the middle column becomes a PaaS, and our Railway vs Render vs Vercel comparison covers how to choose. The right column is the one people avoid because of the setup effort, not because it is the wrong answer; for the client-ownership, own-account and data residency cases in the list above, it is the only answer. The same decision for Replit apps is in our Replit Deployments guide.

The shortcut for the third column

If your app has hit signs 2, 3 or 4 and you would rather not learn cloud infrastructure this quarter, this is exactly the hand-off we do. You send us the GitHub repository from step 1. We deploy it into your own AWS, GCP or Azure account — or into your client's — with the database, secrets, domain, TLS and monitoring included, or run it as a managed API for you, and you never look at a request counter again. It is priced per project, not as a retainer; the comparison with a conventional engagement is in DevOps as a service. Send us the repo and we will tell you what the move actually involves before you commit to anything.