La chronologie du PaaS auto-hébergé, et d'où vient vraiment l'idée

Chaque « alternative à Heroku » semble être une nouvelle idée jusqu’à ce qu’on regarde la vraie chronologie — la catégorie a été reconstruite par une nouvelle équipe à peu près toutes les quelques années depuis Heroku lui-même, et ce qui change constamment n’est pas la promesse de base (git push, obtenir une application qui tourne), c’est qui possède l’infrastructure en dessous.

L’ère du tout-géré

Heroku (2007) a défini la forme que tout le monde copie encore : buildpacks, dynos, add-ons, un git push qui devient un déploiement. Racheté par Salesforce en 2010, et pendant près d’une décennie « PaaS » signifiait essentiellement « Heroku, ou quelque chose qui essaie de l’être ». Le compromis a toujours été le même : une facilité extraordinaire, sur une infrastructure qu’on ne touche jamais et ne possède jamais.

Fly.io (2017) et Render (2018) ont tous les deux gardé ce modèle tout-géré mais ont attaqué des parties différentes du problème — Fly a construit autour de faire tourner des VM près des utilisateurs globalement plutôt que dans une seule région; Render s’est attaqué à la douleur précise des équipes qui perdent du vrai temps d’ingénierie dans la plomberie d’infrastructure plutôt que dans le produit. Aucun des deux n’a changé qui possède le serveur. Railway (fondée le 9 juin 2020 par Jake Cooper) a poussé le même modèle vers une énergie d’activation quasi nulle — le plus petit écart possible entre « j’ai du code » et « ça tourne ».

L’autre branche : ne jamais héberger l’application du client

Cloud 66, fondée en 2012, a fait un pari entièrement différent, des années avant que ce soit une tendance : un plan de contrôle au-dessus de serveurs que le client possède déjà, plutôt qu’une plateforme qui possède elle-même les serveurs. C’est le vrai point d’origine du modèle que suit Railyard — pas une idée récente, une idée de 2012 qui a mis longtemps à devenir évidemment correcte à mesure que les factures cloud augmentaient et que le verrouillage fournisseur devenait plus coûteux à ignorer.

Coolify a repris ce même fil « apportez votre serveur » du côté open source — première version le 24 mars 2021, et au printemps 2026, plus de 50 000 étoiles GitHub, rapportée comme le PaaS auto-hébergé le plus largement reconnu à ce jour. Gratuit, auto-hébergé, géré entièrement par vous, y compris le plan de contrôle lui-même.

Où ça laisse le vrai choix

Le vrai axe n’est pas « quelle plateforme a le plus de fonctionnalités » — toutes les plateformes de cette liste convergent éventuellement vers les buildpacks, les bases de données gérées et les déploiements sans interruption. L’axe qui est resté stable depuis plus d’une décennie est qui possède la machine : de Heroku à Railway, on vous loue toute la pile; de Cloud 66 à Railyard et Coolify, on vous donne un flux de travail au-dessus d’une infrastructure qui est la vôtre. À l’intérieur de ce second groupe, la question suivante est tout aussi ancienne — plan de contrôle géré que vous n’opérez pas (Cloud 66, Railyard) contre plan de contrôle auto-hébergé que vous gérez aussi vous-même (Coolify). Aucun n’est strictement meilleur; ce sont des réponses différentes à combien d’infrastructure vous voulez personnellement opérer, et c’est la vraie décision depuis 2012, pas une nouvelle.

Pourquoi la catégorie continue d’être reconstruite plutôt que de se consolider

Personne n’a gagné ça carrément parce que le compromis ne se résout jamais dans une seule direction — toutes les quelques années, une nouvelle équipe décide que le leader actuel a trop dérivé vers la complexité, le prix, ou le verrouillage, et construit une version plus simple de la même idée de base. Ce n’est pas un signe que le problème n’est pas résolu; c’est un signe que la vraie réponse est « ça dépend de combien d’infrastructure vous voulez posséder », ce qui n’a pas une seule réponse correcte qui rendrait le reste de la catégorie obsolète.

Voyez comment Railyard se compare précisément : Heroku, Railway, Render, Fly, Cloud 66.