April 2024 Update | Firezone Blog

What's new:

Firezone 1.0 GA

After months of beta testing with our early adopters, today we're announcing that Firezone 1.0 is now generally available. We couldn't be more excited for you to try it.

Sign up now to get started.

The road to 1.0

This release marks a significant milestone for Firezone.

When we announced Firezone 1.0 was coming last July, we knew we had our work cut out for us. Until that point, Firezone was a simple web app into a single Docker image. Although a great fit for homelabbers and small groups, it wasn't suited to address the remote access needs of larger organizations.

It was easy to get up and running quickly with Firezone, but as the number of users, devices, and networks to protect grew within an organization, so did the complexity of managing it all.

So we went back to the whiteboard to reimagine how Firezone would look if we rebuilt it from the ground up The Right Way™ -- with scalability and ease of use in mind.

We spent the next several months prototyping, testing, and iterating on a new architecture that would allow Firezone to scale to hundreds of thousands of users and millions of devices.

The stack

We weren't going to squander a good opportunity to rethink our stack choice, but it remained largely the same: the new Firezone would be built with Elixir for the control plane and Rust for the data plane.

Why?

Elixir has been getting lots of acclaim in recent years for its concurrency model and fault-tolerance features. And for good reason: it runs on Erlang's BEAM VM, the same technology that powers the telecom industry's most reliable systems.

As it turns out, managing connections for a remote access product is a lot like managing messages across a telecom network:

1. Peer A wants to connect to Peer B.
2. Is it allowed?
  Yes: here are their addresses and keys to secure the connection.
  No: drop the connection.

And Elixir's concurrency model makes it easy to manage thousands of these connection "intents" on very little hardware -- just a few tiny VMs orchestrate all connections across all our customers, globally.

And what about the data plane? For that, we turned to Rust.

Rust forms the network backbone of Firezone, handling all the heavy lifting of encrypting and decrypting packets as they flow between Clients and Gateways. As far as systems languages go, Rust couldn't be a better fit for the job. Its memory safety guarantees eliminate entire classes of bugs that plague other systems languages, making it a great choice for a security-critical application like Firezone.

And it has build targets for just about every platform under the sun. Our core connectivity library, for example, runs reliably on iOS, Android, Windows, Linux, and macOS.

What's unique about Firezone?

There are a lot of remote access solutions out there, so what makes Firezone different?

For starters, Firezone uses WireGuard® under the hood -- a new VPN protocol that's faster and more secure than traditional VPNs. But that's just the start.

Firezone 1.0 delivers on all of that and more.

Core concepts in 1.0

Before we dive into the new features, let's first cover some core concepts new to Firezone:

For a more detailed overview of these concepts, check out the FAQ and glossary sections of our documentation.

High availability

The first major feature in 1.0 we should discuss is high availability. Firezone achieves high availability by allowing you to deploy multiple Gateways within a given Site.

Each Firezone Gateway is a tiny, self-contained binary that needs only a single environment variable to function.

After you create a Site, you can deploy as many Gateways into that Site as you'd like. All Gateways in the Site will work in unison to provide load balancing and automatic failover for all connections to Resources in the Site.

We think high availability is such a core feature in a remote access solution that we made failover and load balancing available on all plans, including the Starter tier. Read more about how it works in our documentation.

Firewall hole-punching

You know what's not fun? Configuring firewalls.

So we rearchitected Firezone to include the same NAT traversal techniques that WebRTC applications have enjoyed for years now: STUN and TURN, known collectively as ICE.

What does this mean for you? It means you can deploy Firezone without touching a single firewall configuration and still enjoy the same level of performance as if you did.

Directory sync

Firezone currently supports directory sync for Okta, Entra ID, and Google Workspace, with more providers on the way.

Directory sync is available only for the Enterprise plan so we can be sure it'll work reliably for your organization. Read more about how it works or contact sales if you'd like a first-hand demo.

What's next?

We covered only a fraction of what's new in Firezone in this post. Go sign up and see what else is new for yourself, or request a demo if you'd like to better understand how Firezone can help your organization.

We have more to announce in the coming weeks.