Architecture: Tech Stack
Firezone has a unique mix of data throughput, reliability, and scability challenges. 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 scalability.
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:
Ops and infrastructure
Firezone uses the following tools for ops and infrastructure:
Category | Tool/Service |
---|---|
Cloud provider | Google Cloud Platform |
Source code management | GitHub |
CI/CD | GitHub Actions |
Monitoring and alerting | Google Cloud Monitoring |
Logging | Google Cloud Logging |
Persistence store | Google Cloud SQL (PostgreSQL) |
Infrastructure as code | Terraform |
Regional availability
The Firezone-managed components are deployed globally across the following GCP zones for load balancing and latency optimization:
City | Region | Zones |
---|---|---|
Changhua, Taiwan | asia-east1 | asia-east1-a |
Mumbai, India | asia-south1 | asia-south1-a |
Sydney, Australia | australia-southeast1 | australia-southeast1-a |
Warsaw, Poland | europe-central2 | europe-central2-c |
Hamina, Finland | europe-north1 | europe-north1-c |
Saint-Ghislain, Belgium | europe-west1 | europe-west1-d |
London, UK | europe-west2 | europe-west2-c |
São Paulo, Brazil | southamerica-east1 | southamerica-east1-b |
Council Bluffs, Iowa | us-central1 | us-central1-b |
Moncks Corner, South Carolina | us-east1 | us-east1-d |
Los Angeles, California | us-west2 | us-west2-b |
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:
- Discussion forums: Ask questions, report bugs, and suggest features.
- Discord server: Join discussions, meet other users, and chat with the Firezone team
- Email us: We read every message.