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:
| Bereich | Prüfpunkte |
|---|---|
| Versionen | verwendete Image-Tags oder Digests, PostgreSQL-Version, Supabase-Vorlagenstand |
| Konfiguration | Compose-Dateien, Umgebungsvariablen, Volumes, Proxy und Netzwerke |
| Anpassungen | eigene Services, Overrides, Hooks, Storage-Ziel und SMTP |
| Datenbank | Größe, Extensions, Funktionen, Replikation und Backup-Verfahren |
| Anwendung | Clients, SDK-Versionen, Functions, Integrationen und kritische Wege |
| Betrieb | Monitoring, Wartungsfenster, Verantwortliche und Rückfallkriterien |
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:
- vorheriger offizieller Vorlagenstand
- aktueller offizieller Vorlagenstand
- 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:
- Freigabe und Startzeit
- Prüfung des letzten erfolgreichen Backups
- optionalen Schreibstopp oder Wartungsmodus
- Bezug der festgelegten Images
- Konfigurations- und Datenbankschritte in Reihenfolge
- Neustart und technische Health Checks
- Smoke Tests der kritischen Nutzerwege
- Go/No-Go-Entscheidung
- Dauer der verstärkten Beobachtung
- 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.
