Classez le backend avant de choisir une plateforme :
- Web service classique : Express, FastAPI, Django, Rails ou Go sont plus simples sur Render ou des plateformes PaaS proches de Railway.
- API légère ou webhook : Cloudflare Workers est très adapté si le code peut tourner dans un runtime edge/serverless.
- Backend-as-a-service : Firebase est meilleur si vous voulez auth, base de données, hosting, stockage et fonctions sans gérer un process serveur.
- App conteneurisée : Fly.io donne plus de contrôle pour Docker, réseau privé et placement global, mais demande plus d’aisance opérationnelle.
La vraie décision est sommeil contre flexibilité runtime. Les plateformes qui lancent un process serveur normal économisent souvent en mettant les instances gratuites en veille. Les plateformes sans sommeil limitent plutôt le modèle runtime, la durée de requête, le CPU, la taille de bundle ou les APIs disponibles.
Recommandation pratique
Pour une première API backend, commencez avec Render si les cold starts sont acceptables. C’est direct, basé sur Git, et compatible avec beaucoup de langages backend sans réécriture serverless.
Pour un webhook, une petite API JSON, un callback d’auth, un proxy léger ou un backend edge-friendly, commencez avec Cloudflare Workers ou Pages Functions. Vous évitez le problème classique du serveur qui dort, mais vous devez concevoir autour des limites Workers.
Pour les apps mobiles, prototypes realtime et produits où l’authentification compte plus que du code serveur custom, commencez avec Firebase. Ce n’est pas “héberger un serveur backend” au sens ancien, mais cela peut supprimer le besoin d’en avoir un.
Utilisez Railway ou Fly.io quand l’expérience développeur ou le modèle conteneur justifie d’accepter un accès actuel plutôt orienté essai ou usage-based.
Pièges de l’offre gratuite
L’hébergement backend gratuit casse souvent sur l’un de ces points :
- mise en veille et cold starts
- heures d’instance ou crédits mensuels
- CPU par requête
- mémoire et taille de bundle
- stockage base de données et sauvegardes
- support des workers en arrière-plan
- comportement WebSocket
- trafic sortant ou appels API externes
- expiration d’essai
- absence de garantie d’uptime production
Si votre backend sert un vrai produit public, stocke des données utilisateur ou touche des clients payants, choisissez le chemin payant avant le lancement. L’hébergement backend gratuit est excellent pour apprendre, prototyper, démontrer et lancer des side projects peu fréquentés, mais les premiers vrais utilisateurs révèlent souvent très vite la limite cachée.