Coolify : son propre Vercel sur un VPS à 5 euros
Comment Coolify déploie vos applications sur vos serveurs, ce qu'il vaut face à Dokploy, et les règles que son historique de sécurité impose.

La facture Vercel du mois dépasse celle du serveur dédié qui pourrait tout héberger. Le projet personnel a besoin d'une base PostgreSQL, d'un Redis et d'un cron, soit trois services managés de plus. Et chaque nouveau projet ajoute une ligne à la note.
Coolify propose de rapatrier tout ça sur vos machines. C'est une plateforme open source et auto-hébergeable, une alternative à Vercel, Heroku ou Netlify. Vous l'installez sur un serveur, vous lui donnez un accès SSH à une ou plusieurs machines, et il s'occupe du reste : build à chaque push, certificats HTTPS, domaines, bases de données, sauvegardes, journaux.
Le projet
Coolify est développé par coollabs, la structure d'Andras Bacsai, son créateur. Le dépôt coollabsio/coolify existe depuis janvier 2021 et dépasse les 63 000 étoiles en octobre 2026. Il est écrit en PHP avec Laravel, sous licence Apache 2.0. La branche 4, réécrite de zéro, est en version 4.4.6 depuis le 9 octobre.
Le modèle économique est simple. L'auto-hébergement est gratuit, sans fonction réservée. Coolify Cloud, une instance maintenue par l'équipe, coûte 5 $ par mois pour deux serveurs connectés, puis 3 $ par serveur supplémentaire. Dans les deux cas, ce sont vos serveurs qui font tourner les applications : le cloud n'héberge que le tableau de bord.
Ce que Coolify déploie
Coolify sait construire et lancer à peu près tout ce qui tient dans un conteneur :
| Source | Comment |
|---|---|
| Dépôt GitHub, GitLab, Bitbucket ou Gitea | Build avec Nixpacks, Railpack, un Dockerfile ou Docker Compose |
| Image Docker | Depuis n'importe quel registre |
| Base de données | PostgreSQL, MySQL, MariaDB, MongoDB, Redis, ClickHouse… avec sauvegardes vers S3 |
| Service en un clic | Plus de 280 modèles : Plausible, Uptime Kuma, n8n, Dify, Langflow, Nextcloud… |
Nixpacks et Railpack détectent le langage du projet et produisent une image sans Dockerfile. Pour une application Next.js, un dépôt Node ou un projet Go standard, il n'y a rien à écrire. Pour un monorepo ou une pile particulière, un docker-compose.yml reste la voie la plus prévisible.
Le catalogue de services est ce qui fait gagner le plus de temps. Une plateforme comme Dify et ses applications LLM, avec sa dizaine de conteneurs, se déploie en remplissant un domaine et en cliquant sur « Deploy ». Coolify génère les mots de passe, crée les volumes et branche le reverse proxy.
Installer
Il faut un serveur Linux 64 bits, Debian, Ubuntu ou une distribution proche, avec au moins 2 cœurs, 2 Go de mémoire et 30 Go de disque pour Coolify lui-même. Le script d'installation se lance en root :
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bashLe script installe Docker, crée les dossiers dans /data/coolify et démarre la plateforme. L'interface répond sur le port 8000. Créez le compte administrateur immédiatement : le premier visiteur qui arrive sur cette page devient administrateur de l'instance.
Comme pour tout script passé à bash, lisez-le avant de l'exécuter. Il est dans le dépôt, sous scripts/install.sh.
L'architecture : un serveur pour piloter, d'autres pour héberger
Coolify peut déployer sur la machine où il est installé, mais l'équipe recommande une autre organisation : un petit serveur pour Coolify, et un ou plusieurs serveurs pour les applications. Coolify s'y connecte en SSH et y pilote Docker.
Serveur Coolify (tableau de bord, base interne, clés SSH)
├── SSH → Serveur A : apps de production + Traefik
├── SSH → Serveur B : bases de données
└── SSH → Raspberry Pi : services persoSur chaque serveur, un reverse proxy, Traefik par défaut ou Caddy, reçoit le trafic et obtient les certificats Let's Encrypt. Les domaines se déclarent dans l'interface, et le routage suit. Si vous voulez comprendre ce que Coolify configure pour vous, le comparatif Nginx, Caddy ou Traefik comme reverse proxy explique pourquoi Traefik s'adapte si bien aux conteneurs.
Un point rassurant : les applications tournent dans des conteneurs Docker ordinaires. Si vous arrêtez Coolify, elles continuent de fonctionner, et vous pouvez les gérer à la main.
Le cycle de déploiement
Une fois le dépôt connecté par une GitHub App, chaque push sur la branche choisie déclenche un build et un déploiement. Les pull requests peuvent avoir leur propre environnement de prévisualisation, sur un sous-domaine dédié, détruit à la fusion. Les anciennes images sont conservées, et un retour en arrière se fait en un clic.
Pour ceux qui préfèrent construire l'image ailleurs, dans une CI par exemple, chaque ressource a un webhook de déploiement :
curl -X GET "https://coolify.mondomaine.fr/api/v1/deploy?uuid=<uuid-ressource>&force=false" \
-H "Authorization: Bearer $COOLIFY_TOKEN"Coolify expose aussi une API complète, une CLI et un serveur MCP, ce qui permet à un agent de code de consulter les journaux d'un déploiement raté.
Coolify ou Dokploy ?
C'est la comparaison que tout le monde fait. Dokploy, le PaaS auto-hébergé couvre le même besoin, avec une approche proche : Docker, Traefik, Nixpacks, déploiement depuis Git.
| Critère | Coolify | Dokploy |
|---|---|---|
| Ancienneté | 2021, branche 4 depuis 2023 | 2024 |
| Pile technique | PHP, Laravel | TypeScript, Next.js |
| Multi-serveurs | Oui, par SSH | Oui, par SSH, avec Docker Swarm |
| Services en un clic | 280+ | Catalogue plus réduit |
| Offre cloud | 5 $/mois pour 2 serveurs | Oui, payante |
| Licence | Apache 2.0 | Apache 2.0, sauf un dossier propriétaire |
Mon choix : Coolify pour héberger beaucoup de services hétérogènes, grâce à son catalogue ; Dokploy pour qui veut une interface plus sobre et un projet plus récent. Les deux font très bien le travail principal, déployer une application depuis un dépôt avec HTTPS.
La sécurité : un historique à connaître
C'est le point que les tutoriels oublient. Coolify détient les clés SSH root de tous vos serveurs et exécute des commandes Docker à partir de ce que les utilisateurs saisissent dans l'interface. Une faille dans Coolify, c'est donc un accès root sur toute votre infrastructure.
Or les failles n'ont pas manqué. Le dépôt a publié onze avis de sécurité critiques en janvier 2026, puis plus de quarante en juin et juillet 2026, dont cinq critiques. La plupart sont des injections de commandes exploitables par un utilisateur authentifié : un nom de volume, un nom de conteneur ou un champ de base de données mal échappé suffisait pour exécuter du code en root sur un serveur géré. D'autres permettaient à un membre d'une équipe d'agir sur les serveurs d'une autre équipe.
Ce rythme de publication montre aussi un projet qui fait auditer son code et corrige. Mais il impose des règles :
- Mettre à jour vite. La mise à jour automatique est disponible dans les réglages, et la plupart des correctifs arrivent en versions de correction.
- Ne pas exposer le tableau de bord. Accès par VPN ou tunnel, ou au minimum un pare-feu UFW qui limite le port 8000 et le domaine du tableau de bord à vos adresses.
- Limiter les comptes. Une grande partie des failles demandait un compte sur l'instance. Un Coolify partagé avec des personnes à qui vous ne confieriez pas un accès root est une mauvaise idée.
- Séparer les serveurs. Le serveur Coolify ne devrait héberger que Coolify.
Coolify rend l'auto-hébergement presque aussi confortable qu'une plateforme managée, pour le prix d'un VPS. Push, build, HTTPS, base de données, sauvegarde : tout ce que Vercel facture à l'usage, il le fait sur des machines que vous payez au mois. La contrepartie, c'est que vous devenez l'équipe d'exploitation, et que l'outil qui détient les clés de vos serveurs doit être traité comme tel : à jour, fermé, et réservé à des personnes de confiance.