# Firezone: Identity-Based Remote Access on a Shared Rust Data Plane

> Firezone pairs an Elixir control plane with a Rust WireGuard data plane, then leans on identity, device attestation and policy conditions to decide who reaches which Resource.

**firezone/firezone** — Blazing-fast remote access

- Repository: https://github.com/firezone/firezone
- Website: https://www.firezone.dev
- Stars: 9,122 · Forks: 465
- Language: Elixir
- License: Apache-2.0
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/firezone-firezone

## One repository, two runtimes

Firezone describes itself as remote access built on WireGuard with identity-based policies, attested device trust and audit logs, and the repository layout makes the architecture visible at a glance. `elixir/` holds the portal, which is the control plane where users, groups, Resources and policies live. `rust/` holds the shared data plane plus the GUI client, and `swift/` and `kotlin/` hold the Apple and Android clients. `docker-compose.yml`, `mise-tasks/` and `flake.nix` cover local development, and `policy-templates/` keeps policy examples out of the application code.

The primary language on the repository is Elixir, which fits a control plane that is mostly request handling, authorization and long-lived connections, while the packet path is Rust everywhere so that one implementation serves desktop, mobile and headless builds. The README points at separate architecture documentation for the control plane, data plane and connection lifecycle, which is a reasonable split for a project this size.

## Policies, groups and Resources

Access is expressed as policy, not as network topology. A policy grants a group access to a specific Resource, and the Resource is what gets reached: an application, a database, a server or a subnet. That framing is what makes the product different from a tunnel that simply joins you to a network, because a granted group can reach one host on that network and nothing else.

Policies also carry conditions, and the condition that gets the most attention is device attestation, which can be required in addition to user authentication. Two consequences follow. Revocation is an identity operation, since removing a user from a group takes effect without rewriting a config file on any endpoint. And the audit story stays central, because the README describes tracking configuration changes, sessions, API requests and traffic flows with 90-day retention and export to a SIEM through Log Sinks.

## Device Trust means a second factor you can verify cryptographically

User authentication answers who is asking. Device Trust answers whether the machine asking is one your organisation issued. The mechanism is X.509 certificate verification using certificates from your MDM or enterprise PKI, so the check is a chain validation rather than an agent reporting good health.

That distinction matters when a laptop is stolen or a device is handed to someone else. With attestation required as a policy condition, a valid session on an unmanaged machine fails at the point of connection instead of producing a session you discover later in an audit log. Since the certificate comes from infrastructure the organisation already runs, the deployment work is closer to enrolling laptops than to running new infrastructure.

## Device Pools take the gateway out of the path

Most remote access traffic follows the same shape: a client connects to a gateway deployed near the resource, and the gateway enforces policy on behalf of both sides. Device Pools offer a second shape, a peer-to-peer mesh of devices with encrypted client-to-client WireGuard tunnels and no gateway deployed. Policies still decide which groups can reach which devices in a pool, so the authorization model does not change even though the data path does.

This is the feature that changes deployment topology for teams supporting field devices or peer collaboration, since the traffic no longer has to hairpin through infrastructure someone has to operate. The README also introduces Relays, which carry encrypted traffic when a direct connection cannot be established, so a symmetric NAT or a restrictive corporate network degrades into a relay hop rather than a failed session.

## Where the performance work lives

The performance section is unusually specific, which makes it worth reading closely rather than skimming the headline number. The README credits a shared Rust data plane that combines WireGuard encryption with platform-specific I/O work to reduce system calls, task wake-ups and per-packet overhead, and the published throughput table is labelled as figures from the project's own testing: 2 Gbps or better on iOS and Android, 3 Gbps on Windows, 4 Gbps on macOS, and 5 Gbps on commodity Linux VMs or 10 Gbps on tuned hardware. The same section is careful to note that throughput varies with round-trip latency, packet loss, hardware and workload.

The per-platform detail is the interesting part. On macOS and iOS, readiness goes through kqueue via Tokio and Mio with batched `sendmsg_x` and `recvmsg_x` calls on both UDP sockets and the `utun` interface, plus a cache of connected UDP sockets to reach Darwin's fast send path. On Windows, packets are batched to and from WinTUN with TCP coalescing before injection into the ring buffer. The pattern is consistent: batch the syscalls rather than make them per packet.

## Deploying gateways and running your own

Gateways run in your infrastructure, and the README recommends deploying them near the Resources they serve, across cloud and on-premises environments, using several gateways for load balancing and failover. Sizing guidance lives in the documentation rather than in the repository, which is reasonable given that gateway capacity depends on the networks it fronts.

The self-hosting story has a clear boundary. The licenses permit self-hosting subject to their terms, and the README says plainly that production self-hosting is not officially supported, with `CONTRIBUTING.md` being the route for a local evaluation environment. It also warns that published clients are only guaranteed to work with the managed service, because internal APIs change and app store releases can lag the repository, which means a self-hosted portal may need clients built from a compatible revision. Build instructions exist for the Apple, Android and Rust GUI clients, so that path is open source work rather than guesswork.

For local work, the compose file wires the portal to Postgres and an Erlang cluster and exposes the web and API ports separately:

```yaml
  WEB_EXTERNAL_URL: http://localhost:8080/
  API_EXTERNAL_URL: http://localhost:8081/
    image: ${PORTAL_IMAGE:-ghcr.io/firezone/portal}:${PORTAL_TAG:-main}
    hostname: portal.cluster.local
      RELEASE_HOSTNAME: "portal.cluster.local"
```

Client releases ship for each platform on its own cadence, and the last commits recorded on the repository are from late September 2026, with separate tags for the Apple, Android and headless clients.

## Conclusion

Firezone's repository is easier to understand once you accept that it holds two systems at once. The Elixir side owns identity, Resources, policies and audit records, and it is the part you configure; the shared Rust side carries WireGuard packets and is the part you tune, which is why the same codebase can claim multi-gigabit throughput on one platform and behave like an ordinary routed hop on another. Two design choices carry most of the weight. Policies attach to groups and Resources with optional conditions such as device attestation, so access decisions live in one place instead of in every client. Device Pools remove the gateway from the path for device-to-device traffic entirely. The caveat to plan around is stated in the README itself: published clients are only guaranteed against the managed service, so a self-hosted portal means building clients from a compatible revision.

## FAQ

### Is Firezone a VPN or a zero trust access layer?

It is WireGuard-based remote access with an identity layer on top. Policies grant a group access to a specific Resource rather than joining a device to an entire network.

### What does Device Trust check on a client?

It verifies an X.509 certificate issued by your MDM or enterprise PKI, so a policy can require cryptographic device verification in addition to user authentication.

### Can Firezone be self-hosted in production?

The licenses allow it subject to their terms, but the README states that production self-hosting is not officially supported. Published clients are only guaranteed against the managed service, so you may need to build clients from a compatible revision.

### What is a Firezone Device Pool?

A peer-to-peer mesh of devices using encrypted client-to-client WireGuard tunnels without a gateway, where policies still control which groups can reach the devices in the pool.

### How long are Firezone audit logs kept?

The managed service documents 90-day retention covering configuration changes, sessions, API requests and traffic flows, with export to a SIEM through Log Sinks.

## Sources

- [firezone/firezone on GitHub](https://github.com/firezone/firezone)
- [License: Apache-2.0](https://github.com/firezone/firezone/blob/main/LICENSE)
- [Project website](https://www.firezone.dev)
- [README](https://github.com/firezone/firezone/blob/main/README.md)
- [Releases](https://github.com/firezone/firezone/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/firezone-firezone