Cold starts de 50 secondes — alternatives à Render pour les builders qui en ont marre

Pourquoi on cherche des alternatives à Render

Render a fait un truc important en arrivant sur le marché. Il a offert aux indie builders une expérience type Heroku avec un plan gratuit qui marchait vraiment — à un moment où Heroku venait de supprimer le sien. Pour les fondateurs bootstrapés qui devaient shipper un MVP sans dépenser un centime en hosting, Render était le choix évident.

Et puis on se prend les murs.

Les cold starts tuent l'expérience utilisateur. Le plan gratuit de Render met en veille les services web après 15 minutes d'inactivité. La première requête après la mise en veille prend 30 à 60 secondes. Ce n'est pas une exagération. Presque une minute pour charger une page. Pour un projet perso qu'on consulte de temps en temps, c'est tolérable. Pour un produit qu'on montre à des clients potentiels ou des investisseurs, c'est un tueur de taux de conversion. Les utilisateurs n'attendent pas une minute entière — ils ferment l'onglet.

La falaise Postgres à 90 jours. Render propose une base Postgres gratuite, ce qui semble généreux jusqu'à ce qu'on lise les petits caractères : elle expire après 90 jours. Votre base, avec toutes vos données, doit être migrée vers une nouvelle instance gratuite (manuellement, avec pg_dump et pg_restore) ou upgradée vers un plan payant à 7 $/mois. Tous les 90 jours, on se retrouve face à ce dilemme. Pour un prototype avec des données jetables, ça passe. Pour une app avec de vrais utilisateurs, c'est une bombe à retardement qu'il faut penser à désamorcer.

Les builds sont d'une lenteur pénible. Une application Node.js classique avec un arbre de dépendances moyen prend 3 à 6 minutes à build sur Render. La même app se build en 60-90 secondes sur Railway. Quand on itère vite — 5-10 push par jour en développement actif — ces minutes supplémentaires par deploy s'accumulent en temps réellement perdu. La vitesse de build impacte directement le time to value de chaque feature shippée.

Les prix s'accumulent dès qu'on passe au payant. Une fois sorti du plan gratuit, Render facture 7 $/mois par service web. Ça semble raisonnable pour un seul service. Mais un stack SaaS typique — un serveur web, un worker, Postgres et Redis — revient à 28 $/mois. On ajoute un environnement de staging et on est à 56 $/mois. Pour un produit pré-revenu, ce burn rate pèse quand des alternatives existent à moitié prix.

Rien de tout ça ne fait de Render un mauvais produit. C'est une plateforme compétente avec une infrastructure solide. Mais la concurrence s'est suffisamment améliorée pour qu'on regarde ce qui se fait ailleurs.

Comment on a évalué ces alternatives

On s'est concentré sur ce qui compte pour un fondateur solo qui shippe un vrai produit — pas pour un ingénieur plateforme dans une startup Series C :

• Comportement des cold starts : Est-ce que le plan gratuit met en veille ? En combien de temps ça redémarre ?
• Vitesse de build : Temps entre le git push et le déploiement en production
• L'expérience base de données : Postgres intégré ? Limites de temps ? Tarification ?
• Coût d'un stack typique : Service web + Postgres + Redis + worker
• Expérience développeur : Qualité du dashboard, accès aux logs, gestion des variables d'environnement
• Porte de sortie : Est-ce que c'est galère de partir si besoin ?

On a priorisé le profil indie builder : shipper vite, garder des coûts prévisibles et éviter une infrastructure qui nécessite un DevOps dédié.

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

Railway — le Render en plus rapide

Railway, c'est ce que serait Render si chaque aspérité était polie. L'expérience de déploiement est quasi identique — on connecte un repo GitHub, Railway détecte automatiquement le framework, build l'app et la déploie. Sauf que tout va plus vite.

Des builds qui prennent 4-5 minutes sur Render se terminent en 60-90 secondes sur Railway. Pour un indie founder qui push du code plusieurs fois par jour, c'est la différence entre rester en flow et décrocher le temps que ça compile. Railway utilise Nixpacks pour les builds, qui cache agressivement les layers et parallélise les étapes.

L'expérience base de données est là où Railway met Render dans l'embarras. Un clic pour provisionner Postgres, MySQL, Redis ou MongoDB. La connection string est automatiquement injectée en variable d'environnement. Pas d'expiration à 90 jours. Pas de dashboard séparé pour la base. Ça marche, et ça continue de marcher.

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 un workflow qui attrape les bugs avant la production, et Railway le rend trivial. Render propose des preview environments aussi, mais l'implémentation est moins aboutie.

Le plan Hobby à 5 $/mois inclut 5 $ de crédits d'usage. Une petite app avec un service web et une base Postgres coûte typiquement 3-8 $/mois en ressources. Les 5 $ de crédit couvrent donc souvent la totalité de la facture. Par contre, il n'y a pas de vrai plan gratuit — le minimum de 5 $/mois s'applique même si l'usage réel est de zéro.

La tarification à l'usage est le compromis qu'on accepte. On paie pour le compute, la mémoire, la bande passante et le stockage en fonction de la consommation réelle. Pour du trafic prévisible, c'est bon marché. Pour un jour de lancement sur Product Hunt où le trafic fait x10, la facture peut surprendre. Les alertes de facturation, on les configure dès le premier jour.

Quand choisir Railway : On veut tout ce que Render fait, mais en plus rapide et avec de meilleures bases de données. Le minimum de 5 $/mois en vaut la peine pour tout projet sérieux.

Fly.io — la fin des cold starts

Si les cold starts de Render sont la plainte principale, l'API Machines de Fly.io est le remède. Au lieu des 30-60 secondes de redémarrage après mise en veille de Render, les machines Fly.io reviennent de zéro en 1-3 secondes. C'est assez rapide pour que la plupart des utilisateurs ne remarquent rien.

Fly.io adopte une architecture fondamentalement différente. Au lieu de faire tourner l'app dans un seul data center, il déploie les conteneurs dans des points de présence dans 30+ régions. L'API répond depuis le data center le plus proche de chaque utilisateur. Pour un SaaS avec des utilisateurs à New York et à Berlin, ça veut dire une latence basse pour tout le monde sans gérer un déploiement multi-régions soi-même.

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, et les machines restent réactives grâce aux temps de redémarrage rapides. Postgres est disponible avec read replicas, et Fly.io propose LiteFS pour du SQLite distribué — une option étonnamment convaincante pour les applications à lecture intensive.

La courbe d'apprentissage est plus raide que Render. Le déploiement passe par un outil CLI (flyctl) et un fichier de configuration fly.toml. Les concepts — machines, volumes, régions, secrets — demandent plus d'investissement initial que le déploiement via dashboard de Render. Si on arrive de Render en s'attendant à cliquer trois boutons et avoir fini, il faut prévoir une heure ou deux de plus pour le setup initial.

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 plusieurs dimensions tarifaires. C'est moins intuitif que le tarif fixe par service de Render.

Quand choisir Fly.io : Les utilisateurs sont répartis dans le monde, les cold starts sont inacceptables, ou on veut du vrai scale-to-zero qui donne l'impression d'être instantané.

Vercel — quand l'app est surtout du frontend

Render essaie de tout faire — sites statiques, services web, bases de données, cron jobs. Vercel fait une chose mieux que quiconque : déployer des frameworks frontend. Si l'app est un site Next.js, un blog Astro, une application Nuxt ou un projet SvelteKit, l'expérience de déploiement de Vercel est inégalée.

Un push sur GitHub et le site est en ligne en quelques secondes, distribué sur un CDN mondial avec edge middleware, optimisation d'images automatique et ISR (Incremental Static Regeneration). La performance obtenue out of the box demanderait un travail d'infrastructure conséquent à reproduire sur Render.

Les fonctions serverless gèrent les routes API sans provisionner un service web séparé. Pour un SaaS qui est principalement une application web avec quelques endpoints API (callbacks d'auth, webhooks, data fetching), ce modèle élimine le besoin d'un service backend dédié. C'est un service en moins sur la facture Render.

Les preview deployments sur chaque git push avec des URLs partageables uniques sont la norme sur Vercel. On partage un lien avec un beta testeur ou un client, et il voit exactement à quoi ressemblera le prochain deploy. Ce workflow est plus fluide que l'équivalent Render.

La limite est claire : Vercel n'est pas fait pour les process backend longs. Les timeouts de fonctions serverless (10 secondes sur le gratuit, 60 secondes sur Pro) empêchent de lancer du traitement de données lourd, des appels API longs ou des jobs en arrière-plan. Il faut un service séparé — Railway, Fly.io ou un VPS — pour ce travail backend. Vercel n'a pas non plus de base de données intégrée, donc on le couple avec quelque chose comme Supabase, Neon ou PlanetScale.

Quand choisir Vercel : L'app est frontend-heavy, construite sur un framework moderne, et les besoins backend sont modestes. Vercel plus une base de données managée remplace Render pour beaucoup de projets indie.

Coolify — l'évasion de la tarification par service

Chaque reproche fait à Render — cold starts, expiration de la base, vitesse de build, coûts par service — disparaît quand on auto-héberge. Coolify est le moyen le plus simple de le faire.

On installe Coolify sur un VPS à 5-10 $/mois chez Hetzner ou DigitalOcean, et on obtient un dashboard web avec git push deploy, SSL automatique via Let's Encrypt, provisionnement de bases de données en un clic et support des builds Docker et Nixpacks. Ça ressemble à un PaaS. Ça coûte le prix d'un VPS.

C'est le calcul qui convainc. Un seul CPX21 Hetzner à 10 $/mois (3 vCPU, 4 Go de RAM) peut héberger 5-10 petites applications web, plusieurs instances Postgres et Redis, et des workers en arrière-plan. La même charge sur Render coûte 7 $ par service par mois — facilement 50-70 $/mois. Sur Coolify, c'est un forfait de 10 $/mois pour tout.

Pas de cold starts parce que le serveur tourne 24/7. Pas d'expiration de base à 90 jours parce qu'on possède la base. Les builds tournent sur notre hardware à la vitesse que le VPS fournit, et on peut ajuster les ressources de build.

Les compromis sont ceux de l'auto-hébergement. On est responsable des mises à jour OS, des correctifs de sécurité, du monitoring du disque et des sauvegardes. Si le serveur tombe à 3h du matin, personne n'est alerté sauf si on a configuré le monitoring soi-même. Pas de CDN mondial sauf si on met Cloudflare devant. Coolify gère la couche applicative, mais la couche infrastructure, c'est sur nous.

Pour un fondateur technique qui connaît son terminal Linux, Coolify est l'option avec le meilleur rapport qualité-prix de cette liste. On économise immédiatement et on possède tout. Pour quelqu'un qui ne veut pas penser aux serveurs du tout, on reste sur Railway ou Fly.io.

Quand choisir Coolify : On veut éliminer toutes les limites de Render à une fraction du prix, et on est à l'aise avec la maintenance d'un serveur Linux.

DigitalOcean App Platform — le choix fiable et sans surprises

DigitalOcean App Platform est l'offre PaaS de l'un des noms les plus reconnus de l'infrastructure pour développeurs indie. Si on a déjà des Droplets, des bases managées ou des Spaces sur DigitalOcean, App Platform s'intègre naturellement dans cet écosystème.

L'expérience de déploiement est compétente. On connecte un repo GitHub, on configure les variables d'environnement, on déploie. La détection automatique gère les frameworks courants. Le dashboard montre les logs, les métriques et l'historique des déploiements. Rien de surprenant, rien de cassé.

Le plan gratuit couvre 3 sites statiques avec 1 Go de bande passante — plus limité que l'hébergement statique de Render, mais fonctionnel pour une landing page ou un site de documentation. Les services compute démarrent à 5 $/mois par conteneur, soit légèrement moins que les 7 $/mois de Render.

Là où App Platform brille, c'est l'intégration écosystème. Le réseau privé entre l'app et une base managée DO se configure en un clic. La connexion à Spaces (stockage S3-compatible) pour l'upload de fichiers est directe. Si le MVP tourne déjà sur l'infrastructure DigitalOcean, ajouter App Platform garde tout au même endroit avec une seule facture.

La tarification par conteneur suit le même modèle fondamental que Render, et ça s'accumule pareillement. Un service web (5 $) plus un worker (5 $) plus une base Postgres managée (7 $) et on est déjà à 17 $/mois avant d'ajouter Redis ou un environnement de staging.

Quand choisir DigitalOcean App Platform : On est déjà sur DigitalOcean et on veut un PaaS managé qui s'intègre avec l'infrastructure existante. La migration depuis Render est directe.

Koyeb — le plan gratuit sans mise en veille

Koyeb est la plateforme la moins connue de cette liste, mais elle résout l'un des plus gros irritants de Render : les cold starts du plan gratuit. Les services du plan gratuit Koyeb restent actifs. Pas de mise en veille. Pas de 50 secondes de réveil. L'app est juste là quand quelqu'un la visite.

Le plan gratuit offre 2 instances nano avec 256 Mo de RAM chacune. C'est suffisant pour une petite API, un handler de webhook ou une app web légère. Le déploiement global est inclus — l'app tourne dans la région la plus proche des utilisateurs, pas juste dans un seul data center US.

L'autoscaling fonctionne de zéro à plusieurs instances selon le trafic. Quand l'app est mentionnée quelque part et que le trafic explose, Koyeb scale up. Quand le trafic baisse, ça redescend. Les cold starts en moins d'une seconde font que le scaling paraît transparent plutôt que saccadé.

Les limites sont réelles. Pas de bases de données intégrées — il faut un provider externe comme Neon (plan gratuit Postgres), Supabase ou PlanetScale. La communauté est plus petite que Railway, Render ou Fly.io, ce qui veut dire moins de tutos, de réponses Stack Overflow et d'articles de blog pour aider quand on bloque. Les instances nano du plan gratuit (256 Mo de RAM) sont justes pour les frameworks plus lourds comme Next.js en mode SSR complet.

Les plans payants démarrent à 5.50 $/mois pour plus de ressources. Le plan Starter offre des instances plus grosses et plus de flexibilité, mais à ce prix on est en concurrence directe avec le plan Hobby de Railway qui inclut des bases de données.

Quand choisir Koyeb : On veut un plan gratuit qui marche vraiment sans cold starts. On le couple avec une base gratuite Neon ou Supabase et on a un stack à zéro euro qui répond instantanément.

Comparatif de coût pour un stack indie typique

Voici ce qu'un MVP SaaS standard coûte sur chaque plateforme. Le stack : un service web, une base Postgres, une instance Redis, un worker en arrière-plan.

• Render : 7 $ (web) + 7 $ (Postgres) + 7 $ (Redis) + 7 $ (worker) = 28 $/mois
• Railway : Facturation à l'usage, typiquement 8-15 $/mois pour cette charge
• Fly.io : Facturation à l'usage multi-régions, typiquement 10-18 $/mois
• Vercel + Neon + Upstash : 0-20 $ (Vercel) + 0-19 $ (Neon Postgres) + 0-10 $ (Upstash Redis) = 0-49 $/mois selon l'usage
• Coolify sur Hetzner : 5-10 $/mois (coût VPS, tous services inclus)
• DigitalOcean App Platform : 5 $ (web) + 7 $ (BD) + 5 $ (Redis) + 5 $ (worker) = 22 $/mois
• Koyeb + Neon : 0-5.50 $ (Koyeb) + 0-19 $ (Neon) = 0-24.50 $/mois

L'option auto-hébergée (Coolify) est la moins chère pour les déploiements multi-services parce qu'on paie le serveur, pas par service. Parmi les plateformes managées, Railway gagne sur le coût total pour un stack standard. Render finit par être l'une des options les plus chères à 28 $/mois pour une configuration que Railway gère pour moitié moins.

Le choix dépend de ce qu'on valorise. Le temps ? On prend Railway ou Render — zéro réflexion infrastructure. L'argent ? Coolify sur un VPS coûte 3 à 5 fois moins. La portée mondiale ? Fly.io ou Koyeb. La performance frontend ? Vercel plus une base séparée.

Quand rester sur Render

Render reste pertinent dans des situations spécifiques :

• On a besoin d'un hébergement statique vraiment gratuit. L'hébergement statique gratuit de Render avec 100 Go de bande passante par mois est généreux. Le plan gratuit de Vercel est comparable, mais si on est déjà sur Render, il n'y a pas de raison de déplacer les sites statiques.
• Le projet est à faible trafic et les cold starts ne gênent pas. Pour un outil interne, un projet perso ou un environnement de staging que seule l'équipe utilise, la mise en veille du plan gratuit n'est pas un problème.
• On utilise les Render Blueprints pour l'infrastructure-as-code. Le fichier de configuration render.yaml pour définir des déploiements multi-services est une feature solide que certains concurrents n'ont pas.
• L'équipe est peu technique. Le dashboard de Render est parmi les plus accessibles. Celui de Railway est sans doute meilleur, mais Render est plus simple pour quelqu'un qui n'a jamais déployé un service web.
• Le coût de migration dépasse les économies. Si on a 5 services sur Render avec des pipelines CI/CD établis et une facture de 50 $/mois, passer 8 heures à migrer pour économiser 15 $/mois donne un retour sur investissement de plus de deux ans. On s'assure que le changement vaut le temps d'ingénierie.

Render n'est pas une mauvaise plateforme. C'est une bonne plateforme dans une catégorie où plusieurs concurrents sont maintenant excellents.

Conseils de migration : quitter Render

1. Commencez par un service non critique. Déployez un side project ou un environnement de staging sur la nouvelle plateforme d'abord. On se familiarise avec le pipeline de déploiement, les logs et le monitoring avant de toucher la production.

2. Exportez vos données Postgres tôt. Utilisez pg_dump pour créer un backup de la base Render. Testez pg_restore sur la plateforme cible avec une copie des données. Vérifiez que les index, contraintes et extensions sont intacts. On fait ça bien avant que le compteur de 90 jours n'arrive à terme si on est sur le plan gratuit.

3. Documentez vos variables d'environnement. Listez chaque variable, son rôle et d'où vient la valeur. Les incohérences de variables d'environnement sont la cause la plus fréquente de bugs post-migration. Railway et Fly.io supportent tous les deux l'import en masse depuis des fichiers .env.

4. Mettez en place le monitoring d'uptime avant le basculement. Déployez Uptime Robot, Better Uptime ou Uptime Kuma pour surveiller le nouveau déploiement avant d'y envoyer du vrai trafic. Les pannes silencieuses pendant une migration sont le pire type d'incident — personne ne s'en rend compte jusqu'à ce qu'un utilisateur se plaigne.

5. Utilisez le DNS pour un basculement sans downtime. Pointez votre domaine vers la nouvelle plateforme via DNS. Gardez Render actif en parallèle pendant 48-72 heures. Réglez le TTL DNS à 300 secondes pour qu'un rollback prenne 5 minutes au lieu de plusieurs heures. Une fois confiant, on décommissionne les services Render.

6. Surveillez la première facture de près. Les plateformes à tarification à l'usage comme Railway et Fly.io peuvent surprendre si les patterns de trafic diffèrent de ce qu'on attendait. On configure les alertes de facturation sur la nouvelle plateforme avant de migrer le trafic de production.