Supabase self-hosted: Was zwischen Docker Compose und Produktion fehlt

Vorab die Ausgangslage: Supabase liefert für das Self-Hosting eine fertige Docker-Compose-Vorlage. Auf einem frischen Server läuft der komplette Stack damit in wenigen Minuten, samt Studio, Anmeldung und REST-API. Genau das verführt zu einer falschen Rechnung. Wer die Vorlage startet, hat eine Entwicklungsumgebung, aber noch keinen Betrieb.

Was fehlt, steht in keiner Compose-Datei. Wer sichert die Datenbank, und wie spielt man sie zurück? Wo liegen die Schlüssel, und wer darf sie lesen? Was passiert beim nächsten Upgrade, wenn ein Dienst einen neueren Datenbankstand erwartet? Wir haben diese Fragen in Runbooks für den Produktivbetrieb beantwortet. Dieser Leitfaden fasst zusammen, was zwischen docker compose up und einem System liegt, dem du Kundendaten anvertrauen kannst.

Für wen das gilt: für Teams, die Supabase aus Gründen der Datenhoheit selbst betreiben wollen, etwa auf Hetzner, im eigenen Rechenzentrum oder auf Kubernetes. Wer mit der Supabase Cloud in Frankfurt arbeitet, bekommt den Betrieb mitgeliefert. Für dich ist dieser Text eine Checkliste dessen, was du dort mitbezahlst.

Zum Thema Umfang: Supabase ist keine einzelne Anwendung, sondern ein Verbund aus Open-Source-Diensten rund um Postgres. Die Compose-Vorlage startet sie als getrennte Container (Stand Oktober 2026):

Logflare und Vector für die Protokolle liegen in einer zweiten, optionalen Compose-Datei. Für den Start kannst du sie weglassen, solange du Logs auf anderem Weg einsammelst. Wer die Anmeldung über einen eigenen Identity-Provider abwickeln will, findet den Aufbau in unserem Artikel zu Supabase und Keycloak.

Die Pointe: Jeder dieser Dienste hat eigene Versionen, eigene Konfiguration und eigene Fehlerbilder. Wer Supabase selbst betreibt, betreibt zehn Dienste, die sich auf dieselbe Datenbank und dieselben Schlüssel verlassen. Das ist beherrschbar. Aber es ist Betrieb und kein Hosting.

Alle anderen Dienste sind austauschbar: Fällt Realtime aus, startest du den Container neu. Bei Postgres funktioniert das nur, solange die Daten unversehrt sind. Deshalb bekommt die Datenbank einen eigenen Lebenszyklus mit eigenem Speicher, eigenem Backup und eigenen Upgrade-Regeln. Wie du Zugriffsrechte direkt in der Datenbank regelst, beschreibt unser Artikel zu Row Level Security.

Du hast drei Wege. Der Postgres-Container aus der Compose-Vorlage ist der einfachste, verlangt aber Backups in Eigenregie. Auf Kubernetes übernimmt ein Operator wie CloudNativePG die Einrichtung, die fortlaufende Archivierung und die Wiederherstellung. Ein externer Managed-Postgres-Dienst nimmt dir den Betrieb ab, erlaubt aber oft nicht die Erweiterungen, die Supabase voraussetzt.

Der Grund für die Einschränkung: Erweiterungen wie pgsodium und pg_net müssen beim Start der Datenbank geladen werden und brauchen weitreichende Rechte. Viele Managed-Angebote erlauben beides nicht oder nur für eine feste Liste. Prüf deshalb vor der Entscheidung, ob jede Erweiterung, die Supabase nutzt, bei deinem Anbieter verfügbar ist.

Hier liegt der Stolperstein, den kaum eine Anleitung erwähnt. Das Image supabase/postgres legt beim ersten Start über sein Startskript Rollen, Schemata und Erweiterungen an. Ein Operator wie CloudNativePG richtet die Datenbank aber selbst ein und überspringt dieses Startskript. Ohne Gegenmaßnahme fehlen danach das Schema auth, die Rolle supabase_admin und alles, worauf Auth und Storage aufbauen.

Unsere Lösung: Wir kopieren die Init-SQL-Dateien aus genau dem Image-Tag, den wir betreiben, und spielen sie einmalig über einen Migrationsjob ein. Jede angewendete Datei erhält einen Eintrag in einer Protokolltabelle. Ein zweiter Lauf überspringt sie, ein abgebrochener Lauf setzt an der fehlerhaften Datei wieder an.

Daraus folgt eine harte Regel: Ein neuer Image-Tag bringt neue Init-Dateien mit. Tag und eingespielte SQL wechseln deshalb immer gemeinsam, nie einzeln.

Verdichtet: Bei Supabase ist die Datenbank nicht nur Speicher, sondern Teil der Anwendung. Wer sie wie ein beliebiges Postgres behandelt, merkt es spätestens beim ersten Login, der nicht funktioniert.

Supabase lebt von Schlüsseln, und sie hängen voneinander ab. Die mitgelieferten Skripte generate-keys.sh und add-new-auth-keys.sh schreiben sie in eine .env-Datei. Für die Entwicklung ist das in Ordnung. In Produktion gehört diese Datei weder auf den Server noch in Git.

In unseren Runbooks liegt jeder Wert in einem Passwortmanager und gelangt über den External Secrets Operator in den Cluster. Der Operator liest die Felder und legt daraus Kubernetes-Secrets an. Im Git-Repository stehen nur Verweise, nie Werte.

Ob die Quelle Bitwarden, HashiCorp Vault oder der Dienst eines Cloud-Anbieters ist, entscheidet dein Team. Entscheidend ist, dass es genau eine Quelle gibt und dass ihr Export getrennt von den Servern liegt.

Eine Ausnahme bleibt: Der Zugang, mit dem der Cluster den Passwortmanager entsperrt, kann nicht selbst darin liegen. Diesen einen Wert legen wir einmalig von Hand an und nutzen dafür ein eigenes Konto, das nur die Werte dieser Plattform enthält. Wer dieses Secret lesen kann, kann das Konto entsperren. Deshalb ist der Lesezugriff darauf im Cluster eng begrenzt.

Ein typischer Fehler aus der Praxis: Auth und PostgREST prüfen Tokens mit unterschiedlichen Schlüsseln. Die Anmeldung klappt, jede Abfrage über /rest/v1 scheitert mit einem JWT-Fehler. Ursache ist fast immer ein Dienst, der noch einen alten Wert hält. Deshalb tauschen wir Schlüssel immer für alle Dienste gleichzeitig aus.

Das API-Gateway führt alle Pfade auf einem Port zusammen. Öffentlich erreichbar sein müssen davon nur die API-Pfade: Auth, REST, GraphQL, Realtime, Storage und Functions unter /auth/v1, /rest/v1 und so weiter. Alles andere gehört ins interne Netz.

Eine Kleinigkeit mit großer Wirkung: Damit eine IP-Freigabe greift, muss der Ingress die echte Absenderadresse sehen. Auf Kubernetes heißt das externalTrafficPolicy: Local am Ingress-Service. Ohne diese Einstellung prüft die Freigabe die Adresse des Knotens, und Studio ist entweder für alle offen oder für niemanden.

Die Compose-Vorlage legt hochgeladene Dateien standardmäßig auf der lokalen Festplatte ab. Für einen Testbetrieb reicht das. In Produktion verknüpft es zwei Dinge, die getrennt gehören: Fällt der Server aus, sind Datenbank und Dateien gleichzeitig weg. Und wachsen die Dateien, läuft die Platte der Datenbank voll.

Wir setzen deshalb immer einen S3-kompatiblen Objektspeicher außerhalb des Servers ein, etwa Hetzner Object Storage, Cloudflare R2 oder AWS S3. Storage und imgproxy lesen und schreiben in denselben Bucket.

Die Unterschiede zwischen den Anbietern stecken im Detail. Bei AWS bleibt der Endpunkt leer, alle anderen brauchen ihre Adresse und die Path-Style-Adressierung. Bei Cloudflare R2 musst du zusätzlich die S3-Tags für fortsetzbare Uploads abschalten, sonst antwortet Storage mit dem Fehler 500.

Und der Satz, den wir in jedes Runbook schreiben: Ein Backup, das im selben Bucket liegt wie die Live-Daten, ist kein Backup. Für die Datenbanksicherung gibt es deshalb einen zweiten Bucket mit eigenem Zugangsschlüssel.

Zum Thema Sicherung zuerst die unbequeme Frage: Wann hast du zuletzt ein Backup zurückgespielt? Ein Dump, der jede Nacht entsteht, beweist nur, dass ein Dump entsteht. Ob daraus wieder ein funktionierendes Supabase wird, zeigt erst die Wiederherstellung.

Eine Wiederherstellungsprobe läuft bei uns in fünf Schritten: frische Umgebung aufsetzen, Datenbank aus dem Backup wiederherstellen, die Dienste darauf zeigen lassen, den Migrationsjob starten und in Studio eine Zeile lesen, die vor dem Backup geschrieben wurde.

Der Migrationsjob muss dabei nichts tun, weil seine Protokolltabelle mitgesichert wurde. Tut er doch etwas, stimmt etwas nicht. Diese Prüfung kostet eine Minute und erspart dir die Überraschung im Ernstfall.

Ein Detail mit Folgen: Scheitert die Archivierung der Write-Ahead-Logs, bewahrt Postgres die Dateien auf, bis sie archiviert sind. Eine falsch eingerichtete Sicherung füllt so unbemerkt die Platte, bis die Datenbank stehen bleibt. Wir schalten Backups deshalb erst ein, wenn die Grundinstallation läuft, und lösen danach sofort eine erste Sicherung von Hand aus.

Verdichtet: Ein Restore, den du nie geprobt hast, ist eine Hypothese. Ob du die Probe regelmäßig machst oder nur vor großen Upgrades, ist eine Kostenfrage. Dass du sie mindestens einmal machst, ist keine.

Die Compose-Vorlage verweist auf Image-Tags, und Supabase veröffentlicht häufig neue. Die Versuchung ist groß, regelmäßig alles auf den neuesten Stand zu ziehen. Wir machen das Gegenteil: Jede Version ist festgeschrieben, jedes Image zusätzlich über seinen Digest, also die Prüfsumme seines konkreten Inhalts. Ein Tag kann neu vergeben werden, ein Digest nicht.

Tabellen, Policies und Funktionen änderst du im Produktivsystem nicht per Klick in Studio, sondern über Migrationsdateien im Repository. Die Supabase CLI legt sie lokal an, etwa mit supabase migration new. Die lokale config.toml dient nur der Entwicklungsumgebung, der Server liest sie nicht.

In Produktion spielt derselbe Migrationsjob, der die Init-SQL einspielt, auch deine Migrationen ein: in fester Reihenfolge und jede genau einmal. Eine Tabelle merkt sich, welche Version angewendet wurde. Seed-Daten bleiben standardmäßig aus, weil sich ein Seed selten zweimal ausführen lässt, ohne Schaden anzurichten.

Der Gewinn zeigt sich doppelt: Nach einem Restore kennt die Datenbank ihren eigenen Stand. Und jede Änderung ist in Git nachvollziehbar, mit Autor, Datum und Review.

Im Self-Hosting lädt die Edge Runtime deine Funktionen aus einem Verzeichnis. Wir bauen sie deshalb in ein eigenes Image auf Basis von supabase/edge-runtime, versioniert wie jede andere Software. So läuft in Produktion genau der Code, der getestet wurde.

Eine Einschränkung solltest du kennen: Die JWT-Prüfung gilt im Self-Hosting für alle Funktionen gemeinsam. Die Einstellung verify_jwt je Funktion aus der lokalen config.toml greift dort nicht. Braucht eine einzelne Funktion eine Ausnahme, prüfst du das Token in der Funktion selbst.

Damit zur Frage, die eigentlich am Anfang stehen sollte: Welcher Betriebsweg passt zu deinem Team? Unsere Standardempfehlung ist entweder die Supabase Cloud in Frankfurt oder Supabase self-hosted auf einem Hetzner-Server. Kubernetes kommt dazu, wenn dein Team Kubernetes ohnehin betreibt oder Deployments vollständig aus Git steuern will.

Ehrlich gesagt: Ein einzelner Kubernetes-Knoten ist keine Hochverfügbarkeit. Er bringt dir reproduzierbare Deployments und eine saubere Schlüsselverwaltung. Fällt der Server aus, steht der Dienst aber genau wie bei Docker Compose.

Wer echte Ausfallsicherheit braucht, braucht mehrere Knoten und eine Datenbank-Replik auf getrennter Hardware. Damit steigt der Betriebsaufwand deutlich. Für die meisten Projekte, die wir begleiten, ist ein sauber gesicherter einzelner Server mit geprobtem Restore die ehrlichere Wahl.

Zur Ehrlichkeit gehört die Gegenrichtung. Wir raten vom Self-Hosting ab, wenn niemand im Team die Verantwortung für Backups und Upgrades dauerhaft übernehmen kann. Ein System, das nach dem Weggang einer Person keiner mehr versteht, kostet mehr als jede Cloud-Rechnung.

Ebenso raten wir ab, wenn Hochverfügbarkeit Pflicht ist, das Budget aber nur einen Server hergibt. Dann ist die Supabase Cloud die ehrlichere Wahl. Und schließlich, wenn Datenhoheit gar nicht der Grund ist: Wer nur Kosten sparen will, setzt die eigene Arbeitszeit meist zu niedrig an.

Für die Planung ein paar feste Zahlen. Supabase nennt für die reine Compose-Variante 4 GB Arbeitsspeicher als Untergrenze. Auf Kubernetes kommen Cluster-Dienste hinzu: Ingress, Zertifikatsverwaltung, GitOps, Secret-Operator und Datenbank-Operator.

Unsere Runbooks setzen dafür mindestens 4 vCPU, 16 GB Arbeitsspeicher und 100 GB SSD an. Empfohlen sind 8 vCPU, 32 GB und 200 GB SSD, damit Studio, Realtime und ein Migrationsjob gleichzeitig laufen können, ohne dass der Speicher knapp wird.

Der größere Posten ist selten der Server, sondern die Arbeitszeit für Einrichtung, Proben und Upgrades. Wie sich Server, Speicher und Betrieb gegen die Cloud rechnen, steht in unserer ehrlichen TCO-Betrachtung.

Wenn du Supabase selbst betreiben willst, klär zuerst die Betriebsfrage und dann die Technik: Wer ist für Backups, Proben und Upgrades zuständig, auch in zwei Jahren noch? Die Betriebswege, unsere Preisrahmen und die Fälle, in denen wir abraten, findest du auf unserer Supabase-Seite.

Du willst wissen, welcher Weg zu deinem Projekt passt? Im Videogespräch gehen wir deine Anforderungen an Datenhoheit, Verfügbarkeit und Team durch. Danach weißt du, ob Cloud, Compose oder Kubernetes die richtige Wahl ist. Supabase-Erstgespräch vereinbaren