OpenBSD on a VPS: The Most Secure OS Nobody Uses

OpenBSD has had two remote vulnerabilities in its default install in nearly 30 years. Two. The entire Linux ecosystem has more CVEs in a busy month than OpenBSD has accumulated in its lifetime.

It's the most security-obsessed operating system in production. It's also the one almost nobody deploys on a VPS. Here's why that's a mistake for certain workloads.

OpenBSD is not for everyone. It's not trying to be. It doesn't have the package ecosystem of Ubuntu, the enterprise support contracts of RHEL, or the market share of literally any Linux distribution. What it has is a nearly three-decade track record of code auditing, proactive security, and a development philosophy that treats every line of code as a potential attack surface.

If you've been searching for an OpenBSD VPS but aren't sure whether it's the right choice, this guide covers what makes OpenBSD different, which workloads it excels at, where it falls short, and how to deploy an OpenBSD VPS server without fighting your hosting provider.

What Makes OpenBSD Different?

Every Linux distribution markets itself as "secure." OpenBSD doesn't market itself at all. It just ships an operating system where security is the default, not an add-on.

The difference is architectural. On Linux, security is typically layered on top: you install the OS, then configure a firewall, then set up SELinux or AppArmor, then harden SSH, then apply CIS benchmarks. Each layer is optional. Each layer can be misconfigured. Each layer is maintained by different people with different priorities.

On OpenBSD, security is the base layer. The defaults are locked down. The code is continuously audited. The development team has consistently chosen security over features, performance, and compatibility when those goals conflict. That's a trade-off most projects aren't willing to make.

pledge() and unveil(): Security That's Actually Usable

These two system calls are the reason security engineers get excited about OpenBSD, and they're the reason an OpenBSD VPS makes sense for certain workloads where nothing else will do.

pledge() lets a program declare which system operations it will need. Once a program pledges, any attempt to use operations outside that set kills the process immediately. A DNS server can pledge that it only needs network and DNS operations. If it gets compromised and tries to spawn a shell, the kernel kills it. No configuration files. No policy engines. One function call.

unveil() restricts which parts of the filesystem a program can see. A web server can unveil only its document root and its log directory. Everything else on the filesystem becomes invisible. Not just inaccessible — the program can't even confirm other files exist.

pledge() + unveil() vs Linux Security:

OpenBSD:
  pledge("stdio inet rpath", NULL);
  unveil("/var/www", "r");
  unveil("/var/log/httpd", "rw");
  // Done. Three lines. The program is now confined.
  // Any violation = instant SIGABRT. No exceptions.

Linux (to achieve similar confinement):
  1. Write an AppArmor or SELinux policy
  2. Configure seccomp-bpf filters
  3. Set up systemd sandboxing (ProtectSystem, PrivateTmp, etc.)
  4. Configure Linux capabilities
  5. Maybe add Landlock for filesystem restrictions
  6. Hope all five layers are consistent with each other
  7. Debug the inevitable policy conflict

Both can achieve strong confinement.
One of them is three lines of code.
The other is a career.

Nearly every program in the OpenBSD base system uses pledge() and unveil(). That's not a feature you enable. It's how the OS ships. The latest OpenBSD 7.8 release continues to expand pledge and unveil coverage, with patches in March 2026 further tightening restrictions on path handling and mount operations.

Secure by Default, Not Secure by Configuration

Here's what's enabled or enforced on a fresh OpenBSD install without changing anything:

• W^X (Write XOR Execute): Memory pages can be writable or executable, never both. This is enforced across the entire system including the kernel. Most exploit techniques that rely on writing code to memory and then executing it simply don't work.
• ASLR (Address Space Layout Randomization): OpenBSD has had ASLR since 2003. Not the partial implementation some Linux distros ship. Full ASLR across the stack, heap, shared libraries, and now even the kernel itself, which is relinked with random layout on every boot.
• Encrypted swap: Enabled by default since 2005. No configuration needed. Swap contents are encrypted with keys that are discarded on shutdown, preventing cold boot data recovery.
• PF firewall: One of the most elegant packet filters ever written. The syntax reads like English. Firewalls built on PF (pfSense, OPNsense) power millions of networks, and they exist because OpenBSD's PF is that good.
• LibreSSL: OpenBSD forked OpenSSL after Heartbleed and stripped out the garbage. LibreSSL is what you get by default. Cleaner codebase, fewer CVEs, maintained by people who actually audit the code.

On Linux, achieving this level of baseline security requires expertise, time, and ongoing configuration management. On OpenBSD, it's what you get when you type install.

What an OpenBSD VPS Is Good For

OpenBSD isn't a general-purpose server OS in the way Ubuntu or Debian is. It's a specialist tool, and knowing where it excels is the difference between a great deployment and a frustrating one.

Firewalls and Network Appliances

This is OpenBSD's home turf. PF is arguably the best packet filter available on any platform. If you need a VPS that functions as a firewall, VPN gateway, NAT device, or traffic shaper, OpenBSD on a VPS is the obvious choice. The networking stack is battle-tested, the tools are integrated, and the security posture is unmatched.

VPN Endpoints (WireGuard and OpenVPN)

Running your own VPN on an OpenBSD VPS gives you an exit node on an OS where the networking stack has been audited for decades. WireGuard is supported natively in OpenBSD's kernel. Combined with PF for traffic control and the OS's default security hardening, this is one of the most secure self-hosted VPN setups possible.

DNS Servers

OpenBSD ships with unbound (recursive resolver) and nsd (authoritative nameserver) in the base system. Both run with pledge() and unveil() restrictions. Both are from the same security-focused development team. Running a DNS resolver on an OpenBSD VPS means your DNS infrastructure is running on the most hardened platform available, with zero additional packages required.

Mail Servers

OpenSMTPD, developed by the OpenBSD project, is a mail transfer agent designed with the same security-first philosophy. It's in the base system, it uses pledge() and unveil(), and its configuration syntax is dramatically simpler than Postfix or Exim. If you need a small, secure mail server, an OpenBSD VPS server with OpenSMTPD is hard to beat.

Secure Jump Hosts / Bastion Servers

A bastion host's entire purpose is being the one hardened entry point into your network. OpenBSD was essentially designed for this role. Minimal attack surface, audited SSH implementation (OpenSSH was created by the OpenBSD project), and privilege separation throughout the OS.

Privacy-Sensitive Workloads

When you combine OpenBSD's security posture with an anonymous VPS provider that doesn't collect your identity, you get infrastructure that's hardened at both the OS level and the provider level. This makes an OpenBSD VPS hosting setup particularly attractive for journalists, researchers, and anyone handling sensitive data.

What OpenBSD Is NOT Good For

Honesty matters more than evangelism. Here's where OpenBSD will frustrate you:

Docker and containers. OpenBSD doesn't support Docker. It doesn't have container runtimes. If your workflow depends on containerized deployments, OpenBSD is not the right choice. Period. Use Linux.

Large-scale web hosting. If you're running a high-traffic web application with dozens of dependencies, a complex build pipeline, and container orchestration, OpenBSD's smaller package ecosystem and different tool conventions will slow you down. Linux is the better fit for that world.

Desktop applications and GUIs. This is a VPS context, so it's less relevant, but worth noting: OpenBSD's hardware support is narrower than Linux. On server hardware (Intel NICs, standard storage controllers, predictable platforms), this rarely matters. On exotic or bleeding-edge hardware, it can.

Performance-critical workloads. OpenBSD prioritizes security over performance. Its networking stack is excellent, but raw throughput benchmarks will generally favor Linux, especially for workloads that benefit from features like io_uring or eBPF. If you're building a CDN, use FreeBSD or Linux. If you're building a firewall, use OpenBSD.

Large package ecosystem. OpenBSD's ports tree has around 11,000 packages. Compare that to Debian's 60,000+. Most common server software is available, but niche or bleeding-edge packages may not be. Check the ports tree for your specific requirements before committing.

How to Deploy an OpenBSD VPS

Finding an OpenBSD VPS provider that offers it as a first-class option is harder than it should be. Most major providers either don't offer OpenBSD at all, require you to upload a custom ISO, or treat it as an afterthought with outdated images.

Here's what to look for in an OpenBSD VPS hosting provider:

Native OpenBSD template. The provider should offer a current OpenBSD image (7.8 as of this writing) that deploys instantly. If you have to upload your own ISO and manually install through a VNC console, the provider doesn't really "support" OpenBSD — they just don't block it.

KVM virtualization. OpenBSD runs best on KVM-based VPS infrastructure. Avoid providers using container-based virtualization (OpenVZ, LXC) — those share a Linux kernel and can't run BSD at all.

Serial console access. OpenBSD's installer and boot process work through a serial console. Your VPS provider should offer console access (serial or VNC) for initial setup and emergency access.

Reasonable resource allocation. OpenBSD is efficient. A VPS with 1-2GB of RAM is sufficient for most OpenBSD workloads (DNS, VPN, firewall, small web server). You don't need massive specs for the workloads OpenBSD excels at.

On Servury, OpenBSD 7.8 is a first-class template. Select it at deploy time, and your OpenBSD VPS server is live in 30 seconds. No ISO uploads. No manual installs. No email, no KYC, crypto payments accepted.

Getting Started After Deployment

Once your OpenBSD VPS is deployed, the base system is already hardened. But here are the first things most administrators do:

Update the system. Run syspatch to apply any binary security patches. OpenBSD releases patches between versions, and syspatch applies them without requiring a full upgrade.

Configure PF. Edit /etc/pf.conf to set up your firewall rules. A basic starting point:

# /etc/pf.conf - basic OpenBSD firewall
set skip on lo

# Block everything by default
block all

# Allow outbound traffic
pass out quick

# Allow SSH from anywhere (restrict to your IP for production)
pass in on egress proto tcp to port 22

# Allow your application ports
pass in on egress proto tcp to port { 80, 443 }

Install packages. Use pkg_add for any additional software. For a VPN server: pkg_add wireguard-tools. For a web server, httpd is already in the base system.

Enable services. Use rcctl to enable and start services. For example: rcctl enable httpd and rcctl start httpd.

The base system includes SSH (OpenSSH), a web server (httpd), a mail server (OpenSMTPD), DNS resolvers (unbound, nsd), and NTP (OpenNTPD). For many workloads, you don't need to install a single package.

OpenBSD vs FreeBSD on a VPS

If you're choosing between BSD flavors for a VPS, the decision comes down to priorities:

Choose OpenBSD when: Security is the primary concern, your workload is network-oriented (firewall, VPN, DNS, mail), you want the strongest possible defaults, and you're willing to trade some performance and ecosystem size for a hardened platform.

Choose FreeBSD when: You need ZFS, your workload is storage or throughput-intensive, you want a larger package ecosystem, or you need jails for lightweight virtualization. FreeBSD is more general-purpose and has better raw performance for many workloads.

Both are excellent. They serve different roles. OpenBSD is the scalpel. FreeBSD is the Swiss Army knife.

The Bottom Line

OpenBSD is not the most popular operating system. It's not the fastest. It's not the most feature-rich. It's the most secure. And for the workloads where that matters, nothing else comes close.

An OpenBSD VPS makes sense when your workload is security-critical and network-oriented: firewalls, VPN endpoints, DNS resolvers, mail servers, bastion hosts, and privacy-sensitive services. For these roles, OpenBSD's decades of code auditing, pledge() and unveil() system call restrictions, and secure-by-default configuration make it the strongest platform available.

For everything else — containers, large web applications, complex build pipelines — Linux is probably the better tool. And that's fine. Choosing the right OS for the right job is better engineering than running everything on the same platform.

If OpenBSD fits your workload, deploy one on Servury. OpenBSD 7.8 as a first-class template. No email, no KYC, crypto accepted. Live in 30 seconds.

---

Frequently Asked Questions

Is OpenBSD good for a VPS?

For the right workloads, it's the best choice available. OpenBSD excels as a firewall, VPN endpoint, DNS server, mail server, or secure jump host. Its security defaults are unmatched, and the base system includes most of the tools you need without installing additional packages. For general-purpose web hosting or containerized applications, Linux is a better fit.

Can I run Docker on an OpenBSD VPS?

No. OpenBSD does not support Docker or any OCI-compatible container runtime. If your deployment workflow depends on containers, use Linux. OpenBSD's isolation model is based on pledge(), unveil(), and chroot — different tools, different philosophy.

How does OpenBSD compare to Linux for security?

OpenBSD's security advantage comes from defaults and design philosophy, not from any single feature. Linux can be made extremely secure with SELinux, AppArmor, seccomp, Landlock, and careful configuration. But OpenBSD ships that way. The question is whether you want security by configuration or security by default. Both are valid approaches — OpenBSD just requires less ongoing effort to maintain the hardened state.

Is OpenBSD slower than Linux?

In raw benchmarks, generally yes. OpenBSD's kernel makes design choices that favor security over performance (W^X enforcement, KARL, extensive randomization). For network appliance workloads, the difference is negligible. For high-throughput data processing, Linux will outperform OpenBSD. Choose based on your priority.

Where can I deploy an OpenBSD VPS server?

Not many VPS providers offer OpenBSD as a first-class option. Servury offers OpenBSD 7.8 as a native template with instant deployment. Vultr offers OpenBSD images in 32 locations. ARP Networks has supported BSD hosting since 2008. Most mainstream providers (AWS, DigitalOcean) either don't offer OpenBSD or require custom ISO uploads.

What version of OpenBSD should I run?

Always run the latest release. As of this writing, that's OpenBSD 7.8, released October 2025. OpenBSD only supports the two most recent releases with security patches, so running older versions means missing critical fixes. Use syspatch to stay current between releases.