There’s a real difference — wider than most people expect — between software that passes its tests and software that has actually been used. The first kind is clever. The second kind is wise, and it earned that wisdom the hard way. ocifbsd got the second kind of education, because early on we made a decision that turned out to matter more than almost any other: we made it run something real, something unforgiving, something that would embarrass us in public if it broke. Namely, the very website you’re reading. Dogfooding — running your own tool in earnest, as a customer rather than an author — is far and away the fastest way to find the gap between “works in the demo” and plain old “works.”
A real app asks the hard questions
WordPress is not a toy workload, and that’s exactly why it was the right choice. It wants a web server, a PHP runtime, a database, and a cache — all networked together, and all quietly assuming they’re running on a perfectly normal machine that behaves the way machines have always behaved. Standing that whole stack up on ocifbsd immediately surfaced a stack of things a cheerful little hello-world container would never in a million years reveal.
Services that needed devfs present, and sulked without it. A database that was only reachable if the network overlay got applied at exactly the right moment — not a moment later. A PHP process that simply assumed a working loopback interface and fell over when it didn’t find one. And here’s the crucial bit: every single one of those became a fix in the runtime rather than a grubby workaround buried in the app’s config. That is the entire point of dogfooding, distilled. The pain lands somewhere you can fix it permanently, for everyone, instead of somewhere you have to keep apologizing for.
Features that exist only because the site demanded them
Some of ocifbsd’s most genuinely useful capabilities exist for one reason and one reason only: this deployment stood up, crossed its arms, and demanded them. The stats command was born straight out of wanting the site to display its own live resource usage — and now that same JSON feed drives the Machine Room dashboard and the cluster map you can go poke at right now. The proxy grew its algorithms, its sticky sessions, and its multi-worker accept pool under the real, sweaty pressure of actually balancing cluster traffic, not in a vacuum where we guessed at what might someday be nice. The networking fixes came from two containers that genuinely, urgently needed to talk to each other and couldn’t.
None of it was speculative. None of it was a feature added because a roadmap said so or because it would look good on a slide. Every bit of it was pulled into existence by a running system that wanted it — which, if you ask me, is the best possible reason for any feature to exist. Necessity is a far better product manager than imagination.
The site as a test that never clocks out
And here’s the part I like best of all: the dogfooding never stops. This site stays up. Which means ocifbsd is under continuous, honest, unblinking evaluation — not a test suite that runs for ninety seconds and then exits satisfied, but a living workload that has to keep serving correct pages, keep migrating sessions between nodes, keep reporting accurate stats, day after day after day, whether or not anyone’s watching.
When something regresses, a real website breaks — visibly, publicly, right now — and that is a feedback loop no amount of unit testing on Earth can replace. There’s no hiding from a broken homepage. The runtime got sharper precisely because it always had something to prove, out in the open, all the time, with the stakes real. That, in the end, is what “forged by dogfooding” actually means. Not a slogan — a standing dare.