VPS para Coolify em produção: guia prático

Resposta direta

Para rodar Coolify em produção, escolha uma VPS com pelo menos 2 vCPUs, 4 GB de RAM, 60 GB de SSD ou NVMe e uma rotina real de backup. Essa configuração atende bem um painel Coolify com 2 a 5 aplicações leves, um banco PostgreSQL pequeno, Redis opcional e alguns workers. Para projetos com Next.js, APIs Node.js, n8n, filas ou banco de dados no mesmo servidor, 4 vCPUs, 8 GB de RAM e 100 GB de disco rápido são um ponto de partida mais seguro. O Coolify simplifica deploy, domínio, SSL e containers Docker, mas não substitui práticas de produção como firewall, SSH com chave, snapshots testados, monitoramento de disco e atualização planejada. Se a aplicação gera receita ou atende clientes, trate a VPS como infraestrutura crítica desde o primeiro deploy.

Resumo rápido

• Coolify é uma plataforma self-hosted para deploy de aplicações, bancos, serviços e automações usando Docker.
• Para produção básica, comece com 2 vCPUs, 4 GB de RAM e 60 GB de SSD ou NVMe, evitando planos com memória muito apertada.
• Para APIs, Next.js, workers, filas e banco no mesmo servidor, prefira 4 vCPUs, 8 GB de RAM e pelo menos 100 GB de disco.
• Banco de dados em container funciona, mas exige volumes persistentes, backup externo e teste de restauração.
• O servidor precisa de portas 80 e 443 liberadas, DNS bem configurado, firewall ativo e acesso SSH por chave.
• Snapshots ajudam em rollback rápido, mas não substituem backup lógico de PostgreSQL, MySQL ou arquivos críticos.
• Datacenter mais próximo do público reduz latência, mas não corrige aplicação lenta, consulta SQL ruim ou falta de cache.

O que muda ao usar Coolify em produção

Coolify é atraente porque entrega uma experiência parecida com plataformas gerenciadas, só que em uma VPS própria. Você conecta um repositório Git, cria um recurso, define domínio, variáveis de ambiente e manda publicar. Por baixo, a lógica continua sendo a de containers Docker, proxy reverso, redes internas, volumes persistentes e processos que precisam ficar de pé depois de reboot. Em ambiente de teste, isso parece simples. Em produção, a conversa muda porque uma falha de disco, uma migration mal feita ou uma variável errada pode derrubar clientes reais.

Coolify ajuda no deploy, mas não elimina operação

O primeiro erro comum é tratar o Coolify como hospedagem mágica. Ele automatiza muita coisa, mas o servidor ainda precisa ser operado. A VPS precisa ter swap configurado com cuidado, atualizações de segurança, regras de firewall, logs rotacionados e espaço livre suficiente para imagens Docker antigas. Um deploy de aplicação Node.js pode gerar uma nova imagem a cada release. Depois de algumas semanas, o diretório usado pelo Docker pode crescer dezenas de gigabytes se ninguém limpar imagens não usadas.

Um exemplo prático: uma API pequena em Node.js, um frontend Next.js e um PostgreSQL em container podem rodar bem com 4 GB de RAM no começo. Quando você adiciona fila, Redis, preview deployments e build local do Next.js, o consumo sobe rápido. Se o build usa 1,5 GB de RAM e o PostgreSQL já está usando 700 MB, qualquer pico pode acionar swap. A aplicação não cai de imediato, mas fica lenta, o deploy demora e o painel do Coolify começa a responder mal.

VPS, Cloud Server e cloud instance no contexto do Coolify

Para este guia, VPS tradicional significa um servidor virtual com recursos alocados em um host físico. Cloud Server e cloud instance costumam oferecer provisionamento mais flexível, APIs, imagens prontas e upgrades mais rápidos, embora isso varie por provedor. Para Coolify, o mais importante é ter virtualização estável, disco confiável, possibilidade de upgrade, rede consistente e acesso root. Se você ainda está comparando conceitos de containers, vale ler também o guia de VPS para Docker, porque Coolify depende diretamente de Docker para executar aplicações e serviços.

Requisitos de VPS para Coolify em produção

O requisito mínimo oficial de uma ferramenta raramente conta a história inteira. Coolify pode instalar e abrir o painel em um servidor pequeno, mas produção envolve builds, containers simultâneos, banco de dados, proxy reverso e tarefas em background. Uma VPS de 1 vCPU e 1 GB de RAM pode servir para laboratório. Para produção, ela vira gargalo cedo, principalmente quando o build acontece no próprio servidor. A recomendação editorial segura é começar em 2 vCPUs e 4 GB de RAM para projetos pequenos, subindo para 4 vCPUs e 8 GB quando houver banco, workers ou múltiplas aplicações.

CPU e RAM para aplicações, workers e banco de dados

CPU pesa em três momentos: build, inicialização e picos de requisição. Um build de Next.js, por exemplo, pode usar CPU de forma intensa por alguns minutos. Uma API Express ou NestJS consome pouco em repouso, mas pode escalar mal se fizer processamento pesado no request. Workers de fila competem pelos mesmos núcleos. Em um servidor com 2 vCPUs, rodar build, banco e aplicação ao mesmo tempo já exige disciplina. Em 4 vCPUs, há mais folga para deploy sem afetar tanto o tráfego.

RAM é ainda mais sensível. PostgreSQL, MySQL, Redis, n8n, aplicações Node.js e o próprio Coolify mantêm processos residentes. Um cenário realista com Coolify, proxy, uma API Node.js, um Next.js e PostgreSQL costuma ficar entre 2 GB e 3,5 GB de RAM antes de picos. Por isso, 4 GB é o piso confortável. Com 8 GB, você consegue reservar mais memória para banco, cache e builds sem depender tanto de swap.

Disco, IOPS e crescimento de volumes persistentes

Disco não é só tamanho. Coolify usa Docker, e Docker cria camadas, imagens, volumes e logs. Um projeto pequeno pode começar com 20 GB ocupados e chegar a 60 GB em poucos meses com imagens antigas, uploads e backups locais. SSD é o mínimo recomendado. NVMe tende a melhorar operações de I/O, principalmente banco de dados e builds, mas a disponibilidade depende do plano e da localidade do provedor. Não trate NVMe como garantia universal sem confirmar na página oficial.

Rede, latência e banda de saída

Se o público está no Brasil, uma região brasileira ou próxima pode reduzir latência perceptível em login, painel administrativo e APIs com muitas chamadas. Ainda assim, latência baixa não resolve consulta SQL lenta. Para a maioria dos SaaS pequenos, 1 TB de transferência mensal é mais do que suficiente, mas aplicações com upload, imagens, vídeos ou webhooks intensos precisam de análise própria. Bandwidth, franquia e cobrança por tráfego são dados variáveis e devem ser revisados antes da publicação de qualquer comparativo de preço.

Arquitetura recomendada para aplicações, bancos e automações

A arquitetura mais simples para Coolify é colocar tudo em uma única VPS: painel, proxy reverso, aplicações, banco de dados, Redis e automações. Essa abordagem é barata, fácil de entender e boa para começar. O problema aparece quando tudo passa a disputar os mesmos recursos. Se o banco faz vacuum, o Next.js está em build e o n8n executa um fluxo pesado, a VPS inteira sente. Em produção, a decisão não é apenas o que funciona hoje, mas o quanto você aceita de risco operacional.

Tudo em uma VPS quando o projeto ainda é pequeno

Para um projeto inicial, uma única VPS com 4 vCPUs, 8 GB de RAM e 100 GB de SSD ou NVMe pode hospedar o Coolify, uma API, um frontend, PostgreSQL e Redis com boa margem. Esse desenho funciona bem para MVP, painel interno, site institucional com backend leve, automações de equipe e SaaS com poucos clientes. A regra é manter volumes persistentes organizados, limitar logs e evitar que backups fiquem apenas dentro do mesmo disco.

Um exemplo: imagine um SaaS B2B com Next.js, API Node.js, PostgreSQL e um worker para enviar e-mails. O Coolify cuida do deploy via Git e do SSL. O PostgreSQL fica em volume persistente. O worker roda como serviço separado com limite de memória. Nesse caso, um plano com 8 GB de RAM dá espaço para builds, cache e pequenas filas. Se esse SaaS começa a processar milhares de eventos por hora, separar banco ou workers passa a fazer sentido.

Separar banco de dados quando a aplicação vira crítica

Banco no mesmo servidor é aceitável no início, mas produção crítica pede mais cuidado. Separar o banco em outra VPS ou serviço gerenciado reduz impacto de deploys e libera CPU da aplicação. Também facilita backup, tuning e atualização. O custo operacional sobe, já que você terá rede privada, firewall entre servidores e mais pontos de monitoramento. Mesmo assim, para aplicações que faturam, armazenam dados sensíveis ou não podem perder histórico, essa separação costuma compensar.

Volumes persistentes, backups e ambientes isolados

Coolify facilita criar serviços, mas volumes persistentes precisam ser tratados como patrimônio. Uploads, banco, arquivos de configuração e dados de automações não podem depender apenas do container em execução. Use nomes claros para volumes, documente onde cada dado vive e separe produção de staging. Ambientes de preview são úteis, mas não devem acessar banco de produção sem controle. Para automações, n8n e filas, prefira credenciais separadas por ambiente e limite o acesso a APIs externas.

Deploy, domínio, SSL e rede no Coolify

Deploy em Coolify costuma seguir um fluxo simples: conectar Git, escolher buildpack ou Dockerfile, definir variáveis, apontar domínio e publicar. O detalhe é que produção exige consistência. DNS precisa apontar corretamente para o IP da VPS. Portas 80 e 443 precisam estar abertas para emissão e renovação de certificados. O proxy reverso precisa encaminhar tráfego para o container certo. Uma configuração errada pode fazer a aplicação funcionar pelo IP, mas falhar no domínio com SSL.

Portas, proxy reverso e DNS

A configuração básica envolve liberar HTTP e HTTPS no firewall, manter SSH restrito e usar registros A ou CNAME conforme o caso. Um domínio como app.exemplo.com pode apontar para a VPS. A API pode usar api.exemplo.com. O Coolify gerencia o roteamento, mas o DNS externo ainda é sua responsabilidade. Para um servidor Ubuntu, um firewall simples costuma liberar apenas 22, 80 e 443. Se possível, restrinja SSH por IP ou use uma porta não padrão junto com autenticação por chave.

Um checklist prático antes de publicar: confirme se o domínio resolve para o IP correto, se a aplicação escuta na porta interna esperada, se as variáveis de ambiente foram preenchidas e se o healthcheck responde. Em aplicações Node.js, evite hardcode de porta. Use a variável PORT quando o runtime exigir. Quem pretende hospedar APIs JavaScript com tráfego brasileiro pode complementar este guia com o artigo sobre VPS para Node.js no Brasil, especialmente na parte de latência, PM2, Docker e bancos próximos do usuário final.

Variáveis de ambiente e segredos

Variáveis de ambiente são um ponto sensível. Nunca coloque chaves reais em Dockerfile, repositório Git ou exemplos públicos. No Coolify, cadastre segredos no painel e separe valores de produção, staging e desenvolvimento. DATABASE_URL, REDIS_URL, JWT_SECRET, SMTP_PASSWORD e tokens de API devem ser rotacionáveis. Se alguém saiu do time ou um deploy vazou log com credencial, rotacione imediatamente. Logs de build também podem expor dados se scripts imprimem variáveis no terminal.

Deploy de Node.js, Next.js, APIs e automações

Next.js merece atenção especial porque build e runtime podem ter perfis diferentes. Um site estático exportado pesa pouco. Um app com SSR, imagens, autenticação e rotas dinâmicas consome mais memória e CPU. Se você usa Next.js no Coolify, defina cache de build quando possível, monitore tempo de build e evite rodar tarefas pesadas durante deploy em horário de pico. O guia de VPS para Next.js no Brasil aprofunda esse ponto, incluindo impacto de SSR, localização do servidor e banco de dados.

Segurança, backups e rotina de atualização

Produção começa pela suposição de que algo vai falhar. Uma senha pode vazar, um deploy pode quebrar, um disco pode lotar e uma atualização pode trazer incompatibilidade. Coolify melhora o fluxo de publicação, mas a segurança da VPS continua dependendo de boas práticas. O básico inclui SSH por chave, usuário administrativo sem login root direto, firewall ativo, pacotes atualizados e acesso ao painel protegido por senha forte. Se houver suporte a autenticação de dois fatores na camada usada, ative.

Acesso SSH, firewall e usuários administrativos

Evite administrar a VPS inteira com root no dia a dia. Crie um usuário com sudo, desative login root por SSH quando possível e use chaves ed25519. Mantenha a chave privada fora de repositórios, gerenciadores de projeto e scripts compartilhados. No firewall, exponha apenas o necessário. Portas de banco de dados, Redis e serviços internos não devem ficar abertas para a internet. Se o PostgreSQL precisa ser acessado de outra VPS, prefira rede privada do provedor ou libere somente o IP de origem.

Um exemplo simples de política: SSH liberado apenas para IPs administrativos, HTTP e HTTPS públicos, banco fechado externamente, painel Coolify em domínio próprio com senha forte. Para times, crie contas individuais. Compartilhar login administrativo parece prático, mas dificulta auditoria e aumenta risco quando alguém sai do projeto.

Backups, snapshots e teste de restauração

Snapshot é útil para voltar o servidor inteiro a um ponto anterior. Backup lógico é útil para restaurar dados específicos. Os dois se complementam. Para PostgreSQL, use dumps periódicos com retenção, envie para armazenamento externo e teste restauração em ambiente separado. Para uploads, faça cópia incremental para object storage ou outra VPS. Guardar backup apenas no mesmo disco da VPS protege contra erro lógico parcial, mas não protege contra falha de disco, exclusão acidental ampla ou perda do servidor.

Uma rotina realista para produção pequena: snapshot diário com retenção curta, dump de banco a cada 6 ou 12 horas, backup de uploads diário e teste de restauração mensal. Se o negócio depende da aplicação, reduza o intervalo. Também defina RPO e RTO. RPO responde quanto dado você aceita perder. RTO responde quanto tempo você aceita ficar fora do ar. Sem esses dois números, backup vira sensação de segurança, não plano de recuperação.

Atualizações com janela de manutenção

Atualize sistema operacional, Docker e Coolify com planejamento. Antes de atualizar, faça snapshot, confira espaço em disco e leia notas de versão. Em servidores pequenos, uma atualização pode reiniciar serviços e causar indisponibilidade curta. Se você tem clientes ativos, avise ou escolha horário de menor uso. Depois da atualização, confira painel, containers, logs, certificados e jobs agendados. Um comando como docker ps mostra containers em execução, mas não confirma se a aplicação está saudável. Healthchecks e testes HTTP simples ajudam muito.

Tabela comparativa de configurações para Coolify

A tabela abaixo não é uma comparação de preço. Ela serve como referência técnica para dimensionar VPS para Coolify conforme o tipo de carga. Preços, regiões, banda, snapshots, backup automático e tipo de storage variam por provedor e precisam ser conferidos nas páginas oficiais antes de qualquer decisão comercial. Use os números como ponto de partida, não como promessa de capacidade. Uma aplicação mal otimizada pode sofrer em um servidor grande, enquanto um serviço enxuto pode rodar bem em um plano menor.

Como ler a tabela antes de contratar a VPS

O tamanho ideal depende de três fatores: quantidade de containers, perfil de build e criticidade do banco. Se o Coolify vai apenas publicar um site estático e uma API simples, 2 vCPUs e 4 GB de RAM podem atender. Se o servidor também compila Next.js, roda PostgreSQL, Redis, automações e workers, 8 GB de RAM deixam de ser luxo e viram margem operacional. O disco deve considerar imagens Docker antigas, banco, uploads, logs e backups temporários.

Perfil de uso	Configuração inicial sugerida	Carga típica	Pontos de atenção	Quando escalar
Laboratório e staging	2 vCPUs, 2 a 4 GB RAM, 40 GB SSD	1 a 2 apps leves, sem banco crítico	Pode sofrer em builds e picos de RAM	Ao ter deploy frequente ou banco persistente
Produção pequena	2 a 4 vCPUs, 4 GB RAM, 60 a 80 GB SSD ou NVMe	API, frontend, PostgreSQL pequeno e Redis opcional	Limpeza de imagens Docker e backup externo	Ao passar de 3 a 5 apps ou usar workers
SaaS inicial ou clientes	4 vCPUs, 8 GB RAM, 100 GB SSD ou NVMe	Next.js, API, banco, filas, automações e painel	Monitorar IOPS, RAM e tempo de build	Ao ter picos diários, relatórios ou filas longas
Produção crítica	4 a 8 vCPUs, 16 GB RAM, 160 GB ou mais	Banco maior, múltiplos serviços, n8n e workers	Separar banco, storage e observabilidade	Ao exigir alta disponibilidade ou RTO baixo

Na escolha do provedor, priorize estabilidade, possibilidade de upgrade, localidade compatível com o público, documentação clara e suporte ao sistema operacional que você pretende usar. Provedores como DigitalOcean, Vultr, Linode Akamai, AWS Lightsail, Hetzner, Contabo e opções brasileiras podem atender cenários diferentes, mas dados de preço, região, banda e storage são voláteis. LetsCloud pode entrar no radar quando fizer sentido buscar infraestrutura próxima do Brasil ou pagamento local, mas disponibilidade de NVMe, localidades, snapshots e backups precisa ser confirmada por plano antes de publicar qualquer afirmação fechada.

Monitoramento, troubleshooting e escala

Depois que o Coolify está em produção, o trabalho passa a ser observar sinais pequenos antes que virem incidentes. CPU em 100 por cento durante builds pode ser normal por alguns minutos. CPU alta o dia inteiro indica consulta ruim, loop, worker descontrolado ou falta de cache. RAM perto do limite com swap crescente costuma aparecer como lentidão geral. Disco acima de 80 por cento é alerta sério, porque Docker, banco e logs podem ocupar o restante rapidamente.

Sinais de gargalo em CPU, RAM e disco

Use ferramentas simples antes de complicar. htop mostra processos e uso de CPU. df -h mostra espaço em disco. docker system df mostra quanto Docker está consumindo em imagens, containers e volumes. docker logs ajuda a identificar erro repetido. Para PostgreSQL, acompanhe tamanho do banco, conexões abertas e queries lentas. Se o banco está em container, lembre que o volume persistente é o ponto crítico. Apagar container não deveria apagar dados, mas apagar volume errado pode ser desastre.

Um caso comum: deploys começam a falhar sem mudança no código. Ao verificar, o disco está com 96 por cento de uso por imagens antigas. A correção imediata pode ser limpar imagens não usadas, mas a correção de produção é criar rotina de limpeza, aumentar disco ou revisar estratégia de build. Outro caso: o painel do Coolify fica lento enquanto o Next.js compila. Isso pode indicar RAM insuficiente. Subir de 4 GB para 8 GB resolve em muitos cenários, mas também vale revisar dependências, cache e horário de deploy.

Logs, filas e deploys com rollback

Logs são úteis até virarem problema. Configure rotação e evite imprimir payloads sensíveis. Em filas, monitore backlog. Se uma fila que normalmente tem 20 jobs passa a ter 10 mil, adicionar CPU talvez não seja suficiente. Pode haver API externa lenta, worker travado ou erro repetindo. Para deploy, mantenha estratégia de rollback. Snapshot antes de mudanças grandes ajuda, mas rollback de aplicação deve ser possível pelo Git, com imagem anterior ou release anterior.

Quando subir de plano ou separar serviços

Escalar verticalmente é o caminho mais rápido: mais vCPU, mais RAM e mais disco. Funciona bem até certo ponto. Quando banco disputa recurso com aplicação, separar banco tende a trazer estabilidade. Quando workers consomem CPU demais, movê-los para outra VPS reduz impacto no frontend. Quando uploads crescem, object storage evita lotar o servidor. Coolify facilita centralizar deploy, mas produção saudável costuma separar responsabilidades conforme o uso cresce.

Recomendações por perfil

Dev solo e projetos pessoais

Para dev solo, laboratório pago, portfólio, bot pequeno ou ferramenta interna, uma VPS com 2 vCPUs, 4 GB de RAM e 60 GB de SSD já entrega uma experiência confortável. Dá para rodar o Coolify, uma API, um frontend e um banco pequeno, desde que você mantenha backups fora da VPS e limpe imagens Docker antigas. Evite colocar muitos projetos esquecidos no mesmo servidor. O maior risco nesse perfil não é tráfego alto, é acúmulo de containers, logs e credenciais antigas. Use domínio próprio, SSH por chave e um calendário simples de atualização mensal.

Time pequeno com clientes ou SaaS inicial

Para um time pequeno, agência ou SaaS inicial, a recomendação sobe para 4 vCPUs, 8 GB de RAM e 100 GB de SSD ou NVMe. Esse tamanho permite build de Next.js, API Node.js, PostgreSQL, Redis e alguns workers sem deixar o servidor no limite o tempo todo. Também dá margem para staging, desde que o ambiente não replique tudo em escala igual à produção. Nesse perfil, documente variáveis de ambiente, defina responsáveis por deploy e configure alertas básicos de disco e disponibilidade. Se clientes dependem do sistema durante horário comercial, faça deploy com janela e rollback planejado.

Produção crítica com banco e automações

Quando a aplicação gera receita relevante, armazena dados sensíveis ou roda automações que não podem parar, pense em 4 a 8 vCPUs, 16 GB de RAM e disco com folga acima de 160 GB, além de backup externo testado. Nesse estágio, separar banco de dados é uma decisão forte. Workers, n8n e filas também podem ir para outra VPS se competirem com o frontend. O objetivo não é comprar o maior servidor possível, mas reduzir pontos de falha. Monitore RPO, RTO, uso de disco, tempo de resposta, filas e sucesso dos backups. Coolify continua útil, mas operação passa a ser parte do produto.