WireGuard on a VPS: a fast, lean and private VPN

WireGuard is built on a deliberately small source code (about 4,000 lines), which makes it easier to audit and significantly less exposed to security flaws than its alternatives. By hosting it on a dedicated VPS, you obtain a fixed IP address under your control, throughput close to the server's native bandwidth, and the ability to grant or revoke access at the client's granularity. It is the preferred solution of developers and distributed teams who want to secure their communications without sacrificing performance.

Three things set it apart from a commercial VPN. The exit address is shared with no one, so you can add it to the allowlist of an API, a back office or a client's firewall. The logging policy is yours, since nobody else runs the machine. And the protocol stays lean: a single UDP port, fixed cryptography (Curve25519 for key exchange, ChaCha20 and Poly1305 for authenticated encryption) and a tunnel that survives a change of IP address, for instance when a device moves from Wi-Fi to 4G.

WireGuard needs very few resources: with the wg-easy interface, 1 vCPU and 1 GB of RAM are enough for a small team, and the VPS bandwidth, not the CPU, sets the limit. The Marketplace template installs Ubuntu 24.04; the WireGuard module has been part of the Linux kernel since version 5.6, so there is nothing to compile.

Three things to plan before ordering:

The tunnel's UDP port (51820 by default) must be reachable from the internet. If a firewall filters traffic upstream, open it explicitly.

SSH access from your machine: the admin interface is never published, you reach it through an SSH tunnel.

A hostname (optional): an A record such as vpn.yourdomain.com pointing to the VPS IP makes client configurations easier to read and survives a server change. The bare IP address works too.

Whoever reaches wg-easy can create clients, and therefore enter your network: treat this interface like root access.

Keep it on the loopback. The SSH tunnel is enough for day-to-day use. If you must publish it, put it behind an HTTPS reverse proxy (see our Caddy guide), declare the proxy address in the TRUSTED_PROXIES variable and leave INSECURE set to false; never serve it over plain HTTP.

Turn on two-factor authentication. From the user menu, the Account page enables a TOTP code to enter at every login.

Be wary of one-time links. wg-easy can generate a short download link valid for five minutes, but its documentation warns that these links can be guessed and hand over the client's private key without authentication. Prefer the QR code or the file, sent over a private channel.

Revoke cleanly. Disabling a client cuts its access while keeping its configuration; deleting it is final. An expiry date does the job on its own for a contractor or one-off access. If the admin password is lost, the cli db:admin:reset command, run inside the container, resets it.

By default, wg-easy generates full-tunnel configurations: AllowedIPs = 0.0.0.0/0, ::/0, all the device's traffic leaves through the VPS. That is the right choice on public Wi-Fi, or to present the same exit IP everywhere.

To use the VPN only as a gateway to your private services, switch to a split tunnel: in Admin Panel → Config → Allowed IPs (global value) or on a client's page (value for that client only), keep only the VPN subnet, 10.8.0.0/24 in a default install, and the internal networks you need to reach. The rest of the browsing goes out through the local connection. The server holds the address 10.8.0.1: bind your databases, dashboards and back offices to it rather than to 0.0.0.0, and they become reachable only through the tunnel.

Note that AllowedIPs controls routing on the client side, and the user can change it. To enforce a restriction, wg-easy offers a per-client firewall (Admin Panel → Interface → Per-Client Firewall), applied server-side with iptables and still marked experimental: test it before relying on it. Beyond a handful of machines to link together, a mesh such as Netbird saves you from managing these lists by hand.