Here’s a thing that’s easy to take for granted: where do container images actually come from? For a lot of people the answer is a shrug and a pull command — images arrive from somewhere far away as finished, sealed black boxes, and you just trust that whatever’s inside is fine. The images behind this site don’t work like that. They’re not delivered; they’re assembled, right here on FreeBSD, from a recipe short enough to read over a cup of coffee. This is the story of ocifbsd build — the command that lets the platform construct the very containers it later turns around and runs.
A recipe you’ve probably read before
If you’ve ever written a Dockerfile, the recipe here — we call it a Containerfile — is going to feel like running into an old friend. There’s a FROM line to pick your starting point. There are RUN steps to install and configure software. There’s COPY to bring your own files aboard, and ENV, WORKDIR, and CMD to describe how the finished thing ought to wake up and start working. Same grammar, same muscle memory.
The difference is what’s underneath the words. The base here is the official FreeBSD OCI image, so when a RUN pkg install line goes fetching nginx, php, mariadb, or redis, it’s pulling honest-to-goodness FreeBSD packages — the real thing, compiled for this system, not Linux binaries wearing a clever disguise and hoping nobody checks their ID. What you install is what you get.
What really happens when you hit “build”
Let’s peek behind the curtain, because this is where it gets satisfying. Each RUN step doesn’t just execute in some vague sandbox — it runs inside a chroot of the image as it exists so far, with devfs mounted so the tools have the device nodes they quietly expect to find. When the step finishes, that devfs gets unmounted again, cleanly, no mess left behind. Step by step, the image grows.
And building on top of an image that already exists — the classic “I just want to rebuild this thing” scenario — is handled with the same care. Files carrying the immutable schg flag are gently unwound first, and any stale devfs mounts left over from before are torn down before the new build begins. The upshot is that a second build is every bit as clean as the first one; you don’t accumulate weird ghosts from previous attempts. What pops out the other end is a completely normal ocifbsd image — tagged, stored under the local registry path, and ready to run, indistinguishable from anything you might have pulled from elsewhere.
Why building it here, on-platform, actually matters
You could reasonably ask: who cares where the image is built, as long as it runs? Here’s the case for caring. A container platform that can only consume images somebody else made is, honestly, only half a platform. It’s a player that can’t cook, only microwave. By building on FreeBSD, from FreeBSD packages, the entire supply chain stays native and stays inspectable. There’s no cross-build step to squint at, no emulation layer humming along in the background, and no mystery meat about what’s actually inside the thing you’re about to expose to the internet.
So when the Machine Room dashboard casually reports that the WordPress jail is running local/wordpress:latest, that’s not a label pointing off into the distance. That image was born on this same machine, from a recipe living in the repository, assembled by the very same tool that’s now supervising it as it serves you this page. The site, quite literally, builds itself — and then, because we thought you’d enjoy it, turns around and tells you all about it.