Managing a fleet of servers requires moving data between them: DNS zone files, SSL certificates, configuration updates, binary deployments. Doing this over the public internet exposes management traffic to interception and requires careful authentication at each endpoint.
We use WireGuard to build a private network across our servers. All internal traffic travels over this network.
What WireGuard Is
WireGuard is a VPN protocol built directly into the Linux kernel as of version 5.6. Unlike OpenVPN (which runs in userspace and handles its own cryptography) or IPsec (which is complex to configure correctly), WireGuard is extremely lean: around 4,000 lines of code, compared to 100,000+ for OpenVPN.
The cryptographic primitives are fixed: Curve25519 for key exchange, ChaCha20 for symmetric encryption, Poly1305 for authentication. There's no negotiation, no algorithm selection, fewer attack surfaces.
Our Fleet Topology
Our three servers — ember (primary), litespeed (NS2), and spark (NS3) — form a hub-and-spoke WireGuard network with ember at the centre.
Each server has a WireGuard keypair. The public keys are exchanged between servers during setup. The network uses the 10.0.x.x address range, isolated from the public internet.
When litespeed needs to communicate with ember, the packets travel encrypted over the public internet between the two servers' WireGuard endpoints. An observer on the network sees only encrypted UDP packets — not what's being transferred or where within the internal network it's going.
What We Use It For
DNS zone sync: When we update a DNS zone on ember (NS1), we sync the zone files to litespeed (NS2) and spark (NS3) over WireGuard. The transfer happens over the private network, not the public internet.
Binary deployment: When we deploy updated platform binaries to fleet nodes, they travel over the WireGuard network. The manifest and cryptographic signature travel with them and are verified on arrival.
Health monitoring: Our watchman service makes health check calls to fleet nodes over WireGuard. The check traffic is on the private network and doesn't consume public bandwidth.
Emergency access: If a server's public SSH becomes inaccessible (firewall rule, networking issue), we can reach it through the WireGuard network from any other server in the fleet.
Why Not Just Use SSH Tunnels
SSH tunnels are a common alternative for ad-hoc encrypted management traffic. WireGuard has several advantages:
- Persistent connections: WireGuard maintains tunnel state without requiring active sessions
- Lower overhead: WireGuard's UDP-based transport is more efficient than SSH's TCP-based tunnelling for high-frequency, low-latency traffic like health check pings
- Kernel integration: Running in the kernel means lower latency and no userspace process to crash or restart
- Simpler configuration: One configuration file per peer, not SSH config files scattered across the fleet
The result is a private network that's effectively invisible from outside, persistent without manual reconnection, and cryptographically sound by construction.