Komputer is a durable runtime for stateful WebAssembly programs. It captures admitted continuations and journals their interactions so a fresh process can continue after failure or movement; broader Wasm runtimes can recover by replay instead.
The current product focus is agent brains: ordinary async harnesses with conversation, planning, tool, and stream state in memory. The harness does not need an application reducer, recovery callback, or persisted state machine for every await point.
Komputer is early software. Its durable formats and compatibility profiles are versioned, but the public API is not yet stable.
For this use case, the brain is the Wasm harness: its control loop, in-memory state, pending futures, model stream, and tool orchestration. Hands such as sandboxes, MCP servers, model providers, and credentialed services stay outside it and are reached through explicit network or policy gateways. Credentials are never given to the guest.
Komputer's journal is operational recovery history, not an application session schema. A product may still keep a semantic conversation log for context, audit, and brain upgrades; it does not need to encode every internal harness transition there just to survive a process failure.
Komputer is committed to Wasm and does not aim to support native binaries, full POSIX, or act as a general container replacement. See Compatibility for the admitted program shapes and capability limits.
The primary demo runs an ordinary Rust WASI brain with a real streaming model. It relocates the executor during inference and keeps the same WebSocket, provider response, conversation, plan, and local tool state. The guest contains no recovery path or application-level state encoding:
export OPENAI_API_KEY=...
./demos/agent/run.shPrerequisites are Rust with the declared Wasm targets, Binaryen's wasm-opt,
the S2 CLI with local mode, curl, and Python 3. The key stays in a native
policy gateway and is not supplied to the guest, executor, or computer
specification. See the demo contract.
For a credential-free smoke test of relocation with a smaller TCP counter
guest, run ./demos/relocation/run.sh.
- In-flight continuation checkpoints for admitted stateful Wasm programs.
- Replay recovery for broader Wasm runtimes that cannot expose a continuation.
- Journal-before-visibility ordering for clocks, timers, entropy, input, readiness, DNS, network traffic, and external-effect intents and results.
- Reconstructable virtual files and resources rather than copied host handles.
- Independently operated anchors when a live connection must outlast an executor.
- Explicit checkpoint, relocation, handoff, and host-to-host movement.
- Replay-divergence detection and permanent revocation of a divergent incarnation.
With an S2 basin and S3 checkpoint bucket available:
komputer computer init app.wasm \
--directory my-computer \
--s2-endpoint http://127.0.0.1:8080 \
--checkpoint-s3-bucket komputer-checkpoints
komputer computer validate my-computer/computer.json
komputer computer start my-computer/computer.json
komputer computer status --state-dir my-computer/stateThe CLI calls each durable program instance a computer. init admits and
prepares its Wasm image, creates its identity and journal, provisions stable S2
input and output streams, and writes a relocatable computer.json. validate
checks the exact artifacts, bounded histories, selected checkpoint, and network
boundary without acquiring authority.
See Deploying one computer, Running a computer, and Moving a computer.
scripts/check-product.sh
scripts/build-rust-guests.shThese are the automatic pull-request checks. The repository pins Rust 1.96.1
and its Wasm targets; source-image preparation additionally requires Binaryen
131. Development and continuous verification owns the
exact per-change and scheduled gates; Implementation
status summarizes what that evidence
establishes and what remains next.
- Architecture
- Implementation status
- Compatibility
- Journal and checkpoints
- Network I/O
- Documentation map
MIT. See LICENSE.