Gateway Sizing Guidelines

Use this guide to choose the right host for a Firezone Gateway and tune it for maximum throughput. For firewall ports and environment variables, see the Ports and protocols reference and the Gateway CLI reference.

Host requirements

• Any Linux distribution with kernel 3.10 or later
• x86_64, aarch64, or armv7l CPU architecture
• iptables and ip6tables commands available on your system
• Docker Engine or systemd installed, depending on your chosen install method

Sizing recommendations

The Gateway, like the rest of Firezone's data plane stack, is written in Rust, so it's extremely lightweight and computationally efficient by nature.

Gateways are mostly performance-bound by the I/O rate at which they can process packets, so bare-metal deployments or VMs with high I/O rates make a big difference in both throughput and latency.

The number of clients a Gateway can support depends heavily on your throughput requirements — available bandwidth is shared across all connected clients. A single Gateway on a 2-core dedicated vCPU VM can reliably handle up to 1,000 clients, assuming your link speed is sufficient. Throughput is also affected by latency to/from clients and whether connections are peer-to-peer or relayed (relayed connections carry additional overhead).

Gateways scale with CPU cores up to 4 cores, beyond which additional cores provide no benefit. Up to 4 GB of RAM can be used for packet buffers; more than that is not utilized. For ideal performance, we recommend at least 4 dedicated CPU cores.

A typical Gateway on a 4-core Linux machine with a recent kernel and sub-10ms round-trip latency should be able to push 2 Gbps+ of peer-to-peer WireGuard traffic. While the Gateway runs as a userspace binary, this is often on par with or faster than the kernel WireGuard module due to multithreading and offloading optimizations.

Gateways deployed to the Internet Site should always have at least 4 CPU cores.

High availability

For production workloads, we recommend deploying at least 3 Gateways per Site to ensure high availability during rolling upgrades and to distribute load across multiple machines. To scale beyond a single Gateway's capacity, deploy additional Gateways and use Firezone's automatic load balancing to shard Client connections across them.

Reuse the same FIREZONE_TOKEN (shown on the Manual tab of the Deploy a Gateway page) to deploy multiple Gateways in a Site — it's a multi-owner token. Be sure to set a unique FIREZONE_ID for each Gateway.

Performance tuning

The default receive and send buffer sizes on Linux are quite small, which can limit the maximum throughput your users can achieve.

The Gateway attempts to increase the system-wide UDP send and receive buffer max sizes to 16 and 128 MB respectively by setting net.core.wmem_max and net.core.rmem_max. This only works for Gateways deployed on bare metal, not via Docker (Docker mounts /proc/sys read-only). To disable this behavior, set FIREZONE_NO_INC_BUF=true.

To ensure good throughput, set these parameters explicitly:

sudo sysctl -w net.core.wmem_max=16777216 # 16 MB
sudo sysctl -w net.core.rmem_max=134217728 # 128 MB

Need help? See all support options.