Supabase Self-Hosted aktualisieren: Updates ohne Blindflug

Sie möchten Supabase nicht selbst durch Release Notes, Merge-Konflikte und Restore-Risiken führen? WZ-IT übernimmt Supabase Managed Hosting und Betrieb mit kontrollierten Updates, Monitoring und Backups.

Wer Supabase Self-Hosted aktualisieren möchte, aktualisiert keinen einzelnen Container. Der Stack umfasst PostgreSQL, Auth, Storage, Realtime, API-Gateway, Studio, Functions und weitere Dienste. Zwischen Releases können sich Images, Umgebungsvariablen, Compose-Dateien, Datenbankstrukturen und Abhängigkeiten ändern.

Ein belastbarer Update-Prozess behandelt deshalb jedes Upgrade als kleine, wiederholbare Änderung mit Bestandsaufnahme, Sicherung, Staging, Abnahme und Rückfall.

Warum ein einfaches „Pull und Restart“ riskant ist

Ungeprüfte Aktualisierungen scheitern typischerweise an:

• lokal angepassten Compose-Dateien
• neuen oder entfernten Umgebungsvariablen
• nicht kompatiblen Image-Ständen
• Datenbankänderungen oder Major-Versionen
• geänderten Health Checks oder Netzwerkpfaden
• Auth- und JWT-Konfiguration
• Functions und Laufzeitabhängigkeiten
• externen SMTP-, OAuth- oder Storage-Anbindungen

Die Container können formal laufen, während Login, Upload, Realtime oder einzelne APIs bereits gestört sind. Health Checks und echte Nutzerwegtests erfüllen unterschiedliche Aufgaben und werden beide benötigt.

1. Den aktuellen Stand reproduzierbar erfassen

Vor dem Update werden dokumentiert:

Images sollten nicht unkontrolliert über bewegliche Tags aktualisiert werden. Ein dokumentierter Stand ist die Voraussetzung dafür, denselben Zustand wiederherzustellen.

2. Änderungen der Zielversion bewerten

Die offizielle Update-Dokumentation und das Self-Hosting-Repository sind die primären Quellen. Geprüft werden:

• geänderte Compose-Dienste
• neue, umbenannte oder entfernte Variablen
• Datenbankmigrationen
• Änderungen an Auth, Gateway und API
• benötigte Image-Versionen
• Breaking Changes und manuelle Schritte
• bekannte Einschränkungen

Zusätzlich wird geprüft, ob verwendete Clients und Integrationen mit der Zielversion getestet sind. Ein Update kann technisch korrekt sein und trotzdem eine Annahme der Anwendung verletzen.

3. Backups richtig vorbereiten

Die Supabase-Dokumentation weist beim Update-Verfahren ausdrücklich darauf hin, dass PostgreSQL-Daten und Storage-Objekte nicht durch das Zusammenführen der Konfiguration gesichert werden.

Vor Produktion gehören mindestens dazu:

• konsistentes PostgreSQL-Backup
• separate Sicherung der Storage-Dateien
• versionierte Compose- und Override-Dateien
• verschlüsselte Sicherung oder Wiederherstellungsweg für Konfiguration
• dokumentierte Image-Stände
• geprüftes Restore-Runbook

Wichtig ist nicht nur die Existenz der Dateien. Der Betreiber muss wissen, wie lange die Wiederherstellung dauert und welche Daten nach einem Rückfall verloren gingen.

4. Offizielle Änderungen und lokale Anpassungen zusammenführen

Supabase stellt für bestimmte Self-Hosting-Updates ein Skript bereit, das einen Drei-Wege-Abgleich verwendet:

1. vorheriger offizieller Vorlagenstand
2. aktueller offizieller Vorlagenstand
3. lokal angepasster Stand

Dadurch lassen sich eigene Änderungen gezielter erhalten. Merge-Konflikte bleiben aber fachliche Entscheidungen. Besonders sensibel sind:

• Ports und öffentliche Exposition
• Volume-Pfade
• externe Datenbank- oder Storage-Ziele
• Reverse Proxy und TLS
• eigene Secrets-Variablen
• Ressourcenlimits
• Logging und Monitoring

Das Ergebnis wird in Versionskontrolle geprüft. Geheimnisse gehören nicht in das Repository.

5. Zuerst in einer produktionsnahen Umgebung testen

Ein sinnvolles Staging verwendet:

• dieselbe Architektur und relevante Konfiguration
• anonymisierte oder repräsentative Daten
• identische Auth-Provider im Testmodus
• dieselben Functions und Extensions
• realistische Storage- und Realtime-Szenarien

Die Tests decken mindestens ab:

• Studio und Administration
• REST- und GraphQL-Zugriffe
• Login, Logout, Refresh und Passwort-Reset
• RLS-Positiv- und Negativfälle
• Datei-Upload, Download und signierte URLs
• Realtime-Verbindungen
• Functions und Secrets
• SMTP, OAuth, Webhooks und externe APIs
• Backup nach dem Update

6. Das Produktions-Runbook

Ein ausführbares Runbook enthält:

1. Freigabe und Startzeit
2. Prüfung des letzten erfolgreichen Backups
3. optionalen Schreibstopp oder Wartungsmodus
4. Bezug der festgelegten Images
5. Konfigurations- und Datenbankschritte in Reihenfolge
6. Neustart und technische Health Checks
7. Smoke Tests der kritischen Nutzerwege
8. Go/No-Go-Entscheidung
9. Dauer der verstärkten Beobachtung
10. Abschluss und Dokumentation

Jeder Schritt bekommt Verantwortlichen, erwartetes Ergebnis und ein Abbruchkriterium.

7. Rückfall ist mehr als ein Container-Rollback

Alte Images wieder zu starten reicht nicht, wenn ein Update Datenbankzustände verändert hat. Der Rückfallplan beantwortet:

• Sind Schemaänderungen abwärtskompatibel?
• Wird ein vollständiger Datenbank-Restore benötigt?
• Was geschieht mit neuen Schreibvorgängen nach dem Update?
• Passen Storage-Metadaten und Dateien nach dem Restore zusammen?
• Welche DNS-, Proxy- oder Secret-Änderungen müssen zurückgenommen werden?

Bei riskanten Änderungen kann eine vorbereitete parallele Zielumgebung sinnvoller sein als ein In-Place-Update.

8. Nachbeobachtung und Dokumentation

Nach dem Update werden beobachtet:

• Fehlerquoten und Antwortzeiten
• Datenbankverbindungen, Locks und Ressourcen
• Auth-Fehler
• Storage- und Function-Fehler
• Realtime-Verbindungen
• Queue- oder Webhook-Rückstände
• ungewöhnliche Neustarts

Anschließend werden Versionsinventar, Runbook und bekannte Abweichungen aktualisiert. Erkenntnisse aus Störungen oder manuellen Schritten fließen in den nächsten Zyklus.

Quellen

• Supabase: Self-Hosted Deployment aktualisieren
• Supabase: Self-Hosting mit Docker
• Supabase: Datenbank-Backups
• Supabase Self-Hosting Repository