How to set up a WireGuard VPN on a VPS

A commercial VPN gives you convenience and a large pool of exit IPs, but you are trusting a third party not to log and to mean what their privacy policy says. A self-hosted WireGuard endpoint inverts that: you own the box, you write the config, and you decide whether anything is logged at all. There is no shared exit address with thousands of strangers, which also means none of their abuse history lands on you.

The trade-off is honest: the VPS provider can still see that an IP exists and routes traffic, so self-hosting moves trust from a VPN brand to your host. That is exactly why it pays to run it on an offshore no-KYC VPS in a privacy-minded jurisdiction, paid for without handing over your identity. This is also why we say private, not anonymous: a self-hosted tunnel improves your posture, but real anonymity still depends on your own payment and network hygiene. For the broader case, see our overview of running a VPS for a VPN.

WireGuard is remarkably light on resources. A single CPU core and 1 GB of RAM will saturate most home connections, and the encryption work happens in the kernel rather than in a heavy userspace daemon. For one person or a couple of devices, the Pup tier (1 vCPU, 1 GB RAM, 25 GB NVMe) is plenty, and like every tier it ships with unlimited traffic so a VPN does not burn through a metered cap.

Step up only if you are adding load. A handful of family members on the same tunnel are fine on Pup or Cub; if you want to co-host other services, run a few containers, or serve several simultaneous heavy streams, move to Scout or Runner for the extra cores and RAM. Location matters as much as size for a VPN: pick by latency and jurisdiction, which we cover further down. You can pay in Monero or any supported coin, and a server deploys in about sixty seconds with no setup fee.

WireGuard ships in the kernel of modern Linux, so installation is just the userspace tooling. On Debian or Ubuntu LTS, refresh the package index and install the package as root:

apt update && apt install -y wireguard

This pulls in wg and wg-quick, the two commands you will use to manage the tunnel. On AlmaLinux, Rocky or Fedora the equivalent is dnf install -y wireguard-tools. Verify it is present with wg --version before continuing.

WireGuard authenticates peers with Curve25519 keypairs, not passwords. Lock down the directory first, then generate one keypair for the server and one for each client device. Run as root:

umask 077; cd /etc/wireguard

wg genkey | tee server_private.key | wg pubkey > server_public.key

wg genkey | tee client_private.key | wg pubkey > client_public.key

You now have four files. The two public keys are exchanged between peers; the two private keys never leave the machine they belong to. Print them with cat server_private.key and so on when you fill in the config in the next step. Generate a fresh client keypair per device rather than reusing one across phone and laptop.

Create the server interface config at /etc/wireguard/wg0.conf. This defines the tunnel subnet (10.0.0.0/24 here), the listen port, and a NAT rule so client traffic is masqueraded out the server's public interface. Replace SERVER_PRIVATE_KEY and CLIENT_PUBLIC_KEY with the values from step 2, and confirm your public NIC name with ip route get 1.1.1.1 (often eth0 or ens3):

[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.0.0.2/32

The server is 10.0.0.1; the first client will be 10.0.0.2. Each additional device gets its own [Peer] block and the next address in the range.

For the server to route client traffic to the internet, the kernel must forward packets. Enable it permanently and apply it now:

echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf && sysctl -p

Then open the WireGuard port. WireGuard listens on UDP 51820 by default. If you use UFW:

ufw allow 51820/udp && ufw allow OpenSSH

Always allow your SSH port in the same breath so you do not lock yourself out when you enable the firewall. Every VPSCrypto VPS arrives with a dedicated clean IPv4 and an IPv6 /64, so this single UDP rule is all the inbound exposure your VPN needs.

Start the interface with the helper that reads your config, then enable the systemd unit so it survives reboots:

wg-quick up wg0

systemctl enable wg-quick@wg0

Confirm the interface is live and listening with wg show, which prints the interface, its public key and the listening port. At this point the server side is finished; the only thing left is to point a client at it. If you change wg0.conf later, apply it cleanly with wg-quick down wg0 && wg-quick up wg0.

On your laptop or phone, install the official WireGuard app or package and create a tunnel from this config. Use the client private key from step 2 and the server's public key. The client Endpoint is simply your server's public IP followed by the WireGuard UDP port, for example 203.0.113.10:51820:

[Interface]
PrivateKey = CLIENT_PRIVATE_KEY
Address = 10.0.0.2/32
DNS = 1.1.1.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Setting AllowedIPs to 0.0.0.0/0, ::/0 routes all traffic through the tunnel. On mobile, generate a QR code from this file with qrencode -t ansiutf8 < client.conf on the server and scan it in the app. Activate the tunnel, then check your visible IP — it should now be the server's. The PersistentKeepalive line keeps the connection alive behind NAT.

A working tunnel is the start, not the finish. Rotate keys periodically by regenerating a client keypair and swapping the public key in the server's [Peer] block. Keep a separate keypair per device so you can revoke one without disturbing the others — to revoke, simply delete that peer's block and re-apply the config.

• Disable logging you do not need. WireGuard itself is quiet by default; review your SSH and system logs and trim retention if a minimal footprint matters to you.
• Lock down SSH with key-only authentication and consider moving it off port 22; keep that port allowed in UFW before you enable the firewall.
• Choose the jurisdiction deliberately. The server's location is now your VPN's privacy posture. Switzerland under the FADP and Iceland with its free-press tradition are strong choices; the Netherlands and France trade some of that for lower EU latency.

For ongoing operations and credential handling, our documentation covers reverse DNS, IPv6 and panel features in detail.

Self-hosting wins when you want a dedicated IP, full control over logging, and a tunnel that no provider markets to thousands of users. It is ideal for accessing your own services, getting a stable address for allowlists, or simply not trusting a VPN company's no-logs claim. The cost is that you maintain it, and a single self-hosted exit IP is not designed for blending into a crowd the way a commercial VPN's shared pool is.

Commercial VPNs win on convenience, country-hopping and shared-IP plausible deniability. For most privacy-conscious users who want one trusted endpoint they actually own, a small VPS running WireGuard is the better answer — and paying for it through a crypto, no-KYC checkout keeps the setup consistent end to end. If you are still weighing the approach, our VPS-for-VPN overview compares the two in more depth.