Le plan gratuit est mort — alternatives à Heroku qui en proposent encore un

Pourquoi les fondateurs cherchent des alternatives à Heroku

Pendant des années, l'histoire du déploiement pour les indie builders était simple : push sur Heroku, obtenir une URL. Le plan gratuit gérait les projets perso, les MVP et les apps de démo. Quand vous aviez besoin de plus, vous montiez en dynos payants. L'expérience développeur était excellente et les prix étaient justes pour ce qu'on obtenait.

Deux choses ont changé la donne.

Premièrement, Heroku a supprimé le plan gratuit en novembre 2022. Du jour au lendemain, des centaines de milliers de projets perso avaient besoin d'un nouveau foyer. Le dyno Eco à 5 $/mois (partagé entre apps, avec mise en veille après inactivité) et le dyno Basic à 7 $/mois (toujours actif) ont remplacé ce qui était gratuit.

Deuxièmement, la concurrence s'est améliorée. Railway, Render et Fly.io ont tous lancé avec des expériences développeur qui égalent ou dépassent Heroku, à des prix inférieurs, avec une facturation plus transparente. Le dashboard, la CLI et le pipeline de déploiement de Heroku — autrefois les meilleurs du marché — ont commencé à paraître datés.

Pour un fondateur bootstrapé qui déploie un produit SaaS, le choix d'hébergement compte parce que c'est un coût récurrent qui se cumule. Une différence de 20 $/mois en hébergement représente 240 $/an. Sur 3 ans, c'est 720 $ — assez pour un nom de domaine, un service email et quelques mois d'outils marketing. L'optimisation du burn rate commence par l'infrastructure.

Comment nous avons évalué ces alternatives

Nous avons déployé la même application (une API Node.js avec Postgres, Redis et un worker en arrière-plan) sur chaque plateforme et mesuré :

• Vitesse de déploiement : Temps entre le git push et l'URL en ligne
• Latence de cold start : Rapidité de la première requête servie après une période d'inactivité (important pour les plans gratuits qui se mettent en veille)
• Fiabilité : Uptime sur 30 jours avec monitoring synthétique
• Coût à faible trafic : Facture mensuelle pour une app gérant 10 000 requêtes/jour
• Coût à trafic modéré : Facture mensuelle pour une app gérant 100 000 requêtes/jour
• Expérience base de données : Facilité de provisionner, connecter et gérer une instance Postgres

Nous avons priorisé le profil indie builder : livrer un produit rapidement, maintenir les coûts bas, et éviter une infrastructure qui nécessite un DevOps à plein temps.

Analyse détaillée : ce que chaque alternative fait de mieux

Railway — le successeur de Heroku

Railway, c'est ce que serait Heroku s'il était construit aujourd'hui. L'expérience de déploiement est fluide : connectez un repo GitHub, Railway détecte automatiquement le framework et le langage, build l'app et la déploie. Le processus entier prend moins de 90 secondes pour une application Node.js ou Python typique.

L'expérience base de données intégrée est le domaine où Railway surpasse Heroku. Cliquez sur un bouton pour provisionner Postgres, MySQL, Redis ou MongoDB. La chaîne de connexion est automatiquement injectée en variable d'environnement. Pas de marketplace d'add-ons, pas de configuration tierce, pas de copier-coller de connection strings entre dashboards. Ca marche, tout simplement.

Les environnements de preview sont un autre atout. Chaque pull request obtient son propre déploiement avec sa propre base de données. C'est standard en CI/CD enterprise mais rare dans les plateformes indie-friendly. Pour un fondateur solo qui utilise les PR GitHub même pour les projets perso, les environnements de preview attrapent les bugs avant la production.

Le plan Hobby à 5 $/mois inclut 5 $ de crédits d'usage. Une petite app (un service web, une instance Postgres, peu de trafic) coûte typiquement 3-8 $/mois en usage. Les 5 $ de crédit couvrent donc souvent la totalité de la facture pour un side project à faible trafic. Cependant, il n'y a pas de vrai plan gratuit — le minimum de 5 $/mois s'applique même si votre usage est de 0 $.

La tarification à l'usage est l'arme à double tranchant de Railway. Vous payez pour le compute (par heure de vCPU), la mémoire, le trafic sortant et le stockage de base de données. Pour des apps à faible trafic et prévisibles, c'est bon marché. Pour des apps avec des pics de trafic (comme être mis en avant sur Hacker News ou Product Hunt), la facture peut grimper de manière inattendue. Configurez des alertes de facturation.

Les options de régions de Railway sont limitées par rapport à Fly.io. La plupart des déploiements tournent dans des régions US. Si vos utilisateurs sont principalement en Europe ou Asie-Pacifique, la latence supplémentaire peut être perceptible pour les applications sensibles à la latence API.

Quand choisir Railway : Vous voulez la migration la plus facile depuis Heroku, la meilleure expérience développeur et une tarification transparente. Idéal pour les MVP SaaS et les apps en production avec un trafic prévisible.

Render — le champion du plan gratuit

Render s'est positionné comme l'alternative Heroku avec un vrai plan gratuit, et il tient sa promesse. Hébergement de sites statiques gratuit avec 100 Go de bande passante par mois. Services web gratuits avec 750 heures de compute par mois. Ce sont des offres réellement utilisables pour des side projects, des sites de documentation et des environnements de staging.

Le piège des services web gratuits, c'est la mise en veille. Après 15 minutes d'inactivité, votre service s'endort. La première requête après la veille déclenche un cold start qui prend 30 à 60 secondes. Pour une API perso que vous interrogez de temps en temps, c'est acceptable. Pour un produit face aux utilisateurs, les cold starts sont un tueur de taux de conversion.

Le plan Individual payant à 7 $/mois par service supprime la mise en veille et vous donne une instance dédiée. C'est comparable au dyno Basic de Heroku à 7 $/mois, avec l'avantage du meilleur pipeline de déploiement de Render.

Le Postgres managé de Render est solide mais avec un piège : la base gratuite expire après 90 jours. Vous pouvez en créer une nouvelle (en migrant les données manuellement) ou passer au plan payant à 7 $/mois. C'est transparent dans la documentation mais surprend quand même les gens.

Les temps de build sont le point faible de Render. Les applications complexes avec de gros arbres de dépendances peuvent prendre 5+ minutes à build. Railway build typiquement la même application en 1-2 minutes. Pour un fondateur solo qui déploie plusieurs fois par jour, la différence de vitesse d'itération se fait sentir.

L'infrastructure sous-jacente est solide. Render tourne sur AWS et GCP avec SSL automatique, CDN pour les assets statiques et protection DDoS. L'uptime a été fiable dans notre monitoring.

Quand choisir Render : Vous avez besoin d'un plan gratuit pour des sites statiques, des environnements de staging ou des projets à faible trafic. Aussi solide pour les déploiements payants si la vitesse de build n'est pas une priorité.

Fly.io — la plateforme edge mondiale

Fly.io adopte une approche fondamentalement différente. Au lieu de faire tourner votre app dans un seul data center, Fly.io déploie vos conteneurs vers des points de présence dans le monde entier. Votre requête API est servie depuis le data center le plus proche de l'utilisateur qui fait la requête.

Pour un produit SaaS avec des utilisateurs à New York, Londres et Tokyo, cela signifie des temps de réponse sous les 100 ms pour tout le monde, sans la complexité de gérer un déploiement multi-régions vous-même. Les plateformes PaaS traditionnelles font tourner votre app dans une seule région (généralement US East ou EU West), et les utilisateurs éloignés de cette région subissent la latence supplémentaire.

L'API Machines est puissante pour l'optimisation des coûts. Le scale-to-zero signifie que votre app s'arrête quand aucune requête n'arrive et redémarre en quelques secondes quand le trafic arrive. Contrairement à la mise en veille du plan gratuit Render (30-60 secondes de cold start), les machines Fly.io redémarrent typiquement en 1-3 secondes.

L'allocation gratuite inclut 3 VMs partagées avec 256 Mo de RAM chacune. C'est suffisant pour une petite API ou un service web. Postgres est disponible avec read replicas, et Fly.io propose LiteFS pour du SQLite distribué — une option convaincante pour les applications à lecture intensive qui veulent de la réplication mondiale sans un cluster Postgres complet.

La courbe d'apprentissage est plus raide que Railway ou Render. Le déploiement utilise un outil CLI (flyctl) et un fichier de configuration fly.toml. Les concepts (machines, volumes, régions, secrets) demandent plus d'apprentissage initial. Le debug est plus difficile — les logs sont moins accessibles que sur les dashboards web de Railway ou Render, et vous devez parfois vous connecter en SSH sur la machine pour investiguer.

La tarification est granulaire. CPU, mémoire, bande passante et stockage sont tous facturés séparément. Une petite app coûte typiquement 3-10 $/mois, mais prévoir la facture exacte demande de comprendre les dimensions tarifaires. Le dashboard de facturation aide, mais c'est moins intuitif que le modèle de crédits de Railway.

Quand choisir Fly.io : Vos utilisateurs sont répartis dans le monde et le temps de réponse compte. Aussi convaincant pour l'edge computing, les applications temps réel et les apps où le scale-to-zero fait de vraies économies.

Coolify — votre propre PaaS

Coolify est une plateforme open source qui transforme n'importe quel VPS en plateforme de déploiement type Heroku. Installez-le sur un serveur Hetzner ou DigitalOcean à 5 $/mois, et vous obtenez le git push to deploy, le SSL automatique via Let's Encrypt, le provisionnement de bases de données en un clic et un dashboard web pour tout gérer.

Le calcul de coût est convaincant. Un seul CPX21 Hetzner à 10 $/mois (3 vCPU, 4 Go de RAM) peut héberger 5-10 petites applications web, plusieurs bases de données et des workers en arrière-plan. La même charge de travail sur Railway coûterait 5-15 $ par service, dépassant facilement 50 $/mois. Sur Render, même ordre de prix. Coolify consolide tout en un coût d'infrastructure fixe.

L'expérience de déploiement reproduit Heroku de près. Connectez un repo GitHub, Coolify détecte le buildpack, build l'application et la déploie en conteneur Docker. Nixpacks (le même builder que Railway utilise) gère la détection automatique du langage et du framework. Les Dockerfiles personnalisés marchent aussi.

La gestion de bases de données se fait en un clic. Postgres, MySQL, MongoDB, Redis et d'autres se déploient en conteneurs managés sur votre serveur. Coolify gère les sauvegardes automatiques (fréquence et rétention configurables) et l'injection de chaînes de connexion.

Les compromis sont les compromis de l'auto-hébergement. La maintenance serveur (mises à jour OS, correctifs de sécurité, monitoring du disque) est votre responsabilité. Il n'y a pas de failover automatique — si votre serveur tombe, toutes vos apps tombent. Il n'y a pas de CDN mondial ni de déploiement multi-régions sauf si vous le configurez vous-même. Monitorer votre serveur avec des outils comme Uptime Kuma (que Coolify peut déployer pour vous) est indispensable.

Pour un fondateur technique à l'aise avec l'administration Linux de base, Coolify est l'option avec le meilleur rapport qualité-prix de cette liste. Les économies se cumulent dans le temps, et vous possédez toute votre infrastructure.

Quand choisir Coolify : Vous êtes technique, à l'aise avec les serveurs Linux, et voulez minimiser les coûts d'hébergement en consolidant plusieurs services sur un seul VPS.

DigitalOcean App Platform — le choix enterprise sûr

DigitalOcean App Platform est l'offre PaaS managée de l'un des fournisseurs cloud les plus établis pour les développeurs indie. Si vous utilisez déjà des Droplets DigitalOcean, des bases managées ou Spaces, App Platform s'intègre naturellement.

L'expérience de déploiement est compétente mais pas remarquable. Connectez un repo GitHub, sélectionnez votre branche, configurez les variables d'environnement, déployez. La détection de build fonctionne pour les frameworks courants. Le dashboard permet de consulter les logs, métriques et l'historique des déploiements.

L'hébergement statique gratuit couvre 3 sites avec 1 Go de stockage et 1 Go de bande passante. C'est modeste comparé à Render (100 Go de bande passante) mais fonctionnel pour des sites de documentation ou des landing pages.

La tarification par conteneur est la principale limite. Un conteneur Basic à 5 $/mois fait tourner une seule instance. Ajoutez un worker et c'est 5 $/mois de plus. Ajoutez une base Postgres managée (7 $/mois minimum) et vous êtes à 17 $/mois pour un stack d'app web standard. Railway gère la même charge pour 5-10 $/mois en tarification à l'usage.

La valeur d'App Platform, c'est le contexte. Si votre infrastructure est déjà sur DigitalOcean — Droplets pour le compute, bases managées pour les données, Spaces pour les fichiers — App Platform s'inscrit naturellement dans cet écosystème. Le réseau privé entre les services App Platform et vos ressources DigitalOcean existantes fonctionne nativement.

Quand choisir DigitalOcean App Platform : Vous êtes déjà investi dans l'écosystème DigitalOcean et voulez un PaaS qui s'intègre avec votre infrastructure existante.

Dokku — le Heroku auto-hébergé originel

Dokku est le projet le plus ancien de cette liste et le plus simple. C'est littéralement un script bash qui installe une plateforme de déploiement compatible Heroku sur n'importe quel serveur Ubuntu. Si vous connaissez Heroku, vous connaissez Dokku.

La compatibilité avec les buildpacks Heroku est l'atout majeur de Dokku. Si votre app se déploie sur Heroku avec un Procfile, elle se déploie sur Dokku sans aucune modification. Mêmes buildpacks, mêmes types de processus, même gestion des variables d'environnement. La migration se résume à un changement DNS et une mise à jour du remote git.

Dokku est extrêmement léger. Il tourne confortablement sur un VPS de 1 Go de RAM. L'écosystème de plugins couvre l'essentiel : Postgres, MySQL, Redis, SSL Let's Encrypt, HTTP auth et plus. Chaque plugin s'installe en une seule commande.

La limitation, c'est l'interface de gestion. Dokku est 100 % ligne de commande. Pas de dashboard web. Déployer, scaler, consulter les logs et gérer les bases de données se font via des commandes SSH. Pour un développeur qui vit dans le terminal, c'est parfait. Pour quiconque veut un aperçu visuel de ses déploiements, Coolify est la meilleure option auto-hébergée.

L'architecture mono-serveur signifie zéro redondance. Dokku ne supporte pas nativement le clustering, le load balancing ni le failover automatique entre serveurs. Pour un side project ou un SaaS en démarrage, c'est acceptable. Pour un produit avec des clients payants qui attendent des garanties d'uptime, il faut une infrastructure supplémentaire autour de Dokku ou une plateforme managée.

Quand choisir Dokku : Vous avez des apps Heroku existantes, voulez migrer avec un minimum de changements et êtes à l'aise avec la gestion 100 % CLI sur un VPS.

Le vrai coût d'infrastructure pour les indie founders

Voici ce qu'un MVP SaaS typique coûte réellement sur chaque plateforme (service web + Postgres + Redis + worker en arrière-plan) :

• Heroku : 7 $ (Basic dyno) + 9 $ (Mini Postgres) + 15 $ (Mini Redis) + 7 $ (worker dyno) = 38 $/mois
• Railway : Facturation à l'usage, typiquement 8-15 $/mois pour cette charge
• Render : 7 $ (web) + 7 $ (Postgres) + 7 $ (Redis) + 7 $ (worker) = 28 $/mois
• Fly.io : Facturation à l'usage, typiquement 10-18 $/mois selon les régions
• Coolify sur Hetzner : 5-10 $/mois (coût VPS uniquement, tous services inclus)
• DigitalOcean App Platform : 5 $ (web) + 7 $ (BD) + 5 $ (Redis) + 5 $ (worker) = 22 $/mois
• Dokku sur VPS : 5-10 $/mois (coût VPS uniquement)

Les options auto-hébergées (Coolify, Dokku) sont radicalement moins chères pour les déploiements multi-services parce que vous payez le serveur, pas par service. Les plateformes managées (Railway, Render, Fly.io) facturent par service mais gèrent toute l'infrastructure.

Votre choix dépend de ce que vous valorisez davantage : votre temps (plateforme managée) ou votre argent (auto-hébergement). Pour un side project pré-revenu, l'auto-hébergement fait de vraies économies. Pour un produit qui génère du CA, la plateforme managée libère des heures que vous pouvez investir dans les fonctionnalités et la croissance.

Quand rester sur Heroku

Heroku reste pertinent si :

• Vous avez des apps en production sur Heroku avec des dépendances d'add-ons complexes (Heroku Scheduler, Papertrail, New Relic) qui nécessiteraient une migration
• Votre équipe dépend de Heroku Pipelines pour le staging et les review apps dans un workflow CI/CD mature
• Vous avez besoin des certifications enterprise de Heroku (SOC 2, conformité HIPAA sur les Shield dynos)
• L'intégration avec l'écosystème Salesforce compte pour votre business (Heroku Connect pour la synchronisation de données Salesforce)
• Le coût de la migration dépasse les économies quand vous intégrez le temps d'ingénierie pour la migration

L'expérience développeur de Heroku reste bonne. Ce n'est plus la meilleure, mais ça fonctionne de manière fiable. Si votre facture Heroku est de 50 $/mois et qu'une migration prendrait 8 heures de temps d'ingénierie, le retour sur investissement prend un an ou plus. Assurez-vous que le changement en vaut la peine avant de vous engager.

Conseils pratiques pour la migration

1. Commencez par une app non critique. Déployez un side project ou un environnement de staging sur la nouvelle plateforme d'abord. Familiarisez-vous avec le pipeline de déploiement, les logs et le monitoring avant de déplacer la production.
2. Documentez vos add-ons Heroku. Listez chaque add-on, sa configuration et son rôle. Trouvez l'équivalent sur la nouvelle plateforme ou un service autonome qui le remplace.
3. Testez la migration de base de données. Utilisez pg_dump et pg_restore pour migrer les données Postgres. Testez le cycle complet sur une copie avant de toucher à la production. Vérifiez que toutes les contraintes, index et extensions sont préservés.
4. Mettez en place le monitoring immédiatement. Déployez un monitoring d'uptime (Uptime Robot, Better Uptime, ou Uptime Kuma en auto-hébergé) avant de router le trafic vers la nouvelle plateforme. Les pannes silencieuses sont le plus gros risque pendant une migration.
5. Utilisez un basculement par DNS. Pointez votre domaine vers la nouvelle plateforme via DNS. Gardez Heroku actif en parallèle pendant 48 heures au cas où vous auriez besoin de faire un rollback. Un TTL DNS de 300 secondes vous donne un chemin de rollback rapide.