How to self-host a WireGuard VPN on a VPS

Rent from $3.00 annual, run the official WireGuard quick start, and keep the keys plus one UDP port on root you own. No KYC, nineteen coins.

Published 2026-08-30 · Updated 2026-10-14 · FYRHost Editorial · 18 min read

Same protocol, different endpoint

Every large consumer VPN brand runs the same WireGuard protocol you can run yourself, and they document it openly. What a subscription actually buys is an app, a shared fleet and the cover of a crowd — three things, none of which is encryption. If what you want is the protocol on hardware whose root you hold, the subscription is not a shortcut; it is a detour through someone else's terms of service.

A rented VPS is Linux with a public IPv4 and nothing else, which is exactly the specification of a personal endpoint. You install WireGuard on it yourself from the official packages, generate your own keys, and open exactly one UDP port — 51820 by default, any port you like in practice. The tunnel that results is identical on the wire to a commercial one; the entire difference is in who holds the other end.

Outline, Jigsaw's self-hosting project, is the same ownership model behind a friendlier installer, and it lands on the same root server the same way. Either path, the division of labor is absolute: the company rents you the machine and does not operate the tunnel, while you configure, update and revoke. There is no managed endpoint and no client software on the provider side of the fence — root is the product.

There is also a fleet question hiding inside the endpoint question: how many machines carry your keys? A commercial plan answers it for you — all of theirs do, and you cannot count them. Self-hosting answers it with one, and one is enough: a single current kernel, one userspace package, one config file, all of it reviewable in an evening. When the whole security-relevant surface fits in your head, the audit is a habit instead of a vendor promise you renew annually.

Where the model breaks is expectations imported from consumer VPNs: no shared-IP crowd to hide inside, no app store update to trust blindly, and no support desk to email when your own firewall blocks you. The solo IP that results is honest — profiled by usage if you use it loudly — and owning the endpoint means owning that trade. If you wanted the crowd, you wanted the subscription, and that is a legitimate answer that simply is not this guide.

What the tunnel covers — and what it never will

Be precise about the purchase: the tunnel encrypts the leg between your devices and the VPS, which hides that traffic from the ISP on that leg and from anyone sniffing the same cafe network. Inside the tunnel, WireGuard uses ChaCha20-Poly1305 for encryption and Curve25519 for key agreement — the same primitives the big brands use, specified in RFC 8439 and RFC 7748 rather than in marketing pages.

What the tunnel does not do is conceal you from the provider that rents the box, the datacenter that hosts it, or a legal process that can reach the rack. The host sees an encrypted UDP flow and its bandwidth; the facility sees the tenant; a court with jurisdiction sees an addressable machine. Any threat model that requires hiding from the host itself is not solved by self-hosting — it is solved by not doing the thing in the first place.

The honest cost of owning the endpoint is crowd cover removed: your IP serves you alone, so usage patterns profile exactly one person. Endpoint hygiene is therefore part of the architecture, not an afterthought — patch the kernel, rotate keys when a device leaves the family, and keep 1 peer per device so a compromised phone is a revoked key rather than a compromised network. The tunnel is a leg, not a lifestyle.

None of this is a demotion of the tool — it is the accurate warranty. WireGuard does one job at line rate with a small, auditable codebase, and it does not pretend to solve identity, jurisdiction or behavior. Buying honesty about scope is rare in this market, where every product page implies more than the protocol can deliver. Start from what the tunnel actually covers and the rest of the threat model gets easier, because the unknowns stop pretending to be covered.

The mistake is stacking claims on the tunnel it was never meant to carry: anonymity from the provider, immunity from the AUP, or cover for traffic that exits into something abusive. The AUP rides the tunnel too — scanning, spam and attacks launched through it are ban-level events at the exit, exactly as if you had run them without any tunnel at all. Encrypt the leg; behave on the internet at the end of it.

Order the box, not the fleet

Sizing a tunnel endpoint is a solved problem: small. A personal tunnel moves a few megabits when you are pushing hard, and the entry tiers carry that without warming up. Location follows the same rule the jurisdiction guide establishes — Amsterdam when the users sit in Europe, Reykjavik when the jurisdiction is the reason — and one list price covers every flag, so sizing and location never fight each other on the invoice.

Rent the Sentry at $6.00 on the annual term if a handful of family devices will share the endpoint — the Scout at $3.00 covers a strictly personal tunnel with room to spare. Entry lines run unmetered at 1 Gbps, which saturates long before a personal tunnel does, so the ladder above the entry tier buys you nothing for this job until the endpoint also serves traffic that is not yours.

Location deserves its own sentence before checkout, because the tunnel's exit is the jurisdiction you will live in online. Amsterdam for European latency, Reykjavik when the reason for the box is the law around it — the same reasoning the jurisdiction guide applies to any workload, applied here to a workload that happens to be yours. The premium regions price exactly as published, the annual term cuts the effective rate on every tier, and the invoice clears in the coin you already hold. A personal endpoint is a decade-scale habit; starting it on the right rack costs nothing extra on day one.

Upgrade triggers are behavioral, not theoretical: latency complaints from actual users, bandwidth graphs that saturate the port during ordinary evenings, or services joining the box beyond the tunnel itself. Outline users should note the same arithmetic — the installer is friendly, but it runs happily on the same small-class VPS. Nothing about the protocol gets faster on a bigger machine until the network card itself becomes the bottleneck.

The mistake is buying headroom for a tunnel the way you would for a database — top of the ladder, just in case. Where it breaks is the invoice: a tunnel does not use the RAM, the extra cores idle, and even the annual discount cannot rescue a tier you never needed. Start at the bottom, watch two weeks of graphs, and let a real number justify the first upgrade.

Keys and the config that holds them

The official quick start is genuinely quick: install the tools from the install page, generate a private key with wg genkey, derive the public one, and write a config file that names an interface address and a listen port. Everything else — peers, allowed IPs, the handshake schedule — hangs off that one file. Read the quick start once end to end before pasting anything; it is shorter than most troubleshooting sessions you will avoid by doing so.

The config lives at /etc/wireguard/wg0.conf and carries one peer block per device: each device gets its own keypair, its own allowed IP inside the tunnel, and nothing shared. Set Address for the interface, ListenPort for the UDP socket, and AllowedIPs per peer to route exactly what should ride the tunnel. Enable wg-quick@wg0 at boot and the endpoint survives reboots without your attendance.

Address planning takes five minutes and saves rebuilds: give the tunnel a range from the documentation's reserved space, hand out sequential IPs per device, and keep a plain text note of which key belongs to which device. The map is tiny — a personal tunnel rarely exceeds a dozen peers — but the note is what lets you revoke one device in one line instead of auditing the whole file under pressure.

Permissions finish the job that generation started: the config file holds the private key, so it belongs to root and to nobody else — 600, owned by root, never copied through a chat window as a backup. The public keys of your peers, by contrast, are safe to paste anywhere, which is what makes sharing an endpoint with the family painless. One secret per machine, one copy of each secret per machine, and the whole key story stays boring. Boring is the goal; exciting key management is how tunnels end up in someone else's slide deck.

The classic mistake is one peer block copied across every device, because the keys are right there and copying feels efficient. Where it breaks is revocation: with a shared key, removing a lost phone means re-keying everything, and until you do, the lost phone and the laptop are indistinguishable on the wire. One peer per device costs nothing at generation time and is the entire security model at rotation time.

Open one UDP port, forward, and stop

The firewall work is one rule: allow the UDP port you chose through the filter and leave the rest of the interface's exposure alone. With iptables that is a single append to the input chain, per iptables(8); with nft the equivalent line lands in your inet table. WireGuard is quiet by design — it does not respond to unauthenticated packets, so the port neither advertises the tunnel nor answers probes from strangers.

Forwarding is the second switch and the one people miss: the kernel must agree to pass packets between the tunnel interface and the public one, which means setting net.ipv4.ip_forward=1 in sysctl — see sysctl(8) — and making it stick across reboots. Then NAT: a masquerade rule rewrites tunnel clients' source addresses to the server's public IP so return traffic knows the way home. Port open, forwarding on, masquerade set — that is the whole perimeter.

Cosmetics are optional and labeled as such: a matching PTR record set from the panel is polish for tools that reverse-lookup your exit IP, not a requirement of the protocol. The OpenBSD crowd runs the same design with PF — pf.conf(5) — and the in-kernel WireGuard implementation in wg(8); the config translates almost line for line. Different tooling, identical perimeter: one port and a forward.

Order of operations matters more than any individual rule, because the firewall is unforgiving about your mistakes. Bring the interface up, confirm the listener, then add the filter rule and test from outside before you celebrate — a rule that only works from localhost is the classic false positive. Write both the filter rule and the sysctl into whatever persistence mechanism your distribution prefers, so a reboot reproduces the working state without notes. The best firewall config is one you can describe from memory a month later; if you cannot, it is too clever.

Where it breaks is the half-open tunnel: the handshake completes on the server, the client announces connected, and nothing loads. That signature means forwarding or masquerade — almost always the latter — because the encrypted leg works while the exit leg drops. Check the 2 switches in order before touching keys or MTU; keys and MTU are almost never the culprit when the handshake itself succeeded.

Confirm the tunnel before you trust it

Verification on WireGuard is refreshingly literal: wg show on the server lists peers with their latest handshake time, and a handshake younger than about 2 minutes means traffic is flowing. No handshake in the output means nothing has connected — the port, the key or the endpoint line is wrong, in roughly that order of likelihood. The tool tells you which half of the tunnel is broken without ceremony or log diving.

On the listening side, ss -uln should show the UDP socket bound to your chosen port, which rules out the case where the interface came up but the config did not load — see ss(8) for the flags. On the client, the same command or the app's log confirms the attempted endpoint. Splitting the check this way — server handshake, server listener, client attempt — localizes any failure to one machine in one pass.

Behind NAT, add a persistent keepalive of 25 seconds to the peer block so the client's NAT mapping stays open while idle; without it, a phone on carrier NAT silently drops the tunnel between uses and the first packet after lunch goes nowhere. The rekey schedule is automatic and needs no attention — WireGuard renegotiates session keys on its own timer, which is one reason there is nothing to renew by hand.

One more habit from the operations world transfers here unchanged: write down what a healthy endpoint looks like. Two peers with fresh handshakes, one listener on the expected port, MTU at the default until proven otherwise — a five-line note in your own file beats any dashboard. When something breaks next quarter, the note is the baseline you diff against, and the diff usually names the fix before you finish reading it.

The mistake is trusting the client's green checkmark as the test. Client interfaces report configuration, not connectivity; the server's handshake timestamp is the only signal both ends agree on. Where it breaks in practice is the reverse direction — the server shows handshakes, the client still cannot reach the internet — which returns you to the forwarding and masquerade switches from the previous section. Work from the handshake outward and every failure has an address.

Breakage patterns you will actually hit

The most common real-world failure is an MTU black hole: small packets cross, large ones vanish, so pages half-load and uploads stall at exactly the interesting moment. WireGuard's default interface MTU is 1420; on last miles that encapsulate aggressively — some DSL and mobile networks — dropping the client's MTU to 1380 makes the stalls disappear. Diagnosis is a matter of size, not direction: if small requests pass and bulk transfers die, think MTU first.

The second pattern is lifecycle, not networking: a device leaves the family and its key must leave the config the same day. With one peer per device this is a single line deleted and a wg syncconf to apply it live; without that discipline, the departed device keeps a working route through your exit for as long as the server neglects to check. Rotation is cheap only when the key-to-device map from the earlier section actually exists.

Kernel updates deserve a paragraph of respect: the WireGuard code lives in-tree on modern systems, so the monthly patch that fixes everything else also carries any crypto corrections. A tunnel that renews its own keys but never its kernel is half-maintained, and the half you skipped is the half attackers study. Schedule the reboot, watch the handshakes return, and the whole cycle takes under 5 minutes.

Move the endpoint up to a Warden at $15.20 on the annual term the day the box stops being only a tunnel — 16 GB of RAM keeps a side service from starving the routing duties, and the extra headroom makes kernel upgrades a non-event. The protocol does not need the bigger machine; the other things you stacked on it do, and pretending otherwise risks both duties at once.

The residual mistakes are operational: testing the tunnel only from the same LAN as the server, skipping kernel updates because the tunnel works, and treating the AUP as suspended inside an encrypted leg. Where it breaks is always the same shape — the tunnel was fine and the assumptions around it were not. Patch cadence, key hygiene and one honest peer per device are the whole maintenance story, and all three fit on a sticky note.

What the host can see — and what it cannot

The platform's logging posture is part of the threat model you are buying into, so state it plainly: no payload or guest traffic logs are kept, and connection metadata is kept for no more than 24 hours. The host necessarily sees an encrypted UDP flow to your box and the bandwidth it consumes — that is physics — and just as necessarily does not see inside the tunnel, because the keys live in your config file, not on the host.

The asymmetry is the point of the design: tunnel contents are encrypted from your device to the VPS, so the leg you do not control is unreadable in transit, and the exit leg is ordinary internet traffic from your own IP — the protocol details are in WireGuard's protocol documentation. What the arrangement cannot deliver is cover from the operator of the exit; every exit has an operator, and self-hosting makes that operator you. Choose the jurisdiction of the rack with that fact on the table.

Compare it honestly with the commercial alternative: there, the operator sees the same flow metadata for many users and publishes a policy promising restraint; here, the operator is you and the policy is your config file. Neither arrangement hides the fact of the tunnel from the datacenter. The difference is who holds the keys, who reads the logs that do exist, and whose legal process can demand them — three answers, all of which this design moves into your hands.

The honest summary fits in one line: the host sees that a tunnel exists; only you see what goes through it. Every privacy decision downstream — DNS choice, browser hygiene, what the exit IP gets used for — happens inside that line, on your side of the glass. Providers sell you a leg and a posture; the design decisions were always going to be yours. This guide exists to make them explicit rather than assumed.

Where reasoning breaks is conflating no-payload-logs with no-records-anywhere: billing rows and panel actions are retained on any commercial platform, and connection metadata exists for at least the retention window. That is the honest floor. If a threat model requires zero records at every layer, the correct deployment is not a VPS with a tunnel — it is a longer conversation about what the threat model is actually protecting.

The WireGuard setup, in the order to run it

Run the build as a sequence and it cannot half-fail confusingly. First, order the box: entry tier, city chosen by the jurisdiction logic, one list price, paid from the deploy page in whichever coin your wallet holds. Second, install the WireGuard tools from the official packages and work through the quick start once with full attention — it is one page, and every later step assumes its vocabulary of interfaces, peers and allowed IPs.

Third, generate the keypair with wg genkey and write /etc/wireguard/wg0.conf with an interface address, a listen port and one peer block per device. Fourth, open the single UDP port in the firewall, switch on net.ipv4.ip_forward=1, and add the masquerade rule that gives tunnel clients a route home. Fifth, enable wg-quick@wg0 so the endpoint survives reboots unattended.

Sixth, verify from the server outward: wg show for handshakes, ss -uln for the listener, then a client connection and a second look at the handshake timestamps. Add the 25-second keepalive for NAT'd devices, and if pages half-load, drop the client MTU toward 1380 before touching anything else. Seventh, put key rotation on the calendar for the day a device leaves — not the week after.

The sequence compresses well once you have run it twice: about 15 minutes for a new box, most of it waiting for packages. Keep a template config with your address plan and generic peer blocks, and a new device becomes a keypair plus three lines. Keep the sticky note current, keep the kernel patched, and the endpoint becomes the kind of infrastructure you forget about — which is the actual goal. A tunnel you never think about is a tunnel you will actually keep, and a tunnel you keep is the only kind worth building.

Eighth, pay the invoice by whichever of the nineteen coins your wallet holds — the tunnel does not care — and record the box's jurisdiction next to its key fingerprint in your notes. That single line of documentation, kept current, is what turns a hand-built endpoint into infrastructure: any future you, or the person who inherits the box, can reconstruct the whole perimeter from one sticky note and this page.

Video walkthrough

▶

Here's how to roll your own VPN | WireGuard Tutorial — The Linux Experiment (Gardiner Bryant). The player loads from youtube-nocookie.com on click; watch on YouTube.