Self-Hosted VPN on a $5 DigitalOcean or Linode Server

A small VPS can provide a predictable VPN endpoint for travel and remote administration. The “$5” label in the title describes a budget class, not a guaranteed current offer: verify the provider's present instance pricing, transfer allowance, taxes, and backup charges before deploying.

This walkthrough builds an IPv4 WireGuard gateway on Ubuntu. It assumes one client, sudo access, a provider console, and a fresh server without another firewall manager. You remain responsible for patching, DNS policy, private keys, and recovery.

Separate account credentials from tunnel keys

Protect the provider account with multifactor authentication and store recovery codes offline. A compromised control-panel account can replace the server or capture its disk regardless of how well the tunnel is configured. Use SSH keys and a non-root administrative account for routine server work.

The Password & API Key Secure Hash Generator below can help create a separate, strong administrative password or API credential where the service permits user-chosen values. It is not a WireGuard key generator. Generate WireGuard private keys locally with the protocol's own tooling, and never substitute a password or a SHA-256 hash for them.

Do not paste operational private keys into any web utility. Keep client configuration files out of source control and shared chat histories. A client profile containing a private key grants that device's tunnel identity; a screenshot or QR export should be treated as a credential too.

Provision a server and generate its identity

Choose a region near your normal access location unless another requirement matters more. Check the provider's acceptable-use rules, available recovery console, and transfer billing. DigitalOcean's documentation and Linode's documentation cover their respective provisioning and networking controls; the Linux configuration below is not tied to one vendor.

Install updates and WireGuard from Ubuntu packages. Identify the actual uplink interface with ip route show default; this example later uses eth0. Generate the server key under a restrictive umask, and generate a separate key pair on the client rather than sharing the server's identity.

sudo apt update
sudo apt upgrade
sudo apt install wireguard iptables
ip route show default
sudo install -d -m 700 /etc/wireguard
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/server.key'
sudo sh -c 'wg pubkey < /etc/wireguard/server.key > /etc/wireguard/server.pub'

Only the public key should move to the opposite peer. Keep the private key readable by root alone, and avoid putting it in shell command arguments that can be retained in history. Plan how to rotate a lost client key by removing that peer from the server.

Configure forwarding, NAT, and the server peer

Use 10.66.0.0/24 only after checking it does not overlap your local or remote networks. The server will be 10.66.0.1, and the first client 10.66.0.2. A collision can make local devices unreachable or send traffic to the wrong interface.

Enable IPv4 forwarding by creating /etc/sysctl.d/99-wireguard-forward.conf containing net.ipv4.ip_forward=1, then run sudo sysctl --system. On this dedicated server, use the following /etc/wireguard/wg0.conf, replacing the placeholders and eth0. Insert the private key using a secure editor; this is a complete-file template, not something to append repeatedly.

[Interface]
Address = 10.66.0.1/24
ListenPort = 51820
PrivateKey = <SERVER_PRIVATE_KEY>
PostUp = iptables -A FORWARD -i %i -o eth0 -s 10.66.0.0/24 -j ACCEPT
PostUp = iptables -A FORWARD -i eth0 -o %i -d 10.66.0.0/24 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -s 10.66.0.0/24 -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -o eth0 -s 10.66.0.0/24 -j ACCEPT
PostDown = iptables -D FORWARD -i eth0 -o %i -d 10.66.0.0/24 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -s 10.66.0.0/24 -o eth0 -j MASQUERADE

[Peer]
PublicKey = <CLIENT_PUBLIC_KEY>
AllowedIPs = 10.66.0.2/32

The masquerade rule changes forwarded clients' source addresses to the VPS uplink address. Restrict file permissions with sudo chmod 600 /etc/wireguard/wg0.conf, then start the service using sudo systemctl enable --now wg-quick@wg0.

These forwarding rules assume no earlier conflicting drops. Do not combine them blindly with UFW, firewalld, Docker rules, or another gateway configuration. In an existing firewall, integrate equivalent rules into its established policy instead of creating a second manager.

Open only the required entry points

At the provider firewall, permit UDP 51820 for WireGuard and allow SSH only from your current administrative source. If clients roam, the WireGuard UDP source may need to be unrestricted; peer authentication still requires valid keys. Preserve console access before narrowing SSH.

Inspect the host firewall separately. This walkthrough's forwarding hooks do not open an existing restrictive INPUT chain, and they do not harden an otherwise open host. With an existing host policy, explicitly permit WireGuard's UDP port and the required management access. Never change default policies remotely without a working recovery route.

Add a client profile through the platform's WireGuard app or Linux wg-quick:

[Interface]
Address = 10.66.0.2/32
PrivateKey = <CLIENT_PRIVATE_KEY>

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

Replace the endpoint with the server's actual public address. Persistent keepalive can maintain a NAT mapping for a roaming client; it is not a speed boost. Review the WireGuard quick start for platform-specific key and interface handling.

This profile routes IPv4 only. It does not carry IPv6, configure a DNS resolver, or provide a kill switch. Before claiming full-tunnel privacy, deliberately block unsupported IPv6 through your client's tested firewall controls or deploy a properly routed IPv6 tunnel. Set DNS to a resolver reachable through the VPN; do not assume the VPS already runs one.

Validate operation and keep the gateway maintainable

Inspect sudo wg show on the server after activating the client. Look for a recent handshake and increasing transfer counters, then test a controlled HTTPS endpoint. Confirm the endpoint observes the VPS address and verify DNS traffic follows your intended policy. A handshake alone proves neither forwarding nor name resolution works.

Test a server reboot and client reconnect before relying on the setup while traveling. Stop the tunnel deliberately and observe whether the client falls back to its normal network. That behavior is expected without a kill switch, but it must not be mistaken for fail-closed protection.

For credential maintenance, use the password and API key tool only for appropriate non-tunnel credentials, and revoke unused provider API tokens. Follow the Linux DNS leak checklist when configuring the client resolver. Keep security updates current and monitor transfer usage against the provider's actual allowance.

A self-hosted exit moves trust to your VPS operator; it does not make browsing anonymous. Follow local law, workplace policies, and service terms, and keep encrypted application protocols such as HTTPS in use.

Key takeaways

• Use locally generated keys and protect provider access independently of the VPN.
• Configure forwarding and NAT explicitly, with firewall rules matched to the server's real interfaces.
• Verify DNS, IPv6 policy, reboot recovery, and tunnel failure rather than stopping at a successful handshake.
• Budget for transfer and maintenance, not just the advertised instance tier.