Take a Bolt.new App to Production

To take a Bolt.new app to production, first establish what you actually have: which framework Bolt chose, which database it uses (Bolt Database, a connected Supabase project, or a claimed one), and where it is hosted. Then close the gaps a preview never shows: database access rules, secrets, live Stripe keys and webhooks, hosting limits, and tests. Easify's €99 Prototype Check returns the top security and data risks in writing within 48 hours.

Bolt is unusually complete. Its Bolt Cloud bundles hosting, domains, a database, authentication, file storage, server functions and Stripe payments. That is why a Bolt app can look finished long before it is ready, and why the first job is an inventory rather than a fix list.

At a glance

Step one: an inventory of what Bolt built

Answer these before changing anything. Each answer changes what "production-ready" means for your app.

• Framework. Open package.json. A Vite and React app is a browser-only front end with a separate backend. A Next.js app has its own server code. A mobile project is a different exercise again.
• Database. Is it Bolt Database, a Supabase project you connected, or a Bolt database you claimed into Supabase? Bolt's database settings show which.
• Server logic. List the server functions (Bolt also calls them edge functions). These are where permission checks and payment handling belong.
• Hosting. Bolt hosting on a bolt.host address or a custom domain, or Netlify?
• Secrets. Which keys are stored in Bolt's Secrets, and which are sitting in code or .env files?
• Code. Is it connected to GitHub, and is GitHub the copy you trust?

The risks specific to Bolt apps

The preview is not production

The Bolt editor runs your project in WebContainers, a Node.js runtime inside the browser. It is a remarkable piece of engineering and it is not the environment your users hit. The published app runs on separate hosting with its own environment variables and secrets. A feature that only ever ran in the preview, a variable that was never set for the published site, or a server function the preview never called are all invisible until launch. Test the published app, not the editor.

Database rules

Bolt's database documentation includes a Security Audit that checks for issues "such as an open permission or a missing RLS policy". That is useful, and the same page notes its limit: it covers the database, not the whole project. The things to verify by hand:

• every table holding user data has row-level security, and policies restrict rows to their owner;
• update policies stop a user changing their own role, plan or account balance;
• file storage buckets holding private documents are private;
• two test users cannot see each other's records, tested against the published app.

Auth and permissions

Bolt can add sign-up, log-in, email confirmation, password reset and Google sign-in on request. Authentication answers "who is this?"; it does not answer "may they do this?". If admin pages are hidden in the interface but the data behind them is reachable, that is a permission gap. Privileged actions belong in server functions that check the user first, or in database policies.

Keys and secrets

Bolt's Secrets hold the credentials server functions use. Anything referenced from front-end code is shipped to the browser, whatever it is called; in a Vite project, every VITE_ variable ends up in the bundle. Search the code for secret keys, and rotate any that were ever in the front end, a public repository or a chat message.

Payments

Bolt's Stripe integration handles webhook registration and signature verification for you and runs payment processing server-side, which is a better starting point than most prototypes have. Two things remain yours. The guide centres on test mode (keys beginning sk_test_) and does not explain switching to live keys, so check live keys and a live webhook endpoint are in place on the published app. And check the paths a demo never takes: failed renewals, refunds, cancellations and a user who closes the tab mid-checkout. Stripe can deliver an event more than once, so the handler should cope with duplicates.

Scaling and hosting limits

Bolt's hosting docs say each plan includes a set amount of hosting usage and that a site over its limit "stops displaying publicly until your usage resets" at the start of the next billing cycle. For a launch, that is the risk to plan around first: know your plan's limit and raise it before the traffic arrives. After that, the usual demo-scale problems apply: unpaginated lists, one query per row, and no indexes on the columns your filters and policies use.

Tests and CI

A single prompt can touch many files, so a fix in one place can quietly change another, and nothing catches it. Once real users depend on the app, connect it to GitHub if it is not already, protect the main branch, and run at least a type check and a few end-to-end tests (sign-up, the core action, payment) on every change. Keep a separate database for testing, so a prompt experimenting with the schema is not experimenting on customer data.

Lock-in and moving the data

The code exports, so the front end and server logic are yours. The data is the part to handle with care. Bolt's docs say you can claim a Bolt database into your own Supabase account, and they warn that connecting a different Supabase database "will replace the connection, which may cause data loss". If you already have users, claim; do not connect a fresh project and hope.

A self-check you can run today

1. Write down the framework, database, hosting and domain the app uses.
2. Run Bolt's database Security Audit and read every finding, not just the summary.
3. With two test accounts on the published site, try to open each other's records by changing an ID.
4. Search the code for sk_live, sk_test, service_role and any secret in a VITE_ variable.
5. Confirm the published app uses live Stripe keys and a live webhook, then run a real low-value payment and refund it.
6. Look up your plan's hosting usage limit and what you are using now.
7. Check that the latest code is on GitHub and that you could rebuild the app from it without Bolt.
8. Find out whether the database has backups and how you would restore one.

When to stay on Bolt, and when to move off

Stay on Bolt while you are validating, while traffic is modest and well inside your hosting plan, and while one person does the building. Bolt Cloud's bundled services are a genuine advantage at this stage: fewer accounts, fewer places for things to go wrong.

Move the data first once you have real customers: claim the database into your own Supabase account so backups, monitoring and access are under your control, even if you keep building in Bolt.

Move the workflow off when two or more developers need to work at once, when you need reviewable changes and a test pipeline, or when hosting costs or limits stop fitting your traffic. The interface and much of the logic usually carry over; the database rules, server functions and payment handling are what get rewritten.

When not to hire us: if the app is a prototype for user interviews, an investor demo or a tool for your own team, publish it as it is and learn from it. A production review earns its cost when strangers start trusting the app with data or money.

What the €99 Prototype Check covers

The Prototype Check is a human review of the repository and the live app, for products built with Lovable, Bolt, v0, Replit, Cursor or similar. For a Bolt app, that means:

• the inventory above, confirmed from the code rather than from memory;
• database permissions and RLS, tested against the published app;
• secrets in code, environment variables and the front-end bundle;
• how payments are confirmed, and whether live mode is set up;
• hosting plan limits against expected launch traffic;
• whether the data can be moved without loss.

Within 48 hours you receive the top security and data risks in writing, then a 15-minute call. Request it with the Prototype Check form; we reply within one business day with a payment link.

What happens after it

The findings are yours to act on, with us, with another developer or on your own. If you want Easify to continue, the next step is the full five-day audit, quoted after the Prototype Check, and then the fixes. Where a rebuild is the cheaper route, it is scoped like any MVP: typically €5,000 to €25,000 over 4 to 12 weeks, at €25 to €45 an hour with a €1,000 minimum project. For a rough figure first, try the MVP cost calculator. The €99 is credited against the build if you hire us.

We work from Budapest, remotely across Europe on CET, in English or Hungarian, with our engineering team in India. If your app came from another tool, see the guides for Lovable and Replit.