Como rodar Docker em uma VPS com Portainer (guia 2026)

Você já ouviu falar em Dockerception?

Bem, segure o chapéu. Vamos descer pela toca do coelho.

O Portainer, a interface web que você está prestes a instalar sobre o Docker, é ele próprio um contêiner Docker.

É uma ferramenta que roda na mesma coisa que gerencia. Você o inicia com uma única linha docker run, e a primeira coisa que ele faz é passar por uma pequena abertura no host (um arquivo de socket) e pedir ao daemon do Docker que mostre todos os contêineres da máquina, incluindo ele mesmo. De dentro dessa aba do navegador, você gerencia todos os seus outros contêineres Docker.

A interface que você está olhando aparece na sua própria lista de contêineres.

Em uma VPS pela qual você já paga e em que já se sente à vontade com SSH, o Portainer se encaixa perfeitamente sobre o Docker, sem mudar o funcionamento de nada por baixo.

Esse é o valor.

Uma máquina de 4 GB pode ser um ponto de partida para o Docker e o Portainer, mas são os aplicativos que você adicionar que determinam se essa capacidade é suficiente. Pense em automação residencial, no arquivo de fotos da família, no assistente de IA e na newsletter que você vive ameaçando lançar, tudo em um servidor que é realmente seu.

Veja como colocá-lo para rodar, protegê-lo e começar a tirar proveito dele.

O que é o Portainer, exatamente?

O Portainer é uma interface web que roda como um contêiner Docker e gerencia seus outros contêineres por meio do socket do Docker.

Basicamente, é um frontend no navegador (uma GUI para Docker) para os mesmos comandos Docker que você digitaria à mão, além de gerenciamento de stacks, acesso baseado em funções (se você fizer upgrade para a Business Edition) e um painel com o uso de CPU e memória.

A conexão com o socket é o que faz tudo funcionar. A montagem aparece como -v /var/run/docker.sock:/var/run/docker.sock no comando de instalação, e essa única linha faz todo o trabalho pesado. Sem ela, o Portainer é uma interface para um host Docker vazio. Com ela, o Portainer vira o controle remoto do host Docker.

Uma coisa para ter em mente: qualquer processo que consiga acessar /var/run/docker.sock pode controlar o daemon do Docker, e a documentação de segurança do próprio Docker é direta ao dizer que só usuários confiáveis devem ter essa permissão: um contêiner iniciado pelo daemon pode montar todo o sistema de arquivos do host e alterá-lo sem restrições. Isso é um recurso quando é o Portainer quem pede, e um problema quando é algum contêiner que você subiu na semana passada e esqueceu que tinha acesso ao socket.

Trate a montagem do socket como uma capacidade privilegiada e audite qualquer outro contêiner que a solicite.

Você precisa do Portainer se já tem o Docker?

Não. O Docker funciona muito bem pelo terminal, e muita gente roda alguns contêineres por anos sem nunca instalar uma interface por cima.

Você vai querer o Portainer se:

• Você vai administrar mais de dois ou três contêineres Docker em apps diferentes.
• Você prefere clicar em restart a redigitar um comando do Compose às 23h.
• Você compartilha o acesso com alguém que não vive no terminal.
• Você quer implantar atualizações de stacks a partir de um repositório Git sem escrever um script de implantação.

Dispense o Portainer se:

• Você roda um ou dois contêineres que raramente mudam.
• Você já está à vontade com o Docker Compose e satisfeito em continuar assim.

O Docker em si é popular o bastante para que essa não seja uma decisão de nicho. Na Stack Overflow Developer Survey 2025, 71% dos entrevistados disseram usar o Docker, o primeiro lugar entre as tecnologias de desenvolvimento em nuvem e infraestrutura, após um salto de 17 pontos percentuais em relação a 2024. O projeto Portainer tem mais de 38.000 estrelas no GitHub em agosto de 2026.

Existem outras opções. O Dokploy, por exemplo, tende mais para uma PaaS auto-hospedada completa, cuidando de apps, bancos de dados e SSL para você. O Portainer fica mais perto do Docker puro: os mesmos arquivos Compose, as mesmas imagens, só que com uma interface por cima.

Se você vive no tmux e roda um único app, pode fechar esta aba. Está tudo certo. Se você roda quatro apps auto-hospedados e já pesquisou Como eram os logs do Docker mesmo? duas vezes este mês, continue lendo.

De qual tamanho de VPS você precisa para rodar Docker e Portainer?

O Portainer não publica um mínimo de RAM. Uma VPS de 4 GB pode atender a um stack pequeno, mas dimensione-a com base nos requisitos combinados do sistema operacional, do daemon do Docker e de cada contêiner que você pretende executar.

A própria página de requisitos do Portainer diz surpreendentemente pouco sobre RAM: o Server é distribuído como um contêiner leve, e a orientação de desempenho da documentação trata de armazenamento (mais sobre isso abaixo). A conta real de RAM vem das suas cargas de trabalho: reserve recursos para o sistema operacional, o daemon do Docker e cada contêiner que pretende executar. Reserve disco para logs também: o driver de log padrão do Docker, json-file, não faz rotação de logs, então os logs de um contêiner muito verboso podem consumir bastante disco com o tempo. A documentação de logs do Docker recomenda usar o driver local. Depois de instalar o Docker (passo 2 abaixo), crie o diretório de configuração do Docker, defina o driver de log local e reinicie o Docker: execute sudo install -d -m 0755 /etc/docker, depois printf '%s\n' '{ "log-driver": "local" }' | sudo tee /etc/docker/daemon.json > /dev/null e, por fim, sudo systemctl restart docker. Faça isso antes de implantar apps de longa duração: o driver local faz rotação de logs por padrão, e a mudança só se aplica aos contêineres criados depois dela.

Veja como isso se traduz em cargas de trabalho reais:

A planilha é uma soma simples: verifique o requisito de RAM documentado de cada app que você pretende executar, some o sistema operacional e o daemon do Docker e deixe uma folga para picos de uso. O próprio Portainer não publica um mínimo de RAM, então são os apps, não a interface, que ocupam a máquina.

Na DreamHost, nossa Hospedagem VPS é oferecida em quatro planos Stack baseados em RAM (Stack 4, 8, 16 e 32). O Stack 4, de entrada (2 vCPUs, 4 GB de RAM, 75 GB de SSD NVMe e acesso root completo), é ideal para um host Docker pequeno. No faturamento mensal, ele custa US$ 8,99/mês nos 3 primeiros meses e depois é renovado automaticamente por US$ 15,99/mês (valores de agosto de 2026; o valor total do período mais impostos é cobrado no checkout. Os valores atualizados estão sempre na página de VPS com Docker + Portainer).

Se você está em dúvida se a auto-hospedagem vale o seu tempo, o Stack 4 é o tamanho ideal para começar: grande o suficiente para descobrir, pequeno o suficiente para você não pagar por uma folga que não vai usar. Se a sua planilha ultrapassar esse plano, você pode fazer upgrade, e o seu ambiente vai junto. Mas atenção: no momento, não é possível voltar para um Stack menor, então comece pequeno de propósito.

Uma observação sobre armazenamento: o volume de dados do Portainer guarda o próprio banco de dados e a configuração, além de um clone de cada repositório Git a partir do qual você implanta stacks. A documentação do Portainer avisa que repositórios grandes ou múltiplos podem consumir bastante disco. A orientação de desempenho da documentação trata de armazenamento, não de memória: desempenho de nível SSD (≈3,5 MB/s, 30.000 IOPS ou mais e latência de gravação abaixo de 10 ms) é o que ela considera ideal. O Stack 4 inclui 75 GB de armazenamento SSD NVMe.

Como instalar Docker e Portainer em uma VPS?

São sete passos. O tempo de download e instalação depende da sua VPS e da conexão de rede. Os comandos dos passos 2 a 6 foram escritos para Ubuntu e podem ser colados em ordem em um servidor limpo; o único ponto em que um comando precisa de um valor que só você sabe (seu próprio endereço IP, no passo 4) está indicado no passo. (Quer pular a lista toda? A biblioteca de apps da Hospedagem VPS da DreamHost inclui uma imagem Docker + Portainer com os dois já configurados.)

1. Escolha uma distribuição Linux

Este guia usa o Ubuntu 24.04 LTS. O Docker Engine é compatível com o Ubuntu 22.04, 24.04 e 26.04 LTS (em agosto de 2026). O Ubuntu é uma das opções de sistema operacional pré-instaladas na Hospedagem VPS da DreamHost.

O Debian e as distribuições da família RHEL, como o AlmaLinux, também funcionam, mas têm seus próprios procedimentos de instalação na documentação do Docker, e os comandos abaixo não funcionam do jeito que estão. Um detalhe extra na família RHEL: a documentação de instalação do Portainer pressupõe que o SELinux esteja desativado e orienta passar --privileged ao Docker ao implantar o Portainer, caso você precise do SELinux ativo. Se essa frase não fez sentido para você, use o Ubuntu.

Não sabe qual versão do Ubuntu está usando? Conheça cinco formas de verificar.

2. Instale o Docker a partir do repositório oficial

Não use apt install docker.io e também não instale o Docker via snap: a documentação oficial de instalação do Docker lista o docker.io entre os pacotes não oficiais que devem ser desinstalados antes de instalar o Docker Engine, e a documentação de instalação do Portainer avisa que o pacote snap pode causar problemas de compatibilidade.

Primeiro, remova os pacotes conflitantes. Este é o comando de remoção da documentação de instalação atual do Docker e, em um servidor limpo, ele geralmente não encontra nada para remover. A documentação observa que o apt pode informar que nenhum desses pacotes está instalado:

sudo apt remove $(dpkg --get-selections docker.io docker-compose docker-compose-v2 docker-doc docker-buildx podman-docker containerd runc | cut -f1)

Em seguida, adicione a chave GPG do Docker (cada linha abaixo é um comando separado):

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

Depois, adicione o repositório apt do Docker. Isso grava a definição do repositório em /etc/apt/sources.list.d/docker.sources (o arquivo usado pela documentação de instalação do Docker), com a sua versão do Ubuntu e a arquitetura da CPU preenchidas automaticamente:

sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF
sudo apt update

Por fim, instale o Docker Engine e o plugin Compose de uma só vez:

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

3. Verifique se o Docker está rodando

Execute sudo docker run hello-world.

Se você não receber a mensagem Hello from Docker!, corrija o daemon antes de colocar o Portainer por cima.

4. Integre o UFW ao Docker antes de iniciar o Portainer

Esta é a parte que a maioria dos guias deixa para o final, quando já é tarde demais: quando o Docker publica uma porta, o tráfego para ela é desviado antes de chegar às cadeias que o UFW filtra, então uma porta publicada fica acessível pela internet pública mesmo quando o UFW diz que ela está bloqueada. (A explicação completa está abaixo.) Assim que você iniciar o Portainer, a porta 9443 dele ficará pública, justamente durante a janela de cinco minutos em que quem chegar primeiro pode criar a conta de administrador. Por isso, corrija o firewall primeiro.

Se o UFW ainda não estiver ativo, libere o SSH e ative-o. (Se o seu SSH roda em uma porta personalizada, libere essa porta em vez da 22, ou este será o passo em que você se tranca do lado de fora.)

sudo ufw allow 22/tcp
sudo ufw enable

Depois, instale o chaifeng/ufw-docker, uma ferramenta de terceiros que acrescenta as regras necessárias ao /etc/ufw/after.rules para que o tráfego destinado às portas publicadas do Docker seja filtrado pela cadeia DOCKER-USER. Os comandos abaixo fixam a versão 251123 do projeto (novembro de 2025), em vez de baixar da branch master, que muda constantemente, e usam o curl, que você instalou no passo 2:

sudo curl -fsSL -o /usr/local/bin/ufw-docker \
  https://github.com/chaifeng/ufw-docker/raw/251123/ufw-docker
sudo chmod +x /usr/local/bin/ufw-docker
sudo ufw-docker install
sudo ufw reload

Depois do recarregamento, as portas publicadas dos contêineres passam a ser filtradas pelo UFW. Se a sua política de tráfego roteado nega conexões de entrada e nenhuma regra existente libera a porta, as conexões públicas continuam bloqueadas até que você as libere explicitamente. (O projeto ufw-docker observa que, se as regras não entrarem em vigor após reiniciar o UFW, reiniciar o servidor resolve.)

Agora, pré-autorize o seu próprio acesso à interface do Portainer. Substitua YOUR_HOME_IP pelo IP público a partir do qual você vai navegar:

sudo ufw route allow proto tcp from YOUR_HOME_IP to any port 9443

Com essa regra ativa antes de o Portainer iniciar, o tráfego IPv4 para a interface só é permitido a partir do seu IP — inclusive durante a janela de criação do administrador inicial. Do jeito que está escrita, a regra cobre apenas IPv4. A documentação do ufw-docker diz que a ferramenta também oferece suporte a redes IPv6 e atualiza /etc/ufw/after6.rules quando necessário, mas não aceite isso de olhos fechados: se a sua VPS responde em um endereço IPv6 público, execute também via IPv6 o teste de fora para dentro da seção sobre firewall antes de confiar nela. A contrapartida: a maioria das conexões residenciais muda de IP de vez em quando, então talvez você precise atualizar a regra depois. Se isso incomodar você, a solução mais limpa a longo prazo é colocar uma VPN na frente da interface (abordada na seção de proteção).

5. Crie um volume persistente para os dados do Portainer

Em seguida, execute sudo docker volume create portainer_data.

Manter o banco de dados do Portainer em um volume do Docker (e não dentro do contêiner) significa que uma atualização do Portainer não vai apagar sua configuração.

6. Execute o Portainer Community Edition

Este é o comando do documento de instalação para Linux do Portainer, com uma flag a menos: a versão oficial também publica a porta 8000, um túnel TCP que só é necessário se, mais tarde, você conectar ambientes remotos via Edge Agents. Uma instalação em um único host não precisa dela, então a deixamos de fora:

sudo docker run -d \
  -p 9443:9443 \
  --name portainer \
  --restart=always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v portainer_data:/data \
  portainer/portainer-ce:lts

Vamos analisar linha por linha:

• -d executa o contêiner em segundo plano (modo detached).
• -p 9443:9443 é a interface web do Portainer em HTTPS — a porta que você liberou para o seu IP no passo 4.
• --restart=always traz o Portainer de volta depois de uma reinicialização.
• As flags -v são o bind do socket e o volume persistente do passo 5.
• :lts fixa você na linha de versões Long Term Support do Portainer — a tag usada no próprio documento de instalação do Portainer.

7. Abra a interface e crie sua conta de administrador

Acesse https://YOUR_VPS_IP:9443 no navegador (a partir do endereço IP que você liberou no passo 4).

Avance pelo aviso de certificado autoassinado. Você vai cair na tela create the initial administrator user. Escolha um nome de usuário que não seja admin, defina uma senha forte e guarde-a em um lugar seguro de verdade. E… pronto, você entrou!

Por que o Portainer acabou de expirar?

Porque o Portainer espera exatamente cinco minutos para que alguém o reivindique na primeira instalação. Se ninguém fizer isso, ele tranca a porta.

Palavra por palavra, das perguntas frequentes do próprio Portainer:

As a security precaution, when Portainer is first installed it will wait for 5 minutes for an administrator user to be created (part of the initial setup). If a user is not created within those 5 minutes, the Portainer Server will stop listening for requests.

Tradução: se você passou o passo 6 fazendo um sanduíche, sua instalação agora se recusa a falar com você — e você não fez nada de errado.

A solução é simples. Execute sudo docker restart portainer.

Isso reinicia o contêiner, dá a você mais uma janela de cinco minutos e leva você direto para a tela de criação do administrador. Repita quantas vezes precisar. Bem-vindo à auto-hospedagem.

Se você está automatizando a instalação para vários servidores (Ansible, Terraform, um pipeline de deploy), o Portainer aceita a flag --admin-password-file, que cria o usuário administrador a partir de um arquivo quando o contêiner inicia pela primeira vez — assim, não há tela de criação de administrador para correr contra o relógio. O documento de configuração da CLI do Portainer explica a sintaxe. Para uma instalação avulsa em uma VPS, o truque de reiniciar resolve.

Como impedir que o Docker contorne seu firewall?

Você já fez isso, no passo 4. Veja o que realmente aconteceu, como abrir portas de propósito e como provar que funcionou.

O problema: quando você publica a porta de um contêiner com -p 80:80, essa porta fica acessível pela internet pública mesmo que ufw status mostre a porta 80 como negada. Segundo a documentação de filtragem de pacotes do Docker, Docker routes container traffic in the nat table, which means that packets are diverted before it reaches the INPUT and OUTPUT chains that ufw uses.

O UFW não está quebrado. Ele só está parado no corredor errado.

A solução que o próprio Docker indica é a chain DOCKER-USER do iptables — uma chain que o Docker cria especificamente para regras definidas pelo usuário, processada antes das regras das chains do próprio Docker. O script ufw-docker que você instalou no passo 4 conecta o UFW a essa chain adicionando um bloco de regras (entre os marcadores # BEGIN UFW AND DOCKER e # END UFW AND DOCKER) ao arquivo /etc/ufw/after.rules, para que ele seja carregado junto com o restante da sua configuração do UFW.

Para abrir de propósito uma porta de contêiner ao público — digamos, um app web na porta 80 do contêiner —, use uma regra de rota:

sudo ufw route allow proto tcp from any to any port 80

Uma armadilha que a documentação do ufw-docker destaca: a regra usa a porta do contêiner, não a porta do host. Se você publicou com -p 8080:80, a regra acima (porta 80) é a correta, não a porta 8080.

Para verificar de fora, teste a partir de uma rede que não esteja na sua lista de permissões — o roteador do seu celular funciona. O comando deve expirar em vez de retornar a página de login do Portainer:

curl -k --max-time 5 https://YOUR_VPS_IP:9443

# For IPv6, enclose the address in square brackets:
curl -k --max-time 5 'https://[YOUR_VPS_IPV6]:9443'

Execute o mesmo comando a partir do IP que você liberou no passo 4 e você deve receber HTML de volta. O UFW dizer denied é uma alegação; um tempo esgotado vindo de uma rede desconhecida é uma prova.

Para desfazer tudo, execute sudo ufw-docker uninstall, que, segundo a documentação do projeto, restaura sua configuração do UFW e apaga os arquivos que instalou, e depois sudo ufw reload. Você também pode remover manualmente o bloco entre os marcadores # BEGIN UFW AND DOCKER e # END UFW AND DOCKER em /etc/ufw/after.rules e recarregar o UFW.

Essa pega até engenheiros experientes, tanto em máquinas pessoais quanto em servidores de produção: o UFW diz uma coisa, a internet pública diz outra, e a verdade está no iptables. Se você prefere que o Portainer nunca tenha uma porta pública, coloque-o atrás de um túnel VPN como o WireGuard.

O que você deve proteger logo após o primeiro login?

Você entrou. Cinco coisas que valem a pena fazer antes de fechar essa aba do navegador — as quatro primeiras vêm direto do guia de segurança do próprio Portainer:

• Ative o Force HTTPS only. A instalação deste guia publica apenas a porta 9443, então, para começo de conversa, nenhuma porta HTTP fica exposta. Ativar a opção Force HTTPS only em Settings → SSL Certificate garante isso: segundo a documentação de configurações do Portainer, ela desativa totalmente a escuta na porta HTTP legada (9000), então uma futura reimplantação que adicione -p 9000:9000 não consegue reabrir um caminho sem criptografia.
• Substitua o certificado autoassinado. Envie um certificado que você gerou ou coloque o Portainer atrás de um proxy reverso NGINX com um certificado Let’s Encrypt. Passado o primeiro dia, clicar no aviso do navegador toda vez é um hábito do qual você vai se arrepender.
• Use um nome de usuário de administrador de verdade. Usar o nome de usuário padrão admin deixa o invasor com uma credencial a menos para descobrir. Escolha algo específico seu.
• Restrinja a interface a uma VPN. Executar o Portainer atrás de uma VPN WireGuard é o padrão indicado pelo guia de segurança do Portainer. Uma porta 9443 restrita ao seu IP de origem (passo 4) é bom. Uma porta 9443 acessível apenas em uma rede privada é melhor.
• Audite o bind do socket do Docker. Qualquer coisa com acesso a /var/run/docker.sock controla o daemon do Docker e, por meio dele, o host. Não monte o socket em outros contêineres sem pensar. Cada bind adicional é um novo caminho até o host. Se um contêiner diz que precisa do socket, pergunte por quê — e considere um proxy de socket se a resposta for para monitoramento.

Como usar o Portainer no dia a dia?

A recompensa por instalar o Portainer chega no dia em que você para de entrar via SSH para reiniciar um contêiner problemático e passa a simplesmente clicar em um botão. A recompensa maior é o gerenciamento de stacks.

Uma stack do Portainer é um app com vários contêineres definido por um arquivo Docker Compose. O Portainer pode implantar configurações compatíveis do Docker Compose como stacks por quatro caminhos listados na documentação oficial de stacks:

• Cole o Compose no editor web
• Envie um arquivo Compose
• Aponte o Portainer para um repositório Git
• Implante a partir de um template personalizado

O caminho via Git é o que importa. Você aponta o Portainer para um repositório público ou autenticado e um caminho até docker-compose.yml e, em seguida, ativa as atualizações GitOps. O Portainer consulta o repositório no intervalo que você definir ou fornece uma URL de webhook para você adicionar ao seu host Git (acionada por uma GitHub Action, por exemplo). Quando o arquivo Compose muda no repositório, o Portainer baixa as alterações e reimplanta tudo automaticamente. E sim, isso funciona na Community Edition — na página de documentação de stacks, apenas a opção de volumes com caminho relativo traz a marcação de Business Edition.

Essa é a versão auto-hospedada do deploy a cada push, sem pagar uma PaaS pelo privilégio.

As pequenas vitórias do dia a dia também fazem diferença. Pense em ver os logs em um painel em vez de acompanhá-los pela linha de comando, reiniciar com um clique, recriar uma stack com um botão e ver gráficos de recursos que você confere em três segundos em vez de rodar o Docker stats.

Se mais tarde você adicionar hosts remotos via Edge Agents, a porta 8000 volta ao jogo — as perguntas frequentes abaixo explicam a reimplantação e a regra de firewall.

Como fazer backup do Portainer e dos seus contêineres?

Um volume é persistência, não backup. O volume portainer_data do passo 5 sobrevive às atualizações do contêiner, mas fica no mesmo disco que todo o resto — então um plano de backup de verdade tem três partes, e todas as três saem da VPS.

1. A configuração do próprio Portainer. Na interface, vá em Settings → Back up Portainer, mantenha a opção padrão Download backup file e clique em Download backup. Segundo a documentação de configurações do Portainer, isso baixa um tar.gz com tudo o que o Portainer armazena no volume /data, opcionalmente criptografado com senha, e esse arquivo é tudo de que você precisa para restaurar o Portainer. A documentação é igualmente clara quanto ao escopo: o recurso faz backup apenas da configuração do Portainer, não dos contêineres, stacks ou volumes que você implantou. (Backups agendados para S3 existem, mas só na Business Edition — na CE, coloque um lembrete recorrente na sua agenda.)

2. Os dados dos seus aplicativos. A documentação de volumes do Docker diz que os volumes nomeados são a forma preferida de persistir dados de contêineres, além de serem mais fáceis de copiar ou migrar do que bind mounts. Uma montagem somente leitura só impede que o contêiner de backup grave dados — o próprio app ainda pode gravar no volume no meio do arquivamento e entregar a você uma cópia inconsistente. Por isso, pare primeiro o contêiner do app (sudo docker stop myapp) ou use o mecanismo de backup oficial do próprio app. Depois, monte o volume como somente leitura em um contêiner descartável, compacte tudo com tar e inicie o app de novo em seguida (troque pelos seus próprios nomes):

sudo docker run --rm \
  -v myapp_data:/source:ro \
  -v "$PWD":/backup \
  alpine tar czf /backup/myapp_data.tgz -C /source .

Para bancos de dados, prefira a ferramenta de dump do próprio banco (pg_dump, mysqldump) em vez de copiar arquivos de dados em uso, para não arquivar um arquivo no meio de uma gravação. Depois, envie os arquivos para fora da máquina em intervalos regulares — com rsync ou scp para outra máquina, ou para um armazenamento de objetos. Um backup que fica no mesmo disco que ele protege desaparece junto com esse disco.

3. Seus arquivos Compose e segredos. Se você implanta stacks a partir do Git, os arquivos Compose já estão fora do host. O que o Git não guarda é tudo aquilo que você nunca enviou em um commit: arquivos .env, chaves de API e senhas que você informou na hora da implantação. Diretórios com bind mount também ficam fora do backup de volumes acima. Faça um inventário deles separadamente e guarde backups criptografados.

Depois, teste a restauração antes de precisar dela. A documentação do Portainer diz que a restauração da configuração só funciona em uma instância nova: implante um novo contêiner do Portainer com um volume de dados vazio (uma VPS descartável ou seu notebook servem), escolha Restore Portainer from backup durante a configuração inicial e confirme que você consegue entrar com suas credenciais antigas e ver as definições das suas stacks. Esse teste cobre apenas a parte 1 — a configuração do Portainer. As partes 2 e 3 precisam de testes próprios, app por app: restaure um arquivo em um volume novo, inicie o app com ele e verifique se os dados estão mesmo lá. Um backup não testado é só uma esperança com nome de arquivo.

Quanto custa o Portainer? (E quando o gratuito deixa de ser gratuito?)

O Portainer é gratuito em dobro. A Community Edition é gratuita e de código aberto (licença zlib), sem exigir chave de licença. E a Portainer Business Edition é gratuita para sempre para até 3 nós: todos os recursos Business, sem limite de tempo e sem cartão de crédito. Em vez de pagar, você se cadastra para obter uma chave de licença gratuita.

Preços da página de preços do Portainer em agosto de 2026; os planos Starter e Scale exigem compromisso anual.

Então, qual escolher? Para uma única VPS com um só administrador, a Community Edition: ela é open source, não exige cadastro e faz tudo o que está neste guia, inclusive deploys via Git. Se você quer controle de acesso baseado em funções (RBAC) para um segundo usuário, ou já roda dois ou três servidores, escolha o plano Business gratuito para 3 nós: é o mesmo software com os recursos Business liberados, gratuito enquanto você ficar em três nós ou menos. Os planos pagos só fazem sentido quando você gerencia uma quantidade considerável de nós com uma equipe. E confira o tipo de suporte antes de presumir que pago significa com suporte: em agosto de 2026, a página de preços do Portainer lista suporte da comunidade no plano Starter, suporte 9×5 com resposta no próximo dia útil a partir do plano Scale e suporte prioritário no Enterprise.

Você deve adicionar o Portainer ou dispensá-lo?

Aqui vai a resposta honesta, em duas frases:

✅ Se você vai compartilhar este servidor, fazer deploy a partir do Git ou rodar mais de três contêineres daqui a um ano, instale o Portainer enquanto o servidor ainda está novo e seus hábitos ainda estão se formando em torno dele.

❌ Se você roda um único app tranquilo e está feliz no terminal, não vai sentir falta da interface que não instalou.

A verdadeira questão não é ter ou não ter o Portainer. É saber se auto-hospedar é a escolha certa para você, e você já respondeu isso quando abriu esta aba.

Uma VPS de 4 GB, o Docker e o Portainer CE bastam para começar a auto-hospedar de verdade: escolha seus apps, some os requisitos documentados de cada um e deixe a planilha (não a lista de desejos) decidir quando o servidor precisa crescer.

Nada mal, né?

Perguntas frequentes sobre Docker e Portainer