Project status

Project status

Kronik is pre-alpha. It is not ready for production, and interfaces may still change between releases. v0.5.0 is the latest release, the brief's "Isolation, standards and web" release (M20–M26), engine kronik-0.5.0+wasmtime-50.0.1. Its state is below, and the findings of the implementation audit of 2026-11-12 are all resolved in it (see #25, closed 2026-11-14). The main branch is the unreleased 0.6.0-dev line.

Releases

Release	Contents
v0.1.0	Durable turns, effects and capabilities, fork, replay and behavior diff with policy and approvals, proposals that span several actors, the TypeScript and Rust SDKs, the JSON API and MCP server, operations on a VPS, foreign actors in gVisor, privacy mode
v0.3.0	Python and Go SDKs, the CLI against a remote API, watch and preview forks, effect simulators, rollback via replay, foreign actors copied into forks
v0.4.0	Standard fetch through wasi:http, OpenTelemetry traces with a complete verifiable audit export, KMS-wrapped master key (OpenBao/AWS/GCP/Azure), Wasmtime 50.0.1, and crash-path hardening: atomic secret-catalogue publication, paced rate windows, restart-safe custody
v0.5.0	Long-lived connections (WebSocket, SSE, send-now, replay and diff, the four SDKs and chat-ts), streaming request and response bodies, app blob storage (holds, a collector, shipping and restore, erasure and reseal, the four SDKs and media-ts), external secret backends, the nonroot daemon and the microVM level opt-in, and durability fixes across the log, snapshots and reseal. WIT kronik:actor@0.1.1; engine kronik-0.5.0+wasmtime-50.0.1
v0.4.1	Patch release: kronik restore validates the manifest paths and the component names it takes from the snapshot bucket; restarts no longer grow with the log, nor stop on one whose retention compacted past an idle SQL actor; erasure no longer strands scrubbed reads at 503; the audit export and its followers recover at once from an overtaking configuration commit. Engine kronik-0.4.1+wasmtime-50.0.1

v0.5.0, v0.4.1 and v0.4.0 ship static musl archives for x86_64 and aarch64 with install.sh, SHA256SUMS, CycloneDX SBOMs and two-build byte-equality evidence (reproducibility.json); install.sh verifies each archive's attestation and refuses unsigned ones. The historical v0.1.0 and v0.3.0 releases are unsigned, and current consumers intentionally refuse their archives. v0.4.1 changes the engine id, so data written by an earlier release needs a passing kronik upgrade check with it before the first start.

There is no v0.2.0 tag. Its milestones shipped in v0.3.0; M10's fourth criterion (a real public GitHub Actions run) remains open, so the release is not accepted as complete for that milestone.

Milestones

The milestone order and acceptance criteria are defined in the build brief. Milestones M0–M15, M22, M28 and M23's B1 custody change are implemented; their evidence is mapped criterion by criterion in the compliance audit.

Milestone	Area	State
M0	Repository and spikes	done (before the public history; no tag)
M1	Durable turns on one node	done (v0.1.0)
M2	Effects and capabilities	done (v0.1.0)
M3	Fork, replay and behavior diff	done (v0.1.0)
M4	TypeScript SDK	done (v0.1.0)
M5	Policy, API and MCP	done (v0.1.0)
M6	Operations on a VPS	done except the destroyed-VPS demonstration (v0.1.0)
M7	Foreign actors in gVisor	done (v0.1.0)
M8	Privacy mode	done (v0.1.0)
M9	System proposals	done (v0.3.0)
M10	Remote control from CI	done except criterion 4
M11	Guard after promote and preview forks	done (v0.3.0)
M12	Effect simulators	done (v0.3.0)
M13	Rollback via replay	done (v0.3.0)
M14	Foreign actors in forks	done (v0.3.0)
M15	Python and Go SDKs	done (v0.3.0)
M22	WASI 0.3 and wasi:http	done except criterion 3
M23	Key and secret backends	done on main (B1 in v0.4.0; B2–B6 for v0.5.0), see below
M28	OpenTelemetry and audit export	done (v0.4.0)

Remaining work

The major tracks that remain are listed below. Some have design work and partially landed source, but none of the remaining milestones is accepted.

Milestone	Area	State
M16–M19	Cluster: replicated log and membership, placement, distributed replay, rolling upgrades	design only; no cluster crate on main
M20	MicroVM isolation (Firecracker)	on main, opt-in; accepted by the maintainers on 2026-11-14 (ADRs 0095–0096). Every M20 criterion passed in the isolation.yml proofs on GitHub-hosted Ubuntu 24.04 VMs (AMD, nested KVM): a foreign actor in Firecracker, vsock only and no network, a sandbox fork restored from a Firecracker snapshot (Postgres), plus the hostile-actor conformance, resource calibration, guest disk fill and graceful stop. Not yet run on bare metal, Intel or aarch64. gVisor stays the default; without /dev/kvm an add answers KVM_UNAVAILABLE with the gVisor suggestion
M21	Rootless daemon	on main: serve --init --rootless, the nonroot unit and runsc as root of a pinned user namespace (the deviation from the brief's runsc --rootless the maintainers ratified on 2026-11-13; ADRs 0060–0065). Proven in isolation.yml on GitHub-hosted Ubuntu 24.04 VMs with the AppArmor user-namespace restriction on (R1) and lifted: the rootless boundary, the installed fixture, hostile-actor conformance, both v0.1 demos without root, the Postgres fork, ship and restore. A bounded hostile-actor test runs in CI's foreign step. The root service stays the default
M23 B2–B6	External secret backends, cache and outage handling, PKCS#11 helper	done on main: criteria 2 and 3 ran against OpenBao (token and AppRole), moto (AWS Secrets Manager) and GCP/Azure emulators (scripts/e2e-secrets.sh), the PKCS#11 helper against SoftHSM2 with development builds (scripts/e2e-pkcs11.sh), and the DST scenarios "one allocator" and "secret outage" pass. A recorded external version the backend later destroys is scrubbed from an encrypted scrub-only copy (ADR 0142). Runs against real clouds and with release artifacts are not done
M24	Long-lived connections (WebSocket, SSE)	on main (2026-11-14): WIT kronik:actor@0.1.1, WebSocket and SSE in the gateway, buffered frames and send-now, replay and the diff's frames section, the API/CLI/MCP surface, DST properties C1–C9, the four SDKs and chat-ts. Criteria 2–4 pass in tests. Criterion 1 (1,000 clients in 50 rooms, release build) is partial: a 60-minute run at the default turn concurrency (ADR 0140), on the test machine confined to two CPUs standing in for the 2-vCPU test VPS, passed all ten checks (7,200,160 of 7,200,160 deliveries, p99 197 ms, VmHWM 485 MiB, VmRSS +9.4 % over the hour, the heap leveling off about 31 MiB above warm-up; docs/perf.md:855-867), and the 10-minute run passed every condition too. The brief defines the run on the test VPS, which has not run it, and no workflow runs scripts/acceptance-m24.sh load; that is what keeps criterion 1 partial
M25–M26	Streaming bodies and app blob storage	on main (2026-11-14), designs ADRs 0117–0122: the blob store with per-subject keys and sealed identities, uploads and responses streamed through it (constant memory: +1.6 MiB peak for a 300 MB upload, +1.4 MiB for a 1 GB response, release build on 2 CPUs), wasi:http bodies, forks and previews with blobs, collection with dry-run reasons, shipping and restore, holds and blobs on messages, timers, calls and replies with a per-actor quota, erasure and reseal of blobs, a blob DST workload with mutations, SDK support in all four languages and the media-ts example. Blobs are always on (slice B20, 2026-11-14). The upgrade check replays blob turns with the blob store
M27	Admin web interface	partial and unreleased; not wired into CI
M29–M30	Fleet API and event stream/webhooks	partial source, not accepted
M31	Security hardening (fuzzing, external review, signed releases)	signing and attestation done; fuzzing and external review open
M32	Performance at scale (cluster targets)	single-node runner and comparator exist; cluster targets unmeasured
M33	Compatibility promise	corpus and verifier exist; the promise is not in force before v0.9
M34	Documentation and drills	surface checks pass; off-host and cluster runbooks not exercised

Known gaps and open questions

The full list is kept in the compliance audit; the strongest ones are:

• M10 criterion 4. A real end-to-end run of the GitHub Action needs a public example repository and a daemon the GitHub runners can reach.
• M22 criterion 3. WASI 0.3 components cannot pass determinism and identity replay until a pinned Wasmtime ships the p3 previews as stable.
• Destroyed-VPS demonstration. demo/vps-restore.sh runs two data directories and one bucket on one machine and says so; it does not destroy a host or restore onto a second one, so it is not a pass of that criterion.
• SQL erasure and _subject. Decided (ADR 0005 §6, option B): a turn with a default subject may only write tables that have a _subject column. A write to a table without that column fails the turn with subjects/table-without-subject and names the table. Turns without a subject may still write anywhere. Old rows in tables without _subject, or with a NULL _subject, belong to nobody and survive erasure; they are not rewritten. Erasure of rows that have a _subject value is unchanged.
• --no-pii and numbers. Decided on 2026-11-13 (#70): --no-pii forks pseudonymize text and blob SQL cells only; INTEGER and REAL cells reach the fork's guest unchanged. Store numeric personal data as TEXT.
• Crypto in forks. An unmatched crypto.hmac-sha256 or crypto.sign-ed25519 is computed on the host only when that grant's in-forks mode is compute (ADR 0112). Grants written before the field stay compute. A new grant is recorded unless the operator passes --in-forks compute; recorded denies an unmatched call and does not compute. A computation is a log line and a metric. The key never leaves the host.
• KMS providers are verified against emulators. OpenBao transit, AWS KMS, GCP Cloud KMS and Azure Key Vault are exercised against pinned free emulators, not production cloud IAM; a real-cloud run needs explicit spending authorization.
• ACME is tested against Pebble. There is no public domain or public certificate authority in the acceptance path.
• Distribution licensing. Current packaging and the published v0.4.1 musl archive include LICENSE, NOTICE, and THIRD_PARTY_LICENSES.txt.
• CLA. The CLA needs review before the first external contribution.
• External validation. An independent external security review, a production pilot and a three-node thirty-day soak are still pending; single hosts, local processes and internal review do not replace them.
• Cluster verification. From v0.4.0 a release is to be verified on a three-node cluster; no such environment exists yet (the cluster track, M16–M19, is unimplemented), which is also why the M32 cluster targets are unmeasured.
• Single-node performance. Committed throughput meets the brief's 1 000 turns/s target across actors, not per actor (about 7 900 turns/s on the development machine and 2 770 turns/s on a 2-vCPU test VPS); the per-actor rate (about 180–210 turns/s) is not a gate (ADR 0111). Startup after a crash meets the 30-second target for a 1 GiB log (about 19 s). See performance evidence.
• Sampling coverage. A proposal may run in isolated mode with a small sample; only the payments-full-coverage policy stops promote on a sample, so elsewhere coverage relies on the reviewer reading summary.sample. Whether the default policy should ask for more is open.
• M24 ABI choice. Decided on 2026-11-13: v0.5 adds interfaces to kronik:actor@0.1.1 without changing existing ones, connection events arrive through an optional connection-handler export (ADR 0113), and only the actor that accepted a live connection may send on it (ADR 0114).
• M22 criterion 3. scripts/check-wasi-p3-gate.py on 2026-11-13: the gate is still closed (the newest Wasmtime release, 50, still marks its p3 modules experimental and does not list WASIp3 at tier 1 or 2).

How to follow progress

• Releases and signed assets: the releases page.
• The build brief's mapping to the tree: the compliance audit.
• Decisions and their rationale: docs/adr/.
• The CI and nightly GitHub workflows start only when someone runs them (workflow_dispatch). A push or pull request does not. The nightly workflow adds what is too slow for an ordinary CI run: a crash test of 1,000 kill -9 cycles, deterministic simulation with 10,000 seeds over every workload and a million-step run, and the release build. One manual run starts every one of those jobs; the same commands run locally. The release workflow is manual.
• Performance methodology, measurements and current targets: docs/perf.md and the performance evidence page.
• The five M0 spike summaries and their measurements: M0 spikes.