Firezone

Firezone is an open-source zero-trust access platform that replaces legacy VPNs with secure, peer-to-peer connections built on WireGuard®. It enables organizations to grant least-privileged access to applications, subnets, and services without exposing them to the public internet. Designed for DevSecOps teams, IT administrators, and security engineers, Firezone addresses the performance bottlenecks and management complexity of traditional VPNs like OpenVPN by combining WireGuard’s speed with dynamic access policies and identity-aware authentication.

The platform is a polyglot monorepo with a clean architectural split: an Elixir/Phoenix control plane for admin UI, policy management, and identity provider integration, and a high-performance Rust data plane — the connlib library — that powers gateways, relays, and cross-platform clients. Connlib combines WireGuard (via boringtun) with ICE-based NAT traversal to establish direct, hole-punched tunnels between clients and resources without routing traffic through a central server.

Firezone supports self-hosting for non-production use and offers a managed cloud service with enterprise features including directory sync, audit logs, SOC 2 compliance, and SLA-backed support. Native clients are available for macOS, iOS, Android, ChromeOS, Windows, and Linux, all sharing the same Rust connlib core via UniFFI bindings.

What You Get

• WireGuard®-powered performance - Delivers 3-4x faster throughput than OpenVPN using the WireGuard protocol with ChaCha20/Poly1305 encryption and sub-10ms latency overhead.
• Peer-to-peer hole-punching - Establishes direct client-to-resource tunnels via ICE-based NAT traversal without routing traffic through a central relay, minimizing attack surface and latency.
• Granular access policies - Control access to individual applications, subnets, or DNS names using group-based rules with conditions for device posture, time of day, and location.
• SSO and directory sync - Authenticate via OIDC and automatically sync users and groups from Google Workspace, Okta, and Entra ID for seamless onboarding and offboarding.
• Universal client support - Native apps for macOS, iOS, Android, ChromeOS, Windows, and Linux sharing a common Rust connlib core via UniFFI bindings.
• Automatic gateway load balancing - Deploy multiple gateways for traffic distribution and transparent failover without manual configuration or downtime.
• Built-in STUN/TURN relay - Includes a custom eBPF-accelerated TURN relay server for environments where direct peer-to-peer connections cannot be established.
• Audit logs and compliance - Full activity logging for all connections, with 90-day retention and SOC 2 Type I and II compliance available in the managed cloud offering.

Common Use Cases

• Securing cloud infrastructure for remote teams - A DevOps team uses Firezone gateways deployed in AWS and GCP to grant policy-scoped access to internal services without opening public ports or managing complex security group ACLs.
• Zero-trust replacement for legacy VPN - A mid-sized company migrates from OpenVPN to Firezone to eliminate centralized VPN bottlenecks, enforce MFA via Okta, and restrict access to individual apps rather than entire subnets.
• Secure access to on-premises networks - An IT department deploys Firezone gateways on-prem to connect remote employees directly to internal databases, CI/CD systems, and file shares while keeping firewall rules closed to the internet.
• Service account and machine-to-machine access - A platform team issues non-interactive client tokens to CI runners and service accounts, enabling automated workloads to access production resources without exposing credentials.
• Contractor and vendor access management - A security team grants time-limited, resource-scoped access to external contractors through Firezone policies, automatically revoking access when the contract ends via directory sync.
• Multi-site network segmentation - A retail organization connects multiple branch networks through Firezone gateways, enforcing least-privilege access between sites without a full SD-WAN deployment.

Under The Hood

Architecture Firezone uses a deliberately split monorepo architecture that separates concerns across language and runtime boundaries. The Elixir control plane — a Phoenix LiveView application backed by PostgreSQL and Oban for background jobs — manages identity, access policies, gateway registration, and the admin UI. The Rust data plane is organized around a shared library called connlib, which implements a SANS-IO design: ICE-based NAT traversal (via the internal snownet library) and WireGuard tunneling (via boringtun) are composed in a single event loop that reads from TUN devices and UDP sockets on dedicated threads, with state management isolated from IO via bounded channels. Cross-plane communication happens over WebSocket-based Phoenix channels, keeping the control and data planes loosely coupled while maintaining real-time policy enforcement.

Tech Stack The control plane runs on Elixir with Phoenix 1.8, Phoenix LiveView for reactive admin UI, Bandit as the HTTP server, and Ecto with PostgreSQL for persistence and migrations. Background jobs are handled by Oban; observability uses OpenTelemetry with exporters for spans and metrics. The Rust data plane uses boringtun for WireGuard packet handling, stun_codec for STUN/TURN protocol implementation, and an eBPF-accelerated relay server for NAT traversal fallback. Cross-platform clients are built with Tauri for Windows and Linux GUI, Swift/SwiftUI for macOS and iOS, and Kotlin for Android and ChromeOS — all sharing the connlib Rust library via UniFFI foreign function bindings. Developer tooling is unified across languages via mise and enforced by pre-commit hooks.

Code Quality The codebase demonstrates strong engineering discipline across both language ecosystems. Elixir tests span over 220 test files covering unit, integration, and LiveView interaction scenarios; Rust has extensive unit tests, property-based tests using proptest, and fuzz testing targets. Ecto changesets enforce domain invariants with precise, user-facing error messages. Rust modules use Result-based error propagation throughout connlib with anyhow for contextual error chaining. Elixir code is checked with Dialyzer for type safety and Credo for style; Rust uses clippy with a custom configuration. CI enforces both static analysis and test runs before merging, and coveralls tracks test coverage on the Elixir side.

What Makes It Unique Firezone’s most technically distinctive element is the snownet library — a custom, SANS-IO implementation of ICE (Interactive Connectivity Establishment) layered on top of WireGuard, enabling on-the-fly hole-punched tunnels that bypass centralized routing. This is paired with a custom eBPF-accelerated TURN relay for environments where direct connections fail, making the data plane self-contained and not reliant on third-party STUN/TURN infrastructure. The use of UniFFI to compile a single Rust connlib core into native bindings for Swift, Kotlin, and Tauri GUI clients ensures protocol-level consistency across all platforms without maintaining separate implementations. The Elixir billing module integrates Stripe for usage-based seat enforcement directly in the control plane, and component version tracking prevents client-gateway incompatibilities at scale.

Self-Hosting

Firezone uses a dual-license model that varies by component. The Rust data plane (gateways, relays, clients) is licensed under Apache 2.0, meaning it can be used, modified, and distributed freely — including in commercial contexts — with standard attribution requirements. However, the Elixir control plane (the admin portal and API) is licensed under the Elastic License 2.0 (ELv2). ELv2 allows free use and modification but prohibits offering the software as a hosted or managed service to third parties. Practically speaking, a company can deploy Firezone’s control plane internally for their own employees without restriction; they cannot build a VPN-as-a-service product on top of it and charge customers for access to it.

Running Firezone yourself carries real operational weight. The control plane requires a PostgreSQL database with ongoing backup and migration management, a clustered Elixir deployment with libcluster for node discovery, an SMTP relay or Azure Communication Services integration for email, and a GeoIP database for the IP geolocation feature. The data plane requires one or more gateway servers deployed within your infrastructure, properly network-namespaced with elevated capabilities for WireGuard and TUN device management. Firezone explicitly states that production self-hosting is not officially supported — the internal APIs are evolving rapidly, and the published mobile clients (App Store and Google Play) are only guaranteed to work with the managed cloud service. Self-hosters must build and distribute their own clients, which adds a non-trivial mobile CI and signing pipeline.

The managed cloud offering (app.firezone.dev) adds substantially more than just hosting. It provides a production SLA, automatic upgrades across all components, guaranteed compatibility between published clients and the portal, 90-day audit log retention, SOC 2 Type I and II compliance attestations, directory sync with Google Workspace, Okta, and Entra ID (enterprise tier), and a dedicated Slack support channel. The Starter tier is free for up to six users; the Team tier runs at $5 per user per month; Enterprise pricing is negotiated. For teams where the engineering cost of managing a Kubernetes or VM deployment of a rapidly evolving Elixir/Rust stack outweighs the subscription cost, the cloud offering is the practical choice.