Remplacer une facture Heroku de 3 000 $ par mois par un serveur à 55 $ par mois

• La plateforme associative de recherche d’emploi Idealist a migré vers un serveur dédié à bas coût pour résoudre le problème du coût élevé des environnements de staging sur Heroku
• Sur Heroku, la tarification par environnement faisait qu’un environnement de staging coûtait environ 500 $ par mois
• À la place, l’équipe a configuré plusieurs environnements sur un seul serveur Hetzner CCX33 (55 $ par mois) et a conservé la même expérience git push et d’automatisation que sur Heroku grâce à Disco
• Six environnements de staging fonctionnent de manière stable sur un seul serveur, avec une utilisation CPU de 2 % et 14 Go de mémoire utilisés sur 32 Go, laissant une marge confortable
• Les environnements de staging sont ainsi passés du statut de « poste de coût contraignant » à celui de « ressource que l’on peut créer librement », améliorant fortement la culture d’expérimentation et de déploiement de l’équipe de développement

---

Retour d’expérience sur une stratégie pragmatique de réduction des coûts Heroku

Le problème : un environnement de staging à 500 $ par mois

• Idealist.org est une grande plateforme associative de recherche d’emploi accueillant plusieurs millions de visiteurs par mois, et des environnements de staging quasi identiques à la production y sont indispensables
• Sur Heroku, le coût d’un environnement de staging combinant les web/worker dynos et les add-ons nécessaires comme Postgres atteignait environ 500 $ par mois
• Même en ne conservant que dev et main, cela représentait plus de 1 000 $ de coût fixe
• Le modèle tarifaire de Heroku est une facturation par environnement : réduire le nombre de dynos fait peu baisser la facture, et les coûts explosent à mesure que le nombre d’applications augmente

L’expérimentation : migrer vers un serveur unique

• Pour viser une réduction idéale des coûts, l’équipe a commencé à expérimenter avec la location d’un serveur unique Hetzner CCX33 (55 $ par mois)
• En utilisant la solution Disco, elle a pu reproduire telle quelle sur le serveur l’approche de déploiement par git push de Heroku
• Tous les environnements de staging utilisent la même instance Postgres partagée sur le serveur, ce qui réduit fortement le coût des bases de données managées
• Du point de vue des tests, cela convient bien car il est facile de réinitialiser des bases de données isolées par développeur

Pourquoi utiliser Disco : ce qui le distingue de Docker Compose

• Un simple docker-compose up sur un serveur n’offre pas à lui seul une expérience développeur suffisante
• Disco apporte les avantages suivants
  • Le même processus de déploiement par git push que sur Heroku
  • La prise en charge automatique des déploiements sans interruption pour tous les déploiements
  • L’émission et le renouvellement automatiques de certificats SSL pour les URL par branche
  • Une interface web intuitive pour la gestion des logs et des environnements
• Cela permet de conserver le confort de déploiement sans avoir à concevoir ni maintenir soi-même une automatisation dédiée

Explosion du nombre d’environnements de staging et efficacité des ressources serveur

• Avec Disco, l’extension des environnements de staging devient très simple
• Un seul serveur fait tourner simultanément les environnements suivants
  • La branche principale
  • La branche feature-freeze
  • Des environnements jetables temporaires pour les PR
  • Des environnements de longue durée pour le développement de fonctionnalités majeures, etc.
• Au total, 6 environnements de staging indépendants tournent sans difficulté
• Là où Heroku demanderait 3 000 $ par mois, la structure sur Hetzner reste peu coûteuse avec seulement 2 % de CPU et 14 Go de mémoire (sur 32 Go) consommés

Compromis et considérations réalistes

• Ce n’est pas une alternative parfaite, et cela ajoute plusieurs contraintes d’exploitation
• Les tâches d’infrastructure comme la configuration DNS ou CDN pour chaque nouvel environnement ne sont pas automatisées
• Il faut assumer la responsabilité opérationnelle : supervision du serveur, mises à jour de sécurité, gestion des incidents, etc.
• Hetzner ayant une présence limitée aux États-Unis, cela peut être inadapté à un service de production destiné à des utilisateurs américains
• Il existe un compromis de disponibilité : en cas de panne du serveur, il faut accepter une réinstallation
• Adapter l’application au réseau Docker a demandé environ une journée de travail d’ingénierie

Enseignements et évolution

• Après plus de six mois d’exploitation, cette infrastructure s’est installée comme une structure pérenne
• Le changement le plus important n’est pas seulement la baisse des coûts, mais le fait que les environnements de staging soient désormais perçus comme une ressource abondante et libre d’accès
• Les développeurs peuvent maintenant créer librement des environnements par pull request, sans demander d’autorisation ni se soucier du coût
• L’équipe en a tiré la leçon suivante : au-delà du coût, la réticence même à utiliser ces environnements constituait la véritable perte
  • « La contrainte financière freinait la vitesse de développement et l’expérimentation »

[GN⁺]

Commentaires sur Hacker News

• En regardant la capture d’écran de htop, j’ai remarqué l’absence de swap, donc je recommande d’activer earlyoom pour éviter qu’un serveur entier ne tombe quand un service se met à consommer anormalement la mémoire ; l’OOM killer du noyau Linux intervient généralement trop tard. On peut aussi activer zram pour compresser la RAM et surprovisionner comme un pro. Les logiciels qui tournent longtemps finissent souvent par avoir des fuites mémoire, et la compression est alors assez efficace. J’ai résumé dans un gist comment l’appliquer à des serveurs bare metal Hetzner avec Ansible ; ça fonctionne de la même façon sur des VM.

  • Je ne suis absolument pas d’accord : une fois qu’on atteint le swap, la plupart des applis commencent à avoir de gros problèmes. C’est un fait bien connu, et les instances AWS EC2 désactivent aussi le swap par défaut. Bien sûr, AWS a intérêt à vendre plus de RAM, mais le swap n’est plus adapté aux attentes actuelles. Dans les années 90, attendre 2 ou 3 secondes après un clic était acceptable ; aujourd’hui, si ça ne répond pas, on pense que c’est mort et on redémarre tout de suite.

  • Une autre option consiste à ajouter plus de mémoire et à ajuster le oom_score par application, en donnant un poids d’élimination plus élevé aux applis non critiques et un poids négatif aux applis importantes. Par exemple, OpenSSH a déjà oom_score_adj défini à -1000. Il est aussi très utile de désactiver pratiquement l’overcommit sur les serveurs de staging/production. On calcule et configure min_free et les valeurs de réserve à partir de formules selon la quantité de RAM. J’ai constaté en production que cela fonctionne sur plus de 50 000 serveurs physiques exploités sans swap depuis plus de dix ans. Les OOM ne surviennent que lorsqu’on estime mal les besoins mémoire lors d’un déploiement de code. Il y aurait aussi beaucoup à dire quand on ne suit pas les bonnes pratiques Java. On peut également imposer des limites mémoire par application avec des cgroups, mais je passe les détails. Si c’est un serveur entièrement en mémoire qui n’a pas besoin d’écrire sur disque, je recommande aussi d’empêcher complètement les OOM et de le laisser s’auto-réparer automatiquement. Laisser un peu de temps pour capturer les messages de crash via DRAC/iLO et configurer les redémarrages sur panic (kernel.panic, vm.panic_on_oom, etc.) est également utile. À noter qu’on peut aussi s’en servir volontairement comme déclencheur de redémarrage de toute la ferme lors d’une reprise après incident sur un système diskless avec NFS.

  • Merci pour ces bonnes infos. Je contrôle déjà les seuils RAM via les limites système (systemd), mais je me demande si earlyoom n’est pas un meilleur choix pour éviter qu’un comportement anormal d’un processus ne rende l’instance entière non réactive.

  • Je pense que garder une toute petite quantité de swap, par exemple 1 Go, est une bonne idée par précaution.

  • Je n’utilise plus de swap depuis 2010.

• J’ai vu hier que Nate Berkopec avait écrit sur un sujet proche à propos des performances Rails, en disant que Heroku était 25 à 50 fois plus cher à performance égale. C’est presque déprimant de voir à quel point ils n’ont aucune volonté de concurrencer sur les prix, et je pense que s’ils se contentaient de licencier toute la stack à un tarif raisonnable, comme Sidekiq, ce serait bien mieux, même avec du matériel séparé. En 2025, faire payer 50 $ pour un dyno de 1 Go de RAM, c’est presque du vol. Surtout qu’une appli Rails standard n’a pas connu de variation majeure de ressources par rapport à avant, et est même devenue plus efficace ; pourtant les prix ont augmenté et la qualité a baissé. C’en est presque ridicule de voir autant de développeurs faire tourner leurs applis sur Heroku pour plusieurs centaines de dollars par mois, sur du matériel plus lent que leur MacBook de développement. Au final, comme dans beaucoup d’autres domaines aujourd’hui, la tendance n’est plus à fournir un bon produit à un prix raisonnable au plus grand nombre, mais à se concentrer uniquement sur les gros clients les plus riches tout en augmentant les prix.

  • Le problème ne se limite pas aux hausses de prix. Je pense que Heroku et les fournisseurs cloud profitent aussi d’un effet d’ancrage psychologique sur les prix. Quand les utilisateurs commencent à utiliser un service, ils fixent un repère tarifaire et leurs attentes n’évoluent ensuite que de façon linéaire. En réalité, les performances du matériel de calcul progressent de manière exponentielle, mais les utilisateurs ne les perçoivent que de manière linéaire. Les prix de Heroku n’ont pratiquement pas changé depuis au moins sept ans, alors que le matériel a énormément progressé. Si cela donne une impression d’arnaque, c’est en fait parce qu’on compare le point de référence de 2025 à des prix du milieu des années 2010. Les grands fournisseurs cloud ajoutent des obstacles comme le déverrouillage de nouvelles performances matérielles ou des mises à jour de SKU. Heroku, sans ce type de concurrence, a gardé ses prix fixes, et ce genre de billet revient régulièrement à chaque fois qu’une nouvelle génération d’ingénieurs se rend compte des performances réelles du matériel.

  • Tu dis qu’un dyno de 1 Go de RAM à 50 $ est du vol, mais AWS n’est pas tellement différent. À 50 $/mois, on a un m7a.medium, soit 1 vCPU et 4 Go de RAM. Il y a plus de mémoire, certes, mais on comprend vite comment AWS gagne autant d’argent.

  • Je partage l’idée qu’il serait bien d’avoir, comme Sidekiq, un modèle qui licence toute la stack logicielle à prix raisonnable, donc nous avons rendu canine.sh open source. On trouvait absurde que des fournisseurs PaaS ajoutent déjà une marge excessive au-dessus d’un cloud lui-même déjà margé.

  • C’est un peu comme dire qu’une vidange chez le garagiste du coin ou qu’un steak au restaurant coûte moins cher si on le fait soi-même.

• Le cloud fait oublier tout ce qu’on peut faire avec un seul serveur. Même pour un environnement de staging, j’ai du mal à comprendre qu’on le mette sur un cloud coûteux, même si je vois bien qu’aujourd’hui les clouds mêlent tellement d’éléments complexes qu’on finit par comprendre pourquoi c’est devenu nécessaire.

  • Former plusieurs développeurs aux bases du cloud et garder quelques spécialistes cloud est rentable pendant un bon moment. Si les environnements de staging et de prod se ressemblent, on repère aussi les erreurs plus vite. Ensuite, on finit par payer plus en factures cloud qu’en salaires, et c’est à ce moment-là que sortir du cloud devient vraiment rentable. J’ai l’impression qu’en passant finalement sur ses propres serveurs, on atteint assez vite le moment où la facture dépasse à la fois le coût de l’équipe et celui du matériel.

  • J’ai l’impression que le cloud a fini par faire peur aux développeurs dès qu’il s’agit d’un serveur Linux tout simple. Je pense qu’une grande partie de la marge est le prix de cette anxiété. Pourtant, l’auto-hébergement est en réalité simple et amusant. Je n’ai jamais été attiré par Heroku, Vercel et autres, et je pense qu’il n’y a pas de meilleure expérience que de monter son propre serveur dès le départ. Je recommande à tous les développeurs d’essayer au moins une fois.

  • C’est très utile de répliquer complètement l’environnement de prod pour qu’il ressemble vraiment à l’exploitation réelle. Le processus de déploiement devient similaire, on gagne du temps, et on teste dans des conditions beaucoup plus proches de la prod.

  • Ce serait amusant de créer, à partir de cette idée, un site d’apprentissage de l’infra : on te donne X ressources dans le cloud, tu dois les configurer pour tenir une charge donnée, puis les gens peuvent se comparer sur leur score de performance.

  • Vers 2006, la plus petite machine AWS était de la taille d’un bon poste de dev de bureau, au point qu’il fallait la louer plus de deux ans pour que ce soit rentable. Aujourd’hui, les machines AWS sont au niveau d’un téléphone mobile ou d’un portable bas de gamme, et au bout de 3 à 6 mois de location, acheter le matériel devient plus avantageux. Sauf à avoir 75 % de remise, l’on-premise est plus économique que le cloud à la fois en personnel et en coûts.

• Bonjour, je développe avec mon ami Antoine Leclair un PaaS open source appelé Disco. En ce moment, il y a beaucoup de discussions autour de l’auto-hébergement et de la sortie du cloud. N’hésitez pas si vous avez des questions.

  • Quand tu disais que « l’utilisation des ressources serveur était très faible », c’est encore plus impressionnant si on se rappelle que le load average dans htop est mesuré par cœur CPU. Par exemple, sur 8 cœurs, un load average de 0,1 représente seulement 1,25 % de la capacité CPU totale. J’ai beaucoup aimé lire le billet, et ce genre de schéma me fait aussi progresser.

  • Je me demande ce que Disco apporte de vraiment spécifique par rapport à des outils comme Coolify. J’héberge déjà la plupart de mes services sur un VPS Hetzner, donc si Disco a un avantage distinctif, ça m’intéresse.

• On a eu une expérience similaire chez Hack Club. Notre association se concentre sur l’initiation des lycéens au code et à l’électronique. Avant, on utilisait Heroku, mais au-delà du coût, on se demandait aussi si cette petite appli utilitaire valait vraiment 15 $ par mois. Cette année, on est passés à l’auto-hébergement avec Coolify et on fait tourner 300 services sur un seul serveur Hetzner à 300 $/mois. Résultat : on a pu déployer bien plus de code. La plus grande leçon, c’est que si on n’a besoin que de 99 % de disponibilité au lieu de 99,99 %, le champ des possibles s’élargit énormément. La plupart des outils pour développeurs sont obsédés par les 99,99 %, alors que 99 % suffisent souvent pour fonctionner efficacement. Disco m’intéresse aussi, je compte clairement l’essayer.

  • Merci, et si vous avez la moindre question sur le service Disco, n’hésitez pas à venir sur Discord. On a deux cas similaires : dans une école de bootcamp/développement à Porto Rico, ils ont fait déployer tous les projets finaux des étudiants sur un VPS unique, et au Recurse Center, ils hébergent 75 projets web sur un seul Raspberry Pi (lien).

  • Et si vous avez vraiment besoin de 99,99 %, je pense justement qu’il vaut mieux éviter les hyperscalers. La panne de plusieurs heures qu’AWS a connue récemment en est un bon exemple.

  • 300 ? Je suis curieux de savoir à quoi servent tous ces services individuellement.

• Vu la situation actuelle, je pense vraiment que l’auto-hébergement est une solution très séduisante, mais il y a quelque chose que je veux signaler à propos de l’article lui-même. Le texte donne l’impression d’avoir été fortement édité par une IA et, de fait, la partie « Bridging the Gap: Why Not Just Docker Compose? » est un copier-coller quasi mot pour mot du « Powerful simplicity » de la landing page du produit Disco. Ce billet de blog est aussi la seule étude de cas visible sur leur page principale.

  • C’est tout à fait vrai. Je pourrais avancer trois arguments à l’appui (je plaisante), mais notre bibliothèque est open source et je suis fier qu’Idealist ait économisé de l’argent. Si être fier revient à faire de la promo, alors oui, j’en suis tout à fait fier.

  • On dit que c’est un article marketing, mais je me demande pourquoi ce serait un problème. Est-ce interdit par les règles de Hacker News, ou bien pensez-vous que tout marketing devrait être explicitement signalé ? Il existe très peu de textes qui ne soient pas, d’une manière ou d’une autre, du marketing.

  • Écrire un billet marketing sur la concurrence par les prix tout en ne publiant pas les tarifs sur son propre site, en se contentant de proposer de prendre rendez-vous, c’est pour moi le plus gros signal d’alerte sur les prix.

  • J’ai moi aussi immédiatement voulu comprendre le modèle économique, mais je n’en ai conclu qu’une chose : les tarifs seront sans doute publiés bientôt.

  • Ce n’est pas la première fois qu’on voit un billet mêlé de marketing, et je me demande toujours ce qu’on reproche exactement à ce format centré sur des cas concrets. C’est un exemple relativement modéré, et malgré sa dimension marketing, je l’ai trouvé intéressant et utile.

• Les prix de Heroku sont vraiment délirants. Il y a une dizaine d’années, dans une startup où j’ai travaillé, j’ai été choqué de voir qu’on dépensait plus de 10 000 $ par mois juste pour faire tourner un service qui générait des QR codes dans un tableau HTML pour les afficher dans des e-mails. Ça revenait à 0,15 $ l’unité. Le lead dev n’avait jamais fait de profiling du code, donc on est descendus à 0,01 $ l’unité, mais même là c’était absurde.

  • Je ne comprends pas pourquoi générer un simple QR code coûterait autant. Même un hébergement edge cloud permettrait de faire ça gratuitement.

• J’ai du mal à comprendre pourquoi il faudrait six serveurs de staging à 500 $ chacun. Si c’est à cause d’une grosse équipe, alors 3 000 $ de serveurs, ce n’est presque rien par rapport à plus de 100 000 $ de masse salariale annuelle, non ? J’ai regardé idealist.org, ça semble juste être un site d’offres d’emploi, donc ça me paraît excessif.

  • Les six serveurs de staging servent à avoir main, dev et plusieurs branches que des QA non développeurs peuvent vérifier directement. Avec des déploiements de staging comprenant des dynos Performance-M, plusieurs dynos Standard, RabbitMQ, la base de données, etc., la facture grimpe très vite. Le service Idealist touche 100 000 utilisateurs par jour, donc il y a beaucoup de technique derrière la fiabilité et la rapidité.

  • À la lecture, j’ai eu l’impression qu’ils avaient créé plusieurs serveurs de staging pour servir d’environnements de dev où chaque développeur pouvait lancer plusieurs services en parallèle, d’où leur nombre.

  • Dans les calculs de coût réels, tout le monde a tendance à négliger le coût humain en jours-homme.

• Je cherche à remplacer Heroku tout en gardant juste un site Django et sa base de données dumpée, et je me demande quelle est la meilleure option si je veux éviter d’administrer moi-même le système.

  • Render.com est probablement ce qu’il y a de plus proche, et j’en suis vraiment satisfait. Le workflow est identique à Heroku, c’est moins cher, et aussi bien les redémarrages nocturnes que le support des dernières versions de Python me conviennent.

  • Je recommande aussi d’apprendre Docker Swarm : le déploiement se fait en poussant un conteneur puis avec une seule commande. J’ai aussi créé moi-même rove.dev, un outil CLI gratuit qui sert à la fois au déploiement et au diff de services. Sinon, un PaaS basé sur VM peut aussi être une bonne option. Voir aussi Semaphore, Dokku, Dokploy.

  • Il suffit de choisir le VPS que vous voulez selon le prix, les performances, la localisation et le support, puis d’y ajouter l’outil de déploiement de votre choix, comme Coolify ou Dokploy. J’ai récemment migré facilement Django/Postgres depuis Google App Engine avec Coolify et Mythic Beasts. Même avec une expérience devenue un peu rouillée, la migration s’est faite très simplement.

  • À mon avis, il suffit de lancer un seul serveur chez Hetzner, puis de configurer nginx et quelques services systemctl.

  • PythonAnywhere (lien) est aussi une bonne option.

• Beau projet. En lisant la documentation, j’ai l’impression que l’intégration GitHub est une condition obligatoire pour Disco ; est-ce bien le cas ? Et est-ce qu’on peut aussi déployer directement des images Docker existantes depuis son propre registre, sans phase de build séparée, un peu comme --skip-push --version latest dans Kamal ?

  • Oui, pour l’instant l’intégration GitHub est nécessaire. Mais Disco peut aussi récupérer et déployer directement une image Docker existante (c’est ainsi qu’on auto-héberge RabbitMQ). Pour un exemple de déploiement de l’image Meilisearch, voir ici et ce tutoriel. Je suis curieux de savoir si, chez toi, le processus habituel consiste à builder puis pousser vers un registre, et j’aimerais bien entendre plus en détail comment se passe ton déploiement.