Is my Bolt app ready for real customers?
Publishing a Bolt app puts it on a web address. It does not check whether a stranger can safely sign up, pay and trust it with their data. Those are separate questions, and you can answer most of them yourself in an afternoon with two test accounts and the settings pages Bolt already gives you.
The short list: two customers can never see each other's data, a payment is confirmed on the server and not only on the screen, the code and the database exist somewhere outside Bolt, someone is told when the app breaks, and a change you make next month cannot quietly undo one you made this month.
If the app is a demo for investors or a tool only you use, you may not need any of this yet. If people you do not know are about to pay for it, you do.
What Publish in Bolt actually does
Publish deploys your project to Bolt's built-in hosting at a random address ending in bolt.host, which you can rename. A custom domain needs a paid plan, and a site with a custom domain can only be published publicly. Under the hood Bolt Cloud runs on Netlify and Supabase, so the hosting and the database are real infrastructure, not a preview.
Two limits matter once real people arrive. On the free hosting tier every project in your account shares 10 GB of bandwidth and 333,333 requests a month, and when that runs out your sites stop serving until the month resets. The Pro tier has a higher allowance and lets you pay as you go with a spending cap you set. Check which tier you are on before you send a link to customers.
What Publish does not do is look at your data rules, your payment handling, or your backups. Those are yours to check.
Five checks you can run today
None of these needs a developer. Do them on your own app, in order.
- Two accounts. Sign up twice with different emails. As the first account, create something (an order, a project, a note) and copy the address bar. Log in as the second account and paste that address. If the second account sees the first account's record, stop here and read our page on customers seeing each other's data.
- Secrets in the page. Open your published site, right-click, View page source, and search for sk_live_ and service_role. Neither should be there. The publishable (anon) key is designed to be public; the service key is not.
- Payments on the server. Pay with a Stripe test card, then cancel or refund it in the Stripe dashboard. Does the app notice, or does the customer keep access forever?
- Export. Click the project title, then Export, then Download. Open the zip. That is your code. Your database is not in it.
- Security audit. Open the database panel, click Security, and read every finding. A warning that a rule is 'always true' means a table is open to everyone.
Where your code and data live, and who can reach them
Your code is safest when it also lives in a GitHub repository you own. Bolt's GitHub integration commits each working change for you and checks GitHub every 30 seconds for edits made elsewhere. If both sides change at the same moment, Bolt keeps its version and overwrites GitHub's, so one tool should edit at a time.
Your database is the part people forget. Bolt's own docs say that restoring an earlier version of your project 'will not change your current Bolt or Supabase databases', and that version history 'does not support database restores'. A rollback brings back your code, not your customers' records. Take your own database backup before any change you are nervous about, and restore it once somewhere else so you know the backup is real.
On the Pro and Teams plans you can choose a Supabase project of your own instead of the Bolt database when you create a project. That puts the data in an account you control, with its own backups and its own login.
What ready looks like, in plain words
Ready is not a feeling. It is a short list of things you can point at.
- Every table has a rule that says who can read it, and the two-account test passes on every page.
- The server, not the screen, decides who has paid, and a cancelled payment removes access.
- The code is in a repository you own. The database has a backup you have restored once.
- Errors go somewhere a person will see them, not only into a log nobody opens.
- The two or three flows that make money (sign up, pay, the core action) have automated checks that run before any change goes live.
- You know roughly what happens at ten times your current traffic, because you tried it.
If you can tick all six, send the link. If two or three are missing, you have a clear list and most of it is a few days of work.
When you do not need help yet
A Bolt app used by you and a few friends, with no payments and no private data, does not need a staging copy, a test suite or a partner. Keep building. The point where it changes is the first stranger with a credit card, because from then on a bug costs you a customer and a leak costs you trust.
If that moment is close, do the five checks above first. A call with us is most useful when you have done them and found something you cannot fix, or when the app is already carrying money or customer data and you are not sure what is underneath.
| Question | Publish handles it | Still yours to check |
|---|---|---|
| Is it online? | Yes, at a bolt.host address, or your domain on a paid plan | Traffic limits on your tier |
| Can one customer see another's data? | No | Two-account test, database Security audit |
| Is a payment real before access is granted? | No | Stripe test card, then cancel and watch |
| Do I have my code? | No | GitHub sync or Export > Download |
| Do I have my data? | No | Your own database backup, restored once |
| Will I hear when it breaks? | No | Error alerts to a person |
| Will a fix stay fixed? | No | Automated checks on the money flows |
Questions
Does Bolt host my app for free?
Yes, at a bolt.host address, with a monthly traffic cap shared across all your projects and a 'Made in Bolt' badge. When the cap is reached, free sites go offline until the next cycle. A custom domain and pay-as-you-go traffic need a paid plan.
Can I move a Bolt app off Bolt later?
The code, yes: connect GitHub or use Export > Download, and the project is a normal web app you can host on Netlify or elsewhere. The database and logins take more work, and they are easier to move if you chose your own Supabase project from the start.
Does Bolt back up my database?
Bolt's version history and restores cover your project files, not the database. Its docs say a restore will not change your Bolt or Supabase database. Make your own backup and test restoring it.
Is a Bolt app secure enough for paying customers?
It can be. Whether yours is depends on what the agent was asked to build, not on Bolt. The two-account test and the database Security audit tell you most of what you need to know in an hour.
What does Bolt's Security audit cover?
Your database only, not the whole project: row-level security policies, rules that are always true, and a few Supabase settings such as leaked-password protection. It does not test payments, your server code, or what a logged-in user can reach by changing a URL.
First look, $750. After a free call, we read your whole product and tell you what is finished, what is not, and what to do first.
Setup, $3,000 fixed. We make it ready for real customers, in accounts you own.
Partner, $2,500 a month. We review what your coding agent writes and keep the checks and tests current. Month to month.