A Reddit thread this week asked the question directly: why are you using FreeBSD? Seventy-three upvotes, eighty-one comments, and a surprisingly coherent set of themes emerged from the replies. Having built infrastructure on FreeBSD for the better part of two decades, I read through the thread twice and came away agreeing with most of it.
The answers split into three categories -- technical discipline, ecosystem coherence, and operator experience. Each deserves a moment.
Technical Discipline
FreeBSD draws a clean line between base system and ports. The base is the kernel, the core utilities, libc, the C compiler, the system configuration framework -- all developed and versioned together in one tree. Ports and packages are everything else. That separation sounds obvious until you have spent years on Linux distributions where the line is blurred, contested, or actively erased by upstream packaging choices. On FreeBSD, when a component breaks, you know whether it is a base-system problem or a ports problem, and that knowledge changes how you debug.
ZFS is part of base. Jails are part of base. bhyve is part of base. DTrace is part of base. These are not add-ons or optional layers pulled in from third parties -- they are first-class citizens developed in tree with the kernel. The practical result is that when you build a FreeBSD host, the features that matter for production workloads are already present, already integrated, and already maintained by the same people who ship the kernel. There is no separate project coordinating the lifecycle of your filesystem against your container runtime against your hypervisor. It is all one thing.
Ecosystem Coherence
Documentation is the second thing the thread keeps returning to. The FreeBSD Handbook is comprehensive, accurate, and current in a way that most documentation projects simply are not. When I need to refresh my memory on jail configuration, rc.d conventions, or sysctl tunables, the Handbook is where I go first and the answer is nearly always there. Man pages receive the same treatment -- actively maintained, version-accurate, and written with the assumption that the reader is an engineer who needs real information.
That level of documentation culture is not an accident. It reflects a community that prioritizes writing things down, that treats documentation as part of the release process rather than an afterthought. It is one of the reasons FreeBSD keeps producing competent operators -- the path from beginner to capable is paved.
Operator Experience
The boring reason, and perhaps the most important: FreeBSD does not surprise me. Upgrades are predictable. Configuration is declarative and lives in plaintext files I can diff across machines. The operating system behaves consistently across major versions. When I come back to a FreeBSD system after six months, the mental model still fits. rc.conf still controls services. sysctl still tunes the kernel. pf still filters packets. The knowledge I had in 2015 is largely the knowledge I need in 2026.
That consistency is underappreciated in the wider industry. We have normalized the idea that infrastructure tooling will churn every eighteen months -- new init systems, new package managers, new configuration abstractions, new orchestrators. FreeBSD opts out of most of that churn. The result is a system that rewards long memory and punishes no one for running the same stack for a decade.
The Bottom Line
The Reddit thread has dozens of variations on these three themes, but the underlying message is the same. People use FreeBSD because it respects their time. The base system is small. The documentation is accurate. The mental model holds up. When you have built a career on operating other people's systems, those three properties are worth more than any single feature.
The full Reddit discussion is worth reading for the range of use cases -- from single-operator shops running FreeBSD on a Pi to hyperscalers using it as a foundation for purpose-built systems.
Thinking about FreeBSD for production? Learn about our FreeBSD systems engineering services or schedule a consultation.