How to Deploy a Bolt.new App: 5 Proven Paths to Production

Deploying a Bolt.new app means choosing between five paths: Bolt's native hosting, exporting to GitHub and using Vercel or Netlify, managed platforms like Northflank or Railway, Coolify for self-hosted infrastructure, or building on bare metal with Hetzner. Your choice depends on three trade-offs: operational burden, cost predictability, and how much control you want. Most teams find one of the first three handles their needs.

What Are Your Deployment Options?

Here are your five paths, from zero-ops to full-ops:

Each path has a tradeoff. Bolt.new is fastest and requires zero ops. GitHub export is flexible but may have cold starts on serverless functions. Managed platforms like Northflank remove ops burden while keeping your code portable. Coolify and Hetzner save money but require infrastructure knowledge and ongoing maintenance.

Path 1: Publish to Bolt.new Hosting

Bolt.new includes a publish button that deploys directly to Bolt's infrastructure. Click it, wait 60 seconds, your app is live. Bolt handles SSL, CDN, and domain routing automatically. You get a live URL immediately, no configuration required.

The free tier caps you at 150,000 tokens daily and 1,000,000 tokens monthly. Paid plans run $20/month to $200/month and increase token limits, not compute resources. If your app hits Bolt's infrastructure limits, you cannot scale horizontally. Database connections are limited. You cannot install custom system packages or run arbitrary code. Environment secrets are managed inside Bolt's console only, with no integration to external secrets managers.

This path makes sense if: you want to ship in one day, your app is read-heavy or a chatbot, you're okay with Bolt's token economy as your cost ceiling, or you're building a prototype to demo to customers.

This path breaks if: you need persistent database storage (add Supabase separately, debug connections through Bolt's UI), you need to scale beyond Bolt's infrastructure (you're locked in), or you want to export and run elsewhere later (you cannot export the running server for migration).

Path 2: Export to GitHub & Deploy to Netlify/Vercel

Bolt.new lets you export your app as a Git repository. The entire codebase--frontend, backend, dependencies, build scripts--is yours. Push to GitHub, connect to Netlify or Vercel, and the app deploys automatically on every push.

This is the most common path. Setup takes 15 minutes. Both Netlify and Vercel offer free tiers suitable for testing. Both handle SSL and CDN automatically. Scaling is automatic when traffic spikes, but costs can climb if usage is heavy.

The workflow is straightforward:

1. Open your Bolt.new project. Click Export or Publish to GitHub. Authorize Opsily to create a repo under your GitHub account, then confirm. GitHub repo is created with your complete code.

2. Sign in to Netlify.com or Vercel.com. Authorize GitHub access to your repos. Select your Bolt.new export repo from the list.

3. Configure environment variables. If your app uses Supabase, add SUPABASE_URL and SUPABASE_KEY. Add any third-party API keys, database connection strings, or OAuth secrets here. Do this before deploying.

4. Deploy. Your platform pulls your code, runs npm run build, uploads the compiled output to their CDN, and your app goes live. This takes 2-5 minutes.

5. Continuous deployment works automatically: push code to GitHub, Netlify or Vercel rebuilds and redeploys within minutes.

Cost varies by usage. Both platforms offer free tiers. If your app has heavy backend workloads or high traffic, costs can climb beyond their free limits.

Pain points are real. If your Bolt app includes a Node.js backend, it runs as serverless functions. This means cold starts on first request--a delay before the function spins up and your code runs. Database connections in serverless environments require pooling tools like PgBouncer, adding complexity. If you use Supabase, you may hit connection limits under load without pooling. Most tutorial articles skip this--they teach you how to deploy, not what happens at 3 AM when traffic spikes and your database connection pool exhausts.

Path 3: Deploy to a Managed Platform

Managed platforms like Northflank, Railway, Render, and Ship sit between Netlify (least operational work) and bare-metal Hetzner (most operational work). They run your app in containers, handle networking, SSL provisioning, monitoring, and storage for you.

You export your Bolt app to GitHub, connect it to a managed platform, and the platform builds a Docker image, runs it in a container, assigns it resources (CPU, RAM), and handles all the infrastructure plumbing. Cost varies by platform and resource allocation, typically $15-$100+ per month.

Northflank is the incumbent in this space. It's designed for developers shipping production apps: strong networking support for multi-service architectures, built-in database provisioning (PostgreSQL, Redis), monitoring dashboards, and automatic scaling policies. The UI is more complex than Netlify--you configure services, databases, and environment variables separately--but the operational control is worth it. Cold starts are minimal because your app is always running, not spinning up on demand. This matters for production apps where latency affects user experience.

Railway offers simpler onboarding than Northflank but less granular control. You connect your GitHub repo, Railway infers your app type (Node, Python, static, etc.), and deploys automatically. Scaling is automatic. Cost is usage-based, so a spike in traffic can surprise you with a higher bill--a downside for cost-conscious teams.

Render is similar to Railway: simple UI, automatic deployments, usage-based pricing. Both are good choices if you want simplicity and don't need granular networking or resource control.

Ship is purpose-built for apps built with Bolt.new and similar AI builders. It's tuned for this use case: networking, environment setup, and observability are optimized for vibe-coder tools. Flat-rate pricing (no surprise bills on traffic spikes) is a core design choice. Ship's managed hosting for Bolt apps is worth evaluating if cost predictability and operational simplicity matter more than maximum flexibility.

Most teams choose Northflank or Railway for flexibility (they handle any app type) and Ship if they want predictable costs and simpler operations for Bolt-specific apps.

Pre-Deployment Checklist

Before you deploy to any platform, verify these seven things. Mistakes here are the most common reason apps fail silently post-deploy.

1. Environment variables are correct and secure. If you use Supabase, SUPABASE_URL and SUPABASE_KEY must match your project. If you use a third-party API, your API key must be correct. Database connection errors post-deploy usually mean wrong env vars. Do not try to debug this after deploying--verify locally first.

2. Database is seeded. If deploying with a new database, run migrations or verify Supabase schema matches your app expectations. If you built custom tables, verify they exist and have the right columns. A schema mismatch is a silent failure: your app deploys, but database queries fail.

3. Secrets are not in code. Never commit API keys, OAuth tokens, database passwords, or any sensitive data to Git. Store them as environment variables on your deployment platform's env vars UI, not in.env files pushed to GitHub.

4. Your app builds locally. Run npm run build on your machine and verify no errors. This catches missing dependencies before deploy. Most deploy failures are build failures, not runtime failures.

5. Static assets are served correctly. Verify images, CSS, fonts are in your public folder (or assets folder, depending on your framework) and referenced with correct paths. Absolute URLs to localhost will break on production.

6. CORS is configured if you have a backend API. If your frontend calls your own backend API, CORS headers must allow it. If you call external APIs, verify those services allow requests from your deployed domain.

7. Database connection pooling is enabled for PostgreSQL. If using Supabase or similar managed PostgreSQL, add a pooling layer (PgBouncer or Supabase's built-in connection pooler) to avoid "too many connections" errors under load. This is especially important on serverless platforms where each function creates a new connection.

Troubleshooting Common Deployment Issues

Build errors appear in your deploy logs. You exported Bolt.new to GitHub, deployed to Netlify, and the build failed. Check the build logs (Netlify and Vercel show them in their UI). Common causes: missing Node.js dependency (add to package.json), missing environment variable (set it on your platform's env vars page), incorrect node version, or a build script that fails locally too (test locally first with npm run build).

Cold starts slow your first request. You deployed to Netlify or Vercel using serverless functions. The first request to your app is slow (2-5 seconds latency). This is normal and expected for serverless. Subsequent requests are faster. You cannot eliminate this without using a container-based platform (Northflank, Railway, Ship) where your app is always running, not spinning up on demand.

Database connection errors are a common culprit. Your app cannot connect to Supabase or PostgreSQL. Verify the connection string (DATABASE_URL or SUPABASE_URL) is set correctly on your platform's environment variables page. Verify the database is running and accepting connections. Verify your app's IP firewall rules (if any) allow outbound connections. If using Vercel or Netlify serverless, verify connection pooling is enabled and the pooler is reachable.

App hangs or timeouts signal trouble. Your app deployed but requests time out or hang indefinitely. Common cause: your app is waiting for a database response that never comes (connection pooling exhausted, or query is slow). Check your platform's logs to see what's happening. Verify database connection pooling is enabled and has enough capacity for peak traffic.

Missing environment variables cause silent failures. Your app runs locally but fails after deploy because an environment variable is missing. Verify you added it to your platform's environment variables UI. Some platforms require you to redeploy after adding env vars (not automatic). Double-check the variable name matches exactly (case-sensitive).

Builds succeed but app crashes on startup. Your app built fine, but when the container starts, it crashes. Common cause: your app expects a file or directory that doesn't exist (e.g.,.env file, database migration), or your app tries to connect to a service that's not available yet. Check platform logs for the exact error.

Production Readiness After Deploy

Your app is live. Now verify it's production-ready by doing these seven things.

Monitor errors daily the first week. Your platform has an error or crash dashboard. Check it daily for the first week after deploy. If errors spike, fix or roll back fast. Most post-launch issues surface within the first 24 hours.

Set up logging from day one. Log important events: user actions, API calls, database queries (at debug level only, never in production with sensitive data). Use your platform's logging or a log aggregation tool to search logs and set up alerts. You'll need this to debug issues when they happen.

Monitor response time and latency. Slow responses mean users leave. Track latency on your platform's dashboard (Northflank, Railway, Ship all provide this). Spikes may indicate slow database queries, slow external APIs, or your app doing too much work in a single request.

Watch your bill from day one. If using usage-based pricing (Netlify, Vercel, Railway), track costs daily the first month. Set a billing alert at 80% of expected spend to catch surprises before they become expensive. Some platforms let you set hard limits to prevent runaway costs.

Set up alerting for errors and downtime. Configure alerts on your platform: high error rate, high latency, app crash, or out-of-memory. You want to know about problems immediately, not when a user complains.

Test exports and backups before you need them. If your app has user data, verify you can export it. Can you back up your database? Can you restore from backup? Test this before you have an actual emergency.

Plan for data export and portability. Bolt.new doesn't offer a built-in "export my users" feature. You own this responsibility. If using Supabase, you can query and download data. If using a third-party service (Auth0, Stripe, etc.), verify you can export customer data if you need to switch platforms later. Plan this from the start, not after an outage.

When Should You Self-Host vs. Managed?

Bolt's native hosting is fastest for prototypes and demos. You accept infrastructure lock-in for zero operational work. Use it if you want to ship in an afternoon and don't care about portability.

GitHub plus Netlify or Vercel is the mainstream default: simple, automatic scaling, cheap to start ($0-50/month). Cold starts are the main trade-off. Use this if traffic is unpredictable, you want zero ops, and you can tolerate 2-second first-response latency.

Managed platforms (Northflank, Railway, Ship) make sense when: your traffic is consistent (cold starts become a real problem), you need database persistence with connection pooling, you want one predictable invoice instead of surprise overage charges, or you need private networking between services.

DIY infrastructure (Coolify on Hetzner, or bare metal) only wins on raw cost if you have significant scale and team bandwidth to manage it. A Hetzner VPS costs $4-6/month, but you manage everything: OS updates, security patches, backups, monitoring, SSL certs, deployment scripts. Before you pick this path, calculate your time cost: infrastructure management takes 5+ hours per month at scale. Is that cheaper than $50/month on a managed platform? Usually not for teams smaller than 10 people.

Ship is purpose-built for Bolt and similar AI builders. If you want predictable costs without full infrastructure management, Opsily's comparison of hosting platforms shows how flat-rate pricing stacks up against per-usage models.

Frequently Asked Questions

What's the simplest way to deploy a Bolt.new app?

Click Bolt's publish button. Your app is live in 60 seconds on Bolt.new's servers. No custom domain, no configuration needed. This works for prototypes and demos.

Can I use my own domain with Bolt hosting?

Yes. Bolt supports custom domains with automatic SSL provisioning. You configure a CNAME record in your DNS provider, and Bolt handles the certificate. Details are in Bolt's official documentation.

Does exporting to GitHub give me full control over my code?

Yes. You own the GitHub repo and can modify code locally, add dependencies, change build processes, or migrate to a different platform anytime. The downside: you're responsible for keeping dependencies updated and managing deploy workflows.

Will my app have cold starts if I deploy to Vercel?

Yes, if your app has backend API routes. Vercel runs them as serverless functions, which have latency on first request. Static frontend-only apps have no cold start. Managed platforms like Ship eliminate cold starts because your app is always running.

Is it cheaper to self-host on Hetzner than a managed platform?

Raw compute on Hetzner costs less upfront. But you manage everything: OS updates, security, backups, monitoring, SSL certificates, deployment scripts. Your labor cost is significant. Most small teams find managed platforms cheaper when you factor in your time.

How do I keep my app running if I deploy to Hetzner?

You need a process manager (systemd, PM2, or Docker with restart policies) and monitoring (cron jobs or external health checks). If your app crashes, you must fix it or restart the process manually. Managed platforms restart failed services automatically.

What happens to my data if I switch deployment platforms?

Your data stays where you stored it. If you used Supabase, your data is in Supabase regardless of your hosting platform. You can export your code from GitHub and deploy elsewhere anytime. Exporting user data depends on where you stored it: Supabase has export tools built in; other databases require manual queries. Plan this from the start.

Why does Bolt.new limit tokens if I pay for a plan?

Tokens are Bolt's cost unit. Token spending represents API calls, code generation, and inference work. Free tier gets 150,000 daily and 1,000,000 monthly. Paid plans ($20-$200 per month) increase these limits. This monetizes usage separately from deployment hosting.

The Bottom Line

You have five deployment paths, from zero-ops (Bolt.new native) to full-ops (bare metal Hetzner). For most apps, GitHub export to Netlify or Vercel is the practical default: it's simple, cheap, and scales automatically. If cold starts or database scaling become problems, move to a managed platform.

The real decision is not technical--it's operational. How much work do you want to do after launch? Zero equals Bolt or Vercel. Predictable costs and less surprise maintenance equals a managed platform like Northflank or Ship. Own everything equals Hetzner.

Start with Bolt native or Netlify. You can migrate later because your code is portable. If you're building beyond a prototype and want predictable hosting costs without ops overhead, explore Ship's managed hosting for Bolt apps. Ship handles the infrastructure so you focus on your product.