cloudparts

Firezone

Zero-trust access over WireGuard: a hosted control plane decides who may reach each private host, subnet or DNS name, and Gateways you run inside the network connect out to approved clients.

What it is
Remote access
Used for
Sans-I/O protocols
Type
Commercial product
Made by
Firezone, Inc.
License
Apache 2.0 for the clients, Gateway and Relay; Elastic License 2.0 for the Elixir admin portal and control plane
Facts checked
24 October 2026
Website Source code

What it is

Firezone has three parts. You run Gateways, small Rust binaries with no persistent storage, inside each private network (a Site), as Docker containers or systemd services. Users install the Firezone Client on Windows, macOS, Linux, iOS or Android, or run a headless client on servers, which can sign in with a service-account token. Firezone runs the rest as SaaS: the admin portal, the control plane API and the policy engine, written in Elixir and Phoenix and hosted on Azure, plus STUN/TURN relays in several regions. You define Resources (an IP, a CIDR range, or a DNS name such as *.corp.example.com) and Policies that say which identity-provider group may reach which Resource. Access is denied unless a Policy allows it.

Traffic doesn’t pass through a central VPN server. The client contains a small DNS resolver: when an app looks up a protected name, it gets a placeholder address, and the first packet to it triggers a request to the policy engine. If a Policy allows it, the control plane hands WireGuard keys to the client and to a nearby Gateway, and the two punch through NAT to talk directly, falling back to a relay that can’t decrypt the traffic. Gateways and clients only open outbound connections, so no inbound firewall ports are needed, and session keys rotate every two minutes. Since August 2026 the connection checks also travel inside WireGuard, so an observer sees nothing on the wire but WireGuard packets.

The code is on GitHub: the data plane is Apache 2.0 and the portal is under the Elastic License 2.0. Self-hosting is allowed but production self-hosting is not supported, and published clients are only guaranteed to work with the managed service. Plans in October 2026: Starter is free for up to 6 users, Team is $5 per user a month, Business is $8 per user a month and adds directory sync with Google, Entra ID and Okta, device posture checks and log sinks, and Enterprise is custom. A REST API, a Terraform provider and a CLI arrived in 2026.

Why teams pick it

  • Users get access to specific hosts, subnets or DNS names rather than a whole network, decided per Resource by group-based Policies
  • Direct, end-to-end encrypted WireGuard connections between client and Gateway, with relays only as a fallback, so there is no central VPN concentrator to size
  • No inbound ports: Gateways dial out, and stateful cloud firewalls (security groups, NSGs, GCP rules) need no changes
  • Gateways are stateless and configured by one token; running several per Site gives high availability, and capacity grows by adding more

Watch out for

  • The control plane is Firezone’s SaaS: production self-hosting isn’t supported, so sign-in and policy changes depend on Firezone’s service
  • Not entirely open source: the portal and control plane are under the Elastic License 2.0, not an OSI licence
  • Directory sync, device posture checks and log sinks need the Business plan or higher, and Business caps an account at 1,000 users and 200 Sites
  • It works at layer 3, deciding which addresses a device can reach; it doesn’t record sessions or hand out per-session credentials the way identity-aware proxies such as Boundary do

Alternatives

What all remote access have in common →Compare side by side →
Cloudflare AccessCommercialThe identity-aware proxy in Cloudflare One: every request to a protected app must carry a signed token that says who the user is and that a policy allowed them in.Cloudflare TunnelCommercialA small daemon, cloudflared, dials out from your network to Cloudflare, so servers can be published or reached privately with no public IP and no open inbound ports.HashiCorp BoundaryCommercialAn identity-aware proxy: users sign in once and get one proxied session to one private host or database, with credentials fetched per session.ngrokCommercialA small agent dials out from your laptop, server or cluster to ngrok’s network, which gives the service a public URL and carries its traffic back down that connection.

How it fits with other technologies

docker-compose.yml: a Firezone Gateway inside a private network · yaml

services:
  firezone-gateway:
    image: "ghcr.io/firezone/gateway:1"
    environment:
      # The single-owner token shown when you deploy a Gateway in the admin portal
      FIREZONE_TOKEN: <token>
      RUST_LOG: info
    volumes:
      - /var/lib/firezone:/var/lib/firezone   # flow log spool and generated ID
    cap_add:
      - NET_ADMIN
    init: true
    sysctls:
      - net.ipv4.ip_forward=1
      - net.ipv4.conf.all.src_valid_mark=1
      - net.ipv6.conf.all.disable_ipv6=0
      - net.ipv6.conf.all.forwarding=1
      - net.ipv6.conf.default.forwarding=1
    devices:
      - /dev/net/tun:/dev/net/tun
# Outbound only: HTTPS 443 to the control plane, UDP to relays and clients. No inbound ports.

See it in a real stack

No architecture uses Firezone yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2020–2026

Jamil Bou Kheir, a former Cisco engineer, wanted an easy way to deploy and manage a WireGuard VPN. WireGuard supplies the tunnel but leaves key distribution, user management and routing tables to you, which he called “tedious and error-prone”. He left his job and built Firezone in Elixir and Phoenix: a self-hosted WireGuard VPN server with a web UI. It launched on Hacker News in 2021, was backed by Y Combinator, and by mid-2023 had more than 3,000 known running instances.

In July 2023 he announced Firezone 1.0, “an entirely new product with a brand new architecture”. A perimeter VPN trusts everyone once they are inside, so one stolen credential can expose the whole network. Firezone 1.0 instead brokers access to each resource: the protected side sits behind its firewall, keeps an outbound control channel to Firezone, and connects out to a client only after a policy allows it. The control plane became a hosted service with native clients for every platform.

Firezone 0.7, renamed Firezone Legacy, stopped getting updates after 31 January 2024, and 1.0 became generally available on 1 April 2024 with a $5-per-user Team plan. In 2026 the company shipped a redesigned portal, a REST API, a Terraform provider, a CLI and a Business plan, and removed ICE from the data path so that only WireGuard packets appear on the wire.

Why it’s built this way

Build on WireGuard
WireGuard is a small, fast, well-reviewed tunnel protocol in every major OS. What it lacks is key distribution, user management and routing, which is exactly what Firezone adds.
Broker access per resource instead of running a VPN server
A perimeter VPN grants the whole network after one login. Letting a policy engine approve each resource, and having the protected side connect outward, removes both broad access and open inbound ports.
A hosted control plane, open data plane
Running the portal as a service let a small team ship native clients, high availability and fast policy updates; the Rust clients, Gateway and relay stay Apache 2.0 so the parts that touch your traffic can be inspected.
Keep control-plane and data-plane state apart
Packet processing should never wait on a control message, and existing connections should survive a control-plane outage.

Timeline

  1. 2020

    Repository created; Firezone starts as a self-hosted WireGuard VPN server

  2. 2021

    Launches on Hacker News; later backed by Y Combinator

  3. 2023

    Firezone 1.0 announced in July as a zero-trust access platform with a hosted control plane

  4. 2024

    Firezone Legacy (0.7) end of life in January; 1.0 generally available in April

  5. 2026

    REST API, Terraform provider, CLI and Business plan; ICE removed so only WireGuard is on the wire

Sources15 · facts checked 24 October 2026

Improve this page on GitHub