Test d'Arcane pour Docker : est-il prêt à remplacer Portainer ?

Arcane a livré un contrôle d'accès basé sur les rôles complet le 7 juin 2026, avec la version v2.0.0. Il analyse aussi vos images à la recherche de vulnérabilités connues, selon un calendrier que vous définissez. Rien de tout cela n'était vrai quand Brandon Lee a publié ses premières impressions sur Arcane le 29 décembre 2025, un peu plus de cinq mois avant la sortie du RBAC.

Ce décalage est la partie délicate de tout test d'Arcane pour Docker en ce moment. L'outil en est déjà à la v2.10.2, publiée le 5 septembre 2026, moins de deux semaines après la v2.9.0. La version v2.10.0 a corrigé la fuite de clones GitOps abordée plus bas et ajouté un flux expérimental Convert to Compose pour les conteneurs en cours d'exécution. Une liste de fonctionnalités rédigée quelques jours plus tôt décrit déjà un autre produit.

En bref

Arcane en v2.10.2 est un remplaçant viable de Portainer pour le bon profil d'opérateur. Il fournit un RBAC complet, l'authentification unique OIDC, l'analyse de vulnérabilités Trivy et le redéploiement GitOps, sans frais et sans plafond de nœuds. Portainer réserve cette hiérarchie de rôles à la Business Edition au-delà de trois nœuds. 4 sur 5. Ce qui le freine, c'est son ancienneté, pas ses capacités.

• Passez à Arcane une fois le troisième nœud de Portainer dépassé, quand il vous faut des rôles qui délimitent qui peut toucher à quoi. Vous obtenez six rôles intégrés, des rôles personnalisés, une attribution par environnement et la correspondance des claims de groupe OIDC, sans payer et sans compteur.
• L'analyse de vulnérabilités est incluse. Arcane exécute Trivy, un analyseur d'images open source, selon une planification cron et stocke les résultats par image.
• Portainer Business Edition est gratuit jusqu'à trois nœuds, sans restriction de fonctionnalités. Sous cette limite, vous avez déjà le RBAC et le SSO, donc l'argument de l'accès gratuit d'Arcane pèse beaucoup moins.
• Il n'existe toujours pas d'import direct des stacks Portainer. La v2.10.0 peut, à titre expérimental, convertir des conteneurs en cours d'exécution en projets Compose, ce qui réduit une partie du travail manuel, mais vous devez encore relire le YAML généré et planifier une bascule, car les noms et les ports publiés peuvent entrer en conflit tant que les originaux tournent. Sauvegardez d'abord les volumes.
• Durcissez ENCRYPTION_KEY avant la production, et configurez APP_URL correctement. ENCRYPTION_KEY a encore une valeur par défaut de développement, et la connexion par passkey ne fonctionnera pas tant que APP_URL ne pointe pas vers le nom d'hôte HTTPS que les utilisateurs ouvrent réellement. JWT_SECRET n'est plus utilisé, d'après la documentation d'installation actuelle.
• Le bug d'épuisement du disque GitOps signalé sur les v2.8.0 et v2.9.0 est corrigé dans la v2.10.0. Le correctif purge les répertoires temporaires de clone Git au lieu de les laisser s'accumuler sur l'hôte du manager.
• LDAP est toujours absent. L'intégration d'identité se fait uniquement via OIDC.

Comment cette évaluation a été réalisée : il s'agit d'une revue sur pièces, pas d'un test pratique. Aucun sponsoring, aucun paiement, aucun produit fourni, aucun contact avec le mainteneur. Chaque affirmation sur les fonctionnalités est vérifiée par rapport à la documentation et aux notes de version actuelles d'Arcane, et chaque affirmation sur la fiabilité renvoie à un ticket daté sur le tracker public du projet ou à un opérateur nommé qui décrit son propre déploiement. Personne ici n'a fait tourner Arcane pour écrire cet article, donc là où cela limite la lecture (le ressenti de l'interface, la tenue sous charge soutenue), l'article le dit au lieu de deviner.

Qu'est-ce qu'Arcane offre gratuitement que Portainer ne donne pas ?

Une chose, principalement : un contrôle d'accès basé sur les rôles complet. Portainer CE vous donne une gestion des utilisateurs basique ; la hiérarchie de rôles est réservée à la Business Edition. Arcane la fournit gratuitement quel que soit le nombre de nœuds, avec l'analyse Trivy, le redéploiement GitOps, la prise en charge de Swarm, la connexion par passkey, les agents distants et les sauvegardes S3 ajoutées dans la v2.9.0.

Le RBAC est la partie qui mérite un examen attentif, parce que « a du RBAC » recouvre des réalités très différentes. La documentation d'Arcane sur le contrôle d'accès décrit six rôles intégrés immuables : Admin, Editor, No-Shell Editor, Deployer, Monitor et Viewer. Vous pouvez cloner n'importe lequel d'entre eux en rôle personnalisé et cocher des permissions individuelles, qui suivent un <resource>:<action> schéma comme containers:start. Les attributions sont globales ou par environnement, et un utilisateur peut en cumuler plusieurs. La documentation donne l'exemple directement : Editor sur prod, Viewer sur staging.

Ce qui compte pour un déploiement SSO, c'est que l'attribution des rôles peut être pilotée par le fournisseur d'identité lui-même : « À chaque connexion, Arcane lit le claim de groupe de l'utilisateur et resynchronise ses attributions issues d'OIDC », et un utilisateur présent dans plusieurs groupes mappés obtient l'union de leurs droits. C'est le modèle de permissions que Portainer CE n'a jamais eu.

L'analyse de vulnérabilités est le deuxième élément. La documentation d'Arcane sur l'analyse indique que « les analyses sont optionnelles, s'exécutent selon une planification cron, et les résultats sont stockés par image », les résultats étant affichés dans l'interface. Par défaut, elles tournent chaque jour à minuit, trivyIgnoreUnfixed limite les résultats aux vulnérabilités disposant d'un correctif connu, et Trivy est livré dans une image d'outils à version épinglée, donc les mises à jour de l'analyseur ne sont pas à votre charge.

Voici maintenant le contrepoids, et il est de taille. La page CE contre BE de Portainer indique que la Business Edition « est gratuite pour toujours jusqu'à 3 nœuds. Pas de période d'essai. Pas de carte bancaire. Aucune restriction de fonctionnalités. » C'est l'ensemble complet de la BE : RBAC avec sa propre hiérarchie de rôles, OIDC, journaux d'audit avec export Syslog, GitOps avancé. Les conditions de l'offre Take 3 délivrent une licence d'un an, renouvelée chaque année sans frais tant que vous restez à trois nœuds ou moins.

Le calcul de l'offre gratuite ne tourne donc en faveur d'Arcane qu'à partir du quatrième nœud. En dessous, il n'y a pas de barrière payante. Arcane apporte tout de même quelque chose à un ou deux nœuds : pas de clé de licence, pas de renouvellement à retenir, un projet que vous pouvez forker. Mais ce n'est pas le même argument que « le RBAC coûte de l'argent ».

Arcane est l'un des quatre outils qui briguent sérieusement la place de Portainer, et les autres se répartissent selon d'autres lignes.

LIRE

Alternatives à Portainer : guide par cas d'usage de Dockge, Arcane, Dockhand et Komodo

Quelle est la fiabilité d'Arcane aujourd'hui ?

Meilleure qu'elle n'en avait l'air en v2.9.0, mais encore jeune. L'historique des bugs d'Arcane ressemble à celui d'un projet actif qui corrige les choses, et le grave bug d'épuisement du disque GitOps signalé sur les v2.8.0 et v2.9.0 a été corrigé dans la v2.10.0 le 31 août 2026.

Un opérateur a signalé le 26 août 2026 que la synchronisation GitOps laisse fuir un répertoire de clone : "gitops-<N> les répertoires de clone s'accumulent à raison d'environ 1 000 par jour (~9 Go/jour) et ne sont jamais nettoyés, jusqu'à remplir le disque." Six jours de ce régime ont donné environ 6 467 répertoires et 40 Go. Une fois le disque plein, le manager ne pouvait plus écrire dans sa base SQLite et est entré dans une boucle de redémarrage, atteignant 389 redémarrages et entraînant avec lui les connexions des agents edge et les appels API. Le ticket est désormais fermé, et la v2.10.0 embarque le correctif de nettoyage des répertoires temporaires de clone Git.

Si vous êtes encore en v2.8.0 ou v2.9.0 : mettez à jour avant de vous appuyer sur une synchronisation GitOps fréquente. Le correctif de la fuite de clones arrive avec la v2.10.0.

L'historique plus ancien est plus encourageant. Un blocage après mise à jour entre la 2.0 et la 2.0.1 a été résolu. Un bug où « Update Projects » touchait tous les conteneurs de l'hôte au lieu de ceux du projet sélectionné a été fermé après la fusion de la PR de correction #2289. L'interrogation des images qui ne se déclenchait pas silencieusement en v1.13.2 a été corrigée en v1.14.0. Trois bugs, trois correctifs.

Le nombre brut de tickets ouverts en dit très peu à lui seul sur un projet qui livre à ce rythme. Les projets contre lesquels personne ne dépose de ticket n'en sont pas plus fiables pour autant.

Ma lecture reste que c'est un problème d'ancienneté plutôt que de capacité. La cadence de livraison rapide est la raison pour laquelle les lacunes du RBAC et de l'analyse se sont comblées, et c'est aussi pour cela que la v2.10.0 a dû corriger un grave défaut GitOps moins d'une semaine après la v2.9.0. Le risque se trouve dans le code neuf, et l'adopter est un choix.

Que coûte réellement la migration depuis Portainer ?

Une fenêtre d'indisponibilité et un peu de nettoyage manuel, en gros. Arcane n'a toujours pas d'import direct des stacks Portainer, mais la v2.10.0 ajoute une action expérimentale Convert to Compose pour les conteneurs en cours d'exécution. Elle génère un fichier Compose pendant que les originaux continuent de tourner, ce qui supprime une partie du travail de reconstruction du YAML. Vous devez encore relire les montages bind, les réseaux, les valeurs d'environnement et la bascule elle-même ; les noms et les ports publiés peuvent entrer en conflit tant que les originaux ne sont pas arrêtés, donc ce n'est pas un bouton de migration sans interruption.

Avant la v2.10.0, le forum du projet reflétait un parcours entièrement manuel. Un opérateur avec plus de 80 conteneurs répartis sur cinq serveurs a demandé si une migration à chaud était possible sans d'abord couper les services exposés sur le web. La réponse de quelqu'un qui l'avait déjà fait : « vous n'aurez pas d'autre choix que de supprimer les conteneurs existants (et donc les stacks Portainer) et de les recréer de zéro dans Arcane. » Sa séquence : arrêter proprement, sauvegarder, supprimer, copier les données, recréer et redéployer.

Concrètement : des sauvegardes des volumes avant de toucher à quoi que ce soit, et une fenêtre de maintenance dimensionnée à la fois selon le nombre de stacks que vous exécutez et la quantité de données à déplacer. La recréation des conteneurs est généralement la partie rapide ; copier de gros volumes et relancer les services dépendants dans le bon ordre peut allonger la fenêtre. Une note de vocabulaire pendant que vous planifiez : ce que Portainer appelle une stack, Arcane l'appelle un projet.

Le coût en temps se fait sentir même à l'échelle d'un homelab. Moises Aguirre, qui écrivait le 28 février 2026 sur le déplacement d'un homelab hors de Portainer, l'a qualifié de « bon week-end de travail (et d'affrontement avec mes démons) », et ces démons étaient sa propre dérive : il a dû auditer chaque conteneur qu'il faisait tourner et écrire du YAML pour des services qu'il avait « auparavant simplement créés en cliquant ». C'est son expérience plutôt qu'une règle, mais la forme en est transposable.

Une chose à repérer avant de transférer vos fichiers Compose. Les notes de version de la v2.7.0 ont restreint la résolution des variables à quatre sources : vos variables globales dans .env.global, le fichier .env propre au projet, les valeurs par défaut écrites dans le fichier compose lui-même, et le fuseau horaire et la locale issus de l'environnement d'Arcane. L'effet annoncé est qu'un projet déployé via Arcane résout ses variables de la même manière que docker compose up dans le répertoire du projet. C'est un comportement plus correct. Cela signifie aussi que tout ce qui héritait discrètement d'une valeur de l'environnement du conteneur du manager se résoudra désormais vers autre chose, ou vers rien, et le fera sans se plaindre.

Rien de tout cela n'est un défaut du produit. C'est un coût ponctuel, assez prévisible pour être planifié, ce qui est l'essentiel de ce qu'on attend d'une migration.

Développez sur un VPS Linux avec accès root, NVMe et la puissance AMD EPYC.

Voir les plans Linux

Que faut-il durcir avant la production ?

Une clé de chiffrement, l'URL publique et TLS. Arcane crée un compte admin par défaut au premier démarrage et impose un changement de mot de passe à la première connexion, ce qui est un bon réglage par défaut. Deux paramètres doivent être corrects avant la production. Le premier est ENCRYPTION_KEY ; le second est APP_URL.

La référence des variables d'environnement liste toujours ENCRYPTION_KEY avec pour valeur par défaut arcane-dev-key-32-characters!!!, alors que la documentation d'installation vous demande de fournir une valeur unique de 32 octets. Changez-la avant la production. Autre chose a changé : la documentation d'installation indique désormais que JWT_SECRET n'est plus utilisé. Arcane génère lui-même la clé de signature des sessions ; laisser JWT_SECRET configuré ne produit qu'un avertissement au démarrage, donc retirez-le de l'environnement. La documentation d'installation précise que ENCRYPTION_KEY « doit faire 32 octets (brut, base64 ou hexadécimal) ».

L'hygiène des versions fait aussi partie de cette liste. Arcane a publié plusieurs avis de sécurité en 2026 ; un avis de gravité élevée, publié le 29 juillet 2026, indique que les versions antérieures à la v2.5.0 sont affectées et qu'une permission déléguée users:update permettait de réinitialiser le mot de passe d'un administrateur. Il désigne la v2.6.0 comme version corrigée, donc la v2.10.0 n'est pas concernée, mais c'est une raison concrète de ne pas laisser un déploiement de production sur un vieux tag.

APP_URL a pour valeur par défaut http://localhost:3552, et celle-ci a une conséquence fonctionnelle au-delà de l'hygiène. La connexion par passkey et la MFA par passkey reposent toutes deux sur WebAuthn, et la documentation d'Arcane sur les passkeys est explicite : « Les navigateurs n'exposent l'API WebAuthn que dans un contexte sécurisé, donc les passkeys nécessitent HTTPS (ou localhost). » L'identifiant de relying party est dérivé de APP_URL, les passkeys sont liées à ce nom d'hôte, et si APP_URL ne contient pas de nom d'hôte, le service de passkeys ne s'initialise pas. En HTTP simple, Arcane masque entièrement les contrôles de passkey. Déployez sur une IP nue avec un port et la fonctionnalité d'authentification phare de la v2 n'est tout simplement pas là. La documentation le dit clairement : « Définissez APP_URL sur l'URL que vos utilisateurs ouvrent réellement, en HTTPS, avant que quiconque n'enregistre une passkey. »

Les agents distants déterminent ce que vous ouvrez. La documentation d'Arcane sur les environnements indique qu'en mode direct « le Manager se connecte à l'Agent sur le port TCP 3553 », ce port doit donc être joignable en entrée sur l'hôte distant. En mode edge, « l'Agent se connecte en sortie vers le Manager » et n'a besoin d'aucun port entrant.

Au-delà, je préfère indiquer que prétendre. Arcane publie un guide de configuration de proxy de socket dont le principe est qu'un montage direct du socket « donne à Arcane un accès complet à Docker », et qu'un proxy réduit cela aux appels API nécessaires. C'est la même exposition qui rend l'isolation du socket Docker utile partout, et elle vaut la peine ici aussi. Je lis cette documentation comme un déployeur la lit, sans auditer le schéma de jetons.

Que ne fait toujours pas Arcane ?

Deux lacunes tiennent encore face à la documentation actuelle d'Arcane : pas de LDAP et pas de navigateur général pour le système de fichiers propre à un conteneur. Plusieurs autres lacunes d'avant la v2 se sont depuis refermées.

LDAP est absent. La documentation d'Arcane sur l'authentification unique couvre OIDC et uniquement OIDC, et ni elle ni la page de contrôle d'accès ne mentionnent LDAP ou Active Directory nulle part. La Business Edition de Portainer, à l'inverse, s'intègre à « Active Directory, LDAP et aux fournisseurs d'identité compatibles OIDC ». Si votre organisation s'authentifie auprès d'un annuaire sans couche OIDC devant, c'est un obstacle bloquant, pas un contournement.

Pas de navigateur de fichiers général à l'intérieur des conteneurs. La vue conteneur d'Arcane expose la configuration, les montages, les journaux et la source Compose, mais pas de navigateur pour le système de fichiers propre au conteneur. Elle dispose désormais d'un Volume Workspace qui permet de parcourir et de modifier les fichiers à l'intérieur des volumes Docker, donc la lacune restante est plus étroite que l'ancienne description « pas de navigateur de fichiers ».

Ces corrections méritent d'être énoncées clairement, parce que la description « pas de RBAC, pas d'analyse de vulnérabilités » d'Arcane ne tient plus. Le RBAC est arrivé avec la v2.0.0 le 7 juin 2026, et l'analyse Trivy est documentée et s'exécute selon une planification. La journalisation d'activité a aussi évolué : la documentation d'Arcane sur l'activité décrit un Activity Center couvrant les pulls, les builds, les actions de cycle de vie, les analyses et les nettoyages, accompagné d'un journal d'événements portant la gravité, le type, l'horodatage et l'utilisateur à l'origine de chaque action quand Arcane peut l'attribuer. Savoir s'il exporte vers Syslog comme le fait l'offre Business de Portainer n'est pas une question que la documentation tranche.

Ce que la vitesse de livraison ne corrige pas, c'est l'âge. Le dépôt Arcane a été créé en avril 2025. Portainer a derrière lui des années de réponses Stack Overflow, de guides tiers et d'intégrations, et quand vous tombez sur quelque chose d'étrange à 23 h, c'est cette différence que vous ressentez.

Qui devrait passer à Arcane, et qui ne devrait pas ?

Passez à Arcane si vous avez dépassé trois nœuds sur Portainer et voulez un accès multi-utilisateur délimité avec des fichiers Compose suivis dans git, sans discussion de licence. Restez où vous êtes si vous avez trois nœuds ou moins. Compter les hôtes règle l'essentiel de la question plus vite que n'importe quelle liste de fonctionnalités.

Trois profils pour lesquels Arcane est un oui clair :

• Les opérateurs au-delà du plafond de trois nœuds de Portainer qui ont besoin d'un accès délimité. Au-delà de trois nœuds, ces capacités ont un prix chez Portainer et aucun chez Arcane, et les rôles sont assez fins pour donner à quelqu'un Deployer sur un environnement et Viewer partout ailleurs.
• Les opérateurs qui veulent des fichiers Compose comme source de vérité. Si ce qui motive le changement est que les définitions de stacks vivent dans une base de données plutôt que dans un dépôt, c'est une adéquation structurelle, pas une préférence. Le week-end de migration sert surtout à écrire noir sur blanc ce que vous faites déjà tourner, un travail que vous deviez de toute façon.
• Les opérateurs qui consolident plusieurs hôtes, y compris derrière un NAT. Les agents en mode edge n'ont besoin d'aucun port entrant côté distant, les clusters Swarm sont gérés depuis le nœud manager, et les environnements distants ne coûtent rien.

Deux profils pour lesquels ce n'est pas le cas :

• Toute personne à trois nœuds ou moins. La Business Edition est gratuite à cette taille avec l'ensemble complet des fonctionnalités, donc changer d'outil dépense une fenêtre d'indisponibilité et un week-end pour obtenir des capacités que vous avez déjà. Comme alternative à Portainer, Arcane est compétent ; ce n'est toujours pas une raison de bouger.
• Toute personne qui a besoin de LDAP, ou qui ne peut pas arrêter ses stacks. L'authentification par annuaire n'est pas disponible et la migration exige toujours une bascule planifiée. Aucun des deux n'a de contournement astucieux.

Une condition accompagne ce verdict. Si le redéploiement GitOps est précisément la raison de votre migration, utilisez la v2.10.0 ou une version plus récente. Le bug d'épuisement du disque signalé sur les v2.8.0 et v2.9.0 y est corrigé.

LIRE

Comment installer Docker sur un VPS : un guide complet pour utiliser un VPS pour la conteneurisation 🗂️

Foire aux questions