Meilleures alternatives gratuites à Heroku

Notes de migration

Les apps Heroku supposent souvent process long-running, variables, add-ons et logs. Avant de migrer, séparez les vrais besoins de ce qui peut devenir statique, BaaS ou serverless.

Comparaison rapide

Choisir selon le workload

Choisissez Render quand le projet ressemble encore à une app Heroku classique : un process web, des variables d’environnement, un déploiement Git et peut-être un petit worker plus tard. C’est le chemin le moins surprenant pour Express, Django, Rails, Flask et les apps similaires. La contrepartie est la veille : les web services gratuits dorment quand ils sont inactifs, donc ce choix convient mieux aux démos, outils internes et APIs hobby qu’aux apps publiques critiques.

Choisissez Railway si ce que vous aimiez chez Heroku n’était pas seulement le dyno, mais tout le workflow développeur : templates, variables, bases de données et tableau de bord qui rassemble l’infrastructure du projet. Railway est très agréable pour prototyper, mais son chemin gratuit actuel repose sur un essai et des crédits. Considérez-le comme une plateforme développeur peu coûteuse, pas comme le retour de l’ancien free dyno Heroku.

Choisissez Cloudflare quand l’app Heroku peut être décomposée. Un site marketing peut devenir une sortie statique sur Pages. Un handler de webhook peut devenir un Worker. Une petite API peut se rapprocher de l’edge. C’est souvent le meilleur chemin gratuit durable lorsque l’app est stateless, mais ce n’est pas le bon choix pour un process long-running qui attend un serveur classique, des workers persistants ou des connexions TCP arbitraires.

Choisissez Firebase ou Supabase quand le serveur existe surtout pour fournir auth, accès base de données, fichiers ou realtime. Dans ce cas, remplacer le backend par du BaaS peut supprimer le besoin de dyno. C’est souvent moins cher et plus simple, mais cela demande généralement des changements dans le code applicatif.

Pièges cachés à vérifier

Le premier piège est la mise en veille. Les dynos Eco Heroku dorment, les web services gratuits Render dorment, et les fonctions serverless ont des cold starts ou des limites de runtime. Si une API visible par les utilisateurs doit répondre instantanément après une période d’inactivité, l’hébergement PaaS gratuit est rarement la bonne attente.

Le deuxième piège est l’état. Les add-ons Heroku facilitaient Postgres, Redis et les logs. En migrant, l’hébergeur de l’app et la base peuvent devenir deux produits distincts. Ce n’est pas un problème, mais il faut déplacer sauvegardes, chaînes de connexion, SSL et variables avec méthode.

Le troisième piège est le travail en arrière-plan. Cron, queues et workers sont souvent oubliés. Une plateforme statique ou edge peut remplacer beaucoup de trafic request/response, mais pas toujours un worker long-running sans redesign.

Checklist de migration

1. Listez chaque process dans le Procfile ou les scripts de démarrage.
2. Séparez trafic web, jobs, tâches planifiées et besoins base de données.
3. Exportez variables d’environnement et secrets avant de changer de fournisseur.
4. Décidez si la base doit migrer d’abord ou rester externe pendant la migration.
5. Testez build, health checks et domaines personnalisés sur un staging.
6. Gardez Heroku actif jusqu’à ce que logs et erreurs soient normaux ailleurs.

Quand rester sur Heroku

Restez sur Heroku si l’app est déjà critique, dépend fortement d’add-ons ou profite plus de la simplicité opérationnelle d’Heroku qu’elle ne souffre de son prix. Un dyno à 5 ou 7 dollars peut coûter moins cher que plusieurs heures à reconstruire une petite app autour de services gratuits. La meilleure alternative gratuite n’est meilleure que si elle conserve les parties du workflow Heroku dont votre app a réellement besoin.