Let me tell you a small secret about the page you’re looking at: it’s here to win an argument. Not a loud one — there’s no manifesto, no flame war — just a quiet, stubborn claim that a lot of people assume is false. The claim is this: you don’t need Linux, and you don’t need a big background daemon shepherding everything, to run real, modern, containerized applications. You need an operating system that already knows how to fence off processes, hand out private networks, and count who’s using what. FreeBSD has known how to do all three for years. Everything you’re reading right now is served from exactly that stack, and it’s the evidence.
So what’s actually humming away underneath?
On the surface, nothing exotic. This is an ordinary WordPress site: PHP-FPM does the thinking, MariaDB remembers everything, Redis keeps the fast-moving bits close at hand, and Nginx greets you at the door. If you’ve run a website before, you know this cast of characters. What’s unusual is the stage they’re standing on. Every one of those services lives inside a native OCI container built and babysat by ocifbsd, a runtime that takes the Open Container Initiative model — the same shape of images and containers you’d recognize anywhere — and maps it cleanly onto FreeBSD’s own building blocks.
Here’s the fun part, the bit that makes an old FreeBSD hand grin. An image becomes a jail. A pod network becomes a VNET — a genuine, private network stack — wired up to a bridge. A resource limit stops being a polite suggestion and becomes a RACCT rule the kernel enforces directly. There’s no compatibility shim in the middle, no layer quietly pretending to be Linux so the tools upstairs don’t panic. There’s nothing to pretend to be. It’s FreeBSD all the way down, doing what it was already good at.
Two shapes, one story
The same application runs here in two different shapes, and I’d encourage you to think of them as two chapters of one story rather than two separate demos. The first shape is a single FreeBSD VM where all the containers share one host — compact, tidy, the entire platform folded into a single box you could carry in your pocket if pockets held virtual machines. The second is a three-node cluster with a native load balancer standing out front, a shared session store so a visitor can bounce from node to node without noticing, and one database of record sitting calmly behind them all.
The single site is the “does this even work?” answer. The cluster is the “okay, but does it scale?” answer. Both are live, both are public over HTTPS, and — this is my favorite detail — both can describe themselves. Open the dashboard under “The Machine Room” and you’re watching real resource accounting streamed out of the very jails that are, at that exact moment, rendering the page you’re reading. The site isn’t telling you a story about some other system. It’s pointing a camera at itself.
Why go to all this trouble?
Fair question. The honest answer is that the container ecosystem grew up assuming one particular kernel, and that quiet assumption cost the BSDs a seat at a table they were, frankly, architecturally ready for. Jails predate a good chunk of the isolation machinery the container world would later reinvent with great fanfare. So the thing that was missing was never capability. It was ergonomics — the smooth pull, build, run, network, observe rhythm that people now simply expect from a container platform. That gap, that missing sense of “oh, this just feels nice to use,” is precisely what ocifbsd sets out to close.
The rest of these posts are the guided tour. We’ll teach containers to talk to each other over the network, drop a load balancer into the toolbox, make sessions follow you from node to node, and then — because talk is cheap — deliberately try to knock the whole thing over with a stress test. You can start anywhere; each post stands on its own. Just know that whatever page you land on, it’s turtles all the way down. Jails, really. But you get the idea.