Supabase selbst hosten im Produktivbetrieb: Setup, Backup, Kosten

Wann lohnt es sich, Supabase selbst zu hosten?

Supabase ist eine Plattform um die Datenbank PostgreSQL herum: Datenbank, Anmeldung, Dateiablage und serverseitige Funktionen in einem Paket. Supabase ist quelloffen und lässt sich vollständig selbst betreiben. Der Unterschied zur verwalteten Instanz liegt im Betrieb, nicht im Code. Wie wir Anwendungen auf dieser Grundlage bauen, beschreibt die Seite Supabase in Entwicklung und Betrieb.

Selbst hosten ist sinnvoll, wenn Auflagen verlangen, dass Daten auf eigenen Servern liegen, wenn eine bestehende Serverlandschaft genutzt werden soll oder wenn die Installation ohne Verbindung nach außen laufen muss. Als Grundeinstellung empfehlen wir es nicht, weil der Betrieb dann bei Ihnen oder bei Ihrem Dienstleister liegt und nicht beim Anbieter.

Laut Supabase-Dokumentation fehlen im Selbstbetrieb einige Funktionen der verwalteten Plattform, darunter Branching für Vorschau-Umgebungen, verwaltete Sicherungen mit Point-in-Time-Recovery und die Management-Schnittstelle der Plattform. Der Selbstbetrieb ist laut Dokumentation community-gestützt: Hilfe gibt es über GitHub, Discord und Foren, und Einrichtung, Absicherung, Updates und Sicherungen liegen beim Betreiber. Die Rechtsfragen rund um den Serverstandort beschreibt der Ratgeber DSGVO-konformes Hosting in Deutschland.

Aus welchen Komponenten besteht eine selbst gehostete Supabase-Installation?

Die offizielle Docker-Compose-Konfiguration startet eine Reihe von Diensten, die zusammen die Plattform ergeben:

Supabase nennt als Mindestausstattung 4 GB Arbeitsspeicher, 2 Prozessorkerne und 40 GB SSD-Speicher; empfohlen sind 8 GB, 4 Kerne und 80 GB. Nicht benötigte Dienste lassen sich abschalten, um Ressourcen zu sparen. Für den Produktivbetrieb ist die empfohlene Ausstattung der sinnvollere Ausgangspunkt, weil Datenbank, Dateien und Protokolle mitwachsen.

Wie sieht ein produktives Setup aus?

Wir setzen selbst gehostetes Supabase auf Ubuntu mit Docker Compose auf, davor Nginx als Reverse Proxy mit automatisch erneuerten Zertifikaten. Die Supabase-Dokumentation empfiehlt für den Produktivbetrieb ebenfalls einen Reverse Proxy wie Caddy oder Nginx vor dem API-Gateway, weil HTTPS mit gültigem Zertifikat nötig ist, spätestens bei einer Anmeldung über OAuth-Anbieter.

1. 01

   Server vorbereiten

   Aktuelles Ubuntu mit eingespielten Sicherheitsupdates, Anmeldung per SSH-Schlüssel statt Passwort, eigene Benutzer für die Administration.

2. 02

   Konfiguration anlegen

   Die Docker-Compose-Konfiguration aus dem offiziellen Repository übernehmen und die Umgebungsdatei vollständig mit eigenen Werten füllen. Die Beispielwerte dürfen nie in Betrieb gehen.

3. 03

   Reverse Proxy und Zertifikate

   Nginx nimmt die Anfragen per HTTPS entgegen und leitet sie an das API-Gateway weiter. Zertifikate werden automatisch erneuert, damit kein abgelaufenes Zertifikat die Anwendung lahmlegt.

4. 04

   Daten auf eigene Datenträger

   Datenbankdateien und Dateiablage liegen in Verzeichnissen, die gesichert und überwacht werden. Wer Storage mit einem S3-kompatiblen Speicher betreibt, bezieht diesen in die Sicherung ein.

5. 05

   Migrationen einspielen

   Schema und Row-Level-Security-Policies kommen als Migrationsdateien aus der Versionskontrolle, nicht aus Klicks im Dashboard. So lässt sich jede Umgebung reproduzierbar aufbauen.

Wie sichern Sie selbst gehostetes Supabase ab?

Die Beispielkonfiguration ist für einen Test gedacht, nicht für den Betrieb. Vor dem ersten echten Datensatz sollten diese Punkte erledigt sein:

• Eigene Geheimnisse: Datenbank-Passwort, Dashboard-Passwort, die Schlüssel zum Signieren der Anmelde-Token und alle weiteren Schlüssel der Umgebungsdatei neu erzeugen. Die Dokumentation liefert dafür Skripte mit.
• API-Schlüssel richtig verteilen: Der öffentliche Schlüssel (Publishable Key, früher anon key) darf in Browser und App, weil seine Rechte über Row Level Security begrenzt sind. Der geheime Schlüssel (Secret Key, früher service_role key) umgeht Row Level Security und gehört nur in serverseitige Umgebungen und Edge Functions — nie in eine Client-Anwendung, nie ins Repository.
• Studio nicht öffentlich: Das Dashboard ist im Standard nur mit Benutzername und Passwort geschützt. Im Produktivbetrieb sollte es nur über VPN, einen SSH-Tunnel oder freigegebene IP-Adressen erreichbar sein.
• Firewall: Von außen sind nur HTTPS und der Verwaltungszugang erreichbar. Die Datenbank-Ports bleiben geschlossen, solange keine Anwendung außerhalb des Servers direkt darauf zugreifen muss.
• Row Level Security auf jeder Tabelle: Jede Tabelle mit Kundendaten bekommt ihre Policies, bevor sie Daten enthält.
• Updates: Betriebssystem, Docker und Supabase-Dienste werden regelmäßig aktualisiert, nicht erst nach einer Sicherheitsmeldung.

Wie sichern Sie die Daten einer selbst gehosteten Supabase-Instanz?

Im Selbstbetrieb gibt es keine verwalteten Sicherungen. PostgreSQL kennt drei grundlegend verschiedene Wege der Sicherung; im Produktivbetrieb ist eine Kombination sinnvoll. WAL steht dabei für Write-Ahead Log, das Protokoll, in dem PostgreSQL jede Änderung an den Datendateien festhält.

Die Datenbank ist nicht alles. Die Dateien in Storage liegen außerhalb der Datenbank, auf einem eigenen Datenträger oder in einem S3-kompatiblen Speicher, und brauchen eine eigene Sicherung. Dasselbe gilt für die Umgebungsdatei mit den Schlüsseln, verschlüsselt abgelegt. Ohne sie passen wiederhergestellte Daten und Anwendung nicht mehr zusammen, weil neue Schlüssel in allen Clients ausgetauscht werden müssten.

Für alle Teile gilt das 3-2-1-Prinzip: drei Kopien, zwei verschiedene Medien, eine davon außer Haus. Ein Auszug gehört an einen Ort, der weder auf demselben Server noch im selben Konto liegt. Und eine Sicherung gilt erst dann als Sicherung, wenn sie in eine leere Umgebung zurückgespielt wurde und die Anwendung danach läuft. Diesen Wiederherstellungstest dokumentieren wir, statt nur einen Kopiervorgang zu prüfen. Wie das Prinzip im Alltag aussieht, beschreibt der Ratgeber zum Backup-Konzept nach 3-2-1.

Wie überwachen und aktualisieren Sie die Installation?

Ein selbst gehosteter Dienst braucht dieselbe Überwachung wie jeder andere Server: Erreichbarkeit der Schnittstelle von außen, Auslastung von Prozessor, Arbeitsspeicher und Datenträgern, Laufzeit der Zertifikate, Erfolg der nächtlichen Sicherung und das Wachstum des WAL-Archivs. Wichtig ist eine Alarmierung, die jemand liest. Ein Fehlerprotokoll, das niemand öffnet, ist keine Überwachung.

Supabase veröffentlicht nach eigenen Angaben etwa einmal im Monat einen stabilen Stand der Docker-Compose-Konfiguration. Ein mitgeliefertes Skript übernimmt die Aktualisierung und führt die neue Konfiguration mit Ihren Anpassungen zusammen. Änderungen laufen bei uns zuerst auf einer Testumgebung und erst danach im Betrieb. Vor jede Aktualisierung gehört eine frische Sicherung. Ein Sprung auf eine neue Hauptversion von PostgreSQL ist ein eigenes kleines Projekt und gehört nicht in ein Routine-Update.

Was kostet der Selbstbetrieb von Supabase?

Die Software selbst verursacht keine Lizenzkosten. Die Kosten entstehen im Betrieb, und sie lassen sich in vier Arten einteilen:

Serverpreise nennen wir hier bewusst nicht, weil sie sich je nach Anbieter und Ausstattung stark unterscheiden und schnell ändern. Die Position, die man leicht unterschätzt, ist der Betriebsaufwand: Er fällt jeden Monat an, auch wenn nichts passiert. Wie sich die Kosten einer Anwendung über Entwicklung und Betrieb verteilen, beschreibt der Ratgeber Was kostet Individualsoftware wirklich?.

Wann ist die verwaltete Supabase-Instanz die bessere Wahl?

Die verwaltete Instanz in einer EU-Region ist der übliche Weg, wenn keine Auflage dagegen spricht. Supabase betreibt die Instanz, Point-in-Time-Recovery gibt es, wo der Tarif es hergibt, und die Region wird beim Anlegen auf die EU festgelegt; nachträglich lässt sie sich nicht ändern. Vor dem ersten echten Datensatz steht der Auftragsverarbeitungsvertrag mit dem Anbieter. Die verwaltete Instanz ist die bessere Wahl, wenn

• keine Auflage eigene Server verlangt,
• niemand im Betrieb oder beim Dienstleister Updates, Überwachung und Wiederherstellungstests verlässlich übernimmt,
• Funktionen wie Branching oder Point-in-Time-Recovery gebraucht werden, ohne sie selbst aufzubauen,
• die Anwendung noch klein ist und der Betriebsaufwand in keinem Verhältnis zum Nutzen stünde.

Ein späterer Wechsel bleibt möglich: Unter Supabase liegt eine gewöhnliche PostgreSQL-Datenbank, deren vollständiger Auszug sich in jede andere Postgres-Installation einspielen lässt. Gebunden ist man an die Zusatzdienste, nicht an die Daten. Bei unserer Individualsoftware halten wir die Fachlogik deshalb in der Anwendung und nicht in anbieterspezifischen Bausteinen und übergeben Quellcode, Migrationen und Deployment-Anleitung vollständig.