Skip to content
The Gateway

Sizing & performance

Choose hardware against the workload you will actually run: required throughput, simultaneous flows, tunnel protocol, privacy settings, DNS traffic and retention. A device count or advertised network-port speed is not enough to predict capacity.

The v2.13.1 release reports functional and leak-check results on two reference nodes. Those are not throughput benchmarks. See Performance evidence & release verification for the scope and a reproducible test procedure.

Throughput envelopes

Section titled “Throughput envelopes”

There is no measured hardware-throughput table on this page. Use these starting points to select a candidate, then benchmark it:

Candidate Useful starting point What to validate
Raspberry Pi 4 A home or lab gateway where you can test against a known workload Sustained tunnel throughput, temperature, power and interface topology
Raspberry Pi 5 A newer Pi-based deployment Cooling, power supply, storage, and whether the actual bottleneck improves
x86 mini-PC A gateway needing multiple NICs or more compute options Exact CPU, NIC drivers, sustained load and power use
Linux VPS A remote exit, bridge or federated node CPU contention, transfer quota, provider policies and remote-exit latency

Measure direct routing first, then each protected path. A tunnel can be limited by the gateway, the remote peer, the ISP, MTU, queueing or configured shaping. Buying a faster CPU will not remove a configured rate limit.

Privacy levels and shaping

Section titled “Privacy levels and shaping”

Higher privacy settings may add shaping, padding and cover traffic. Inspect the effective configuration and traffic-splitting settings before interpreting a speed test.

For example, if a tunnel is configured with a 10 Mbit/s ceiling, a claim of 50 Mbit/s of payload through that same shaped tunnel is inconsistent. Payload throughput can be lower than the configured ceiling because of protocol overhead and competing traffic.

Several exits do not automatically multiply the speed of one connection. Per-connection selection, shared uplinks, endpoint capacity and shaping determine the aggregate result.

WireGuard can use multiple CPU cores on Linux; do not assume one tunnel always equals one saturated core. Measure CPU use and the actual forwarding path on the target host.

Memory & storage

Section titled “Memory & storage”

Budget for the Linux host as well as gatewayd, DNS services, active connections, tunnel or bridge processes, and logs. There is no fixed memory cost per device or policy established by the release checks.

Watch these signals under a representative load:

  • Resident memory and available host memory over time.
  • Swap activity and out-of-memory events.
  • DNS cache/query-log growth and audit retention.
  • Database and log disk usage, including temporary backup space.
  • Storage latency, I/O errors and sustained write volume.

Use reliable storage, retain enough free space for updates and backups, and verify that a backup can be restored. On flash media, consider log retention and volatile logging deliberately; volatile logs are lost on reboot and are not a replacement for persistent configuration backups.

CPU budget

Section titled “CPU budget”

CPU demand depends on packet rate, packet size, encryption, active connections, policy complexity and enabled privacy features. A large-file transfer and many small interactive requests can stress the same gateway differently.

Run both your expected steady workload and a peak-load test. Record per-core utilization, temperature or throttling, latency, packet loss and throughput. Keep headroom for DNS, the management UI and configuration reconciliation.

When to scale up

Section titled “When to scale up”

Consider different hardware or topology when measurement shows:

  • CPU saturation limits throughput below your required rate and configured shaping ceiling.
  • Memory pressure causes sustained swapping or terminated processes.
  • Reconciliation cannot keep up with changes.
  • Storage errors or latency impair state persistence.
  • Your network needs more physical interfaces, redundancy or a faster recovery path.

More devices alone is not a sufficient trigger: an idle IoT device and a high-throughput client impose very different loads. Compare candidates using the same test and settings; do not assume a fixed multiplier between Pi generations or CPU families.

Splitting clients across gateways may distribute workload, but federation is not a guarantee of automatic failover or increased single-flow bandwidth. See the hybrid lab use case.

Bridge-node sizing

Section titled “Bridge-node sizing”

For a remote bridge, measure concurrent connections, handshake/reconnect rates, traffic volume and latency. Check the provider’s sustained bandwidth policy and monthly transfer quota as well as CPU and memory.

There is no universal price tier or client count that guarantees capacity. Start with a controlled workload and resize based on observed saturation or quota consumption.

Disk I/O

Section titled “Disk I/O”

Configuration changes, audit logs, optional DNS logs and SQLite activity all contribute writes. Check the actual install profile and logging configuration instead of assuming every directory is volatile or that write volume is negligible.

Investigate storage errors before increasing load or attempting upgrades. A service restart does not repair an unavailable backing device.

Section titled “Related”