You describe an app in a chat window. Twenty seconds later you're staring at a working React UI that does roughly what you asked for. v0, Bolt, Lovable, and Firebase Studio have made the first hour of building a web app look almost magical — and the next hour is when reality lands. Where does this thing actually live? Whose name is on the URL? Who pays the bill?
The defaults each of these tools nudge you toward all share one trait: lock-in. v0 ships you to Vercel. Bolt has a one-click button to Netlify. Lovable hosts at <project>.lovable.app until you upgrade. Firebase Studio assumes Firebase Hosting. Each of those is a fine first step — they're free, they work in two clicks, they give you a URL to share. They also bind you to one ecosystem's pricing, runtime, and account terms the moment you want to move past the demo.
This isn't a hypothetical migration — it's a pattern users are already documenting. The r/lovable thread sorry Lovable, but I moved on
is one recent example: OP and the top commenters describe the same workflow shift — keep the AI builder for the initial scaffold, then continue editing in your own editor with Claude Code or Cursor, with Supabase still doing the backend, and free hosting on top.
That last bullet is the one this post addresses. Most migrants land at Vercel because it's the most visible free option; this is the alternative.
DeployHQ Static Hosting is the lock-in-free alternative for the static frontend these tools produce. It runs on Cloudflare's global edge, framework-detects your build (Next.js, Vite, Astro, Angular, SvelteKit, Flutter web), and atomically deploys every Git push. It's free during beta. And it doesn't touch the backend you've already wired up — Supabase, Firebase, your own API, whichever the tool of your choice put behind your UI.
The pattern: where each AI builder leaves you
| Builder | Default deploy target | What you can move | What you can't |
|---|---|---|---|
| v0 | Vercel | The Next.js project (with static export configured) | Server actions, App Router server components, route handlers |
| Bolt | Netlify | Vite + React/Vue/Svelte, Astro, SvelteKit static, Next.js export | The server/ directory in full-stack starters |
| Lovable | *.lovable.app (custom domains paid) |
The Vite + React frontend | Custom Node servers you've added beyond Supabase Edge Functions |
| Firebase Studio | Firebase Hosting | Next.js export, Angular, Vite, Astro, Flutter web | Firebase App Hosting (Cloud Run SSR), firebase.json rewrites |
The pattern: anything that compiles to a flat output directory — dist/, out/, build/ — moves cleanly to Static Hosting. Anything that needs a Node runtime at request time — server actions, SSR, route handlers, your own Express/Hono backend — doesn't, and shouldn't try to.
For the parts that don't fit static, DeployHQ Managed VPS is the upgrade path (covered in detail below). Same DeployHQ project, same build pipeline, different deploy target. You don't have to choose one or the other at the start.
The four how-to guides
Each of the tools has its own export flow, framework defaults, and a handful of gotchas worth knowing before the first push. Walk through whichever guide matches your starting point:
- v0: How to Deploy a v0 App to DeployHQ Static Hosting — covers exporting from v0 to GitHub, switching Next.js into static-export mode, and the server-action gotchas v0 sometimes generates.
- Bolt: How to Deploy a Bolt App to DeployHQ Static Hosting — works across every framework Bolt scaffolds. Includes the WebContainer path-cleanup gotcha and the framework→output-directory mapping for Vite, Astro, SvelteKit, Next, and Remix.
- Lovable: How to Deploy a Lovable Frontend to DeployHQ Static Hosting — keeps the Supabase backend intact and walks through updating Supabase Auth redirect URLs for the new domain. The
static frontend, your Supabase backend keeps doing the work
path. - Firebase Studio: How to Deploy a Firebase Studio App to DeployHQ Static Hosting — covers the framework-agnostic build configuration, the Firebase Auth authorized-domains update, and the carve-out around Firebase App Hosting.
All four follow the same shape: export to GitHub, point DeployHQ at the repo, configure the build pipeline with the right framework env-var prefixes, ship the first deploy, then update auth allowlists if the backend you're calling has one.
What stays the same when you move
The biggest reason people stall on moving an AI-built app off its default host is the worry that auth and data will break. They almost never do.
- Supabase-backed projects (Lovable's default and a common pattern in v0/Bolt) keep working because Supabase's API and Auth flows are hosted on Supabase. You set
VITE_SUPABASE_URLandVITE_SUPABASE_ANON_KEYin DeployHQ's environment-variable UI, add the new domain to Supabase's redirect-URL allowlist, and the rest is unchanged. - Firebase-backed projects (Firebase Studio's default, sometimes appears in other builders) keep working because Firebase Auth, Firestore, Storage, and Cloud Functions all run on Google's infrastructure. You add the new domain to Firebase Auth's authorized-domains list and the SDK keeps talking to the same backend it always did.
- Apps calling third-party APIs directly (Stripe checkout, public REST APIs, scraped data sources) keep working because those calls leave the browser regardless of where the bundle is served from.
The only things that genuinely move are the build pipeline (now run by DeployHQ instead of Vercel/Netlify/Firebase) and the public URL (now Cloudflare's edge instead of Vercel/Netlify/Firebase Hosting). Everything between user and database stays put.
Why this is worth the 15 minutes
The first deploy from an AI builder's default host is essentially free. The second one — when the demo becomes a real project — is where the trade-offs start mattering:
- Lock-in. Each builder's default host is owned by a different company. Moving later is harder than picking your own host up front, because URLs accumulate users, integrations, and SEO equity that don't migrate cleanly.
- Pricing trajectory. Vercel's bandwidth and serverless-execution pricing scales with traffic. Netlify's build-minute caps bite earlier than you'd expect on a chatty Vite project — the DeployHQ Static Hosting vs Netlify comparison covers where those thresholds land.
*.lovable.appis fine for demos but custom domains are a paid Lovable plan. Firebase Hosting traffic is metered against the same Firebase Spark/Blaze quotas as your database calls. - Runtime constraints you didn't agree to. Vercel's static export still goes through Vercel's edge-function billing model. Netlify's bandwidth tier resets monthly. Firebase Hosting can serve static files but pulls you into the broader Firebase plan structure.
DeployHQ Static Hosting is free during the beta, and the post-beta plan structure is straightforward enough to put on a single DeployHQ pricing page — covered in the same way the rest of the DeployHQ catalog is priced, with no per-invocation runtime metering on a static bundle.
For the head-to-head against the most common alternatives, read the DeployHQ Static Hosting vs Vercel comparison — it covers framework support, pricing, edge network, and the trade-offs that decide which one fits your stack. The Static Hosting pillar guide is the longer reference on framework auto-detection, SPA mode, atomic deploys, and the rest of the feature surface.
What Static Hosting isn't for
Three categories of project don't belong on Static Hosting, and it's worth saying so up front:
- Anything with required SSR at request time. Next.js with server actions, Astro with server-side render, SvelteKit with the Node adapter, full Next.js App Router server components — these need a Node runtime Static Hosting doesn't provide. Move them to Managed VPS or refactor to static export.
- Full-stack starter templates with bundled servers. Bolt's full-stack starters include an Express or Hono server. Lovable projects that have grown a custom WebSocket layer beyond Supabase Edge Functions. v0 projects you've turned into half-static, half-SSR hybrids. The static frontend half deploys fine; the server half needs to live somewhere with a runtime.
- Firebase App Hosting projects. Firebase Studio's newer App Hosting target provisions a Cloud Run instance for SSR — that runtime is fundamentally Google-bound and can't move to Static Hosting.
In all three cases, DeployHQ Managed VPS is the natural home — same DeployHQ project, same Git workflow, different deploy target. You can also split the difference: keep the static UI on the edge and run only the dynamic parts on Managed VPS. The build pipeline you set up adapts to either target.
How to start
If you're already an AI-app-builder user with a project ready to move:
- Pick the guide that matches your tool (v0, Bolt, Lovable, Firebase Studio — links above)
- Export to GitHub if you haven't already
- Sign up free for DeployHQ — the beta-tier Static Hosting site is included
- Walk through the guide; the whole loop is under 20 minutes
If you're earlier in the journey and still deciding which builder to use, the framework support is the right way to choose: Static Hosting framework-detects every common output, so the question is really which builder's UX you prefer and which backend (Supabase, Firebase, your own) you want behind it. The hosting decision compounds: pick a lock-in-free host now and you keep the option to swap the builder later.
For the broader DeployHQ catalog beyond static, the hosting hub covers the four other deploy targets DeployHQ supports — Managed VPS, SFTP, SSH/Rsync, S3 — all driven from the same project and build pipeline. And for context on the proposition across the full hosting catalog, your universal deployment and hosting platform is the longer read.
The full product reference lives in the Static Hosting support library. And for a roundup of how DeployHQ fits alongside the rest of the deployment-tool category, best software deployment tools in 2026 is a useful next reference.
Questions, edge cases, or a builder you'd like covered that isn't in the list above? Email support@deployhq.com or follow @deployhq on X — we're adding to this list as more AI builders ship credible static-export paths.