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](https://www.reddit.com/r/lovable/comments/1qupsrk/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](https://www.deployhq.com/guides/claude-code) or [Cursor](https://www.deployhq.com/guides/cursor), with [Supabase](https://www.deployhq.com/guides/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](https://www.deployhq.com/hosting/static) 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](https://www.deployhq.com) Managed VPS is the upgrade path (covered in detail below). Same [DeployHQ](https://www.deployhq.com) 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](https://www.deployhq.com/blog/deploy-v0-app-to-deployhq-static-hosting)[Deploy](https://www.deployhq.com) a v0 App to [DeployHQ](https://www.deployhq.com) 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](https://www.deployhq.com/blog/deploy-bolt-app-to-deployhq-static-hosting)[Deploy](https://www.deployhq.com) a Bolt App to [DeployHQ](https://www.deployhq.com) 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](https://www.deployhq.com/blog/deploy-lovable-frontend-to-deployhq-static-hosting)[Deploy](https://www.deployhq.com) a Lovable Frontend to [DeployHQ](https://www.deployhq.com) 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](https://www.deployhq.com/blog/deploy-firebase-studio-app-to-deployhq-static-hosting)[Deploy](https://www.deployhq.com) a Firebase Studio App to [DeployHQ](https://www.deployhq.com) 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](https://www.deployhq.com) 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_URL` and `VITE_SUPABASE_ANON_KEY` in 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](https://www.deployhq.com) 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](https://www.deployhq.com/blog/deployhq-static-hosting-vs-netlify) covers where those thresholds land. `*.lovable.app` is 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](https://www.deployhq.com) Static Hosting is free during the beta, and the post-beta plan structure is straightforward enough to put on a single [DeployHQ pricing page](https://www.deployhq.com/pricing) — covered in the same way the rest of the [DeployHQ](https://www.deployhq.com) 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](https://www.deployhq.com/blog/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](https://www.deployhq.com/blog/static-hosting-on-deployhq) 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:

1. **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.
2. **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.
3. **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](https://www.deployhq.com/hosting/managed-vps) is the natural home — same [DeployHQ](https://www.deployhq.com) 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:

1. Pick the guide that matches your tool (v0, Bolt, Lovable, Firebase Studio — links above)
2. Export to GitHub if you haven't already
3. [Sign up free for DeployHQ](https://www.deployhq.com/signup) — the beta-tier Static Hosting site is included
4. 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](https://www.deployhq.com) catalog beyond static, the [hosting hub](https://www.deployhq.com/hosting) covers the four other deploy targets [DeployHQ](https://www.deployhq.com) 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](https://www.deployhq.com/blog/deployhq-your-universal-deployment-platform-for-all-hosting-types) is the longer read.

The full product reference lives in the [Static Hosting support library](https://www.deployhq.com/support/servers/static-hosting). And for a roundup of how [DeployHQ](https://www.deployhq.com) fits alongside the rest of the deployment-tool category, [best software deployment tools in 2026](https://www.deployhq.com/blog/best-software-deployment-tools) 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](mailto:support@deployhq.com) or follow [@deployhq](https://x.com/deployhq) on X — we're adding to this list as more AI builders ship credible static-export paths.