Portainer muda de rumo: será que já é preciso procurar uma alternativa para gerenciar seus contêineres Docker?

O Portainer já faz quase parte da mobília em muitos home labs. Instalamo-lo num NAS, num Raspberry Pi, num mini PC ou numa VM Proxmox e, cinco minutos depois, temos uma interface Web para iniciar, parar, atualizar e monitorizar os nossos contentores Docker.

Em domótica, é muito prático. O Home Assistant funciona muito bem num contentor e, à sua volta, encontramos frequentemente Mosquitto, Zigbee2MQTT, Node-RED, ESPHome, Frigate, InfluxDB, Grafana, AdGuard Home, Nginx Proxy Manager… A lista cresce rapidamente.

A 11 de setembro de 2026, o Portainer anunciou uma mudança de rumo: a versão 3.0 será pensada primeiro para Kubernetes, e a Community Edition permanecerá na ramificação 2.x.

É preciso desinstalar o Portainer amanhã de manhã? Não. Mas este é o momento certo para ver o que está a crescer no jardim do vizinho.

Portainer 3.0: rumo ao Kubernetes

Foi Neil Cresswell, CEO do Portainer, quem detalhou a nova estratégia numa publicação no blogue. E não estamos a falar de uma simples mudança no número da versão.

O Portainer 2.45 LTS, lançado em agosto, é a última versão da ramificação 2.x. A 3.x será desenvolvida com uma prioridade: Kubernetes.

O editor explica a situação de forma bastante franca. A distância entre Docker e Kubernetes aumentou tanto que já não é viável desenvolver tudo em paralelo para Docker, Podman, Swarm e Kubernetes numa mesma base de código. Os clientes empresariais pedem políticas de segurança, observabilidade, GitOps, soluções para executar workloads de IA… Tudo isso depende de mecanismos próprios do Kubernetes (network policies, admission controllers) que o Docker não tem.

Há vários produtos a ser preparados em torno deste ecossistema: Portainer-Run, Portainer-IDP, Portainer-Command, Portainer-Operations e ainda Portainer-AiGrid. Só os nomes já dão o tom.

Quando só queremos executar o Zigbee2MQTT e um punhado de serviços num mini PC, estamos bastante longe da necessidade inicial.

O Portainer CE não morreu, apesar de tudo

Alguns títulos publicados após o anúncio eram francamente alarmistas, por isso vamos esclarecer as coisas: o Portainer não está a abandonar o Docker nem a desligar a Community Edition de um dia para o outro.

A CE permanece na ramificação 2.x e continuará a receber correções de segurança e de erros. O Portainer também promete retroportar para esta versão as novidades da 3.x que tenham um equivalente na API do Docker. O Portainer 2.45 LTS tem manutenção garantida até maio de 2027.

Se o seu servidor funciona bem hoje com o Portainer CE, não há pressa.

Por outro lado, não haverá Portainer CE 3.0. Para usufruir gratuitamente da versão 3.x, será necessário recorrer ao programa «3 Nodes Free», ou seja, à edição Business gratuita até três nós. Os ambientes Docker, Swarm e Podman continuarão a ser geridos, mas passarão para segundo plano na interface, e as novas funcionalidades chegarão primeiro, ou até exclusivamente, ao Kubernetes.

Hoje, a diferença parece pequena. Daqui a dois ou três anos, acho que será muito mais visível.

Porque é que isto diz respeito à domótica

Para um home lab, o Kubernetes é, na maioria das vezes, excessivo.

Pense num servidor convencional com Home Assistant, Mosquitto, Zigbee2MQTT, Node-RED, Frigate e duas ou três ferramentas de monitorização. O Docker Compose dá conta do recado: um ficheiro por aplicação, os dados em volumes e alguns comandos para fazer uma cópia de segurança de tudo ou reconstruir tudo.

Montar um cluster Kubernetes só para manter as últimas funcionalidades de uma interface de administração é um pouco como usar uma escavadora para plantar três tulipas.

Aliás, o Portainer reconhece isso: o Docker continuará a ser suportado na versão 3.x, mas o esforço de desenvolvimento será direcionado para o Kubernetes. Se não tem qualquer intenção de fazer essa mudança, coloca-se a questão: existem interfaces pensadas primeiro para Docker e Docker Compose?

Sim. E várias evoluíram bastante nos últimos meses.

Arcane: provavelmente, a alternativa mais convincente neste momento

Se só pudesse experimentar um em 2026, seria este.

O Arcane parece-se com aquilo que esperaríamos de um Portainer moderno: contentores, imagens, volumes, redes e projetos Docker Compose numa interface Web, além da gestão de máquinas remotas através de um agente.

Em termos de autenticação, temos OIDC, passkeys e autenticação de dois fatores. Também há uma API, gestão de atualizações de imagens e um scanner de vulnerabilidades que apresenta os riscos associados a cada imagem.

E está a evoluir rapidamente. As versões 2.10 a 2.14 foram lançadas em menos de um mês. A versão 2.14.0 data de 26 de setembro de 2026, poucos dias antes de eu escrever estas linhas. Acrescenta ações em lote sobre vulnerabilidades, uma vista de riscos de segurança reformulada e um separador que apresenta os processos de cada contentor.

A instalação é simples: o próprio Arcane é executado num contentor e acede ao socket Docker do anfitrião. Tal como no Portainer, tenha em mente que o acesso ao socket equivale a conceder direitos de root na máquina. Por isso, evite expor a interface na Internet sem tomar precauções.

Se tivesse de substituir o Portainer amanhã no meu home lab, seria o primeiro que instalaria.

Dockge: simplicidade acima de tudo

O Dockge é o outro nome que aparece constantemente nas conversas.

Foi criado por Louis Lam, o programador do Uptime Kuma, e tem uma filosofia diferente. Não tenta recriar todo o Portainer: concentra-se no Docker Compose. É possível criar, editar, iniciar, parar e atualizar stacks a partir de uma interface muito simples.

O que mais aprecio é que os ficheiros compose.yaml continuam a ser ficheiros a sério no disco (por predefinição, em /opt/stacks), em vez de registos numa base de dados interna. Podemos abri-los com qualquer editor ou executar o bom e velho docker compose up -d no terminal.

Desde a versão 1.4, também consegue ligar-se a outras instâncias do Dockge para apresentar as stacks de várias máquinas na mesma interface.

Num Raspberry Pi ou mini PC que execute uma dezena de serviços de domótica, é realmente muito agradável.

A desvantagem é o ritmo de desenvolvimento. A última versão estável, a 1.5.0, data de março de 2025. Isso não a impede de funcionar, mas, para uma nova instalação que pretendo manter durante vários anos, hesitaria em escolhê-la como primeira opção.

Komodo: quando o home lab tem vários servidores

Se o seu home lab cresceu bastante, vale a pena conhecer o Komodo.

Foi concebido para implementar e gerir vários servidores. É um projeto de código aberto sob a licença GPLv3, sem limite para o número de máquinas ligadas.

Gere Docker Compose, sabe importar stacks existentes e obter configurações a partir de um repositório Git. Assim, pode descrever uma stack no Git, implementá-la automaticamente num servidor e voltar a implementá-la sempre que o repositório for alterado. E, se preferir manter os ficheiros Compose diretamente na máquina, à moda antiga, isso também é possível.

O Komodo 2 acrescentou a gestão do Docker Swarm, autenticação de dois fatores (TOTP ou passkey) para contas locais, a possibilidade de associar vários métodos de início de sessão (local, OIDC, GitHub…) à mesma conta e terminais remotos renovados. Em termos de automatização, já oferecia bastante.

Um exemplo concreto: um mini PC para a domótica, um segundo servidor para o Frigate e as câmaras, um NAS com alguns serviços e um VPS no exterior. O Komodo centraliza tudo.

É mais demorado de aprender a utilizar do que o Dockge, naturalmente. Mas também é muito mais poderoso.

Dockhand: a novidade a acompanhar

O último da lista é o Dockhand. A sua primeira versão data de dezembro de 2025, e está a evoluir a uma velocidade impressionante.

Gere contentores, stacks Compose, vários ambientes Docker, repositórios Git e webhooks. Também é possível explorar volumes e ficheiros dentro dos contentores, visualizar ligações de rede ou agendar operações de manutenção.

Destaca-se sobretudo pela segurança, com funcionalidades que raramente se encontram numa ferramenta de self-hosting. Analisa imagens com o Grype e o Trivy para detetar vulnerabilidades conhecidas e pode analisar uma nova imagem antes de substituir um contentor em execução. É útil para evitar que uma atualização automática instale, a meio da noite, uma imagem repleta de vulnerabilidades conhecidas.

A versão 1.0.50 foi lançada a 30 de setembro de 2026.

Atenção à licença, no entanto. O Dockhand está abrangido pela Business Source License 1.1: é gratuito para uso pessoal ou interno numa empresa, mas não é software livre no sentido de um projeto GPL ou MIT. Por exemplo, não é possível revendê-lo como serviço alojado. O código passará para a licença Apache 2.0 em 2029.

Então, é preciso deixar o Portainer?

Não necessariamente.

Se tem o Portainer CE 2.45 num servidor Docker em casa e tudo está a funcionar, não vejo qualquer razão para alterar tudo. A ramificação continua a ser mantida e as correções continuarão a chegar.

Mas o anúncio mudou a forma como encaro a ferramenta a longo prazo. O Portainer escolheu o seu caminho: Kubernetes e empresas. Compreendo perfeitamente essa decisão do ponto de vista do editor. Simplesmente, não é o caminho de quem tem um mini PC e vinte contentores no armário técnico.

Para esse perfil, esta é a minha opinião:

• Hoje, o Arcane é o que mais se aproxima de um Portainer moderno e desenvolvido ativamente;
• O Dockge continua a ser excelente se quiser uma interface minimalista em torno do Docker Compose e não se importar com a desaceleração do desenvolvimento;
• O Komodo faz todo o sentido assim que se gerem vários servidores ou se quer avançar para GitOps;
• O Dockhand é muito completo, sobretudo no que diz respeito à segurança, e vale a pena acompanhá-lo de perto, se a licença for adequada às suas necessidades.

O mais prudente é não migrar nada de imediato. Instale uma destas ferramentas ao lado do Portainer e teste-a durante algumas semanas. Todas comunicam com o mesmo daemon Docker e coexistem sem problemas; aliás, a FAQ do Dockge diz isso mesmo, preto no branco. Há apenas um ponto a ter em conta: as stacks criadas no editor Web do Portainer são armazenadas no respetivo volume de dados, não numa pasta que possa gerir. Recupere os ficheiros Compose antes de mudar.

É isso que faria no seu lugar.

Durante anos, à pergunta «que interface usar para gerir o Docker?» havia uma resposta quase automática: Portainer. Em 2026, temos finalmente uma verdadeira escolha e, para quem gosta de experimentar no seu home lab, isso é uma boa notícia.

E vocês, o que acham?