Supabase na VPS: como instalar com Docker

Aprenda a instalar o Supabase no seu servidor com Docker Compose, gerar as chaves, trocar as senhas padrão, acessar o Studio, ligar o HTTPS com proxy e manter tudo atualizado.

Por Redação Eleven Host · @robson.direitodigital · 1 de novembro de 2026 · 9 min de leitura

O Supabase na VPS é a instalação própria do Supabase, com Postgres, autenticação, API e o painel Studio, no seu servidor. Você sobe tudo com Docker Compose a partir do repositório oficial e acessa o Studio pelo navegador.

O que é o Supabase self-hosted e o que muda em relação à nuvem

Rodar o Supabase por conta própria é o que a documentação chama de self-hosting. Segundo ela, esse caminho serve para quem quer controle total sobre os dados, e também para quem tem exigência de conformidade que impede um serviço gerenciado, ou precisa de um ambiente isolado.

Em troca do controle, a responsabilidade passa a ser sua. Pela documentação, quem hospeda cuida de provisionar e manter o servidor, de manter o sistema e os serviços atualizados, de configurar os serviços, de manter o Postgres, de alta disponibilidade e escala, de backups e recuperação de desastres e do monitoramento. O suporte também muda: o self-hosted é apoiado pela comunidade, por meio de GitHub Discussions e Issues, Discord e Reddit.

A documentação também lista o que não acompanha a instalação própria. O Studio não oferece várias organizações nem vários projetos, e alguns recursos da plataforma gerenciada não estão disponíveis, como branching, métricas avançadas além dos logs, backups gerenciados com recuperação em um ponto no tempo (PITR), analytics, vector buckets, ETL e Management API. Na prática, isso significa que o self-hosted não é uma cópia completa da nuvem da Supabase.

Requisitos para instalar

Antes de contratar o servidor, leia a tabela de requisitos que a documentação do Supabase traz para a instalação com Docker. Os números são do Supabase, e por isso vale escolher uma VPS que atenda ao mínimo. Se ainda está conhecendo o assunto, o guia de iniciantes sobre servidor VPS explica o que é cada parte.

• RAM: mínimo de 4 GB, recomendado 8 GB ou mais.
• CPU: mínimo de 2 núcleos, recomendado 4 ou mais.
• Disco: mínimo de 40 GB em SSD, recomendado 80 GB ou mais em SSD.

Também são necessários o Git e o Docker, com o Docker Engine e o Docker Compose no servidor. Para saber o que cada plano da Eleven Host inclui, confira a página de VPS na loja.

Passo a passo: baixar os arquivos

Na versão self-hosted/v0.8.3, segundo a documentação, o caminho manual é este. Ele clona o repositório, copia a pasta docker para um projeto seu e prepara o arquivo de variáveis:

git clone --depth 1 --branch self-hosted/v0.8.3 https://github.com/supabase/supabase

mkdir supabase-project

cp -rf supabase/docker/. supabase-project

cd supabase-project && cp .env.example .env

printf 'ref=self-hosted/v0.8.3\n' > .supabase-version

docker compose pull

Para uma versão mais nova, a documentação manda usar a tag mais recente, que aparece na lista de tags do repositório do Supabase no GitHub. O último comando baixa as imagens dos contêineres.

A documentação também descreve um início rápido para Linux que baixa um script e o executa direto no shell. Por isso, recomendamos o caminho manual acima, em que você vê cada comando antes de rodar.

Gerar as chaves e trocar os valores padrão

O .env.example vem com valores de exemplo, como your-super-secret-and-long-postgres-password para a senha do Postgres e supabase como usuário do painel. O próprio arquivo avisa em letras maiúsculas que os valores padrão precisam ser trocados antes de subir os contêineres pela primeira vez, e a documentação diz que o Supabase não deve ser iniciado com esses padrões.

Para gerar os segredos e as chaves, a documentação usa dois scripts. Rode-os dentro da pasta do projeto:

sh utils/generate-keys.sh

sh utils/add-new-auth-keys.sh

Depois, abra o .env e confira estes pontos:

• POSTGRES_PASSWORD: defina uma senha longa. A documentação aconselha usar apenas letras e números nela.
• DASHBOARD_USERNAME e DASHBOARD_PASSWORD: o exemplo traz o usuário supabase e uma senha que o próprio arquivo chama de insegura. Troque os dois.
• SUPABASE_PUBLISHABLE_KEY e SUPABASE_SECRET_KEY: a chave secreta não deve aparecer em código de cliente. As variáveis ANON_KEY, SERVICE_ROLE_KEY e JWT_SECRET aparecem no arquivo como chaves legadas.
• SECRET_KEY_BASE, REALTIME_DB_ENC_KEY, VAULT_ENC_KEY e PG_META_CRYPTO_KEY: outros segredos que a documentação manda revisar.
• SUPABASE_PUBLIC_URL, API_EXTERNAL_URL e SITE_URL: no exemplo apontam para localhost. Ajuste para o seu endereço.
• SMTP_HOST, SMTP_USER e SMTP_PASS: preencha se o seu projeto enviar e-mails.

Um cuidado de edição: a documentação avisa que os arquivos podem ter sido baixados com quebras de linha CRLF em vez de LF, o que atrapalha os scripts. Guarde os segredos num gerenciador de segredos em produção e não os envie para o controle de versão.

Subir os serviços e conferir

Com o .env revisado, suba tudo. A documentação diz que o run.sh start equivale a docker compose up -d --wait. Depois, confira os contêineres e os logs:

sh run.sh start

docker compose ps

sh tests/test-container-logs.sh

O docker compose ps lista os serviços e o estado de cada um. O tests/test-container-logs.sh faz parte da conferência que a documentação indica depois de subir os serviços. Para parar os serviços, use sh run.sh stop.

Um detalhe: Logs e Analytics não fazem parte da configuração padrão, para reduzir o uso de memória. Se quiser ligá-los, a documentação indica sh run.sh config add logs.

Está escolhendo uma VPS? VPS a partir de R$ 17,00/mês no Plano Bronze; confira na loja o que cada plano inclui. Ver os planos de VPS

Gateway da API na porta 8000 e primeiro acesso ao Studio

O gateway da API usa a porta 8000 (variável API_GW_HTTP_PORT). Na versão da documentação, o padrão é o Envoy, e o Kong virou uma alternativa opcional. Por isso, um guia antigo que fale em Kong na porta 8000 está desatualizado.

O Studio abre em http://seu-dominio:8000, com autenticação HTTP básica: o usuário e a senha são os DASHBOARD_USERNAME e DASHBOARD_PASSWORD que você definiu. A documentação reforça que uma senha segura precisa estar definida antes de iniciar o Supabase. As APIs ficam no mesmo gateway, nos caminhos /rest/v1/, /auth/v1/, /storage/v1/ e /realtime/v1/.

O banco tem portas próprias: 5432 para o Postgres pelo pooler em modo sessão e 6543 para o modo transação. Como o Studio e a API compartilham a porta 8000, e o banco tem as suas, recomendamos conferir o que está exposto com o guia Portas abertas no Linux: como ver com ss e lsof na VPS e abrir só o que você de fato usa.

HTTPS com um proxy reverso

Segundo a documentação, em produção, principalmente com provedores OAuth, é preciso HTTPS com certificado TLS válido, e a abordagem indicada é colocar um proxy reverso, como Caddy ou Nginx, na frente do gateway da API. Para isso, você vai precisar de um domínio apontado para a sua VPS.

O guia Nginx Proxy Manager: vários sites numa VPS só mostra o proxy com painel, e o Caddy na VPS: servidor web com HTTPS automático mostra a opção que emite e renova o certificado sozinha. Em ambos, o destino é a porta 8000 do Supabase.

Com o HTTPS no ar, atualize o SUPABASE_PUBLIC_URL, o API_EXTERNAL_URL e o SITE_URL no .env para o endereço novo.

Atualizar o Supabase

A documentação informa que o Supabase publica snapshots estáveis da configuração do Docker Compose aproximadamente uma vez por mês. O script update.sh atualiza uma instalação existente no próprio lugar: ele busca a configuração self-hosted/v* mais recente e a mescla com os seus arquivos, por meio de uma mesclagem de três vias. A documentação não traz um bloco de comando para ele, então siga as instruções do próprio script no repositório.

Para atualizar um serviço só, a documentação mostra estes comandos, aqui com o Studio:

sh run.sh pull

sh run.sh recreate studio

Atenção: ao misturar versões de imagens, a documentação avisa que a compatibilidade não é assegurada. Sobre backup, a documentação não traz um procedimento. Ela só informa que o backup é de quem hospeda e que o PITR gerenciado não existe no self-hosted. Por isso, planeje a sua cópia do banco antes de atualizar.

Cuidados de segurança que a documentação aponta

Pontos que valem uma segunda leitura:

• Trocar os padrões do .env antes do primeiro start.
• Não guardar segredos no controle de versão e usar um gerenciador de segredos em produção.
• Manter o HTTPS com certificado válido na frente da API.
• Manter o sistema e os serviços atualizados, como parte da responsabilidade de quem hospeda.

Para apagar tudo, existe o sh reset.sh. A documentação alerta que ele destrói todos os dados, incluindo o banco e os volumes de armazenamento. Rode-o só quando tiver certeza.

Vale instalar o Supabase por conta própria?

Vale quando você quer controle dos dados e aceita cuidar do servidor, das atualizações e dos backups. Se prefere que outra empresa assuma essa parte, existe a plataforma gerenciada da Supabase, que tem os recursos que o self-hosted não traz.

Quer conhecer a VPS da Eleven Host? VPS a partir de R$ 17,00/mês no Plano Bronze; confira na loja o que cada plano inclui. Conhecer a VPS

Perguntas frequentes

Quanta memória o Supabase precisa?

A documentação indica o mínimo de 4 GB de RAM e recomenda 8 GB ou mais, além de 2 núcleos de CPU como mínimo e 40 GB de disco em SSD.

O Supabase self-hosted é igual ao da nuvem?

Não. Ele roda como um único projeto, e alguns recursos da plataforma gerenciada não estão disponíveis, como branching, backups gerenciados com PITR e Management API.

O gateway ainda é o Kong?

Na documentação do Supabase, o padrão é o Envoy, e o Kong virou uma alternativa opcional. A API continua na porta 8000.

Preciso trocar o usuário e a senha do painel?

Sim. O exemplo traz o usuário supabase e uma senha que o arquivo chama de insegura. A documentação manda definir uma senha segura antes de iniciar.