Si vous avez déjà quitté le PaaS managé, votre VPS est provisionné, la clé SSH est ajoutée et le curseur de votre terminal clignote sur la ligne d'installation. La seule question qui reste : lancez-vous curl ... | bash pour Coolify, ou pour Dokploy ?
Les deux outils s'installent en une commande. Tous deux vous offrent des déploiements par Git-push, du SSL automatique, une interface web et un reverse proxy par-dessus Docker. Les différences intéressantes sont celles qui apparaissent en production : la façon dont chacun gère un docker-compose.yml, ce qui se passe pendant un déploiement, et la façon dont chaque projet a réagi aux nouvelles qui ont redéfini cette comparaison en 2026. Deux nouvelles pèsent le plus lourd ici : les divulgations de CVE de Coolify de janvier 2026 et la clé la restructuration de licence de Dokploy du même mois.
Cet article associe chaque outil à un cas d'usage précis plutôt que de couronner un vainqueur. À la fin, vous saurez, je l'espère, lequel correspond à votre flux de travail.
En bref
- Coolify est plus ancien et dispose du plus grand écosystème (~55k étoiles GitHub, plus de 300 modèles de services en un clic), plus lourd au repos, sous Apache 2.0 de bout en bout, sans palier payant côté auto-hébergé.
- Dokploy est plus jeune (~34k étoiles), plus léger au repos, avec un cœur sous Apache 2.0 plus une Source Available License distincte qui encadre les futures fonctionnalités payantes (SSO, RBAC, journaux d'audit, marque blanche).
- Coolify ne peut pas faire de déploiements sans interruption via Docker Compose aujourd'hui ; uniquement via Dockerfile, Nixpacks ou des déploiements mono-image. Dokploy propose Docker Swarm comme mode de premier rang ; le Swarm de Coolify est étiqueté comme expérimental.
- Les CVE de Coolify de janvier 2026 sont corrigées dans la v4.0.0 (April 27, 2026). Mettez Coolify à jour et n'exposez pas le tableau de bord publiquement.
Quand aucun des deux outils n'est la bonne réponse
Coolify comme Dokploy ne conviennent pas à certaines configurations. Trois alternatives qui méritent d'être connues, en bref :
- Kamal (de 37signals) : pour les équipes avec une ou deux applications qui ne veulent aucune interface ; juste
kamal deploydepuis votre ordinateur portable. Bien plus simple que Coolify ou Dokploy, et le bon choix quand vous ne voulez pas de tableau de bord. - Dokku: le classique, en Git-push, modèle mono-serveur. Plus ancien, périmètre plus restreint, très stable. L'original du « Heroku sur un seul VPS ».
- GitHub Actions + Docker Compose sur un VPS nu: la pile la plus minimale possible. Pas d'interface d'orchestration, mais pas non plus de surcharge d'orchestration. Idéal pour une application unique dont le flux de déploiement est
docker compose pull && docker compose up -ddéclenché depuis la CI.
Si votre configuration se résume à une application sur un serveur, Coolify comme Dokploy sont probablement surdimensionnés ; essayez d'abord l'une des options ci-dessus. Si vous avez plusieurs applications, plusieurs bases de données, ou une équipe avec des membres non techniques qui ont besoin d'une interface pour piloter les choses, le choix Coolify vs Dokploy est le bon à faire. Pour un panorama plus large des options de cette catégorie, consultez notre tour d'horizon de plateformes cloud auto-hébergées avec interface web.
Coolify et Dokploy en bref
Coolify v4.0.0 stable est sorti le April 27, 2026, après un long cycle de bêta. Dokploy en est à la v0.29.4 au May 11, 2026. Les deux sont des projets de PaaS auto-hébergés open source dans l'espace des alternatives à Heroku/Render/Vercel, tous deux enveloppant Docker d'une interface, d'un reverse proxy HTTPS par défaut (Traefik) et de déploiements basés sur Git.
| Fonctionnalité | Coolify | Dokploy |
|---|---|---|
| Dernière version stable | v4.0.0 (April 27, 2026) | v0.29.4 (May 11, 2026) |
| Licence | Apache 2.0 | Cœur Apache 2.0 + Source Available pour les fonctionnalités payantes |
| Pile technique | PHP / Laravel | TypeScript / Node.js |
| Étoiles GitHub | ~55,000 | ~34,000 |
| RAM minimale (officielle) | 2 GB | 2 GB |
| CPU minimal (officiel) | 2 cœurs | non spécifié |
| RAM au repos (rapportée par la communauté) | 500 MB – 1.2 GB | 300 – 400 MB |
| Zéro-interruption avec Docker Compose | Non pris en charge (Dockerfile/Nixpacks uniquement) | Gestion standard de Compose |
| Clustering multi-serveurs | Docker Swarm (expérimental) | Docker Swarm (natif) |
| Prise en charge ARM64 | Oui (y compris Raspberry Pi OS) | Non annoncé dans la doc |
| Systèmes de build | Nixpacks, Dockerfile, image Docker | Nixpacks, Dockerfile, image Docker, Heroku Buildpacks, Paketo, Railpack |
| Proxy inverse | Traefik | Traefik |
| Périmètre de la supervision auto-hébergée | Métriques intégrées + visionneuse de logs | Métriques de ressources de base + analyse IA des logs et erreurs de build (v0.29.0+) |
Notre avis : choisissez Dokploy si vous voulez une moindre surcharge au repos, une prise en charge native du multi-serveur et une gestion standard de Docker Compose sans bidouillage propre à la plateforme. Choisissez Coolify si vous voulez la plus grande bibliothèque d'applications en un clic, la prise en charge ARM64/Raspberry Pi, ou du pur Apache 2.0 sans futur palier payant en embuscade.
Empreinte ressources et dimensionnement du VPS
Un PaaS auto-hébergé peut vous épargner le coût de Heroku. Si la couche d'orchestration grignote 1,5 GB des 2 GB de votre VPS au repos, il ne vous reste plus rien pour déployer. La première question pratique sur un petit serveur est donc : combien chaque outil vous coûte-t-il avant même d'avoir déployé une seule application ?
L'usage de RAM au repos de Coolify dépend de la supervision activée, avec une empreinte CPU de référence de 5–7 % qui grimpe lors de l'exécution du scrape des métriques. La propre documentation de Coolify prend comme charge de production représentative 8 GB de RAM, 4 cœurs et 150 GB de stockage faisant tourner 3 applications Node.js, 4 sites statiques et quelques bases de données. C'est une référence de dimensionnement raisonnable si votre pile y ressemble.
Dokploy, à l'inverse, tourne bien plus léger, nettement en dessous de 2 % de CPU lorsqu'aucun déploiement n'est en cours.
A compte rendu de production de LogRocket qui a fait tourner les deux outils côte à côte est parvenu à la même conclusion directionnelle : un docker stop && docker start sur une application Dokploy ne déclenche pas une reconstruction complète, alors que la même opération sur Coolify le fait. Cela seul fait pencher le coût en régime permanent en faveur de Dokploy, surtout sur les plans VPS plus petits où les rafales de reconstruction grignotent votre budget CPU.
Pour le dimensionnement, voici la configuration VPS que je recommanderais :
- Coolify, charge légère : 2 vCPU / 4 GB RAM / 120 GB NVMe is the practical starting point for Coolify plus a couple of small apps.
- Coolify, charge de référence production : 4 vCPU / 8 GB RAM / 160 GB NVMe to match Coolify's own documented 3 Node.js + 4 static sites + databases example.
- Dokploy, charge légère : 1 vCPU / 2 GB RAM / 60 GB NVMe is comfortable for a single small app.
- Dokploy, marge de production : 2 vCPU / 4 GB RAM / 120 GB NVMe gives you room for a small production stack.
Astuce de pro : la RAM au repos de Coolify augmente avec la configuration de supervision. Si vous êtes juste en mémoire, réduisez l'intervalle de scrape des métriques (ou désactivez entièrement la supervision intégrée si vous faites déjà tourner Prometheus/Grafana ailleurs) avant de provisionner un serveur plus gros.
Réalité du déploiement : Docker Compose, Dockerfile et le zéro-interruption
La plupart des équipes arrivent vers l'un de ces outils avec un docker-compose.yml existant et une attente : coller le fichier, cliquer sur déployer, voir l'application démarrer. C'est dans la façon dont chaque plateforme gère le Compose standard, et dans ce qu'il advient des requêtes en cours lors du prochain déploiement, qu'apparaît la distinction pratique.
Coolify prend en charge Docker Compose, Dockerfile, Nixpacks (détection automatique à partir des fichiers du projet) et les déploiements d'image Docker directs. Il y a toutefois un hic qui mérite d'être explicité : les déploiements sans interruption (mises à jour progressives, blue/green) ne fonctionnent dans Coolify que via Dockerfile, Nixpacks ou des déploiements mono-image. Ils ne fonctionnent pas via Docker Compose. Un mainteneur de Coolify a confirmé dans une discussion GitHub que « pour les déploiements basés sur Compose, tous les conteneurs sont arrêtés avant de démarrer les nouveaux ; il n'y a pas de mise à jour progressive pour les déploiements basés sur Compose actuellement ». La prise en charge progressive de Compose est sur la feuille de route pour la v5 ; la v4 ne l'aura pas. Le contournement suggéré par le mainteneur consiste à scinder une pile Compose en services Coolify individuels, ce qui représente une migration non triviale si votre fichier Compose exprime de vraies relations inter-services.
La conséquence visible pour l'utilisateur apparaît dans un fil Hacker News sur Coolify, où un opérateur l'a dit sans détour : « toute requête en attente lorsque vous mettez à jour une application est simplement tuée. » C'est exact pour les déploiements Compose aujourd'hui.
La couche Compose de Coolify ajoute aussi ce que le projet appelle des « variables magiques ». Cela signifie l'injection automatique d'images d'assistance, des réécritures de réseau et des surcharges d'environnement. L'intention est de gagner en efficacité ; l'effet secondaire est qu'un docker-compose.yml qui tourne sans accroc sur votre ordinateur portable a parfois besoin d'ajustements pour tourner sans accroc sur Coolify. Le même fil Hacker News fait remonter un cas représentatif : « Ajouté 8 variables dans docker-compose, seules 7 sont reconnues. » Si votre pile Compose est petite et standard, vous n'y serez peut-être pas confronté. Si elle est volumineuse ou atypique, vous le serez.
La posture de Dokploy est différente. Le compte rendu pratique de LogRocket a constaté que Dokploy « peut déployer un docker-compose.yml existant avec peu ou pas de modification » et reste proche du modèle de routage natif de Docker basé sur les labels. Le même compte rendu note que l'arrêt/démarrage de conteneur dans Dokploy ne déclenche pas une reconstruction complète, alors que la même action sur Coolify le fait. C'est un signal directionnel sur le comportement à l'exécution plutôt qu'une « garantie de zéro-interruption » formelle de la doc de Dokploy, mais cela concorde avec ce que rapportent les auto-hébergeurs sur des instances VPS plus petites.
Dokploy prend également en charge Heroku Buildpacks, Paketo Buildpacks et Railpack en plus de Nixpacks et Dockerfile. Pour les équipes qui arrivent de Heroku avec heroku.yml ou des flux de travail basés sur les buildpacks, c'est la voie de moindre résistance.
À retenir de cette section : si vos services existants forment une vraie pile Docker Compose, Coolify vous obligera soit à restructurer votre stratégie de déploiement, soit à accepter une brève interruption à chaque push. Dokploy, non.
Sécurité : les divulgations de CVE de Coolify de janvier 2026
Je lis l'histoire plus large ainsi : Coolify peut être exécuté en toute sécurité aujourd'hui si vous le maintenez à jour et que vous n'exposez pas le tableau de bord à l'internet public. La divulgation ne disqualifie pas le projet. La divulgation responsable a été respectée et les correctifs ont été publiés. Ce qu'elle révèle, c'est que la surface d'attaque accessible à un utilisateur authentifié à faibles privilèges était plus large qu'elle n'aurait dû l'être. C'est une leçon de conception pour le projet et une leçon opérationnelle pour l'exploitant : resserrez le modèle d'exposition dès maintenant.
Astuce de pro : même après le correctif, traitez votre tableau de bord Coolify comme du SSH. Liez-le à un réseau privé, placez-le derrière un VPN, ou faites-le précéder de Tailscale. N'exposez pas le port 8000 à l'internet public simplement parce que le script d'installation le rend facile.
Dokploy n'est pas non plus exempt de ce genre de problème. Les notes de version de la v0.29.3 reconnaissent une vulnérabilité de sécurité identifiée dans Dokploy et fournissent un script de correctif de sécurité que vous êtes censé exécuter en parallèle de la mise à niveau. Surface plus petite, historique de projet plus court, mais la même discipline opérationnelle s'applique : mettez à jour le jour où les correctifs sortent, ne laissez pas le tableau de bord sur l'internet public.
À retenir de cette section : l'histoire des CVE est un drapeau jaune pour la pratique opérationnelle de Coolify, pas un drapeau rouge contre le projet, mais elle relève la barre en matière de discipline de mise à jour et de la façon dont vous exposez le tableau de bord.
Licences : ce qui est gratuit, ce qui ne l'est pas
La licence de Dokploy a été restructurée le January 21, 2026. Voici ce qui a changé et ce que cela signifie pour les auto-hébergeurs.
Dokploy est désormais sous Apache 2.0 standard pour le cœur, remplaçant l'ancienne Apache 2.0 adaptée et non standard qui semait la confusion sur ce qui était open source et ce qui ne l'était pas. Une Dokploy Source Available License distincte régit désormais le code dans les répertoires proprietary/ répertoires : source visible, payant pour un usage en production. Les fonctionnalités que Dokploy annonce derrière cette licence :
- Authentification unique (SSO/SAML) et contrôles d'accès avancés
- Personnalisation de la marque et marque blanche
- Haute disponibilité, auto-scaling et reprise après sinistre
- Supervision avancée, intégrations et fonctionnalités de conformité
Le projet s'est explicitement engagé à ne jamais déplacer une fonctionnalité open source existante vers le palier payant ; les futures fonctionnalités payantes visent les organisations qui ont besoin de liant d'entreprise. La 2FA est déjà aujourd'hui derrière le palier Startup sur la page de tarification de Dokploy.
La situation de Coolify est simple. Le projet est sous Apache 2.0 sur GitHub; chaque fonctionnalité de la version auto-hébergée est gratuite. Il existe une offre Coolify Cloud pour les équipes qui veulent que le mainteneur l'héberge, mais la version auto-hébergée est un produit complet sans verrou de fonctionnalité ni chemin de mise à niveau vers un palier payant que vous n'avez pas aujourd'hui.
Mon analyse : pour les développeurs solo et les petites équipes qui s'auto-hébergent sur leur propre VPS, Dokploy est fonctionnellement gratuit et le restera. Pour une organisation qui finit par avoir besoin du SSO, d'un RBAC à granularité fine, de journaux d'audit ou de marque blanche, Dokploy finira par vous pousser vers un palier payant. Coolify, non, parce que Coolify n'a pas ce palier sur sa feuille de route.
Une clarification multi-sources qui mérite d'être faite : la version auto-hébergée de Dokploy inclut bien des métriques de ressources de base (CPU, mémoire, stockage, réseau), et la v0.29.0 a ajouté l'analyse des logs et des erreurs de build assistée par IA. Le système de supervision de Dokploy est réservé au cloud pour les fonctionnalités de supervision les plus avancées. La supervision tourne cependant toujours localement sur une installation auto-hébergée pour les métriques de ressources de base, pré-conteneur.
Multi-serveur et clustering : la réalité face au marketing
Tôt ou tard un seul VPS ne suffit plus, et les deux projets mettent en avant la prise en charge multi-serveur sur leurs pages d'accueil. La réalité sur le terrain n'est pas la même.
La documentation officielle d'évolutivité de Coolify est directe à ce sujet : la prise en charge de Docker Swarm est étiquetée comme expérimentale. Le modèle multi-serveur standard utilise des serveurs distants validés connectés via SSH avec un Docker Registry partagé entre eux, et des instances Traefik tournant par serveur. Le mode Swarm exige un minimum de trois serveurs dans la même architecture (tous ARM, ou tous AMD64). Kubernetes ? « Juste prévu, mais pas encore sur la feuille de route, donc pas de date estimée. » Si vous lisez la propre page de Coolify à ce sujet, la version courte est : le multi-serveur fonctionne, Swarm est en bêta, et Kubernetes est une vision.
Dokploy propose Docker Swarm comme mode de premier rang, sans indicateur expérimental. Traefik gère le routage à la fois en configuration mono-serveur et Swarm. La version v0.29.0 a ajouté la prise en charge multi-serveur non-root, ce qui comble une véritable lacune (fini le SSH réservé à root pour ajouter des nœuds distants).
Si le clustering multi-nœuds est quelque chose dont vous aurez besoin dans les six prochains mois, et non « un jour sur une présentation », Dokploy est le choix le moins risqué aujourd'hui.
À retenir de cette section : si le clustering est sur votre feuille de route à court terme, la différence de Swarm fait pencher la recommandation vers Dokploy, quelles que soient les autres considérations.
Systèmes de build et prise en charge des langages
Les équipes qui arrivent de Heroku se soucieront surtout des écosystèmes de buildpacks pris en charge par chaque outil, car cela détermine la quantité de réécriture nécessaire pour votre projet avant son premier déploiement.
Le chemin de build de Coolify est Nixpacks (par défaut, détecté automatiquement à partir des fichiers de votre projet), Dockerfile, ou une image Docker préconstruite. Nixpacks est solide pour les cas courants (Node, Python, PHP, Go, Rust), mais la détection automatique a ses aspérités. À vérifier pour votre pile : un problème Nixpacks de janvier 2026 affectant les projets Laravel avec à la fois composer.json et package.json produisait des blocs de location Nginx en double, ce qui cassait une classe de déploiements jusqu'à ce qu'un correctif amont soit publié.
Dokploy prend en charge Nixpacks, Dockerfile et l'image Docker, et y ajoute Heroku Buildpacks, Paketo Buildpacks et Railpack. Si votre projet se construit déjà sans accroc avec heroku.yml ou un buildpack, Dokploy vous laisse conserver ce flux de travail. Coolify vous demandera de convertir.
En surface, les deux outils se ressemblent : déploiements par Git-push depuis GitHub, GitLab, Bitbucket, SSL Let's Encrypt automatique, une interface web pour les variables d'environnement et la gestion des bases de données. L'étendue des systèmes de build est l'un des rares domaines où Dokploy va clairement plus loin.
Catalogues d'applications en un clic
Pour les opérateurs non techniques qui veulent déployer des services open source connus (n8n, Plausible, Supabase, Ghost, Listmonk, l'écurie habituelle de l'auto-hébergement), la taille de la bibliothèque de modèles en un clic est un vrai facteur de différenciation. Pour certains utilisateurs, c'est plus important que d'autres aspects comme les performances ou la légèreté.
Coolify propose plus de 300 services en un clic répartis sur une quarantaine de catégories : IA, analytique, automatisation, bases de données, sécurité, stockage, et le reste. C'est de loin la plus grande bibliothèque et la réponse pratique pour les non-développeurs qui veulent déployer un service sans écrire de fichier Compose.
La bibliothèque de modèles de Dokploy est plus petite. La doc actuelle de Dokploy ne publie pas de décompte net, donc je ne vais pas vous donner de chiffre.
La réponse pratique : si votre flux de travail consiste à « déployer n8n, Supabase et Plausible en deux clics chacun », Coolify l'emporte nettement sur cet axe. Si vous écrivez vos propres applications et voulez simplement les déployer, la taille du catalogue n'a aucune importance et ce sont les autres axes qui comptent.
Comment choisir : recommandations par cas d'usage
Il n'y a pas de vainqueur unique ici. Il y a des correspondances entre un outil et une forme de déploiement :
- Équipe non technique qui veut une bibliothèque de services : Coolify. Le catalogue de plus de 300 modèles est un avantage significatif.
- Développeur Docker-natif qui veut de la légèreté + une gestion standard de Compose : Dokploy.
- Matériel ARM64 (Raspberry Pi, VPS à base d'ARM) : Coolify. Dokploy n'annonce pas la prise en charge ARM64 dans la doc actuelle ; si vous êtes sur ARM, optez par défaut pour Coolify jusqu'à confirmation du contraire.
- Clustering multi-nœuds que vous utiliserez ce trimestre : Dokploy. Swarm natif vs Swarm expérimental est le facteur décisif.
- Pur Apache 2.0, sans aucun futur palier payant possible : Coolify.
- Migration depuis Heroku en voulant conserver Heroku Buildpacks : Dokploy.
- Inquiet des CVE de janvier 2026 : un Coolify à jour (v4.0.0+) convient. La vraie question est votre modèle d'exposition. Si vous ne pouvez pas lier le tableau de bord à un réseau privé ou à un VPN, Dokploy est le choix le moins stressant : surface plus petite et historique plus court de divulgations de haute gravité.
Une note sur le déploiement de l'un ou l'autre outil
Une fois votre choix fait, l'installation elle-même se résume à une commande sur l'un comme l'autre projet, mais il y a un raccourci qui mérite d'être connu. Coolify comme Dokploy sont disponibles en déploiements en un clic dans notre marketplace, avec Ubuntu 24.04 et Docker préinstallés et le tableau de bord déjà accessible. Si vous voulez sauter la configuration manuelle, les fiches de la marketplace pour Coolify et Dokploy sont la voie la plus rapide. Si vous préférez partir d'un OS vierge et lancer vous-même l'installateur officiel, les deux projets publient un script en une ligne ; choisissez celui qui correspond à votre flux de provisionnement.
Foire aux questions
Dokploy est-il toujours open source après le changement de licence de 2026 ?
Oui pour la plateforme cœur. À compter du January 21, 2026, le cœur de Dokploy est sous Apache 2.0 standard. Une Dokploy Source Available License distincte régit désormais le code dans les répertoires proprietary/ répertoires, actuellement limité aux futures fonctionnalités d'entreprise (SSO/SAML, RBAC à granularité fine, journaux d'audit, marque blanche). Pour un usage auto-hébergé solo ou en petite équipe, Dokploy est fonctionnellement open source.
Les vulnérabilités de sécurité de Coolify de janvier 2026 sont-elles toujours une préoccupation ?
Les 11 CVE divulguées sont corrigées dans Coolify v4.0.0 (publié le April 27, 2026). Si vous exécutez la v4.0.0 ou plus récent, les vulnérabilités divulguées sont prises en charge. Ce qui reste, c'est l'exposition : maintenez Coolify à jour et n'exposez pas le tableau de bord à l'internet public. Liez-le à un réseau privé ou placez-le derrière un VPN.
