Your AI App Builder Ships Where It Wants: The Open Deploy-Target Gap Behind v0, Bolt, Lovable, and Replit

At Vercel's Ship 2026 event in June, the company disclosed a number worth sitting with: six months earlier, fewer than 3% of deployments to its infrastructure were triggered by a coding agent instead of a human running git push. By June, that share had crossed 50%. Vercel called it the fastest infrastructure shift it has ever recorded.

Most of those agent-triggered deployments share something else in common, and it's rarely a decision anyone made on purpose: the app landed on the vendor's own cloud because that's where the tool that wrote it happened to point. v0 writes an app and offers one button — deploy to Vercel. Bolt.new writes an app and ships it to a .bolt.host subdomain by default. The generation step and the hosting step have quietly become the same step, and "where does this actually run" stopped being a question most builders ever ask.

What "Export the Code" Actually Gets You​

The pitch across every major AI app builder is some version of "you're never locked in — you can always export and deploy elsewhere." It's worth checking that claim against what each tool actually hands you, because "export" turns out to mean four different things.

Two of these — Bolt and Replit — hand you source that runs about as portably as any hand-written repo. The other two are where "export" gets more interesting. v0's own SDK repo has an open issue asking for programmatic export because the current path (GitHub sync, or a UI-triggered ZIP that community reports say sometimes contains little more than a README) doesn't match what "export" implies. And Lovable's case is the sharper one: independent write-ups on self-hosted alternatives note that its generated backend is wired directly to Lovable Cloud's own services, so the code you export still expects Lovable's infrastructure underneath it rather than running standalone.

None of this is written down anywhere as "you're locked in." It's the accumulated effect of every default pointing one direction, in a market that's exploding specifically because the defaults work.

Why "You Can Export the Code" Isn't "You Can Deploy It"​

Say you do export a v0 or Bolt-generated app and want it running on a server you own instead of the vendor's cloud. Here's what that export actually leaves you to do yourself, by hand, every time:

1. Provision compute. Pick a box, install a runtime, open a port — none of this is in the exported repo.
2. Reconstruct the build. The builder's own platform infers your framework, sets environment variables, and wires a database connection through its dashboard. None of that configuration ships in the ZIP; you're reverse-engineering requirements from the source.
3. Get TLS and a domain working. Every builder's one-click deploy includes automatic HTTPS. Self-hosting means Let's Encrypt, a reverse proxy, and certificate renewal are now your job.
4. Wire the redeploy loop. The entire value of the agent-generated workflow is that the next prompt produces the next commit produces the next live deploy. Self-hosting a static export breaks that loop unless something is watching the repo and rebuilding on push — which is exactly the piece no export ships with.

Item 2 is where the real, well-documented gotcha lives, and it's worth walking through because it's not hypothetical — it's the top thread in Bolt and v0's own community forums. During generation, the builder's preview environment injects your API keys and database URLs directly; the app runs, so nothing looks wrong. But those values are configured through the platform's dashboard, not written into the repo, so an export hands you source code that references environment variables that don't exist anywhere in the exported project. You have to go re-declare every one of them by hand, one by one, cross-referencing the code for process.env.X reads with whatever was in the builder's UI panel.

That gets worse the moment the framework changes underneath you. Bolt.new projects are frequently Vite-based; Vite requires client-exposed variables to be prefixed VITE_, while v0's Next.js output expects NEXT_PUBLIC_ for the same purpose — so a variable that worked fine as API_KEY inside the builder's own runtime silently returns undefined in the browser once you've exported and rebuilt it elsewhere, with no error, just a blank value where a key should be. Layer onto that the other two recurring failure modes practitioners report post-export: TypeScript errors the builder's live dev server never enforced but a real next build/vite build step fails on immediately, and case-sensitive import paths (./Button vs ./button) that run fine on the builder's case-insensitive dev filesystem and then break the first time they hit a case-sensitive Linux build server. None of these are edge cases — they're the standard first-hour experience of taking an exported app anywhere else, and they're also exactly the class of problem a builder's own one-click deploy never surfaces, because it never leaves the environment where the workarounds were baked in from generation.

That fourth item on the list — the redeploy loop — is the one that matters most in the long run, because it's not a hosting inconvenience, it's the actual product these tools sell. An app builder's value proposition is prompt-to-running-app in one motion: the agent edits, commits, and the live preview updates without anyone touching a terminal. The moment you export to "deploy elsewhere," you've kept the app and lost the motion, unless whatever you deploy to can restore it — turning "push a commit" back into "a running service," automatically, on every push, the same way the builder's own infrastructure did.

The Piece That Closes the Gap: A Webhook Any Agent Can Point At​

The fix isn't asking Lovable to stop bundling Supabase or v0 to ship a better ZIP exporter — those are reasonable product choices for a hosted platform to make. The fix is a deploy target on the other end that restores the one-motion workflow instead of degrading it back into manual ops.

Concretely, that means two things a self-hosted platform needs to expose:

• A git-push webhook, so pointing an exported repo's remote at a new host and pushing is the entire migration — no manual build reconstruction, because the platform's buildpacks do framework detection the same way the app builder's own infra did.
• An MCP tool an app-builder's own agent can call directly — deploy(repo, branch) — so "ship this somewhere I own" is a tool call the agent makes mid-session, not a manual export-then-configure step a human does after the agent is finished.

This is the concrete integration surface a Render-compatible, git-push PaaS like Bex.co is built around: point a webhook at a repo, get a running HTTPS service on hardware you own, and expose the same deploy/rollback/logs surface to an agent through MCP that a human gets through the CLI. Framework auto-detection at the buildpack layer is what handles item 2 from the section above without a human re-declaring every environment variable by hand — the platform's build step infers the same VITE_/NEXT_PUBLIC_ conventions the app builder's own preview environment did, instead of a person reverse-engineering them from a stack trace. It doesn't require v0, Bolt, or Lovable to change anything about how they generate code — it just gives the exported repo somewhere to land that doesn't ask a human to manually rebuild what the vendor's dashboard used to do automatically.

Widen the lens past any single vendor and the pattern holds across the wider agent-infrastructure stack this shift is creating. The Agent2Agent protocol crossed 150+ organizations in production a year after launch specifically because independent agents needed a standard way to hand work to each other, not just to call a tool. An app-builder's coding agent handing a finished repo to a deploy agent is the same shape of problem at smaller scale: two agents, one handoff, and a machine-readable contract in between instead of a human relaying a ZIP file. A webhook plus an MCP tool is that contract's minimal viable form today; a signed Agent Card advertising "I accept a git remote and return a live URL" is a plausible next one. Either way, the requirement is the same — the deploy target has to be something an agent can address directly, not a dashboard a human has to click through after the agent's done.

Where This Goes From Here​

The 3%-to-50% jump in agent-triggered deployments isn't a plateau — it's a trend line, and every point further along it means more apps whose hosting decision was never actively made by anyone. That's fine as long as the default destination is a reasonable one. It stops being fine the moment a team wants to move off it and discovers "export the code" was never quite the same promise as "deploy the app."

The honest fix isn't a lock-in accusation against any one vendor — Bolt and Replit already hand back code that runs anywhere, and even Lovable's Supabase-wrapped export is a defensible product decision for a hosted platform to make. The fix is making sure the other side of that export exists: a deploy target that takes a git remote and an MCP tool call and turns them into a running service, so that "ship this somewhere I own" is a one-command decision for a human and a one-tool-call decision for an agent, instead of a rebuild project either one has to schedule for later.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with an MCP surface an agent can call directly. Star the repo on GitHub or deploy your first app today.