Zero
Run applications with confidence.
An operating system and a platform on upstream Linux, with nothing to assemble around it.
Linux already has what those layers add. Zero uses it directly, and connects it through one identity per workload.
Zero is in development. Everything on this page is planned.
Why Zero
Confidence and security
Each pod runs in its own sandbox, with its own kernel, by default. See the sandbox.
One system, nothing to assemble
Execution, isolation, identity, network, observability and integrity share one model. See the two parts.
Seeing everything
Every connection, byte and decision is traced to the pod that made it. Plans are shown before changes. See the trace.
Less hardware and cost
The same applications run on less hardware, with one thing to operate instead of many.
One sandbox and one kernel per pod
Each pod runs in its own sandbox: its own Linux kernel under KVM, what other products call a microVM. Inside it, each container is fenced with namespaces, cgroups, Landlock and seccomp.
Every connection traced to its pod
Zero records every connection, peer, byte, file and exec for each pod, attributed to its identity, without agents or sidecars.
Zero OS and Zero Platform
Zero OS runs on each machine. Zero Platform runs your workloads across them: scheduling, replicas, rollouts, identity, networking and observability.
A/B OS updates with automatic rollback
Zero OS writes a new image to the inactive slot and boots it. The node commits only if its local checks pass: it starts a small sandbox, installs its rules, and tests allowed and denied connections. If a check fails, the node returns to the old slot and records why.
How Zero differs
For each need a platform serves: how the Kubernetes stack and other stacks meet it today, and how Zero meets it.
| Need | Today | Zero |
|---|---|---|
| Running a workload | Pod, container image, containerd and runc, kubelet. | A pod in its own sandbox. Zero accepts OCI images and does not run Docker. |
| Kernel exploit containment | An extra runtime: gVisor or Kata. | One kernel per pod. |
| Workload identity | ServiceAccount tokens, or SPIFFE in a mesh. | Each pod’s IPv6 address. The node prevents forgery and Zero records which pod owns it. |
| Encrypted node-to-node traffic | A network plugin option (Cilium or Calico WireGuard), or mesh mTLS. | An encrypted WireGuard overlay network between nodes. |
| Network policy | NetworkPolicy through the network plugin, with iptables or eBPF. | Rules on source, destination, protocol, port and direction, checked by the networking process and the node’s kernel. |
| Connection visibility | Hubble (Cilium), or mesh telemetry. | Every connection, however short, with its duration and both ends attributed. |
| Metrics and logs | metrics-server, Prometheus, node-exporter and kube-state-metrics; fluent-bit or Vector for logs. | CPU, memory and I/O per pod, attributed to its identity, without agents or sidecars. |
| Node OS updates | Outside Kubernetes: Talos, Bottlerocket or kured. | A signed image, an A/B update on every node, one node at a time. |
| Fencing a dead node | A manual out-of-service taint, or Pacemaker STONITH. | Proof of stop from a fence Zero can check, never by timeout alone. |
| Extending the platform | CRDs and operators. | No custom kinds and no webhooks. Controllers are ordinary callers of the API. |
Zero docs
From the interface to the internals.