All posts
5 min read

How to Deploy a Bolt.new App: Bolt Hosting, Netlify, or Your Own Server

Bolt.new can publish your app in one click, to its own hosting or to Netlify. What each option actually gives you, when to export the code and host it yourself, and the checks to run before you share the link with real users.

deploymentno-codegetting startedBolt

Bolt.new builds full web apps from a prompt, in the browser, and it can put them online without you leaving the page. That's genuinely impressive — and it leaves a lot of builders unsure what they've actually got. Is the published app production-ready? Where does the data live? What happens if you want to move?

Here are the deployment options, what each gives you, and the checklist before you share the link.

Bolt's hosting options have changed several times; this reflects September 2026. Check Bolt's support docs for the current details.

Option 1: Bolt hosting

New Bolt projects publish to Bolt's own hosting by default. You get a URL on a Bolt subdomain, and paid plans let you connect a custom domain. Bolt also offers databases for your projects, built on Supabase, with a security audit tab in the project settings.

Good for: getting something in front of people quickly, prototypes, and projects where you'll keep iterating inside Bolt.

Watch for: the builder, the hosting, and the database are one vendor. That's the whole appeal, and it's also the lock-in.

Option 2: Netlify via Bolt's integration

Bolt has a long-standing integration with Netlify: connect your Netlify account and publish straight from the editor. You still work in Bolt, but the deployed site lives on Netlify.

Good for: people who want a mainstream, well-known host with its own dashboard, deploy history, and rollbacks — without leaving Bolt's workflow.

Watch for: Netlify is excellent at frontends and serverless functions. If your app grows a long-running backend, you'll need something else for that part.

Option 3: export the code and host it yourself

Bolt apps are standard code — usually a JavaScript framework like React or Next.js, plus a Supabase or similar backend. You can download the project or push it to GitHub, then deploy it anywhere:

  1. Get the code into a GitHub repository.
  2. Run it locally once (npm install, then npm run dev) to see what breaks outside Bolt.
  3. List every environment variable the app uses and recreate them on your host.
  4. Deploy: a static host for frontend-only apps; a platform that runs server processes if there's a backend.
  5. Connect your domain and confirm HTTPS works.

Good for: apps that have become real products, teams bringing in a developer, and anyone who wants the app to outlive their choice of builder.

Which to choose

Situation Choose
Testing an idea this week Bolt hosting
Real users, frontend-heavy, happy in Bolt Netlify integration
Real backend, a developer joining, or long-term product Export to GitHub and host it
You'll keep building it with an AI agent after launch A platform where the agent works against the running app

The one-click deploy hides every decision, including the ones that matter. Check these yourself.

Your database is locked down

If your app uses Supabase (directly or through Bolt's database), the key in your frontend is public — anyone can read it from the page source. What protects your data is row-level security: rules in the database saying who can read which rows.

  • Enable RLS on every table.
  • Write policies that restrict each user to their own data.
  • Test it: sign in as a second user and try to read the first user's records. Try again logged out.

Missing RLS is how, in 2025, a large number of apps from one popular AI builder exposed their users' data to anyone who looked. It's the most important check on this list. Run Bolt's security audit, then verify by hand.

No secret keys in the frontend

Any key the browser can see, a visitor can see. Payment provider secret keys, AI API keys, and Supabase's service-role key must only ever exist in server-side code or serverless functions. If you're not sure how to tell the difference, read How to Keep API Keys Out of an AI-Built App before launch.

Data survives changes

Make a change, redeploy, and confirm your test data is still there. It sounds obvious; it's the most common way AI-built apps lose everything.

Backups exist

Find out exactly what your database plan backs up, how often, and how to restore it. "It's managed" doesn't always mean "it's backed up."

The real flows work on the real URL

Sign up, confirm email, log in, reset a password, pay — on the deployed site, not the preview. Auth redirects and payment webhooks are registered against specific URLs and are the usual things that break after deploy.

When you've outgrown the builder

Signs it's time to move the app somewhere with more room:

  • You need background jobs, scheduled tasks, or a long-running server.
  • A developer is joining and wants a normal repository and deployment flow.
  • You want staging and preview environments per branch.
  • Costs are hard to predict, or you want the database under your own control.

None of that means Bolt was the wrong choice — it got you to a working app fast. It means the app has become something that needs infrastructure rather than a publish button. Our plain-English guide to what that involves is You Built an App With AI. Now What?

EasySpawn is where an AI-built app goes once it needs real infrastructure: managed Postgres with daily backups, automatic SSL, your own domain, and Claude Code continuing to work on the live app. See how it works for AI-built apps or join the waitlist.

Related: How to Deploy a Lovable App to Production · A Security Checklist for Vibe-Coded Apps

Keep reading