Mastodon-Update ohne Downtime

Vor ein paar Jahren habe ich meine eigene Mastodon-Instanz, Fulda.Social, aufgesetzt. Damals war das noch ein kleines Projekt – doch mit der Zeit wurde es immer aufwendiger, die Instanz aktuell zu halten. Besonders nervig: Bei jedem Update musste ich das Docker-Image neu bauen, was mit der Zeit immer länger dauerte. Der Grund? Der Build-Prozess zog den Cache mit ein, was nicht nur Zeit kostete, sondern auch den Speicherplatz auf dem Server knapp werden ließ. Dazu kamen noch die typischen Probleme mit Schreib- und Leserechten in Containern, die ich in einem älteren Artikel schon mal beschrieben habe.

Doch seit dem letzten Update habe ich das Setup komplett umgestellt – und bin nun zufrieden. Statt das Image jedes Mal neu zu bauen, binde ich jetzt nur noch meine angepassten Konfigurationsdateien als Read-Only-Volume ins offizielle Mastodon-Image ein. Das bringt gleich mehrere Vorteile:

1. Keine Downtime mehr bei Updates

Früher musste ich die Instanz beim Update kurz herunterfahren, manchmal hatte dann was nicht gepasst und so entstand eine Downtime. Jetzt ziehe ich einfach das aktuelle Image von Docker Hub und starte die Container neu. Die Konfiguration bleibt erhalten, weil sie extern eingebunden ist. So entfällt die lästige Ausfallzeit, und die Nutzer merken nichts vom Update.

2. Stabileres Setup

Durch die Trennung von Code und Konfiguration vermeide ich Probleme mit Berechtigungen oder versehentlichen Änderungen im Container. Die Konfiguration liegt sicher außerhalb des Containers und wird nur eingelesen. Das macht das Ganze nicht nur stabiler, sondern auch einfacher zu warten.

3. Automatische Updates mit Watchtower

Da ich jetzt keine manuellen Builds mehr brauche, kann ich Watchtower nutzen, um die Container automatisch zu aktualisieren. Watchtower überwacht die Images und startet bei neuen Versionen einen Rollout – ohne dass ich eingreifen muss. Wichtig: Ich pinne die Versionen in der docker-compose.yml, um unerwartete Major-Updates zu vermeiden. So bleibe ich immer auf dem aktuellen Stand, ohne dass die Instanz plötzlich nicht mehr läuft, weil ein Update Migrationen erfordert, die ich nicht beachtet habe
.

4. Weniger Speicherverbrauch

Kein Cache, keine alten Build-Artefakte – der Server bleibt schlank. Der Speicherplatz, der früher für die Build-Prozesse draufging, steht jetzt wieder für wichtigere Dinge zur Verfügung.

So geht’s: Die Umstellung im Detail

1. Offizielles Image nutzen
   Statt selbst zu bauen, verwende ich jetzt das offizielle tootsuite/mastodon-Image aus dem Docker Hub. In der docker-compose.yml trage ich einfach die gewünschte Version ein:

image: tootsuite/mastodon:v4.5.7Code-Sprache: HTTP (http)

So vermeide ich Überraschungen und behalte die Kontrolle über die Versionen.

2. Konfiguration extern halten
   Meine .env.production und andere Konfigurationsdateien liegen jetzt in einem separaten Verzeichnis auf dem Host und werden als Read-Only-Volume eingebunden:

    image: ghcr.io/mastodon/mastodon:latest
    volumes:
      - ./public/system:/opt/mastodon/public/system
      - ./tmp:/opt/mastodon/tmp
      - ./custom-config/status_length_validator.rb:/opt/mastodon/app/validators/status_length_validator.rb:ro
      - ./custom-config/poll_options_validator.rb:/opt/mastodon/app/validators/poll_options_validator.rb:ro
Code-Sprache: JavaScript (javascript)

Das schützt vor versehentlichen Änderungen und macht Backups einfacher.

3. Watchtower einrichten
   Mit einem einfachen Watchtower-Container werden die Images automatisch aktualisiert, sobald eine neue Version verfügbar ist:

services:

   watchtower: 

      image: containrrr/watchtower 

      volumes: - /var/run/docker.sock:/var/run/docker.sock 

   restart: alwaysCode-Sprache: JavaScript (javascript)

Wichtig: Vorher prüfe ich immer die Release Notes, ob Migrationen nötig sind.

4. Datenbank-Backup nicht vergessen
   Bevor Watchtower loslegt, sichere ich die Datenbank – denn auch bei automatischen Updates gilt: Safety first!

<code class="bash language-bash">docker exec mastodon_db_1 pg_dump -Fc -U postgres postgres > mastodon_backup_$(date +%Y%m%d).dump</code>Code-Sprache: JavaScript (javascript)

Fazit: Weniger Arbeit, mehr Stabilität

Die Umstellung hat sich gelohnt. Die Instanz läuft stabiler, Updates sind kein Stress mehr, und ich spare mir die nervige Build-Zeit. Wer selbst eine Mastodon-Instanz betreibt, sollte unbedingt über diesen Ansatz nachdenken – besonders, wenn die manuellen Updates langsam zur Qual werden.

Mehr zum Thema:

• Mastodon mit Docker betreiben – mein erster Guide
• Watchtower: Automatische Docker-Updates richtig nutzen
• Docker-Berechtigungen im Griff – so vermeidest du typische Fehler

Falls du ähnliche Erfahrungen gemacht hast oder Fragen zur Umstellung hast – schreib’s in die Kommentare! Wie handhabt ihr eure Mastodon-Updates?