Docker,
in the browser.
Real OCI/Docker containers on unmodified Alpine Linux, booted by a from-scratch RISC-V emulator — entirely client-side in WebAssembly. No server, no daemon, no install. Just a URL.
Not a toy. A whole machine.
Every layer of a real computer, re-implemented and verified — then compiled to run in the one runtime everyone already has.
Unmodified Linux
Boots the stock Alpine riscv64 kernel + userland to a login shell — OpenRC, busybox, apk, the works.
// boot-to-loginPersistent disk
A copy-on-write overlay in IndexedDB survives tab reloads, with crash-consistent virtio-blk flush semantics.
// IndexedDB overlayReal networking
A user-mode TCP/IP stack (slirp) with DHCP + DNS, plus a Tailscale transport — the guest gets a real IP.
// slirp + tailscaleOCI containers
Pull and run real Docker Hub images as isolated containers with wvrun — pid/mount/uts namespaces.
Snapshot & resume
Freeze the whole machine — CPU, RAM, devices — to a coherent blob and resume instruction-exact, fsck-clean.
// save_resumeProvably correct
Differentially tested byte-for-byte against Spike, with a native≡wasm determinism gate on every build.
// diff vs spikeBuilt the long way. On purpose.
One checksum fixture, five runtime mechanisms.
Every published row requires seven raw-backed command and readiness samples. Command timing uses submit → checksum marker; responsive readiness uses each runtime’s own fresh-launch → first-response path.
| Runtime | Execution model | Command median | First command | Per-runtime responsive readiness | vs native |
|---|---|---|---|---|---|
| Loading raw benchmark evidence… | |||||
Fixture: a stateful, non-foldable 2,000,000-iteration Math.imul recurrence;
every sample must print RUNTIME_BENCH_v1_76363d7f_79d1baaf.
Command medians cover each mechanism's seven declared fresh-command population and stop at the exact
checksum marker; wasm-vm uses the first genuine Node command in each fresh restored VM. Responsive
readiness is reported separately, stops at the first exact probe response, and
displays the runtime-specific launch mechanism—including snapshot restore versus process launch.
Each row preserves its own capture revision, timestamp, browser mode, source, and collector; the
comparison does not pretend they came from one campaign. It is a mechanism comparison, not a
normalized cold-boot or isolation-equivalence claim.
Raw samples and provenance →
Fetch → decode → execute, a few hundred million times.
An interpreter core in Rust, compiled to WebAssembly, driving a full virt platform — CLINT, PLIC, UART, virtio-blk/net/rng — off a deterministic clock. The whole stack, top to bottom:
# booting unmodified Alpine riscv64 in WebAssembly… [ 0.000000] Linux version 6.6.63 (riscv64) — in your browser [ 2.664] Run /init as init process wasm-vm:~# uname -m riscv64 wasm-vm:~# cat /proc/cpuinfo | grep isa isa : rv64imafdc wasm-vm:~# wvrun run busybox echo "hello from a container" hello from a container wasm-vm:~# _
A real machine — not a clever illusion.
Plenty of things look like a computer in a browser. This one actually is one.
Every instruction runs for real, retiring one at a time — not a pre-baked screencast or a canned transcript.
There's no server doing the work. The CPU, RAM, disk, and network stack all live in the page — offline-capable after first load.
Unmodified riscv64 binaries execute against a spec-correct core — differentially checked byte-for-byte against Spike.
Boot a Linux box. Right now.
It runs entirely on your machine — nothing you do here leaves the tab.