DockPanel est un panel d’administration serveur self-hosted qui promet de gérer sites web, bases de données, apps Docker, Git deploy, DNS, mail, sauvegardes et sécurité depuis une seule interface. Après un vrai essai dans une sandbox Linux, mon verdict est simple : l’idée est solide et certaines briques fonctionnent déjà, mais je ne le mettrais pas encore en production sans phase pilote sérieuse.
DockPanel, c’est quoi ?
DockPanel vise le même territoire que HestiaCP, CloudPanel ou aaPanel, mais avec une approche plus moderne : un backend et un agent en Rust, une interface React, une logique très orientée Docker, et une CLI pour automatiser l’exploitation.
La promesse est large. Dans le README, le projet annonce notamment :
| Élément | Ce que DockPanel annonce |
|---|---|
| Stack | Rust, Axum, React 19, Vite, PostgreSQL |
| Usage | Sites, Docker apps, bases de données, mail, DNS, monitoring |
| Sécurité | WAF, Fail2Ban, durcissement SSH, scans CVE, SBOM |
| Automatisation | CLI, export YAML, Git deploy, webhooks |
| Licence | Business Source License 1.1, gratuit pour ses serveurs |
Dit autrement : DockPanel veut être le cockpit d’un serveur applicatif moderne. Pour un freelance DevOps, c’est exactement le genre d’outil qui fait gagner du temps si l’exécution suit.
Installation de DockPanel : ce que j’ai vraiment fait
Je n’ai pas seulement lu la fiche GitHub. J’ai cloné le dépôt, lu le README, le guide de contribution, les fichiers Cargo et le frontend, puis j’ai construit les parties disponibles dans mon environnement.
Le dépôt a été cloné à ce commit : d1e19b7.
Côté frontend, l’installation et le build React passent :
cd panel/frontend
npm ci
npm run build
Résultat observé : Vite produit bien une SPA découpée en chunks, avec des pages pour les sites, les bases de données, les apps, la sécurité, le monitoring, les backups, les logs, le mail et les intégrations. Le build a pris environ dix secondes après installation des dépendances. NPM signale aussi 6 vulnérabilités dans l’arbre JavaScript, dont 4 hautes, point à surveiller pour un outil d’administration.
Côté Rust, la CLI compile avec Rust 1.85. L’agent, lui, a nécessité Rust 1.96, car certaines dépendances récentes refusent Rust 1.85. Après installation de Rust stable via rustup, l’agent a compilé.
cargo build --manifest-path panel/cli/Cargo.toml
cargo build --manifest-path panel/agent/Cargo.toml
Premier blocage utile : l’agent refuse de démarrer si /var/run/docker.sock est absent. C’est cohérent pour un panel Docker, mais ça rend le mode découverte moins souple. Dans ma sandbox, il n’y avait pas de vrai daemon Docker. J’ai donc pu tester les fonctions agent qui ne parlent pas réellement à Docker, mais pas déployer une app Docker de bout en bout.
DockPanel à l’usage : création d’un site statique
Pour avoir un vrai cas d’usage, j’ai lancé l’agent DockPanel, la CLI, Nginx, puis j’ai créé un site statique scout.local.
La CLI répond d’abord avec un statut serveur réel : hostname, OS, kernel, uptime, CPU, RAM, disque et nombre de processus.
dockpanel status
Elle a ensuite exécuté un diagnostic système :
dockpanel diagnose
Résultat : DockPanel remonte correctement les problèmes opérationnels, par exemple Nginx absent avant installation, Docker non actif, Fail2Ban non actif, UFW non actif et absence de swap. C’est le genre de retour concret que j’attends d’un panel serveur, pas juste un dashboard décoratif.
J’ai ensuite installé Nginx dans la sandbox et créé un site statique :
dockpanel sites create scout.local --runtime static
Cette commande a vraiment produit quelque chose :
- un fichier Nginx dans
/etc/nginx/sites-enabled/scout.local.conf, - une racine web dans
/var/www/scout.local/public/, - un
index.htmlpar défaut, - un rechargement Nginx réussi après test de configuration.
La page servie répondait bien avec le contenu généré par DockPanel :
<h1>Welcome to scout.local</h1>
<p>Site is ready. Upload your files to replace this page.</p>
J’ai aussi lancé le frontend avec Vite et capturé l’écran de setup administrateur. L’interface est propre, sombre, simple, et va droit au but. On sent que le projet a déjà beaucoup de surface produit.
Ce que j’aime dans DockPanel
Le premier bon point, c’est la séparation agent, API, frontend et CLI. Pour un outil qui touche au système, c’est plus sain qu’un gros monolithe PHP qui exécute tout depuis le web.
La CLI est également une vraie bonne idée. Elle permet d’intégrer DockPanel dans des scripts, des runbooks ou une automatisation GitOps légère. Dans mon test, status, diagnose, apps templates et sites create donnent des sorties lisibles.
Autre point positif : le produit ne se limite pas à afficher des écrans. La création de site génère une vraie config Nginx, crée un répertoire web, teste la config, puis recharge Nginx. C’est concret.
J’aime aussi le volume de fonctionnalités prévues : templates Docker, sécurité, monitoring, sauvegardes, secrets, webhooks, export YAML. Même si tout n’a pas été validé de bout en bout dans ce test, la structure du code montre une ambition sérieuse.
Les limites de DockPanel
La première limite est la maturité opérationnelle. L’installation officielle suppose un serveur avec Docker, Nginx, privilèges root et les bons chemins système. C’est normal pour ce type d’outil, mais ça laisse peu de place à un mode local simple pour évaluer le produit.
Deuxième limite : l’agent dépend fortement de Docker dès le démarrage. Dans mon environnement sans daemon Docker, il ne démarre pas tel quel. J’ai dû contourner ce point pour tester les routes non Docker. Pour moi, un agent d’administration devrait pouvoir démarrer en mode dégradé et marquer seulement les fonctions Docker comme indisponibles.
Troisième limite : le frontend build bien, mais le run complet API plus base PostgreSQL plus agent demande plus de préparation que le README ne le laisse penser. Le docker-compose du panel existe, mais sans daemon Docker utilisable dans la sandbox, impossible de valider la partie bases, apps Docker et API web complète.
Enfin, le signal NPM sur les vulnérabilités frontend mérite un suivi. Sur un panel exposé à des admins, même une dépendance de build mérite d’être prise au sérieux.
Est-ce que DockPanel marche vraiment ?
Oui, partiellement et concrètement. Dans mon test, DockPanel a compilé, son frontend s’est lancé, sa CLI a interrogé l’agent, le diagnostic a détecté l’état réel de la machine, la liste des 152 templates d’apps est remontée, et la création d’un site statique a généré une config Nginx et une page web servie.
Non, je n’ai pas validé toute la promesse. Je n’ai pas pu déployer une app Docker, tester le Git deploy, la gestion mail, les sauvegardes, le DNS ou les scans CVE en conditions réelles, faute de daemon Docker dans l’environnement de test.
Le bon résumé : les fondations sont là, mais le produit doit être essayé sur un vrai VPS jetable avant toute décision de production.
Faut-il adopter DockPanel ?
Pour un homelab ou un VPS de test, je dirais : essayez DockPanel, surtout si vous aimez les panels modernes et l’automatisation CLI. Il y a assez de matière pour mériter un essai sérieux.
Pour un serveur client en production, mon verdict est plus prudent : attendre, ou lancer un pilote isolé. Le périmètre est très large, l’agent tourne avec des privilèges élevés, et les fonctions critiques méritent des tests longs.
Pour un freelance sécu et DevOps, DockPanel est intéressant comme laboratoire : il montre une voie moderne pour remplacer les vieux panels, avec Rust, React et une logique plus infra. Mais je ne le vendrais pas encore comme brique stable sans validation complète sur VPS.
FAQ
DockPanel peut-il remplacer HestiaCP ou CloudPanel ?
Peut-être, mais pas sans test. DockPanel a une ambition plus large, notamment Docker et CLI, mais il faut valider la stabilité sur un vrai serveur.
DockPanel nécessite-t-il Docker ?
Oui, en pratique. L’agent attend la présence de Docker, et beaucoup de fonctions clés tournent autour des apps conteneurisées.
DockPanel est-il prêt pour la production ?
Je le classerais plutôt en phase d’essai avancé. Il marche sur des fonctions concrètes, mais je recommande un VPS jetable, des backups et une revue sécurité avant un usage client.