Architecture: Tech Stack

Firezone has a unique mix of data throughput, reliability, and scability requirements. So we made sure to pick the right tools for the job. Here's a high-level overview of the tech stack choices we made and why.

Control plane

The control plane, which includes the admin portal, control plane API, and Policy Engine, is built using Elixir and Phoenix.

Elixir is a functional programming language that's received lots of attention in recent years for its performance and concurrency properties.

It's built on top of the Erlang VM, which has a reputation for being fault-tolerant and highly concurrent. Erlang continues to power some of the world's most reliable systems, including a wide variety of telecom equipment and messaging platforms like WhatsApp.

Together, these technologies power Firezone's realtime control plane API, allowing it to reliably handle thousands of policy decisions per second.

Data plane

The data plane, which includes the Clients, Gateway, and Relay, is built using Rust.

Rust is a systems programming language that's known for its performance and safety. Not only do its memory safety guarantees prevent entire categories of security vulnerabilities, but it also has an outstanding ecosystem of libraries and tools that make it a great choice for building performant network applications.

Client architecture

Some parts of the macOS, iOS, and Android applications can't be built in Rust, and so a foreign function interface (FFI) is used to call into either Swift or Kotlin code appropriately. In general, we strive to keep the FFI architecture as simple as possible, leaving Rust-land only when absolutely required.

Internally, the Clients maintain two primary types of state:

  • Control plane event loop
  • Data plane state machine

These manage the control path and hot paths of the Client, respectively. They interact through a thin software layer to exchange WireGuard keys and STUN information between the control plane API and the TUN interface.

Here's a high-level diagram of the various software components used in the Client applications:

Firezone client architecture diagram

The separation between control plane and data plane state serves two functions:

  • It ensures that control plane messages do not slow down or otherwise block the data plane processing loop.
  • It allows the Client to withstand temporary network partitions from the control plane API without dropping data plane packets. This means, for example, existing connections to Resources continue to operate uninterrupted even as we deploy new versions of the control plane API.

Ops and infrastructure

Firezone uses the following tools for ops and infrastructure:

Cloud providerGoogle Cloud Platform
Source code managementGitHub
CI/CDGitHub Actions
Monitoring and alertingGoogle Cloud Monitoring
LoggingGoogle Cloud Logging
Persistence storeGoogle Cloud SQL (PostgreSQL)
Infrastructure as codeTerraform

Regional availability

The Firezone-managed components are deployed globally across the following GCP zones for load balancing and latency optimization:

Changhua, Taiwanasia-east1asia-east1-a
Mumbai, Indiaasia-south1asia-south1-a
Sydney, Australiaaustralia-southeast1australia-southeast1-a
Warsaw, Polandeurope-central2europe-central2-c
Hamina, Finlandeurope-north1europe-north1-c
Saint-Ghislain, Belgiumeurope-west1europe-west1-d
London, UKeurope-west2europe-west2-c
São Paulo, Brazilsouthamerica-east1southamerica-east1-b
Council Bluffs, Iowaus-central1us-central1-b
Moncks Corner, South Carolinaus-east1us-east1-d
Los Angeles, Californiaus-west2us-west2-b
Firezone regional availability diagram

For an accurate, up-to-date list of regions we are deployed in, refer to our Terraform configuration.

Need additional help?

Try asking on one of our community-powered support channels:

Or try searching the docs:
Last updated: May 06, 2024