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 and Lovable's preview use.
• 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 (image processing), better-sqlite3, headless Chrome, ffmpeg, native crypto modules — either fails or runs in a JS-emulation mode that's much slower.
• Real public networking. The app doesn't have a public IP. To reach it from outside the browser tab, traffic gets proxied through StackBlitz's edge. Webhooks from Stripe / GitHub / Twilio either don't work or require 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 Dockerfile is yours, the CPU is yours, the memory is yours, the disk is yours, the public network interface is yours. Everything that works in a normal Linux server works here. Specifically:

• Full npm install works. Native deps compile because there's a real C toolchain. SQLite + Postgres clients work. Sharp installs. Playwright launches a real Chrome.
• Public HTTPS. Each VibeKit app gets a real subdomain on *.vibekit.bot with auto-issued Let's Encrypt SSL. Stripe webhooks reach it because it's a normal HTTPS endpoint, not a tab-bound proxy.
• Container stays alive. When the user closes their iPhone app, the Fargate task keeps running. Scheduled tasks fire on cron. Webhooks land. The app is deployed, in the production sense of the word.
• Real resource accounting. We allocate exactly 256 MB / 512 MB / 1 GB per app per plan. 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. We mitigate this with template scaffolds (no npm install needed) and an EFS Access Point -shared workspace so the agent's state 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 migrating 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 stays online with no browser tab open — Stripe webhooks, scheduled tasks, real users hitting your URL all work.
• Your domain is a real domain — map your Namecheap purchase, point an A record, done.
• 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 Health drawer. The 30-second cold start is real. So is everything that runs on top of it.