Deploy Gateways


Gateways are what Clients connect to in order to access Resources in a Site. They're the data plane workhorse of the Firezone architecture and are responsible for securely routing traffic between Clients and Resources.


  • 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 for your distribution

Firewall ports

Gateways implement the industry-standard STUN and TURN protocols to perform secure NAT holepunching. No inbound firewall ports need to be opened for Gateways to function.

If the network in which your Gateway is deployed applies egress filtering, you'll need to make sure the following outbound traffic is allowed:

HostIP AddressPort(s)Protocol(s)Purpose
api.firezone.dev34.102.202.25443HTTPS/WebSocketControl Plane API (IPv4)
api.firezone.dev2600:1901:0:620b::443HTTPS/WebSocketControl Plane API (IPv6)
N/ASee relay-ips.json3478STUNSTUN protocol signaling
N/ASee relay-ips.json49152-65535TURNTURN protocol channel data, www.firezone.devVaries443HTTPSOnly required for Gateway upgrades.

Where to deploy Gateways

Ideally, Gateways should be deployed as close to the Resources they're serving -- in some cases, even on the same host. This ensures the lowest possible latency and highest possible throughput for Client connections, and allows you to more easily deploy additional Gateways for other Resources that need to handle more Client connections.

The downside of deploying Gateways close to Resources is that it increases the overall number of Gateways and Sites you need to manage. Firezone's control plane is designed to make this as easy as possible, but it's still something to keep in mind when planning your deployment.

When deploying Gateways, remember that all Gateways and Resources in a Site must have unobstructed network connectivity to each other. This is necessary for Firezone's automatic failover and load balancing features to work correctly.

Sizing recommendations

The Gateway, like the rest of Firezone's data plane stack, is written in Rust. As a result, 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 will make a big difference in both throughput and latency.

Despite this, even tiny, shared vCPU VMs can perform acceptably well in many cases. An f1-micro instance with just 0.25 vCPU cores on Google Cloud, for example, can handle around 200 Mbps of sustained throughput.

Gateway sizeApprox. users servedCPU coresMemoryRecommended link speed
Micro10 - 501512 MB500 Mbps
Small50 - 10021 GB1 Gbps
Medium100 - 50042 GB2.5 Gbps

To go beyond the table above, you can deploy additional Gateways and use Firezone's automatic load balancing to distribute Client connections across them.

Deploy a single Gateway

Deploying a single Gateway can be accomplished in the admin portal.

We strongly recommend deploying a minimum of three Gateways in a Site for production use cases. This ensures high availability even when performing rolling upgrades.

Go to Sites -> <name of Site> -> Deploy a Gateway and follow the prompts to deploy for your preferred environment. This will deploy a single Gateway.

Deploy multiple Gateways

To achieve high availability, deploy two or more Gateways within the same Site. High availability is achieved through a combination of automatic failover and load balancing, both of which are available on all plans.

You can deploy multiple Gateways within a Site manually from the admin portal, or automate the process by reusing the FIREZONE_TOKEN environment variable shown on the Manual tab of the Deploy a new Gateway page. This is a multi-owner token that can be reused to deploy multiple Gateways within the same Site.

Note: Be sure to set a unique FIREZONE_ID for each Gateway you deploy. This can be any non-empty string and is used to identify Gateways in the portal.

Deploy as many Gateways as you need to handle the load of Client connections to Resources in a Site. This effectively shards Client connections across all Gateways in a Site, achieving higher overall throughput than otherwise possible with a single Gateway.

Deploy using Terraform

See our Terraform examples for deploying and scaling Gateways using Terraform on various cloud providers.

Keeping Gateways up to date

It's a good idea to keep your Gateways up to date with the latest version available. See upgrading Gateways for ways to automate this.

Need additional help?

See all support options or try asking on one of our community-powered support channels:

Or try searching the docs:
Last updated: June 10, 2024