--- title: Migrer de Heroku vers Coolify description: >- Guide pratique pour déplacer une application Heroku vers Coolify. Équivalences, variables d'environnement, migration Postgres et bascule DNS sécuritaire. date: '2026-08-27' lastUpdated: '2026-08-27' keywords: - migrer heroku vers coolify - heroku vers coolify - quitter heroku - guide migration heroku - alternative heroku - migration postgres coolify - variables config heroku coolify - migration PaaS auto-hébergé type: article author: Ross Hill locale: fr_CA site_name: MapleDeploy slogan: Hébergement performant en sol canadien organization_url: 'https://mapledeploy.ca/' logo: 'https://mapledeploy.ca//api/logo/lockup' creator: MapleDeploy publisher: MapleDeploy founding_date: '2026-01-13' email: hello@mapledeploy.ca geo_region: CA-QC geo_placename: Montréal address_country: CA area_served: Canada application_category: DeveloperApplication app_url: 'https://app.mapledeploy.ca' llms_txt: 'https://mapledeploy.ca/fr/llms.txt' offers: >- Starter $45/mo, Pro $95/mo, Ultra $195/mo, Ultra 32 $395/mo, Ultra 64 $695/mo CAD in_language: fr-CA canonical_url: 'https://mapledeploy.ca/fr/blog/migrate-heroku-to-coolify' --- Heroku a banalisé le déploiement par `git push`. Toute une génération de développeurs a appris à livrer avec, et ce processus reste celui que la plupart des plateformes reproduisent. Si vous lisez ceci, la plateforme n'est probablement pas le problème. C'est autre chose qui a changé : la facture, le plafond de ressources ou l'endroit où vivent vos données. [Coolify](https://coolify.io) (en anglais) est l'une des destinations les plus fréquentes. C'est une plateforme de déploiement en logiciel libre qui s'exécute sur un serveur que vous contrôlez, avec le même modèle : on connecte un dépôt, on déploie. Ce guide couvre les équivalences, la séquence de migration et les responsabilités que Heroku assumait pour vous et qui deviennent les vôtres. ## Pourquoi les gens migrent **Le coût à grande échelle.** Heroku facture à la ressource. Un dyno Basic coûte 7 $ USD/mois pour un conteneur toujours actif, et les dynos Eco partagent une réserve de 1 000 heures-dyno à 5 $ USD/mois pour l'ensemble du compte, avec mise en veille après une période d'inactivité. Les bases de données et les modules complémentaires se facturent en plus. Rien de déraisonnable pris isolément. C'est l'addition qui surprend : un processus web, un worker, une base de données, un planificateur, un service de journalisation, puis la même chose en préproduction. Consultez la [page de tarification de Heroku](https://www.heroku.com/pricing) (en anglais) pour les chiffres à jour avant de bâtir votre modèle. **Des ressources dédiées.** Les dynos sont des conteneurs dimensionnés par palier. Pour plus de mémoire ou de CPU, on change de palier. Avec Coolify, vous déployez sur un serveur dont vous avez choisi les caractéristiques, et chaque application ou base de données qui y vit partage ces ressources selon vos règles. **La résidence des données.** Les régions libre-service de Heroku sont américaines et européennes. Une région canadienne existe via les Private Spaces, à un prix qui l'écarte pour la plupart des équipes. Si vos données doivent rester au Canada, c'est une contrainte ferme et non une préférence. Notre [comparatif complet avec Heroku](/fr/compare/heroku) présente le détail côte à côte. ## Table d'équivalences L'essentiel de ce que vous connaissez se transpose. Ce sont les noms qui changent. | Heroku | Coolify | |---|---| | App | Ressource « application » dans un projet | | Dyno | Conteneur qui exécute votre application | | Types de processus du Procfile | Une application par processus, ou une pile Docker Compose qui définit chaque service | | Buildpacks | Nixpacks (détection automatique) ou votre propre Dockerfile | | Config vars | Variables d'environnement | | Module Heroku Postgres | Une base de données PostgreSQL créée sur votre serveur | | Heroku Scheduler | Tâches planifiées, définies en syntaxe cron standard | | Release phase | Commandes de pré-déploiement et de post-déploiement | | Place de marché de modules | Services en un clic, ou n'importe quelle image Docker | Deux équivalences méritent une précision. **De la release phase aux commandes de déploiement.** La commande de pré-déploiement de Coolify s'exécute dans le conteneur existant avant la mise en ligne de la nouvelle version, et la commande de post-déploiement s'exécute dans le conteneur fraîchement construit. Les deux se configurent dans les réglages avancés de l'application et s'exécutent avec `sh -c`. Les migrations qui vivaient dans le processus `release` de votre Procfile appartiennent à la commande de post-déploiement. Heroku exécutait la release phase à partir du nouveau slug, alors que la commande de pré-déploiement de Coolify s'exécute à partir de l'ancienne image : une migration livrée dans le même commit ne s'y trouve pas encore. Gardez de toute façon vos migrations rétrocompatibles, puisque le nouveau conteneur commence à servir le trafic avant la fin de la commande de post-déploiement. **Du Scheduler aux tâches planifiées.** Les tâches planifiées de Coolify exécutent une commande à l'intérieur d'un conteneur que vous désignez, selon un horaire cron, avec la syntaxe complète à cinq champs et les horaires nommés comme `@daily`. Une nuance à retenir : elles s'exécutent dans le conteneur. Heroku Scheduler lançait chaque tâche dans son propre dyno ponctuel, tandis que Coolify exécute la commande dans le conteneur déjà en marche : votre application doit donc être active pour que la tâche se déclenche. Si vous avez besoin de lancer quelque chose sur l'hôte lui-même, ce n'est pas ce que fait cette fonction. ## La séquence de migration Suivez l'ordre. Le principe : rien n'est irréversible avant la dernière étape. 1. **Faites l'inventaire.** Lancez `heroku config -s` pour extraire vos config vars et `heroku addons` pour lister tous vos modules. Notez les types de processus de votre Procfile, la commande de release phase s'il y en a une, vos tâches Scheduler et vos domaines personnalisés. Abaissez dès maintenant le TTL de ces enregistrements DNS pour que la bascule soit rapide plus tard. 2. **Montez l'application sur Coolify à partir du même dépôt.** Connectez votre fournisseur Git, créez un projet, ajoutez le dépôt comme application. Si vous avez un Dockerfile, utilisez-le. Si vous dépendiez des buildpacks, commencez par Nixpacks et voyez jusqu'où ça vous mène. Notre [guide de déploiement Coolify](/fr/blog/deploy-app-coolify-guide) couvre le choix de la méthode de build, la configuration des ports et les pièges courants. 3. **Transférez les variables d'environnement.** Copiez-les, sauf celles que Heroku générait pour vous. `DATABASE_URL` et les identifiants de modules seront remplacés par les valeurs de vos propres services. Portez attention aux variables dont votre framework a besoin au build plutôt qu'à l'exécution : celles-là doivent être marquées comme variables de build. 4. **Migrez les données Postgres.** Créez d'abord une base PostgreSQL dans Coolify, puis déplacez les données. Le principe : `pg_dump` depuis la chaîne de connexion Heroku en format personnalisé, puis `pg_restore` vers la nouvelle base avec `--no-owner --no-acl`, pour éviter qu'il tente de recréer les rôles de Heroku. Utilisez des versions de `pg_dump` et de `pg_restore` au moins aussi récentes que la plus récente des deux bases, car des outils clients plus anciens refusent de lire un serveur plus récent. Faites un essai jetable maintenant pour attraper les problèmes de schéma, et un essai final au moment de la bascule. 5. **Testez sur l'URL temporaire.** Coolify attribue une URL temporaire à chaque application avant même d'y attacher un domaine. Exercez les vrais parcours : connexions, tâches en arrière-plan, téléversements, tâches planifiées, tout ce qui touche une API externe. C'est l'étape qu'on bâcle, et c'est celle qui révèle la variable d'environnement manquante. 6. **Basculez le DNS.** Mettez l'application Heroku en mode maintenance et réduisez à zéro vos dynos worker (le mode maintenance ne bloque que le trafic web : les workers et les tâches du Scheduler continuent de tourner), prenez un dernier dump, restaurez-le, puis pointez votre enregistrement A vers votre serveur Coolify. C'est cette combinaison qui rend ce dernier dump cohérent : traitez-la comme un gel des écritures planifié et chronométrez l'essai jetable de l'étape 4 pour en estimer la durée. Avec un TTL bas, la majorité du trafic suit en quelques minutes. Coolify provisionne le certificat Let's Encrypt dès que le domaine pointe vers le serveur. 7. **Gardez Heroku en marche.** Ne supprimez rien avant au moins une semaine. Laissez l'application et sa base de données en place, et continuez de payer, le temps d'observer un cycle complet de trafic, de sauvegardes et de tâches planifiées sur la nouvelle installation. 8. **Démantelez.** Retirez les modules, supprimez l'application, annulez ce qui reste. Conservez une dernière sauvegarde Heroku hors plateforme avant que la base disparaisse. ## Ce que vous reprenez à votre charge Voici la partie honnête. Heroku accomplit un vrai travail qui devient le vôtre dès que vous auto-hébergez. **L'entretien de la plateforme.** Correctifs du système d'exploitation, mises à niveau de Docker, mises à jour de Coolify, espace disque, vérification des sauvegardes, surveillance de la disponibilité. Heroku faisait tout ça sans que vous le voyiez, et vous le facturait à même le prix du dyno. Sur un VPS que vous avez loué vous-même, ça devient votre samedi. **Le comportement des buildpacks.** Les buildpacks de Heroku encapsulent des années de connaissances sur la façon dont chaque framework veut être construit. Les détecteurs automatiques de Coolify, Nixpacks et Railpack, couvrent beaucoup de projets standards. Quand aucun des deux ne correspond à votre configuration, c'est vous qui écrivez le Dockerfile. Plus de contrôle, plus de travail. **L'écosystème de modules.** La place de marché de Heroku vous donne des services tiers avec leur propre soutien et leur propre facturation. Sur Coolify, vous déployez les équivalents sur votre serveur, via les services en un clic ou n'importe quelle image Docker. La couverture est plus large, mais c'est vous qui les gardez en vie. La moitié « entretien » de cette liste, c'est précisément ce qu'un hébergeur Coolify géré vous reprend. La couche plateforme est prise en charge, et vous gardez le serveur dédié et la pile en logiciel libre en dessous. ## La place de MapleDeploy MapleDeploy offre Coolify entièrement géré sur une [infrastructure canadienne](/fr/canadian-hosting) à Toronto. Nous nous occupons de la machine virtuelle, des mises à jour du système, des correctifs de sécurité, de la surveillance et des instantanés hebdomadaires. Vous obtenez la plateforme de déploiement sans l'administration de serveur. Tarification fixe en dollars canadiens, à partir de 45 $ CAD/mois pour une machine virtuelle dédiée de 4 Go, bases de données, SSL et déploiements inclus. Déployez autant d'applications et de bases de données que le serveur peut en contenir, sans facturation à la ressource à prévoir. Consultez [notre tarification](/fr/#pricing) pour la liste complète des forfaits. {% cta-section title="Déplacez votre première application" %} Essai gratuit de 30 jours sur les forfaits Starter et Pro. Pointez Coolify vers votre dépôt, testez sur l'URL temporaire, basculez quand vous êtes prêt. {% /cta-section %}