Supabase self-hosten op een VPS in 2026 (Een productiegids)

Om Supabase te self-hosten op een VPS clone je de officiële Docker-stack, wijzig je elke standaard secret, start je de containers, en zet je het geheel achter een reverse proxy met HTTPS. Het opstartgedeelte duurt ongeveer 15 minuten. Het deel dat de lijstjes overslaan — back-ups, security hardening, en de functies die je stilletjes verliest ten opzichte van de cloud — is het deel dat eigenlijk bepaalt of je dit überhaupt zou moeten doen. Deze gids loopt het volledige pad af en is eerlijk over de afwegingen.

Supabase is open source, dus dezelfde Postgres, Auth, Storage, Realtime en Studio die je krijgt op supabase.com kunnen draaien op een VPS van $20 die jij beheert. Wij draaien onze eigen Postgres bij TechRiseUps, dus de voorkeur hier neigt naar het bezitten van je eigen stack — maar self-hosten is een echte afweging, geen gratis lunch, en de rest van dit stuk behandelt het zo.

Wat je krijgt, en wat je opgeeft

De self-hosted stack spiegelt één enkel cloudproject, maar verschillende platform-only functies bestaan simpelweg niet in de box.

	Self-hosted Supabase	Supabase Cloud
Core (Postgres, Auth, Storage, Realtime, Studio)	Ja	Ja
Beheerde back-ups + point-in-time recovery	Je bouwt het zelf	Ingebouwd
Meerdere projecten / organisaties in Studio	Nee (één project)	Ja
Branching, geavanceerde metrics, ETL, vector buckets	Nee	Ja
Updates	Handmatig, soms achterlopend op laatste versie	Automatisch
Support	Alleen community	Betaalde plannen
Dataresidentie / volledige controle	Volledig	Vendor-gecontroleerd

Volgens de self-hosting-docs van Supabase zijn platformfuncties zoals branching, beheerde back-ups, PITR, analytics buckets en de management API niet beschikbaar wanneer je self-host. Je krijgt alles wat nodig is om een app te draaien — je krijgt niet het beheerde vangnet. Als dat vangnet de reden was waarom je Supabase überhaupt gebruikte, lees dan de kostensectie aan het eind voordat je je vastlegt.

Stap 0: bemeet de VPS correct

De meest voorkomende self-hosting-fout is onder-provisioning. De Supabase-stack draait ruwweg 12–15 containers en zit op 3–4 GB RAM in rust, voordat ook maar één gebruiker verbinding maakt.

• 4 GB RAM is de absolute ondergrens — prima voor ontwikkeling of een hobbyproject dat onder belasting zal omvallen.
• 8 GB RAM is het realistische startpunt voor alles wat je productie zou noemen.
• 2 vCPU minimaal; 4 als Realtime of Edge Functions verkeer zien.
• Snelle NVMe-opslag — Postgres is I/O-gevoelig, en dat geldt ook voor het herstellen van een back-up om 2 uur 's nachts.

Als je een kleine machine wilt aanhouden, kun je diensten die je niet gebruikt (Realtime, Storage, imgproxy, Edge Runtime) uit het compose-bestand verwijderen en zo een gigabyte of twee terugwinnen. Voor het kiezen van de onderliggende machine vergelijkt onze ranking van de beste VPS-hosting in 2026 de echte prijs-prestatieverhouding — en let op het specificatieblad, want VPS-RAM-prijzen klimmen al het hele jaar.

Stap 1: installeer Docker en haal de stack op

Installeer op een verse Ubuntu-VPS Docker Engine en de Compose-plugin, en haal vervolgens de officiële stack op met een shallow clone (je hebt de hele repo-geschiedenis niet nodig):

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

Dit geeft je een .env-bestand dat de volledige deployment bestuurt en de Compose-definitie voor Postgres, GoTrue (Auth), PostgREST, Realtime, Storage, de Kong API-gateway en Studio.

Stap 2: wijzig de secrets die ertoe doen (sla dit niet over)

Dit is de stap die van een self-host een datalek maakt. De officiële Docker-gids is bot: "never start your self-hosted Supabase using these defaults." Voordat je iets opstart, bewerk .env en regenereer:

• POSTGRES_PASSWORD — het wachtwoord van je database-superuser. Gebruik alleen letters en cijfers om URL-encoding-bugs te ontwijken.
• JWT_SECRET plus een verse ANON_KEY en SERVICE_ROLE_KEY — deze ondertekenen en autoriseren elke API-token. Genereer ze met de meegeleverde utils/generate-keys.sh-helper; hergebruik de voorbeeldwaarden niet, die zijn publiek op GitHub.
• DASHBOARD_USERNAME en DASHBOARD_PASSWORD — de basic-auth-login op Studio. Het wachtwoord moet ten minste één letter bevatten.

Waarom dit niet onderhandelbaar is: de anon-key die je in client-code insluit is alleen veilig omdat Row-Level Security erachter staat. RLS is opt-in, niet standaard. In 2025 legde CVE-2025-48757 170+ door Lovable gegenereerde apps bloot juist omdat RLS nooit was ingeschakeld, en Supabase's eigen security-retrospectief van 2025 benadrukt dat RLS, hoewel krachtig, complex is voor ontwikkelaars die nieuw zijn met het patroon, en dat security op applicatieniveau de verantwoordelijkheid van de klant blijft. Self-hosten legt die verantwoordelijkheid direct bij jou: lever met standaardkeys of zonder RLS en je publiceert je database naar het internet. Schakel RLS in voor elke tabel die echte data bevat.

Stap 3: start het op en log in

Vanuit de projectmap:

sh run.sh start

Dat wikkelt docker compose up -d --wait, wat elke container opbrengt totdat hij healthy meldt. Zodra ze groen zijn, is het dashboard bereikbaar via de Kong API-gateway op poort 8000:

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

Log in met de dashboard-credentials die je hebt ingesteld. Je hebt nu een werkend Supabase-project — maar het spreekt platte HTTP op een publieke poort, wat prima is voor tien minuten en onacceptabel voor productie.

Stap 4: HTTPS en een dichtgetimmerde firewall

Twee dingen maken dit veilig om bloot te stellen:

1. Reverse proxy met TLS. Zet Caddy of Nginx voor poort 8000 en termineer HTTPS daar. Caddy is de snelle weg — wijs een Caddyfile van twee regels naar je domein en het voorziet en vernieuwt Let's Encrypt-certificaten automatisch.
2. Firewall de rest. Sluit alles behalve 80/443 (en je SSH-poort). Cruciaal: stel Postgres (5432) niet bloot aan de wereld. De docs waarschuwen dat het direct blootstellen van Postgres "bypasses connection pooling and exposes your database to the network" — houd het gebonden aan localhost of een privénetwerk en bereik het via de pooler, en beperk elke externe toegang tot uitsluitend vertrouwde IP's.

Als je reden om de cloud te verlaten datacontrole was, is dit ook waar je je egress-houding bepaalt — verkeer op één provider houden is een van de schonere manieren om verrassende cloud egress-kosten te vermijden.

Stap 5: het deel dat de gidsen overslaan — back-ups zijn nu jouw taak

Hier is de sectie die de meeste "installeer Supabase in 15 minuten"-posts weglaten, en het is degene die het meest telt. Op het moment dat je self-host, geef je beheerde back-ups en point-in-time recovery op. Niemand maakt een snapshot voor je. Een self-hosted Supabase zonder back-upstrategie is geen database; het is een toekomstig incident.

Een minimaal levensvatbare back-upopstelling ziet er zo uit:

• Logische dumps op een schema. Een nachtelijke pg_dump (of pg_dumpall voor de rollen erbij) weggeschreven naar off-box-opslag — de object store van een andere provider, niet dezelfde VPS. Een dump die op de stervende schijf staat is geen back-up.
• WAL-archivering voor point-in-time recovery. Als het verliezen van een dag aan data onacceptabel is, configureer dan continue write-ahead-log-archivering zodat je naar elk moment kunt terugspelen. Dit is het self-hosted alternatief voor de PITR-schuif van de cloud.
• Test het herstel. Een ongeteste back-up is een gok. Herstel minstens één keer per maand in een wegwerpcontainer en bevestig dat de data er daadwerkelijk is. De meeste mensen ontdekken dat hun back-ups kapot zijn pas wanneer ze ze nodig hebben.

Dit is de eerlijke kostenpost van self-hosten: niet de setup, die is makkelijk, maar de day-2 operations — patchen, monitoren en bewijzen dat je restores werken. Niets ervan is moeilijk. Het ligt allemaal bij jou.

Zou je überhaupt moeten self-hosten? Een kostenrealiteitscheck

Supabase self-hosten heeft zin wanneer minstens één van deze waar is:

• Datacontrole of compliance dwingt gesprekken om te blijven op infrastructuur die jij bezit.
• Voorspelbare kosten op schaal doen ertoe — een vaste VPS-rekening verslaat usage-prijzen zodra je voorbij de gratis tier bent en groeit.
• Je beheert al servers. Als het draaien van Postgres en een reverse proxy een doordeweekse klus voor je is, is de overhead marginaal.

Het is de verkeerde keuze wanneer je team geen on-call-bereidheid heeft, wanneer je oprecht branching en beheerde PITR nodig hebt, of wanneer je tijd meer waard is dan de $25–50/maand die een beheerd plan kost. Als je de platforms zelf nog afweegt, behandelen Neon vs Supabase en onze ranking van de beste beheerde Postgres de gehoste kant. En als je motivatie het bredere "bezit je eigen tools"-instinct is, is het dezelfde logica achter het draaien van een self-hosted AI-assistent zoals OpenClaw.

Wij self-hosten Postgres omdat controle de operationele belasting voor ons waard is. Die rekensom is niet universeel. Maak hem voor je eigen team voordat je de onze kopieert.

FAQ

Hoeveel RAM heb ik nodig om Supabase te self-hosten? Reken op 8 GB voor productie. De stack draait ruim een dozijn containers en draait stationair rond 3–4 GB voordat er verkeer is. 4 GB werkt voor ontwikkeling maar laat weinig speling.

Is self-hosted Supabase gratis? De software is gratis en open source. Je betaalt voor de VPS, opslag en de back-upinfrastructuur die je zelf opzet — doorgaans een vaste maandelijkse serverrekening in plaats van usage-gebaseerde prijzen.

Welke functies ontbreken in self-hosted Supabase? Beheerde back-ups en point-in-time recovery, branching, meerdere projecten in één Studio, geavanceerde analytics, ETL, en de management API. De kerndatabase, auth, storage en realtime zijn allemaal aanwezig.

Is Supabase self-hosten veilig? Dat kan, maar de security ligt volledig bij jou. Wijzig alle standaard secrets, schakel Row-Level Security in op elke tabel, termineer HTTPS bij een reverse proxy, en stel Postgres nooit direct bloot. De meeste publieke Supabase-datalekken komen door ontbrekende RLS, niet door de engine.

Hoe update ik een self-hosted Supabase-instantie? Haal de nieuwste images uit de Supabase-repo en hercreëer de containers, nadat je eerst een back-up hebt gemaakt. Self-hosted releases kunnen achter de cloud aanlopen, dus lees de changelog voordat je een productiemachine upgradet.