mirror of https://github.com/fleetdm/fleet synced 2026-04-21 13:37:30 +00:00

Add compatibility note to upgrading docs (#40569 )

Clarify the rare cases when upgrading to a minor/patch version can break
compatibility.

---------

Co-authored-by: Noah Talerman <47070608+noahtalerman@users.noreply.github.com>

2026-02-26 10:45:07 -06:00

3.6 KiB

Raw Blame History

Upgrading Fleet

This guide explains how to upgrade your Fleet instance to the latest version in order to get the latest features and bug fixes. For initial installation instructions, see Installing Fleet.

There are four steps to perform a typical Fleet upgrade:

Bringing Fleet offline
Installing the latest version
Preparing the database
Serving the new Fleet instance

Bring Fleet offline

In order to avoid any errors while preparing the database for the new version of Fleet, all Fleet instances need to be shut down during the migration process. During a typical upgrade, you can expect 5-10 minutes of downtime.

Your hosts will buffer any logs generated during this time and send those buffered logs once the server is brought online again.

Install the latest version of Fleet

Fleet may be installed locally, or used in a Docker container. Follow the appropriate method for your environment.

Local installation

Download the latest version of Fleet. Check the Upgrading section of the release notes for any additional steps that may need to be taken for a specific release.

Unzip the newly downloaded version, and replace the existing Fleet version with the new, unzipped version.

For example, after downloading:

unzip fleet.zip 'linux/*' -d fleet
sudo cp fleet/linux/fleet* /usr/bin/

Docker container

Pull the latest Fleet docker image:

docker pull fleetdm/fleet

Prepare the database

Changes to Fleet may include changes to the database. Running the built-in database migrations will ensure that your database is set up properly for the currently installed version.

It is always advised to back up the database before running migrations.

Database migrations in Fleet are intended to be run while the server is offline. Osquery is designed to be resilient to short downtime from the server, so no data will be lost from osqueryd clients in this process. Even on large Fleet installations, downtime during migrations is usually only seconds to minutes.

Run database migrations:

fleet prepare db

Serve the new version

Once Fleet has been replaced with the newest version and the database migrations have completed, serve the newly upgraded Fleet instance:

fleet serve

AWS with Terraform

If you are using Fleet's Terraform modules to manage your Fleet deployment to AWS, update the version in main.tf:

  fleet_config = {
    image = "fleetdm/fleet:<version>" 
    [...]
  }

Run terraform apply to apply the changes.

Compatibility

Fleet follows Semantic Versioning (SemVer). This means that breaking changes are never introduced in a new minor or patch version, except in these rare cases:

Experimental features: Experimental features are tagged as such in the API documentation. These features are being rapidly iterated on and are not for use in automated workflows.
Security: Fleet reserves the right to make breaking changes for security. When no alternative solution is available, security fixes may introduce backward-incompatible changes.

In each of these cases, breaking changes are clearly communicated in the version notes.

3.6 KiB Raw Blame History