Keel
Declarative, self-healing orchestration for FreeBSD jails.
Why you'd use it
Keel ties FreeBSD's own isolation and resource-control primitives together the way Kubernetes ties together Linux namespaces, cgroups, and overlay networking.
Declarative jails
Describe a jail (image, command, resources, network, restart policy) as a spec; apply it; the daemon makes reality match it, continuously, not a one-shot script.
Self-healing
Crashed jails restart automatically per policy, with crash-loop backoff so a persistently broken jail doesn't spin forever.
Safe by construction
The daemon only ever touches jails it created (name-prefixed and tracked in its own state), so it can share a host with other jails or tooling without stepping on them.
Fast provisioning
Jail root filesystems are ZFS clones of a base image, so creating a new jail is close to instant and cheap on disk.
Cluster networking
Every node gets a routable, deterministic subnet with kernel-level routing to every other node, no overlay tunnel, no new dependency.
Services and load balancing
A kind: Service spec runs N replicas spread across nodes behind one stable virtual IP, transparently relayed round-robin to a currently-healthy replica.
Persistent volumes
A jail can declare named volumes backed by their own ZFS datasets, created on first use and surviving the jail's own deletion, mounted back in on re-apply with the data intact.
How this differs from Kubernetes
Keel borrows Kubernetes' shape, not its scope. Today it's the FreeBSD analog of a kubelet plus a growing cluster layer.
| Kubernetes | Keel (current) | |
|---|---|---|
| Workload unit | Pod (Linux containers) | Jail |
| Filesystem | overlay/container images | ZFS clones of a base dataset |
| Storage | PersistentVolume/PVC, any node | named ZFS volumes, single node only |
| Scope | multi-node cluster, resource-aware scheduler | multi-node, resource-aware scheduler (heuristic) |
| Networking | CNI, overlay networks, Services | per-node kernel routing, per-service virtual IP + proxy |
Keel