Upgrading a docker-compose based Mastodon server to gain today's security fixes

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 (v4.1.3, v4.0.5 and 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 v4.1.2.

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

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.

Docker Image

The notification email sent to admins of larger instances notes that, when released, the docker image would be tagged nightly-2023-07-06-security.

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 web, streaming and sidekiq instances)

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

-        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

-        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

-        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.