Vibe coding production limits, in three constants you can read

Three concrete ceilings, all visible in source. First, the runtime: E2B_TIMEOUT_MS at src/core/e2b.ts line 33 is set to 3,600,000 milliseconds, so the sandbox your app runs in auto-pauses every hour. Second, custom-domain publishing: src/core/e2b.ts line 1870 throws 'Domain publishing is not yet supported on the E2B backend.' The product still has a deploy button, but src/app/api/publish/route.ts line 11 sets NOTIFY_TO = 'i@m13v.com' and the deploy action sends an email rather than mapping DNS automatically. Third, model access: FREE_MODEL = 'haiku' at src/app/api/chat/model/route.ts line 5, and the route returns subscription_required if a non-anonymous user without billing tries to switch to a stronger model. None of these stop you shipping a real prototype. All three are what you graduate past when the prototype turns into a production app.

It is a pause, not a kill. The createSandbox call passes lifecycle: { onTimeout: 'pause', autoResume: true }, so when E2B_TIMEOUT_MS elapses the sandbox suspends rather than terminating. The next request to the same session calls Sandbox.connect, the runtime resumes, and the timeout window resets via setTimeout(E2B_TIMEOUT_MS) at src/core/e2b.ts line 337. The pool side is shorter: POOL_MAX_AGE_MS at line 1896 is 45 minutes, which is when the warm-pool entry is considered stale and recycled. Practically, short sessions never see the timeout, long marathons get a brief reconnect pause, and if a session goes truly cold the project is restored from the head SHA in Firestore on the next prompt. Production apps that need to be reachable continuously by other users do not sit well inside this lifecycle, which is the limit being honest about.

Because the publish-to-real-domain step is human-in-loop on purpose. src/core/e2b.ts line 1870 in startDomainVerification throws 'Domain publishing is not yet supported on the E2B backend.' The deploy handler in src/app/api/publish/route.ts catches the user's intent earlier: it accepts the domain string, builds an email payload that includes the domain, project name, session key, VM ID, user email, and the live preview URL on the mk0r preview subdomain, and ships that to NOTIFY_TO = 'i@m13v.com'. A real person reads the email and finishes the domain mapping. The honest framing: the iteration loop is fully automated, the production publish is gated by a human review. If you want one-click DNS for any domain, you have outgrown the product at this seam.

FREE_MODEL = 'haiku' at src/app/api/chat/model/route.ts line 5 means an unsigned visitor or a signed-in user without an active subscription can keep using the default model for free, but the route returns 403 with error: 'subscription_required' if a non-anonymous user without billing tries to set a different modelId. For prototyping that is rarely a binding constraint, Haiku 4.5 is fast and good at HTML/CSS/JS apps. It becomes a production limit when you start asking the agent to plan multi-file refactors that benefit from a stronger model, at which point you authenticate, subscribe, and switch. The model itself does not change what the running app can do, it changes how thoroughly the agent reasons about edits. That is the one of the three production limits you can clear without leaving the product.

The product description is explicit: full HTML, CSS, and JS mobile apps from a single sentence prompt. The qualification list is also explicit: the right user has a specific app or prototype idea to ship within a week or two, is fine with mobile-first HTML/CSS/JS as the starting point, and either does not write code or wants a disposable first draft before investing engineering time. Within those bounds the tool carries you through the entire iteration loop without infrastructure friction. Outside them, native iOS or Android, real-time multi-user state, complex backend orchestration, the same three limits stop being abstract and start being daily blockers. The win is to know which side of that line your idea sits on before the first prompt.

Each limit has a different right move. For the sandbox lifecycle, deploy the generated HTML/CSS/JS or the Vite/React project to a real always-on host, the prototype repository is genuinely portable. For the publish flow, send the deploy email with the domain you want and expect a human to respond, that is what the route is designed to do. For the model gate, sign in with Google and start a paid plan if you want the stronger model in the agent. None of those steps require throwing away the work already done, which is why source-level honesty about limits is more useful than a blanket 'AI builders cannot do production'.