Why Is Everyone Stuck on FreeBSD 13?

FreeBSD 13.0 shipped on April 13, 2021. Five years and six minor releases later, the branch reached the end of the road: stable/13 and 13.5-RELEASE went end-of-life on April 30, 2026. Since that date, the FreeBSD Security Team publishes no advisories and no patches for any 13.x system. 

And yet 13 is still everywhere: on storage appliances, on firewalls, on that quietly reliable pair of servers nobody has touched since 2022. If you’re running it, you’re not an outlier, and you’re not negligent. You’re the predictable result of how the branch was used and of what the upgrade path actually costs. Let’s walk through how teams end up here, why the way out is steeper than it looks, and what your options are now that the advisories have stopped. 

How You End Up on 13

FreeBSD 13 was a good place to settle. The branch lived five years, produced six minor releases, and covered the era when a lot of infrastructure got built or rebuilt. If you standardized a fleet between 2021 and 2023, you standardized on 13. Within a stable branch, that was a comfortable decision, because minor upgrades preserve the ABI and rarely break anything. 

Products made the same choice. The clearest example is TrueNAS CORE: it is built on FreeBSD 13, and in 2024 iXsystems announced there are no plans for a FreeBSD 14-based TrueNAS. CORE moved into “sustaining engineering” while development shifted to the Linux-based SCALE. Every CORE box in the field is a FreeBSD 13 system with no vendor path to 14. Appliance vendors do this as a rule, not an exception: you certify a base release, you ship thousands of units on it, and each unit is a copy of that release living at a customer site you don’t control. 

That’s the first half of the answer. Nobody decided to run an unsupported OS. They decided, years ago, to run a very well supported one, and the fleet grew around it. 

Why the Next Step Is Bigger Than It Looks

The second half is that leaving 13 is a genuinely larger step than the minor upgrades that preceded it. A major version jump is where FreeBSD spends its accumulated change, and 13 to 14 spends a lot of it: 

• OpenSSL moves from 1.1.1 to 3.0. The base system handles it, but anything you built against deprecated OpenSSL APIs needs attention, and 1.1.1-era software is exactly what a 2021 fleet is full of. 

• Every third-party package must be rebuilt or reinstalled for the new major version. On a machine with a handful of pkg-installed ports, that is routine. With custom-built ports, local patches, or out-of-tree kernel modules, it is a major porting project. 

• Familiar tools are gone. portsnap was retired in favor of git; mergemaster gave way to etcupdate; drivers like amr(4), twa(4), and iscsi_initiator(4) were removed outright. If your hardware or your runbooks depend on any of them, the upgrade stops being mechanical. 

• Defaults shift underneath you: root’s shell, the system mailer, home directory locations. Small things individually; an afternoon of surprises collectively. 

Even when everything goes right, the per-machine choreography is substantial, and from 13 it now runs twice: 

# 13.5 -> 14.4, then the same dance again for 15.1 
$ zfs snapshot -r zroot@pre-upgrade      # rollback point 
$ freebsd-update -r 14.4-RELEASE upgrade 
$ freebsd-update install                 # kernel first 
$ shutdown -r now 
$ freebsd-update install                 # then userland 
$ pkg upgrade -f                         # reinstall every package 
$ etcupdate resolve                      # merge config drift 
$ freebsd-update install                 # remove old libraries 
# validate services, then start over for 15.1 

The FreeBSD Forums are full of what this looks like when it goes wrong: 13-to-14 upgrades wedged mid-flight, systems “caught in boot loader hell,” pkg failing with mystery errors after the jump. Most of these stories end well, but they end well after hours of expert attention, per machine. 

And the target keeps moving. If you’re on 13 today, the current production release is 15.1, which means the realistic jump is two majors. FreeBSD 15 retired the i386, armv6, and 32-bit powerpc platforms entirely. If your fleet includes 32-bit hardware, there is no upgrade, only replacement. 15 also began the pkgbase transition, with the project planning to retire freebsd-update itself by FreeBSD 16 in late 2027. Each cycle you sit out, the gap between where you are and where “current” lives gets structurally wider, not just numerically. 

The Fleet Multiplier

Upgrading one server across a major version is a careful weekend. Upgrading a fleet is a program. Every step that took you an hour on the test box (snapshot, upgrade, rebuild packages, merge configs, reboot, validate) multiplies by the machine count, and then collides with the constraints that fleets actually live under: customer maintenance windows that come twice a year, certification and compliance processes that re-open when the OS major version changes, remote or embedded units where a failed boot means a site visit, and application vendors who validated their software on 13 and haven’t blessed anything newer. 

This is how the trap closes. The fleet was built on a five-year branch, the exit requires touching every machine, and the organization can’t touch every machine quickly. None of that is mismanagement. It’s the standard collision between a release calendar and operational reality. The calendar doesn’t bend, and neither do customer maintenance windows. 

What EOL Actually Costs

Since April 30, 2026, the meter has been running. Every vulnerability disclosed in code that 13 shares with 14 and 15; the supported releases get the patch, 13 does not. Each new advisory adds to the pile, and the longer the migration takes, the taller it gets. The worst version of this story is doing a two-major upgrade under incident pressure, because a CVE forced the timeline. 

Doing nothing also gets more expensive on its own. Klara has documented a case where a product fork that began as three local patches on FreeBSD 12.1 grew to more than 70 changes across the kernel, rc scripts, and base utilities; moving it to 13.2 meant re-porting, retesting, and rebuilding CI for every one of them: an estimated six engineer-months. Unsupported systems accumulate local fixes, and every local fix is a debt the eventual upgrade collects. Now they need to move to 15.1, and pay all of those costs over again. 

There’s a quieter cost too: compliance. Vulnerability scanners and auditors flag an EOL operating system regardless of whether any specific exploit applies to you, and “the vendor no longer patches it” is not an answer that shortens an audit. 

LTS by Klara for FreeBSD

This gap is exactly what LTS by Klara is built for: fleets that cannot move on the project’s schedule, running releases the project no longer patches. The core of the service is extended security patching beyond upstream EOL. Klara backports fixes for base-system and kernel vulnerabilities to branches the FreeBSD Security Officer has retired, and delivers them through modern pkg-base mechanisms, so the application patch workflow your runbooks already describe applies to the OS itself as well. 

Around that core sits the tracking that makes patching meaningful. Klara triages every FreeBSD Security Advisory and Errata Notice and cross-references them against your installed base, producing a concrete exposure list, not a generic bulletin. Where an upstream fix depends on code that has moved on in newer branches, the patch is re-ported to your release and affected packages are rebuilt through poudriere-based pipelines, preserving ABI and KBI compatibility within the branch. Updates are staged with boot environments and nextboot, so a patched image is validated before it becomes the default boot target. Every supported system is tracked against a maintained SBOM and changelog, which provide the audit trail those compliance scanners were asking about. 

LTS is a bridge, not a destination. Klara builds and tests the migration path in parallel with extended support, and works to keep your branch close to mainline: system-level changes are isolated from proprietary logic, and eligible fixes are pushed upstream, so the fleet avoids the fork drift described above. The result is the thing the EOL date took away: the ability to reach a supported release deliberately, on a business timeline, instead of under pressure. 

If your fleet is one of the many still on 13, the honest first step is an inventory: what’s running, what it depends on, and what actually blocks each group from moving. The second step is deciding what protects those machines in the meantime. That’s the conversation we’re here for.