Supabase (self-hosted, core)
Comunidade7 serviços
Supabase, the open-source Firebase alternative — Postgres, auth, instant APIs, realtime and storage in one self-hosted stack.
O que você ganha
- Todos os 7 serviços provisionados juntos: supabase-db, supabase-auth, supabase-rest, supabase-realtime, supabase-storage, supabase-meta, supabase-studio
- Um template da comunidade, ainda não verificado de ponta a ponta pela equipe do Railyard
- HTTPS automático e deploys sem downtime
Como fazer deploy de Supabase (self-hosted, core)
- 1
Conecte um servidor
Conecte um servidor DigitalOcean, Hetzner ou Vultr ao Railyard, ou qualquer máquina Linux via SSH.
- 2
Clique em "Fazer deploy de Supabase (self-hosted, core)"
O Railyard constrói o container e provisiona todos os 7 serviços.
- 3
Configure seu domínio
Aponte seu domínio para o app. O Railyard emite um certificado HTTPS e o mantém renovado automaticamente.
Por que fazer deploy no Railyard
O Railyard provisiona todos os 7 serviços dessa stack juntos — supabase-db, supabase-auth, supabase-rest, supabase-realtime, supabase-storage, supabase-meta, supabase-studio — conectados entre si pela rede privada, em um servidor que você já paga.
Fazer deploy de Supabase (self-hosted, core) é só uma peça de uma stack maior que você pode continuar construindo — adicione um banco de dados, um worker, um cache, ou outro app, tudo nos mesmos servidores que você já paga.
Ideal para
- A self-hosted Postgres + Auth + Storage + Realtime backend
- A Firebase-style backend for a team that wants to own the database
Bom saber
- 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