Qual é a configuração mínima de VPS para Portainer em produção?

Para produção pequena, a recomendação prática é começar com 2 vCPUs, 4 GB de RAM e 60 GB de SSD ou NVMe. O Portainer sozinho consome pouco, mas ele normalmente roda junto com proxy reverso, banco de dados, Redis, workers e aplicações web. Em 2 GB de RAM, qualquer pico pode empurrar o servidor para swap. Se houver múltiplas stacks, builds locais ou banco com consultas pesadas, suba para 4 vCPUs e 8 GB de RAM.

É seguro expor o Portainer diretamente na internet?

Não é a abordagem mais segura. Mesmo com HTTPS, a tela de login exposta recebe varreduras e tentativas de acesso. O ideal é restringir a origem por VPN, allowlist de IP, túnel seguro ou camada de acesso como Cloudflare Access. Se o painel precisar estar em um domínio público, use proxy reverso com TLS, senha forte, 2FA quando disponível e atualização frequente. Quem acessa o Portainer com permissão administrativa pode controlar containers, volumes e partes sensíveis do host.

Portainer substitui Docker Compose em produção?

Não. Portainer pode criar e gerenciar stacks baseadas em Compose, mas o arquivo Compose continua sendo a descrição principal da aplicação. A prática mais segura é manter os arquivos versionados em repositório privado, revisar mudanças por pull request e aplicar deploys de forma controlada. Portainer ajuda na visualização, logs, reinício de containers e operação do dia a dia. Ele não deve virar o único lugar onde a configuração existe, porque isso dificulta auditoria, rollback e reconstrução do ambiente.

Snapshot da VPS é suficiente para backup dos containers?

Snapshot ajuda muito em recuperação rápida, mas não deve ser o único backup. Ele captura o estado do servidor em um momento, inclusive problemas que já existiam naquele instante. Bancos de dados precisam de dumps consistentes ou estratégia própria de backup. Uploads e arquivos persistentes devem ser copiados para storage externo com retenção. Uma boa rotina combina snapshot antes de mudanças grandes, backup diário do banco, cópia incremental de volumes importantes e teste periódico de restauração em ambiente separado.

Qual proxy reverso combina melhor com Portainer?

Depende do tipo de operação. Caddy é simples e automatiza HTTPS com pouca configuração, por isso funciona bem para devs solo e projetos pequenos. Nginx oferece controle fino e ampla documentação, sendo uma escolha boa para equipes que já conhecem sua sintaxe. Traefik se integra muito bem ao Docker por labels e descobre serviços dinamicamente, o que ajuda quando há muitas stacks. Em qualquer opção, mantenha banco e Redis sem porta pública e publique apenas serviços HTTP necessários.

Devo rodar banco de dados na mesma VPS do Portainer?

Para projetos pequenos, rodar banco na mesma VPS pode ser aceitável se houver backup externo, monitoramento de disco e recursos suficientes. Para produção crítica, separar o banco reduz risco e facilita escalar CPU, RAM, I/O e políticas de backup. O ponto principal é não publicar a porta do banco na internet e não depender apenas do volume local. Se a aplicação exige baixa perda de dados, defina RPO, teste restauração e considere serviço gerenciado ou VPS dedicada para o banco.

Como escolher VPS para Portainer em produção

Resposta direta

Uma VPS para Portainer em produção deve ser dimensionada pelo conjunto de containers que ela vai administrar, não pelo Portainer sozinho. Para um ambiente pequeno, comece com 2 vCPUs, 4 GB de RAM, 60 GB de SSD ou NVMe e backups externos dos volumes. O painel deve rodar com TLS, firewall restritivo, autenticação forte e acesso limitado por VPN, allowlist de IP ou proxy reverso bem configurado. Portainer facilita a administração de Docker, stacks, volumes, redes e logs, mas não elimina a necessidade de hardening, monitoramento e plano de restauração. Em produção, trate o socket Docker como acesso privilegiado ao servidor. Se alguém controla o Portainer com permissão administrativa, na prática controla os containers, imagens, volumes e boa parte do host.

Resumo rápido

Portainer é útil para administrar Docker em VPS, mas precisa de arquitetura, segurança e backup bem planejados.
Para produção básica, use pelo menos 2 vCPUs, 4 GB de RAM, 60 GB de disco SSD ou NVMe e swap moderado.
O painel não deve ficar aberto sem controle. Use TLS, firewall, senha forte, 2FA quando disponível e restrição de origem.
Volumes de banco de dados, uploads e configurações precisam de backup próprio, separado do snapshot da VPS.
Proxy reverso com Nginx, Caddy ou Traefik ajuda a publicar aplicações com HTTPS e domínios separados.
Snapshots são ótimos para recuperação rápida, mas não substituem dumps de banco nem cópias versionadas fora da VPS.
Em times, use RBAC, contas individuais e separação entre ambientes de teste, homologação e produção.

Onde o Portainer entra em uma VPS de produção

Portainer é uma camada de administração para ambientes Docker. Em uma VPS, ele costuma ser usado para criar stacks com Docker Compose, acompanhar logs, reiniciar containers, gerenciar volumes, controlar redes e visualizar o estado geral dos serviços. Isso reduz a dependência de comandos manuais no terminal, especialmente quando há mais de uma pessoa operando a infraestrutura. Ainda assim, Portainer não transforma uma VPS simples em uma plataforma gerenciada. Ele é um painel de controle, não uma barreira mágica contra falhas.

Portainer não substitui arquitetura

O erro mais comum é instalar Portainer, subir todos os containers na mesma rede padrão e tratar isso como produção. Funciona no começo, mas vira problema quando aparecem banco de dados, filas, uploads, SSL, logs e deploys frequentes. Uma stack com aplicação Node.js, PostgreSQL, Redis e worker, por exemplo, precisa de volumes nomeados, variáveis de ambiente bem protegidas, política de restart e estratégia de backup. O painel facilita a operação, mas as decisões continuam sendo suas.

Para quem ainda está definindo a base Docker da VPS, faz sentido ler primeiro o guia de VPS para Docker, porque ele cobre instalação do engine, organização de containers, redes e recursos mínimos do host. Portainer entra depois dessa base, como interface para administrar o que já foi planejado.

Quando faz sentido usar Portainer

Portainer brilha em cenários com várias aplicações pequenas, agências que hospedam projetos de clientes, times que precisam consultar logs sem acesso root e desenvolvedores que preferem gerenciar stacks por interface. Um exemplo prático: uma agência pode manter três stacks separadas, uma para site institucional, outra para API e outra para automação interna. Cada stack usa seu próprio arquivo Compose, rede própria e volumes persistentes. O time enxerga status, portas, consumo básico e logs sem precisar decorar comandos.

Também existe um ganho operacional em incidentes simples. Se um container travou depois de uma atualização, o operador consegue ver logs, reiniciar o serviço e validar se a porta voltou a responder. Para incidentes sérios, como corrupção de banco, disco cheio ou invasão de credenciais, o painel não resolve sozinho. Nesses casos, o que salva o ambiente é uma combinação de backup, snapshot, logs externos e processo claro de restauração.

Dimensionamento da VPS: CPU, RAM, disco e rede

O Portainer em si consome poucos recursos em ambientes pequenos. O dimensionamento real vem dos containers que ele administra. Uma VPS com 1 vCPU e 1 GB de RAM pode até rodar Portainer e um serviço leve, mas esse perfil é apertado para produção. Ao adicionar proxy reverso, banco de dados, aplicação web, worker e monitoramento, a memória passa a ser o primeiro gargalo. Swap ajuda a evitar queda abrupta, mas não deve virar muleta para falta de RAM.

Configuração mínima realista

Para produção pequena, a base mais segura é 2 vCPUs, 4 GB de RAM, 60 GB de disco SSD ou NVMe e pelo menos 1 TB de transferência mensal, quando o provedor informa esse limite. Essa configuração sustenta Portainer, um proxy reverso, uma aplicação web, um banco PostgreSQL ou MySQL pequeno e Redis com folga moderada. Em disco, reserve espaço para imagens Docker antigas, logs, volumes e backups temporários. Se o sistema tem 60 GB, não planeje usar 58 GB. Trabalhe com alerta a partir de 70% e ação obrigatória perto de 80%.

Um exemplo comum é uma API em Node.js com PostgreSQL. A aplicação pode consumir 300 a 700 MB de RAM em carga baixa, o banco mais 600 MB a 1,5 GB, Redis cerca de 100 a 300 MB e o proxy reverso menos de 150 MB. Some Portainer, Docker, sistema operacional e cache de filesystem. Em uma VPS de 2 GB, tudo fica justo. Em 4 GB, há margem para picos, deploys e manutenção.

Quando subir para 4 vCPUs ou mais

Suba para 4 vCPUs e 8 GB de RAM quando houver build local de imagens, múltiplas aplicações, banco de dados com consultas pesadas ou muitos workers. CPU também pesa em TLS, compressão, filas e tarefas agendadas. Se você roda n8n, WordPress em container, API, banco e proxy na mesma VPS, a configuração de 4 vCPUs e 8 GB costuma ser mais confortável para produção moderada.

Disco rápido ajuda em bancos e workloads com muitos arquivos pequenos. NVMe tende a reduzir latência de I/O, mas não compensa query sem índice, logs sem rotação ou backup gravando no mesmo volume durante pico. Rede também entra na conta. Público brasileiro acessando uma VPS em datacenter nacional pode perceber menor latência, mas disponibilidade de região, tipo de disco e banda muda por provedor e plano. LetsCloud, DigitalOcean, Vultr, Linode, AWS Lightsail e outros provedores podem atender partes desse cenário, porém localidade, armazenamento, transferência e recursos do plano precisam ser verificados nas páginas oficiais antes da contratação.

Instalação segura do Portainer com Docker

A instalação típica do Portainer usa um volume persistente para os dados do painel e monta o socket Docker do host. Essa montagem é poderosa. Com acesso ao socket, o Portainer pode criar containers, alterar redes, montar volumes e executar operações administrativas. Por isso, o servidor precisa ser tratado como ambiente privilegiado desde o primeiro comando. Não instale o painel em uma VPS abandonada, sem atualização, com SSH aberto por senha e sem firewall.

Separar painel, aplicações e dados

Uma instalação simples pode criar um volume chamado portainer_data e iniciar o container na porta 9443. Em produção, prefira uma rede dedicada para o painel e outra para as aplicações publicadas. Isso facilita regras de comunicação e reduz mistura entre serviços internos. Um comando inicial seria docker volume create portainer_data, seguido da execução do container com política restart unless-stopped, porta administrativa protegida e volume persistente. Em stacks maiores, documente tudo em Compose para poder recriar o painel sem depender de histórico de terminal.

Um desenho prático fica assim: Portainer em uma stack de administração, Traefik ou Caddy em uma stack de borda, aplicação e banco em stacks próprias. A aplicação conversa com o banco por rede interna. O proxy reverso fala apenas com os serviços que devem receber tráfego HTTP. O banco não publica porta externa. Essa separação reduz acidentes, como expor PostgreSQL na internet por engano.

Cuidados com socket Docker

Montar /var/run/docker.sock dentro do Portainer é conveniente, mas equivale a conceder controle amplo do Docker. Se alguém compromete a conta administrativa do painel, pode subir um container com volume do host e acessar arquivos sensíveis. Para reduzir risco, use senhas longas, contas individuais, 2FA quando disponível, restrição por IP e atualização frequente da imagem do Portainer. Também evite compartilhar a conta admin entre várias pessoas. Em times, cada operador deve ter usuário próprio.

Outro cuidado é não guardar segredos soltos em descrições, nomes de stack ou variáveis visíveis para pessoas sem necessidade. Use secrets quando a edição do Compose e o fluxo da aplicação permitirem. Em aplicações simples, no mínimo separe arquivos .env, restrinja permissões no host e limite quem acessa a stack. Portainer melhora a visualização, mas também torna segredos mal organizados mais fáceis de encontrar.

Segurança em produção: firewall, TLS e acesso ao painel

A segurança de uma VPS com Portainer começa fora do Portainer. O host precisa de atualização automática ou rotina semanal de patches, usuário SSH sem login root direto, chave pública no lugar de senha e firewall permitindo apenas o necessário. Um ponto de partida comum é liberar 22 ou uma porta SSH alternativa para IPs confiáveis, 80 e 443 para tráfego web e bloquear o restante. A porta 9443 do Portainer não precisa ficar aberta para o mundo se você usa VPN, túnel, allowlist ou proxy reverso com autenticação adicional.

Não exponha tudo para a internet

Em produção, a pergunta não é apenas se o Portainer usa HTTPS. A pergunta melhor é quem consegue chegar na tela de login. Uma tela administrativa exposta recebe varreduras, tentativas de senha e exploração de falhas recém-divulgadas. Se o acesso for restrito por IP corporativo, WireGuard, Tailscale, Cloudflare Access ou regra de firewall, o risco cai bastante. Para um dev solo, uma VPN simples já resolve boa parte do problema. Para um time, controle centralizado com identidade e logs de acesso fica mais adequado.

TLS precisa ser renovável e previsível. Certificados manuais esquecidos derrubam painel e aplicações no pior momento. Por isso, use automação com Caddy, Traefik, Nginx Proxy Manager ou Certbot. No caso do painel, você pode publicar portainer.seudominio.com.br atrás de proxy reverso e manter a porta interna fechada para acesso público direto. Esse padrão também facilita aplicar cabeçalhos HTTP, compressão e autenticação extra.

Autenticação e permissões

Senha forte não é detalhe. Use gerenciador de senhas e crie credenciais com 20 caracteres ou mais. Ative 2FA se a edição e configuração em uso oferecerem esse recurso. Em Portainer Business, recursos de RBAC e controle por time podem ajudar empresas, mas a disponibilidade depende da edição e licenciamento. Em Portainer Community, organize usuários e permissões com o que estiver disponível e revise acessos periodicamente.

Logs também importam. Guarde registros de autenticação, alterações de stack e eventos do Docker quando possível. Se alguém remove um volume por engano, você precisa saber quando aconteceu e qual era o último backup íntegro. Segurança operacional é isso: impedir acessos indevidos, reduzir impacto de erro humano e conseguir reconstruir a linha do tempo quando algo foge do normal.

Volumes, backups e recuperação de desastre

Docker facilita recriar containers, mas dados persistentes continuam exigindo cuidado. A regra básica é simples: imagem e container são descartáveis, volume não. Em uma VPS com Portainer, os dados importantes normalmente ficam em volumes nomeados, bind mounts ou diretórios montados do host. Isso inclui bancos de dados, uploads de usuários, arquivos gerados pela aplicação, configurações do Portainer e certificados do proxy reverso. Se você não sabe onde esses dados estão, ainda não tem backup confiável.

O que precisa ser persistente

Comece mapeando volumes por stack. Uma aplicação com PostgreSQL pode ter app_db_data, app_uploads e app_redis_data, embora Redis nem sempre precise persistir dependendo do uso. O Portainer usa seu próprio volume, geralmente portainer_data. O proxy reverso pode ter volumes para certificados, configuração dinâmica e logs. Documente o caminho, o tamanho esperado, a frequência de mudança e o método de restauração.

Backups de banco devem ser consistentes. Copiar o diretório de dados do PostgreSQL enquanto ele está em escrita pode gerar backup inútil. Prefira pg_dump para bases pequenas e médias, ou estratégias próprias como base backup e WAL para cenários maiores. Em MySQL ou MariaDB, use mysqldump, mariadb-dump ou ferramenta equivalente conforme volume e janela de manutenção. Para uploads, rsync, restic, borg ou backup incremental para storage externo são escolhas comuns. Teste restauração em outra VPS antes de confiar.

Snapshots ajudam, mas não bastam

Snapshots de VPS são excelentes para voltar rapidamente depois de atualização ruim, alteração de firewall ou deploy que quebrou o sistema. Ainda assim, snapshot não substitui backup granular. Se o banco corrompeu às 10h e o snapshot foi feito às 11h, você preservou o problema. Se um atacante apagou arquivos e o snapshot roda depois, a cópia também pode ficar comprometida. O guia sobre VPS com snapshots para recuperação rápida aprofunda essa diferença entre recuperação do servidor e recuperação dos dados.

Uma rotina razoável para produção pequena combina três camadas: snapshot antes de mudanças grandes, dump diário do banco para storage externo e backup incremental de uploads. Defina retenção, por exemplo 7 cópias diárias, 4 semanais e 3 mensais. Criptografe backups fora da VPS. E faça simulação. Restaurar uma stack em ambiente limpo, com docker compose up -d, volumes recuperados e DNS de teste, revela problemas que nunca aparecem em planilhas.

Proxy reverso com Nginx, Caddy ou Traefik

Portainer administra containers, mas não deve ser a única peça responsável por publicar aplicações na internet. Para isso, use um proxy reverso. Ele recebe tráfego nas portas 80 e 443, decide qual container deve responder por cada domínio e cuida de HTTPS. Nginx, Caddy e Traefik resolvem o problema de formas diferentes. A melhor escolha depende do seu nível de automação, quantidade de serviços e familiaridade da equipe.

Escolhendo a abordagem

Nginx é previsível, muito documentado e excelente para configurações explícitas. Você cria blocos por domínio, aponta para o container interno e controla cabeçalhos, timeouts e limites. Caddy simplifica bastante o HTTPS, porque em muitos casos emite e renova certificados automaticamente com configuração curta. Traefik se integra muito bem a Docker por labels, descobre serviços dinamicamente e combina com times que sobem e removem stacks com frequência. Se você quer comparar os caminhos com exemplos, veja o artigo sobre VPS para reverse proxy com Nginx, Caddy e Traefik.

Em uma VPS pequena, Caddy costuma ser rápido de operar. Um Caddyfile com app.seudominio.com.br apontando para app:3000 resolve muitos casos. Em uma VPS com várias stacks e deploy contínuo, Traefik reduz configuração manual ao usar labels como rota, entrypoint e resolver de certificado. Nginx continua ótimo quando você quer controle fino ou quando a equipe já domina seus arquivos.

Exemplo de roteamento por domínio

Imagine três serviços na mesma VPS: api.seudominio.com.br, painel.seudominio.com.br e portainer.seudominio.com.br. O proxy fica exposto em 80 e 443. A API escuta internamente em 3000. O painel da aplicação escuta em 8080. Portainer escuta internamente em 9443, mas o acesso externo passa pelo proxy e ainda pode ser limitado por IP ou autenticação adicional. O banco de dados não tem porta publicada. Redis também não.

Esse arranjo reduz ruído e melhora manutenção. Certificados ficam concentrados. Logs HTTP têm ponto único. Headers de segurança podem ser padronizados. Quando uma aplicação muda de container, você troca destino interno ou labels, não precisa abrir nova porta pública. Para produção, também configure limites de upload, timeouts adequados e compressão quando fizer sentido. Aplicações com WebSocket, como painéis em tempo real, exigem proxy compatível e teste específico.

Tabela prática de perfis de VPS para Portainer

A escolha da VPS não precisa começar por marca. Comece pelo perfil de uso. Portainer pode administrar desde uma stack simples até dezenas de containers, mas a VPS precisa acompanhar CPU, memória, disco e operação. A tabela abaixo usa perfis técnicos, não preços. Valores de planos, regiões, armazenamento e transferência mudam com frequência em provedores como LetsCloud, DigitalOcean, Vultr, Linode, AWS Lightsail, Hetzner e Contabo, então qualquer comparação comercial precisa de revisão humana e consulta ao site oficial na data de publicação.

Perfil de uso	Configuração sugerida	Serviços típicos	Cuidados principais	Quando escalar
Laboratório controlado	1 a 2 vCPUs, 2 GB RAM, 40 GB SSD	Portainer, proxy simples, 1 app leve	Não usar para dados críticos sem backup externo	Ao passar de 60% de RAM por vários dias
Produção pequena	2 vCPUs, 4 GB RAM, 60 a 80 GB SSD ou NVMe	Portainer, Caddy ou Traefik, API, PostgreSQL, Redis	Backups diários, firewall, TLS, logs e alertas de disco	Ao ter builds locais, workers ou banco acima de 2 GB
Produção moderada	4 vCPUs, 8 GB RAM, 120 GB SSD ou NVMe	Múltiplas stacks, banco maior, filas, automações	Separar redes, monitorar I/O, testar restauração mensal	Ao ter picos de CPU, I/O alto ou muitas stacks
Produção crítica	4 a 8 vCPUs, 16 GB RAM ou mais, disco rápido e backup externo	Apps de receita, APIs públicas, workers, observabilidade	Separar banco, replicar backups, controle de acesso e plano de incidente	Ao exigir alta disponibilidade ou RPO menor que 1 hora

Para muitos projetos, o salto de 2 GB para 4 GB de RAM muda a experiência mais do que trocar de painel. O Docker mantém imagens, containers e redes, o sistema usa cache, o banco cresce e os logs acumulam. Se a VPS começa a usar swap durante horário de tráfego, o painel pode continuar respondendo, mas a aplicação sofre. Monitorar docker stats, df -h, uso de inodes e latência do banco ajuda a decidir antes da queda.

Também faz sentido separar ambientes. Homologação e produção na mesma VPS economizam no começo, mas aumentam risco de conflito de portas, consumo imprevisível e erro humano. Se o orçamento permitir, use uma VPS menor para homologação e outra para produção. Portainer pode administrar endpoints diferentes, mas credenciais, permissões e nomes de stack precisam deixar claro onde cada ação será aplicada.

Recomendações por perfil

Dev solo

Para um desenvolvedor solo, a prioridade é simplicidade com segurança suficiente. Uma VPS de 2 vCPUs, 4 GB de RAM e 60 GB de SSD já atende bem uma API, um banco pequeno, Redis, Portainer e Caddy. Mantenha tudo em Docker Compose versionado em repositório privado, mas não coloque segredos no Git. Use firewall, SSH por chave, atualização automática de segurança e acesso ao Portainer por VPN ou allowlist. Antes de cada mudança grande, faça snapshot. Todo dia, gere dump do banco para storage externo. Esse conjunto evita que um erro de deploy vire madrugada perdida.

Time pequeno

Em um time de 3 a 10 pessoas, o maior risco costuma ser operacional. Alguém reinicia a stack errada, remove volume sem perceber ou aplica variável de ambiente em produção pensando que está em homologação. Use contas individuais no Portainer, permissões por responsabilidade e nomes de stack muito claros, como prod-api, prod-worker e hml-api. Uma VPS de 4 vCPUs e 8 GB de RAM oferece margem para múltiplos serviços, mas backups e logs precisam sair do servidor. Para deploys, prefira pipeline com imagem versionada. Portainer deve operar o ambiente, não virar substituto improvisado para CI/CD.

Produção crítica

Se a aplicação gera receita direta, recebe tráfego constante ou tem dados sensíveis, trate Portainer como parte de uma operação maior. Considere separar banco de dados em serviço próprio ou VPS dedicada, manter backups criptografados fora do provedor principal e definir RPO e RTO. RPO de 24 horas significa aceitar perder até um dia de dados. RPO de 15 minutos exige outra arquitetura. Para esse perfil, 4 a 8 vCPUs, 16 GB de RAM e disco rápido podem ser ponto de partida, mas alta disponibilidade não nasce de uma VPS única. Documente restauração, controle acessos, monitore métricas e teste incidente antes do incidente real.