Keel

Declarative, self-healing orchestration for FreeBSD jails.

Get started Read the docs View on GitHub

Sub-projects 1-7, 9, 10, and 12 are complete: single-node jail reconciliation, the multi-node control plane, resource-aware scheduling, mutual-TLS hardening with certificate revocation/rotation, cross-node overlay networking, service discovery with a per-node virtual-IP proxy for load balancing across a service's replicas, persistent storage (named ZFS-backed volumes, node-pinned stateful services, and cross-node failover via zfs send/receive replication plus an operator force-repin verb), automatic HTTPS via ACME/DNS-01, a read-only operational dashboard, and cluster-wide backup/restore. Cordon/drain (sub-project 11) is code-complete, real-VM verification pending; bhyve VM workloads (sub-project 8) are designed but shelved for lack of nested-virt hardware. See the full journey →

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.

Automatic HTTPS

A kind: Ingress spec gets a real, auto-renewing Let's Encrypt certificate via ACME's DNS-01 challenge, no inbound reachability needed for issuance, proxied through a single per-node nginx jail.

Cluster backup and restore

One command backs up the control plane's state, every node's agent state, and every node's volume data; one command restores it all back, with partial failure reported clearly, never silently swallowed.

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

Read the full comparison →