My previous post detailing how to run a Mastodon server using
docker-compose includes a section detailing how to upgrade an instance built using that approach
However, today's Mastodon releases (
v3.5.9) include important security fixes (especially the fix for
CVE-2023-36460), so I thought it was worth a quick post detailing the process that I've followed to upgrade my instance (
mastodon.bentasker.co.uk) to ensure that I get today's security fixes in place.
Every Mastodon upgrade should be preceded by a backup of the Postgres database:
docker exec postgres pg_dumpall -U postgres | gzip > postgres_backup_PREUPGRADE_`date +'%Y%m%d'`.sql.gz
Depending on the size of your database (and the speed of the storage you're writing too), this may take a little while to complete. The next section includes some prep that you can be doing whilst it runs.
Upgrading from Earlier Versions
Prior to today's release, the latest version of Mastodon was
If you've fallen behind in applying updates, it's important that you check release notes for each of the versions between your current version and
v4.1.2: upgrades sometimes include additional steps, so you need to identify whether there are any additional commands that you need to run.
For example, my instance was running
v4.1.0, so I needed to check
- Release notes for v4.1.2 (no additional steps when upgrading from v4.1.1)
- Release notes for v4.1.1 (no additional steps when upgrading from v4.1.0)
However, had I instead been running
v4.0.2, I would have needed to run a database migration.
If you're in that position, you'll need to work through from the earliest work-requiring version to the latest (you can skip over any version that doesn't need additional steps run).
Essentially you just need to follow the process below for each of the interim versions that you need to update to, run the migration, and then upgrade to the next work-requiring version until you reach today's version - as long as you're not miles behind, it's a much quicker process than it sounds.
The notification email sent to admins of larger instances notes that, when released, the docker image would be tagged
Note that Nightlies go to the Github Container Registry not docker hub.
So, in preparation for the upgrade, we need to update the image in
docker-compose.yml (it'll need updating for your
diff --git a/docker-compose.yml b/docker-compose.yml index dd681e4..cfdc182 100644 --- a/docker-compose.yml +++ b/docker-compose.yml @@ -97,7 +97,7 @@ services: - /usr/local/share/meiko/files/mastodon/files/redis:/data web: - image: tootsuite/mastodon:v4.1.0 + image: tootsuite/mastodon:v4.1.3 restart: always container_name: web env_file: /usr/local/share/meiko/files/mastodon/files/.env.production @@ -117,7 +117,7 @@ services: - /usr/local/share/meiko/files/mastodon/files/public/system:/mastodon/public/system streaming: - image: tootsuite/mastodon:v4.1.0 + image: tootsuite/mastodon:v4.1.3 restart: always container_name: streaming env_file: /usr/local/share/meiko/files/mastodon/files/.env.production @@ -135,7 +135,7 @@ services: - redis sidekiq: - image: tootsuite/mastodon:v4.1.0 + image: tootsuite/mastodon:v4.1.3 restart: always container_name: sidekiq env_file: /usr/local/share/meiko/files/mastodon/files/.env.production
Note: Do not use
latest - it'll drop you onto the 3.x branch
Run database migrations (don't forget this bit or you can end up looking a bit of a tit)
docker-compose run --rm web rails db:migrate
Pull the new image (not technically necessary, but will speed the next step up)
docker pull ghcr.io/mastodon/mastodon:nightly-2023-07-06-security
And then have services restart using the new image
docker-compose up -d
The v4.1.3 tag has landed, so if you followed an earlier version of this post to move to nightlies you can now move back onto the main release track - just update the image to
tootsuite/mastodon:v4.1.3 and run
docker-compose up -d again.
With the fixes having been released as a tagged image, upgrading is quick and easy - at least once I realised I needed to watch
ghcr.io for the release and not dovker hub.
In the unlikely event that something does go wrong, rollback is just a case of switching the docker image back in
docker-compose.yml and (if needed) restoring the database backup.