Pourquoi j’ai migré de Portainer vers Arcane

Pendant longtemps, Portainer a été la page d'accueil de mon serveur Docker. Je pouvais voir mes conteneurs. Je pouvais les arrêter, consulter leurs logs ou déployer une stack. Tout cela sans retenir chaque commande Docker.

Portainer a très bien fait ce travail. Puis mes besoins ont changé. Je voulais une interface plus moderne. Je voulais retrouver mes fichiers Compose facilement. Je voulais aussi mieux voir les risques cachés dans mes images.

J'ai donc testé Arcane. Puis j'ai migré.

Portainer, la valeur sûre pour administrer Docker

Portainer est une interface web pour gérer des environnements conteneurisés. Il sait piloter Docker, Docker Swarm et Kubernetes. Pour un homelab, je m'en sers surtout pour Docker.

Son intérêt est immédiat. Il évite une grande partie des commandes répétitives. En quelques clics, je vois les conteneurs, les images, les volumes et les réseaux. Je consulte les logs. J'ouvre une console. Je crée une stack à partir d'un fichier Docker Compose.

Le tableau de bord Portainer. Capture issue du dépôt public de la documentation Portainer.

C'est pratique. C'est aussi rassurant quand on découvre Docker. L'interface masque une partie de sa complexité. Elle donne une vue globale de la machine. Elle permet d'intervenir vite quand un service ne démarre plus.

Portainer reste un projet solide et mature. Sa communauté est grande. Sa documentation est riche. Je ne suis donc pas parti parce que Portainer était mauvais. Je suis parti parce qu'Arcane correspond mieux à ma manière de travailler aujourd'hui.

Arcane, une approche plus récente

Arcane est un projet beaucoup plus jeune. Sa première version publique date de 2025. Son objectif est simple : proposer une gestion moderne de Docker, sans transformer l'interface en usine à gaz.

Arcane permet de gérer les conteneurs, images, volumes et réseaux. Il prend aussi en charge les projets Docker Compose, les environnements distants, les mises à jour, les notifications et les scans de vulnérabilités.

Le tableau de bord Arcane. Capture issue du dépôt public officiel d'Arcane.

Ce qui m'a d'abord plu est son interface. Elle est sobre. Les informations importantes ressortent vite. Je passe moins de temps à chercher une action ou un statut.

Le projet évolue rapidement. C'est un avantage. C'est aussi un point de vigilance. Je lis les notes de version avant une mise à jour. Je sauvegarde les données Arcane. Et je n'utilise pas aveuglément le tag latest sur une machine importante.

Une vue centralisée de toute mon infrastructure

Portainer et Arcane partagent un autre avantage important. Je peux installer un agent sur chacun de mes serveurs. L'interface centrale communique ensuite avec ces agents.

Je n'ai donc pas besoin de me connecter séparément à chaque machine. Depuis un seul tableau de bord, je retrouve mes environnements Docker. Je vois leurs conteneurs, leurs images, leurs volumes et leurs projets.

C'est particulièrement pratique quand l'infrastructure grandit. Je peux gérer mon serveur principal, mes machines secondaires et mes environnements de test depuis le même endroit. Je conserve ainsi une vue centralisée de toute mon infrastructure.

Cette centralisation demande tout de même quelques précautions. Je protège les communications entre le serveur central et les agents. Je limite les ports exposés. Je vérifie aussi les droits accordés à chaque environnement.

Le mode Edge d'Arcane réduit les ports exposés

Arcane va plus loin avec son mode Edge. Dans ce mode, c'est l'agent installé sur le serveur distant qui ouvre une connexion sortante vers le Manager Arcane. Le Manager n'a pas besoin de joindre directement l'agent.

Je n'ai donc pas à ouvrir le port 3553 sur chacun de mes serveurs. C'est vraiment pratique derrière un pare-feu ou un NAT. La configuration réseau est plus simple. Surtout, je réduis le nombre de services accessibles depuis le réseau et donc la surface d'attaque de mon infrastructure.

Le Manager doit toujours rester joignable par les agents. Je le publie en HTTPS et je protège son accès. Arcane peut aussi ajouter une authentification mTLS entre le Manager et les agents Edge. Je conserve ainsi une vue centralisée sans multiplier les ports entrants sur mes machines distantes.

Portainer ou Arcane : pourquoi j'ai choisi Arcane

Les deux outils couvrent les besoins de base. Ils ne prennent toutefois pas le même chemin.

Une interface qui me paraît plus naturelle

L'interface d'Arcane est la première différence visible. Elle affiche beaucoup d'informations sans paraître chargée. Je retrouve rapidement un projet. Je vois son état. Je vois ses services. Je peux ensuite ouvrir les logs ou le fichier Compose.

Arcane me permet aussi de visualiser les métriques CPU, mémoire et disque d'un seul coup d'œil. Je repère immédiatement un serveur qui consomme trop de ressources ou dont le stockage commence à se remplir. Je n'ai pas besoin d'ouvrir chaque environnement pour obtenir cette première vue d'ensemble.

Les métriques CPU, mémoire et disque affichées par Arcane pour mes différents environnements.

Ce point reste subjectif. Portainer est très complet. Il couvre aussi davantage de scénarios historiques. Mais pour mon usage Docker Compose, Arcane me semble plus cohérent.

Une licence plus simple à comprendre

Portainer propose une Community Edition open source et une Business Edition sous licence commerciale. Ce modèle est parfaitement légitime. Mais il faut parfois vérifier dans quelle édition se trouve une fonction.

Arcane est publié sous licence BSD 3-Clause. Je dispose du même socle fonctionnel sans choisir entre une édition communautaire et une édition professionnelle. Pour mon infrastructure auto-hébergée, je préfère cette simplicité.

De vrais fichiers Compose, à un endroit connu

C'est le point qui a vraiment décidé ma migration.

Arcane considère son répertoire de projets comme la source de vérité. Chaque projet est un dossier. Il contient un compose.yaml, un éventuel .env et les fichiers associés. Le parcours peut être récursif. Je peux donc organiser mes applications comme je le souhaite.

/srv/compose/
├── monitoring/
│   ├── compose.yaml
│   └── .env
├── reverse-proxy/
│   ├── compose.yaml
│   └── config/
└── sauvegardes/
    └── compose.yaml

Je sais où sont mes fichiers. Je peux les sauvegarder. Je peux les versionner dans Git, sans les secrets. Je peux aussi lancer docker compose directement depuis le terminal.

Portainer sait bien sûr déployer depuis Git ou depuis un fichier Compose. Mais une stack créée dans son éditeur peut rester liée à son stockage interne. Je trouvais alors moins naturel de récupérer une arborescence portable et immédiatement lisible sur l'hôte.

Avec Arcane, l'interface ne remplace pas mes fichiers. Elle travaille avec eux. C'est exactement ce que je cherchais.

Le scan de vulnérabilités intégré

Arcane peut lancer des scans planifiés sur les images Docker avec Trivy. Les résultats sont enregistrés par image. L'interface affiche les niveaux de sévérité et permet de se concentrer sur les vulnérabilités corrigeables.

Ce n'était pas mon critère principal au départ. Je voulais surtout une meilleure gestion de mes projets Compose. Pourtant, ce scan est devenu l'un des bénéfices les plus utiles de la migration.

Un nombre élevé ne signifie pas que mon serveur est déjà compromis. Il ne faut pas non plus corriger au hasard. Je regarde d'abord la sévérité, l'exposition réelle du service et la présence d'une version corrigée. Mais cette visibilité m'oblige à ne plus ignorer le sujet.

Des notifications dès qu'une nouvelle image est disponible

Arcane ne se contente pas d'afficher les mises à jour dans son tableau de bord. Il peut envoyer une notification lorsqu'il détecte qu'une nouvelle image est disponible pour un conteneur.

Le choix des canaux est large : Discord, email, webhook générique, Google Chat, Gotify, Matrix, ntfy, Pushover, Signal, Slack ou encore Telegram. Je peux donc recevoir l'alerte dans l'outil que j'utilise déjà au quotidien.

Arcane propose plusieurs canaux pour signaler la détection d'une nouvelle image de conteneur.

Je n'ai plus besoin d'ouvrir régulièrement chaque environnement pour vérifier si une image plus récente existe. L'information vient directement à moi. C'est particulièrement utile quand je gère plusieurs serveurs et de nombreux projets.

La notification ne signifie pas que je dois appliquer aveuglément chaque mise à jour. Elle me permet d'identifier rapidement les images concernées, de consulter les notes de version, d'évaluer le risque et de choisir le bon moment pour intervenir.

Comment j'ai migré de Portainer vers Arcane

La migration ne déplace pas réellement les conteneurs. Docker continue de les exécuter. Je change surtout l'outil qui les administre et l'endroit où vivent mes définitions Compose.

Je l'ai faite en quelques grandes étapes.

1. J'ai commencé par un inventaire

J'ai listé mes stacks, conteneurs, volumes, réseaux et variables. J'ai noté les chemins des bind mounts. J'ai aussi vérifié le nom Compose réel de chaque projet.

Cette étape est importante. Un changement de nom peut créer de nouveaux volumes ou de nouveaux réseaux au lieu de réutiliser les anciens.

2. J'ai tout sauvegardé

J'ai exporté une sauvegarde Portainer. J'ai également sauvegardé les volumes et les bases de données de mes applications.

La sauvegarde de Portainer ne remplace pas celle des données applicatives. Ce sont deux choses différentes.

3. J'ai récupéré et rangé mes fichiers Compose

J'ai extrait les fichiers des stacks gérées par Portainer. Pour les projets déjà stockés dans Git, j'ai conservé Git comme source de vérité.

J'ai ensuite créé un dossier par application sous /srv/compose. J'ai déplacé les secrets dans des fichiers .env non versionnés. J'ai validé chaque projet avec docker compose config.

4. J'ai installé Arcane à côté de Portainer

J'ai démarré Arcane sur un autre port. J'ai monté /srv/compose au même chemin dans le conteneur. J'ai ensuite déclaré ce chemin comme répertoire de projets.

Je n'ai pas retiré Portainer à ce moment-là. Je voulais pouvoir revenir en arrière.

5. J'ai vérifié les projets avant de les redéployer

Arcane a découvert les dossiers. J'ai comparé les services, les images, les ports, les volumes et les réseaux.

J'ai commencé par une application non critique. Puis j'ai migré les autres par petits groupes. Pendant cette période, je n'ai jamais laissé Portainer et Arcane modifier la même stack en même temps.

6. J'ai retiré Portainer en dernier

J'ai attendu plusieurs jours. J'ai vérifié les redémarrages, les sauvegardes, les mises à jour et les logs. Une fois satisfait, j'ai arrêté Portainer.

J'ai gardé sa sauvegarde et son volume pendant quelque temps. Un retour arrière restait donc possible.

Conclusion : le scan m'a fait réfléchir

Je n'ai pas été déçu par Arcane. L'interface est agréable. Mes projets Compose sont enfin rangés dans un répertoire clair. Leur sauvegarde est plus simple. Leur restauration aussi.

Mais la vraie surprise est venue du scan de vulnérabilités.

La synthèse affichée par Arcane sur mon infrastructure. Le nombre de vulnérabilités m'a surpris.

Je ne regardais pas vraiment ces chiffres auparavant. Mes conteneurs fonctionnaient. Mes services répondaient. Je considérais donc que l'essentiel était fait.

Les récentes fuites de données m'ont donné à réfléchir. L'infrastructure professionnelle d'Appliman héberge des données clients précieuses. Leur protection est une responsabilité importante. Je ne veux pas attendre un incident pour renforcer la sécurité de cette infrastructure.

Arcane ne sécurise pas tout par magie. Un scan ne remplace ni les mises à jour, ni des sauvegardes testées, ni un accès distant correctement protégé. Mais il rend le risque visible. Il me donne une liste de travail concrète.

C'est aussi pour cela que j'ai migré. Je voulais mieux organiser mon Docker. J'ai finalement commencé à bétonner mon infrastructure.

Pour aller plus loin

• Documentation officielle de Portainer
• Dépôt GitHub de Portainer
• Documentation officielle d'Arcane
• Gestion des projets dans Arcane
• Environnements distants et mode Edge dans Arcane
• Protection mTLS des agents Edge
• Scans de vulnérabilités dans Arcane
• Dépôt GitHub d'Arcane