From Bolt.new and Lovable to Live Domain: The Missing Deployment Manual

From Bolt.new and Lovable to Live Domain

You prompted a beautiful app into existence inside Bolt.new or Lovable. The UI is gorgeous, the interactions feel polished, and the prototype does exactly what you imagined. Then you click the deploy button, and you get a sandbox URL on a subdomain nobody will ever remember. You want your app on your own domain, with SSL, with a real database, with the ability to accept payments. The sandbox does not give you any of that. This is the missing deployment manual for vibe coders: how to take a browser-generated app from sandbox to live domain in minutes, without writing a Dockerfile, without configuring Nginx, and without learning DevOps.

The direct answer is that Bolt.new and Lovable are incredible at the first half of the pipeline (idea to working prototype) and intentionally limited at the second half (prototype to production). Their deploy buttons give you a preview URL, sometimes on a platform like Netlify, but the moment you need a custom domain, a persistent backend, WebSockets, a Postgres database, or background workers, you hit a wall. The sandbox was never designed for production. It was designed to show you the app working. The gap between that and a real production deployment is what Deployxa fills.

Why Browser-Based AI Builders Stop at the Sandbox

Three structural reasons explain why Bolt.new and Lovable do not take you all the way to production. First, they run your app in a sandboxed WebContainer or similar browser-based runtime, which is fundamentally different from a cloud container. Code that runs in the sandbox does not necessarily run in a real Linux environment, because the sandbox emulates certain APIs and patches others. Second, they do not provision persistent infrastructure. A production app needs a database that survives restarts, a file system for uploads, and a process that stays alive to handle WebSockets. Sandboxes are ephemeral by design. Third, they do not handle the operational side of production: SSL certificates, custom domains, health checks, log aggregation, and rollback. These are platform concerns, not code concerns, and browser-based builders do not own that layer.

The result is a jarring experience for vibe coders. You feel like you built a complete app, but the moment you try to put it on the internet for real users, you discover that the last 20 percent of the work (deployment, operations, scaling) was never part of the tool. You are handed a zip file or a GitHub repository and told to figure out the rest. For a non-traditional developer who does not know what a Dockerfile is, this is where the vibe dies.

A fourth reason is worth naming: the unit economics of browser-based builders do not favor production hosting. Bolt.new and Lovable make money on subscription tiers that unlock more prompts, more context, and more sandbox time. They do not make money on long-running containers, because long-running containers cost real money to operate, and the sandbox model cannot subsidize that cost. The structural incentive is to push users out of the sandbox once the prototype is done, and to push them toward a deployment partner (Netlify for Lovable, Vercel for Bolt.new historically) that handles the long-running layer. This is not a betrayal; it is a sensible division of labor. But the seam between the sandbox and the deployment partner is exactly where vibe coders get stuck, because the deployment partner assumes DevOps knowledge that the vibe coder does not have.

A second subtlety: the sandbox's runtime is often a WASM-compiled Node.js or a WebContainer that emulates a Linux filesystem in the browser. Native modules (Sharp for image processing, Bcrypt for password hashing, the Prisma query engine) frequently do not work in the sandbox. The sandbox patches or polyfills these, so the prototype works, but the patches do not transfer to a real Linux container. The vibe coder ships to production and discovers that Sharp fails to load, Bcrypt throws module not found, or Prisma's query engine binary is missing. These are sandbox-runtime divergences, and they are a class of bug that Deployxa's polyglot engine and AutoRepairService are specifically designed to absorb.

The Traditional Fix: A Multi-Tool Pipeline

Without a platform designed for this transition, the manual pipeline looks like the following. You export your project from Bolt.new or Lovable as a zip or GitHub repository. You clone it locally. You install Node.js if you do not have it. You run npm install and npm run dev to verify it works locally. You realize you need a database, so you sign up for Supabase or Neon, get a connection string, and add it to a .env file. You write a Dockerfile, because your cloud provider needs one. You configure the build command, start command, and port binding. You push to GitHub. You connect your cloud provider. You configure environment variables in the provider's dashboard. You deploy. The build fails because of a missing dependency. You fix it. You redeploy. The build succeeds but the container crashes because of a missing environment variable. You fix it. You redeploy. You configure a custom domain. You wait for SSL to provision. You test. You finally have a live app, two to four hours later.

This pipeline is not hard for an experienced engineer, but it is genuinely hostile to a vibe coder who just wants their app on the internet. Every step requires knowledge the vibe coder does not have and does not want to acquire. The cognitive overhead kills the momentum that Bolt.new and Lovable built up.

The Concrete Pipeline

Concretely, the traditional pipeline is a 14-step process:

# 1. Export from Bolt.new (Download ZIP) or Lovable (Download Project)
# 2. Unzip locally
unzip bolt-project.zip
cd bolt-project

# 3. Initialize git and push to GitHub
git init && git add . && git commit -m "init"
git remote add origin [email protected]:you/app.git
git push -u origin main

# 4. Provision a Postgres database on Neon
# (via the Neon dashboard, copy the connection string)

# 5. Write a Dockerfile (if your cloud provider requires one)
cat > Dockerfile <<'EOF'
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["npm", "start"]
EOF

# 6. Push the Dockerfile
git add Dockerfile && git commit -m "add Dockerfile" && git push

# 7. Connect the cloud provider to GitHub
# 8. Configure environment variables in the provider dashboard
# 9. Trigger the first deploy
# 10. Watch it fail on a missing dependency
# 11. Run npm install  locally, push package.json, redeploy
# 12. Watch the build succeed but the container crash on missing DATABASE_URL
# 13. Add DATABASE_URL in the provider dashboard, redeploy
# 14. Configure custom domain, wait for SSL, test

Steps 10 through 13 are where most vibe coders give up. The Deployxa workflow collapses these 14 steps into 4: push, connect, deploy, add domain.

How Deployxa Bridges the Sandbox-to-Production Gap

Deployxa is designed to be the second half of the pipeline that Bolt.new and Lovable do not cover. You export your project, push it to GitHub, connect Deployxa, and the platform handles the rest. Framework auto-detection identifies your stack (Next.js, Vite, React, FastAPI, etc.) and configures the build and start commands automatically. The AutoRepairService catches missing dependencies. The localhost rewriter fixes hardcoded URLs. The build resilience injector bypasses ESLint and TypeScript strictness. The pre-flight scanner checks for required environment variables. You add your database URL, hit deploy, and your app is live on a Deployxa subdomain within 60 to 90 seconds. You can then add a custom domain, and SSL is provisioned automatically.

The key insight is that Deployxa treats the gap between sandbox and production as a platform problem, not a user problem. The vibe coder should not have to learn Dockerfiles, port binding, or SSL certificate provisioning. The platform should handle those automatically, and only surface decisions to the user that genuinely require their input (like which database to use and what domain to point at).

The Polyglot Engine: 30+ Frameworks, 10 Runtimes

Deployxa's zero-config polyglot engine auto-detects the framework and runtime from your repository's file structure. The detection is layered: first, the engine looks for a package.json with a framework field or a known Next.js/Vite/CRA dependency; if found, it configures the Node.js runtime with the appropriate build and start commands. If no package.json is found, it checks for requirements.txt or pyproject.toml (Python with FastAPI, Flask, Django, or Streamlit), go.mod (Go), Cargo.toml (Rust with Axum or Actix), Gemfile (Ruby on Rails or Sinatra), composer.json (PHP with Laravel or Symfony), or pom.xml/build.gradle (Java with Spring Boot). In total, the engine supports 30+ frameworks across 10 runtimes.

The full list of supported runtimes as of this writing: Node.js 18/20/22, Python 3.11/3.12, Go 1.22, Rust 1.78, Ruby 3.3, PHP 8.3, Java 21, Deno 1.43, Bun 1.1, and .NET 8. The full list of supported frameworks: Next.js, Vite, Create React App, Nuxt, SvelteKit, Astro, Remix, Gatsby, FastAPI, Flask, Django, Streamlit, Gradio, Rails, Sinatra, Laravel, Symfony, Spring Boot, Axum, Actix, Rocket, Phoenix, Gin, Echo, Fiber, Hono, Deno Fresh, Bun's Bun.serve, and ASP.NET Core. For each framework, the engine knows the canonical build command, output directory, start command, and port binding convention.

This matters for Bolt.new and Lovable exports specifically because both platforms default to Vite with React, but they sometimes emit Next.js projects, plain Create React App projects, or Remix projects depending on the prompt. The polyglot engine handles all of these without requiring the vibe coder to know which framework their export uses.

Step-by-Step: From Bolt.new Sandbox to Live Domain

Here is the exact workflow for a typical Bolt.new or Lovable app.

Step 1: Export your project from Bolt.new or Lovable

Both platforms let you export your project as a GitHub repository or a zip file. Choose GitHub, because it makes the Deployxa connection seamless. If you export as a zip, unzip it locally, initialize a git repository, and push to GitHub.

git init
git add .
git commit -m "import from bolt.new"
git remote add origin https://github.com/yourname/your-app.git
git push -u origin main

Step 2: Connect to Deployxa

Open the Deployxa dashboard, click New App, and select your GitHub repository. Deployxa auto-detects the framework from your package.json. For a typical Bolt.new project, this is Vite with React. The build command (npm run build), output directory (dist), and start command are configured automatically.

Step 3: Add environment variables

If your app uses environment variables (database URLs, API keys), add them in the Deployxa dashboard under Environment Variables. The pre-flight scanner will warn you about any that are clearly required but missing.

Step 4: Deploy

Click Deploy. The ingestion service runs, handling localhost rewrites and build resilience injection. The build runs, with the AutoRepairService standing by to patch any missing dependencies. The container starts, and your app is live at your-app.deployxa.app within 60 to 90 seconds.

Step 5: Add a custom domain

In the Deployxa dashboard, navigate to Domains, click Add Domain, and enter your domain. Deployxa gives you a CNAME record to add to your DNS provider. Once the DNS propagates, SSL is provisioned automatically via Let's Encrypt, and your app is live at your custom domain with HTTPS.

Step 6: Verify with deployxa doctor

Run deployxa doctor to get a full health check. The 14-point readiness engine verifies SSL, DNS, environment variables, health endpoints, and container status.

npm i -g @deployxa/cli
deployxa login
deployxa doctor --app your-app-name

Common Pitfalls

Three pitfalls appear in Bolt.new and Lovable exports. First, WebContainer-specific patches. Bolt.new sometimes injects a polyfill for process.env or Buffer that works in the WebContainer but breaks in a real Node.js runtime. If your build fails with ReferenceError: process is not defined or Buffer is not defined, look for a vite.config.ts patch that defines these globals and remove it; Deployxa's runtime provides them natively. Second, missing tsconfig.json. Bolt.new's export sometimes omits tsconfig.json, which Vite requires for TypeScript projects. The AutoRepairService detects this and generates a default tsconfig.json from the Vite template, but if you have specific path aliases, you need to add them manually. Third, base path issues. Lovable exports sometimes set base: '/preview/' in the Vite config for the sandbox URL, which breaks production asset URLs. Remove or change to base: '/' before deploying.

Troubleshooting: Common Bolt.new and Lovable Export Issues

Below are common errors after deploying an export and their interpretations.

Error: Cannot find module '/app/dist/index.html'

The build output directory is wrong. Bolt.new defaults to dist, but some templates use build. Check your vite.config.ts and adjust the outDir or override it in Deployxa's Build Settings.

ReferenceError: process is not defined

A WebContainer polyfill is leaking into production. Search for define: { 'process.env': {} } in your Vite config and remove it.

TypeError: Bun.serve is not a function

Your export uses Bun-specific APIs but Deployxa is running it under Node.js. Either rewrite the server to use Node's http module, or change the runtime in Deployxa's Build Settings to Bun.

Failed to load module script: Expected a JavaScript module script

The base path in Vite config is wrong. Set base: '/' and redeploy.

Handling the Database Question

Most Bolt.new and Lovable apps eventually need a database. The sandbox might use localStorage or an in-memory store, but production needs persistence. The cleanest approach is to provision a managed Postgres database from a provider like Supabase, Neon, or Railway, get the connection string, and add it as DATABASE_URL in your Deployxa environment variables. If your app uses Prisma or Drizzle, the schema and migrations travel with your code, and Deployxa runs them as part of the deployment process.

For apps that need file storage (user uploads, generated images), the pattern is similar: provision an S3-compatible bucket, add the credentials as environment variables, and your app can upload and serve files. Deployxa's persistent containers mean you can also use local file storage for simpler use cases, though managed object storage is recommended for production.

A common pattern for Bolt.new exports that originally used localStorage: replace the localStorage calls with a thin API layer that talks to a Postgres-backed endpoint. The LLM that generated the original code can usually do this refactor in a single prompt, and the resulting code uses fetch('/api/data') which Deployxa's localhost rewriter will leave alone (because it is already a relative path). This is the cleanest path from a localStorage-backed sandbox prototype to a Postgres-backed production app.

The Pricing Reality: Sandbox vs Production

Bolt.new and Lovable have free tiers that are generous for prototyping, but production has real costs. Deployxa's free tier includes 3 active apps with 512MB RAM, which is enough to run a small app with light traffic. The paid tier starts at $9 per month for 15 apps, with predictable pricing based on provisioned resources rather than bandwidth or function invocations. This is the right shape for vibe coders, because the bill does not spike when an app goes viral. Compare this to serverless platforms that charge per request and can produce $400 bills from a traffic spike, and the value of predictable pricing becomes clear.

Cost Comparison: Full Stack on Each Platform

The table below estimates monthly cost for a typical Bolt.new export running on each platform, assuming one Next.js app with a Postgres backend, light traffic (10k requests/day), and a custom domain.

|---|---|---|---|---|---|

| Custom domain | $0 (Vercel includes) | $0 | $0 (Render includes) | $0 | $0 |

| Total | $0 | $20-40/mo | $0 (then $7/mo) | $0-15 | $9-24 |

The Vercel Hobby stack is the cheapest, but it caps at 3 apps and exhausts build minutes quickly when iterating. The Deployxa Paid stack is $9 flat for 15 apps with no build-minute metering, which is the better deal for vibe coders iterating on multiple projects.

When Deployxa Is Not the Right Choice

Deployxa is single-region, which means all your users hit the same geographic region regardless of where they are. If your Bolt.new export is a globally-read content site with millions of users in five continents, you want a multi-region CDN with edge rendering (Vercel with Edge Functions, Cloudflare Pages with Workers). Deployxa's Cloudflare front-end caches static assets globally, but the dynamic backend is single-region. For most vibe coder projects, this is fine; for a viral consumer app, it is not.

Deployxa also does not provide a managed Postgres. You bring your own database via a connection string. If you want the platform to own the database (provision, backup, scale, replicate), use Render, Railway, or Supabase directly. Deployxa's bet is that managed Postgres from a specialist provider (Neon, Supabase) is better than a half-managed Postgres from a generalist deploy platform, and the vibe coder should pick the database separately from the deploy platform. This is opinionated and not universally shared.

If your Bolt.new export is a static site with no backend (a pure landing page, a resume, a one-pager), Deployxa is overkill. Use Cloudflare Pages, Netlify, or GitHub Pages, all of which are free for static sites and have global CDN distribution built in. Deployxa's value is in the persistent container layer, which a static site does not need.

Conclusion: Complete the Pipeline

Bolt.new and Lovable are incredible tools for the first half of the pipeline. Deployxa is the platform for the second half. Together, they form a complete workflow from idea to production, without the vibe coder ever having to learn DevOps. Stop staring at a sandbox URL and start shipping to a real domain.

Ready to take your Bolt.new or Lovable app live? Drag your project folder to Deployxa Drop for an instant live preview with zero signup, or install the CLI with npm i -g @deployxa/cli and deploy from your terminal. For a deeper comparison of deployment platforms, see Deployxa vs Vercel and explore our free developer tools to speed up your workflow.