Making a Bolt.new App Production-Ready

What changes between a Bolt prototype and production

Bolt.new builds and runs your app inside the browser using StackBlitz WebContainers, which is why it feels instant. Production is a different environment: a real Node.js runtime or static host, real users, real data and nobody watching the preview. Most problems we see in Bolt projects come from that gap, not from the generated code being unusable. The checklist below closes it step by step.

1. Own the code and the accounts

• Connect the project to GitHub or download it, and make that repository the single source of truth. From then on, changes made in Bolt arrive as commits you can review.
• Create hosting, database, domain and third-party accounts under your company, not under a personal login of whoever built the prototype.
• Check that the project builds on a clean machine with npm ci and a pinned Node.js version. If it only works inside Bolt, you do not fully own it yet.
• Read the tool’s terms of service on code ownership and usage, especially if investors or customers will ask.

2. Hosting and environment variables

Bolt offers built-in deployment, including a Netlify integration, which is fine for many apps. For production, make sure deployments are triggered from your repository through a pipeline, not by pressing a button in the editor, so every release is reproducible.

Environment variables need special care. Bolt projects are frequently built with Vite, and Vite exposes every variable prefixed with VITE_ to the browser bundle. That is correct for a public Supabase URL or a publishable key and wrong for anything secret. Payment provider secrets, AI API keys and service role keys belong in server-side functions. Also check that .env files are listed in .gitignore and were never committed.

3. Database and data

Depending on how the project was set up, data lives in Supabase or in a backend provided by Bolt. Either way, before real users arrive:

1. Separate development and production databases, so prompts and experiments never touch live data.
2. Keep schema changes as migrations in the repository.
3. Enable backups and test a restore at least once.
4. With Supabase, verify row level security on every table, because the browser talks to the database directly.

4. Monitoring and tests

A prototype fails silently. Production should not. Add an error tracking service such as Sentry with source maps uploaded during the build, so stack traces point to real lines of code. Add simple uptime monitoring for the main URL and any API endpoints.

You do not need full test coverage on day one. Start with what hurts most when it breaks:

• end-to-end tests with Playwright for sign-up, login and the main paid or core flow,
• unit tests with Vitest for pricing, permissions and data transformations,
• a CI job that runs type checks, linting and tests on every pull request.

Once tests exist, you can keep using Bolt or another agent for changes without fear that each prompt breaks something unnoticed. Our guide on testing strategies for AI-generated code goes deeper.

When to keep Bolt and when to move on

Bolt remains useful for UI iterations and quick features as long as the repository and pipeline are the source of truth. Teams usually move to a regular IDE or a coding agent like Claude Code when the codebase grows, when several developers work in parallel or when backend logic becomes more complex than the generated structure handles well.

How jocapps can help

OnlineAppCreator is our ISO-certified B2B and B2G delivery team in Germany. It takes AI-built prototypes such as Bolt apps into production: repository and account handover, hosting and CI setup, secrets, database hardening, monitoring, tests and long-term maintenance under an SLA. See our prototype to production service or book a free 30-minute intro call via the meeting planner.