Why we picked AWS Fargate over WebContainers for an AI coding platform

The fork in the road

When you're building an AI coding platform, one of the first big choices is where the code your agent writes actually runs. There are two ways to answer this, and they sit at opposite ends of a tradeoff:

• Browser-side runtime. StackBlitz WebContainers bring a Node.js-compatible runtime into the browser tab via WASM. Boots in 2-3 seconds, no server cost, no cold start. This is what Bolt's in-browser preview runs on.
• Real container, server-side. AWS Fargate (or equivalent: Cloud Run, Render, Railway). Boots in 30-60 seconds first time, costs real money per hour, but it's an actual Linux box on the public internet.

The browser-side option is genuinely beautiful engineering. It's also the wrong default for our use case. Here's why we picked Fargate.

The architectural ceiling of WebContainers

WebContainers are a sandbox built on Web APIs. That's not a temporary limitation; it's the foundational tradeoff. Things that don't work, or work degraded:

• Native binaries. Anything that shells out to a system tool (sharp for image processing, better-sqlite3, headless Chrome, ffmpeg, native crypto modules) either fails or needs a WebAssembly build that's slower than the native one.
• Real public networking. The app doesn't have a public IP. Its preview is served inside your browser session, so webhooks from Stripe / GitHub / Twilio have nowhere to land without special routing.
• Persistence when no one is looking. Close the tab, the container dies. Bolt re-spins it next time you visit, but anything that lives in process state (in-flight jobs, cached sessions, agent state) is gone.
• Memory and CPU ceilings. Bounded by what the browser tab is allocated, which is unpredictable and tends to crash heavy builds (the npm install of a real Next.js app already pushes some browsers).

For an AI agent platform specifically, two of these matter most:

1. The agent might call native tooling. Run ffmpeg to process a user's uploaded video, run playwright for an end-to-end test, install a package that requires a native build. These are normal things real apps do. The agent should be able to do them too.
2. The deployed app needs to keep responding when nobody has a tab open. This is the entire point of "deployment." If your hosting model fails on this, you don't have hosting; you have a preview.

What "real container" buys you

Fargate is just a managed way to run a Linux container. The image, the CPU, the memory, the disk, and the network interface all belong to that one app. Everything that works in a normal Linux server works here. Specifically:

• Full npm install works. Native deps compile because the image carries a real C toolchain (python3, make, g++). SQLite + Postgres clients work. Sharp installs.
• Public HTTPS. Each VibeKit app gets a real subdomain on *.vibekit.bot, covered by a wildcard certificate, and a custom domain gets its own Let's Encrypt certificate automatically. Stripe webhooks reach it because it's a normal HTTPS endpoint, not a tab-bound preview.
• The app runs without you. When the user closes their iPhone app, nothing stops: the Fargate task keeps serving, and the agent's scheduled work runs on our side. An app that sits idle for an hour sleeps and wakes on the next request; Always-On (one app included on Builder, three on Pro, an add-on on Free) keeps it up around the clock. The app is deployed, in the production sense of the word.
• Real resource accounting. Each app gets 512 MB on Free and Builder, and 1 GB with 0.5 vCPU on Pro or with the App Boost add-on. The user gets that capacity end-to-end, not whatever the browser tab decided to give up.

The cost we pay for picking real

Three things get harder:

• Cold start is real. First boot of a new app is ~30 seconds, and so is waking one that slept. We soften this with template scaffolds and a workspace on EFS, mounted through an EFS Access Point, so the agent's work outlives container restarts, but we can't ship a 2-second boot like Bolt does.
• Compute costs real money. Each running Fargate task is ~$0.012/hour minimum. At scale this requires careful idle-suspension (we auto-stop containers after inactivity and wake them on first request).
• We're on the hook for ops. Cluster failures, EFS mount issues, NFSv4 ownership drift: we own all of it. WebContainer's "it runs in the browser tab" model means StackBlitz handles zero of those problems.

We accept these costs because the upside is "your app is real" instead of "your app is a preview that happens to look real." That's the line we want VibeKit to be on.

Where WebContainers are still the right call

If you're optimizing for "show me what this React component looks like in 10 seconds with zero setup", WebContainers are unbeatable. The model fits perfectly for browser-tab prototyping. We're not saying StackBlitz made the wrong call; they made the right call for their use case.

The boundary is at "shipping vs prototyping":

• Prototyping → WebContainer wins on boot time, zero-setup, and cost.
• Shipping → Real container wins on capability ceiling, persistence, and addressability.

VibeKit is built for the second. If you're moving from Bolt because you hit one of WebContainer's ceilings, you're in the right place.

What this means for users

The concrete payoff:

• You can install any npm package, including ones with native compile steps.
• Your app answers with no browser tab open: Stripe webhooks and real users hitting your URL reach a real server, and the agent's scheduled work runs whether or not you're watching.
• Your domain is a real domain: buy one inside VibeKit and the DNS is set up for you, or add the A record VibeKit gives you at your registrar (custom domains come with Builder and Pro).
• Your AI agent can run anything a real Linux box can run, including the things WebContainers can't emulate.

We picked the slower, costlier, harder option because "this app is real" is more valuable than "this app boots in 2 seconds." If you weighted those differently, we'd have built a different product.

If you want to see how this plays out end-to-end, deploy something and watch the container lifecycle in the app's Health panel. The 30-second cold start is real. So is everything that runs on top of it.