86 lines
3.6 KiB
Markdown
86 lines
3.6 KiB
Markdown
---
|
|
title: "Why FreeBSD for a Homelab"
|
|
date: 2026-03-01
|
|
tags: [freebsd, homelab]
|
|
slug: why-freebsd
|
|
description: "The case for running FreeBSD as the foundation of a homelab — ZFS, jails, pf, clean base system, and the value of good documentation."
|
|
draft: false
|
|
---
|
|
|
|
A few people have asked why I chose FreeBSD for this homelab instead of the usual suspects —
|
|
Proxmox, TrueNAS, some flavor of Linux. The short answer: I wanted to actually understand what
|
|
my infrastructure is doing, and FreeBSD forces that in a way nothing else does.
|
|
|
|
## ZFS Is the Right Filesystem
|
|
|
|
FreeBSD ships ZFS in the base system and it's a first-class citizen. Copy-on-write,
|
|
checksumming, snapshots, send/receive for replication, compression, deduplication. For a
|
|
homelab running storage workloads, ZFS means you actually trust your data is what you think it is.
|
|
|
|
Compare that to the ext4/LVM dance on Linux — it works, but you're stitching together multiple
|
|
tools to get what ZFS gives you out of the box.
|
|
|
|
## Jails Are the Right Way to Isolate Services
|
|
|
|
FreeBSD jails give you lightweight OS-level isolation without the overhead or complexity of VMs,
|
|
and without the moving parts of Docker. A jail is just a restricted process tree with its own
|
|
filesystem view. Predictable, auditable, and you control exactly what it can see.
|
|
|
|
The security model is sound. A compromised service in a jail can't reach the host or other jails
|
|
without explicit configuration. Compare this to a typical Linux container where the security
|
|
boundary depends on which kernel namespaces you've set up correctly.
|
|
|
|
## pf Is the Best Firewall I've Used
|
|
|
|
FreeBSD ships pf — the same packet filter that made BSD firewalls famous. The rule syntax reads
|
|
like English. State tracking is intelligent by default. The whole networking stack hangs together
|
|
coherently.
|
|
|
|
Here's a minimal pf.conf to give a sense of the syntax:
|
|
|
|
```
|
|
set skip on lo
|
|
|
|
block all
|
|
|
|
pass in on egress proto tcp to port { 80 443 } keep state
|
|
pass in on egress proto tcp to port 22 keep state
|
|
pass out all keep state
|
|
```
|
|
|
|
That's readable. You can audit that in two minutes.
|
|
|
|
## The Base System Is Clean
|
|
|
|
FreeBSD ships a complete, coherent base system — separate from ports and packages. No systemd.
|
|
Everything in the base has been considered deliberately and fits together.
|
|
|
|
When I install a service, I know exactly what I'm adding on top of a well-understood foundation.
|
|
On a typical Linux distro, I'm never quite sure what's lurking in the base.
|
|
|
|
## The Documentation Is Accurate
|
|
|
|
The FreeBSD Handbook is one of the best pieces of technical documentation in open source. The
|
|
man pages are maintained by the people who wrote the code. When the Handbook describes how to
|
|
set up ZFS or configure pf, it describes what actually happens.
|
|
|
|
With FreeBSD, the documentation and the system agree with each other. This matters enormously
|
|
when you're learning a new tool or debugging an obscure issue at 2am.
|
|
|
|
## The Tradeoffs
|
|
|
|
FreeBSD isn't the right choice for everything. The package ecosystem is smaller than Linux.
|
|
Some software just doesn't run on FreeBSD, or requires extra effort to get working.
|
|
|
|
For a homelab where the goal is to *understand* the infrastructure rather than just consume
|
|
services, these tradeoffs are worth it. The constraint of a smaller, more deliberate ecosystem
|
|
means you end up with a leaner, more auditable system.
|
|
|
|
If you want a point-and-click hypervisor, use Proxmox. If you want to actually know what your
|
|
firewall is doing and why, FreeBSD is worth the investment.
|
|
|
|
## What's Next
|
|
|
|
The next post covers the hardware — what's actually in the rack and why those particular
|
|
machines. After that, I'll get into the pf configuration and VLAN setup.
|