Dokploy : le PaaS self-hosted qui promet beaucoup, mais qui a encore du chemin
Retour d'expérience après un test sur homelab — peut-il remplacer un k3s ?
TL;DR
Dokploy est une plateforme PaaS open-source basée sur Docker et Docker Swarm qui simplifie le déploiement d'applications sur vos propres serveurs. Après un test sur un homelab avec une dizaine d'applications et une stack de monitoring/logging, le constat est contrasté. L'interface web est agréable, le déploiement via webhooks Git fonctionne bien, et les fonctionnalités de base (certificats SSL, backups, bases de données managées) sont au rendez-vous. En revanche, dès qu'on sort de l'interface pour automatiser via de l'Infrastructure as Code, les choses se compliquent sérieusement. Peut-il remplacer un petit k3s pour réduire la complexité ? Pas aujourd'hui. Excellent pour déployer rapidement quelques applications, mais insuffisamment mature pour aller au-delà.
Qu'est-ce que Dokploy ?
Dokploy est un PaaS self-hosted et open-source (licence MIT), souvent présenté comme une alternative gratuite à Heroku, Vercel ou Netlify. Le projet, porté principalement par un développeur (Siumauricio), cumule aujourd'hui plus de 31 000 étoiles sur GitHub et plus de 6 millions de téléchargements sur Docker Hub. Il repose sur une stack technique claire : Docker pour la conteneurisation, Docker Swarm pour l'orchestration multi-nœuds, et Traefik comme reverse-proxy avec gestion automatique des certificats Let's Encrypt.
L'installation tient en une commande curl | sh sur un VPS, ce qui donne accès en quelques minutes à un dashboard web sur le port 3000. Sous le capot, Dokploy déploie trois services Swarm : l'application elle-même, une base PostgreSQL interne, et un Redis.
Contexte du test
Ce retour d'expérience s'appuie sur un déploiement réel en homelab : un nœud unique hébergeant une dizaine d'applications, accompagné d'une stack de monitoring et de logging.
La question de départ était simple : est-ce que Dokploy peut remplacer un petit k3s ? L'idée étant de réduire la complexité opérationnelle — Kubernetes, même dans sa version allégée, reste Kubernetes, avec sa courbe d'apprentissage, ses CRDs, ses manifestes YAML et son écosystème d'outils à maîtriser. Dokploy promettait une approche plus légère pour un périmètre similaire : déployer des applications conteneurisées, gérer des bases de données, exposer des services avec du TLS, le tout piloté par une interface web ou de l'IaC.
L'objectif du test était donc double : évaluer Dokploy comme outil de déploiement au quotidien via l'interface, puis tenter d'industrialiser la configuration via de l'Infrastructure as Code (Ansible et Terraform) pour voir si on pouvait atteindre le même niveau d'automatisation qu'avec k3s. C'est sur ce second volet que les limites sont apparues.
Ce que Dokploy fait bien
Déploiement d'applications
Dokploy supporte le déploiement depuis GitHub, GitLab, Bitbucket et Gitea, avec déploiement automatique sur push via webhook. Le support des méthodes de build est varié : Nixpacks (détection automatique du langage), Heroku Buildpacks, ou Dockerfile personnalisé. On peut aussi déployer directement une image Docker ou un fichier Docker Compose.
En pratique, le workflow est fluide : on connecte son dépôt Git, on sélectionne la branche, et Dokploy gère le build et le déploiement. Pour une application standard (Node.js, Python, Go, PHP), ça fonctionne sans friction notable. Un point à noter cependant : la configuration du webhook côté GitLab (ou autre provider Git) reste une étape manuelle post-configuration. Dokploy ne provisionne pas automatiquement le webhook dans votre dépôt — il faut aller le créer soi-même. Ça fonctionne bien une fois en place, mais sur une dizaine d'applications, la manipulation devient répétitive. Et surtout, cette URL de webhook n'est pas récupérable via l'API (on y reviendra), ce qui empêche d'automatiser cette étape.
Gestion des certificats SSL
L'intégration Traefik fait le travail : on déclare un domaine dans l'interface, on coche HTTPS, et Let's Encrypt provisionne le certificat automatiquement. Le renouvellement est géré de manière transparente. C'est un gain de temps réel par rapport à la gestion manuelle de Certbot ou d'un reverse-proxy Nginx.
Bases de données managées
Dokploy propose la création en un clic de PostgreSQL, MySQL, MariaDB, MongoDB et Redis. Les volumes sont persistés automatiquement. La fonctionnalité de backup automatisé vers un stockage externe (S3 compatible) est un vrai plus pour un outil de cette catégorie.
Monitoring intégré
Le dashboard affiche en temps réel la consommation CPU, mémoire, réseau et stockage par conteneur — essentiellement un docker stats habillé d'une interface web. Pour un suivi basique, c'est suffisant : on voit d'un coup d'œil si un conteneur consomme anormalement ou si le nœud est sous pression. Mais c'est aussi là que s'arrête le confort. Dès qu'on veut passer à un monitoring plus professionnel — historisation des métriques, alerting, corrélation de logs, dashboards personnalisés — il faut déployer sa propre stack (Grafana, Prometheus, Loki, etc.), et c'est là que les choses se corsent (on y reviendra dans la section sur les limites).
Templates one-click
Dokploy propose une bibliothèque de templates pour déployer des outils open-source populaires (Supabase, Plausible, PocketBase, Cal.com, etc.) en un clic. Pour bootstrapper un homelab ou un environnement de développement, c'est un gain de temps appréciable.
Là où ça se complique
L'API : un mur opaque
C'est probablement le point le plus frustrant. Dokploy expose une API générée automatiquement depuis son routeur tRPC via le package @dokploy/trpc-openapi. Sur le papier, un Swagger est disponible. En pratique, c'est une autre histoire.
Le problème fondamental est documenté dans une issue GitHub (#2524) ouverte par un développeur qui souhaitait créer un provider Terraform : les schémas de réponse de l'API sont génériques. La spécification OpenAPI ne décrit pas la structure réelle des données renvoyées. On obtient un "successful response" sans savoir ce que contient réellement le JSON. Pour interagir avec l'API de manière fiable, il faut ouvrir les DevTools du navigateur et observer les trames réseau pour comprendre la structure des requêtes et des réponses. Ce n'est pas une méthode acceptable pour construire de l'automatisation fiable.
Concrètement, voici les murs rencontrés lors du test :
Webhooks non exposés : impossible de récupérer via l'API l'URL du webhook à transmettre à GitLab. Cette information n'est disponible que dans l'interface. Pour une dizaine d'applications, cela signifie dix allers-retours manuels dans le dashboard, puis dix configurations manuelles côté GitLab. L'automatisation de bout en bout est impossible.
Métadonnées au format inconnu : le format attendu pour les métadonnées des ressources n'est documenté nulle part. On découvre la structure par essai-erreur ou en sniffant les requêtes du frontend.
Hiérarchie projet/environnement/application opaque : Dokploy organise ses ressources en projets contenant des environnements contenant des applications. Mais la navigation dans cette arborescence via l'API est laborieuse. Récupérer l'identifiant d'un environnement, par exemple, nécessite de fouiller dans des réponses imbriquées dont la structure n'est pas documentée.
Certaines informations uniquement via l'interface : des données visibles dans le dashboard ne sont tout simplement pas récupérables via l'API, ce qui rend impossible une automatisation complète sans passer par des clics manuels.
Infrastructure as Code : la voie étroite
Ansible
Automatiser Dokploy en Ansible est faisable, mais fastidieux. Sans SDK ni documentation d'API exploitable, chaque interaction doit être construite manuellement via le module uri d'Ansible. Il faut d'abord reverse-engineerer les appels API en sniffant les requêtes de l'interface, puis les reproduire dans des playbooks. Sur le test réalisé, chaque nouvelle ressource à automatiser (création de projet, ajout d'un environnement, déploiement d'une application) a nécessité une session de reverse-engineering dans les DevTools avant de pouvoir écrire la tâche Ansible correspondante. Et certaines étapes restent manuelles — la récupération du webhook pour GitLab, par exemple, oblige à repasser par l'interface quoi qu'il arrive.
Chaque mise à jour de Dokploy peut potentiellement casser ces appels, puisqu'il n'y a pas de contrat d'API stable et versionné.
Terraform
Quelques providers communautaires existent sur le Terraform Registry. Le plus avancé au moment du test est ahmedali6/dokploy, qui couvre un périmètre déjà conséquent : applications, Docker Compose, bases de données, mounts, registries, clés SSH, providers Git (GitLab, Gitea), destinations de backup. C'est le provider qui s'en rapproche le plus d'une couverture fonctionnelle exploitable. D'autres existent (j0bIT/dokploy) mais restent plus limités.
Malgré tout, même avec le meilleur provider disponible, on bute sur les mêmes limites structurelles : les schémas de réponse incomplets de l'API Dokploy rendent le développement et la maintenance de ces providers fragiles. Et les lacunes de l'API se répercutent mécaniquement — ce qui n'est pas exposé par l'API ne peut pas être géré en Terraform. Les webhooks, par exemple, restent un angle mort.
Docker Swarm : connaissances requises
Dokploy abstrait Docker pour les cas simples, mais dès qu'on pousse la configuration, des connaissances solides en Docker et Docker Swarm deviennent indispensables.
Exemple concret : le déploiement d'une stack de monitoring/logging (type Grafana, Prometheus, Loki) via Dokploy. En soi, Dokploy permet de la déployer — c'est faisable via Docker Compose directement dans l'interface. Mais pour que les métriques et les logs remontent correctement, il faut que les conteneurs de monitoring puissent communiquer avec les conteneurs applicatifs. Et là, il faut jouer proprement avec les Docker networks : comprendre quels réseaux overlay Dokploy crée, rattacher manuellement les services au bon réseau, gérer les résolutions DNS internes entre services de projets différents. L'interface ne guide pas sur ces aspects — on est seul face à la configuration Docker.
L'ambition initiale était de piloter cette stack de monitoring en mode GitOps : la configuration versionnée dans un dépôt Git, déployée automatiquement via webhook. En théorie, Dokploy supporte ce workflow avec le déploiement Docker Compose depuis un dépôt. En pratique, le couplage entre la configuration réseau manuelle et le déploiement automatisé crée une zone grise : une partie de la configuration vit dans le dépôt Git, une autre dans l'interface Dokploy, et une troisième dans la configuration Docker sous-jacente. On est loin du GitOps pur où tout l'état désiré est décrit dans le code.
Ce n'est pas un reproche en soi — tout PaaS a ses limites d'abstraction — mais il faut en être conscient. Dokploy ne remplace pas la compétence Docker, il la complète. Et dès qu'on veut aller au-delà du déploiement d'une application web classique, cette compétence devient un prérequis, pas un bonus.
Maturité du projet
Dokploy en est à la version 0.x (v0.26.7 au moment de la rédaction). Le versioning sémantique indique clairement que l'API n'est pas encore considérée comme stable par les mainteneurs. Le rythme de release est soutenu (une release tous les 4-5 jours en moyenne), ce qui est à la fois un signe de vitalité et un risque de breaking changes fréquents.
Le projet est porté principalement par un seul développeur principal, assisté d'une communauté de contributeurs. C'est un point d'attention : la pérennité d'un outil d'infrastructure dépend fortement de la santé de son écosystème de maintenance.
Comparaison rapide avec les alternatives
Dokploy n'est pas seul sur ce créneau. Coolify (~50 000 étoiles GitHub) est le concurrent le plus direct, avec une communauté plus large et une maturité légèrement supérieure. Kamal (37signals) prend une approche radicalement différente : pas de dashboard, pas de daemon serveur, juste du déploiement SSH piloté par YAML — idéal pour les équipes qui veulent zéro overhead. Dokku reste la référence historique pour le PaaS minimaliste façon Heroku.
Le positionnement de Dokploy se situe entre Coolify (plus mature, plus de features) et Dokku (plus simple, plus éprouvé). Son avantage principal est son approche Docker-native et son support natif de Docker Swarm pour le multi-nœuds, un domaine où Coolify est moins avancé.
Et face à k3s ?
C'était la question initiale du test, et la réponse est non — pas en l'état. Paradoxalement, k3s permet d'aller plus loin plus vite malgré la complexité inhérente de Kubernetes. L'écosystème Kubernetes offre un outillage IaC mature (Helm, Kustomize, ArgoCD, Flux), une API stable et documentée, et un modèle déclaratif natif. On peut atteindre un GitOps pur sans contorsion. Le monitoring s'intègre proprement via des standards établis (ServiceMonitor, PodMonitor). La gestion réseau est explicite et prédictible.
Dokploy réduit la complexité initiale — c'est indéniable. Mais il la réduit en sacrifiant la capacité d'automatisation et l'extensibilité. Pour trois ou quatre petites applications qu'on veut juste mettre en ligne rapidement, c'est un excellent choix. Pour un homelab de dix applications avec du monitoring, du logging, et une ambition GitOps, on retrouve de la complexité, sauf qu'elle est moins bien outillée que celle de Kubernetes.
Pour qui Dokploy est-il adapté ?
Bon candidat si :
Vous voulez déployer rapidement quelques applications web sans vous soucier de l'infrastructure sous-jacente
Vous gérez un homelab et voulez une interface unifiée pour vos services auto-hébergés
Vous êtes développeur solo ou en petite équipe et voulez un VPS sans payer de PaaS managé
Vous êtes à l'aise avec Docker et voulez un layer d'abstraction léger par-dessus
Vous acceptez de travailler principalement via l'interface web
Pas recommandé si :
Vous cherchez à remplacer un k3s ou un Kubernetes léger — vous retrouverez de la complexité, moins bien outillée
Vous avez besoin d'automatiser entièrement vos déploiements en IaC (Terraform, Ansible, Pulumi)
Vous visez une approche GitOps pure où tout l'état désiré est versionné dans Git — une partie de la configuration restera inévitablement dans l'interface
Vous avez besoin d'un monitoring professionnel intégré — le monitoring natif est basique et déployer sa propre stack demande des compétences Docker réseau solides
Verdict
Dokploy est un projet prometteur qui fait bien ce qu'il fait dans son périmètre d'usage principal : fournir une interface web agréable pour déployer rapidement des applications conteneurisées sur ses propres serveurs. Pour héberger quelques applications sans se soucier d'orchestration, de certificats ou de reverse-proxy, c'est un gain de temps réel. Le time-to-deploy pour une petite application est imbattable.
En revanche, l'outil atteint ses limites dès qu'on veut aller plus loin. L'écart entre l'expérience via l'interface et l'expérience via l'API est un frein majeur pour quiconque cherche à industrialiser. L'absence de schémas de réponse fiables dans l'API, le manque de documentation pour l'automatisation, et la nécessité de reverse-engineerer les appels réseau pour construire de l'IaC rendent le passage à l'échelle compliqué. Et pour répondre à la question initiale : non, Dokploy ne remplace pas un k3s aujourd'hui. La promesse de "moins de complexité que Kubernetes" se vérifie à l'installation et pour les cas simples, mais dès qu'on dépasse ce périmètre, on retrouve de la complexité — avec un outillage moins mature pour la gérer.
Le projet est encore jeune (version 0.x) et évolue vite. Les fondations sont saines, le rythme de développement est soutenu, et la communauté grandit. Si l'équipe Dokploy investit dans la stabilisation de son API et la documentation pour les usages programmatiques, l'outil pourrait devenir une référence dans l'écosystème PaaS self-hosted. En attendant, il faut le prendre pour ce qu'il est : un excellent outil de déploiement rapide, pas une plateforme d'infrastructure complète.
Contexte du test : Homelab, 1 nœud, ~10 applications, stack monitoring/logging — Mars 2026
Ressources mentionnées :
Provider Terraform ahmedali6/dokploy (le plus avancé au moment du test)
