FreeBSD 13 Is End of Life: Your Upgrade Path

FreeBSD 13 is end of life: what that means for your server

FreeBSD 13 reached end of life on April 30, 2026. On that date, both releng/13.5 and stable/13 stopped getting security fixes. The upgrade path from FreeBSD 13 is two major jumps: first 13.5 to 14.4 with freebsd-update, then 14.4 to 15.1. Each jump uses the same steps: install, reboot, install, reinstall every package, then install once more.

The dates in this guide come from the FreeBSD security information page and the release pages, as of October 6, 2026. Check them again before you start, because the project adds releases and end-of-life dates on a fixed schedule. Right now the supported releases are these:

• 15.1-RELEASE, supported until March 31, 2027.
• 15.0-RELEASE, which reached end of life on September 30, 2026. That date has passed, so do not choose it as a target.
• 14.5-RELEASE, supported until June 30, 2027.
• 14.4-RELEASE, supported until December 31, 2026.

The stable/14 branch is supported until November 30, 2028, and stable/15 until December 31, 2029. 15.2-RELEASE is scheduled for December 4, 2026.

A note before you start: SSD Nodes does not offer FreeBSD images. This guide is for readers who run FreeBSD on their own hardware or at another provider. The commands follow the FreeBSD Handbook and the official release notes. We could not run them in our own test containers, because those containers run Linux. Run every command yourself, on a system you have backed up.

Why FreeBSD 13 to 15 is two major jumps

freebsd-update only supports upgrades from the releases that each release page lists. The 15.1 instructions say that systems on 14.4-RELEASE or 15.0-RELEASE can upgrade. The 14.4 instructions accept 13.5-RELEASE or 14.3-RELEASE. No 15.x page lists a 13.x release as a source, so a direct jump from 13 to 15 is not a supported path.

Each major version also has its own ABI (application binary interface). Packages built for FreeBSD:13:amd64 are linked against the version 13 system libraries. When the base system moves to 14, those packages must be replaced with builds for FreeBSD:14:amd64. You do this once per major jump, so you reinstall your packages twice.

Why 14.4 and not 14.5? 14.5 came out on September 8, 2026, which is after 15.1 came out on June 16, 2026. So the 15.1 instructions do not list 14.5 as a source. If you want to reach 15 now, go through 14.4. If you are happy to stay on 14 for a while, 14.5 is supported longer, and 15.2 is the release whose instructions should cover a move from 14.5.

If your server runs 13.4 or older, move to 13.5 first. That is a minor upgrade with the same command: freebsd-update -r 13.5-RELEASE upgrade. 13.5 is past end of life too, so the update servers may stop offering files for it at some point. If freebsd-update cannot fetch the files it needs, use the reinstall path below.

Upgrade in place, or reinstall?

An in-place upgrade keeps your users, your /etc edits and your data where they are. It works well on a plain server with a GENERIC kernel and packages from the official repository.

A fresh install of 15.1 is often the better choice. Reinstall in these cases:

• The machine is 32-bit (uname -m prints i386). FreeBSD 15 dropped i386, so no upgrade reaches 15 on that hardware or VM.
• The system runs a custom kernel, or out-of-tree kernel modules you built yourself.
• /etc holds years of hand edits that nobody remembers. Two config merges in a row on such a system take longer than a rebuild.
• You can create a second server. Build it on 15.1, move the data across, and switch over. The old box stays your rollback until the new one works.

For the rebuild route, setting up a FreeBSD 15 server covers a clean install. If your data lives on ZFS (the Zettabyte File System), ZFS send and receive to a second server moves datasets with their snapshots intact.

The TrueNAS CORE caveat

TrueNAS CORE is built on FreeBSD 13, but it is an appliance, not a general FreeBSD install. Its middleware manages the operating system, and its updates come only through the TrueNAS update process. Do not run freebsd-update or pkg upgrade on it.

iXsystems has not released a CORE version based on FreeBSD 14. Its documentation lists 13.3-U1.2, from April 29, 2025, as the final CORE release, and CORE 13.3 as end of life. The vendor path is the Linux-based TrueNAS Community Edition, and its migration notes say that a move to version 24.10 or later needs a clean install. The other path is a plain FreeBSD 15 install that imports the existing pool. Whichever path you pick, read the ZFS warning below before you touch zpool upgrade.

Before you start: inventory and a rollback point

Record what you have. These commands change nothing.

freebsd-version -kru
uname -m
uname -i
pkg query -e '%a = 0' '%n' > /root/pkg-explicit.txt
kldstat

freebsd-version -kru prints three lines: the installed kernel, the running kernel and the userland. All three should read 13.5-RELEASE with a patch level, for example 13.5-RELEASE-p6. uname -i prints the kernel config name. Anything other than GENERIC means a custom kernel. The Handbook says to keep a GENERIC kernel in /boot/GENERIC and boot it with nextboot(8) during the upgrade. pkg query writes the list of packages you installed on purpose, which is useful if a forced reinstall fails partway. kldstat lists loaded kernel modules, and any module that came from a port must be rebuilt for each new kernel.

Then back up configuration and create a rollback point:

tar czf /root/etc-backup-13.tgz /etc /usr/local/etc
bectl create pre-14
bectl list

bectl manages ZFS boot environments, which are bootable clones of the root file system. bectl list should show pre-14 next to your active environment. If the root file system is UFS (Unix File System), bectl does not work. Take a snapshot at your provider, or a full backup, instead. How ZFS snapshots, clones and rollback work explains what a boot environment can and cannot undo.

Step 1: patch 13.5 fully

freebsd-update fetch
freebsd-update install

Fixes to freebsd-update itself ship as errata, so the tool on an unpatched system can be the broken part. The 15.0 instructions show why this matters: they warn that upgrading without the FreeBSD-EN-25:18.freebsd-update errata "will result in an inoperative system". Patch the release you are leaving before you ask the tool to leave it.

Step 2: freebsd-update -r from 13.5 to 14.4

freebsd-update -r 14.4-RELEASE upgrade

The tool downloads the new release and compares it with your files. It then merges configuration files. Where your edit and the new default touch the same lines, it opens an editor with conflict markers. Read each diff. FreeBSD 14 changed defaults that a merge can propose. root uses sh as its default shell instead of csh, and dma replaced sendmail as the default mail agent. Keep the lines you rely on, and remove every conflict marker before you save.

Now run the install, reboot, install sequence:

freebsd-update install
shutdown -r now

The first install puts only the new kernel in place. After the reboot, freebsd-version -kru should show 14.4-RELEASE for the two kernel lines and 13.5-RELEASE for userland. That mix is expected at this point. Continue:

freebsd-update install

This second install puts the 14.4 userland in place. freebsd-update saves its state between runs, so it continues from the next phase and does not start again from the beginning. Old shared libraries stay on disk for now, so your 13.x packages can still start.

Reinstall every package for the new ABI

pkg-static upgrade -f

-f forces a reinstall of every package, even when the version number did not change. You need that because the package name and version stay the same while the ABI underneath it changes. A plain pkg upgrade sees nothing newer and leaves the old builds in place. pkg-static is the statically linked copy of pkg, so it does not depend on the system libraries that are changing under it.

If pkg prints Newer FreeBSD version for package, the running kernel is older than the packages. That means you skipped the reboot. Reboot into the new kernel, then run the command again.

If you build from ports, two things changed. portsnap was retired, and the ports tree now comes from git:

pkg install git
git clone --depth 1 https://git.FreeBSD.org/ports.git /usr/ports

Then rebuild everything you built from ports, including kernel modules such as graphics drivers. A module built for the 13 kernel will not load into the 14 kernel.

Finish the jump:

freebsd-update install
shutdown -r now
freebsd-version -kru
pkg check -d -a

The last install removes the old 13.x libraries. After the reboot, all three freebsd-version lines should read 14.4-RELEASE. pkg check -d -a checks every package for missing dependencies, and a healthy system reports none. Now start your services and test them before you continue. If a service fails here, you know the 13 to 14 jump caused it.

What else breaks when you leave FreeBSD 13

Klara Systems, a FreeBSD consultancy, lists the changes that catch people leaving 13. These are the ones to check on a server:

• OpenSSL moves from 1.1.1 to 3.0. Packages from the official repository are already built against it. Your own software that links against the base OpenSSL needs a rebuild, and code that uses APIs (application programming interfaces) deprecated in 3.0 may need changes. openssl version should report a 3.0 version on 14.
• portsnap is gone. Scripts and cron jobs that call it now fail with a not-found error. Replace them with git -C /usr/ports pull.
• mergemaster is retired. etcupdate replaces it for systems built from source. If you use freebsd-update, it already does the merge for you.
• Some old drivers were removed, among them amr(4), twa(4) and iscsi_initiator(4). Check kldstat and dmesg for them before you upgrade. iSCSI clients use iscsid and iscsictl instead.

Step 3: freebsd-update -r from 14.4 to 15.1

The second jump repeats the same steps with a new target. Patch 14.4 first:

freebsd-update fetch
freebsd-update install
bectl create pre-15
freebsd-update -r 15.1-RELEASE upgrade
freebsd-update install
shutdown -r now

After the reboot:

freebsd-update install
pkg-static upgrade -f
freebsd-update install
shutdown -r now

freebsd-version -kru should then read 15.1-RELEASE on all three lines.

Check these before this jump:

• 32-bit platforms are gone. FreeBSD 15 retired i386, armv6 and 32-bit powerpc. On amd64, 32-bit programs still run through the compatibility layer, so only the platform is affected. An i386 system stays on 14 (stable/14 is supported until November 30, 2028) until you reinstall it as amd64.
• OpenSSL moves again, to 3.5 in 15.0. Rebuild your own OpenSSL-linked software a second time.
• OpenSSH is 10.0 or newer, and OpenSSH 10.0 removed DSA keys. Search authorized_keys files for ssh-dss before you reboot, or that login stops working.
• Kerberos is now MIT Kerberos in base, in place of Heimdal. This matters only if you use Kerberos.

Where pkgbase changes the picture

FreeBSD 15.0 added pkgbase as a technology preview. With pkgbase, the base system itself is a set of packages, managed by pkg instead of freebsd-update. The installer offers it as an option.

A system you upgraded with freebsd-update is still a freebsd-update system on 15.1. Keep using freebsd-update fetch install for its patches. Nothing in this guide converts it.

If you install with pkgbase, or convert later, the commands change. The 15.1 release notes give separate instructions for pkgbase systems: they start with pkg upgrade -r FreeBSD-base, and they do not use freebsd-update. Follow those notes on such a system. The FreeBSD Foundation publishes a conversion tool, pkgbasify. Its README says the tool and pkgbase are both experimental, and that running it "may result in irreversible data loss and/or a system that fails to boot". Convert only after a backup, and not in the same maintenance window as the jump to 15. Klara reports that the project plans to retire freebsd-update by FreeBSD 16, so a conversion is in your future either way.

ZFS: do not run zpool upgrade yet

After each jump, zpool status prints a message like this for your pools:

status: Some supported and requested features are not enabled on the pool.

This is not an error. The new OpenZFS knows about features your pool does not use yet. The pool works as it is. Leave it alone for now, for two reasons.

The boot loader must understand the pool first. zpool upgrade turns on new on-disk features. The boot loader reads the pool before any kernel runs, and an old loader that meets a feature it does not know stops the boot. It prints a line that starts with ZFS: unsupported feature:. freebsd-update updates the files in /boot, but the boot code your firmware actually runs is a separate copy. It sits on the EFI system partition, or in the freebsd-boot partition on BIOS systems. That copy is only updated when you update it yourself.

An upgraded pool ends your rollback. The pre-14 boot environment runs a 13.5 kernel. That kernel cannot import a pool with features it does not know, so after zpool upgrade, rolling back to it no longer works.

Upgrade the pool only after these four checks:

1. The new release has run well for long enough that you will not roll back.
2. You know your boot method. On amd64, sysctl machdep.bootmethod prints UEFI or BIOS.
3. You updated the boot code for that method. Follow the FreeBSD Handbook and the manual pages it points to (gpart(8), gptboot(8), gptzfsboot(8) and loader.efi(8)). The right command depends on your partition layout, so take it from them and not from a blog post.
4. No older system has to import this pool. A TrueNAS CORE box or a 13.x backup server cannot read features it does not know.

zpool upgrade with no arguments only lists pools that have features to enable. It changes nothing. Many pools never need the upgrade at all. The ZFS settings you cannot change later explains why a feature, once active, is permanent. How ZFS differs on FreeBSD and Linux matters if a Linux system will ever import the pool.

Rolling back when a step fails

On a ZFS root, return to the boot environment you made before the jump:

bectl activate pre-14
shutdown -r now

This works as long as you have not run zpool upgrade. On UFS, freebsd-update rollback undoes the most recent install. It cannot undo a forced package reinstall, so your provider snapshot or backup is the real rollback there.

After the upgrade: stay on a supported release

15.1 is supported until March 31, 2027, so plan the minor move to 15.2 after its release in December. Minor upgrades within 15 keep the same ABI, so they do not need a forced package reinstall. To get advisories by email and apply them in time, read how FreeBSD security advisories and errata reach your server.

If this end-of-life date made you ask whether to stay on FreeBSD, the Linux versus FreeBSD comparison for servers sets out the trade. The same problem exists on Linux, and the Debian 11 end-of-life upgrade path also takes two release jumps.

FAQ

Can I upgrade directly from FreeBSD 13 to FreeBSD 15?

No supported path does that. The 15.1 instructions accept only 14.4-RELEASE or 15.0-RELEASE as a source for freebsd-update. Upgrade from 13.5 to 14.4 first, reinstall your packages, then upgrade from 14.4 to 15.1 and reinstall them again. If the system is i386, it cannot reach 15 at all, because FreeBSD 15 dropped that platform.

Is it safe to keep running FreeBSD 13 after April 30, 2026?

FreeBSD 13 gets no more security advisories or patches from the FreeBSD Security Team after April 30, 2026. A newly found flaw in OpenSSH or the kernel will stay unfixed on that system. The system will keep running, but every month adds known problems that nobody fixes for you. Upgrade it, or reinstall it on a supported release.

Why do I have to reinstall every package after freebsd-update?

Each FreeBSD major version has its own ABI, and packages are built against one version's system libraries. After the base moves from 13 to 14, the package names and versions stay the same, so a plain pkg upgrade changes nothing. Run pkg-static upgrade -f to force a reinstall of every package from the repository for the new version. Then run the final freebsd-update install that removes the old libraries.

When is it safe to run zpool upgrade after the upgrade?

Run it only after you have updated the boot code for your boot method, and only when you will not roll back. An old boot loader cannot read new pool features and stops the boot. An old kernel cannot import the upgraded pool, so the boot environment you made before the upgrade stops working. Check sysctl machdep.bootmethod, then follow the FreeBSD Handbook for that boot method.

Can I upgrade TrueNAS CORE with freebsd-update?

No. TrueNAS CORE is an appliance whose middleware manages the operating system, and iXsystems released no CORE version based on FreeBSD 14. Its final CORE release is 13.3-U1.2. Your choices are to migrate to the Linux-based TrueNAS Community Edition, which needs a clean install for 24.10 or later, or to install plain FreeBSD and import the pool. Do not run zpool upgrade until you have chosen.