Launch
How to Launch an App Built With Bolt
Bolt.new lets you describe an app in plain language and watch it appear in the browser — complete with a live preview URL. That preview feels like launch day, but it is not the same as owning your code on GitHub and deploying to a host you control. This guide walks through the full path from Bolt preview to production: exporting your project, syncing to GitHub safely, picking the right host, and fixing the failures that show up when Bolt's in-browser magic meets real-world deployment.
Updated July 2026 · 12 min read
Written for AI makers using tools like Cursor, Bolt, Lovable, Replit, Claude, and ChatGPT.
Quick answer
Bolt builds and previews your app in the browser — it does not replace GitHub and a production host. Export or sync your Bolt project to GitHub, review AI-generated config for hardcoded keys, match your stack to Vercel (frontend/serverless) or Railway (full-stack/API), set environment variables on the host, and deploy. Run a readiness scan before going live to catch preview-only settings.
Best for
Bolt.new apps ready to leave preview and go to a URL you own
What the tool gives you
Live browser preview + a full generated project in a WebContainer
What still needs launching
GitHub export, host choice (Vercel vs Railway), env vars, deploy
Main risk
Preview-only config — keys, SQLite, CORS — breaking in production
Who this is for
- You built an app in Bolt.new and the preview works, but you want a URL you own and control
- You exported a Bolt zip or connected GitHub and hit build errors on Vercel or Railway
- You are unsure whether your Bolt app is frontend-only or needs a full-stack host
What you'll need
- A Bolt.new account with a finished or near-finished project
- A GitHub account for storing and deploying your code
- A hosting account — Vercel for most React/Next.js Bolt apps, Railway if you have a persistent backend
- API keys from any services Bolt integrated (OpenAI, Stripe, Supabase, etc.)
Key concept
What Bolt gives you — and what it does not
Bolt.new is a browser-based AI builder. You chat with it, and it generates a full project — React components, API routes, config files, and dependencies — then runs it inside a WebContainer so you see a live preview without installing Node locally.
That preview URL is real and shareable, which makes Bolt feel like deployment. But Bolt's preview runs on StackBlitz infrastructure with Bolt-managed environment. You do not control scaling, custom domains, production database isolation, or long-term uptime the way you do on Vercel or Railway.
Bolt does not replace GitHub or a dedicated host for a serious launch. Think of Bolt as rapid prototyping and iteration. When you are ready for beta users, a custom domain, or production-grade secrets management, you export the code and deploy elsewhere.
Bolt can also regenerate or overwrite files during chat sessions. Once you export, your GitHub repo becomes the source of truth — not the Bolt project history.
Deploy settings
Export your code from Bolt.new
Bolt offers two main ways to get code out: GitHub integration and direct download. Both work — pick based on whether you already use GitHub.
GitHub sync (recommended): In your Bolt project, open the GitHub panel and connect your account. Bolt creates a repository and pushes your current codebase. This is the cleanest path because Vercel and Railway deploy directly from GitHub.
Zip download: If you prefer GitHub Desktop or want to review files first, download the project as a zip. Unzip it locally, confirm .gitignore excludes .env, then upload via GitHub Desktop or Cursor Source Control.
After export, open the repo on github.com and scan the file list. Bolt sometimes generates .env files with real keys during preview. If .env is visible in the repo, remove it from Git history, add it to .gitignore, and rotate every exposed key before deploying.
- GitHub sync (recommended) or zip + GitHub Desktop
- Confirm
.gitignoreexcludes.envbefore first push - Scan github.com for accidental key files after export
- Rotate any key that was ever committed
Watch out
Review Bolt's AI-generated configuration
Bolt moves fast. It may add API routes, middleware, database clients, and environment variable references you never read line by line. Before deploying, do a focused review pass — or ask Bolt itself to audit the exported code.
Search the codebase for hardcoded secrets. Bolt occasionally embeds API keys directly in client-side files because that makes the preview work instantly. Keys in .tsx or .jsx files will be public after deploy — move them to server-side routes or environment variables.
Check for localhost URLs in fetch calls, OAuth redirect URIs, and CORS settings. Bolt configures these for its preview origin, not your production domain.
Read package.json scripts. Bolt usually sets dev, build, and start commands, but verify they match what your host expects. Note the Node version if Bolt pinned one in engines or .nvmrc.
- Search for sk-, pk_live, api_key, and Bearer strings in source files
- Confirm
.env.examplelists every variable the app reads at runtime - Check whether API logic lives in /api routes (serverless-friendly) or a separate Express server (needs Railway/Render)
- Look for SQLite or local file storage — these work in Bolt preview but fail on serverless hosts
Deploy settings
Choose hosting that fits your Bolt stack
Most Bolt projects ship as React with Vite, Next.js, or a similar JavaScript framework. The right host depends on whether your backend runs as serverless functions or as a long-lived Node process.
Vercel fits when: your app is a Next.js or React frontend, API logic lives in /api routes or Edge Functions, and you do not need a persistent WebSocket server or background worker running 24/7. This covers a large share of Bolt apps.
Railway fits when: Bolt generated an Express or Fastify server, you use a long-running process, you need PostgreSQL with persistent connections, or serverless timeouts cause failures. Railway also works well for full-stack Bolt apps with a separate backend folder.
If Bolt added Python (Flask/Django) or a Dockerfile, look at Railway, Render, or Fly.io instead of Vercel. Mismatch here is the number-one reason Bolt exports fail on the first deploy attempt.
- Next.js / serverless API → Vercel
- Express, WebSockets, PostgreSQL → Railway
- Python / Docker → Railway, Render, or Fly.io
Key concept
Set environment variables for production
Bolt's preview injects environment variables behind the scenes so your app works immediately. Those values do not travel with your GitHub repo — and they should not.
Open .env.example in your exported project. Every variable listed there needs a matching entry in your host's environment settings dashboard. Common Bolt integrations include OPENAI_API_KEY, STRIPE_SECRET_KEY, DATABASE_URL, and Supabase URL/key pairs.
Client-side variables need framework-specific prefixes: NEXT_PUBLIC_ for Next.js, VITE_ for Vite/React. Without the prefix, the variable exists on the server but your browser code sees undefined — a classic 'works in Bolt preview, blank in production' bug.
After adding or changing environment variables, trigger a new deploy. Most hosts do not hot-reload env changes into running builds.
- Copy every name from
.env.exampleto the host dashboard NEXT_PUBLIC_for Next.js client vars ·VITE_for Vite client vars- Redeploy after every env change
Deploy settings
Deploy and verify on your host
Connect your GitHub repository to Vercel or Railway. The platform will detect your framework and suggest build settings. Compare them to the scripts in package.json before clicking Deploy.
Add all environment variables before the first production deploy if possible. Apps that crash on startup because DATABASE_URL is missing waste hours of log-diving.
When the build finishes, open the provided URL in an incognito window. Test signup, login, payments, and any AI features. Bolt previews often have auth relaxed or use test keys — production may behave differently.
Check deploy logs for the first error at the bottom of the stack trace. 'Module not found', 'ECONNREFUSED', and 'Invalid API key' each point to different fixes.
- Connect GitHub → add env vars → deploy
- Test core flows in incognito, not just the homepage
- Read deploy logs from the bottom up for the real error
Watch out
Bolt-specific failures: preview vs production
These patterns appear constantly when moving Bolt projects off preview hosting.
- Preview works, production shows blank page → client env vars missing
VITE_orNEXT_PUBLIC_prefix - API calls fail with CORS error → backend still allows only Bolt or
localhostorigins - 500 errors on API routes → server-side env vars not set on Vercel/Railway dashboard
- Build succeeds but features hang → serverless function timeout (move heavy logic to Railway or increase timeout)
- Database 'unable to open' → SQLite used in Bolt preview; switch to PostgreSQL for production
- Stripe or OpenAI 'invalid key' → test keys in Bolt preview, live keys needed (or vice versa) in production
- Hardcoded key exposed in browser DevTools → move secret to server route, never ship in client bundle
After you leave Bolt preview
Your GitHub repo is now the canonical project. Make future edits in Cursor or your preferred editor, commit, and push — hosts redeploy automatically.
Keep Bolt as a prototyping tool if you like, but avoid editing the same project in both Bolt and GitHub without syncing carefully. Conflicts are common when two sources of truth diverge.
When you add new API integrations, update .env.example and your host's env dashboard together. Run a readiness scan after major changes to catch regressions before users do.
Bolt workspace vs GitHub repo vs deployed app
| Criteria | Bolt workspace | GitHub repo | Deployed app |
|---|---|---|---|
| Where it runs | StackBlitz WebContainer | GitHub cloud storage | Your host (Vercel, Railway, etc.) |
| Code ownership | Inside Bolt project | Your repository — source of truth | Built from GitHub on each deploy |
| Env vars | Bolt injects for preview | Only .env.example — no secrets | You set in host dashboard |
| Backend fit | SQLite / preview-only OK | Full project structure visible | Must match host (serverless vs Railway) |
| Best use | Prototype and iterate fast | Backup + connect to hosts | Real users, custom domain, uptime |
Step-by-step
- 1
Step 1
Export or sync to GitHub
Connect Bolt to GitHub or download the zip and upload via GitHub Desktop. Verify no
.envfile with real keys is in the repository. - 2
Step 2
Review generated config
Search for hardcoded keys,
localhostURLs, and SQLite usage. Update.env.examplewith every required variable name. - 3
Step 3
Pick Vercel or Railway
Next.js or serverless API routes → Vercel. Express server, WebSockets, or PostgreSQL → Railway.
- 4
Step 4
Run a readiness scan
Scan your GitHub repo for launch blockers. Fix critical security and config issues before deploying.
- 5
Step 5
Deploy, set env vars, test live
Connect repo to host, add environment variables, deploy, and walk through core flows on the production URL in incognito mode.
Common mistakes
Treating Bolt's preview URL as your permanent production site
What happens: You cannot add a custom domain, control env vars reliably, or guarantee uptime on Bolt preview hosting.
How to fix it: Export to GitHub and deploy on Vercel or Railway for custom domains, env control, and reliable uptime.
Deploying a Bolt Express backend to Vercel serverless without changes
What happens: Build may succeed but API routes time out, crash, or fail to stay running.
How to fix it: Move long-running servers to Railway or refactor API logic into /api serverless routes.
Leaving API keys in client-side Bolt-generated components
What happens: Anyone can open DevTools and copy keys from the downloaded JavaScript bundle.
How to fix it: Move secrets to server-side routes or environment variables. Rotate any key that was ever in GitHub.
Skipping
.env.examplereview after exportWhat happens: Production deploy starts with missing vars — blank pages, 500 errors, or failed API calls.
How to fix it: Bolt preview injects vars silently. Your host needs every name from
.env.exampleset manually.Not redeploying after adding environment variables
What happens: The running build still uses old or missing values until a fresh deploy runs.
How to fix it: Trigger a fresh deploy from your host dashboard after every env change.
Copy-ready prompt
Prompt: audit Bolt export before deploy
Paste this into Cursor, Claude, ChatGPT, Bolt, Lovable, or your AI coding tool.
Ready to paste
I exported this Bolt.new project to GitHub and I am ready to deploy to production. 1. Identify the framework (Next.js, Vite/React, Express, etc.) and recommend Vercel vs Railway. 2. Detect whether this is frontend-only, serverless API routes, or a separate backend server. 3. List every environment variable this app needs. Update .env.example with placeholders only. 4. Find hardcoded API keys, localhost URLs, or Bolt preview-specific config and fix them. 5. Tell me whether any API logic must move from client to server for security. 6. Confirm build and start commands for my chosen host. 7. Flag anything that worked in Bolt preview but will break in production (SQLite, missing env prefixes, CORS). Do not put real API keys in any file committed to GitHub.
Paste this into Cursor, Claude, ChatGPT, Bolt, Lovable, or your AI coding tool.
Ready check
Before you launch
Work through these checks before you connect a host.
- Exported Bolt project to GitHub (or zip uploaded safely)
- No
.envor real API keys visible on github.com .env.examplelists all required variable names- Hardcoded keys and
localhostURLs removed or updated - Hosting platform chosen (Vercel for serverless, Railway for full-stack)
- Launch readiness scan completed — critical issues fixed
- Environment variables set on host dashboard
- Build and deploy succeeded
- Core user flows tested on live URL in incognito mode
Frequently asked questions
- Can I keep using Bolt after I deploy elsewhere?
- Yes, but treat GitHub as the source of truth once exported. Edits made only in Bolt without syncing back to GitHub will not appear in production deploys.
- Why does my Bolt app work in preview but fail on Vercel?
- Bolt preview injects environment variables and runs on different infrastructure. Missing env vars on Vercel, wrong build output directory, or serverless-incompatible backend code are the usual causes.
- Should I use Vercel or Railway for a Bolt app?
- Vercel for Next.js and apps whose API lives in serverless routes. Railway for Express servers, PostgreSQL, WebSockets, or anything that needs a long-running Node process.
- Does Bolt push secrets to GitHub automatically?
- It can if
.envwas generated during preview and not gitignored. Always check your repo after the first push and rotate any exposed keys. - How do I add a custom domain to a Bolt-launched app?
- Custom domains are configured on your production host (Vercel, Railway), not in Bolt. After adding the domain, update OAuth callbacks and any hardcoded URLs in your codebase.