What is OpenBSD, and why is it considered one of the most secure OSes?

If you’ve provisioned a VPS and picked OpenBSD instead of the usual Ubuntu or Debian image, you might be wondering what you’ve actually got. The short answer: something quite different from Linux, built by a small team with a very specific obsession – correctness and security, ahead of features or convenience.

A different family tree

OpenBSD isn’t a Linux distribution. It’s a BSD – descended from the Berkeley Software Distribution lineage, not from Linus Torvalds’ Linux kernel. Theo de Raadt started the project on 18 October 1995 after a falling-out with the NetBSD core team, forking from NetBSD 1.0. The first release, OpenBSD 1.2, shipped in July 1996. Three decades on, it’s still developed by a small, tight-knit team who release on a strict six-month cycle – typically May and November each year. The current release at the time of writing is OpenBSD 7.9, released May 2026.

That release cadence matters. Every six months the entire base system – kernel, userland, documentation – is frozen, tested, and shipped together as one coherent unit. There’s no separate “distro” layering packages on top of somebody else’s kernel; the OpenBSD team controls the whole stack, top to bottom.

Secure by default, not secure after hardening

Most operating systems ship reasonably open and expect an administrator to lock them down afterwards – disable unused services, tighten permissions, apply a hardening guide. OpenBSD flips that around. A default, freshly installed system runs almost nothing listening on the network, ships with sensible file permissions out of the box, and has never enabled a service you didn’t explicitly ask for.

This “secure by default” philosophy is backed up by a set of practices the project has stuck to for decades:

• Continuous code auditing. The team reads through the source tree looking for bugs, unsafe patterns, and logic errors – not just responding to reported vulnerabilities, but actively hunting for them before anyone else finds them.
• Mitigations built into the base system. Techniques like stack protection, address space layout randomisation, and W^X (memory pages are never simultaneously writable and executable) are enabled throughout the system by default, not offered as opt-in extras.
• Minimalism. If it isn’t needed, it isn’t installed. A smaller base system means a smaller attack surface and less code that could hide a bug.
• Correctness over cleverness. The project has a low tolerance for code that “mostly works.” Bugs get fixed properly rather than patched around.

The track record

For years OpenBSD’s own website carried a line that became something of a badge of honour in the security world: “Only two remote holes in the default install, in a heck of a long time.” It’s a slightly cheeky claim, but it reflects something real – over more than a decade, the default install (before you add any third-party services) had an exceptionally small number of remotely exploitable vulnerabilities, largely thanks to the auditing discipline above. That’s not a guarantee nothing will ever be found, but it says a lot about the priorities baked into the project.

Its most famous export: OpenSSH

If you’ve ever typed ssh on any Unix-like system, Windows machine, or macOS – you’ve used something the OpenBSD project built. OpenSSH began in 1999 when OpenBSD developers forked an early, more restrictively licensed SSH implementation, audited and rewrote large parts of it, and shipped the result with OpenBSD 2.6 in December 1999. It’s still developed and maintained by the OpenBSD team today, with a separate “portable” release maintained for use on Linux, macOS, and everywhere else. It is, without much argument, the standard way the world does secure remote login – and it came out of exactly the same auditing culture described above.

Where OpenBSD makes sense on a VPS

OpenBSD isn’t trying to be your general-purpose application server. It earns its keep in roles where a small, hardened, predictable attack surface matters more than a huge ecosystem of pre-packaged software:

• Firewalls and routers – OpenBSD’s pf packet filter (later ported to FreeBSD and macOS) started life here, and it’s a natural fit for edge/gateway roles.
• Mail servers – OpenSMTPD, also an OpenBSD project, gives you a mail transfer agent designed with the same security priorities.
• DNS servers – a minimal, well-audited base system is exactly what you want fielding untrusted queries from the open internet.
• Anywhere you want a genuinely minimal, hardened box – a jump host, a VPN endpoint, a reverse proxy sitting in front of something more fragile.

The trade-offs, honestly

None of this is free. Be realistic about what you’re taking on:

• Smaller hardware and driver support. OpenBSD supports far fewer platforms and peripherals than Linux – rarely an issue on a standard VPS, but worth knowing.
• Smaller software ecosystem. The ports and packages collection is good but nowhere near as vast as what you’ll find in the Linux world. Some software simply isn’t packaged for OpenBSD.
• A steeper learning curve for most admins. Command names, configuration file locations, and defaults often differ from Linux in small but important ways – pkg_add instead of apt, doas instead of sudo, pf.conf instead of iptables. Muscle memory from Linux doesn’t transfer directly.

If you want a box that does one job, does it with a minimal footprint, and has decades of auditing discipline behind it, OpenBSD is a genuinely strong choice. The rest of this series covers the practical basics – creating users, installing packages, and configuring the pf firewall – to get you comfortable running it day to day.