Supabase (self-hosted, core)
Community7 Services
Supabase, the open-source Firebase alternative — Postgres, auth, instant APIs, realtime and storage in one self-hosted stack.
Was du bekommst
- Alle 7 Services gemeinsam bereitgestellt: supabase-db, supabase-auth, supabase-rest, supabase-realtime, supabase-storage, supabase-meta, supabase-studio
- Ein Community-Template, noch nicht end-to-end vom Railyard-Team verifiziert
- Automatisches HTTPS und Zero-Downtime-Deploys
So deployst du Supabase (self-hosted, core)
- 1
Einen Server verbinden
Verbinde einen DigitalOcean-, Hetzner- oder Vultr-Server mit Railyard, oder jede Linux-Box per SSH.
- 2
Auf "Supabase (self-hosted, core) deployen" klicken
Railyard baut den Container und stellt alle 7 Services bereit.
- 3
Deine Domain einrichten
Richte deine Domain auf die App. Railyard stellt ein HTTPS-Zertifikat aus und erneuert es automatisch.
Warum auf Railyard deployen
Railyard stellt alle 7 Services dieses Stacks gemeinsam bereit — supabase-db, supabase-auth, supabase-rest, supabase-realtime, supabase-storage, supabase-meta, supabase-studio — verdrahtet, damit sie sich übers private Netzwerk erreichen, auf einem Server, den du schon bezahlst.
Supabase (self-hosted, core) zu deployen ist nur ein Teil eines größeren Stacks, den du weiter ausbauen kannst — füge eine Datenbank, einen Worker, einen Cache oder eine weitere App hinzu, alles auf denselben Servern, die du schon bezahlst.
Gut für
- A self-hosted Postgres + Auth + Storage + Realtime backend
- A Firebase-style backend for a team that wants to own the database
Gut zu wissen
- Every service gets its own Railyard URL instead of sitting behind one API gateway — Supabase's own compose routes everything through Kong/Envoy, which is skipped here the way nginx is skipped elsewhere in this catalog
- This runs as a single project, same as upstream self-hosted Supabase — Studio doesn't support multiple organizations or projects the way Supabase Cloud does
- Known gap: supabase-realtime still won't boot cleanly — its migrator writes an unqualified public.schema_migrations, which collides with the bookkeeping table the supabase/postgres image's own bootstrap already creates there. Upstream avoids this by mounting an extra init script that pre-creates a dedicated _realtime schema before Realtime ever starts; this template has no equivalent bootstrap step yet, so redirecting Realtime's search_path there fails too (the schema doesn't exist). Needs a Railyard-side way to run one-time setup SQL against supabase-db before dependent services boot