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, the build errors that only appear on a real server, and a way to recover code and data separately. 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. Copy the table into a document and fill in the right-hand column.

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, and what Bolt's audit covers

Bolt's security page describes two checks. The project security audit, on paid plans, "reviews your whole project, including your code and database, fixes what it can, and flags anything you need to handle". It is run from the Publish menu, does not use tokens, and is capped at 30 runs a day. The database security check, on all plans, is described as "a lightweight review of your database". Bolt recommends running a check at least once before publishing.

Run the audit, and read what it asks you to do by hand. Then verify the things no scanner can know, because they depend on what your app is meant to allow:

• 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.

One trap: Bolt's docs note that rolling back to a version from before a fix also removes the security changes Bolt made. After any rollback, run the audit again.

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. When you move to a custom domain, update the auth redirect URLs too, or sign-in and password reset links will send users back to the old address.

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. Work out the price on the server; never trust an amount the browser sends.

Scaling, hosting limits and cost

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. They also say custom domains are only available on Pro. For a launch, the usage limit 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. Any server function that calls a paid AI or email API needs a per-user limit, or a single script can drain the account.

The other cost grows with the codebase rather than with traffic. Bolt's token docs say most usage comes from Bolt "reading, understanding, and syncing your project files", so "larger projects use more tokens per message". As the app grows, each fix costs more, which pushes founders toward quick patches exactly when the app most needs careful ones. Direct edits in Code view do not use tokens.

Builds that only fail on a real server

When a Bolt project moves to Netlify or another host, the same few problems account for most failed deploys:

• Type errors the preview tolerated. Run npx tsc --noEmit (or the project's build command) and fix every error before you trust a deploy.
• Import paths with the wrong letter case. ./components/Header and ./components/header are the same file on some machines and different files on the Linux servers most hosts use.
• Dependencies used but not listed. If package.json does not name a package, a clean install on the host will not have it.
• Missing environment variables. A blank page after deploy is very often a variable that exists in Bolt but not on the new host.
• Deep links that return 404. A browser-routed single-page app needs a rewrite so every path serves index.html. Netlify's rewrite docs give the rule: /* /index.html 200 in a _redirects file.

Logs, errors and alerts

Bolt Cloud's database logs include server function, authentication, PostgreSQL and storage logs, which is where you look when something fails. Logs only help if someone reads them. Before launch, add an error-tracking service to both the front end and the server functions, send alerts to a named person, and add an outside uptime check. Then test a partial failure on purpose: a payment that succeeds while the confirmation email fails should leave the system in a state you can explain.

Recovery: code and data are separate

Bolt's rollback docs recommend version history for restoring earlier versions of a project, and state that "restoring to an earlier project version will not change your current Bolt or Supabase databases". That is the right design, and it has a consequence: if a change altered the schema, rolling back the code leaves old code facing the new schema. Make schema changes additive where you can (add a column, migrate, remove the old one later), keep the code on GitHub as an independent copy, and back up the database separately before any risky change. Bolt's database overview does not describe backups, so if the data matters, claim it into your own Supabase account, where you control the backup plan.

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. Bolt's documentation is not consistent here: its database overview says there is "currently no supported way to migrate an existing Bolt database to Supabase", so check that the claim option actually appears in your project before you plan around it.

A self-check you can run today

1. Fill in the inventory table above: framework, database, hosting, domain, secrets, code and plan.
2. Run Bolt's security audit (or the database check on a free plan) 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. Run a clean build outside Bolt (npm ci and the build command) and fix every error.
8. Check that the latest code is on GitHub and that you could rebuild the app from it without Bolt.
9. Find out how the database is backed up, and restore a copy somewhere that is not production.

Release checklist for every change after launch

Once customers are using the app, run this before each publish. It takes minutes when nothing is wrong.

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, when token costs per change keep climbing, 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 code and data can each be recovered, and 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, through the MVP Scoping Sprint: €900 and about two weeks for a written scope and a fixed price, credited in full against the build if you build with us. Builds are typically €4,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; for ways to pay for it, see MVP grants and funding in Europe. The €99 Prototype Check 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. Client products are deployed to EU data-centre regions, and invoices are in euros. If your app came from another tool, see the guides for Lovable, v0 and Replit.