Supabase auf Hetzner betreiben: Architektur, Kosten und Betrieb

Sie möchten Supabase auf Hetzner bereitstellen oder aus der Cloud migrieren, ohne den laufenden Betrieb selbst aufzubauen? WZ-IT übernimmt Supabase Managed Hosting, Migration und Betrieb auf dedizierter oder kundeneigener Infrastruktur.

Supabase auf Hetzner betreiben ist technisch gut möglich: Der Self-Hosted-Stack wird mit Containern bereitgestellt und Hetzner bietet Cloud-Server, Dedicated Server, Netzwerke und Speicherbausteine. Die eigentliche Architekturentscheidung beginnt aber nach dem ersten erfolgreichen Start.

Für eine produktive Plattform müssen Datenbank, Auth, Storage, Realtime, Functions, Netzwerk, Backup, Monitoring und Updates als ein System geplant werden.

Wann Hetzner als Supabase-Ziel sinnvoll ist

Typische Gründe sind:

• kontrollierbarer Betriebsort in Europa
• dedizierte oder kundeneigene Infrastruktur
• private Verbindungen zu weiteren Systemen
• planbare Ressourcen für PostgreSQL
• Migration aus Supabase Cloud oder einem Prototyp
• Integration in bestehende Hetzner- oder WZ-IT-Umgebungen
• Wunsch nach einem klaren Managed-Betriebsmodell

Der Betriebsort allein erzeugt weder Sicherheit noch Souveränität. Kontrolle entsteht erst durch dokumentierte Zugänge, Portabilität, Backups, Wiederherstellung und benannte Verantwortlichkeit.

Cloud Server oder Dedicated Server

Ein produktiver Einstieg kann auf einem einzelnen System erfolgen, wenn die Anwendung ein dokumentiertes Wartungs- und Ausfallfenster toleriert. Hohe Verfügbarkeitsziele benötigen dagegen eine andere Architektur: getrennte Fehlerdomänen, Replikation, Load Balancing und getestete Failover-Prozesse. Mehr Container auf demselben Host erzeugen keine Hochverfügbarkeit.

Sizing: nicht nur Nutzer zählen

Relevante Treiber sind:

• Größe und Wachstum der PostgreSQL-Datenbank
• gleichzeitige Datenbankverbindungen
• Komplexität und Laufzeit der Abfragen
• Realtime-Verbindungen und Ereignisrate
• Upload-, Download- und Storage-Volumen
• Edge Functions und deren Ressourcenbedarf
• Hintergrundjobs, Webhooks und Importe
• erwartete Spitzenlast
• Backup- und Restore-Dauer

CPU, Arbeitsspeicher, IOPS, lokale Kapazität und Netzwerk werden gemeinsam geplant. PostgreSQL profitiert häufig stärker von ausreichend RAM und stabiler Storage-Latenz als von einer pauschal hohen Anzahl virtueller CPUs.

Eine sinnvolle Basisarchitektur

Für eine klar begrenzte Anwendung kann der Einstieg so aussehen:

1. Hetzner Cloud oder Dedicated Server in der gewünschten Region
2. gehärtetes Linux und restriktive Firewall
3. Docker Compose oder eine kontrollierte Coolify-Instanz
4. Reverse Proxy mit TLS und eigener Supabase-Domain
5. Supabase-Dienste mit festen Image-Ständen
6. lokales oder externes PostgreSQL entsprechend der Architektur
7. Storage-Backend und unabhängiges Backup-Ziel
8. Monitoring, Logs und Alarmierung
9. private Administration über VPN oder begrenzte Zugänge

Studio und interne Verwaltungsendpunkte sollten nicht unnötig öffentlich erreichbar sein.

Direktes Docker Compose oder Coolify?

Die offizielle Supabase-Dokumentation beschreibt Docker als Self-Hosting-Weg. Hetzner veröffentlicht zusätzlich eine Community-Anleitung für Supabase mit Coolify.

Direktes Docker Compose:

• bleibt nahe an der offiziellen Vorlage
• macht Änderungen und Overrides explizit
• eignet sich für Git-basierten Infrastrukturprozess
• verlangt eigene Bedien- und Deployment-Automatisierung

Coolify:

• bietet eine zentrale Oberfläche für Deployments und Domains
• kann App- und Plattformbetrieb vereinfachen
• eignet sich für mehrere verwaltete Workloads
• fügt eine zusätzliche Management-Ebene hinzu, die ebenfalls gesichert und aktualisiert werden muss

Coolify ersetzt weder Supabase-Releaseprüfung noch PostgreSQL-Backup, Storage-Sicherung und Restore-Test.

Netzwerk und öffentliche Exposition

Öffentlich benötigt werden nur die Endpunkte, die Anwendung und Auth-Flows tatsächlich verwenden. Geprüft werden:

• DNS und TLS
• API-Gateway und erlaubte Origins
• OAuth-Redirects
• SMTP und E-Mail-Links
• Webhooks und externe Callbacks
• Adminzugänge
• direkte PostgreSQL-Verbindungen
• private Netze zu Anwendungen oder Backends

Administrativer Zugriff kann über Managed NetBird oder einen anderen kontrollierten VPN-Weg erfolgen. Datenbankports und Studio werden nicht pauschal für das Internet geöffnet.

Storage-Entscheidung

Supabase Storage benötigt neben PostgreSQL-Metadaten einen Ort für die eigentlichen Objekte. Je nach Stack und Anforderungen kommen lokale Volumes oder ein kompatibles Objekt-Storage-Ziel infrage.

Zu bewerten sind:

• erwartetes Datenvolumen und Wachstum
• Durchsatz und Dateigrößen
• Zugriffslatenz
• Redundanz
• Lebenszyklus und Löschung
• Kosten für Speicher und Datenübertragung
• getrennte Backup- und Restore-Fähigkeit

Lokaler Speicher auf einem einzelnen Server ist einfach, koppelt Dateien aber an dessen Fehlerdomäne. Ein externes Objektziel löst nicht automatisch Backup und Datenkonsistenz.

Backups und Wiederherstellung

Ein belastbarer Betrieb sichert getrennt:

• PostgreSQL einschließlich Auth und Metadaten
• Storage-Dateien
• Compose-, Coolify- und Proxy-Konfiguration
• Function-Code und Schema-Migrationen
• Verfahren für Secrets, OAuth, SMTP und Domains

Die Kopien liegen nicht ausschließlich auf demselben Server. Ein Restore-Test prüft, ob Datenbankstand, Storage-Objekte und Anwendung wieder zusammenpassen. Details erläutert der Artikel Supabase vollständig sichern.

Monitoring und laufender Betrieb

Technisches Monitoring betrachtet:

• Erreichbarkeit von API und Auth
• CPU, RAM, Disk, I/O und Netzwerk
• PostgreSQL-Verbindungen, Locks und Fehler
• Containerzustände und Neustarts
• Storage-Kapazität
• Function- und Gateway-Fehler
• Backup-Erfolg und Alter
• TLS-Zertifikate

Zusätzlich sind synthetische Nutzerwege sinnvoll, etwa Login, lesender API-Zugriff und ein kontrollierter Dateiabruf. Sie erkennen Fehler, die reine Container-Health-Checks übersehen.

Updates und Verantwortung

Beim Self-Hosting übernimmt nicht Supabase automatisch:

• Prüfung neuer Versionen
• Zusammenführung offizieller und lokaler Konfiguration
• Sicherung vor Änderungen
• Staging und Kompatibilitätstests
• Wartungsfenster
• Smoke Tests und Rückfall

Ein Managed-Service-Modell legt Patch-Zyklus, Monitoring, Backup-Kontrolle, Incident-Reaktion und Änderungsprozess fest. Mehr dazu zeigt Supabase Self-Hosted aktualisieren.

Kosten realistisch vergleichen

Der Serverpreis ist nur eine Zeile der Gesamtbetriebskosten:

• Rechenleistung und primärer Speicher
• Objekt- oder Backup-Speicher
• Monitoring und Log-Aufbewahrung
• Einrichtung und Migration
• Updates und Sicherheitsprüfungen
• Bereitschaft und Incident-Reaktion
• Restore-Tests
• Kapazitätsanpassungen

Ein fairer Vergleich mit Supabase Cloud setzt identische Anforderungen an Backup, Verfügbarkeit und Verantwortlichkeit voraus. Die Analyse Supabase-Kosten: Cloud vs. Self-Hosted zeigt die vollständige Struktur.

Quellen

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