Supabase 2026 selbst auf einem VPS hosten (Ein Produktionsleitfaden)

Um Supabase selbst auf einem VPS zu hosten, klonst du den offiziellen Docker-Stack, änderst jedes Standard-Secret, startest die Container und packst das Ganze hinter einen Reverse Proxy mit HTTPS. Der Boot-Teil dauert etwa 15 Minuten. Der Teil, den die Listicles auslassen — Backups, Sicherheitshärtung und die Funktionen, die du gegenüber der Cloud klammheimlich verlierst — ist der Teil, der eigentlich entscheidet, ob du das überhaupt tun solltest. Dieser Leitfaden geht den kompletten Weg und ist ehrlich über die Kompromisse.

Supabase ist Open Source, also können dasselbe Postgres, Auth, Storage, Realtime und Studio, die du auf supabase.com bekommst, auf einem 20-$-VPS laufen, den du kontrollierst. Wir betreiben bei TechRiseUps unser eigenes Postgres, also geht die Tendenz hier dahin, den eigenen Stack zu besitzen — aber Selbst-Hosting ist ein echter Handel, kein kostenloses Mittagessen, und der Rest dieses Texts behandelt es so.

Was du bekommst und was du aufgibst

Der selbst gehostete Stack spiegelt ein einzelnes Cloud-Projekt wider, aber mehrere reine Plattform-Funktionen existieren in der Box schlicht nicht.

	Selbst gehostetes Supabase	Supabase Cloud
Kern (Postgres, Auth, Storage, Realtime, Studio)	Ja	Ja
Verwaltete Backups + Point-in-Time-Recovery	Du baust es	Eingebaut
Mehrere Projekte / Orgs in Studio	Nein (einzelnes Projekt)	Ja
Branching, erweiterte Metriken, ETL, Vector Buckets	Nein	Ja
Updates	Manuell, hinken manchmal dem Neuesten hinterher	Automatisch
Support	Nur Community	Bezahlte Pläne
Datenresidenz / volle Kontrolle	Total	Anbietergesteuert

Laut Supabases Self-Hosting-Doku sind Plattform-Funktionen wie Branching, verwaltete Backups, PITR, Analytics Buckets und die Management-API beim Selbst-Hosting nicht verfügbar. Du bekommst alles, was zum Betrieb einer App nötig ist — du bekommst nicht das verwaltete Sicherheitsnetz. Wenn dieses Sicherheitsnetz der Grund war, warum du Supabase überhaupt benutzt hast, lies den Kostenabschnitt am Ende, bevor du dich festlegst.

Schritt 0: den VPS richtig dimensionieren

Der mit Abstand häufigste Self-Hosting-Fehler ist Unterdimensionierung. Der Supabase-Stack betreibt rund 12–15 Container und liegt im Leerlauf bei 3–4 GB RAM, bevor sich auch nur ein Nutzer verbindet.

• 4 GB RAM sind die absolute Untergrenze — okay für Entwicklung oder ein Hobbyprojekt, das unter Last umkippen wird.
• 8 GB RAM sind der realistische Ausgangspunkt für alles, was du Produktion nennen würdest.
• 2 vCPU mindestens; 4, wenn Realtime oder Edge Functions Traffic abbekommen.
• Schneller NVMe-Speicher — Postgres ist I/O-empfindlich, und ebenso das Wiederherstellen eines Backups um 2 Uhr nachts.

Wenn du eine kleine Maschine behalten willst, kannst du Dienste, die du nicht nutzt (Realtime, Storage, imgproxy, Edge Runtime), aus der Compose-Datei streichen und ein bis zwei Gigabyte zurückholen. Für die Wahl der zugrunde liegenden Maschine vergleicht unser Ranking des besten VPS-Hostings 2026 echtes Preis-Leistungs-Verhältnis — und achte auf das Datenblatt, denn die VPS-RAM-Preise klettern das ganze Jahr.

Schritt 1: Docker installieren und den Stack ziehen

Installiere auf einem frischen Ubuntu-VPS die Docker Engine und das Compose-Plugin und schnapp dir dann den offiziellen Stack mit einem flachen Klon (du brauchst nicht die gesamte Repo-Historie):

git clone --depth 1 https://github.com/supabase/supabase
mkdir supabase-project
cp -rf supabase/docker/* supabase-project
cp supabase/docker/.env.example supabase-project/.env
cd supabase-project
docker compose pull

Das gibt dir eine .env-Datei, die das gesamte Deployment steuert, sowie die Compose-Definition für Postgres, GoTrue (Auth), PostgREST, Realtime, Storage, das Kong-API-Gateway und Studio.

Schritt 2: die Secrets ändern, auf die es ankommt (überspring das nicht)

Das ist der Schritt, der ein Selbst-Hosting in eine Datenpanne verwandelt. Der offizielle Docker-Leitfaden ist unverblümt: "Starte dein selbst gehostetes Supabase niemals mit diesen Standardwerten." Bevor du irgendetwas bootest, bearbeite .env und generiere neu:

• POSTGRES_PASSWORD — das Passwort deines Datenbank-Superusers. Verwende nur Buchstaben und Zahlen, um URL-Kodierungs-Bugs zu umgehen.
• JWT_SECRET plus einen frischen ANON_KEY und SERVICE_ROLE_KEY — diese signieren und autorisieren jedes API-Token. Generiere sie mit dem mitgelieferten Helfer utils/generate-keys.sh; verwende nicht die Beispielwerte erneut, die auf GitHub öffentlich sind.
• DASHBOARD_USERNAME und DASHBOARD_PASSWORD — der Basic-Auth-Login bei Studio. Das Passwort muss mindestens einen Buchstaben enthalten.

Warum das nicht verhandelbar ist: Der anon-Key, den du in den Client-Code einbettest, ist nur deshalb sicher, weil Row-Level Security dahintersteht. RLS ist opt-in, nicht Standard. 2025 legte CVE-2025-48757 über 170 mit Lovable generierte Apps offen, und zwar genau deshalb, weil RLS nie eingeschaltet wurde, und Supabases eigener Sicherheitsrückblick 2025 betont, dass RLS, so mächtig es ist, für Entwickler, die mit dem Muster neu sind, komplex ist und dass die Sicherheit auf Anwendungsebene in der Verantwortung des Kunden bleibt. Selbst-Hosting übergibt dir diese Verantwortung direkt: Geh mit Standard-Keys oder ohne RLS live, und du veröffentlichst deine Datenbank im Internet. Schalte RLS für jede Tabelle ein, die echte Daten enthält.

Schritt 3: booten und einloggen

Aus dem Projektverzeichnis:

sh run.sh start

Das umhüllt docker compose up -d --wait, was jeden Container hochfährt, bis er als gesund gemeldet wird. Sobald sie grün sind, ist das Dashboard über das Kong-API-Gateway auf Port 8000 erreichbar:

http://<your-server-ip>:8000

Logge dich mit den Dashboard-Zugangsdaten ein, die du gesetzt hast. Du hast jetzt ein funktionierendes Supabase-Projekt — aber es spricht reines HTTP auf einem öffentlichen Port, was für zehn Minuten in Ordnung und für die Produktion inakzeptabel ist.

Schritt 4: HTTPS und eine abgeschottete Firewall

Zwei Dinge machen das sicher genug, um es freizugeben:

1. Reverse Proxy mit TLS. Setz Caddy oder Nginx vor Port 8000 und terminiere HTTPS dort. Caddy ist die Abkürzung — richte eine zweizeilige Caddyfile auf deine Domain und es stellt Let's-Encrypt-Zertifikate automatisch aus und erneuert sie.
2. Firewall den Rest. Schließe alles außer 80/443 (und deinem SSH-Port). Entscheidend: Exponiere Postgres (5432) nicht ins Netz. Die Doku warnt, dass das direkte Exponieren von Postgres "das Connection Pooling umgeht und deine Datenbank dem Netzwerk aussetzt" — halte es an localhost oder ein privates Netzwerk gebunden und erreiche es über den Pooler, wobei du jeglichen externen Zugriff auf vertrauenswürdige IPs beschränkst.

Wenn dein Grund, die Cloud zu verlassen, die Datenkontrolle war, entscheidest du auch hier deine Egress-Haltung — den Traffic bei einem Anbieter zu halten, ist eine der saubereren Methoden, überraschende Cloud-Egress-Gebühren zu vermeiden.

Schritt 5: der Teil, den die Leitfäden auslassen — Backups sind jetzt dein Job

Hier ist der Abschnitt, den die meisten "installiere Supabase in 15 Minuten"-Posts weglassen, und es ist der, auf den es am meisten ankommt. In dem Moment, in dem du selbst hostest, gibst du verwaltete Backups und Point-in-Time-Recovery auf. Niemand macht für dich einen Snapshot. Ein selbst gehostetes Supabase ohne Backup-Strategie ist keine Datenbank; es ist ein zukünftiger Vorfall.

Ein minimal tragfähiges Backup-Setup sieht so aus:

• Logische Dumps nach Zeitplan. Ein nächtlicher pg_dump (oder pg_dumpall auch für Rollen), der auf Off-Box-Speicher geschrieben wird — den Objektspeicher eines anderen Anbieters, nicht denselben VPS. Ein Dump, der auf der sterbenden Platte liegt, ist kein Backup.
• WAL-Archivierung für Point-in-Time-Recovery. Wenn der Verlust eines Tages an Daten inakzeptabel ist, konfiguriere kontinuierliche Write-Ahead-Log-Archivierung, damit du auf jeden beliebigen Moment zurückspielen kannst. Das ist der selbst gehostete Ersatz für den PITR-Regler der Cloud.
• Teste die Wiederherstellung. Ein ungetestetes Backup ist eine Vermutung. Stell mindestens einmal im Monat in einen Wegwerf-Container wieder her und bestätige, dass die Daten tatsächlich da sind. Die meisten Leute entdecken erst dann, dass ihre Backups kaputt sind, wenn sie sie brauchen.

Das sind die ehrlichen Kosten des Selbst-Hostings: nicht das Setup, das einfach ist, sondern der Day-2-Betrieb — Patchen, Monitoring und der Nachweis, dass deine Wiederherstellungen funktionieren. Nichts davon ist schwer. Alles davon liegt bei dir.

Solltest du überhaupt selbst hosten? Ein Kosten-Realitätscheck

Supabase selbst zu hosten ergibt Sinn, wenn mindestens eines davon zutrifft:

• Datenkontrolle oder Compliance zwingt dazu, dass alles auf Infrastruktur bleibt, die du besitzt.
• Vorhersehbare Kosten bei Skalierung sind wichtig — eine feste VPS-Rechnung schlägt nutzungsbasierte Preise, sobald du über den kostenlosen Tarif hinaus bist und wächst.
• Du betreibst bereits Server. Wenn Postgres und ein Reverse Proxy zu betreiben für dich ein Dienstag ist, ist der Mehraufwand marginal.

Es ist die falsche Entscheidung, wenn dein Team keinen Appetit auf Rufbereitschaft hat, wenn du wirklich Branching und verwaltete PITR brauchst oder wenn deine Zeit mehr wert ist als die 25–50 $/Monat, die ein verwalteter Plan kostet. Wenn du noch die Plattformen selbst abwägst, decken Neon vs Supabase und unser Ranking des besten verwalteten Postgres die gehostete Seite ab. Und wenn deine Motivation der breitere "besitze deine Werkzeuge"-Instinkt ist, steckt dieselbe Logik hinter dem Betrieb eines selbst gehosteten KI-Assistenten wie OpenClaw.

Wir hosten Postgres selbst, weil die Kontrolle uns die operative Steuer wert ist. Diese Rechnung ist nicht universell. Stell sie für dein eigenes Team auf, bevor du unsere kopierst.

FAQ

Wie viel RAM brauche ich, um Supabase selbst zu hosten? Plane 8 GB für die Produktion ein. Der Stack betreibt mehr als ein Dutzend Container und liegt im Leerlauf bei rund 3–4 GB, bevor irgendein Traffic kommt. 4 GB funktionieren für die Entwicklung, lassen aber wenig Spielraum.

Ist selbst gehostetes Supabase kostenlos? Die Software ist kostenlos und Open Source. Du zahlst für den VPS, den Speicher und die Backup-Infrastruktur, die du selbst einrichtest — typischerweise eine feste monatliche Serverrechnung statt nutzungsbasierter Preise.

Welche Funktionen fehlen bei selbst gehostetem Supabase? Verwaltete Backups und Point-in-Time-Recovery, Branching, mehrere Projekte in einem Studio, erweiterte Analytics, ETL und die Management-API. Die Kern-Datenbank, Auth, Storage und Realtime sind alle vorhanden.

Ist das Selbst-Hosting von Supabase sicher? Kann es sein, aber die Sicherheit liegt vollständig bei dir. Ändere alle Standard-Secrets, aktiviere Row-Level Security an jeder Tabelle, terminiere HTTPS an einem Reverse Proxy und exponiere Postgres niemals direkt. Die meisten öffentlichen Supabase-Pannen kommen von fehlendem RLS, nicht von der Engine.

Wie aktualisiere ich eine selbst gehostete Supabase-Instanz? Zieh die neuesten Images aus dem Supabase-Repo und erstelle die Container neu, nachdem du zuerst ein Backup gemacht hast. Selbst gehostete Releases können der Cloud hinterherhinken, also lies das Changelog, bevor du eine Produktionsmaschine upgradest.