Arcane, c’est le nom d’une solution open source destinée à faciliter l’administration d’environnements Docker à partir d’une interface web moderne. Cette solution entre donc en concurrence directe avec des outils existants, et si je vous en parle aujourd’hui, c’est parce qu’elle monte vraiment en puissance.
Quand on gère un homelab ou une infrastructure avec des conteneurs, le fichier Docker Compose et la ligne de commande suffisent au début. Puis les stacks s’accumulent, les mises à jour d’images passent à la trappe, et vous perdez de vue ce qui tourne réellement sur votre serveur. C’est là que la solution Arcane intervient, avec une interface web open source pensée pour piloter vos projets Docker Compose, vos conteneurs, vos images, etc… depuis votre navigateur.
Dans cet article, je vous propose un tour d’horizon de la solution Arcane. Mais avant cela, nous verrons d’abord ce qu’est ce projet et en quoi il se distingue de Portainer, de Dockge et de Dockhand. Certains de ces outils ont d’ailleurs fait l’objet d’un article sur IT-Connect, mais ça me semble important d’en parler.
Pour les personnes pressées, voici la marche à suivre en cinq étapes :
Créez un dossier de projet, par exemple /opt/docker-compose/arcane, ainsi qu’un sous-dossier arcane-data pour les données persistantes.
Générez deux secrets de 32 octets avec la commande openssl rand -hex 32.
Créez le fichier docker-compose.yml à partir de l’image ghcr.io/getarcaneapp/manager:v2, en publiant le port 3552 et en montant le socket Docker.
Renseignez le fichier .env, en particulier la variable APP_URL qui doit correspondre exactement à l’URL utilisée dans le navigateur.
Lancez docker compose up -d, puis connectez-vous sur http://:3552 avec le compte arcane et le mot de passe arcane-admin.
Voilà pour la synthèse. Tous les détails sont disponibles dans la suite de cet article.
Qu’est-ce qu’Arcane ?
Arcane est une interface web de gestion Docker, le tout en open source (licence BSD 3-Clause). Elle s’installe dans un unique conteneur, se connecte à l’API Docker de votre hôte et vous donne la main sur l’ensemble des ressources : projets Docker Compose, conteneurs, images, réseaux, volumes, et même un cluster Docker Swarm. Côté technique, Arcane s’appuie sur un backend écrit en Go et l’image officielle est relativement légère : environ 124 Mo, avec un conteneur peu consommateur en ressources (au repos).
Sachez qu’avec Arcane, il n’existe pas d’édition payante ni de fonctionnalité réservée à une version entreprise. Tout ce que nous allons voir dans cet article, y compris le contrôle d’accès par rôles et l’authentification OIDC, est disponible dans la version gratuite. Même s’il n’est pas à exclure que cela évolue, c’est un élément différenciateur en comparaison d’autres outils comme Portainer et Dockhand.
Surtout, je trouve qu’Arcane évolue vite, très vite. Il y a plusieurs nouvelles versions par mois, et ce projet lancé en 2025 avance vraiment dans le bon sens, avec une communauté qui se construit progressivement.
Arcane, Portainer CE, Dockge et Dockhand : quelles différences ?
Arcane arrive sur un terrain déjà occupé par d’autres solutions, notamment certaines déjà évoquées sur IT-Connect. Voici un rapide comparatif.
CritèreArcanePortainer CEPortainer BEDockgeDockhandLicenceBSD 3-ClausezlibPropriétaire, clé de licenceMITBSL 1.1, bascule en Apache 2.0 en 2029Modèle économiqueAucune édition payanteGratuitGratuit jusqu’à 3 nœuds, payant au-delàGratuitGratuit pour un usage personnel, payant en entrepriseReprise en main des stacks existantesDécouverte automatique du répertoireImport limitéImport limitéRépertoire de stacks dédiéAdoption par scan d’un répertoireÉdition des fichiers Docker ComposeMulti-fichiers, validation de schémaÉditeur intégréÉditeur intégréÉditeur intégré, conversion depuis docker runÉditeur en ligne, mode visuel, vue graphe (Arcane ne propose pas ça)Prise en charge Docker SwarmOuiOuiOuiAbsenteAbsenteDétection des mises à jourPar empreinte, planifiable, exclusionsManuelleIndicateur de nouvelle versionMise à jour des images à la demandePlanifiable, application automatiqueScan de vulnérabilitésTrivy intégréAucun scanner intégréAucun scanner intégréAbsentTrivy et Grype, au choix ou les deuxContrôle d’accès par rôlesSix rôles intégrés, rôles personnalisésDeux rôles seulement (admin et user)Hiérarchie de rôles par environnement et par équipeAbsentRéservé à la version payanteAuthentification OIDCIntégréeFournisseur OAuth génériqueOAuth avec modèles, LDAP, Active Directory, mise en correspondance des groupesAbsenteIntégrée (LDAP et AD réservés à la version payante)Journal d’auditJournal d’événementsAbsentJournaux d’authentification et d’activité, export SyslogAbsentHistorique d’activitéMulti-hôtesAgents distantsEnvironnements multiplesEnvironnements multiples et gouvernanceAgents depuis la version 1.4Agent Hawser et TLSRythme de publicationRythme de publication élevé (certainement le plus actif de la catégorie)RégulierRégulierDernière version en mars 2025Régulier
Arcane et Dockhand sont vraiment les deux outils qui sortent du lot pour l’administration Docker d’un Homelab. Portainer reste une valeur sûre, et il mérite d’être étudié pour un Homelab (car on a souvent peu de nœuds), tandis que Dockge semble plutôt au point mort (d’ailleurs c’est un projet de Louis Lam, l’auteur d’Uptime Kuma). Il y a une autre solution, que je me dois de citer pour être complet, mais que je n’ai pas encore testée, c’est Komodo.
Prérequis
Pour suivre ce tutoriel, il vous faut :
Une machine Linux (si vous voulez le même environnement que moi) avec Docker et Docker Compose installés. Si ce n’est pas encore le cas, notre chapitre sur l’installation de Docker sur Linux vous guidera.
Un accès en ligne de commande avec les droits sudo.
Facultatif, mais recommandé pour la seconde partie : un reverse proxy Traefik déjà en place, avec un réseau Docker externe partagé.
Arcane s’appuie sur l’API Docker de l’hôte. Cela signifie qu’il aura besoin d’un accès en écriture au socket Docker, ce qui n’est pas anodin sur le plan de la sécurité. Nous verrons plus loin comment limiter cette exposition, avec une technique déjà évoquée à plusieurs reprises.
Installer Arcane avec Docker Compose
Commençons par le déploiement le plus simple, avec le port d’écoute publié directement sur l’hôte. C’est la configuration idéale pour tester l’outil rapidement (sans reverse proxy).
Préparer l’arborescence
J’ai l’habitude de ranger toutes mes stacks sous /opt/docker-compose, avec un sous-dossier par projet. Nous allons donc créer le dossier d’Arcane et le sous-dossier destiné à recevoir ses données :
# Créer le dossier du projet et celui des données persistantes
sudo mkdir -p /opt/docker-compose/arcane/arcane-data
cd /opt/docker-compose/arcane
# Attribuer le dossier de données à votre utilisateur (ici l’UID/GID 1000)
sudo chown -R 1000:1000 arcane-data
Depuis la version 2.0, le conteneur Arcane démarre en root pour préparer son environnement d’exécution, puis bascule sur un utilisateur non privilégié. Si le dossier de données appartient à root alors que le processus tourne sous un autre compte, l’application ne pourra pas écrire sa base de données. En attribuant le dossier à votre propre utilisateur (généralement l’UID 1000 sur Debian et Ubuntu), vous réglez le problème et vous gardez la possibilité de manipuler les fichiers en SSH sans passer par sudo.
Générer les secrets
Arcane a besoin de deux secrets de 32 octets : une clé de chiffrement pour les données sensibles stockées en base et une clé de signature pour les jetons de session. Je vous propose d’utiliser la commande openssl pour le faire :
# Générer la valeur d’ENCRYPTION_KEY
openssl rand -hex 32
30bfabc62ff88fc89a07a3b4162ec6f0b22d55d41f3264733ec5b1bab3714339
# Générer la valeur de JWT_SECRET
openssl rand -hex 32
73557fccb25aac9330571204bdb23098366c871f9dc4897f84933488b6327d65
Attention : les deux valeurs ci-dessus sont là pour illustrer le format attendu. Générez impérativement les vôtres.
Nous allons utiliser ces valeurs dans le fichier .env, juste après.
Le fichier docker-compose.yml
Voici le fichier /opt/docker-compose/arcane/docker-compose.yml que vous devez créer dans le répertoire du projet :
services:
arcane:
image: ghcr.io/getarcaneapp/manager:v2
container_name: arcane
restart: unless-stopped
ports:
– “3552:3552”
environment:
– APP_URL=${APP_URL}
– ENCRYPTION_KEY=${ENCRYPTION_KEY}
– JWT_SECRET=${JWT_SECRET}
– PROJECTS_DIRECTORY=${PROJECTS_DIRECTORY}
– PUID=${PUID}
– PGID=${PGID}
– TZ=${TZ}
volumes:
– /var/run/docker.sock:/var/run/docker.sock
– ./arcane-data:/app/data
– /opt/docker-compose:/opt/docker-compose
cgroup: host
healthcheck:
test: [“CMD”, “/app/arcane”, “health”, “–timeout”, “2s”]
interval: 30s
timeout: 5s
retries: 3
start_period: 15s
Vous avez la configuration sous les yeux, mais voici quelques explications pour bien comprendre ce qui a été déclaré ci-dessus :
Le montage de /opt/docker-compose. C’est le mécanisme le plus important à comprendre. Arcane pilote vos stacks Docker Compose en appelant l’API Docker de l’hôte, et les chemins relatifs contenus dans vos fichiers (./config, ./data) sont résolus par le démon Docker côté hôte, pas à l’intérieur du conteneur Arcane.
cgroup: host. Cette option améliore la détection par Arcane de son propre conteneur, ce qui conditionne sa capacité à se mettre à jour lui-même. Vous pouvez la retirer si vous préférez ne pas partager le namespace cgroup de l’hôte.
Le socket Docker. Il ne peut pas être monté en lecture seule. Arcane crée, démarre, arrête et supprime des conteneurs, il a donc besoin d’un accès en écriture à l’API. Nous verrons juste après comment restreindre cet accès.
Le fichier .env
Le fichier avec les variables d’environnement contient les informations susceptibles de changer d’une installation à une autre. Créez le fichier ici : /opt/docker-compose/arcane/.env, aux côtés du fichier Docker Compose. Voici le code à insérer (et à adapter !).
# URL EXACTE utilisée dans le navigateur pour joindre Arcane (schéma + hôte + port)
APP_URL=http://192.168.100.10:3552
# Secrets générés à l’étape précédente
ENCRYPTION_KEY=30bfabc62ff88fc89a07a3b4162ec6f0b22d55d41f3264733ec5b1bab3714339
JWT_SECRET=73557fccb25aac9330571204bdb23098366c871f9dc4897f84933488b6327d65
# Dossier contenant vos stacks Docker Compose
PROJECTS_DIRECTORY=/opt/docker-compose
# UID/GID de l’utilisateur propriétaire de /opt/docker-compose
PUID=1000
PGID=1000
TZ=Europe/Paris
Pour connaître les valeurs à renseigner dans PUID et PGID, interrogez simplement votre compte utilisateur :
id -u
1000
id -g
1000
Sur Debian et Ubuntu, le premier compte créé à l’installation porte l’UID et le GID 1000, ce qui est le cas ici.
Démarrer Arcane et se connecter
Il ne reste plus qu’à lancer la stack. Bon, là, c’est classique :
docker compose up -d
Au premier démarrage, Arcane crée un compte administrateur local et l’affiche dans ses journaux. Vous devriez voir quelque chose comme ceci :
docker compose logs arcane | grep -i “Username\|Password”
arcane | Jul 27 17:50:46.827 INF 🔑 Username: arcane
arcane | Jul 27 17:50:46.827 INF 🔑 Password: arcane-admin
arcane | Jul 27 17:50:46.827 INF ⚠️ User will be prompted to change password on first login
Les identifiants par défaut sont donc l’utilisateur arcane et le mot de passe arcane-admin. La dernière ligne le confirme, le changement de mot de passe est imposé dès la première connexion. Rendez-vous ensuite sur http://:3552 et connectez-vous.
Une fois le nouveau mot de passe défini, les journaux en gardent la trace, ce qui permet de vérifier que l’opération est bien passée :
arcane | Jul 27 17:52:54.704 INF Incoming request request.method=POST request.host=192.168.100.10 request.path=/api/auth/password response.latency=295.971778ms response.status=200
Au passage, vous constaterez que les journaux d’Arcane sont structurés et détaillent chaque requête reçue avec sa méthode, sa route, et son code de réponse. Moi je dis, pour le troubleshooting, c’est bon à prendre !
Exposer Arcane en HTTPS derrière Traefik
Publier le port 3552 en clair sur le réseau convient pour un test, mais pas pour un usage quotidien. Voyons la version de production, avec Arcane placé derrière Traefik et joignable en HTTPS. Le port n’est plus publié sur l’hôte, tout passe par le reverse proxy. L’adresse utilisée est : https://arcane.it-connectlab.fr.
Le fichier Docker Compose adapté
Pour publier Arcane avec Traefik, quelques labels Docker suffisent ! Voici le fichier Docker Compose adapté.
services:
arcane:
image: ghcr.io/getarcaneapp/manager:v2
container_name: arcane
restart: unless-stopped
environment:
– APP_URL=${APP_URL}
– TRUSTED_PROXIES=${TRUSTED_PROXIES}
– ENCRYPTION_KEY=${ENCRYPTION_KEY}
– JWT_SECRET=${JWT_SECRET}
– PROJECTS_DIRECTORY=${PROJECTS_DIRECTORY}
– PUID=${PUID}
– PGID=${PGID}
– TZ=${TZ}
volumes:
– /var/run/docker.sock:/var/run/docker.sock
– ./arcane-data:/app/data
– /opt/docker-compose:/opt/docker-compose
cgroup: host
healthcheck:
test: [“CMD”, “/app/arcane”, “health”, “–timeout”, “2s”]
interval: 30s
timeout: 5s
retries: 3
start_period: 15s
networks:
– frontend
labels:
– traefik.enable=true
– traefik.docker.network=frontend
– traefik.http.routers.arcane-https.rule=Host(`arcane.it-connectlab.fr`)
– traefik.http.routers.arcane-https.entrypoints=websecure
– traefik.http.routers.arcane-https.tls=true
– traefik.http.routers.arcane-https.tls.certresolver=ovhcloud
– traefik.http.services.arcane-https.loadbalancer.server.port=3552
networks:
frontend:
external: true
Et le fichier .env correspondant. Vous remarquerez que j’ai adapté la valeur de la variable APP_URL. La variable TRUSTED_PROXIES a été ajoutée en complément.
# URL publique, SANS le port interne 3552
APP_URL=https://arcane.it-connectlab.fr
# Sous-réseau du réseau Docker partagé avec Traefik
TRUSTED_PROXIES=10.200.1.0/24
ENCRYPTION_KEY=30bfabc62ff88fc89a07a3b4162ec6f0b22d55d41f3264733ec5b1bab3714339
JWT_SECRET=73557fccb25aac9330571204bdb23098366c871f9dc4897f84933488b6327d65
PROJECTS_DIRECTORY=/opt/docker-compose
PUID=1000
PGID=1000
TZ=Europe/Paris
Quelques mots à propos de TRUSTED_PROXIES : Arcane limite le débit sur ses points d’authentification (connexion, rafraîchissement de jeton, callback OIDC) en se basant sur l’adresse IP du client. Derrière un reverse proxy, sans cette variable, toutes les requêtes semblent provenir de la même adresse : la protection contre les attaques par force brute perd son intérêt, et un utilisateur légitime peut se retrouver bloqué à cause du trafic généré par les autres. La valeur autorise Arcane à faire confiance à l’en-tête X-Forwarded-For transmis par Traefik.
Autre point, toujours à propos de cette même variable : ne recopiez surtout pas la plage d’adresses au hasard. Ici, j’ai indiqué l’adresse du réseau Docker correspondant à mon réseau frontend (qui est un sous-réseau personnalisé). Interrogez donc directement Docker :
docker network inspect frontend –format ‘{{range .IPAM.Config}}{{.Subnet}}{{end}}’
10.200.1.0/24
Limiter l’accès au socket Docker
Monter /var/run/docker.sock dans un conteneur revient à lui donner les clés de l’hôte. Pour réduire la surface d’attaque, vous pouvez intercaler un Docker Socket Proxy qui filtre les appels autorisés. Arcane documente cette configuration sur une page dédiée, et voici le jeu d’autorisations qu’elle recommande :
services:
arcane-socket-proxy:
image: ghcr.io/tecnativa/docker-socket-proxy:latest
container_name: arcane-socket-proxy
restart: unless-stopped
environment:
# Nécessaire au fonctionnement d’Arcane
– CONTAINERS=1
– IMAGES=1
– NETWORKS=1
– VOLUMES=1
– INFO=1
– EVENTS=1
– VERSION=1
– PING=1
– EXEC=1
– POST=1
# Indispensable pour conserver la détection des mises à jour (voir plus bas)
– DISTRIBUTION=1
# Refusé explicitement
– AUTH=0
– SECRETS=0
– BUILD=0
– COMMIT=0
– CONFIGS=0
– SWARM=0
– SERVICES=0
– TASKS=0
– NODES=0
– PLUGINS=0
– SESSION=0
– SYSTEM=0
volumes:
– /var/run/docker.sock:/var/run/docker.sock:ro
networks:
– arcane-socketproxy
security_opt:
– no-new-privileges:true
Côté service Arcane, retirez le montage du socket et ajoutez la variable DOCKER_HOST=tcp://arcane-socket-proxy:2375, puis rattachez le conteneur au réseau interne du proxy.
Attention : l’exemple de la documentation officielle place DISTRIBUTION=0. Cependant, cette autorisation est précisément celle qui permet à Arcane d’inspecter les images et de vérifier les mises à jour. En la laissant à zéro, vous conservez la gestion des conteneurs mais vous perdez la détection des nouvelles versions, c’est-à-dire l’une des fonctions les plus intéressantes de l’outil. C’est la raison pour laquelle je la passe à 1 dans la configuration ci-dessus.
En réalité, vous devez ajuster la configuration en fonction de ce que vous souhaitez utiliser ou non comme fonctionnalités dans Arcane. Quelques précisions pour vous aiguiller :
BUILD=0 bloque le point de terminaison pour build les images.
SWARM, SERVICES, NODES et TASKS à zéro rendent la section Cluster inopérante (donc pas de Docker Swarm)
POST=1 reste indispensable. Sans lui, Arcane ne peut ni démarrer, ni arrêter, ni créer quoi que ce soit.
EXEC=1 est nécessaire au terminal web intégré. À retirer si vous n’en avez pas l’usage, c’est l’autorisation la plus sensible du lot après POST.
Découvrir l’interface d’Arcane
Une fois connecté, l’interface se présente avec une barre latérale organisée en quatre blocs : Gestion (tableau de bord, projets, environnements, personnalisation), Ressource (conteneurs, images, mises à jour, réseaux, volumes), Essaim (cluster Swarm) et Administration (journal d’événements, réglages).
Le tableau de bord
Le tableau de bord donne l’état de santé de l’hôte en un écran : nombre de mises à jour disponibles, conteneurs en cours d’exécution et arrêtés, images utilisées et inutilisées, volumes, puis la consommation processeur, mémoire et disque. Sur ma machine de test, Arcane a immédiatement remonté 23 mises à jour d’images en attente sur 40 conteneurs, et 75 images inutilisées sur 115 pour un total de 41,48 Go. Il y a du tri à faire !
Les environnements
Arcane se connecte à un ou plusieurs environnements où sont exécutés les conteneurs. Celui qui existe par défaut, nommé « Local Docker », correspond au socket monté dans le conteneur : c’est votre hôte local. Vous pouvez en déclarer d’autres pour piloter des hôtes Docker distants, via un agent à installer sur la machine cible. C’est ce qui permet de centraliser plusieurs serveurs dans une seule interface, sans ouvrir l’API Docker sur le réseau.
Chaque environnement dispose de sa configuration où tout ça est réparti sur cinq onglets : stockage et limites, paramètres Docker, paramètres de sécurité, automatisations et synchronisations Git. C’est dans le premier que vous retrouvez le répertoire des projets déclaré via PROJECTS_DIRECTORY. C’est vraiment complet.
Gérer ses projets Docker Compose
La découverte automatique des stacks existantes
À son lancement, Arcane parcourt le répertoire déclaré dans PROJECTS_DIRECTORY et référence chaque sous-dossier contenant un fichier Compose comme un projet. Ainsi, vos stacks remontent toutes seules. Sur mon serveur, il a ainsi trouvé une trentaine de projets sans aucune intervention de ma part. Ce qu’il faut bien comprendre, c’est que vous n’avez rien à importer ni à recréer : vos stacks existantes remontent telles quelles, avec leur répertoire de travail, leur statut, leur nombre de services. Ce n’est pas toujours le cas, par exemple avec Dockhand, il y a une notion d’adoption avec les projets en dehors de l’outil.
Créer un nouveau projet
La création d’un projet ouvre deux éditeurs côte à côte : le fichier Docker Compose à gauche, le fichier .env à droite. Sauf si vous passez en mode “Espace de travail”, où vous aurez l’éditeur à droite et l’arborescence de fichiers à gauche (vous avez un exemple plus loin dans l’article).
L’éditeur en ligne valide la syntaxe en direct, notamment pour voir si cela respecte le schéma Docker Compose, et affiche en bas de page le nombre d’erreurs et d’avertissements. C’est un point important car on se rapproche d’une expérience d’édition dans VS Code (même si cela ne va pas aussi loin). L’exemple ci-dessous est proposé par défaut par Arcane, afin de ne pas partir de zéro, mais vous pouvez aussi créer des templates de Docker Compose. Cela peut être pratique si vous utilisez toujours Traefik pour préconfigurer les labels.
Modifier un projet existant
L’édition d’un projet existant va plus loin que le simple couple docker-compose.yml et .env. Le panneau de gauche liste tous les fichiers du projet, autorise l’ajout d’un fichier et permet de téléverser des fichiers de configuration annexes. Les fichiers principaux sont signalés via un cadenas, pour éviter une suppression accidentelle. Vous pouvez arrêter une stack, la redémarrer, la redéployer et même pull de nouveau l’image (via le bouton “Tirer”, on aurait pu se passer de cette traduction).
Consulter les journaux en temps réel
Les journaux sont agrégés au niveau de chaque projet, avec le nom du service en préfixe, l’horodatage et la distinction entre STDOUT et STDERR. C’est propre et suffisant pour du dépannage courant. Si vous cherchez une recherche plein texte performante sur l’historique et des alertes sur motif, un outil dédié comme Dozzle reste plus adapté. D’ailleurs, les deux cohabitent très bien. En fait, Arcane (dans sa version actuelle), ne permet pas d’afficher les logs de plusieurs conteneurs / stacks en même temps.
Administrer les conteneurs et les images
La vue des conteneurs
La liste des conteneurs affiche pour chacun son image, son statut, s’il y a une mise à jour en attente ou pas, et sa consommation processeur. En cliquant sur l’indicateur de mise à jour, une fenêtre détaille la nature de la mise à jour détectée. À ce propos, un conteneur qui tourne sur latest peut très bien être en retard de plusieurs semaines sans qu’aucun changement de tag ne le signale. Arcane compare l’empreinte locale à celle du registre et vous indique qu’il existe des correctifs de sécurité ou de bugs disponibles, en affichant l’empreinte de référence, ce qui permet de détecter les updates de façon fiable.
L’affichage est personnalisable, que ce soit au niveau des colonnes visibles ou pour regrouper les conteneurs par stack Docker Compose.
La gestion des images
La vue Images liste vos images avec un ensemble d’informations, dont le dépôt, le tag, le conteneur qui les utilise, l’indicateur de mise à jour, et les résultats de l’analyse de vulnérabilités. Vous pouvez aussi filtrer la liste pour afficher uniquement les images utilisées, ou à contrario, celles qui ne le sont pas. Sur ma machine de tests, il a identifiés des dizaines d’images inutilisées, autant d’espace disque à récupérer.
Rechercher et télécharger une image
Arcane peut télécharger une image Docker au moment de lancer un conteneur ou une stack Docker Compose pour la première fois, mais pas seulement. En effet, il intègre une fonction de recherche dans les registres pour télécharger l’image en local. Même si la recherche reste basique comparée à l’interface de Docker Hub, c’est pratique si vous savez exactement ce que vous souhaitez télécharger.
Construire une image
Fonction plus inattendue pour une interface de ce type : Arcane sait construire des images. L’espace de travail propose un explorateur de fichiers dans lequel vous déposez votre Dockerfile et son contexte, ou bien vous pointez vers un dépôt Git distant. Vous choisissez ensuite si l’image doit être chargée localement ou poussée vers un registre, et vous lancez la construction.
Mais attention, pour cette feature, il faut ajouter le montage du dossier au fichier Docker Compose :
# Espace de travail des builds d’images
– ./builds:/builds
Suivre et automatiser les mises à jour
La gestion des mises à jour, et leur automatisation, cela fait partie des fonctions attendues lorsque l’on adopte un outil d’administration pour Docker. La bonne nouvelle, c’est qu’Arcane dispose d’une vue dédiée qui centralise l’ensemble des mises à jour disponibles, avec un affichage possible entre le niveau conteneur et le niveau projet. Vous avez le choix pour déclencher les mises à jour “par ligne”, par lot, ou de tout mettre à jour d’un coup (attention aux éventuels effets de bord). Chaque entrée indique l’image concernée, l’empreinte actuelle, la dernière empreinte publiée et la date de vérification. Arcane a une routine préconfigurée pour aller vérifier de façon régulière la disponibilité d’une mise à jour.
Planifier les vérifications et les mises à jour
Le sujet des mises à jour est l’occasion de basculer vers l’onglet Automatisations. En effet, il y a deux mécanismes distincts pour automatiser la gestion des mises à jour d’images Docker, et il est utile de bien les différencier :
Auto Update applique les mises à jour, selon une planification exprimée en syntaxe cron. Une liste d’exclusion permet de désigner les conteneurs à laisser tranquilles (vous pouvez le faire avec des labels Docker également).
Image Update Watcher se contente de vérifier les registres, sans rien appliquer.
Vous avez donc le choix, et vous pouvez garder la main sur les projets sensibles.
Dans les faits, Arcane vient donc empiéter sur le terrain de Watchtower et de What’s Up Docker.
Labels supportés pour les mises à jour via Arcane
Trois labels sont documentés du côté d’Arcane (getarcane.app/docs/guides/updates), tous sous l’espace de noms com.getarcaneapp.arcane.*. Voici comment les utiliser au niveau de vos projets Docker Compose :
labels:
# Exclut le conteneur des mises à jour automatiques
# Activer : true, 1, yes, on / Désactiver : false, 0, no, off
– com.getarcaneapp.arcane.updater=false
# Ordre de redémarrage : liste de noms de conteneurs séparés par des virgules
– com.getarcaneapp.arcane.depends-on=db,redis
# Signal d’arrêt personnalisé au lieu de SIGTERM
– com.getarcaneapp.arcane.stop-signal=SIGINT
Tout en sachant que le label est prioritaire sur l’interface. Un conteneur portant un label updater explicite aura une mention explicite sur l’interface web. Je trouve que le label depends-on est particulièrement utile pour un couple applicatif + base de données, afin que le redémarrage se fasse dans le bon ordre après une mise à jour.
Recevoir des notifications
Le volet Notifications d’Arcane est vraiment très complet, car il prend en charge de nombreux canaux de communication. Cela va du plus basique, à savoir l’e-mail, à des méthodes plus modernes : Discord, Gotify, Matrix, Ntfy, Pushover, Signal, Slack et Telegram. À cela s’ajoute la possibilité de pouvoir déclencher un webhook.
Maintenant, la question que l’on peut se poser est : dans quels cas sont envoyées les notifications ? Actuellement, vous pouvez activer ou désactiver les notifications (par canal) pour les événements suivants :
Mise à jour de l’image détectée
Conteneur mis à jour
Rapport de suppression du système
Vulnérabilité trouvée avec un patch disponible
Conteneur redémarré automatiquement suite à un état incorrect (unhealth)
Analyser les vulnérabilités des images avec Trivy
Voici une fonction qui, à mon sens, place Arcane dans une catégorie à part : l’intégration de Trivy, le scanner de vulnérabilités d’Aqua Security. Ceci permet de scanner les images Docker et d’agréger les résultats au sein d’Arcane, vis-à-vis des images que vous utilisez. Il est à noter que c’est une fonctionnalité disponible également avec Dockhand (qui propose même 2 moteurs d’analyse différents).
Le tableau liste chaque vulnérabilité avec son identifiant CVE (avec un lien cliquable vers la base du NIST), le paquet concerné, la sévérité, la version installée, la version qui corrige le problème et l’image touchée, identifiée par son empreinte. La première fois, c’est à vous de lancer une analyse. Il y a un bouton “Analyser toutes les images” prévu pour cela et qui lance une analyse image par image en tâche de fond. Ensuite, la présence d’une CVE critique dans une image ne signifie pas nécessairement que votre service est menacé, tout dépend du paquet concerné et de son usage réel.
Note : Trivy a lui-même été la cible d’une attaque sur sa chaîne d’approvisionnement en mars 2026, avec la publication de versions malveillantes (une grosse affaire à l’époque !). Cet incident, que j’avais couvert dans un article dédié, rappelle qu’un outil de sécurité fait partie de votre surface d’attaque, y compris lorsqu’il est embarqué dans une autre application.
Réseaux, ports et topologie
La vue Topologie représente sous forme de graphe les réseaux Docker et les conteneurs qui y sont rattachés, avec leur adresse IP. Un conteneur connecté à plusieurs réseaux affiche ses différentes adresses, ce qui rend immédiatement lisible une architecture avec un réseau frontal partagé et des réseaux internes cloisonnés. Chaque nœud est cliquable pour accéder directement au détail de la ressource (sur sa page dédiée).
C’est le genre de vue que l’on ne cherche pas activement mais qui devient précieuse au moment de comprendre pourquoi deux conteneurs ne peuvent pas communiquer entre eux. Cela est mis à jour dynamiquement, donc c’est encore mieux !
Tout aussi utile, la vue Ports. Elle inventorie tous les ports de l’environnement en distinguant deux états :
Publié : pour un port réellement accessible depuis l’hôte,
Exposé : pour un port déclaré par l’image mais non publié. Elle indique aussi l’adresse d’écoute, ce qui permet de repérer d’un coup d’œil un service lié à 0.0.0.0 alors qu’il devrait rester sur 127.0.0.1.
Pour un audit rapide de ce que votre machine expose réellement, cette vue vaut mieux qu’un docker ps ou l’analyse des réseaux Docker….
Des fonctionnalités pour les entreprises dans Arcane
Les rôles intégrés (RBAC)
La gestion des accès basée sur les rôles, c’est natif dans Arcane. Le RBAC natif et gratuit, c’est vraiment rare ! Souvent, c’est ce qui fait la différence entre un outil gratuit et un outil payant… Arcane propose six rôles prédéfinis, avec un décompte sur les permissions associées qui donne une idée de leur granularité :
RôlePortéePermissionsAdminAccès admin complet137EditorLecture et écriture sur les ressources Docker105No-Shell EditorÉditeur sans accès au shell interactif des conteneurs104DeployerDéploiement et cycle de vie des conteneurs et projets45ViewerLecture seule sur toutes les ressources42MonitorObservabilité uniquement : journaux, tableaux de bord, événements22
Voici un aperçu de l’état par défaut.
Même s’il y a ces rôles prédéfinis, vous pouvez créer des rôles personnalisés. Pour chaque rôle, vous pouvez spécifier le nom et les autorisations associées. Certaines permissions sont globales à la plateforme, tandis que d’autres fonctionnent par environnement Docker.
L’authentification OIDC
Pour couronner le tout, Arcane est capable de déléguer l’authentification à un fournisseur OIDC externe, qu’il s’agisse de Keycloak, d’Authentik, d’Okta ou d’un autre. La configuration est complète et s’appuie sur les mécanismes habituels pour mettre en place ce type d’authentification (Client ID, client Secret, etc.). Vous pouvez aussi personnaliser les revendications, ce qui permet, par exemple, de faire correspondre vos groupes existants aux rôles d’Arcane.
Une option permet de lier les identités OIDC à des comptes locaux déjà créés. Par ailleurs, il est recommandé de conserver l’authentification locale activée en secours, ce qui est un bon réflexe : si votre fournisseur OIDC tombe, vous gardez une porte d’entrée pour accéder à Arcane (surtout s’il tourne sur Docker aussi…).
Les clés API
Pour piloter Arcane depuis un script ou une chaîne d’intégration CI/CD externe, vous pouvez créer des clés d’API avec un jeu de permissions à la carte. Un petit détail intéressant : vous ne pouvez pas accorder à une clé une permission que vous ne disposez pas vous-même. C’est une protection essentielle contre l’élévation de privilèges.
Variables globales et personnalisation
La section Personnalisation regroupe quatre briques : les modèles de projets, les registres de conteneurs avec leur authentification, les variables globales et les dépôts Git utilisés pour la synchronisation. C’est ici que vous pouvez déclarer un registre supplémentaire sur lequel récupérer des images Docker. Vous pouvez aussi créer des templates de fichier Docker Compose que vous appelez ensuite dans vos projets.
Les variables globales permettent de gagner du temps au quotidien. Le principe : vous définissez une clé et une valeur, une fois, et elles deviennent disponibles pour vos projets. Un exemple typique : votre nom de domaine, que vous répétez aujourd’hui dans chaque fichier .env. Vous pouvez limiter la portée à certains environnements ou l’ouvrir à tous, y compris ceux que vous ajouterez plus tard, et coller un fichier .env entier plutôt que de saisir les entrées une par une.
Le bouton “Secret” chiffre la valeur en base et la masque après enregistrement. C’est précisément à cela que sert la variable ENCRYPTION_KEY que nous avons générée à l’installation. Cette section est utile si vous avez l’habitude de partager certaines informations entre X projets.
Le reste des réglages couvre l’historique du centre d’activités (le bouton en haut à gauche ouvre un panneau latéral avec l’état des dernières tâches), les fournisseurs d’authentification, les clés API, les paramètres de construction, les timeouts, les notifications, les utilisateurs, les webhooks entrants et la fréquence des tâches planifiées. On a déjà vu plus en détail certaines de ces sections.
Conclusion
Début 2026, j’ai présenté la solution Dockhand pour l’administration de Docker. Cette solution m’avait impressionnée. Mais aujourd’hui, je dois avouer qu’entre Dockhand et Arcane, mon cœur balance. Arcane évolue vite et continuellement, avec déjà beaucoup de fonctionnalités natives en allant jusqu’à l’OIDC et au RBAC. Le tout en open source. C’est vraiment un outil à suivre et à tester ! Je vous en parlerai prochainement dans une vidéo complète.
Qu’en pensez-vous ?
Cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Mon obsession depuis près de 15 ans ? Rendre l’administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu’un métier, l’IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.