Análise do Arcane para Docker: ele está pronto para substituir o Portainer?

O Arcane lançou o controle de acesso baseado em funções completo em 7 de junho de 2026, na versão v2.0.0. Ele também varre suas imagens em busca de vulnerabilidades conhecidas, no cronograma que você definir. Nada disso era verdade quando Brandon Lee publicou seu artigo de primeiras impressões sobre o Arcane em 29 de dezembro de 2025, pouco mais de cinco meses antes do lançamento do RBAC.

Essa lacuna é a parte incômoda de qualquer análise do Arcane para Docker neste momento. A ferramenta já está na v2.10.2, lançada em 5 de setembro de 2026, menos de duas semanas depois da v2.9.0. A versão v2.10.0 corrigiu o vazamento de clones do GitOps discutido abaixo e adicionou um fluxo experimental Convert to Compose para contêineres em execução. Uma lista de recursos escrita poucos dias antes descreve um produto diferente.

TL;DR

O Arcane na v2.10.2 é um substituto viável do Portainer para o operador certo. Ele entrega RBAC completo, login único OIDC, varredura de vulnerabilidades com Trivy e reimplantação GitOps sem custo e sem teto de nós. O Portainer reserva essa hierarquia de funções à Business Edition acima de três nós. 4 em 5. O que o segura é a pouca idade, não a capacidade.

• Migre assim que passar do terceiro nó do Portainer e precisar de funções que delimitem quem pode mexer em quê. Você recebe seis funções integradas, funções personalizadas, atribuição por ambiente e mapeamento de claims de grupo OIDC, sem pagar e sem medição.
• A varredura de vulnerabilidades vem incluída. O Arcane executa o Trivy, um scanner de imagens de código aberto, em um cronograma cron e armazena os resultados por imagem.
• O Portainer Business Edition é gratuito até três nós, sem restrições de recursos. Abaixo dessa linha você já tem RBAC e SSO, então o argumento do acesso gratuito do Arcane fica bem mais fraco.
• Ainda não existe importação direta de stacks do Portainer. A v2.10.0 pode, de forma experimental, converter contêineres em execução em projetos Compose, o que reduz parte do trabalho manual, mas você ainda precisa revisar o YAML gerado e planejar uma virada, porque nomes e portas publicadas podem colidir enquanto os originais estiverem rodando. Faça backup dos volumes primeiro.
• Proteja ENCRYPTION_KEY antes da produção e configure APP_URL corretamente. ENCRYPTION_KEY ainda tem um valor padrão de desenvolvimento, e o login com passkey não vai funcionar até que APP_URL aponte para o nome de host HTTPS que os usuários realmente acessam. JWT_SECRET não é mais usado, segundo a documentação de instalação atual.
• O bug de esgotamento de disco do GitOps relatado nas v2.8.0 e v2.9.0 está corrigido na v2.10.0. A correção limpa os diretórios temporários de clone do Git que sobram em vez de deixá-los acumular no host do manager.
• O LDAP continua ausente. A integração de identidade é apenas via OIDC.

Como esta avaliação foi feita: esta é uma análise baseada em evidências, não um teste prático. Sem patrocínio, sem pagamento, sem produto fornecido, sem contato com o mantenedor. Toda afirmação sobre capacidades foi conferida na documentação e nas notas de versão atuais do Arcane, e toda afirmação sobre confiabilidade remete a uma issue datada no rastreador público do projeto ou a um operador identificado escrevendo sobre sua própria implantação. Ninguém aqui rodou o Arcane para escrevê-la, então onde isso limita a leitura (como a interface se comporta, como ela aguenta carga sustentada) o texto diz isso em vez de adivinhar.

O que o Arcane oferece de graça que o Portainer não oferece?

Uma coisa, principalmente: controle de acesso baseado em funções completo. O Portainer CE oferece gerenciamento básico de usuários; a hierarquia de funções é da Business Edition. O Arcane a entrega de graça com qualquer número de nós, junto com varredura Trivy, reimplantação GitOps, suporte a Swarm, login com passkey, agentes remotos e os backups em S3 adicionados na v2.9.0.

O RBAC é a parte que merece um olhar atento, porque "tem RBAC" cobre coisas muito diferentes. A documentação de controle de acesso do Arcane descreve seis funções integradas imutáveis: Admin, Editor, No-Shell Editor, Deployer, Monitor e Viewer. Você pode clonar qualquer uma delas em uma função personalizada e marcar permissões individuais, que seguem um <resource>:<action> formato como containers:start. As atribuições são globais ou por ambiente, e um usuário pode ter várias ao mesmo tempo. A documentação dá o exemplo diretamente: Editor em prod, Viewer em staging.

A parte que importa para uma implantação de SSO é que a atribuição de funções pode ser conduzida pelo próprio provedor de identidade: "A cada login o Arcane lê o claim de grupo do usuário e ressincroniza suas atribuições vindas do OIDC", e um usuário em vários grupos mapeados recebe a união delas. Esse é o modelo de permissões que o Portainer CE nunca teve.

A varredura de vulnerabilidades é a segunda peça. A documentação de varredura do Arcane afirma que "as varreduras são opcionais, rodam em um cronograma cron e os resultados são armazenados por imagem", com os resultados exibidos na interface. O padrão é diariamente à meia-noite, trivyIgnoreUnfixed restringe os resultados a vulnerabilidades com correção conhecida, e o Trivy é distribuído em uma imagem de ferramentas com versão fixada, então as atualizações do scanner não ficam por sua conta.

Agora o contrapeso, e ele é grande. A própria página do Portainer sobre CE versus BE diz que a Business Edition "é gratuita para sempre até 3 nós. Sem período de teste. Sem cartão de crédito. Sem restrições de recursos." Esse é o conjunto completo da BE: RBAC com sua própria hierarquia de funções, OIDC, logs de auditoria com exportação para Syslog, GitOps avançado. Os termos do Take 3 emitem uma licença de um ano, renovada anualmente sem custo enquanto você ficar em três nós ou menos.

Então a conta do nível gratuito só começa a favorecer o Arcane a partir do quarto nó. Abaixo disso, o paywall não existe. O Arcane ainda oferece algo com um ou dois nós: nenhuma chave de licença, nenhuma renovação para lembrar, um projeto que você pode bifurcar. Mas esse não é o mesmo argumento que "RBAC custa dinheiro".

O Arcane é uma das quatro ferramentas que disputam seriamente a vaga do Portainer, e as outras se dividem por linhas diferentes.

LER

Alternativas ao Portainer: um guia por caso de uso de Dockge, Arcane, Dockhand e Komodo

Quão confiável é o Arcane agora?

Melhor do que parecia na v2.9.0, mas ainda jovem. O histórico de bugs do Arcane se lê como o de um projeto ativo consertando as coisas, e o grave bug de esgotamento de disco do GitOps relatado nas v2.8.0 e v2.9.0 foi corrigido na v2.10.0 em 31 de agosto de 2026.

Um operador relatou em 26 de agosto de 2026 que a sincronização do GitOps vaza um diretório de clone: "gitops-<N> os diretórios de clone se acumulam a cerca de 1.000 por dia (~9 GB/dia) e nunca são limpos, até encher o disco." Seis dias disso resultaram em cerca de 6.467 diretórios e 40 GB. Com o disco cheio, o manager não conseguia mais gravar em seu banco SQLite e entrou em um loop de reinicializações, chegando a 389 reinícios e derrubando junto as conexões dos agentes edge e as chamadas de API. A issue já está fechada, e a v2.10.0 traz a correção que limpa os diretórios temporários de clone do Git.

Se você ainda está na v2.8.0 ou v2.9.0: atualize antes de depender de sincronização GitOps frequente. A correção do vazamento de clones chega na v2.10.0.

O histórico mais antigo é mais animador. Um travamento pós-atualização entre a 2.0 e a 2.0.1 foi resolvido. Um bug em que o "Update Projects" atingia todos os contêineres do host em vez dos do projeto selecionado foi fechado com o PR de correção #2289 mesclado. A sondagem de imagens que não disparava silenciosamente na v1.13.2 foi corrigida na v1.14.0. Três bugs, três correções.

A contagem bruta de issues abertas diz muito pouco por si só sobre um projeto que lança nesse ritmo. Projetos contra os quais ninguém abre issues não são por isso mais confiáveis.

Minha leitura continua sendo que este é um problema de tempo de estrada, não de capacidade. Lançar rápido é o motivo de as lacunas de RBAC e varredura terem fechado, e também o motivo de a v2.10.0 ter precisado corrigir um defeito grave do GitOps menos de uma semana depois da v2.9.0. O risco está no código novo, e adotá-lo é uma escolha.

Quanto custa de fato migrar do Portainer?

Uma janela de indisponibilidade e alguma limpeza manual, grosso modo. O Arcane ainda não tem importação direta de stacks do Portainer, mas a v2.10.0 adiciona uma ação experimental Convert to Compose para contêineres em execução. Ela gera um arquivo Compose enquanto os originais continuam rodando, o que elimina parte do trabalho de reconstrução do YAML. Você ainda precisa revisar bind mounts, redes, valores de ambiente e a própria virada; nomes e portas publicadas podem colidir até os originais serem parados, então isso não é um botão de migração sem indisponibilidade.

Antes da v2.10.0, o próprio fórum do projeto refletia um caminho totalmente manual. Um operador com mais de 80 contêineres em cinco servidores perguntou se uma migração ao vivo era possível sem antes derrubar os serviços expostos na web. A resposta de alguém que já tinha feito isso: "você não terá escolha a não ser excluir os contêineres existentes (e portanto as stacks do Portainer) e recriá-los do zero no Arcane." A sequência dele: desligar de forma limpa, fazer backup, excluir, copiar os dados, recriar e reimplantar.

Na prática: backups dos volumes antes de mexer em qualquer coisa, e uma janela de manutenção dimensionada tanto pela quantidade de stacks que você roda quanto pelo volume de dados a mover. Recriar os contêineres costuma ser a parte rápida; copiar volumes grandes e subir os serviços dependentes na ordem certa pode esticar a janela. Uma nota de terminologia enquanto você planeja: o que o Portainer chama de stack, o Arcane chama de projeto.

O custo em tempo aparece até em escala de homelab. Moises Aguirre, escrevendo em 28 de fevereiro de 2026 sobre tirar um homelab do Portainer, chamou isso de "um bom fim de semana de trabalho (e de encarar meus demônios)", e os demônios eram a própria bagunça dele: precisou auditar cada contêiner que rodava e escrever YAML para serviços que antes "simplesmente tinha criado no clique". É a experiência dele, não uma regra, mas o formato se repete.

Uma coisa para pegar antes de levar seus arquivos Compose. As notas da versão v2.7.0 restringiram a resolução de variáveis a quatro fontes: suas variáveis globais em .env.global, o arquivo .env do próprio projeto, os padrões escritos no próprio arquivo compose, e fuso horário e localidade do ambiente do Arcane. O efeito declarado é que um projeto implantado pelo Arcane resolve suas variáveis do mesmo jeito que docker compose up faz no diretório do projeto. É um comportamento mais correto. Também significa que qualquer coisa que herdava silenciosamente um valor do ambiente do contêiner do manager agora vai resolver para outra coisa, ou para nada, e vai fazer isso sem reclamar.

Nada disso é um defeito do produto. É um custo único, previsível o bastante para ser planejado, que é o principal que se quer de uma migração.

Construa num VPS Linux com acesso root, NVMe e o poder do AMD EPYC.

Ver planos Linux

O que você precisa proteger antes da produção?

Uma chave de criptografia, a URL pública e TLS. O Arcane cria uma conta admin padrão na primeira execução e força a troca de senha no primeiro login, o que é um padrão sensato. Duas configurações precisam estar certas antes da produção. A primeira é ENCRYPTION_KEY; a segunda é APP_URL.

A referência de variáveis de ambiente ainda lista ENCRYPTION_KEY com um padrão de arcane-dev-key-32-characters!!!, enquanto a documentação de instalação manda você fornecer um valor único de 32 bytes. Troque-o antes da produção. Outra coisa mudou: a documentação de instalação agora diz que JWT_SECRET não é mais usado. O Arcane gera a própria chave de assinatura de sessão; deixar JWT_SECRET configurado só produz um aviso na inicialização, então remova-o do ambiente. A documentação de instalação especifica que ENCRYPTION_KEY "deve ter 32 bytes (bruto, base64 ou hexadecimal)."

A higiene de versões também entra nessa lista. O Arcane publicou vários avisos de segurança em 2026; um aviso de severidade alta, publicado em 29 de julho de 2026, lista as versões anteriores à v2.5.0 como afetadas e permitia que uma permissão delegada users:update redefinisse a senha de um administrador. Ele aponta a v2.6.0 como a versão corrigida, então a v2.10.0 não é afetada, mas é um motivo concreto para não deixar uma implantação de produção parada em uma tag antiga.

APP_URL tem como padrão http://localhost:3552, e este tem uma consequência funcional além da higiene. O login com passkey e o MFA com passkey rodam sobre WebAuthn, e a documentação de passkeys do Arcane é explícita: "Os navegadores só expõem a API WebAuthn em um contexto seguro, então passkeys precisam de HTTPS (ou localhost)." O ID do relying party é derivado de APP_URL, as passkeys ficam vinculadas a esse nome de host, e se APP_URL não tiver um nome de host o serviço de passkeys não inicializa. Em HTTP puro, o Arcane esconde os controles de passkey por completo. Implante em um IP pelado com porta e o recurso de autenticação de destaque da v2 simplesmente não aparece. A documentação é direta: "Defina APP_URL como a URL que seus usuários realmente acessam, via HTTPS, antes que alguém registre uma passkey."

Os agentes remotos decidem o que você abre. A documentação de ambientes do Arcane diz que no modo direto "o Manager se conecta ao Agent na porta TCP 3553", então essa porta precisa estar acessível de entrada no host remoto. No modo edge, "o Agent se conecta de saída ao Manager" e não precisa de nenhuma porta de entrada.

Além disso, prefiro apontar a fingir. O Arcane publica um guia de configuração de proxy de socket cuja premissa é que montar o socket diretamente "dá ao Arcane acesso total ao Docker", e um proxy reduz isso às chamadas de API necessárias. É a mesma exposição que faz o isolamento do socket do Docker valer a pena em qualquer lugar, e aqui também. Estou lendo esses documentos como quem implanta os lê, sem auditar o esquema de tokens.

O que o Arcane ainda não faz?

Duas lacunas ainda se mantêm diante da documentação atual do Arcane: sem LDAP e sem um navegador geral para o sistema de arquivos do próprio contêiner. Várias outras lacunas anteriores à v2 já foram fechadas.

O LDAP está ausente. A documentação de login único do Arcane cobre OIDC e apenas OIDC, e nem ela nem a página de controle de acesso mencionam LDAP ou Active Directory em lugar nenhum. A Business Edition do Portainer, por outro lado, se integra com "Active Directory, LDAP e provedores de identidade compatíveis com OIDC". Se sua organização se autentica em um diretório sem uma camada OIDC na frente, isso é um impedimento total, não algo contornável.

Sem navegador de arquivos geral dentro dos contêineres. A visão de contêiner do Arcane expõe configuração, montagens, logs e a origem do Compose, mas não um navegador para o sistema de arquivos do próprio contêiner. Ela agora tem um Volume Workspace que consegue navegar e editar arquivos dentro de volumes Docker, então a lacuna que resta é mais estreita do que a velha descrição "sem navegador de arquivos".

Vale deixar essas correções explícitas, porque a descrição do Arcane como "sem RBAC, sem varredura de vulnerabilidades" não se sustenta mais. O RBAC chegou com a v2.0.0 em 7 de junho de 2026, e a varredura Trivy está documentada e rodando em cronograma. O registro de atividades também mudou: a documentação de atividades do Arcane descreve um Activity Center que cobre pulls, builds, ações de ciclo de vida, varreduras e limpezas, ao lado de um log de eventos com severidade, tipo, carimbo de data e hora e o usuário que disparou cada ação, quando o Arcane consegue atribuí-la. Se ele exporta para Syslog como o nível Business do Portainer faz, é algo que a documentação não esclarece.

O que a velocidade de lançamentos não resolve é a idade. O repositório do Arcane foi criado em abril de 2025. O Portainer tem anos de respostas acumuladas no Stack Overflow, guias de terceiros e integrações por trás, e quando você esbarra em algo estranho às 23h é essa diferença que você sente.

Quem deve migrar para o Arcane, e quem não deve?

Migre para o Arcane se você passou de três nós no Portainer e quer acesso multiusuário delimitado com Compose versionado no git, sem conversa sobre licenciamento. Fique onde está se tem três nós ou menos. Contar hosts resolve a maior parte disso mais rápido do que qualquer lista de recursos.

Três perfis para os quais o Arcane é um sim claro:

• Operadores acima do teto de três nós do Portainer que precisam de acesso delimitado. Acima de três nós, essas capacidades têm preço no Portainer e nenhum no Arcane, e as funções são granulares o bastante para dar a alguém Deployer em um ambiente e Viewer em todos os outros.
• Operadores que querem arquivos Compose como fonte da verdade. Se o que motiva a mudança é que as definições das stacks vivem em um banco de dados em vez de um repositório, isso é um encaixe estrutural, não uma preferência. O fim de semana de migração é gasto principalmente colocando no papel o que você já roda, um trabalho que você devia de qualquer forma.
• Operadores consolidando vários hosts, inclusive atrás de NAT. Agentes em modo edge não precisam de porta de entrada do lado remoto, clusters Swarm são gerenciados a partir do nó manager, e ambientes remotos não custam nada.

Dois perfis para os quais não é:

• Qualquer um com três nós ou menos. A Business Edition é gratuita nesse tamanho com o conjunto completo de recursos, então migrar gasta uma janela de indisponibilidade e um fim de semana para obter capacidades que você já tem. Como alternativa ao Portainer o Arcane é capaz; isso ainda não é motivo para mudar.
• Qualquer um que precise de LDAP, ou que não possa derrubar as stacks. A autenticação por diretório não está disponível e a migração ainda exige uma virada planejada. Nenhum dos dois tem uma saída esperta.

Uma condição acompanha esse veredito. Se a reimplantação GitOps é exatamente o motivo da sua migração, use a v2.10.0 ou mais recente. O bug de esgotamento de disco relatado nas v2.8.0 e v2.9.0 está corrigido lá.

LER

Como Obter o Docker num VPS: Um Guia Completo Sobre Como Utilizar o VPS Para Containerização🗂️

Perguntas frequentes