Taking a Bolt.new App to Production: What to Fix Before Launch

Bolt.new is a fast way to get a working web app: you describe what you want, and it generates a full-stack project in the browser, with a live preview and one-click publishing. For a demo, that is remarkable. For real customers, the gap is rarely the screens. It is everything around them: where the code lives, how it is deployed, who owns the database and what happens when something breaks at night.

This guide is about the move from "a project in a browser tab" to a proper delivery pipeline, so making a Bolt.new app production ready is about operations as much as code. If you want a quick signal first, run our free AI App Health Check. For the broader launch view, see our 20-point production readiness checklist; here we go deeper on the specifics of how to take a Bolt app to production.

Platforms change quickly. Features, export options and integrations described below are general patterns; check your own project settings and Bolt's current documentation before relying on any detail.

Why a Bolt project needs a real pipeline

A browser-based builder optimises for speed of the first version. A production system optimises for repeatability: anyone on the team can build it, deploy it, roll it back and understand what changed. If your only copy of the app lives inside the builder, you have a single point of failure and no history of decisions.

The goal of the steps below is simple: your code in a repository you own, built by an automated process, running in environments you control, with data you can back up and restore.

Step 1: own your code and repository

Before anything else, get the project into a Git repository under an account or organisation that your company controls, not the personal login of a freelancer or a former teammate. Bolt projects can commonly be exported or connected to GitHub; check your project settings for the current options.

• Commit the current state as a baseline and tag it. That is your known starting point.
• Add a proper .gitignore so that environment files, build output and local caches never reach the repository.
• Check the history for secrets. If a key was ever committed, rotating it matters more than deleting the file.
• Protect the main branch and require a pull request, even if the only reviewer is a second pair of eyes.
• Write a short README with how to install, run, build and deploy. If you cannot, that gap is your first finding.

Step 2: hosting and environments

A one-click publish is convenient, but production needs more control: your own domain, HTTPS, predictable rollbacks and separate environments. At minimum you want three.

Local, staging and production

Local is where engineers work. Staging is a copy of production with fake data, used to test every change before release. Production is the only place real customers and real data exist. Each should have its own database, its own keys and its own domain or subdomain. If testing happens against the live database, customers eventually receive test emails and test records.

Choosing a host

Most front-end-heavy Bolt apps can run on a managed static or serverless host. Apps with long-running server code, background jobs or websockets need a host built for that. The right choice depends on what the app actually does, so decide it after reading the code, not before. Whatever you pick, deploys should come from the repository, not from a manual upload.

Step 3: environment variables and secrets

This is where generated apps most often leak. Anything bundled into the browser code is public, no matter how it is named. Walk through the following.

• Separate public from private. Values that are safe in the browser (for example a publishable key or a public API URL) are different from secret keys, which must live only on a server.
• Search the built output. Open your production JavaScript bundle and search for key prefixes and service names. If a secret is there, treat it as compromised and rotate it.
• Use the host's secret store for production values and a documented example file for local setup. Never share secrets in chat messages or tickets.
• Use different keys per environment, with least privilege and spending caps, especially for any language-model API key your app calls.
• Move calls that need secrets to the server. If the browser currently talks directly to a paid third-party API with a key, add a thin backend endpoint that holds the key and applies per-user limits.

Step 4: backend, database and migrations

Bolt apps commonly pair a front end with a hosted database and authentication service, and sometimes with serverless functions. The question for production is not "which one" but "who controls it, and can it be rebuilt".

Make the schema reproducible

If the tables only exist because a prompt created them, you cannot recreate them reliably. Export the schema into version-controlled migration files, apply them to a fresh database and confirm the app works. Then future changes go through migrations, reviewed like code, and never through manual edits in a dashboard.

Access rules, backups and restores

Check that every table holding user data has access rules, and prove tenant isolation with two test accounts. If you use Supabase, our guide to Row Level Security mistakes in AI-built apps covers the usual traps. Turn on backups, and then test a restore into a scratch database. A backup you have never restored is a hope, not a plan.

Step 5: auth and payments hardening

Generated authentication usually works for the happy path. Production needs the unhappy ones.

• Authorization enforced on the server, not only by hiding buttons.
• Roles stored where users cannot edit them.
• Email verification, password reset with expiring single-use links, and rate limits on login and sign-up.
• Multi-factor authentication for admin accounts.

For payments, the success page is only a browser redirect. Paid access should come from verified, idempotent webhook events, with test and live modes fully separated. We walk through the failure modes in Stripe webhooks and subscriptions in AI-built apps. Check renewals, failed payments, cancellations and refunds before launch, not after the first angry email.

Step 6: CI and dependency hygiene

Continuous integration (CI) is an automated job that runs on every change. Even a small one pays for itself.

1. Install from the lockfile so builds are repeatable.
2. Run lint, type checks and the build on every pull request.
3. Add a few tests around money and access: sign-up, login, a paid action, and a cross-account access attempt that must fail.
4. Deploy automatically to staging, and to production after approval.

On dependencies, generated projects often pull in packages that were convenient for one prompt and are no longer needed. Remove unused ones, update packages with known security advisories, and pin versions. Fewer dependencies means a smaller surface to maintain.

Step 7: performance and monitoring

A demo with ten rows of data feels fast. Production does not. Check the basics:

• Heavy pages. Look at bundle size, unoptimised images and data fetched on every render.
• Database queries. Watch for lists that load everything at once, and add indexes for the columns you filter and sort on.
• Error monitoring and uptime alerts that reach a person who will act. If the first you hear about an outage is a customer, monitoring is missing.
• Logs without secrets or personal data, kept long enough to investigate an incident.

Patch or rebuild? Decide section by section

The question is rarely "rebuild the whole app". Judge each area separately.

Usually worth patching

Screens and flows that users understand, working integrations, and a data model that matches your business. These hold real product decisions, and rewriting them throws away learning.

Often worth rebuilding

Authentication and authorization that was bolted on in layers, payment logic scattered through the front end, and a database design that fights every new feature. These are the parts where a clean, tested implementation is commonly cheaper than layers of fixes. Our post on when to stop prompting and hire an engineer lists the signs that you have reached that point.

A rescue path, in order

1. Freeze features. Stop adding things while you stabilise.
2. Take ownership. Move the code to your repository and record who has access to hosting, database, domain and payments.
3. Baseline and inventory. List every service, key and environment. Run the free AI App Health Check to spot obvious gaps.
4. Rotate exposed secrets and move private calls to the server.
5. Make the database reproducible, switch on backups and test a restore.
6. Harden access and payments, proving it with two accounts and test payments.
7. Add CI and a staging environment.
8. Add monitoring and a rollback plan with a named owner.
9. Launch to a small group first, then widen.

How UnlockLive fits in

If you would rather not do this alone, our two services follow the same path. The AI App Technical Audit reviews the code, data, auth, payments, infrastructure and risks, and gives you a prioritised list of what to fix and in what order. The AI App Repair and Launch service then carries out the fixes and builds the deployment pipeline, so the app goes live on infrastructure you own. Our engineers work from Toronto and our Dhaka engineering centre, with project management on the Toronto side.

Ready to take your Bolt app to production?

Start with the free AI App Health Check to see where your app stands, then decide whether you need an audit, a repair or just a few afternoons of focused work. Most of what stands between a Bolt prototype and a dependable product is fixable without starting over, as long as you find it before your customers do.