Lifo
Try Demo

Roadmap

Where Lifo is headed

North star

A developer can run agent code, dev servers, and real stacks in a sandbox that boots instantly — in the browser and in Node today, and as a single Docker-free binary on any host tomorrow. The measure of success isn't a feature checklist; it's: take a real project, point your tools at Lifo, and it just runs.

Already shipped

  • ✓Runs in the browser and in Node today — the same VM, client-side or server-side
  • ✓Real stacks unmodified — create-expo-app, Vite, Expo Router, Supabase (tinbase)
  • ✓Live previews — in-VM ports served over a service worker with HMR
  • ✓Git in every shell (isomorphic-git)
  • ✓Snapshot & restore a box's disk state
  • ✓Per-box process manager (list, kill, stop, restart)
  • ✓Same-origin CORS proxy so the VM reaches api.expo.dev with no relay

Next

Benchmarks for browser & Node environments

In progress

Reproducible numbers behind the claims: boot time, command throughput, filesystem and network overhead, memory, and dev-server cold-start — measured in both the browser VM and the Node runtime, published with the harness so anyone can re-run them.

The lifo CLI

Planned

A `lifo` command-line tool to run a box straight from your terminal — an interactive shell, `lifo run script.js`, mounting a host directory into the VM, and exposing in-VM ports locally. The on-ramp to using Lifo server-side before the standalone binary lands. It also gives Windows a consistent POSIX shell + coreutils build environment (so npm scripts like `rm -rf dist && …` just work) without WSL or Docker — for pure-JS toolchains; native compilation stays out of scope.

Filesystem persistence & durability

Planned

Pluggable filesystem backends so a box's disk maps to the right layer for where it runs: the browser's persistent storage (IndexedDB / OPFS) in a tab, the host filesystem when running via the CLI, or purely volatile in-memory for throwaway sandboxes. Plus durability beyond whole-disk snapshots — a write-ahead log for crash-consistent, incremental persistence.

A single distributable binary for host VMs

Exploring

Lifo already runs in Node. The next step is a single `lifo` binary — no Node install required — that spins up isolated VM instances per use case (per-agent, per-project, per-request) so you can run and tear down disposable sandboxes on a server without Docker.

Tunnelling & network

Planned

Expose an in-VM port to a public URL through a tunnel — via a self-hosted relay or a hosted proxy — so a dev server or API running in a box is reachable from a phone or a teammate. Document using Lifo in place of Docker for local dev and CI sandboxes, honestly, for the cases where it fits.

Host escape hatches (opt-in)

Exploring

A deliberate, permissioned API to reach the host beyond port tunnels — run host-machine commands when Lifo is embedded in a CLI/Node process (e.g. `osascript` on macOS), and call browser/Web APIs (clipboard, notifications, geolocation) from inside a box in the browser. Powerful and risky by design, so it ships behind explicit, per-capability permissions and is off by default.

Embeddable UI (terminal & browser)

In progress

Ship the playground's building blocks as reusable, framework-agnostic components in @lifo-sh/ui. The Terminal and the PreviewBrowser (an iframe view bound to an in-VM port, with back/forward/reload and a friendly address bar) are here today and documented; richer browser chrome (tabs, history) is the remaining lower-priority follow-up.

Package manager & WASM runtimes

Planned

A first-class package manager for VM tools plus pluggable WASM runtimes, so more binaries (Python, native tools) run inside the VM.

Broader Node & serverless coverage

Planned

Extend the Node compatibility layer toward serverless handlers and more of the ecosystem, running unmodified in either environment.

Priorities shift with real usage. Have a use case? Open an issue.