OpenBSD End of Life (EOL) Dates and End of Support (EOS) Dates

Wondering whether your server is still safe to run? OpenBSD end of life works on a short, predictable clock: only the newest builds get fixes, so the OpenBSD release you installed a year ago may already be out of support. This guide shows which versions are covered today, how the project decides, and how to move before the fixes stop.

OpenBSD End of Life Policy and the One-Year Window

The OpenBSD project ships a new version of this Unix-like operating system every six months, with target release dates in May and November. In practice the schedule has settled into spring and October drops, and the team cuts the next one only when the code is ready. Each version then gets about one year of attention before the developers move on, and the developers announce each change of status on the mailing lists.

That year is not a promise written on a calendar by a vendor. It follows from the way the project works: the window is tied to the next two releases. When a new version appears, the one released two cycles earlier loses its maintenance and drops off the list. There are no more fixes for it, no matter how serious a later bug turns out to be.

The result is simple to remember. If your system is on the latest version or the one before it, you are covered. If not, you are running unsupported software, and the only sensible next step is a move to a newer build.

OpenBSD Release Status Table for OpenBSD 8.0, OpenBSD 7.9 and OpenBSD 7.8

OpenBSD 8.0 arrived on 20 October 2026, which immediately pushed OpenBSD 7.8 out of support. OpenBSD 7.9 is the other supported release and stays covered until its successor's successor ships. This is the release date and end-of-support picture as of 27 October 2026; the two future end dates are projections, because the exact day depends on when the next builds land.

Read the table as a rule rather than a list: only the two most recent releases receive security and reliability fixes for the base system. The last updated column of any third-party tracker will tell you the same story, but the project's own announcements are the final word.

Platforms and Hardware Supported by Each Release

Every platform gets the same end date as its release. Every release runs on the same broad set of platforms, from amd64 servers and arm64 boards to older architectures such as sparc64 and powerpc64. That includes small single-board machines like the Raspberry Pi. Your hardware does not change the schedule: a platform with a niche following gets the same one-year window, though a port can be dropped between releases, as happened with Loongson after 7.9.

Older Releases and the May and November Rhythm

Early releases show the original pattern: a version every May and every November, half a year apart. The project later drifted to April and October as development timing shifted, which is why the newer rows above fall in those months. All of these releases have been unsupported for years.

OpenBSD Lifecycle Release Flavors: -release, -stable and -current

Three names show up in every discussion of the OpenBSD lifecycle, and they are the key to reading support status correctly. Together they are the release flavors:

• -release is the build shipped on each cycle, with the number you see in the table above.
• -stable is that release plus the patches published on the errata page. Important fixes are backported into the supported stable branch.
• -current is the development branch. Every six months it is tagged and becomes the next release, and a snapshot of it is available for anyone testing ahead of time.

Machine-readable data helps if you track many hosts: community trackers publish a JSON feed, a CPE identifier (cpe:2.3:o:openbsd:openbsd) and an RSS feed for new advisories, so you can alert on a coming support deadline instead of discovering it afterwards.

Security Support, Errata and Reliability Fixes

The security story, with its strong default security posture, is why many people pick this system in the first place. Among BSD systems it stands out: the developers audit the project's own source tree continuously and integrates cryptography into the base, which makes it a favourite for a firewall or a gateway. That reputation only holds on a supported build, though.

Security fixes arrive in two forms. Security advisories describe a vulnerability and the patch that closes it; the same page covers reliability problems. Both land as patches you can apply to a supported release, and the announcements go out through the announcement mailing list. Subscribe to it, because it is the earliest warning you will get.

Once a release leaves the window, the team stops writing new security support for it. A flaw found tomorrow is fixed in the supported lines and in the development branch, never in your old install.

What Unsupported OpenBSD Systems Risk After EOL

An unsupported machine does not stop working on the morning its release expires. Packages still run, the router still routes and the daily logs still look normal, because the operating system keeps booting happily. The risk is quieter: every new vulnerability found afterwards stays open on your host.

This matters most where the system faces the network. A router, a VPN gateway or a perimeter firewall running past its final fix date is exactly the kind of box an attacker looks for. A small product that embeds an old release has the same problem, and customers rarely know which version sits inside.

Old UNIX installs linger, and the archive of past announcements shows how the team words it. When the 3.4 line closed in 2004 the notice was blunt: there would be no new fixes, and users should upgrade appropriately. The advice has not changed.

Upgrade Before EOL: Migrating to the Next Release

Staying inside the window takes two small habits. First, apply fixes to the release you run. Second, move to the next one when it appears, ideally before the old one runs out. If you are migrating from another system, start from the newest release rather than an older install image.

Applying Fixes with Syspatch

This tool installs the binary security and reliability updates published for your release. Run it regularly, then reboot if it asks you to.

Moving to the Next Release with Sysupgrade

It moves a host near its end date onto a current one: it downloads the next release (or a newer snapshot) and installs it on the next boot. Afterwards, read afterboot in the manual and refresh your packages so they match the new base system.

doas syspatch
doas sysupgrade
doas pkg_add -u

Test the sequence on a spare machine before you touch production, and read the release notes for any step that your hardware needs.

OpenBSD Support Resources: Mailing Lists, Man Pages and Bug Reports

Official OpenBSD support comes from volunteers, and the same channels carry each end-of-support notice, so know where to look before you post. The man pages are the authoritative documentation, and the project expects you to read them first. Next come the mailing list archives, where most questions already have answers. When you find a real bug, send a report with the sendbug tool rather than guessing at a workaround.

The Open Source Roots Behind Each Unsupported Release

The schedule comes from how the project is built. OpenBSD is a free, open source Unix-like operating system in the BSD family. Every part of the software is free to use and redistribute, and the developers fund much of the work themselves, so a volunteer team cannot keep many old branches alive and backs only the newest two. Other BSD systems publish their own support policies, so never assume a FreeBSD or NetBSD date applies here. The Unix tradition values small, audited code over long vendor support contracts, which is why a free Unix like this one expects you to keep pace. In return you get a clear answer to how long a given release lasts, plus security fixes with no licence fees, thanks to the permissive BSD license behind the project's software.

Parts of that BSD code live on in other products and proprietary software, but each reuser, whether a BSD project or a software maker, follows the supplier's own end-of-support schedule, not this one. Treat this free software as a base that you must keep current.