Skip to main content

· 6 min read
Jason Gong

My first tech job was at Strong, a workout journal app that was pretty popular at the time. The founders were “digital nomads,” and the team was fully remote.

Back in 2016, this was highly uncommon.

We spent a lot of time creating processes to work together effectively on opposite sides of the world. One of these was meeting up in person regularly.

digital nomads

At first, it was by accident. Since everyone was traveling anyway, we would coordinate being in the same city at the same time.

After working in person, we quickly noticed the way we worked remotely improved. People were more comfortable sharing their ideas, better at giving constructive criticism, and happier in general.

It just felt better to work together in person.

Why try this at Firezone?

If you believe Firezone can take a sizable bite out of the usual suspects of legacy remote access products, we’ll need to use every advantage.

As a startup, our biggest advantage is the ability to move quickly as a team.

This is much easier when everyone is comfortable sharing ideas and engaging in lively debate. Plus, it’s a lot more fun.

So we decided to try it out. After much planning, canceled bookings, and a few long flights, our team met in Santa Rosa, California.

offsite office

What did we do?

Our itinerary included architecture planning, a multi-day hackathon, and plenty of fun activities around the Bay Area.

offsite office

The focus of the off-site was building. We each defined a few tasks that could realistically be completed by the end of the trip. So what did we work on?

  • A new Firezone gateway (coming in 0.8!) that will eventually allow decoupling the web portal from the WireGuard data plane. A single Firezone web portal will soon be able to manage hundreds or even thousands of little Firezone gateways securing access to their respective private resources. More details to come!
  • A new REST API in 0.7 to allow configuring Firezone in a more automatable way. Users love our snappy web portal, but nothing beats the power of an API for automation.
  • Various documentation improvements to improve consistency between Omnibus and Docker sections, detail logging, and implement a v1 style guide.

Of course, no visit to the Bay Area would be complete without a tour of San Francisco. It rained most of the time, so we missed out on much of the picturesque hiking. But we still managed to snap some photos of the Golden Gate bridge and devour a few In-N-Out burgers.

Of special mention are the team dinners. Remote companies lack that familiar bond typically formed over team lunches in the office, so we sought to recreate that when we met in person. As an added bonus, we also split cooking duties. In many ways preparing food for your teammates is like opening a pull request: make something, request feedback on it, then merge and enjoy.

As someone whose culinary talents rival his passion for building security products, our resident chef Jamil led most of the culinary endeavors, including a 2-hour drive around Santa Rosa in search of live Dungeness crab.

team dinner

Lessons learned for next time

Since this was our first off-site, some things could have gone better. Here’s a small list of hiccups and other things we’d do differently next time.

Turn on low power mode

team dinner

If you’re booking an Airbnb, check for planned maintenance and outages! We were notified three days before arrival the power would be out during two full workdays.

Fortunately, we had a small power bank and mobile hotspot with unlimited data. Unfortunately, our lead Rust engineer’s beefy Linux machine only gets a single hour of battery life on a full charge.

When his machine died, we migrated to our local coffee shop, where power and WiFi were surprisingly abundant. Editor’s note: Coffee shops in Santa Rosa are much more accommodating as a makeshift office than most in San Francisco.

When you’re building software, electricity and internet are vital -- splurge for that bigger battery bank and faster hotspot!

Lumbar support is underrated

You’ll sacrifice some ergonomics when you work out of an Airbnb. Put a premium on large work surfaces, open common areas, and comfortable chairs. After a few days of working hunched over on a sofa, we learned the hard way.

Even better, leave heads down work until after the off-site. Instead, prioritize architecture discussions, brainstorming sessions, and design sprints.

Stock the right fuel

We got carried away at Costco. Our out-of-town guests had never witnessed the spectacle of an American snack aisle. Fortunately, our talented engineers can turn Funyuns into elegant lines of Rust code (shoutout @Gabi).

All jokes aside, you’ll need the right fuel for your hackathons and deep product discussions. We recommend stocking up with plenty of coffee and healthy snacks.

Plan ahead: it’ll pay off

As is often the case with startups, we planned the trip on short notice. This meant many last-minute restaurant bookings and trips to the store for basic supplies.

So, make a shopping list, book a few restaurants in advance, and have a backup plan. If you’re looking for a template, take a look at this guide from our friends at PostHog. A great checklist is hard to beat.

What’s next?

In a few short days, we:

  • Aligned on Firezone’s product direction
  • Made critical architecture decisions for the gateway and client apps
  • Made significant progress on a few key features
  • Bonded over great food, conversation, and Mario Kart

We could have accomplished some of these over a few long Zoom calls and chat threads, but not as quickly. There’s something about mind melding over a few days of intense work that’s hard to replicate.

So, will we have another off-site? Definitely!

Until next time!

👋 thanks for reading

Firezone secures remote access to private resources. This post doesn't have much to do about security, networking, or a fancy new feature. But hey, our product improves the remote work experience - organizing a great off-site helps too.

If you want to try it out, our Docker install script gets Firezone running in just a few minutes.

· 4 min read
Jamil Bou Kheir

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:

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.

· 4 min read
Jamil Bou Kheir

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.

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.


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.