What Is lifo.sh? The Browser-Native OS for AI Sandboxing
Every AI coding assistant needs somewhere to run code. Today that usually means spinning up a cloud container — a remote Linux box that boots in seconds, bills by the millisecond, and disappears when the session ends. It works. It also costs money, adds latency, requires internet, and puts your users' code on someone else's infrastructure.
Lifo takes a different approach. It is a browser-native operating system — a layer that maps familiar POSIX-like interfaces (filesystem, processes, shell) onto APIs the browser already provides (Web Workers, IndexedDB, WebAssembly). The result is a full sandboxed environment that boots in under a millisecond, persists across sessions, runs offline, and costs nothing to operate — because it runs on hardware the user already owns.
Why does this matter?
The cloud sandbox market is growing fast. E2B raised $35 million. StackBlitz (the company behind WebContainers and Bolt.new) raised $135 million. Vercel, Cloudflare, and Daytona all shipped their own sandbox products. Every AI agent builder faces the same question: where does the code run?
The default answer — cloud containers — creates three problems that scale with your product:
Cost scales with usage. Cloud sandboxes bill per session, per second, per CPU-millisecond, or some combination. When every user interaction triggers code execution, your infrastructure bill grows linearly with your user base. For a startup trying to offer a generous free tier, this is a structural disadvantage.
Latency compounds across interactions. A single network round-trip to a cloud sandbox takes 50-200ms. An AI agent that makes 15 tool calls per conversation accumulates 750ms to 3 seconds of pure network overhead — time the user spends waiting for a spinner. Lifo executes in the same browser context as your application, so each operation completes in under a millisecond.
Internet dependency limits reach. Cloud sandboxes require a network connection by definition. That rules out airplanes, rural schools, developing regions with unreliable connectivity, and any environment where code shouldn't leave the device for privacy reasons.
Lifo solves all three by moving execution to the browser. Not by emulating Linux (which is slow and fragile), but by mapping POSIX interfaces to native browser APIs — giving you the familiar shape of an operating system backed by the V8 engine that's already running on your user's machine.
How it works
Lifo sits between your application code and the browser's built-in capabilities. When your AI agent calls fs.writeFile(), Lifo writes to IndexedDB. When it calls spawn(), Lifo launches a Web Worker. When it needs to run compiled code, Lifo delegates to WebAssembly.
From the developer's perspective, it looks like a normal sandbox:
npm install @lifo-sh/core
import { Sandbox } from '@lifo-sh/core';
const sandbox = await Sandbox.create();
// Write a file
await sandbox.fs.writeFile('/app/hello.js', 'console.log("Hello from Lifo")');
// Run it
const result = await sandbox.exec('node /app/hello.js');
console.log(result.stdout); // "Hello from Lifo"
That code runs entirely in the browser. No server receives the request. No container boots. No billing meter ticks. The sandbox is ready the moment Sandbox.create() resolves — which takes less than a millisecond.
The filesystem
Lifo provides a POSIX-like filesystem backed by IndexedDB. Files persist across browser sessions and survive page refreshes. You can create directories, read and write files, and navigate paths exactly as you would on a Linux box. The difference is that the data never leaves the user's device unless you explicitly send it somewhere.
This persistence is automatic. There's no configuration, no external storage to mount, and no cleanup to manage. When a user returns to your application tomorrow, their files are still there.
Process isolation
Each process runs in its own Web Worker — the browser's built-in mechanism for running code on a separate thread. Web Workers are sandboxed by the browser itself: they can't access the DOM, can't read cookies, and can't interfere with other workers. This gives you process-level isolation without the overhead of container boundaries.
The shell
Lifo includes a shell that understands common commands. Your AI agent can run scripts, pipe outputs, and chain commands in a way that feels natural for anyone who's used a terminal. The shell is the interface between the high-level "run this code" request and the low-level Web Worker execution.
The product stack
Lifo isn't a single product — it's a stack of four layers, each building on the one below:
Lifo Core is the runtime. It's the @lifo-sh/core npm package — the filesystem, process manager, and shell. Core is MIT-licensed and always will be. This is what you embed in your product.
Lifo Desktop is a browser-based desktop environment built on Core. Think of it as a visual interface for the operating system — a file manager, terminal, and application launcher that runs in a browser tab. Also MIT-licensed.
Lifo Board is a collaborative AI agent canvas built on Desktop. It's where non-technical users interact with AI agents that use Lifo for code execution. Board is designed for teams — product managers, designers, analysts — who need AI assistance without a terminal. MIT-licensed.
Lifo Cloud is the paid layer. It adds always-on sandboxes (persistent even when the browser is closed), SSH access from external tools, team workspaces with shared filesystems, and an API for headless automation. Cloud is the revenue engine; everything below it is free and open-source.
This open-core model means you can build a complete product on the free layers. Lifo Cloud exists for teams that need server-side capabilities on top of the browser-native foundation.
Who is it for?
Lifo is designed for developers building products where AI agents need to execute code. The most common use cases include:
AI coding assistants
You're building a product where users describe what they want in natural language, and an AI writes and runs the code. Each conversation involves multiple rounds of code generation, execution, and refinement. Lifo handles the execution layer — no infrastructure to provision, no costs to manage, instant feedback on every run.
Interactive documentation
Your developer docs include runnable code examples. Users click "Run" and see output inline, without leaving the page. Lifo makes this trivial: embed the sandbox, load the example code, and execute on click. The sandbox boots instantly, so there's no loading state between the click and the output.
Educational platforms
Students learn to code by writing and running exercises in the browser. You need persistent progress (students pick up where they left off), offline support (schools have unreliable internet), and zero per-student cost (you can't bill per execution when serving thousands of students on a free tier). Lifo handles all three by default.
Browser-based development environments
You're building something like a web IDE, a prototyping tool, or a no-code platform that generates and runs code behind the scenes. Lifo gives you the execution environment without the server. Your users get instant feedback, and you get a simpler architecture.
Privacy-sensitive applications
Your users' code can't leave their device — whether for regulatory compliance, intellectual property protection, or user trust. Because Lifo runs entirely in the browser, code never touches a server. There's nothing to secure on the backend because there is no backend.
How Lifo compares to cloud sandboxes
The fundamental difference is where code runs. Cloud sandboxes (E2B, Cloudflare Sandbox, Vercel Sandbox) run code on remote servers. Lifo runs code on the user's device inside the browser.
This creates clear trade-offs:
| Lifo | Cloud sandboxes | |
|---|---|---|
| Cost | $0 (runs on user hardware) | Per-session or per-second billing |
| Boot time | <1ms | 300ms – 5s |
| Latency | Sub-millisecond (same context) | 50-200ms per round-trip |
| Offline | Yes | No |
| Persistence | Automatic (IndexedDB) | Ephemeral or requires cloud storage |
| Language support | JavaScript, TypeScript, WASM | Any (full Linux container) |
| System access | Browser-sandboxed | Full Linux (networking, packages, binaries) |
| License | MIT (open-source) | Proprietary or vendor-locked |
Cloud sandboxes win when you need full Linux capabilities — native binaries, system packages, real networking, multi-language support beyond JavaScript. If your agent needs to run Python with NumPy, compile C++ code, or expose a running web server via a preview URL, a cloud sandbox is the right tool.
Lifo wins when the execution is JavaScript or TypeScript (which covers most web development), when cost matters at scale, when latency matters per interaction, when offline support is needed, or when code privacy is non-negotiable.
For a detailed breakdown of each competitor, see our comparison guides:
- Lifo vs E2B
- Lifo vs WebContainers
- Lifo vs Vercel Sandbox
- Lifo vs Cloudflare Sandbox
- AI Sandbox Comparison 2026
Getting started
Add Lifo to any JavaScript or TypeScript project:
npm install @lifo-sh/core
import { Sandbox } from '@lifo-sh/core';
const sandbox = await Sandbox.create();
// Your AI agent can now execute code
const result = await sandbox.exec('node -e "console.log(2 + 2)"');
console.log(result.stdout); // "4"
// Files persist automatically
await sandbox.fs.writeFile('/data/result.json', JSON.stringify({ answer: 4 }));
// Read them back later — even after a page refresh
const data = await sandbox.fs.readFile('/data/result.json', 'utf-8');
No API keys. No environment variables. No backend deployment. The sandbox runs the moment your frontend loads.
For the full API reference and guides, visit lifo.sh. The source code is available on GitHub under the MIT license — fork it, modify it, embed it, contribute back.
Or just try it now:
npx lifo-sh
Frequently Asked Questions
Is lifo.sh free?
Yes. Lifo Core, Lifo Desktop, and Lifo Board are MIT-licensed and free forever. Lifo Cloud — which adds always-on sandboxes, SSH access, and team workspaces — is a paid product. You can build and ship a complete product without ever paying for Lifo.
What languages does Lifo support?
Lifo runs JavaScript and TypeScript natively. It also supports any language that compiles to WebAssembly — Rust, C, C++, Go, and others. Python support is available through Pyodide (a WebAssembly port of CPython). Full native binary support (like running arbitrary pip packages with C extensions) requires Lifo Cloud or a cloud sandbox.
Is Lifo secure?
Lifo inherits the browser's security model. Each sandbox runs in a Web Worker, which is isolated from the main thread, other workers, and the DOM. The browser enforces same-origin policy, prevents file system access outside IndexedDB, and sandboxes all execution. This is the same isolation model that protects you when visiting untrusted websites — battle-tested across billions of devices.
Can Lifo replace my cloud sandbox?
It depends on your use case. If your product executes JavaScript or TypeScript and doesn't need real networking, native binaries, or multi-language support beyond what WASM provides, Lifo can replace your cloud sandbox entirely — saving you infrastructure cost and complexity. If you need full Linux capabilities, Lifo can complement a cloud sandbox by handling the common cases client-side and only offloading complex workloads to the server.
How is Lifo different from WebContainers?
WebContainers (by StackBlitz) also runs code in the browser, but it's proprietary, commercially licensed, and limits free usage to 500 sessions per month. Lifo is MIT-licensed with no session caps. For a full comparison, see Lifo vs WebContainers.
Does Lifo work in all browsers?
Lifo works in any modern browser that supports Web Workers, IndexedDB, and WebAssembly — which includes Chrome, Firefox, Safari, and Edge. It works on desktop and mobile. No browser extensions or plugins are required.