Ce que Dokku et Coolify font bien
Rendons d'abord hommage, car il est mérité. Dokku a distillé la boucle centrale de Heroku — git push, regarder le build, l'application est en ligne — en un outil mono-serveur fiable depuis une décennie. Coolify a enveloppé la même idée dans une interface réellement agréable, avec des bases de données en un clic et une bibliothèque de modèles qui s'étoffe. Les deux gèrent TLS, les deux parlent Dockerfile, et les deux tournent sur du matériel que vous contrôlez entièrement — ce qui compte quand les données doivent rester sur place ou quand un VPS à prix fixe est tout le budget.
Si vous exploitez l'un des deux avec bonheur aujourd'hui, rien ci-dessous n'affirme que vous vous êtes trompé. La question à laquelle ce guide répond est plus étroite et n'apparaît qu'avec le temps : qui opère la plateforme sous votre plateforme — et est-ce encore le meilleur usage de vos heures ?
Le poste que le README omet : vous êtes l'équipe plateforme
Un PaaS auto-hébergé, c'est un logiciel que vous exploitez sur un serveur que vous exploitez. Deux couches, toutes deux à vous. Le serveur a besoin de correctifs de sécurité de l'OS, d'un durcissement SSH, et d'un disque qui se remplit silencieusement d'images Docker et de caches de build jusqu'au matin où les déploiements échouent avec « no space left on device » — l'incident Dokku classique, et il choisit toujours son moment. Le PaaS lui-même a besoin de mises à niveau dont vous lisez le changelog, car il se tient entre votre code et la production : un changement cassant à cet endroit EST un changement de production.
Puis viennent les questions plus tranchantes. Les sauvegardes : les bases de données que votre PaaS a créées en un clic — qui les exporte, où vont les dumps, et quand quelqu'un a-t-il testé une restauration pour la dernière fois ? La haute disponibilité : un seul serveur signifie qu'un redémarrage de l'hôte fait tomber toutes les applications ensemble. Rien de tout cela n'est un travail exotique. C'est un poste d'ingénierie plateforme à temps partiel, arrivé en silence avec le script d'installation, facturé sur vos soirées.
La même boucle, opérée pour vous
Le workflow que vous aimez vraiment, c'est le push-to-deploy, et ce n'est pas ce que vous abandonneriez. Sur cdn.com.tr, GitHub Deploy connecte un dépôt et transforme un push en déploiement : la plateforme tire la branche, construit votre Dockerfile dans un builder isolé (aucun compte de registre nécessaire), exécute les étapes que vous définissez, et déploie la version derrière un healthcheck — le trafic ne bascule vers le nouveau conteneur que lorsqu'il se déclare prêt, si bien qu'un build cassé ne fait jamais tomber le site. Le cache de périphérie en façade est purgé automatiquement à chaque déploiement.
Ce qui change, c'est qui reçoit l'appel. Le patch de l'hôte, les mises à niveau du builder, le disque et la disponibilité de la plateforme elle-même cessent d'être votre côté de la table. Postgres et Redis managés remplacent les conteneurs en un clic par des bases de données opérées et sauvegardées en tant que service, et le stockage d'objets compatible S3 remplace le schéma « volume sur ce serveur » pour les uploads. Le compromis honnête, comme toujours : pas de root sur l'hôte, pas d'installations au niveau de l'OS, le trafic public est en HTTP(S). Votre Dockerfile est le contrat — c'est aussi ce qui garde la porte ouverte pour partir.
À quoi ressemble le côté panneau
Les utilisateurs de Coolify en particulier trouveront la forme familière : des applications avec domaines, variables d'environnement et secrets, des logs lisibles sans SSH, et des bases de données attachées aux applications — moins les pages de réglages serveur, car il n'y a aucun serveur à vous en dessous. Les container apps portent leur healthcheck, leur nombre de réplicas et leur stockage persistant comme des réglages de premier rang, et tout ce qui est à l'écran est aussi scriptable depuis la même CLI : l'interface est une vue de la plateforme, pas la seule porte d'entrée.
Tout ce qui est dans le panneau est aussi à une commande CLI de distance
# see your apps and read logs without SSH
cdnctl container apps list --account <uuid>
cdnctl container apps logs --account <uuid> --app <app_uuid> --tail 100
# scale, restart, roll back — the operations you actually reach for
cdnctl container apps scale --account <uuid> --app <app_uuid> --replicas 2
cdnctl container apps restart --account <uuid> --app <app_uuid>
cdnctl container apps rollback --account <uuid> --app <app_uuid> --revision <revision_uuid>Migrer : plus petit que vous ne le pensez
Votre application vit déjà dans Git, et sous Dokku ou Coolify elle se construit déjà depuis un Dockerfile ou une structure buildable — autrement dit, la partie difficile de la migration a eu lieu il y a longtemps. Déménager, c'est re-pointer la destination du push, plus une passe de données.
Connectez le dépôt à GitHub Deploy (ou, si l'application est décrite par un docker-compose.yml, importez-le : les services avec une section build: sont construits depuis leurs Dockerfiles, les bases de données deviennent des add-ons managés). Recréez les variables d'environnement et les secrets. Déplacez les données : exportez la base et restaurez-la dans la base managée, puis copiez les fichiers uploadés vers le stockage d'objets. Faites tourner les deux plateformes en parallèle quelques jours — l'ancien serveur continue de servir pendant que vous vérifiez le nouveau déploiement — puis basculez le DNS et retirez la machine à votre propre rythme.
Une application décrite en compose : prévisualisez le plan, puis appliquez-le
# see exactly what your compose file becomes — nothing is created yet
cdnctl container compose preview --account <uuid> --file docker-compose.yml
# apply when the plan looks right
cdnctl container compose apply --account <uuid> --file docker-compose.yml
# data: dump on the old box, restore into the managed database
pg_dump -Fc appdb > appdb.dump
pg_restore -d "$MANAGED_DATABASE_URL" appdb.dump
# uploads: from the old server's volume into object storage
aws --endpoint-url https://s3.cdn.com.tr s3 sync ./uploads s3://app-uploadsQuand rester en auto-hébergé
La symétrie exige cette section. Gardez Dokku ou Coolify quand le serveur est réellement gratuit pour vous — un homelab, du matériel que vous possédez déjà et que vous aimez opérer. Gardez-les quand la localisation des données est une contrainte dure et que la machine doit être la vôtre. Gardez-les quand le travail d'exploitation est le but : faire tourner sa propre plateforme est l'une des meilleures façons d'apprendre tout ce domaine. Et gardez-les quand vous avez besoin de ce que le compromis managé exclut — root, ports TCP bruts, dépendances système exotiques qui n'ont pas leur place dans une image de conteneur.
Si rien de tout cela ne vous décrit — si la plateforme sous vos applications est une corvée plutôt qu'un loisir ou une exigence — alors le workflow que vous aimez est portable, et l'astreinte est optionnelle.
Questions fréquentes
Est-ce que je perds le workflow git-push en quittant Dokku ?
Non — ce workflow est ici le produit. GitHub Deploy transforme un push en cycle pull-build-release conditionné par un healthcheck, et Docker Compose Instant Deploy couvre les applications multi-services. Ce que vous arrêtez de faire, c'est opérer la machine qui fait tourner tout cela.
Mon application Dokku utilise des buildpacks, pas de Dockerfile. Peut-elle migrer ?
Oui, moyennant une petite étape : ajoutez un Dockerfile. Pour la plupart des applications en buildpacks, c'est une poignée de lignes (image de base, copie, installation, commande de démarrage), et cela rend l'application portable vers n'importe quelle plateforme de conteneurs — celle-ci comprise. Cela vaut la peine même si vous restez sur Dokku.
Qu'est-ce qui remplace les bases de données en un clic de Coolify ?
Des add-ons Postgres et Redis managés — attachés à vos applications de la même manière, mais opérés et sauvegardés en tant que service au lieu de tourner comme des conteneurs dont le disque et les dumps sont votre responsabilité.
Puis-je migrer progressivement plutôt qu'en une seule bascule ?
Oui, et vous devriez : déployez sur la plateforme managée pendant que l'ancien serveur continue de servir la production, vérifiez sur le build réel, pré-synchronisez les données, puis basculez le DNS quand vous êtes satisfait. L'ancienne machine fait un excellent plan de repli jusqu'à ce que vous l'éteigniez.