La plateforme en tant que service se situe entre les serveurs bruts et les fonctions serverless : vous poussez du code, et la plateforme le construit, l’exécute, connecte une base de données et vous donne une URL — mais contrairement au serverless, votre application tourne comme un processus continu. Cela fait du PaaS le foyer naturel des applications full-stack, des API à connexions persistantes, des workers en arrière-plan et de tout ce qui repose sur un framework qui s’attend à rester en fonctionnement.
Le compromis déterminant des offres PaaS gratuites est la façon dont le fournisseur les maintient abordables. Certaines mettent votre application en veille après une période sans trafic et la réveillent à la requête suivante, échangeant un délai de démarrage à froid contre un hébergement gratuit toujours disponible ; d’autres vous donnent un crédit mensuel fixe qui s’épuise à mesure que l’application tourne. Railway et Render sont des choix courants, et le bon dépend de la tolérance de votre projet à la mise en veille et de la façon dont sa consommation de ressources correspond à l’allocation de chaque plateforme.
Pour comparer les options, vérifiez quatre choses : si l’offre gratuite est perpétuelle ou un essai qui s’épuise, la politique de veille/inactivité, quelles base de données et stockage persistant sont inclus, et les runtimes pris en charge (y compris la prise en charge des Dockerfile si vous en avez besoin). Un PaaS qui inclut un Postgres managé sur le même compte gratuit vous évite de câbler un fournisseur de base de données séparé, ce qui fait souvent la différence entre un déploiement de cinq minutes et un après-midi de configuration.