Orchestration for Zigbox
A cluster that only runs what it can verify.
Zigcube schedules Zigbox workloads across a fleet. Images move as chunks between peers, every node checks signatures before it runs anything, and services talk only along declared grants.
Design principles
Kubernetes' good idea, rebuilt around it
Declared state reconciled by controllers stays. Most of the plumbing around it goes.
One thin agent
Each node runs a single rootless agent that links Zigbox directly. No CRI, no containerd, no shims.
Store-aware scheduling
The scheduler knows which chunks each node holds, and nodes fetch from peers before the registry.
Trust checked twice
Admission checks policy, then every node re-checks before exec. A compromised control plane cannot run unsigned code.
Grants, not a flat network
web → db:5432 is the whole rule. Identity-based, encrypted, default deny.
Ask why
zcube why prints the causal chain behind any state, so "why isn't it running" takes one command.
Pluggable storage
State lives behind a small versioned key-value interface. Postgres first, with OrioleDB for hot tables; SQLite for development.
Roadmap and demos
Every milestone ends in a live demo
Each demo is an automated test that runs in CI, and a shipped milestone shows the output recorded by that run, with a link to it. The control plane runs against a stand-in runtime until real Zigbox plugs in from its M2. Planned output is marked until the milestone ships. How it is built.
Documentation
Docs grow with the code
Each page goes live with the milestone that makes it true.
The project
Open, neutral, staying that way
Apache 2.0, forever
The same licence and no-relicensing pledge as Zigbox. DCO sign-off, no CLA.
Headed for a foundation
Conformance tests and a neutral home before anyone is asked to bet a company on it.
Speaks Kubernetes at the edge
A Kubernetes API facade is on the roadmap so existing tooling keeps working.