Firezone 0.6 Released!​

Today, I'm excited to announce we've closed the first public issue on our GitHub repository, more than a year after it was originally opened: Containerization support! We're also releasing preliminary support for SAML 2.0 identity providers like Okta and OneLogin.

Docker Support​

Docker is now the preferred method for deploying Firezone. Our automatic install script now uses Docker by default, and we even have a new Docker migration script that will non-destructively migrate your Omnibus-based Firezone installation to a Docker-based one with minimal downtime.

How to Deploy​

You can now deploy Firezone complete with valid SSL certificates and a provisioned administrator in just a couple minutes:

This also means Firezone runs on any platform that supports Docker, like my Mac in the video above. The automatic install script will probably barf on Windows, though. In that case, try the manual install method!

Why Docker?​

Docker offers a number of benefits over the old Omnibus-based method of deploying Firezone:

• Simpler, more robust upgrades: In most cases, simply pull the latest firezone/firezone image and restart the container.
• Simpler configuration: Most day-to-day configuration of Firezone can now be done in the web UI instead of the /etc/firezone/firezone.rb configuration file. All other configuration variables can be specified as ENV vars to the Firezone container.
• Smaller footprint: The Firezone image weighs in at a couple dozen megabytes versus hundreds of megabytes for the Omnibus package.
• Portability: Firezone now runs on any platform that supports Docker.
• Security: Containerization providers better security isolation than simply running as an unprivileged local user.

It also makes it easier to build and test Firezone. CI pipelines rejoice! No more 4-hour long compiles and intermittent build failures.

What about Omnibus?​

Chef Omnibus is a Ruby-based build system designed to make building and distributing complex software easier. You define your dependencies as source tarballs, configure options, and platform-specific build flags, and Omnibus automatically fetches, builds, and links all your dependencies automagically, emitting an OS-native installer artifact when complete.

Omnibus was a popular choice for distributing self-hosted software before Docker was popular -- GitLab and Mattermost are two popular self-hosted products that still support Omnibus-based deployments today. It's still used in many cases where Docker can't be used (on the *BSDs, for example).

But, since Omnibus is effectively EOL in 2024 due to its reliance on Chef Infra Client, we've decided to deprioritize reliance on it, and dedicate those resources to containerized deployments instead.

Note: Beginning with 0.6, Omnibus support in Firezone is deprecated. We'll be removing support for it completely in a future Firezone release.

How to migrate from Omnibus to Docker​

We've written an in-depth migration guide to migrate your instance from Omnibus to Docker:

https://www.firezone.dev/docs/administer/migrate

Most instances will migrate without issue. If you're running Firezone in production for your team or business, contact us so we can better understand how we can help with your migration.

SAML 2.0​

Also in 0.6 is preliminary support for SAML 2.0 authentication. You'll need the IdP Metadata XML document to set it up. In most cases the identity provider will provide it for you. If not, you should be able to build it manually or using a tool such as this nifty online IdP builder.

In general we recommend using OpenID Connect integration over SAML whenever possible. It's simpler, tends to be implemented more consistently across identity providers, and much easier to debug when things go wrong.

Speaking of OIDC, 0.6 also introduces a couple improvements to make integrating your identity provider a more pleasant experience:

• auto_create_oidc_users is now a per-provider configuration setting. Enable or disable autocreation of users when logging into Firezone via that provider.
• New web form for entering OIDC details, with improved validation and error checking:

IdP not supported?​

If your IdP isn't supported or you'd like to learn about your options for custom integrations, contact us to learn more about custom integrations.

Firezone 0.5 Released!​

As the first post on our new blog, we thought it'd be fitting to kick things off with a release announcement. So without further ado, we're excited to announce: Firezone 0.5.0 is here!  It's packed with new features, bug fixes, and other improvements — more on that below.

User-scoped egress rules​

Rules can now optionally receive a user scope, limiting the rule's application only to devices owned by that user. This allows you to selectively allow or deny traffic from a particular user to an IP, set of IPs, or CIDR range.

Auto-renewed, ECDSA-backed, ACME-powered SSL certificates​

One of our most-requested features is now available — Firezone 0.5.0 supports ACME SSL certificate renewal backed by Let's Encrypt's new ECDSA key type. Other providers and key types are available too. See all ACME configuration options in our configuration file reference.

Note: ACME is disabled by default to remain compatible with existing Firezone installations. To enable, set the following in your config file:

default['firezone']['ssl']['acme']['enabled'] = true

BYORP: Bring Your Own Reverse Proxy​

Want to disable Nginx and deploy Firezone under your own reverse proxy or HTTP load balancer? Well, now you can! We've documented the required headers and other configuration necessary to make this happen. Check the docs for some configuration examples for popular proxies. In short:

Set the default['firezone']['phoenix']['external_trusted_proxies'] configuration variable to a comma-separated list containing the proxies you'd like to receive forwarded requests from. If your proxy uses an RFC1918 address, add its IP to default['firezone']['phoenix']['private_clients'] instead of default['firezone']['phoenix']['external_trusted_proxies']. Update your proxy's configuration to point to Firezone, making sure to set the X-Forwarded-For header and enable WebSocket connection upgrades.

Note: ACME support is tied to Nginx. If you disable the bundled Firezone Nginx service, you'll need to provide your own SSL certificates (or configure ACME renewal manually).

Additional note: If you go this route, you'll need to terminate SSL yourself — Firezone sets the secure attribute on all cookies and thus requires the downstream proxy to terminate SSL.

Runtime configuration available in the UI​

Some Firezone configuration settings are now configurable in the product UI under the Security settings. This will override anything you have set in the config file. Moving runtime configuration into the application itself brings us a step closer to Docker-based deployments (coming Soon™).

New and improved documentation​

Our docs have been migrated from Jekyll to Docusaurus. Aside from all the Formatting is improved, user guides are updated and many pages have been edited for clarify and further detail. As an added bonus, our docs are feature improved search thanks to the powerful search functionality provided by DocSearch by Algolia. Contributions welcome!

Red Hat and Debian package repositories​

If you're on one of our supported distros (or its derivatives), the one-line install script will automatically install Firezone from our package repository and track further updates from there. This means your Firezone installation can be managed like any other package on your system and will be marked for upgrades by the same apt and yum tools you're already familiar with. Be sure to check the upgrade notes prior to each upgrade in case there are any backwards-incompatible changes or manual steps involved.

If you've got an existing installation and still want to add our package repository for easier package management, just follow the relevant section in the manual install guide.

Smaller package sizes​

Speaking of packages, we've done a bit of work reducing the size of our Omnibus release package. The Nodejs, Python, Erlang, and Elixir runtimes have all been removed, reducing the package size by 50% and total installed size by even more. There's still lots of work to be done to be done here —  we expect package sizes to be reduced even further moving forward.

Custom landing page logo​

In the first round of what we hope to be the start of a full-featured customization experience, it's now possible to change the landing page logo. Upload an image up to 1 MB or specify a URL to an image your end users will see when landing at your Firezone portal.

Conclusion​

That's all we've got for now. If you'd like to spin up Firezone to try it out, head to the deploy guide in our docs.