Dora NodaVibe coding is a $4.7 billion market in 2026, growing at 38 percent a year, with 92 percent of US developers using AI coding tools daily — and 63 percent of the people prompting apps into existence aren't professional developers at all. That is the headline. Here is the footnote: in October 2025, Escape.tech scanned 5,600 publicly available vibe-coded applications and found more than 2,000 high-impact vulnerabilities, over 400 exposed secrets, and 175 instances of personal data exposure including medical records and bank numbers. Every one of them was in a live production system.
So the guides all agree on the pipeline by now: audit what the AI built, harden the boring infrastructure layer, observe what runs in the wild, and deploy behind a sandbox. All correct. All incomplete. Because every guide stops at "deploy behind a sandbox" without answering the question that arrives on day two: where does this app actually live long-term, who owns the running service, and how does it get redeployed when the agent iterates again?
Here is the answer up front, and the rest of this post is the receipt: the agent's output needs a permanent, git-backed home with a redeploy loop — a repo as source of truth, a git-push build that turns commits into a running HTTPS service with its domain, secrets, data, logs, and rollback, and an API the agent itself can call so iteration N+1 deploys the same way iteration 1 did. A sandbox is where untrusted code runs. A home is where your service lives. They are different jobs, different bills, and different lifespans — and confusing them is the step everyone skips.
The four stages everyone agrees on (and what each one costs)
The 2026 consensus on shipping AI-generated apps to production converges on four stages. They are all load-bearing, so here is the compact version with the numbers attached:
1. Audit what the AI built. Veracode's 2025 GenAI Code Security Report found security weaknesses in 45 percent of AI-generated code samples. Tenzai's December 2025 assessment had five leading tools build the same three test apps and found 69 vulnerabilities across the 15 outputs. A March 2026 "Vibe Security Radar" from Georgia Tech researchers counted at least 35 new CVEs disclosed in a single month that were the direct result of AI-generated code. Apiiro's finding compresses the whole story: AI-assisted developers ship three to four times faster while producing security findings at roughly ten times the rate. Speed is real; review is not optional.
2. Harden the boring infrastructure layer. Auth, rate limits, secrets, error handling — the parts no demo includes. GitGuardian's 2026 report counted 28.6 million new secrets exposed on public GitHub in 2025, up 34 percent year over year, with leaked AI-service credentials up 81 percent — and commits co-authored by coding agents leaking secrets at roughly twice the human baseline. The Lovable RLS incident behind CVE-2025-48757, which left an estimated 170 apps' database rows reachable, is the canonical example: the app worked perfectly and the front door was open.
3. Observe what runs in the wild. Logs, metrics, and audit trails from the first deploy, not the tenth. The Hacker News "Secure Vibe Coding" guide's unglamorous core recommendation is documentation: record AI involvement in code generation and maintain audit trails, because you cannot incident-review a system whose authorship is unknown.
4. Deploy behind a sandbox. Run untrusted, agent-produced code in an isolated execution environment — E2B, Daytona, Vercel Sandbox, Modal — with bounded network, filesystem, and lifetime. Correct advice. And then the guides end, as if the story is over once the app is running inside a box with walls.
But a sandbox answers "where does untrusted code execute safely," not "where does my service live." Those differ in four concrete ways, and each one bites on a different day-two morning.
Why a sandbox is not a home
Sandbox runtimes are engineered for ephemerality. That is the product, not a flaw — and it is exactly why they fail as permanent hosting:
- Sessions expire by design. E2B sandboxes cap out around 24 hours of session life (with auto-pause rather than persistence). Vercel Sandbox sessions run up to 45 minutes on Hobby and 24 hours on Pro/Enterprise. Daytona enforces auto-stop intervals; Mastra's multi-provider deployer has to map an
idleTimeoutMinuteshint onto each backend's native lifetime knob because every backend assumes the sandbox goes away. Nothing here promises your app is running next Tuesday. - The filesystem is scratch space. Ephemeral
/tmp-style storage, repos re-cloned on cold start, in-memory session handles lost when the runtime recycles. A sandbox that restarts is a sandbox with amnesia — fine for executing a task, fatal for a service with users. - The meter never stops being per-second. Vercel Sandbox bills roughly $0.128 per active-CPU-hour plus $0.0212 per GB-hour of memory, $0.60 per million sandbox creations, and $0.15 per GB of transfer — metered for execution bursts, not for sitting patiently at 2 a.m. serving three requests an hour. Always-on is the most expensive shape to run on an execution meter.
- There is no service surface. No stable custom domain with TLS you own, no persistent attached data, no log retention you control, no rollback to last-known-good when iteration N+1 breaks. Sandboxes expose preview URLs and session handles. Services need addresses, state, history, and undo.
Put bluntly: the sandbox is the agent's workshop. The day the agent finishes, the workshop gets demolished on schedule. Your users need an address that outlives the builder.
The missing fifth stage: give the app a permanent, redeployable home
Here is the day-two lifecycle, worked end to end for a typical case — say, an internal dashboard an agent built over a weekend that the team now depends on every morning. Each step names who owns what, because "who owns the running service" is the question the guides never assign:
Step 1 — The agent commits to a git repo, and the repo becomes the source of truth. Not a chat transcript, not a sandbox snapshot: a real repository with history. Lovable and Bolt both offer GitHub sync; v0 integrates with GitHub and Vercel; even Replit lets you export. The friction varies — Replit is the stickiest, since its runtime, database, and deployment assumptions travel poorly — but the principle doesn't: if the app's future can't be expressed as git log, it has no future. The owner here is the team, and the artifact is reviewable by humans and agents alike.
Step 2 — A push triggers a reproducible build. Buildpacks (or the platform's equivalent) turn the repo into a runnable image deterministically — same commit, same image, no "works because the sandbox had the right global binary" surprises. This closes the environment gap that hosted builders paper over: your production container is built from the repo, not inherited from whatever the agent's workshop happened to contain.
Step 3 — The build becomes an HTTPS service with a domain and TLS you own. Not a preview URL with a session token in it. A stable address, certificate renewal handled, custom domain attached. This is the moment the app stops being a demo link and starts being infrastructure.
Step 4 — Secrets, config, and persistent data attach outside the container. API keys via a secrets manager or the platform's env store (rotatable without rebuilding), the database as a real Postgres you can back up — your own managed instance or a self-hosted one on the same fleet — never SQLite-in-the-container or credentials baked into the image. Recall the GitGuardian numbers: agent-authored commits leak at 2x the human rate, so the layer that holds secrets must be separate from the layer the agent writes to.
Step 5 — Logs, metrics, and rollback come with the address. Structured logs with retention, basic health and latency signals, and one-command rollback to the previous deployment. When the agent's next iteration breaks the dashboard at 9 a.m., recovery is "revert to the last good deploy," not "ask the agent to fix it live while everyone waits."
Step 6 — The agent iterates by pushing again, through an API it can call. This is the step that closes the loop instead of reopening the workshop every time. The redeploy path must be machine-operable: a git push, a deploy hook, or a Render-compatible API call the agent makes itself — same pipeline, same guardrails, no human copy-pasting code between windows. The agent goes from builder to operator without changing venues.
Owning the running service: the checklist
If you want the one-table version to tape above your monitor, here is what "the app has a home now" concretely means — and what each layer gives you versus a sandbox:
| The service needs | A sandbox gives you | A home gives you |
|---|---|---|
| Stable address | Preview URL tied to a session | Custom domain + managed TLS you own |
| Secrets | Env vars baked into the session | Rotatable secret store, separate from code |
| Data | Ephemeral disk, amnesia on restart | Backed-up Postgres with a restore story |
| History | Session handle that expires | Git log + deployment history |
| Observability | Streamed stdout while attached | Retained logs, metrics, alerts |
| Undo | Re-run the agent and hope | One-command rollback to last good deploy |
| Iteration | New session, new copy-paste | Push or API call through the same pipeline |
If your setup can't check every row in the right-hand column, you don't have a production deployment. You have a long-running demo with users.
The cost crossover: execution meters vs. flat floors
There is also money in this distinction, and it cuts both ways — honestly this time, because each side wins somewhere.
Sandbox pricing is built for bursts: pay per active-CPU-second, per session, per creation, and pay nothing while idle. For the shape a deploy-from-chat workflow actually produces — short agent sessions that compile, test, and preview, then end — that meter is genuinely cheaper than reserving hardware. An agent that runs twenty 10-minute sessions a day consumes a few CPU-hours; billing only busy time is the right trade.
But flip the shape to always-on and the meter turns hostile. A service that sits at 2 a.m. serving three requests an hour still occupies memory every one of those hours ($0.0212 per GB-hour adds up across a month of mostly-idle), still pays per sandbox creation every time a session rolls over at its TTL, and still pays transfer per GB on top. Meanwhile the same workload on owned flat-rate hardware — a small Hetzner-class box with terabytes of included traffic — costs one predictable number whether the night is busy or silent. The breakeven isn't subtle: bursty execution belongs on the execution meter, and a 24/7 service belongs on the flat floor. Running your permanent home on sandbox pricing is paying hotel rates for an apartment you live in.
That is also why the "deploy behind a sandbox" guidance curdles when it becomes the whole strategy: teams keep the app in the execution environment past the execution phase, and the bill quietly becomes the architecture. The sandbox was pricing you for hours. You needed pricing for months.
The venue has to be machine-operable
There is one more reason the home matters more than the workshop, and it points forward. The April 2026 OpenAI Agents SDK update made sandbox execution a first-class, provider-pluggable primitive — E2B, Daytona, Modal, Vercel, Cloudflare behind one interface — and frameworks like Mastra now treat ephemeral sandboxes as instant preview deployments with live URLs. The agent ecosystem is standardizing on the idea that agents act through APIs: they create sandboxes, run code, ship previews, all as calls.
The permanent home deserves the same treatment. If the redeploy path is a dashboard only a human can click, the agent that built the app can't operate it — every iteration is a manual relay race between chat window and console. If the home exposes a machine-readable deploy API with observable state (deploy status, logs, health, rollback as calls, not screenshots), the agent closes its own loop: build, ship, watch, revert. That is what "AI agents as first-class operators" actually requires — not a smarter sandbox, but a home the agent can run without asking a human to drive.
So the pipeline everyone describes gets its missing fifth stage: after audit, harden, observe, and sandbox — house it. Put the repo in git, put the service on a platform that builds from git, give it an address, secrets, data, logs, and rollback, and hand the agent the API keys to its own front door. The workshop did its job the day the code worked. The home does its job every day after.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
