Se você se encaixa em alguma das situações abaixo, o Portainer será muito útil:

• O Docker já está instalado na VPS e há vários contêineres em execução de longo prazo.
• Você precisa com frequência ver logs de contêineres, reiniciar serviços e verificar variáveis de ambiente e mapeamentos de portas.
• Você usa Docker Compose, mas não quer entrar por SSH no servidor toda vez para verificar o status.
• Você quer dar a colegas sem perfil de operações um ponto de entrada visual relativamente seguro.
• Você tem várias VPSs e precisa ver vários ambientes Docker de forma centralizada.

Se sua VPS roda apenas um WordPress e você quase nunca mexe nos contêineres, o Portainer não é obrigatório. Ele é indicado para a fase em que "os contêineres já se multiplicaram e o gerenciamento pela linha de comando começa a ficar bagunçado".

O Portainer pode:

• Ver o status de execução dos contêineres, imagens, redes e Volumes.
• Iniciar, parar e reiniciar contêineres.
• Ver logs em tempo real e o console do contêiner.
• Criar e gerenciar Stacks do Docker Compose.
• Gerenciar variáveis de ambiente, mapeamentos de portas e diretórios montados.
• Conectar-se ao Docker local ou a ambientes Docker remotos.

O Portainer não pode fazer por você:

• Corrigir automaticamente arquivos Compose com erro.
• Substituir sistemas de backup, monitoramento e alerta.
• Substituir o firewall do Linux, a segurança do SSH e as atualizações do sistema.
• Garantir que a própria aplicação não tenha vulnerabilidades de segurança.
• Gerenciar migrações de banco de dados e recuperação de dados que você não entende.

Em resumo, o Portainer é um ponto de entrada de gerenciamento do Docker, não uma solução de segurança para a VPS, nem todo o processo de publicação em produção.

Antes de começar, recomenda-se preparar:

1. Uma VPS com Ubuntu 22.04 / 24.04 ou Debian 12.
2. Docker Engine já instalado.
3. Um usuário sudo comum.
4. O firewall do servidor ativado.
5. Opcional: um domínio, por exemplo portainer.example.com.

Confirme que o Docker está disponível:

docker version
docker ps

Se indicar permissões insuficientes, você pode usar primeiro:

sudo docker ps

Não é recomendado adicionar todos os usuários ao grupo docker só por conveniência. Adicionar um usuário ao grupo docker equivale basicamente a dar a ele capacidades de nível root, porque ele pode montar diretórios do host, controlar contêineres e acessar o socket do Docker.

O Portainer recomenda oficialmente usar um volume do Docker para armazenar os dados. Primeiro crie o volume de dados:

sudo docker volume create portainer_data

Depois inicie o Portainer CE:

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:latest

Os parâmetros-chave aqui são:

• -p 9443:9443: expõe a porta de gerenciamento HTTPS integrada do Portainer.
• --restart=always: restaura automaticamente após reiniciar o servidor.
• /var/run/docker.sock:/var/run/docker.sock: permite que o Portainer gerencie o Docker local.
• portainer_data:/data: armazena a configuração, os usuários e as informações de ambiente do Portainer.

Verifique o status do contêiner:

sudo docker ps --filter name=portainer

Veja os logs de inicialização:

sudo docker logs --tail=100 portainer

Acesse no navegador:

https://你的服务器IP:9443

No primeiro acesso, o navegador pode avisar que o certificado não é emitido por uma CA pública; isso acontece porque o Portainer usa um certificado autoassinado por padrão. Se você está apenas fazendo uma inicialização temporária, pode continuar por enquanto; para uso formal, recomenda-se resolver isso depois com um domínio e proxy reverso.

Durante a inicialização, é preciso fazer três coisas:

1. Criar a conta de administrador.
2. Definir uma senha forte.
3. Selecionar o ambiente Docker local.

Não reutilize a senha do SSH, do e-mail ou do provedor de nuvem para a senha do administrador. O Portainer pode controlar o Docker e tem privilégios muito altos; uma vez comprometido, um atacante consegue facilmente controlar o host.

A forma mais simples é abrir 9443 diretamente, mas essa não é a solução mais robusta a longo prazo.

Se for apenas para uso pessoal temporário, você pode restringir o firewall assim:

sudo ufw allow from 你的固定IP to any port 9443 proto tcp

Se você não tem IP fixo, é mais recomendado:

• Usar Caddy/Nginx como proxy reverso para o Portainer.
• Acessar por trás do Cloudflare, Tailscale, WireGuard ou Zero Trust.
• No mínimo, não exponha o Portainer como um ponto de entrada público sem proteção.

Se você usa UFW, primeiro confirme que o SSH não será bloqueado:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status

Depois, não abra todas as portas de gerenciamento de qualquer jeito.

Suponha que você já tenha o Caddy e o domínio seja portainer.example.com. Você pode vincular o Portainer apenas a uma porta local:

Primeiro remova o contêiner antigo:

sudo docker stop portainer
sudo docker rm portainer

Reinicie, escutando apenas na máquina local:

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

Exemplo de Caddyfile:

portainer.example.com {
    reverse_proxy https://127.0.0.1:9443 {
        transport http {
            tls_insecure_skip_verify
        }
    }
}

Aqui se usa tls_insecure_skip_verify porque o Portainer de origem usa um certificado autoassinado. Os usuários públicos acessam o HTTPS formal fornecido pelo Caddy, e a conexão do Caddy com o Portainer local ocorre apenas no endereço de loopback local.

Após modificar, execute:

sudo caddy fmt --overwrite /etc/caddy/Caddyfile
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

Assim, externamente você só precisa acessar https://portainer.example.com em vez de acessar diretamente https://IP:9443.

O Portainer é ótimo para observação diária e operações leves:

• Ver se um contêiner está Running.
• Reiniciar um contêiner travado.
• Ver as últimas 1000 linhas de log.
• Confirmar tags de imagem, mapeamentos de portas e diretórios montados.
• Entrar temporariamente no console do contêiner para solucionar problemas.
• Excluir contêineres de teste já parados.

Mas não trate o Portainer como o único método de publicação. Para ambientes de produção, é mais recomendado:

• Manter os arquivos Compose em um repositório Git.
• Gerenciar variáveis de ambiente importantes com .env ou Secrets.
• Validar localmente ou em um ambiente de teste antes de publicar.
• Atualizar via Git, CI/CD ou um processo de mudança claro.

O Portainer permite "ver" e "operar", mas a origem da configuração idealmente ainda deve ser rastreável.

Os Stacks no Portainer correspondem a projetos Docker Compose. Você pode colar o conteúdo do Compose na interface web ou usar um arquivo Compose de um repositório Git.

Um exemplo simples de Compose:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - uptime_kuma:/app/data

volumes:
  uptime_kuma:

Este exemplo tem dois pontos importantes:

1. A porta é vinculada a 127.0.0.1, evitando expor a porta da aplicação diretamente à internet pública.
2. Os dados ficam em um volume do Docker, então não se perdem ao atualizar o contêiner.

Se você já gerencia serviços com Compose na linha de comando, não é recomendado entregar o mesmo projeto ao mesmo tempo ao Portainer e à linha de comando e ficar alterando repetidamente. É melhor definir um único ponto de entrada principal: ou Git + Compose é a referência e o Portainer apenas observa, ou o Stack é gerenciado pelo Portainer.

O Portainer consegue ver os volumes do Docker, mas não é uma ferramenta de backup.

O erro comum é: ver um volume no Portainer e achar que os dados estão seguros. Na realidade, o volume continua no disco desta VPS. Se o disco falhar, o volume for excluído por engano ou o sistema for reinstalado, os dados ainda podem ser perdidos.

Recomendações:

• Faça backup dos bancos de dados com o método recomendado pela aplicação, por exemplo PostgreSQL com pg_dump.
• Sincronize periodicamente dados do tipo arquivo para armazenamento de objetos ou outra máquina.
• Arquive periodicamente volumes do Docker importantes.
• Faça simulações de recuperação após o backup; não apenas verifique se o arquivo de backup existe.

Você pode ver os volumes pela linha de comando:

sudo docker volume ls
sudo docker volume inspect portainer_data

A interface do Portainer é boa para visualizar e auxiliar no gerenciamento, mas a estratégia de backup ainda precisa ser projetada separadamente.

A página Logs do Portainer é boa para ver rapidamente a saída dos contêineres. Passos comuns de diagnóstico:

1. Primeiro verifique se o status do contêiner é Running.
2. Se estiver em Restarting, veja o código de saída e os logs recentes.
3. Se a aplicação não abrir, verifique o mapeamento de portas e a configuração do proxy reverso.
4. Se houver perda de dados, verifique se o caminho de montagem do volume mudou.
5. Se falhar após uma atualização, revise a tag da imagem e as variáveis de ambiente.

Mantenha também a linha de comando:

sudo docker ps -a
sudo docker logs --tail=200 容器名
sudo docker inspect 容器名

Quando a própria página do Portainer não abre, a linha de comando é o último ponto de resgate.

O processo básico para atualizar o Portainer CE é:

sudo docker pull portainer/portainer-ce:latest
sudo docker stop portainer
sudo docker rm portainer
sudo docker run -d \
  -p 127.0.0.1:9443:9443 \
  --name portainer \
  --restart=always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v portainer_data:/data \
  portainer/portainer-ce:latest

Como os dados estão no volume portainer_data, excluir o contêiner não exclui a configuração. Mas ainda assim recomenda-se fazer backup antes de atualizar:

sudo docker run --rm \
  -v portainer_data:/data \
  -v "$PWD":/backup \
  alpine tar czf /backup/portainer_data_backup.tar.gz -C /data .

Se você não gosta de latest, pode fixar uma tag de versão para reduzir o risco de atualizações inesperadas. Em ambientes de produção, é mais recomendado fixar a versão e atualizar após confirmar em testes.

Para uma única VPS, prefiro esta estrutura:

公网用户
   ↓
Caddy / Nginx :443
   ↓
127.0.0.1:9443
   ↓
Portainer
   ↓
/var/run/docker.sock
   ↓
本机 Docker Engine

Os contêineres de aplicação também devem ser vinculados a portas locais sempre que possível, e depois expostos à internet pública pelo Caddy/Nginx:

app.example.com -> Caddy -> 127.0.0.1:3000
portainer.example.com -> Caddy -> 127.0.0.1:9443

Isso reduz a superfície de exposição pública e concentra todos os pontos de entrada nas portas 80/443.

O Portainer não é um substituto do Docker, mas um complemento à experiência de gerenciamento do Docker. Para uma única VPS, seu valor mais importante é: poder ver contêineres, logs, Volumes, Stacks e status de execução sem entrar por SSH toda vez.

Mas seus privilégios são altos, então ele não pode ser exposto à internet pública de qualquer jeito. A abordagem correta é: usar um volume do Docker para armazenar os dados do Portainer, inicializar a conta de administrador com uma senha forte, restringir a 9443 à máquina local ou a fontes confiáveis e, em seguida, acessar por Caddy/Nginx, VPN, Zero Trust etc.

Se sua VPS já executa vários serviços Docker, o Portainer pode reduzir bastante o custo de manutenção diária; se você tem apenas um contêiner simples, ele não é obrigatório, mas como ferramenta visual para aprender sobre o status do Docker, redes e Volumes, vale muito a pena instalar uma vez.