So hostest du Supabase selbst auf einem VPS

Du nutzt Supabase Cloud seit ein paar Monaten, und die Rechnung steigt und steigt.

Jedes zusätzliche Bisschen Datenbank-Egress bringt einen weiteren Posten auf die Rechnung. Alle 10.000 monatlich aktiven Nutzer bringen dich näher an Zusatzkosten.

Der Pro-Tarif, der mit 25 $ im Monat begann, liegt inzwischen eher bei 70 $.

Irgendwo zwischen der Preisseite und deiner tatsächlichen Rechnung hat sich das Ganze nicht mehr wie ein Schnäppchen angefühlt.

Selbst hosten ist die naheliegende Alternative, aber naheliegend heißt noch lange nicht einfach. Supabase ist keine einzelne Binärdatei, die du einfach auf einen Server legst. Es ist ein kompletter Backend-Stack – eine Postgres-Datenbank, ein Authentifizierungsdienst, eine REST API, Echtzeit-Abonnements, Speicher, Edge Functions und ein Dashboard –, alles miteinander verbunden und als kleine Flotte von Docker-Containern betrieben.

Diese Flotte auf deinem eigenen Server zu betreiben, kostet mit Stack 16 etwa 23 bis 35 $ im Monat (22,99 $/Monat für die ersten 3 Monate bei monatlicher Laufzeit, danach 34,99 $/Monat) für einen VPS mit genug RAM, um alles im Arbeitsspeicher zu halten. Das sind zwei Streaming-Abos im Monat für ein Backend, das dir keine Extrakosten berechnet, wenn der Traffic plötzlich ansteigt.

Was ist Supabase und warum hosten es so viele selbst?

Supabase ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine Postgres-Datenbank, Authentifizierung, eine REST API, Echtzeit-Abonnements, Speicher und Edge Functions in einem einzigen Deployment bündelt.

Es ist die Firebase-Alternative, die auf deiner eigenen Infrastruktur läuft, wenn du das möchtest. Das GitHub-Repository hat Stand Mai 2026 die Marke von 100.000 Sternen überschritten, und die Plattform betreibt Backends für Unternehmen wie Mozilla, PwC, Johnson & Johnson und 1Password.

Die Frage ist, ob du die operative Arbeit, die Supabase Cloud dir abnimmt, selbst übernehmen oder jemand anderen dafür bezahlen willst. Gemeint sind Backups, Logs, E-Mail-Versand und Updates.

Es gibt drei Gründe, warum Leute Supabase selbst hosten:

1. Sie wollen planbare Kosten, die nicht mit der Nutzung steigen.
2. Sie wollen ihre Daten auf einer Infrastruktur, die sie selbst kontrollieren.
3. Sie wollen raus aus der Vendor-Lock-in-Falle, die den Abschied von Firebase so schmerzhaft gemacht hat.

Supabase selbst ist erfrischend offen darüber, wer selbst hosten sollte und wer nicht. Die offizielle Self-Hosting-Dokumentation sagt es ganz klar: Self-hosted Supabase is community-supported. You won’t receive the same level of official support as Supabase Cloud customers.

Übersetzt heißt das: Wenn um 2 Uhr nachts etwas kaputtgeht, bist du auf dich allein gestellt.

Was Supabase dir von Haus aus bietet

Falls du dachtest, Supabase sei nur Postgres mit einer REST API, liegst du falsch. Der selbstgehostete Stack betreibt etwa 12 Container parallel.

Die Teile, mit denen du am häufigsten arbeitest, sind ziemlich überschaubar:

• Postgres. Die Datenbank, um die sich alles dreht. Supabase nutzt einen modernen PostgreSQL-Build mit Erweiterungen für Authentifizierung, Echtzeit und Volltextsuche.
• PostgREST. Erzeugt automatisch eine REST API aus deinem Postgres-Schema. Aus einer Tabelle wird ein Endpunkt, und du musst dafür keine einzige Zeile Backend-Code schreiben.
• Auth (früher GoTrue). Kümmert sich um Registrierungen, Logins, das Zurücksetzen von Passwörtern, OAuth und die Ausstellung von JWTs.
• Realtime. Überträgt Datenbankänderungen per WebSockets an verbundene Clients.
• Storage. S3-kompatibles Object Storage mit einer Zugriffskontrolle, die an deine Datenbank gekoppelt ist.
• Edge Functions. Serverless-Funktionen auf Basis von Deno, die nah bei deinen Nutzern laufen.
• Supabase Studio. Das Dashboard, in dem du Tabellen durchsuchst, SQL ausführst und Auth-Nutzer verwaltest.

Dazu bekommst du Kong als API-Gateway, imgproxy für die Bildverarbeitung, Supavisor für Connection Pooling und Logflare für Analytics. Alles zusammen ergibt einen kompletten Backend-Stack, keine simple App.

Was kostet es, Supabase selbst zu hosten?

Supabase auf einem VPS selbst zu hosten, kostet mit Stack 16 etwa 23 bis 35 $ im Monat, inklusive Server, Speicher und Bandbreite. Die Supabase-Software selbst ist kostenlos.

Schau dir kurz deine letzte Rechnung von Supabase Cloud an. Der Posten, der viele überrascht, ist nicht die Grundgebühr von 25 $. Es sind Datenbank-Egress und zusätzlicher Speicher, die der Pro-Tarif separat abrechnet (die Kostenaufschlüsselung 2026 von Supascale geht die einzelnen Posten durch).

Vergleich das mit Supabase Cloud:

Der Grundpreis von Pro wirkt vergleichbar, aber die reale Nutzung treibt ihn schnell nach oben.

Laut der Analyse von Supascale landen die meisten kleinen bis mittelgroßen Produktiv-Apps mit Pro bei 100–200 $/Monat, sobald Compute-Add-ons und nutzungsbasierte Zusatzkosten dazukommen. Allein die Compute-Stufen von Supabase reichen von 10 $/Monat bis zu 3.730 $/Monat für die 16XL-Instanz. Apps mit 100.000–200.000 monatlich aktiven Nutzern können deutlich darüber liegen, und bei 500.000 MAUs können die Rechnungen 1.000–2.000 $/Monat erreichen.

Der Free-Tarif ist kostenlos, bis du ihn für die Produktion nutzen willst.

Projekte pausieren automatisch nach sieben Tagen Inaktivität. Deine Staging-Umgebung fällt also jede Woche aus, und deine Nebenprojekte gehen jedes Mal kaputt, wenn du in den Urlaub fährst. Laut der Preisaufschlüsselung 2026 von UI Bakery ist das der häufigste Grund, warum Leute den Free-Tarif früher verlassen als gedacht.

Beim Selbsthosten sieht die Rechnung ganz anders aus. Deine Kosten hängen an deiner Infrastruktur, nicht an deiner Nutzung. 50.000 MAUs kosten genauso viel wie 500.000, begrenzt nur durch das, was dein VPS schafft. Keine Egress-Gebühren, keine Speicher-Zusatzkosten, keine Compute-Add-ons.

Selbst hosten ist mehr als nur die VPS-Rechnung

Die VPS-Rechnung ist nicht der einzige Kostenfaktor beim Selbsthosten. Du investierst auch auf andere Weise:

• Deine Zeit. Plane ein bis zwei Stunden pro Monat für die routinemäßige Wartung ein, etwa für Sicherheitsupdates, das Abrufen neuer Docker-Images, das Prüfen von Logs und das Überprüfen von Backups. Rechne mit mehr Zeit, wenn du Funktionen hinzufügst oder skalierst.
• E-Mail-Versand. Supabase Cloud übernimmt Auth-E-Mails (z. B. zum Zurücksetzen von Passwörtern, Magic Links, E-Mail-Verifizierung) als verwalteten Dienst. Selbstgehostet musst du dich selbst darum kümmern. Du brauchst einen SMTP-Anbieter wie SendGrid, Mailgun oder AWS SES. Rechne je nach Volumen mit 0–30 $/Monat.
• Object Storage für Dateien. Der Storage-Dienst nutzt standardmäßig das lokale Dateisystem. Das ist in Ordnung zum Testen, in der Produktion aber eine tickende Zeitbombe. Du brauchst S3-kompatibles Object Storage: AWS S3, Backblaze B2, Wasabi oder ein anderer S3-kompatibler Dienst funktionieren alle. Plane für eine kleine bis mittelgroße Produktiv-App 5–20 $/Monat ein.
• Backup-Infrastruktur. Beim Selbsthosten gibt es keine automatischen Backups, also musst du sie selbst einrichten. Richte einen Cron Job mit simple pg_dump ein und speichere die Ausgabe an einem zuverlässigen Ort. Überspring diesen Teil nicht. Dein zukünftiges Ich wird es dir danken.

Welche Serverspezifikationen braucht Supabase?

Supabase braucht viel Arbeitsspeicher. Bei 12 gleichzeitig laufenden Containern, die meisten davon datenbanknah, ist RAM wichtiger als CPU. Das praktische Minimum liegt bei 4 GB für eine Entwicklungsinstanz mit deaktivierten optionalen Diensten. Produktiv-Deployments brauchen 8 GB oder mehr.

Der Grund ist die Anzahl der Container, nicht ein einzelner Dienst. Postgres braucht Shared Buffers. PostgREST braucht einen Connection Pool. GoTrue braucht etwas Speicher für die Go-Runtime. Realtime hält WebSocket-Verbindungen offen. Edge Runtime startet V8-Isolates.

Einzeln ist jeder Dienst genügsam. Zusammen summiert sich das schnell.

Wenn du noch nie einen VPS eingerichtet hast, lies zuerst unseren Einsteiger-Leitfaden zu VPS, bevor du deinen Server dimensionierst.

Bei DreamHost ist Stack 16 (4 vCPU, 16 GB RAM, 250 GB NVMe-SSD, voller Root-Zugriff) der kleinste Tarif, der die von Supabase empfohlenen 4 Kerne und 8 GB für ein Deployment mit allen optionalen Diensten erfüllt. Stack 8 erfüllt mit 2 vCPU die Empfehlungen für Arbeitsspeicher und Festplatte und eignet sich für eine kleine App oder eine Staging-Umgebung.

Welche VPS-Größe braucht Supabase?

Du kannst auch optionale Dienste aus der Docker-Compose-Datei entfernen, um den Ressourcenbedarf zu verringern.

Du brauchst keine Echtzeit-Abonnements? Lass den Realtime-Container weg.

Du nutzt keine Edge Functions? Entferne die Edge Runtime.

Analytics ist nicht entscheidend? Streich Logflare.

Ein abgespeckter Stack passt deutlich besser auf einen VPS mit 4 GB.

NVMe-Speicher ist wichtiger, als du denkst. Postgres liest und schreibt ständig, und die SSD-Latenz wirkt sich direkt darauf aus, wie schnell Abfragen laufen. Ältere SATA-Laufwerke oder klassische Festplatten bremsen dich aus, lange bevor die Datenbank richtig gefordert wird.

Wie funktioniert die Einrichtung von selbstgehostetem Supabase?

Das komplette Deployment umfasst etwa fünf Schritte und dauert ein bis zwei Stunden, wenn du dich im Terminal wohlfühlst.

So gehst du vor:

1. Stell einen VPS bereit mit Ubuntu 22.04 oder neuer, 8 GB RAM und SSH-Zugriff.
2. Installiere Docker und Docker Compose auf dem Server.
3. Klone das Supabase-Repository und kopiere die Beispiel-Umgebungsdatei: git clone https://github.com/supabase/supabase && cp supabase/docker/.env.example supabase/docker/.env
4. Generiere und setze die Secrets. Führe das Skript generate-keys.sh von Supabase aus, um JWT_SECRET, ANON_KEY und SERVICE_ROLE_KEY zu erzeugen. Setze dann POSTGRES_PASSWORD und die Zugangsdaten für das Dashboard in der Datei .env.
5. Führe docker compose up -d im Verzeichnis docker aus, dann startet der komplette Stack.

Es hat funktioniert, wenn docker compose ps jeden Dienst im Status running oder healthy anzeigt und curl http://localhost:8000/rest/v1/ eine JSON-Antwort von PostgREST zurückgibt.

Falls ein Container im Status restarting oder exited ist, prüf zuerst dessen Logs. Meist ist Postgres der Übeltäter, und die Ursache ist in der Regel eine fehlende oder fehlerhafte Umgebungsvariable.

Die offizielle Dokumentation von Supabase zum Self-Hosting mit Docker erklärt jede Umgebungsvariable.

Kong, das API-Gateway, sitzt vor allem anderen und kümmert sich um das Routing. In der Produktion setzt du typischerweise einen Reverse Proxy (einen Server zwischen dem Internet und deiner Anwendung, der SSL und Routing übernimmt) wie Caddy oder Nginx vor Kong, um HTTPS zu terminieren und den Zugriff auf das Dashboard einzuschränken.

Speichere JWT_SECRET, ANON_KEY und SERVICE_ROLE_KEY an einem zuverlässigen Ort, sobald sie generiert sind. Sie zu verlieren, ist keine Katastrophe, weil du sie neu generieren kannst. Eine Rotation lässt aber alle aktiven Nutzersitzungen ablaufen und zwingt jede Client-App, neue Schlüssel zu beziehen.

Was du zum Selbsthosten von Supabase brauchst

• Ein VPS mit Ubuntu 22.04+, mindestens 8 GB RAM und Root-/SSH-Zugriff
• Ein Domainname, der auf die IP-Adresse deines Servers zeigt
• Docker und Docker Compose installiert
• Ein SMTP-Anbieter, konfiguriert für Auth-E-Mails (SendGrid, Mailgun, AWS SES)
• S3-kompatibles Object Storage für Datei-Uploads in der Produktion (optional, aber empfohlen)
• Grundkenntnisse im Terminal und etwa ein bis zwei Stunden Zeit

Wie sicherst du eine selbstgehostete Supabase-Instanz ab?

Die Sicherheit von selbstgehostetem Supabase ruht auf drei plattformspezifischen Säulen und der üblichen Grundhygiene für deinen VPS.

Das JWT-Secret

Jedes Autorisierungstoken, das Supabase ausstellt, wird mit JWT_SECRET signiert. Wenn das Secret nach außen gelangt, können Angreifer Tokens fälschen und sich als beliebige Nutzer ausgeben.

Die Dokumentation von Supabase zur Token-Sicherheit erklärt, wie das funktioniert: A shared secret that is in the hands of a malicious actor can be used to impersonate your users [and] give them access to privileged actions or data, and it is difficult to detect or identify when or how a shared secret has been given to a malicious actor.

Behandle JWT_SECRET wie das Passwort einer Produktionsdatenbank, denn genau das ist es funktional. Bewahre es in einem Secrets-Manager auf, nicht in einer .env-Datei in Git und niemals in deinem Frontend-Bundle.

Für die Produktion empfehlen wir asymmetrische Signaturschlüssel (RS256 oder ECC). Sie lassen sich schwerer versehentlich leaken als ein gemeinsames Secret, und Supabase unterstützt beide Varianten.

Row Level Security

Der PostgREST-Dienst von Supabase stellt jede Tabelle deiner Datenbank als REST-Endpunkt bereit.

Ohne Row-Level-Security-Richtlinien für jede Tabelle kann jeder authentifizierte Nutzer jede Zeile lesen und schreiben. Das ist der größte Fehler, den Neulinge beim Self-Hosting machen.

Aktiviere RLS vom ersten Tag an für jede Tabelle, auch für die, bei denen du glaubst, dass du es nicht brauchst.

Service Role Key

Der SERVICE_ROLE_KEY ist ein Super-Admin-Key, der Row Level Security komplett umgeht.

Er ist für Aufrufe zwischen Backends gedacht, bei denen du Berechtigungen auf Nutzerebene ausdrücklich umgehen musst. Der Key darf niemals in Frontend-Code, öffentlichen Repositorys oder Client-App-Bundles auftauchen. Wenn er geleakt wird, liegt deine gesamte Datenbank offen.

Über die Supabase-spezifischen Punkte hinaus gilt die übliche Server-Härtung. Aktiviere eine Firewall, die nur die Ports 22 (SSH), 80 (HTTP) und 443 (HTTPS) freigibt. Betreibe alles hinter einem Reverse Proxy mit HTTPS. Beschränke den Zugriff auf Supabase Studio auf bekannte IPs und halte den Server mit Patches aktuell. Unsere Tipps zur Cloud-Sicherheit enthalten die allgemeine Checkliste zur Härtung – ein Blick lohnt sich also.

Noch eine letzte Sache: Wenn du das JWT-Secret rotierst, werden alle aktiven Nutzersitzungen sofort ungültig. Plane ein Wartungsfenster ein und rotiere nicht an einem Freitagnachmittag – sonst wird es ungemütlich.

Selbstgehostet oder Supabase Cloud: Was sind die Vor- und Nachteile?

Selbstgehostetes Supabase und Supabase Cloud sind nicht austauschbar. Jede Variante punktet in anderen Bereichen.

Self-Hosting lohnt sich, wenn dir planbare Kosten wichtiger sind als der Komfort einer verwalteten Lösung, wenn deine Daten physisch auf Infrastruktur liegen müssen, die du kontrollierst, oder wenn du mehrere Projekte betreibst, die in der Cloud jeweils 25 $ oder mehr pro Monat kosten würden.

Die Cloud gewinnt, wenn deine Kapazitäten für den Betrieb knapp sind und automatisierte Backups sowie eine durch SLA abgesicherte Verfügbarkeit unverzichtbar sind. Sie ist auch eine gute Wahl, wenn dein Team klein ist und die Rechnung zu den Gesamtbetriebskosten tatsächlich für verwaltetes Hosting spricht.

Es gibt auch einen Mittelweg.

Tools wie Coolify, Dokploy und Railway können Supabase auf deinem VPS bereitstellen und verwalten. Sie kümmern sich um Updates, Backups und einen Teil des Monitorings, ohne dass du alles manuell mit Docker Compose erledigen musst.

Kurz gesagt: Du bekommst den Großteil der Kostenvorteile des Self-Hostings mit weniger Betriebsaufwand. Keines dieser Tools erreicht den Feinschliff des Cloud-Dashboards, aber alle sind bei wachsender Nutzung günstiger als die Cloud.

Solltest du Supabase wirklich selbst hosten?

Ob du Supabase selbst hostest, ist weniger eine Kosten- als eine Betriebsfrage.

Das VPS ist günstig. Worauf du dich eigentlich einlässt, ist die Verantwortung für Backups, Logs und die gesamte Technik hinter den Auth-E-Mails. Für die meisten kleinen Teams lohnt sich dieser Tausch erst, wenn die Preise der Cloud wehtun oder wenn der Datenstandort nicht mehr nur wünschenswert, sondern Pflicht ist.

Wenn du noch nicht bereit für die komplett manuelle Einrichtung bist, bieten Tools wie Coolify und Dokploy einen Mittelweg. Sie verwalten den Stack auf deinem VPS mit weniger Aufwand als reines Docker Compose und sind bei wachsender Nutzung günstiger als die Cloud.

Der erste Monat Self-Hosting ist der anstrengendste. Du justierst Ressourcenlimits, von denen du nicht wusstest, dass es sie gibt, entdeckst Fehlerquellen, die niemand dokumentiert hat, und schreibst das Runbook, das du selbst gern bekommen hättest.

Ab Monat zwei bis Monat 12 wird es ruhig. Du ziehst Updates mit Docker Compose, lässt jede Nacht einen pg_dump nach S3 laufen, und deine Rechnung bleibt konstant.

Am besten findest du so heraus, auf welcher Seite du stehst: Starte ein Stack 4 (8,99 $/Monat für die ersten 3 Monate bei monatlicher Laufzeit), betreibe eine Supabase-Instanz außerhalb der Produktion eine Woche lang und lass die Erfahrung für dich entscheiden.

Den Rest verraten dir die Zahlen.

Häufig gestellte Fragen zum Selbsthosten von Supabase