As of November 2026, the current release is 15.1-RELEASE (June 16, 2026), supported until March 31, 2027. The conservative choice is 14.5-RELEASE (September 8, 2026), supported until June 30, 2027. The 15 branch is supported until December 31, 2029 and the 14 branch until November 30, 2028 — but an individual minor release is only supported for three months after the next minor release on the same branch. That is the rule that catches people: 15.0-RELEASE, from December 2025, already reached end of life on September 30, 2026, and FreeBSD 13 reached end of life on April 30, 2026. Pick a release, then put its end-of-life date in your calendar the same day.
15.2-RELEASE is due December 8, 2026. If you install 15.1 this week, plan the move to 15.2 as part of the same exercise, not as a surprise in January.

On Linux, the distribution is the system. On FreeBSD, the base system — kernel, libc, the shell, the network stack, the firewall, the tools in /bin and /usr/bin — is one thing, developed and released together. Everything else is a package or a port. That split explains almost every difference below: the base system is coherent and documented as a whole, and third-party software lives in its own world, installed from the ports tree or as prebuilt packages, and never mixed into the base.
FreeBSD 15 adds pkgbase — the base system itself installable and updatable as packages, as an alternative to the older freebsd-update tool, which the project plans to remove in future. On 14.x, freebsd-update is still the way. Either way, the habit to keep from RHEL is the same: know which layer a file belongs to before you edit it, and never hand-edit a file the base system owns.

ZFS on FreeBSD is not a module you load and hope about. It is a first-class part of the system: the installer offers it, the boot environment lives on it, and the tooling assumes it. One system gives you a filesystem and a volume manager together — checksummed data that catches silent corruption instead of trusting the disk, instant snapshots, cheap clones, and zfs send / zfs receive to ship a filesystem to another machine byte for byte.
The three commands that pay for the learning curve: zfs snapshot zroot/ROOT/default@before-upgrade before any change you might regret, zfs rollback zroot/ROOT/default@before-upgrade when you do regret it, and zpool status when something feels wrong with a disk. FreeBSD 15 ships OpenZFS 2.4, including block cloning — copy a file and the filesystem shares the blocks until one copy changes, instead of duplicating them.
The Linux comparison, honestly: ZFS on Linux works, and on a modern RHEL box it works well. What FreeBSD gives you is not a different ZFS, it is ZFS without the friction — no DKMS rebuild after every kernel update, no wondering whether the module matches the kernel, no separate project to track. If ZFS is the reason you are here, that absence of friction is the whole argument.

A jail is a directory tree plus a few lines of configuration, running real FreeBSD userland against the host kernel, with its own files, processes, hostname, and IP address. If that sounds like a container, it is — jails predate Docker by more than a decade, and they are simpler, because there is no image layer, no daemon, and no registry in the way. The tools are jail, jls, and jexec, and they are already installed.
A minimal jail, roughly: create a dataset for it (zfs create zroot/jails/web), unpack the base system into it (tar -xf base.txz -C /jails/web), add a few lines to /etc/jail.conf naming it, and start it with service jail start web. jls lists it, jexec web /bin/sh puts you inside it, and root inside the jail cannot load kernel modules, cannot see the host’s processes, and cannot escape by writing to the host’s filesystem — the kernel belongs to the host, and the jail knows it.
Jails and ZFS are better together: a jail per dataset means a jail can be snapshotted, cloned, and rolled back exactly like any other filesystem. Clone a jail to test an upgrade, break the clone, throw it away. FreeBSD 15 also adds file-descriptor-based jail operations, closing a long-standing race where a jail could be destroyed and recreated with the same ID between a lookup and an action.
The Linux comparison, honestly: jails do not do what Docker does — there is no ecosystem of prebuilt images, no Compose file to download, no registry to pull from. What they do is isolation with almost no moving parts, for services you run yourself. If your mental model is “a VM, but lighter,” a jail is closer to “a chroot that the kernel actually enforces.”

pf is in the base system, configured in /etc/pf.conf, and its rules read almost like sentences: block in all, pass out all keep state, pass in on em0 proto tcp to port ssh. Enable it with pf_enable="YES" in rc.conf, load the rules with pfctl -f /etc/pf.conf, and inspect them with pfctl -s rules. That is the whole workflow, and the rule file is the documentation.
The Linux comparison, honestly: nftables is more powerful and more widely deployed on Linux, and firewalld is what your RHEL boxes actually run. pf is not more powerful. It is more readable, and readability is a security property — a firewall rule you can read at 2 a.m. is a firewall rule you are less likely to get wrong.

Where it wins: ZFS without friction. Jails for lightweight isolation with no daemon. pf for readable firewalling. A coherent base system with one manual — the FreeBSD Handbook is genuinely the best documentation in open source, and reading it is the fastest way to learn the system. And stability: a base system that changes as a whole, on a published schedule, with security advisories you can actually follow.
Where it does not: hardware and driver coverage, especially laptops and brand-new server hardware — Linux gets drivers first, and it is not close. Commercial software: if a vendor ships a Linux binary and nothing else, you are running it under Linux binary compatibility, which works more often than you would expect and is still a compatibility layer, not a promise. VPS images: fewer hosts offer FreeBSD than Linux, so check before you order, and be ready to install it yourself from an ISO where it is not offered. And the ecosystem: the ports tree is large, but it is not the RHEL/Debian package universe, and some niche tool will be missing, or a version behind.
The Linux binary compatibility note, because someone will ask: FreeBSD can run many Linux binaries, and for a single closed-source agent or tool that is often enough. It is not a reason to choose FreeBSD for a Linux workload. If the workload is Linux, run Linux.

1. A VM first, with ZFS as the disk layout — that is the configuration the installer expects, and it is where the snapshot and boot-environment habits form. Install 15.1, not 15.0 (end of life) and not 13 (end of life).
2. Put one real service in a jail — nginx, or a small internal tool — and snapshot the dataset before you upgrade it. That single loop, jail plus snapshot plus rollback, is the whole FreeBSD server story in miniature.
3. Read the Handbook’s ZFS and jails chapters before you improvise. They are short, they are accurate, and they will save you from relearning, by trial and error, things the project already wrote down.
4. Only then ask the VPS question. Some hosts offer FreeBSD images, some do not, and the answer changes by provider and by month — check the host’s image list before you plan a migration around it.

FreeBSD is not a secret, and it is not a curiosity. It is a complete Unix that never tried to be Linux, and the things it does well — ZFS, jails, pf, a coherent base system, documentation you can trust — it does as well as anything in the field. The things it does poorly are real too, and they are mostly about breadth: drivers, commercial software, and how many hosts will hand you an image. A Linux sysadmin who learns FreeBSD does not become a FreeBSD sysadmin. They become a sysadmin with a second way of thinking about the same problems — and on the day the Linux way is the wrong tool, that second way is worth having.