How building an OS in the browser saved us $$$ on sandboxes

Almost every AI app builder works the same way under the hood. You type a prompt, and somewhere a cloud VM boots up just for you. It installs packages, starts a dev server, runs the AI's code, and streams a preview back to your browser.

That VM is a sandbox, and someone pays for every second it's alive.

When we started building RapidNative, an AI builder for real React Native apps, we made a bet that looked a little crazy at the time. We wouldn't give users a sandbox at all. Everything would run inside the browser tab they already had open.

More than a year, 40K users, 50K projects and 170K prompts later, I finally sat down with our production database and asked the obvious question: how much money did that bet actually save us?

The answer: more than $10,000, and up to about $30,000 depending on how you size the machines. For a product with 40K users, that's a huge saving. And the money turned out to be the smaller half of the story.

The bet: put the whole dev environment in the tab

A React Native dev environment is heavy. You need Linux, a shell, Node, npm packages, the Metro bundler and often a Postgres database. That's why everyone reaches for a VM.

We rebuilt each piece so it could run in a browser instead:

• Linux → Lifo. A tiny Linux-like OS written in TypeScript. It isn't an emulated Linux VM; it reimplements the OS and Node.js APIs directly on top of what the browser already gives you. It has a virtual filesystem, a bash-like shell, 60+ commands and a Node.js compatibility layer. It runs anywhere JavaScript runs: a browser tab, a Node process, a serverless function.
• Metro → browser-metro. A Metro-compatible bundler that runs in the browser, so the preview builds right next to your code.
• npm install → pre-bundled packages. Packages come from a CDN already bundled, so nothing has to download and watch node_modules.
• Postgres → PGlite. Real Postgres compiled to WebAssembly, about 16 MB, running in the tab.

Even our AI agent doesn't get a VM. Each prompt runs in a normal serverless function, which boots a fresh in-memory Lifo in under a millisecond, loads the project files, lets the agent use bash and file tools, saves the changes and shuts down. If you want the full architecture, I wrote it up in we kept the shell and left the VM anyway.

The result: when you open a project on RapidNative, your laptop is the sandbox. We pay for nothing while you think, read or test your app.

What over a year of usage looks like

I pulled everything from our production database, from our first project on 30 June 2025 to today:

• ~40K users signed up, and 35.7K of them opened the editor and built something
• 50K+ projects
• 170K+ prompts sent to the AI
• ~78K editing sessions

The busiest single hour we've ever had saw 68 projects being worked on at the same time. On a normal hour it's under 10.

How I turned that into a sandbox bill

Sandboxes don't bill per prompt. They bill for wall-clock time: every second the machine is alive, whether it's busy or idle. So the real question is how long a sandbox would have been running for each user.

Here's the method. You can run the same thing on your own product.

1. Group activity into sessions. I took every prompt, editor click and project creation, per user and per project. A long enough gap starts a new session.
2. Keep the sandbox alive while the user is around. AI builders keep the sandbox running while your editor tab is open, so you can test the preview. Our logs only see prompts and clicks, not you tapping around in your app. So I joined gaps of up to an hour into one session and kept the sandbox alive 30 minutes after the last action.
3. Add the time spent waiting on the agent. Our older logs saved a prompt only when the agent finished, so the generation time before it was missing. That adds about 2,300 hours.
4. Add the cold start. Every new session means creating the VM, copying the project in, installing packages and running the first Metro bundle. I counted 2.5 minutes per session at full CPU.
5. Add snapshots. Resuming quickly needs a saved copy of each project, about 1 GB with node_modules. We have roughly 3,500 active projects a month.
6. Pick a realistic machine and price it. An Expo/Metro dev server wants about 2 vCPUs and 4 GB of RAM, the default on most platforms. For platforms that bill CPU only when it's busy, I assumed 15% average use. Prices are each vendor's public rates today.

That comes to about 57,500 sandbox-hours since day one. For comparison:

• A stingy setup that kills the sandbox 10 minutes after your last click would still need about 27,000 hours.
• A bigger 4 vCPU / 8 GB machine, which plenty of teams use for Metro, roughly doubles the compute bill.

The bill we never got

Here's what those hours would have cost on each platform since day one, on a 2 vCPU / 4 GB machine, next to the same usage on a bigger 4 vCPU / 8 GB machine:

So running everything in the browser saved us $10,000 to $18,000 so far, and up to ~$30,000 on bigger machines. For a product with 40K users, mostly on the free plan, that's huge. It's money that would have gone to keeping VMs warm for people who were mostly reading, thinking or away from the keyboard.

At today's usage, that's roughly $700 to $1,250 every month we don't pay, and it would grow with every new user.

Where the money goes: idle time and cold starts

Here's what surprised me. People don't camp in the editor for hours. They build in short bursts.

Measured by actual clicks and prompts:

• The median session is 2 to 4 minutes. The average is about 10.
• 75% of sessions are under 10 minutes.
• Fewer than 1 in 500 sessions last more than 3 hours.

People open a project, send a prompt or two, look at the result and leave. Then they come back later and do it again.

That pattern teaches you two things about sandbox costs.

First, the idle timeout is your biggest cost lever. Killing the sandbox 10 minutes after the last click needs about 27,000 hours. Keeping it alive while the user is around needs 57,500. Same users, same prompts, double the bill. When sessions are this short, the time after the user leaves can cost more than the time they spent working.

Second, cold starts add up. With about 74,000 sessions, a 2.5-minute boot alone comes to over 3,000 hours. That's paid before the user sees a single pixel, and the user spends those minutes staring at a spinner.

What users feel: speed

The savings show up on our invoice. What users notice is the speed.

Nothing to boot. A Lifo box is ready in about 27 ms, so opening a project just means opening a tab. There's no VM to provision, no npm install and no dev server to start. On a sandbox, each of those ~74,000 sessions would have begun with a cold start of a minute or more.

Changes show up where you are. When you or the agent change a file, the bundler runs in your tab and the preview hot-reloads right there, with no round trip to a remote machine (here's how that live preview pipeline works). On the server, the agent's own Lifo box boots in under a millisecond per prompt, so nothing has to be kept warm.

And on the business side

A free tier whose cost doesn't grow with users. Most of our 40K users are on the free plan. In the browser, a free user costs us close to nothing while they edit. On a sandbox, each one is a meter running. That changes how generous you can afford to be.

No ceilings. No concurrency limits to negotiate, no rate limits on creating VMs, no capacity planning for a launch day spike. If a post goes viral tomorrow, each new user brings their own computer.

Costs that stay flat as we grow. So far the gap is $10k to $18k. At 10× our current usage, the same sandbox setup would cost roughly $85k to $150k a year. In the browser, that number barely moves.

"Why not just use WebContainers?"

If you've built anything in this space, you're probably asking this already. WebContainers from StackBlitz, the tech behind Bolt.new, already runs Node.js in a browser tab. Why build our own?

We looked at it seriously. The blocker was the license.

• The npm package, @webcontainer/api, is MIT licensed, but it's only a thin client. The runtime it boots is closed source and loads from StackBlitz's own servers.
• StackBlitz says production use in a commercial, for-profit setting needs a commercial license, and that includes serving your customers or your employees. It's free for open source, prototypes and proofs of concept.
• There's no public price. You contact sales.

For us, that meant the runtime every user touches in every session would depend on one vendor's pricing and terms. We couldn't fork it, change it, or run it on our own servers for the agent. We'd have swapped a per-minute VM bill for a license we'd have to renegotiate as we grew.

So we built Lifo and made it open source under MIT. Later we benchmarked the two ourselves, in the same headless Chromium on the same machine. The benchmark is in the Lifo repo if you want to rerun it:

On the server, a fresh Lifo box boots in about 0.6 ms. Shell commands run at over 200,000 per second and small file reads at nearly 600,000 per second. That's cheap enough to create a brand-new box for every request and throw it away.

It isn't a free lunch. WebContainers ships a real build of Node.js, so its compatibility is more complete. Lifo can't run native Linux binaries, and its isolation happens in JavaScript, so it isn't a security boundary. That's part of why we still run real containers for live previews on physical phones.

What I'd tell anyone building an AI coding product

1. Measure your sessions before you pick a sandbox. Group your events by user and project with a 30-minute gap and look at the distribution. If your median session is a few minutes like ours, cold starts and idle timeouts will dominate your bill.
2. Treat the idle timeout as a pricing decision. It can double the bill on exactly the same usage. Pause aggressively, and resume from a snapshot when the user comes back.
3. Prefer platforms that bill CPU only when it's busy. A dev server is idle most of the time. On Vercel Sandbox and Cloudflare Containers, an idle machine mostly costs you memory, which is a big part of why Cloudflare came out cheapest here.
4. Right-size the machine. Everyone defaults to 2 vCPUs and 4 GB. If your tooling fits in 1 GB, you can cut the bill in half or more.
5. Ask what really needs a server. For us, editing, bundling, previewing and even the database fit in the browser. The AI agent runs in a normal serverless function with Lifo inside it, no VM required. Lifo is open source, so you can do the same in your own product.
6. Be honest about what still needs one. We're not server-free. Since August we run our own container platform for live previews on real phones, and the agent's serverless runs aren't free either. The browser handles the common case; servers handle the rest.

The real lesson

I went looking for a savings number and found a big one: over $10,000 for a product our size. But I also found something more useful: a clear picture of how people actually build with AI. They work in short bursts, they come and go, and they want to see their app now.

A browser tab fits that pattern perfectly. It's already open, it's already paid for, it starts instantly and it reloads your app the moment anything changes.

RapidNative is where all of this runs in production, and Lifo is open source if you want to build something like it.

This post first ran as an article on X. If you're weighing sandboxes for your own product, or think I've got a number wrong, reply there. I read every one.

Numbers come from RapidNative's production database, 30 June 2025 to 31 October 2026. Sandbox prices are the public rates on 31 October 2026 from E2B, Vercel, Cloudflare, Daytona and Modal. Snapshot storage is included at $0.08/GB-month; network traffic is left out, so the real sandbox bill would have been a little higher. Lifo vs WebContainers numbers are from Lifo's open benchmark suite, measured in the same headless Chromium.