FreeBSD Has Everything It Needs for Container Orchestration. So Why Doesn't It Exist Yet?

This is the first post in a series where I build a Kubernetes-like orchestration layer on FreeBSD, using only native primitives. No Linux. No VMs. No “just run K8s in bhyve.”

TL;DR

FreeBSD jails have been around since 2000: 8 years before Linux cgroups, 13 years before Docker. In November 2025, FreeBSD was officially added to the OCI Runtime Specification v1.3 (unanimous vote, 9-0). Podman runs on FreeBSD. Official OCI images exist. ZFS, VNET, pf, rctl: all the primitives for container orchestration are there.

And yet, when you search for “Kubernetes on FreeBSD”, you find workarounds running Linux VMs inside bhyve. The actual native work is scattered across a handful of repos with single-digit stars.

I’m going to build a proof of concept that ties these pieces together. Not a Kubernetes clone: a FreeBSD-native orchestrator that uses jails, ZFS, and VNET the way they were meant to be used.

The “FreeBSD Isn’t Ready” Narrative

Search for FreeBSD and containers, and you’ll find a consistent story: close but not there yet.

The Register (December 2024): “do still have to run it as root - even though rootless operation is one of Podman’s selling points on Linux.” Fair point, but rootless is a convenience feature, not a prerequisite for orchestration.

The f3s project (November 2024): an attempt at “Kubernetes with FreeBSD” that actually runs Linux VMs on a FreeBSD host via bhyve. The author gave up on native FreeBSD because the networking stack for containers isn’t there. Honest, but it reinforces the narrative.

FreeBSD forums in 2025: people asking about Docker Compose on FreeBSD, getting pointed to Linuxulator workarounds.

The pattern is always the same: someone tries to replicate the Linux container experience on FreeBSD 1:1, hits the gaps, and concludes FreeBSD isn’t ready.

But that’s the wrong question. The right question is: can FreeBSD do what containers actually DO, using its own primitives?

What Actually Exists Today

Let’s look at the building blocks, with real version numbers and dates.

Isolation: jails (since 2000)

FreeBSD jails provide process isolation, filesystem isolation, and network isolation through a single jail(2) system call. Where Linux bolted on namespaces incrementally (mount 2002, PID 2006, network 2009, user 2013), FreeBSD had a coherent isolation model from day one.

The philosophical difference matters: Linux containers are additive (start with nothing, add capabilities). FreeBSD jails are subtractive (start with a full system, restrict). Both work. The subtractive model is arguably easier to reason about for security.

OCI Compliance: ocijail (2023-present)

ocijail by Doug Rabson: an OCI-compatible runtime that uses jails as the isolation mechanism. Currently at v0.4.0, 96 stars, required by the Podman and Buildah ports on FreeBSD. Think of it as the FreeBSD equivalent of crun/runc.

And the big one: on November 4, 2025, FreeBSD was officially added to the OCI Runtime Specification v1.3. Unanimous vote. The freebsd object in the spec defines how to implement containers using jails. The FreeBSD Foundation called it a watershed moment. They’re right.

Container Images: official since FreeBSD 14.2

FreeBSD 14.2-RELEASE ships official OCI images on Docker Hub and GHCR:

• Static: 5.45 MB (bare minimum)
• Dynamic: 15.9 MB (shared libraries)
• Minimal: 35.1 MB (shell + pkg)

Both amd64 and arm64.

Storage: ZFS

This is where FreeBSD is years ahead of Linux in the container context. ZFS snapshots and clones are the perfect primitive for container layers: copy-on-write, instant cloning, built-in checksumming. Linux containers use OverlayFS or devicemapper. FreeBSD gets ZFS natively, with none of the kernel module drama.

Networking: VNET + pf

VNET gives each jail its own network stack: routing tables, interfaces, firewall rules. Combined with pf for packet filtering and NAT, you have per-container networking that’s more capable than what most Linux CNI plugins provide. The pieces are all kernel-native.

Resource Limits: rctl + cpuset

rctl(8) for resource limits (CPU time, memory, open files, processes) and cpuset for CPU pinning. The equivalent of cgroups, built into the base system.

Container Management: Bastille and Pot

Bastille (1,000 stars, last release February 2026): jail manager with Bastillefiles (think Dockerfile). Zero dependencies, pure shell. Supports thin/thick/empty containers and VNET.

Pot (369 stars, last release March 2025): jail framework with ZFS integration and, critically, a Nomad driver for HashiCorp Nomad orchestration.

The K8s Demo

In August 2023, Doug Rabson posted on Mastodon: a FreeBSD native Kubernetes node running with CRI-O. Single-node, proof of concept, kubectl describe node freebsd0 showing os: freebsd. At the 2024 Developer Summit, he was working on porting kubeadm and kube-proxy to FreeBSD.

That demo has 4 stars on GitHub. Almost nobody knows it exists.

The Gap Is Not Technology: It’s Assembly

Look at the list above. Isolation, OCI compliance, images, storage, networking, resource limits, container management, even a working K8s node demo. All the pieces exist.

What’s missing is someone putting them together into a coherent orchestration layer that:

1. Schedules jail-based containers across multiple FreeBSD nodes
2. Manages networking between them (service discovery, load balancing)
3. Handles storage provisioning via ZFS
4. Provides a declarative API (describe what you want, not how to get it)
5. Monitors health and restarts failed containers

That’s what Kubernetes does on Linux. Not with alien technology: with syscalls, cgroups, and iptables. FreeBSD has equivalent primitives for every one of those.

What I’m Building

I’m starting a POC for a FreeBSD-native orchestrator. Working name: still open. The constraints:

• FreeBSD only. No Linux compatibility layers, no bhyve VMs, no Linuxulator.
• Native primitives. jails for isolation, ZFS for storage, VNET + pf for networking, rctl for resource limits.
• OCI-compatible. Use ocijail as the runtime. Accept standard OCI images.
• Simple first. Single-node scheduler before multi-node. jail.conf generation before custom API servers.
• Real workloads. Run actual services (web server, database, monitoring) not just echo hello.

The goal is not to replace Kubernetes. K8s is a 4-million-line codebase with 10 years of production hardening. The goal is to prove that FreeBSD’s primitives are sufficient for container orchestration, and to document the journey so others can build on it.

Why Now

Three things converged:

1. OCI spec v1.3 (November 2025) gave FreeBSD official standing in the container world. This isn’t experimental anymore: it’s standardized.

2. The EU Cyber Resilience Act (in force since December 2024, full requirements by December 2027) is pushing the entire software supply chain toward SBOM compliance and documented security practices. The FreeBSD Foundation launched a CRA readiness project in February 2026. Organizations that embed FreeBSD need container workflows that are auditable and compliant. Linux isn’t the only option: it just needs to not be the ONLY option with working tooling.

3. Visibility. The people building FreeBSD container infrastructure (Doug Rabson, Dave Cottlehuber, Ed Maste, the Bastille and Pot teams) are doing solid work. But it’s invisible outside the BSD community. 96 stars on ocijail. 4 stars on the K8s demo. A 6-hour tutorial at EuroBSDCon 2024 that most people will never see. The documentation gap is as big as the code gap.

Known Gotchas (Before I Even Start)

Based on the research and what others have hit before me, here’s what I already know will bite:

Rootless is not a thing yet. Everything runs as root. On Linux, rootless Podman is mature and widely used. On FreeBSD, it’s a known gap. For a POC this is acceptable. For production, it’s a problem.

Networking is the biggest blocker. The 2024 Developer Summit identified it repeatedly. VNET gives you per-jail network stacks, pf gives you filtering and NAT, but there’s no equivalent to Linux CNI plugins. No Calico, no Cilium, no Flannel. Inter-jail service discovery and load balancing: you build it yourself. This will likely be the hardest part of the series.

OCI image compatibility has limits. You can run FreeBSD OCI images on FreeBSD, and Linux images via Linuxulator, but you can’t take an arbitrary Docker Hub image and expect it to work. The FreeBSD OCI images are small and official but the ecosystem of pre-built FreeBSD container images is tiny compared to Linux.

Podman on FreeBSD is “evaluation and non-critical production.” That’s a direct quote from the testing report. They found networking stability issues, orchestration integration gaps, and the rootless limitation. Honest assessment from the Foundation: I respect that.

rctl is not cgroups. Resource limits work, but the granularity is different. cgroups v2 on Linux gives you hierarchical CPU/memory/IO control with pressure stall information. rctl is flatter. Whether this matters for a POC: probably not. For production orchestration: it will.

I’ll document each of these as I hit them in practice. Theory is one thing, a running system is another.

What’s Next

This is the first post in a series. The plan:

1. Environment setup: FreeBSD 14.2, ZFS pool, ocijail, Podman. Get a container running.
2. Networking: VNET jails with pf NAT. Inter-container communication. Service discovery.
3. Storage: ZFS datasets as container volumes. Snapshots for rollback.
4. Scheduling: A minimal scheduler that reads a YAML manifest and creates jails across a node.
5. Multi-node: Extending to a second node. Overlay networking.
6. Real workload: Deploy a multi-service application (web + db + cache) and stress test it.

I’ll document everything: what works, what breaks, and what’s missing. If you want to follow along or contribute, the code will be on GitLab.

I maintained Remmina (the Linux remote desktop client) for 9 years and have been working in cloud governance at Kyndryl for over 16 years. I’m not a FreeBSD committer: I’m an infrastructure engineer who thinks FreeBSD deserves better cloud tooling than “just run Linux in a VM.”

If you’ve done work in this space, or you think I’m wrong about something, I want to hear about it.

Sources and references:

• OCI Runtime Spec v1.3 release
• ocijail on GitHub
• FreeBSD OCI Working Group
• FreeBSD Foundation OCI project
• Podman testing on FreeBSD
• Bastille and Pot
• FreeBSD Foundation CRA readiness
• Dave Cottlehuber’s OCI intro
• vermaden: Are FreeBSD Jails Containers?

Antenore Gatta

A proud and busy Hacker, Father and Kyndrol

Post comment