How to Use Firezone: The Beginner's Guide (First Deploy, First Gateway, First Policy, and the Self-Host Reality Check)

CodexFuse Team · 2026-10-31T03:57:27.257Z · 16 min read

Learn how to use Firezone: pass the self-host reality check, deploy your first gateway, add resources, write your first policy, and connect your first client.

How to Use Firezone: The Beginner's Guide (First Deploy, First Gateway, First Policy, and the Self-Host Reality Check)

Learning how to use Firezone is the fastest way to give people secure access to your servers and private network without running a legacy VPN. Firezone is an open-source zero trust network access (ZTNA) platform built on WireGuard, which the Firezone docs describe as up to 4-6x faster than OpenVPN. Using it means one beginner arc: create a Firezone account, deploy a self-hosted Gateway into the network you want to share, add Resources, write your first Policy, and connect your first client. This Firezone tutorial walks that entire arc in one sitting — and it starts with the self-host reality check, because Firezone's split architecture surprises almost every beginner who arrives with old self-host guides open in another tab.

You will build in this order: pass the self-host reality check, create your account, deploy your first Gateway with one Docker command, add your first Resource, write your first Policy under the default-deny rule, connect your first client, then wire up SSO and understand the pricing. Once that first client connects and your Resources appear, verify the connection is clean the same way you would check any VPN — a free VPN leak test is the fastest way to confirm your IP, DNS, and WebRTC traffic are routing through Firezone and not leaking around it.

How do you use Firezone? (The 60-second version)

Here is the complete beginner arc — six steps from zero to a working zero-trust network, straight from Firezone's own quickstart:

1. Sign in to your Firezone Admin Portal: create a free account at app.firezone.dev (US) or eu.app.firezone.dev (EU) and sign in with email.
2. Create a Site: Sites hold the Gateways and Resources that share a network context — think "US-West" or "Chicago-office."
3. Deploy a Gateway: click Deploy a Gateway on the Site page, pick the Docker or systemd tab, and run the generated command on a server inside that network.
4. Add a Resource: register anything the Gateway can reach — a server IP, a domain name, or a whole CIDR range.
5. Create a Policy for each Resource: access is default-deny, so nothing works until a Policy explicitly grants a user group access to the Resource.
6. Install the Firezone Client and sign in: download the client for your platform, sign in with your account slug, and your Resources appear.

Everything in this guide changes nothing about your existing infrastructure — Firezone is an overlay network, so it can bolt fine-grained access control onto a network you already have, and it can run alongside your existing VPN while you migrate at your own pace.

Can you self-host Firezone? The reality check comes first

You cannot self-host the whole Firezone platform — and understanding this saves you from the most common beginner trap. Firezone uses a split control plane and data plane architecture: the data plane components (Clients and Gateways) are specifically designed to be self-hosted, but the control plane — key distribution, user authentication, policy enforcement — is not, because of its reliability, security, and persistence requirements.

Here is what that means in practice. Your traffic never lives on Firezone's servers: it is always end-to-end encrypted, routes directly to Gateways on your infrastructure by default, and only passes through Firezone's global relay network in the rare case a direct connection cannot be established. Firezone states it can never decrypt or see your traffic's contents. The managed control plane at app.firezone.dev handles the admin portal, identity, and policy coordination — that is the part you do not host.

The source code is 100% open source and the license does not prevent you from self-hosting Firezone without limits for your organization. But Firezone provides no support or documentation for self-hosted deployments, and the current docs recommend full-stack self-hosting only for hobby or educational purposes. So the honest way to state "firezone self host" in 2026 is: self-host the data plane (Gateways and Clients) on your own infrastructure — every paid and free plan works this way — and use the managed control plane for everything else. Do not follow the old 2021-era guides (the Docker Compose stacks with their own Postgres, admin passwords, and Let's Encrypt configs) that still rank in search results — they document a retired architecture.

What do you need before you start?

Three things, and the whole Firezone setup takes less than 10 minutes. First, a Firezone account — sign up free; the Starter plan needs no credit card. Pick the US (app.firezone.dev) or EU (eu.app.firezone.dev) region when you register. Second, something worth sharing: a prod server, a database, a SaaS app, or an entire subnet. Third, a server or VM that can reach both that Resource and the internet, and that can run a Docker container or a Linux binary — you do not need specialized networking expertise.

That third item usually means a small VPS. If you do not have one yet, read what is VPS hosting to pick the right size — the Gateway itself is a lightweight Rust binary, so you do not need a big machine for a first deployment.

How do you install Firezone? Deploying your first Gateway

Installing Firezone really means deploying a Gateway: this is the one genuinely "self-hosted" step, where you run Firezone's software on a machine inside the network you want to share. The Firezone install flow starts in the admin portal, not on the command line: log in, create a Site first — Firezone auto-generates a name, but rename it to something real like "Production" or "US-West" — then click Deploy a Gateway on the Site Details page to get the generated command for your first Firezone Gateway.

You get two deployment options: Docker or systemd. The Firezone Docker path is the fastest for most beginners: pick the Docker tab and the portal generates a ready-to-run command containing your FIREZONE_TOKEN. Pick whichever you prefer — the Gateway shows as online in the portal within moments of starting. If you are new to containers, the Docker beginner guide gets you to a working Docker Engine first. You will SSH into that server to run the command, so set up key-based login with an SSH key generator before you start — never SSH with passwords into a box that guards your network.

Treat FIREZONE_TOKEN like an API key: it authenticates your Gateway to your account, so it goes in the deploy command and nowhere else — never in a screenshot, a public repo, or a shared chat log. You need only one Gateway per Site to get started, but the docs recommend deploying two or more for load balancing and automatic failover: clients automatically pick the nearest Gateway and fail over to a healthy one if one goes down. And here is the part that surprises VPN veterans: you do not open any inbound firewall ports. The control plane propagates connection information like public keys across your network, so Gateways and Resources never listen for inbound connections from the public internet — NAT hole-punching handles the rest, and your network gains no visible entry points.

How do you add your first Resource?

A Resource is simply anything your Gateway can reach that you want to give users secure access to — a server, a database, an application, even an entire subnet. On the Site Details page, click Add Resource and enter a name and an address. The name is anything you like; the address must be one of three forms, straight from the quickstart:

• IP address — for example 10.1.2.3 or 2001:db8::1
• Fully qualified domain name — for example example.com
• CIDR range — for example 10.10.10.0/24 or 2001:db8::/48

You can also add an Address description, which is what users actually see as the Resource address in their Clients. One design rule from the docs: the more granular your Resources, the more control you have over who can access what. A single /24 Resource is easy but coarse; separate Resources for the database server, the staging box, and the admin panel let your Policies say very different things about each.

How do you write your first Firezone policy?

Firezone access is default-deny: a user cannot reach a Resource until a Policy explicitly permits it. This is the heart of "zero trust" — every access attempt is denied until the user verifies their identity and the platform confirms they are allowed in. So adding a Resource without a Policy is the number one reason beginners stare at a connected client and reach nothing.

To create your first Policy, open the Policies page from the left-side menu, select the Resource, choose which user groups may access it, and save. Firezone policies combine with User Groups to give you role-based — or any other logical — access control at a fine-grained Resource level. The quickstart's own wording is worth memorizing: end-users cannot access a Resource unless they are members of a group that has explicit access to that Resource.

Practical habit: name your groups for the role, not the person — "Engineering," "Contractors," "On-call" — because groups are what Policies point at, and renaming people is cheaper than rewriting Policies.

How do you connect your first client?

Download the Firezone Client for your platform: Windows and Linux users grab it from the Firezone downloads page, while macOS, iOS, iPadOS, Android, and ChromeOS users install it from their device's app store. Sign in from the app — on mobile tap Sign in, on desktop click Sign in from the menubar dropdown — and enter your account slug, which is the part of your sign-in URL after the domain (for example, https://app.firezone.dev/your-organization).

Once signed in, the client runs quietly in the background — there is nothing to toggle. Your permitted Resources appear in the app's Resources section, and connecting is one click. Firezone uses always-on split tunneling: only traffic to your Firezone Resources goes through the tunnel, so everything else on the device behaves exactly as before. For servers and automation without a human, service accounts let you run the Firezone Client in headless, non-interactive mode — they cannot satisfy 2FA prompts, which is precisely why they exist for machine-to-machine access.

Firezone vs Tailscale: which one should you pick?

Firezone and Tailscale both replace legacy VPNs, but they solve different problems. Tailscale is a hosted mesh VPN: every device joins a flat tailnet, and you write per-device routes and exit-node rules. Firezone is a zero-trust access platform: you organize infrastructure into Sites, self-host Gateways inside those networks, register Resources, and govern them with identity-based Policies. We are covering Tailscale in its own beginner guide in this series — here is the honest comparison so you pick the right lane:

Rule of thumb: if your question is "which people may touch which servers," Firezone's Policy model fits. If your question is "how do my three laptops reach my NAS," the mesh model is simpler. Neither answer is a rivalry — they are different tools that happen to share a WireGuard foundation.

How does Firezone SSO work?

Firezone integrates with any OIDC-compatible identity provider — Google Workspace, Microsoft Entra ID, Okta, and OneLogin are all named in the docs — and it never stores or handles end-user credentials like passwords itself. Out of the box, email one-time-code sign-in works with no configuration: the admin portal sign-in sends you a magic link or a token you paste into the form.

Connect your IdP in the admin portal to get real single sign-on, and on the Business plan you get directory sync for Google, Entra ID, and Okta, so users and groups flow in automatically instead of being typed by hand. WireGuard encryption keys rotate on a session basis each time a user signs in, so a stolen key has a short useful life. One caution from the docs worth repeating: Firezone does not handle passwords, which means password hygiene for your IdP is password hygiene for your network — enforce MFA at the identity provider.

How much does Firezone cost?

Firezone's pricing is per-seat with a genuinely useful free tier. Starter is free with no credit card required: up to 6 users and 10 service accounts, 10 Sites, native clients for every platform, email and OIDC authentication, resource-level access policies, audit logs, the REST API, and Gateway load balancing and failover. That covers a homelab or a small project completely.

Team is $5 per seat per month or $50 per seat per year (about $4.17/month equivalent), scaling to 500 users with full-tunnel routing, conditional access policies, and a custom account slug. Business is $8 per active seat per month or $80 per active seat per year, with every product feature — directory sync, device posture checks, log sinks and SIEM integrations — up to 1,000 users. Enterprise is custom with a 99.9% uptime SLA, SOC 2 and pentest reports, and dedicated Slack support. Nonprofits and educational institutions get 50% off.

The seat-counting difference between Team and Business is worth working through once, because it decides which plan is cheaper for you:

If your whole team logs in daily, Team's static seats are simple. If half your directory is dormant in any given month, Business's floating seats win — the pricing page's own example makes exactly this 100-user/40-active comparison.

The beginner mistakes that break a first deploy

Almost every failed first deploy is one of these five. All five are avoidable if you know the current architecture before you start:

Sources

Every fact in this guide was verified against these sources on 2026-10-31. The Firezone docs are the authority for the current architecture — the old community deploy guides below it describe the retired self-host stack and are cited here only as the history the reality check warns against.

• Firezone Docs — FAQ (kb/faq): split control/data plane architecture, self-host policy (hobby/educational, no support or docs), pricing plans and seat counting, gateway deployment (Docker/systemd), OIDC providers, client platforms, always-on split tunneling, account slugs — crawled 2026-10-31.
• Firezone Docs — Quickstart (kb/quickstart): the six-step arc — admin portal sign-in, Site creation, Gateway deploy, Resource address formats (IP/FQDN/CIDR), default-deny Policies, client sign-in with account slug — crawled 2026-10-31.
• Firezone Pricing page: Starter free for up to 6 users and 10 service accounts, Team $50/seat/year, Business $80/active seat/year, static vs floating seat definitions, the 100-user/40-active worked example, the 5-seat proration example, 50% nonprofit/education discount — crawled 2026-10-31.
• RamNode — "Deploy Firezone on a VPS": FIREZONE_TOKEN handling, no inbound ports (STUN/TURN NAT hole-punching), docker compose ps troubleshooting, default-deny policies — guide crawled within the last day.
• Brightcoding — "Firezone: The Revolutionary Zero-Trust Access Platform": feature overview, pricing note (free for 6 users, confirmed on the pricing page), client install and group policies — published 7 days ago.

Frequently asked questions

Can I self-host Firezone for free?

Yes — but only the data plane. Clients and Gateways are designed to be self-hosted on your own infrastructure on every plan, including the free Starter plan. The control plane (admin portal, identity, policy coordination) is managed by Firezone. Full-stack self-hosting from the open-source code is license-permitted but officially recommended only for hobby or educational use, with no support or documentation.

Do I need to open firewall ports for the Gateway?

No. Firezone's control plane propagates connection information such as public keys across your network, so Gateways and Resources do not listen for inbound connections from the public internet. NAT hole-punching establishes the tunnels, and the docs recommend keeping your inbound firewall rules as restrictive as possible.

What is the difference between a Site, a Gateway, and a Resource?

A Site is a collection of Gateways and Resources that share the same network connectivity context — typically a subnet or VPC. A Gateway is the self-hosted component you deploy on a server inside that network to provide connectivity between clients and Resources. A Resource is anything you want to give users access to: a server, a database, an application, or a whole subnet.

Can Firezone replace my VPN?

Yes, and you do not have to switch overnight — Firezone can run alongside your existing VPN with no downtime, and you migrate resource by resource. Unlike a traditional VPN that grants access to the entire network, Firezone authenticates users and authorizes each access request against Policies before connecting them to a specific Resource. The tunnels themselves run on WireGuard.

Is Firezone free? How many users can I have?

The Starter plan is free with no credit card and supports up to 6 users and 10 service accounts, with unlimited Policies and Resources. If you outgrow it, Team ($5/seat/month) covers up to 500 users and Business ($8/active seat/month) up to 1,000 users — both with annual billing discounts of roughly 17%.