How to deploy a Bolt.new app to production (and what will break)

Updated June 2026 · 7 min read

Bolt.new runs your app in a WebContainer — a browser-based sandbox that behaves just enough like a real server to be convincing. Production is a different planet. Here's the path from "works in Bolt" to "works at a URL you can put on a business card," including the parts that reliably go wrong.

Step 1: Get it out of Bolt

Export to GitHub (or download the zip and push it yourself). Before anything else, run it locally: npm install, then npm run dev. If it doesn't run on your machine, it won't run on a server — fix local first. The usual first failure is missing environment variables; search the code for process.env and import.meta.env and build your .env file from what you find.

Step 2: Know which kind of app you have

This determines where you can host it:

• Pure frontend (Vite/React, no server code): any static host — Vercel, Netlify, Cloudflare Pages. Easiest case.
• Full-stack framework (Next.js, Remix, Astro SSR): Vercel or Netlify will detect and build it. Mind the env vars at build time vs runtime — they're different buckets.
• Custom Node server (an express server in the repo): you need a host that runs processes — Railway, Render, Fly.io — not a static host. This is the one people get stuck on most.

Step 3: The backend you don't actually have

The classic Bolt trap: inside the WebContainer, your app may have been "persisting" data to memory or local storage. It looked like a database. It wasn't. Refresh-proof in the preview is not the same as persistent in production. If your app needs real data, you need a real database (Supabase, Neon, Convex) and real API routes in front of it. Check what you actually have before you deploy — features built on sandbox persistence will quietly lose everyone's data.

Step 4: The security pass nobody asked the AI for

Before sharing the URL anywhere public, check these four things. They take an hour and they're the difference between a launch and an incident:

• API keys in client code. Anything in frontend code ships to every visitor's browser. OpenAI/Stripe secret keys must live on the server only. Search the built output for sk- if you're not sure.
• Unprotected API routes. AI-generated endpoints frequently trust the client completely. Every route that reads or writes user data needs an auth check on the server.
• Database rules. If you bolted on Supabase or Firebase, confirm row-level security / security rules actually restrict access per user.
• Auth misconfiguration. OAuth callback URLs and site URLs are domain-bound and will break on your production domain — here's the full auth-repair guide.

Step 5: Deploy, then verify like a user

After the first deploy, don't just look at the homepage. Sign up as a brand-new user in an incognito window, do the core action of your app, refresh, and check the data survived. Most "deployed but broken" reports we see would have been caught by five minutes of pretending to be a customer.

Related reading: fixing a broken Lovable export covers the same disease in a different tool, and what it costs to have this done for you if the checklist above is more weekend than you wanted to spend.