VPS para Supabase self-hosted: guia de produção

Resposta direta

Para rodar Supabase self-hosted em produção, a VPS precisa ser escolhida como infraestrutura de banco de dados, API e storage, não como uma hospedagem genérica. Um ponto de partida seguro para um projeto pequeno é 2 vCPUs, 4 GB de RAM, 80 GB de SSD ou NVMe, Docker atualizado, firewall restritivo e backups externos testados. Para um SaaS em uso real, 4 vCPUs, 8 GB de RAM e disco com boa taxa de IOPS reduzem gargalos no PostgreSQL, no Realtime e no Storage API. A escolha também depende da latência para usuários brasileiros, da política de snapshots, da facilidade de upgrade e da maturidade operacional do provedor. Em qualquer cenário, preço, região, bandwidth e recursos inclusos precisam ser confirmados no site oficial antes da contratação.

Resumo rápido

Supabase self-hosted pode funcionar muito bem em uma VPS, mas exige cuidado maior do que uma aplicação web comum. O stack combina PostgreSQL, autenticação, APIs, storage, Realtime, gateway e serviços auxiliares em containers. Isso concentra muitas responsabilidades no mesmo servidor, então CPU, RAM, disco, rede e rotina de backup precisam ser pensados juntos.

• Para laboratório e MVP interno, 2 vCPUs e 4 GB de RAM costumam ser um começo realista, desde que o tráfego seja baixo e o banco não esteja pesado.
• Para produção pequena, 4 vCPUs, 8 GB de RAM e 100 GB de SSD ou NVMe oferecem margem melhor para PostgreSQL, API, Auth e Storage.
• O PostgreSQL é o componente mais sensível. Disco lento, pouco cache e ausência de backups testados viram problema antes da CPU.
• Docker simplifica a instalação, mas não elimina a necessidade de hardening, monitoramento, atualização de imagens e controle de segredos.
• Storage de arquivos precisa de plano claro. Você pode usar volume local para começar, mas objetos importantes pedem backup externo ou serviço compatível com S3.
• Para público no Brasil, datacenter local pode reduzir latência, principalmente em autenticação, uploads e chamadas frequentes de API.
• LetsCloud, DigitalOcean, Vultr, AWS Lightsail, Hetzner e Contabo podem entrar na análise, mas região, tipo de disco, backup e preço devem ser verificados nas páginas oficiais. Dados voláteis foram considerados como pendentes de revisão humana em 2026-07-04.

O que muda ao rodar Supabase self-hosted em uma VPS

Rodar Supabase self-hosted não é o mesmo que subir um PostgreSQL com um painel bonito. A distribuição oficial reúne vários serviços que conversam entre si: PostgreSQL, PostgREST, GoTrue para autenticação, Realtime, Storage API, Kong como gateway, Studio para administração, funções e componentes de logging. Em uma VPS pequena, todos esses processos disputam CPU, memória, disco e conexões de rede. Por isso, a pergunta correta não é apenas se a VPS roda Docker, mas se ela sustenta o conjunto com folga em horários de pico.

Supabase não é apenas PostgreSQL

O PostgreSQL continua sendo o coração do ambiente. Tabelas, índices, Row Level Security, extensões e conexões simultâneas passam por ele. Só que a experiência do Supabase depende de mais camadas. Uma tela de login chama o Auth, uma listagem do app pode usar PostgREST, um upload passa pelo Storage API e uma atualização em tempo real depende do Realtime. Se o banco estiver com I/O alto, o usuário sente atraso em várias partes do produto, mesmo que o container da API esteja saudável.

Um exemplo simples ajuda. Um SaaS com 2.000 usuários cadastrados, 100 usuários ativos por dia, autenticação por e-mail e upload de imagens pequenas pode operar em uma VPS de 4 vCPUs e 8 GB de RAM. Se o mesmo produto adicionar eventos em tempo real, relatórios pesados e uploads de 20 MB, o gargalo muda. O disco cresce rápido, o PostgreSQL precisa de mais cache e o backup demora mais.

VPS tradicional, Cloud Server e cloud instance

Uma VPS tradicional costuma ficar em um host físico com recursos virtualizados e plano fixo. Um Cloud Server ou cloud instance geralmente facilita upgrades, snapshots e automação via painel ou API, embora o comportamento varie por provedor. Para Supabase, essa flexibilidade pesa. Se o banco crescer de 30 GB para 120 GB, ou se uma campanha dobrar o tráfego, a possibilidade de aumentar CPU, RAM e disco sem migração longa vale mais do que economizar alguns reais no plano inicial. Se você ainda está comparando cenários de banco, o guia de VPS para banco PostgreSQL aprofunda os pontos de CPU, cache, conexões e disco.

Requisitos técnicos para produção

A configuração mínima depende do que você chama de produção. Um projeto com poucos clientes, tabelas pequenas e uploads moderados pode rodar em 2 vCPUs e 4 GB de RAM, mas essa margem é apertada para atualizações, backups e picos. Para uma produção inicial mais confortável, trate 4 vCPUs, 8 GB de RAM e 100 GB de SSD como base. Em workloads com muitos uploads, relatórios ou Realtime, considere 8 vCPUs, 16 GB de RAM e disco separado ou volume expansível. Não é exagero, é a diferença entre ter tempo para agir e ficar apagando incêndio.

CPU e RAM para cada porte de aplicação

O PostgreSQL usa RAM para cache, ordenações, joins e conexões. Os containers do Supabase também consomem memória de forma contínua. Em um host de 4 GB, você precisa controlar limites de containers, evitar jobs pesados no mesmo servidor e monitorar swap. Swap pode salvar o processo por alguns minutos, mas não deve virar estratégia permanente. Um sintoma comum de subdimensionamento é o Studio ficar lento enquanto a API responde de forma irregular, principalmente durante backup ou importação de dados.

Para um MVP com poucos usuários, 2 vCPUs e 4 GB de RAM podem bastar. Use Postgres com conexões controladas, limite uploads e rode backups em horários de menor uso. Para um produto B2B pequeno, 4 vCPUs e 8 GB dão espaço para Auth, API, Realtime e banco sem sufoco. Para um SaaS com centenas de usuários ativos por hora, 8 vCPUs e 16 GB começam a fazer mais sentido, principalmente se o banco estiver no mesmo host.

Disco, IOPS e crescimento do banco

Disco é o recurso que mais costuma ser subestimado. PostgreSQL escreve WAL, índices, dados temporários e arquivos de vacuum. O Storage API ainda adiciona objetos, imagens, documentos e metadados. SSD é o mínimo aceitável para produção. NVMe pode ajudar em I/O, mas não resolve consultas ruins, índices ausentes ou falta de memória. Em provedores como LetsCloud, DigitalOcean, Vultr e outros, confirme tipo de storage por plano e localidade antes de assumir disponibilidade. Para um banco de 30 GB, planeje pelo menos 100 GB de disco útil, porque backups locais temporários, logs e crescimento mensal consomem espaço rapidamente.

Rede também entra na conta. Uploads de arquivos e chamadas frequentes de API aumentam tráfego de saída. Se o público está no Brasil, uma região local pode reduzir latência percebida em login, listagens e envio de arquivos. Ainda assim, localidade, franquia de bandwidth e política de cobrança são dados voláteis. A coleta de referência de concorrentes e provedores relevantes foi marcada como verificada em 2026-07-04, com recomendação de revisão humana antes de publicar qualquer preço ou condição comercial.

Arquitetura recomendada com Docker

O caminho mais comum para Supabase self-hosted é Docker Compose, porque o projeto oficial já organiza serviços, variáveis de ambiente e dependências. Isso facilita o início, mas também cria uma armadilha: subir containers não significa ter produção pronta. Você precisa definir volumes persistentes, segredos fortes, firewall, proxy HTTPS, atualização de imagens, logs e rotina de restauração. Um comando como docker compose up -d resolve a inicialização, não a operação.

Serviços principais do stack

Em uma instalação típica, o gateway recebe as requisições, direciona tráfego para APIs internas e expõe endpoints de autenticação, REST, Realtime e storage. O PostgreSQL guarda dados da aplicação e metadados. O Studio permite administração visual. O Auth gerencia usuários, sessões e provedores externos. O Storage API trata objetos, buckets e permissões. Dependendo da versão e configuração, outros containers entram para funções, analytics e logging.

A primeira decisão prática é separar o tráfego público do tráfego administrativo. O Studio não deve ficar aberto sem controle. Use HTTPS com proxy reverso, autenticação adicional quando possível e regras de firewall que liberem apenas portas necessárias, normalmente 22 para SSH restrito, 80 e 443 para web, além de portas internas fechadas para a internet. Quem está planejando rodar outros serviços no mesmo host deve ler também o guia de VPS para Docker, porque limites de memória, redes Docker e volumes persistentes fazem diferença quando vários containers convivem.

Separar ou não separar o banco

No início, manter tudo na mesma VPS reduz custo e complexidade. É mais simples fazer deploy, monitorar e atualizar. O problema aparece quando o PostgreSQL vira gargalo. Se backups, consultas pesadas ou Realtime competem com a API no mesmo host, a experiência do usuário fica instável. A evolução natural é separar o banco em uma VPS dedicada ou migrar o PostgreSQL para um serviço gerenciado, mantendo Supabase APIs e gateway em outro servidor.

Um desenho intermediário funciona bem para times pequenos: VPS 1 com Supabase API, Auth, Realtime, Storage e Studio, VPS 2 dedicada ao PostgreSQL, ambas na mesma região ou rede privada quando o provedor oferecer esse recurso. Essa arquitetura reduz disputa por disco e memória, mas exige atenção a latência interna, firewall entre servidores, criptografia em trânsito e backup coordenado. Não use esse desenho se o time não consegue monitorar dois hosts. Complexidade sem operação vira risco.

PostgreSQL, storage e backups sem improviso

O ponto mais crítico do Supabase self-hosted é a persistência. Containers podem ser recriados. Imagens podem ser atualizadas. O banco e os arquivos dos usuários não podem sumir. Antes de colocar clientes reais, defina onde ficam os dados, como eles são copiados, por quanto tempo ficam retidos e quanto tempo você leva para restaurar. Backup que nunca foi restaurado é apenas uma esperança compactada em algum diretório.

Volume persistente e política de retenção

No PostgreSQL, use volume persistente fora do ciclo de vida do container. Evite guardar dados apenas dentro da camada efêmera do container. Um layout comum mantém o diretório de dados do Postgres em um volume Docker ou caminho montado no host, com permissões corretas e monitoramento de espaço. Para backups lógicos, pg_dump e pg_dumpall ajudam em bancos pequenos e médios. Para bancos maiores, pense em WAL archiving, ferramentas como pgBackRest ou restauração por base backup. A estratégia depende do tamanho, da janela de recuperação e da equipe disponível.

Um exemplo prático: banco de 20 GB, 5 GB de arquivos enviados por mês e meta de recuperação em até 2 horas. Nesse caso, rode backup lógico diário para armazenamento externo, mantenha retenção de 7 a 14 dias, teste restauração semanal em ambiente separado e monitore falha de job. Se o banco passar de 100 GB, o tempo de pg_dump pode ficar incômodo. Aí faz sentido avaliar backup físico, snapshots coordenados e uma rotina mais madura de WAL.

Snapshots não substituem backup lógico

Snapshots do provedor são úteis para recuperar uma VPS inteira, principalmente antes de atualização grande. Eles não substituem backup lógico do PostgreSQL. Um snapshot tirado enquanto há escrita intensa pode exigir recuperação do banco e não ajuda se alguém apagou dados importantes há três dias e o snapshot mais antigo já foi sobrescrito. O ideal é combinar camadas: snapshot antes de mudanças, backup lógico ou físico regular, cópia externa e teste de restore.

Storage de arquivos também precisa de plano. Para MVP, armazenar objetos no disco local pode ser aceitável, desde que exista backup. Para produção com documentos de clientes, fotos ou anexos importantes, avalie armazenamento compatível com S3, replicação ou rotina externa de cópia. Em qualquer alternativa, calcule crescimento. Se 500 usuários enviam 10 arquivos de 2 MB por mês, são cerca de 10 GB mensais só em uploads, sem contar thumbnails, logs e versões. Esse número muda rapidamente quando o produto começa a reter histórico.

Segurança, autenticação e operação diária

Supabase self-hosted entrega muito controle, mas também transfere responsabilidades que a plataforma gerenciada normalmente absorve. Você passa a cuidar de chaves JWT, senhas de banco, SMTP, provedores OAuth, certificados TLS, atualização de imagens, logs e proteção do painel. O risco não está apenas em ser invadido. Configuração fraca pode causar vazamento de token, bucket público sem querer, perda de acesso administrativo ou indisponibilidade depois de um update.

Segredos, JWT e painel administrativo

Comece por segredos fortes. Gere senhas únicas para PostgreSQL, tokens anon e service role com tamanho adequado, JWT secret robusto e credenciais separadas para SMTP e provedores externos. Nunca versionar o arquivo .env em repositório público. Em times, use cofre de segredos, permissões por função e rotação documentada. O token service role deve ficar apenas em ambientes confiáveis de backend, porque ele tem poder elevado. No frontend, use somente a chave pública prevista para esse uso e mantenha Row Level Security bem revisada.

RLS merece atenção especial. O Supabase incentiva políticas no banco, o que é ótimo para segurança, mas uma política mal escrita pode liberar dados demais ou bloquear usuários legítimos. Antes de produção, teste casos como usuário sem sessão, usuário de outra organização, membro removido, admin limitado e arquivo privado. Um SaaS multi-tenant precisa validar todas as consultas por organização ou tenant. Se esse é o seu cenário, o artigo sobre VPS para SaaS no Brasil ajuda a pensar latência, isolamento e crescimento de infraestrutura.

Firewall, SSH e observabilidade

No host, desative login SSH por senha, use chave pública, altere políticas de sudo com cuidado e aplique atualizações de segurança. Configure firewall para expor apenas o necessário. Portas internas do PostgreSQL, APIs administrativas e serviços auxiliares não devem ficar abertas para a internet. Um proxy reverso como Nginx, Caddy ou Traefik pode cuidar de HTTPS e roteamento, mas precisa de configuração clara para headers, limites de upload e timeouts.

Operação diária pede métricas simples: uso de CPU, RAM, swap, disco, I/O, conexões do PostgreSQL, crescimento de tabelas e status de containers. Alertas de disco acima de 80 por cento, falha de backup, container reiniciando e certificado próximo do vencimento evitam sustos. Logs devem ter retenção. Se o servidor ficar sem disco por causa de logs ou uploads, o PostgreSQL pode parar de aceitar escrita. Esse tipo de incidente parece básico, mas é comum em ambientes self-hosted sem rotina definida.

Comparação de configurações para Supabase self-hosted

A escolha da VPS fica mais clara quando você compara perfis de uso em vez de olhar apenas para preço. Supabase pode servir um protótipo interno, um produto com clientes pagantes ou uma plataforma com alta dependência de autenticação e dados. Cada perfil muda a tolerância a downtime, o tamanho do disco, a frequência de backup e a necessidade de separar componentes. A tabela abaixo usa configurações técnicas de referência, não recomenda planos comerciais específicos. Preços, localidades, bandwidth, tipo de storage e recursos inclusos variam por provedor e exigem revisão humana antes da publicação.

Perfil de uso	Configuração de referência	Storage recomendado	Backup mínimo	Quando faz sentido
Laboratório e MVP interno	2 vCPUs, 4 GB RAM, 60 a 80 GB SSD	Volume local persistente	pg_dump diário e snapshot antes de updates	Testes, demos, app com poucos usuários e baixo volume de upload
Produção pequena	4 vCPUs, 8 GB RAM, 100 a 160 GB SSD ou NVMe	Volume persistente com monitoramento de I/O	Backup externo diário, retenção de 7 a 14 dias e restore testado	SaaS inicial, app B2B pequeno, autenticação e storage moderados
Produção em crescimento	8 vCPUs, 16 GB RAM, 200 GB ou mais em SSD/NVMe	Disco expansível ou banco separado	Backup físico ou WAL, snapshots coordenados e teste recorrente	Centenas de usuários ativos, relatórios, Realtime e uploads frequentes
Arquitetura separada	VPS app 4 vCPUs e 8 GB, VPS banco 4 a 8 vCPUs e 16 GB	Banco em host dedicado, storage externo quando possível	Política combinada para banco, arquivos e configuração	Time com operação madura e necessidade de reduzir disputa por recursos

Como interpretar os recursos

CPU ajuda em picos de API, autenticação, compressão, tarefas internas e consultas paralelas. RAM ajuda mais ainda quando o banco precisa manter dados quentes em cache. Disco rápido reduz latência de escrita, vacuum, índices e WAL. Rede afeta uploads, downloads e chamadas frequentes feitas pelo frontend. Nenhum recurso isolado salva uma arquitetura ruim. Uma VPS com NVMe e 2 GB de RAM pode sofrer mais que uma VPS SSD com 8 GB se o banco estiver sem cache.

Na análise de provedores, DigitalOcean, Vultr, AWS Lightsail, Hetzner, Contabo e LetsCloud aparecem com propostas diferentes de região, painel, API, storage e público-alvo. LetsCloud pode ser considerada quando a localização no Brasil, cobrança local ou proximidade com usuários brasileiros fizer sentido, mas a disponibilidade de NVMe, regiões como São Paulo, Fortaleza ou Miami, backups, snapshots e suporte deve ser confirmada por plano. A última verificação editorial de fontes oficiais e documentação foi registrada em 2026-07-04, sem publicação de comparativo de preço automático.

Recomendações por perfil

A melhor VPS para Supabase self-hosted depende menos da marca e mais da sua capacidade de operar o ambiente. Se você não tem rotina de backup, monitoramento e atualização, um plano maior só adia problemas. Se você tem processo, uma VPS bem dimensionada pode sustentar um produto sério com bom custo operacional. A decisão deve juntar tráfego, tamanho do banco, volume de arquivos, latência esperada, orçamento e tempo de resposta do time em incidentes.

Dev solo validando um MVP

Para um dev solo, a prioridade é simplicidade. Use uma VPS de 2 vCPUs, 4 GB de RAM e 60 a 80 GB de SSD para validar o produto, desde que não existam clientes dependentes do ambiente. Configure Docker Compose, HTTPS, firewall, backup diário para fora da VPS e alerta de disco. Evite hospedar n8n, WordPress, analytics pesado e Supabase no mesmo servidor se a memória for baixa. Faça um teste de restauração antes do lançamento público. Se o MVP começar a ter usuários reais, programe upgrade para 4 vCPUs e 8 GB antes de sentir lentidão.

Time pequeno com produto em uso

Para um time pequeno, 4 vCPUs, 8 GB de RAM e 100 a 160 GB de SSD ou NVMe são uma base mais equilibrada. O ambiente já deve ter rotina de deploy, logs, backup externo, snapshots antes de mudanças e documentação de recuperação. Separe credenciais por ambiente, revise políticas RLS e monitore conexões do PostgreSQL. Se o produto usa uploads, calcule crescimento mensal e defina retenção. Se o tráfego vem majoritariamente do Brasil, teste latência em regiões brasileiras e nos EUA antes de decidir. Diferenças de 100 ms podem aparecer em telas que fazem muitas chamadas de API.

Produção crítica ou SaaS em crescimento

Para produção crítica, trate Supabase self-hosted como infraestrutura de dados. Comece em 8 vCPUs, 16 GB de RAM e 200 GB ou mais, ou separe PostgreSQL em um host dedicado. Use backup físico ou WAL quando o banco ficar grande, mantenha cópias externas e rode simulações de restore. Planeje janela de manutenção, atualização de imagens e rollback. Se o time não tem disponibilidade para operar banco, segurança e incidentes, considere PostgreSQL gerenciado ou Supabase Cloud para partes críticas. Self-hosted dá controle, mas cobra disciplina. A economia só compensa quando a operação está no mesmo nível da responsabilidade.