Supabase mit Coolify installieren und produktiv betreiben

Sie möchten Supabase über Coolify bereitstellen, aber Backups, Updates und Betrieb nicht improvisieren? WZ-IT übernimmt Supabase Managed Hosting und Migration sowie Coolify Managed Hosting auf dedizierter oder kundeneigener Infrastruktur.

Supabase mit Coolify installieren ist ein attraktiver Einstieg in Self-Hosting. Coolify bietet eine Verwaltungs- und Deployment-Ebene für containerisierte Anwendungen, Domains und Umgebungsvariablen. Supabase bringt PostgreSQL, Auth, Storage, Realtime, APIs, Functions, Studio und weitere Dienste als zusammenhängenden Stack mit.

Das macht die Bereitstellung übersichtlicher, reduziert aber nicht die technische Verantwortung. Für Produktion müssen beide Ebenen gemeinsam geplant werden: Coolify als Management-Plattform und Supabase als zustandsbehaftetes Backend.

Was Coolify bei Supabase übernimmt

Coolify kann je nach gewähltem Deployment unter anderem unterstützen bei:

• Bereitstellung der Container und Netzwerke
• Verwaltung von Domains und TLS
• Umgebungsvariablen und Secrets-Eingabe
• Status und Logs der Dienste
• kontrolliertem Neuaufbau von Containern
• gemeinsamer Verwaltung weiterer Frontends und Backends

Coolify ist dabei nicht die Supabase Cloud. Es übernimmt nicht automatisch die verwalteten Supabase-Plattformfunktionen wie Managed Backups, PITR, Branching oder vollständige Plattformmetriken.

Was zusätzlich geplant werden muss

1. Workload und Betriebsziel erfassen

Vor der Serverauswahl werden mindestens erfasst:

• erwartete Nutzer und gleichzeitige Zugriffe
• Datenbankgröße und Wachstum
• Anzahl und Art der Abfragen
• Storage-Volumen und Dateitransfer
• Realtime-Verbindungen
• Functions und Hintergrundjobs
• weitere Anwendungen auf demselben Coolify
• gewünschtes RPO und RTO
• akzeptierte Wartungs- und Ausfallzeit

Ein Hobby- oder Testsystem stellt andere Anforderungen als eine SaaS-Anwendung mit Kundendaten. Pauschale Mindestgrößen sind nur Startpunkte und ersetzen keine Messung.

2. Den Coolify-Host vorbereiten

Der Host benötigt:

• unterstütztes und gepflegtes Linux
• restriktive Firewall
• SSH-Zugriff über begrenzte Schlüssel oder VPN
• ausreichend schnellen und überwachten Storage
• saubere DNS-Einträge
• Backup-Ziel außerhalb der primären Fehlerdomäne
• Monitoring für CPU, RAM, Disk, I/O und Netzwerk

Coolify selbst ist ein privilegierter Verwaltungszugang. Oberfläche, Zugangsdaten und Wiederherstellungsverfahren werden entsprechend geschützt. Der Ausfall oder Verlust der Management-Ebene darf nicht den einzigen Weg zur Dokumentation und Wiederherstellung beseitigen.

3. Vorlage und Versionen vor dem Deploy prüfen

Supabase Self-Hosting entwickelt sich weiter. Vorlagen in Plattformen können hinter dem offiziellen Repository liegen oder eigene Anpassungen enthalten. Vor dem ersten Start werden deshalb verglichen:

• Quelle und Aktualität der Coolify-Vorlage
• verwendete Supabase-Image-Stände
• PostgreSQL-Version
• erforderliche Umgebungsvariablen
• Volume- und Storage-Pfade
• öffentliche und interne Ports
• Update-Verfahren für spätere Releases

Ein funktionsfähiger aktueller Ausgangsstand ist einfacher zu betreiben als ein unbekannter Mix beweglicher Image-Tags.

4. Domains, TLS und Endpunkte planen

Die Anwendung benötigt eine stabile Supabase-URL. Zusätzlich sind interne und administrative Endpunkte zu unterscheiden.

Zu konfigurieren sind:

• öffentliche API-Domain
• TLS-Zertifikat und Erneuerung
• Site URL und Auth-Redirects
• OAuth-Callback-URLs
• erlaubte CORS-Ursprünge
• E-Mail-Links
• Studio- und Administrationszugriff
• direkte PostgreSQL- oder Pooling-Verbindungen

Studio und Datenbankports werden nicht ohne Grund öffentlich ausgestellt. Administration kann über VPN oder ein eingeschränktes Netz erfolgen.

5. Secrets und Auth-Konfiguration

Vor Produktion werden zufällige, voneinander getrennte Geheimnisse verwendet. Dazu gehören je nach Stack:

• PostgreSQL-Zugang
• JWT- und API-Schlüssel
• Dashboard- und Studio-Zugang
• SMTP-Credentials
• OAuth-Provider
• Function-Secrets
• externe Storage- oder Webhook-Zugänge

Beispielwerte aus Vorlagen dürfen nicht bestehen bleiben. Secrets werden nicht in Screenshots, Logs oder ein öffentliches Git-Repository übernommen. Für Rotation und Wiederherstellung existiert ein Verfahren.

6. SMTP und Auth vollständig testen

Ohne korrektes SMTP funktionieren wichtige Abläufe nur eingeschränkt oder unzuverlässig:

• Registrierung und Bestätigung
• Magic Links
• Passwort-Reset
• Einladungen
• Änderung der E-Mail-Adresse

Für jeden verwendeten OAuth-Provider werden erlaubte Domains und Callback-URLs angepasst. Testkonten decken Login, Logout, Token-Refresh und Fehlerzustände ab.

7. Storage bewusst auswählen

Die Datenbank speichert Metadaten zu Supabase Storage, nicht automatisch eine unabhängige Kopie der Dateien. Geprüft werden:

• lokales Volume oder kompatibles Objektziel
• erwartete Kapazität und Wachstum
• Upload- und Download-Durchsatz
• private und öffentliche Buckets
• Storage-RLS
• Backup und Restore der eigentlichen Objekte

Läuft Storage lokal auf demselben Host, teilt es dessen Ausfallrisiko. Ein externes Storage-Ziel benötigt weiterhin Zugriffs-, Lifecycle- und Backup-Regeln.

8. Erstabnahme mit echten Nutzerwegen

Nach dem Deploy werden nicht nur grüne Container geprüft:

1. Registrierung und Login
2. Passwort-Reset oder Magic Link
3. lesender und schreibender API-Zugriff
4. RLS-Test mit zwei Nutzern oder Mandanten
5. Datei-Upload und privater Download
6. Realtime-Verbindung
7. Function-Aufruf und Fehlerfall
8. SMTP, OAuth und Webhook
9. Neustart der Plattform
10. Backup-Lauf und dokumentierte Restore-Probe

9. Backups außerhalb von Coolify

Eine vollständige Sicherung umfasst getrennt:

• PostgreSQL
• Storage-Objekte
• Coolify- und Supabase-Konfiguration
• Schema-Migrationen und Function-Code
• Image- und Versionsstände
• Wiederherstellungsverfahren für Secrets und Domains

Ein Server-Snapshot kann ergänzen, ersetzt aber nicht automatisch konsistente, getestete Datenbank- und Storage-Backups. Der Artikel Supabase vollständig sichern beschreibt die Ebenen.

10. Updates kontrolliert durchführen

Ein „Redeploy latest“ ist kein sicherer Update-Prozess. Vor jedem relevanten Update werden:

• offizielle Supabase-Änderungen gelesen
• Coolify-Vorlage und lokaler Stand verglichen
• Backups geprüft
• Update in Staging getestet
• Auth, RLS, Storage und Functions abgenommen
• Wartungsfenster und Rückfall definiert

Weitere Details stehen unter Supabase Self-Hosted aktualisieren.

Wann Supabase und Coolify getrennt werden sollten

Eine Trennung kann sinnvoll werden, wenn:

• PostgreSQL konstante oder hohe I/O-Last erzeugt
• mehrere Apps um Ressourcen konkurrieren
• unterschiedliche Wartungsfenster gelten
• ein Management-Update die Datenbank nicht beeinflussen darf
• höhere Verfügbarkeits- oder Recovery-Ziele bestehen
• Verantwortlichkeiten getrennt sind

Der richtige Zeitpunkt folgt aus Messwerten und Risiko, nicht aus einer pauschalen Regel.

Quellen

• Supabase: Self-Hosting mit Docker
• Supabase: Self-Hosted Deployment aktualisieren
• Coolify: Installation
• Hetzner Community: Supabase mit Coolify bereitstellen