import { HiCheck } from "react-icons/hi2";
import { TabsItem, TabsGroup } from "@/components/DocsTabs";

# Upgrading Firezone

Upgrading Firezone consists of upgrading the client applications and gateways.
Read more below to understand how our versioning system works, how you can
auto-update these components, and suggestions for an upgrade strategy in
high-availability deployments.

## How versioning works in Firezone

Firezone uses a semantic version scheme in the following format:

`MAJOR`.`MINOR`.`PATCH`

Firezone is changing rapidly, so we currently recommend staying as up-to-date as
possible to make sure you have the latest bug fixes and performance improvements
in place.

All components currently have a major version of `1` -- this is not expected to
change for some time.

## Client application auto-updates

In general we recommend keeping clients and gateways as up-to-date as possible.
See below for auto-update details for each client.

<TabsGroup>
  <TabsItem title="macOS" active>
    Enable auto-updates in Settings.app.
  </TabsItem>
  <TabsItem title="iOS">Enable auto-updates in Settings.app.</TabsItem>
  <TabsItem title="Android">Enable app auto-updates in Settings.</TabsItem>
  <TabsItem title="ChromeOS">Enable app auto-updates in Settings.</TabsItem>
  <TabsItem title="Linux">
    Linux auto-updates are configured by default if you deployed using the Linux
    client deployment guide.
  </TabsItem>
</TabsGroup>

## Upgrading gateways

Upgrading a gateway generally consists of simply replacing the binary or Docker
image and then restarting. See below for specific steps depending on how you've
deployed your gateway:

<TabsGroup>
<TabsItem title="Docker" active>

Run the following upgrade script which pulls the latest image, stops the running
gateway, and then restarts it using the newer image with the same configuration.

```bash
curl -s https://raw.githubusercontent.com/firezone/firezone/main/scripts/gateway-docker-upgrade.sh | bash
```

</TabsItem>
<TabsItem title="systemd">

If you deployed via the portal, your unit file should already contain logic
necessary to upgrade the gateway on service start. Simply move the old binary
and restart the service to trigger the upgrade:

```bash
sudo mv /usr/local/bin/firezone-gateway /usr/local/bin/firezone-gateway.bak
sudo systemctl restart firezone-gateway
```

</TabsItem>
</TabsGroup>

### Downtime considerations

Gateways deployed within the same site will automatically
[failover](/kb/deploy/gateways#failover) for each other. By upgrading gateways
one-by-one, clients connected to the gateway being upgraded will automatically
reconnect to an available gateway.

Currently the failover timeout is about **15 seconds**. Upgrades should be
performed during a scheduled maintenance window to ensure minimal disruption.
Other than a possible short-term connection interruption to in-use resources,
users won't otherwise be impacted by upgrading gateways within the same site.
