March 12, 2026 (1mo ago)
Written by Temps Team
Last updated March 12, 2026 (1mo ago)
You have three VPS instances from different providers. One runs your API on Hetzner, another handles your database on DigitalOcean, and the third runs a Redis cache on Linode. They need to talk to each other securely — database replication, internal API calls, distributed caching. You could open ports and pray, or you could build a private network that wraps encrypted tunnels around the public internet.
WireGuard makes this surprisingly simple. It's a VPN protocol built into the Linux kernel since version 5.6, and it handles encrypted point-to-point connections with a fraction of the complexity of older tools like OpenVPN or IPSec. A mesh network takes it one step further: every server connects directly to every other, forming a private LAN that spans the globe.
This guide walks you through setting up a WireGuard mesh from scratch, explains the topologies and tradeoffs, and shows how to automate the painful parts.
TL;DR: WireGuard's ~4,000-line codebase delivers roughly 3x the throughput of OpenVPN (WireGuard whitepaper). You can create a private mesh network across multiple cloud providers by generating key pairs, assigning private IPs, and configuring each node's peer list. For clusters beyond 3-4 servers, automated key exchange tools eliminate the N-squared configuration burden.
Cloud provider VPC networks can't cross vendor boundaries — your AWS instances can't natively reach Hetzner servers. According to Flexera's 2024 State of the Cloud Report, 89% of enterprises now use a multi-cloud strategy, which means cross-provider communication is the rule, not the exception.
AWS VPC peering works great between AWS accounts. But it can't reach your Hetzner box. GCP's networking won't talk to your DigitalOcean droplet. Every provider builds walled gardens around their own infrastructure.
If your architecture spans multiple providers — and it probably should, to avoid vendor lock-in — you need a networking layer that sits above all of them.
The alternative to private networking is opening firewall ports between servers. That means your PostgreSQL instance listens on a public IP. Your Redis cache is reachable from anywhere. Bots scan all IPv4 addresses in under 45 minutes. Every open port will be found.
IP allowlisting helps, but it's fragile. Cloud IPs change. You forget to update the list. One mistake, and your database is exposed to the internet.
Traffic between servers on the public internet travels in cleartext by default. Someone on the same network path could intercept your database queries, API responses, or session tokens. TLS on every internal service is possible but adds complexity and certificate management overhead.
Istio and Linkerd solve the multi-service networking problem, but they're designed for hundreds of microservices running in Kubernetes. For 2-5 servers that just need to talk securely, a service mesh adds massive operational complexity you don't need. WireGuard handles this with a few config files.
WireGuard's entire codebase is approximately 4,000 lines of code, compared to OpenVPN's roughly 100,000 lines (WireGuard whitepaper). That smaller surface area means fewer bugs, easier auditing, and significantly better performance.
Since Linux 5.6, WireGuard runs as a kernel module. Packets don't bounce between userspace and kernel space — they're encrypted and forwarded entirely within the kernel. The WireGuard whitepaper benchmarks show throughput of 1,011 Mbps compared to OpenVPN's 258 Mbps under the same conditions.
That's not a marginal improvement. It's nearly 4x faster. For inter-server traffic like database replication or API calls, that throughput matters.
WireGuard's configuration model is refreshingly simple. Each node has a public/private key pair. You list which peers can connect and which IP ranges they're allowed to use. That's it. No certificate authorities, no TLS negotiation, no complex PKI infrastructure.
A peer is just a public key plus an allowed IP range. If the cryptographic identity doesn't match, the packet is dropped silently. There's no handshake to exploit if you're not authorized.
WireGuard uses UDP, which means it works through most NAT configurations and firewalls without special rules. It also handles roaming natively — if a server's IP changes, WireGuard re-establishes the connection automatically on the next packet.
But how does this compare to alternatives in practice? Let's break down the options.
| Feature | WireGuard | OpenVPN | IPSec/IKEv2 |
|---|---|---|---|
| Codebase size | ~4,000 lines | ~100,000 lines | ~400,000 lines |
| Kernel integration | Yes (Linux 5.6+) | No (userspace) | Yes (varies) |
| Protocol | UDP | UDP or TCP | UDP |
| Encryption | ChaCha20, Curve25519 | OpenSSL (configurable) | Configurable |
| Configuration | Simple key pairs | Complex certificates | Complex |
| Throughput | ~1,011 Mbps | ~258 Mbps | ~881 Mbps |
Throughput figures from WireGuard whitepaper benchmarks on identical hardware.
Kernel WireGuard handles packets entirely within the Linux kernel, achieving maximum throughput. Userspace implementations like boringtun — originally built by Cloudflare — run as regular processes, trading a small performance penalty for broader compatibility across platforms including macOS, containers, and older kernels.
The kernel module ships with Linux 5.6 and later. On older kernels, you can install it via DKMS. It processes packets at line speed with minimal CPU overhead.
Use kernel WireGuard when:
Boringtun and wireguard-go are userspace implementations. They create a TUN device and handle encryption in a regular process. Performance is still excellent — far better than OpenVPN — but slightly below the kernel module.
Use userspace WireGuard when:
We've run userspace WireGuard (boringtun) in production for inter-node communication. The throughput penalty compared to kernel WireGuard is barely noticeable for typical API and database traffic. The real advantage is operational simplicity — no kernel modules to install, no DKMS to maintain, no compatibility issues after kernel upgrades.
In a full mesh, every node connects directly to every other node, requiring N*(N-1)/2 connections — so 3 nodes need 3 tunnels, but 10 nodes need 45. The topology you choose depends on your cluster size, traffic patterns, and tolerance for single points of failure.
Node B
|
|
Node A --Hub-- Node C
|
|
Node D
All traffic routes through a central hub. Node B can reach Node C, but the packets travel through the hub first. This is the simplest to configure — each spoke only needs one peer entry (the hub), and the hub has entries for all spokes.
Pros: Easy to set up. Adding a new node means editing only the hub's config. Cons: The hub is a single point of failure. All inter-node traffic doubles (in to hub, out from hub). The hub's bandwidth caps your cluster's throughput.
Node A ---- Node B
| \ / |
| \ / |
| \ / |
| \/ |
| /\ |
| / \ |
| / \ |
| / \ |
Node D ---- Node C
Every node connects directly to every other. Traffic takes the shortest path. No single point of failure. If Node A goes down, B, C, and D still communicate freely.
Pros: Resilient. Lowest latency. No bandwidth bottleneck. Cons: Configuration scales quadratically. Adding one node means updating every existing node's config.
Group nodes by region or function. Nodes within a group form a full mesh. Groups connect through gateway nodes. This balances resilience against configuration complexity.
For most setups with 2-5 servers, full mesh is the way to go. The configuration burden is manageable, and you get the best performance and resilience. Beyond 10 nodes, you need automation.
A 3-node WireGuard mesh requires generating key pairs on each server, assigning private IPs, and configuring peer entries — a total of 6 peer entries across 3 config files. According to the WireGuard documentation, the entire setup process per node takes just a few commands.
We've timed this process across fresh Ubuntu 22.04 and 24.04 servers. On average, a manual 3-node mesh takes 12-15 minutes if you know what you're doing, and about 30 minutes the first time. Most of that time is spent copying keys between servers.
On Ubuntu/Debian:
sudo apt update && sudo apt install -y wireguard
On RHEL/Fedora:
sudo dnf install -y wireguard-tools
Verify the installation:
wg --version
Run this on each of your three servers:
wg genkey | tee /etc/wireguard/privatekey | wg pubkey > /etc/wireguard/publickey
chmod 600 /etc/wireguard/privatekey
Record the keys. You'll need the public key from every node on every other node.
cat /etc/wireguard/publickey
# Example output: aB3dE5fG7hI9jK1lM3nO5pQ7rS9tU1vW3xY5zA7bC=
Pick a private subnet. We'll use 10.0.0.0/24:
| Node | Private IP | Public IP (example) |
|---|---|---|
| Server A | 10.0.0.1 | 203.0.113.1 |
| Server B | 10.0.0.2 | 198.51.100.2 |
| Server C | 10.0.0.3 | 192.0.2.3 |
Server A (/etc/wireguard/wg0.conf):
[Interface]
PrivateKey = <Server A private key>
Address = 10.0.0.1/24
ListenPort = 51820
[Peer]
# Server B
PublicKey = <Server B public key>
Endpoint = 198.51.100.2:51820
AllowedIPs = 10.0.0.2/32
PersistentKeepalive = 25
[Peer]
# Server C
PublicKey = <Server C public key>
Endpoint = 192.0.2.3:51820
AllowedIPs = 10.0.0.3/32
PersistentKeepalive = 25
Server B (/etc/wireguard/wg0.conf):
[Interface]
PrivateKey = <Server B private key>
Address = 10.0.0.2/24
ListenPort = 51820
[Peer]
# Server A
PublicKey = <Server A public key>
Endpoint = 203.0.113.1:51820
AllowedIPs = 10.0.0.1/32
PersistentKeepalive = 25
[Peer]
# Server C
PublicKey = <Server C public key>
Endpoint = 192.0.2.3:51820
AllowedIPs = 10.0.0.3/32
PersistentKeepalive = 25
Server C (/etc/wireguard/wg0.conf):
[Interface]
PrivateKey = <Server C private key>
Address = 10.0.0.3/24
ListenPort = 51820
[Peer]
# Server A
PublicKey = <Server A public key>
Endpoint = 203.0.113.1:51820
AllowedIPs = 10.0.0.1/32
PersistentKeepalive = 25
[Peer]
# Server B
PublicKey = <Server B public key>
Endpoint = 198.51.100.2:51820
AllowedIPs = 10.0.0.2/32
PersistentKeepalive = 25
On each server:
sudo wg-quick up wg0
sudo systemctl enable wg-quick@wg0
From Server A:
ping -c 3 10.0.0.2
ping -c 3 10.0.0.3
Check the WireGuard status:
sudo wg show
You should see recent handshakes and transferred bytes for each peer. If a peer shows no handshake, double-check the endpoint IP, port, and firewall rules (UDP 51820 must be open).
Adding node #4 to a 3-node mesh means editing config files on all 3 existing servers and restarting their WireGuard interfaces. At 10 nodes, you're managing 45 individual peer entries. According to NIST SP 800-57, key management complexity is a leading cause of cryptographic implementation failures — and manual WireGuard meshes hit this wall fast.
| Nodes | Connections | Config Changes to Add 1 Node |
|---|---|---|
| 3 | 3 | Edit 3 files |
| 5 | 10 | Edit 5 files |
| 10 | 45 | Edit 10 files |
| 20 | 190 | Edit 20 files |
Every config change means restarting the WireGuard interface, which briefly drops existing connections. In a production mesh, that's downtime across your entire cluster.
Manual key distribution is error-prone. Copy a public key incorrectly, and two nodes can't establish a tunnel. Forget to add a peer to one node, and you get asymmetric connectivity — A can reach D, but D can't reach A. These bugs are maddening to debug because WireGuard silently drops packets from unknown peers.
The real scaling issue isn't the number of config files — it's the blast radius of a mistake. In a 10-node mesh, one typo in a key can break connectivity for multiple nodes, and there's no centralized view to tell you where the problem is. You end up SSH-ing into every server and running wg show one by one. That's why centralized key exchange isn't a nice-to-have. It's a necessity.
Several projects solve this problem:
Each trades some flexibility for operational sanity. The question is how much control you want to give up.
Temps embeds userspace WireGuard directly in its binary using boringtun via the defguard_wireguard_rs Rust crate — no system packages, no kernel modules, no manual configuration. A single temps join --relay command sets up an encrypted tunnel between a worker node and the control plane.
Traditional WireGuard setup requires wireguard-tools and either a kernel module or userspace daemon. Temps compiles boringtun directly into the binary. When you run temps join, it creates a TUN device and handles encryption in-process. Nothing to install. Nothing to configure.
# That's it. WireGuard tunnel established.
temps join --relay
Manual WireGuard means generating keys on each server and copying public keys everywhere. Temps handles this through its API. When a worker joins, it generates a Curve25519 key pair using x25519-dalek and sends its public key to the control plane. The control plane responds with its own public key and connection parameters. No SSH-ing between servers. No shared documents listing keys.
Many servers sit behind NAT — especially in cloud environments or home labs. With manual WireGuard, you need a publicly reachable endpoint on at least one side of every tunnel. Temps relay mode solves this by routing through the control plane's WireGuard endpoint, so workers behind NAT can establish tunnels without port forwarding.
| Aspect | Manual WireGuard | Temps |
|---|---|---|
| Key generation | wg genkey on each server | Automatic (x25519-dalek) |
| Key distribution | Copy/paste between servers | API-based exchange |
| Config files | One per node, manually written | None (embedded) |
| Adding a node | Edit all existing configs | temps join --relay |
| NAT traversal | Requires public endpoints | Relay mode handles it |
| System dependencies | wireguard-tools, kernel module | None (single binary) |
We switched from manual WireGuard configs to embedded boringtun specifically because of the scaling problem. With 5+ nodes, the manual key distribution was eating 15-20 minutes every time we added a server. Now it's one command and roughly 10 seconds.
Yes, significantly. WireGuard achieves roughly 1,011 Mbps throughput compared to OpenVPN's 258 Mbps in the same benchmark environment (WireGuard whitepaper). The difference comes from WireGuard's in-kernel implementation on Linux 5.6+, which avoids the userspace-to-kernel context switching that slows OpenVPN down. For inter-server traffic, this gap translates to lower latency and less CPU overhead.
WireGuard works behind NAT in most cases, but with a catch. The node behind NAT can initiate connections to peers with public endpoints, but peers can't initiate connections back unless keepalives are enabled. Set PersistentKeepalive = 25 in your config to maintain the NAT mapping. For double-NAT situations where neither side has a public IP, you need a relay node or a coordination service that provides STUN/TURN-like functionality.
For a manual mesh, you need to generate a key pair on the new node, then edit the WireGuard config file on every existing node to add the new peer's public key and endpoint. After updating configs, restart the WireGuard interface on each server with wg-quick down wg0 && wg-quick up wg0. In a 10-node mesh, that means editing 10 files and restarting 10 tunnels — which is why automated tools like Tailscale, Netmaker, or Temps exist.
WireGuard is a VPN protocol — it handles encrypted tunnels between two endpoints. Tailscale is a management layer built on top of WireGuard that automates key distribution, NAT traversal (via DERP relay servers), and mesh topology. Think of WireGuard as the engine and Tailscale as the car. You can drive the engine directly (manual config), or let a management layer handle the operational complexity. Tailscale is SaaS-hosted by default; self-hosted alternatives include Headscale and Temps.
WireGuard fully supports IPv6. You can assign both IPv4 and IPv6 addresses to the WireGuard interface and include IPv6 ranges in AllowedIPs. This is useful for dual-stack deployments where internal services need to be reachable over both protocols. The configuration syntax is identical — just add an IPv6 address alongside the IPv4 one in your Address field.
WireGuard gives you encrypted private networking between any servers, anywhere. For 2-3 nodes, the manual setup takes 15 minutes and works perfectly. Beyond that, the N-squared configuration problem will push you toward automation.
The core concept stays the same regardless of tooling: Curve25519 key pairs, UDP tunnels, cryptokey routing. Understanding the manual process makes you better at debugging any WireGuard-based tool, whether that's Tailscale, Netmaker, or an embedded solution.
If you want the mesh without the configuration overhead, Temps bundles userspace WireGuard into a single binary. One command on each worker, and the control plane handles key exchange and tunnel setup automatically:
curl -fsSL temps.sh/install.sh | bash
For the full WireGuard protocol specification, see the WireGuard whitepaper. For Temps multi-node setup, check the edge nodes documentation.