Render vs Fly.io : hosting simple ou terrain de jeu infra ?

Deux reponses a la meme question

Render et Fly.io repondent tous les deux a "ou est-ce que je deploy mon app ?". Mais ils repondent pour des profils differents.

Render est le successeur spirituel de Heroku. C'est le PaaS ou on veut que l'hebergement soit un probleme resolu. On deploy, ca marche, on passe a autre chose. Le pricing est clair, l'interface est propre, les services geres font le job.

Fly.io est un terrain d'experimentation infra deguise en PaaS. C'est la plateforme pour les devs qui aiment savoir ou tournent leurs machines, comment le trafic est route, et qui veulent placer des instances a Paris, Tokyo et Sao Paulo sans monter leur propre infra.

La question de fond : est-ce que l'hebergement doit etre invisible (Render), ou est-ce que c'est un levier produit (Fly.io) ?

Render : l'hebergement qui se fait oublier

La promesse de Render, c'est la previsibilite. Et il la tient.

Le deploy est un non-evenement. On connecte un repo GitHub, on configure quelques variables d'environnement, on clique Deploy. Pour un projet Node.js, Python, Ruby, Go ou un Dockerfile, Render detecte le runtime et configure le build automatiquement. En quelques minutes, l'app est en ligne.

Le dashboard est minimaliste et efficace. Pas de graphe de services complexe, pas de visualisation d'infra sophistiquee. Juste une liste de services, des logs, des metriques basiques, et des boutons pour ce dont on a besoin. C'est reposant.

Les types de services couvrent les cas courants. Web services, workers background, cron jobs, sites statiques, bases de donnees Postgres, Redis. On ne va pas orchestrer du Kubernetes, mais pour un SaaS standard, tout est la.

Le Postgres gere est solide. Backups automatiques, connection pooling, metriques. On ne gere pas l'infra de la base. On l'utilise. C'est ce qu'on attend d'un service gere.

Le pricing est lisible. Un web service demarre a 7$/mois. Un Postgres a partir de 7$/mois. Les sites statiques sont gratuits. On comprend la facture sans calculatrice. Pas de surprises en fin de mois.

Les preview environments existent. Comme Railway, Render permet de deployer automatiquement chaque pull request dans un environnement isole. Pratique pour la review avant merge.

Le compromis : Render est geographiquement limite. L'app tourne dans une region (US Oregon ou Frankfurt, principalement). Il n'y a pas de placement multi-region natif pour les services dynamiques. Le CDN couvre les sites statiques, mais pour un backend ou une API, c'est mono-region.

Fly.io : le PaaS pour les architectes distribuees

Fly.io part d'un postulat que Render ignore : la latence depend de la geographie.

Le multi-region est le produit. Fly.io ne propose pas le multi-region comme une feature premium. C'est le coeur de l'offre. Chaque app peut tourner dans une ou plusieurs des 30+ regions disponibles. Le routing anycast envoie chaque utilisateur vers l'instance la plus proche.

Les micro-VMs Firecracker sont rapides. Au lieu de conteneurs Docker traditionnels, Fly.io fait tourner des micro-VMs Firecracker. Le cold start est rapide, l'isolation est forte, et le modele est plus proche du bare metal que du PaaS classique.

Le controle est granulaire. On choisit la taille des machines (CPU, RAM), le nombre d'instances par region, les volumes persistants, la configuration reseau. C'est du controle direct, pas de l'abstraction.

Le CLI flyctl est l'interface principale. fly launch, fly deploy, fly scale count 3 --region cdg,iad,nrt, fly ssh console. Pour les devs qui vivent dans le terminal, c'est naturel. Pour les autres, c'est une courbe d'apprentissage.

Le reseau prive WireGuard. Les machines Fly.io se parlent via un reseau prive automatique. Ca simplifie les architectures distribuees ou plusieurs services doivent communiquer entre eux sans exposer de ports publics.

Le compromis : la complexite operationnelle est reelle. Fly Postgres demande plus d'attention que le Postgres gere de Render. Le scaling n'est pas automatique par defaut -- on gere le nombre de machines manuellement. Et la facture peut surprendre si on oublie des machines actives dans des regions inutilisees.

L'experience du premier deploy

C'est la que la difference de philosophie se ressent le plus.

Sur Render : on va sur le dashboard, on connecte son repo Git, Render detecte le langage et propose des settings de build. On ajuste si besoin, on clique "Create Web Service". Trois minutes plus tard, l'app est en ligne avec une URL en .onrender.com. Temps total : cinq minutes.

Sur Fly.io : on installe flyctl, on se connecte, on lance fly launch dans le repertoire du projet. Le CLI pose des questions : quelle region ? Quelle taille de machine ? Besoin d'un Postgres ? Un fichier fly.toml est genere. On lance fly deploy. L'app build, se deploie, et est accessible. Temps total : dix a quinze minutes si c'est la premiere fois.

Ce n'est pas que Fly.io est lent. C'est qu'il demande plus de decisions upfront. Des decisions qui ont de la valeur si on sait pourquoi on les prend, mais qui sont du bruit si on veut juste deploy rapidement.

Pricing : previsible vs optimisable

Render a un pricing lineaire. Un web service Starter coute 7$/mois. Un Standard coute 25$/mois. Un Postgres Starter coute 7$/mois. On additionne les services, on a la facture. Simple.

Fly.io a un pricing a la consommation. On paie les machines (taille x duree d'execution), le stockage (volumes persistants), la bande passante sortante. Le tier gratuit inclut quelques petites machines. Mais la facture depend de combien de machines tournent, dans combien de regions, pendant combien de temps.

Pour un projet simple (un web service + un Postgres), Render est generalement moins cher et toujours plus previsible. On sait ce qu'on va payer avant de deploy.

Pour un projet distribue dans plusieurs regions, Fly.io peut etre plus economique parce qu'on controle precisement les ressources. Mais il faut monitorer sa consommation activement.

Le piege Fly.io classique : lancer des machines de test dans plusieurs regions pour experimenter, oublier de les arreter, et se retrouver avec une facture qui ne correspond a rien de productif.

Base de donnees : gere vs DIY assiste

C'est un point de decision majeur pour beaucoup de devs.

Render Postgres est un vrai service gere. Backups quotidiens automatiques, point-in-time recovery, metriques dans le dashboard, connection pooling integre. On ne pense pas a l'infra de la base. On se connecte et on utilise.

Fly Postgres est une app Fly qui fait tourner Postgres. Techniquement, c'est une machine Fly avec un volume persistant et des scripts de gestion. Les backups existent mais demandent plus de configuration. Le failover est possible mais pas transparent. Les mises a jour de version sont manuelles.

Si ta base de donnees est au coeur de ton app (et c'est presque toujours le cas), le Postgres gere de Render offre une tranquillite d'esprit que Fly Postgres n'a pas encore atteint. C'est un facteur concret dans la decision.

Sites statiques et CDN

Un domaine ou Render a un avantage clair : les sites statiques.

Render heberge les sites statiques gratuitement avec un CDN global. Pour un site Astro, un blog Hugo, ou une SPA Vite, c'est deploy gratuit avec des performances correctes. Le build automatique depuis Git fonctionne bien.

Fly.io n'a pas d'offre specifique pour les sites statiques. On peut deployer un serveur statique dans un conteneur, mais ca revient a utiliser une machine Fly pour servir des fichiers -- ce qui est overkill et moins economique.

Pour les projets qui combinent un site statique et un backend, Render permet d'heberger les deux sur la meme plateforme sans friction.

Quand choisir Render

• Tu veux un PaaS simple, fiable, sans surprises
• Le pricing previsible est important pour toi
• Tu n'as pas de contraintes de latence multi-region
• Tu as besoin d'un Postgres gere sans te soucier des backups et du failover
• Tu heberges des sites statiques en plus de services dynamiques
• Tu veux une alternative a Heroku avec une meilleure DX et un meilleur prix
• Tu es en phase de lancement et tu veux minimiser le temps passe sur l'ops

Quand choisir Fly.io

• Tes utilisateurs sont repartis sur plusieurs continents et la latence est un enjeu
• Tu veux choisir exactement dans quelles regions tes instances tournent
• Tu es a l'aise avec le CLI et la gestion directe de machines virtuelles
• Tu construis une architecture distribuee avec des caches ou replicas regionaux
• Tu veux le controle fin sur les ressources CPU, memoire et reseau
• Le placement geographique est un avantage produit pour ton app

Verdict

Render est le choix par defaut. Pour la majorite des projets -- SaaS, APIs, sites web, outils internes -- Render fait le job sans friction. On deploy, on paie ce qu'on comprend, et on se concentre sur le produit.

Fly.io est le choix delibere. On le choisit quand la geographie compte, quand on veut que l'app tourne a Paris pour les utilisateurs francais et a Tokyo pour les utilisateurs japonais, quand la latence est une feature produit.

Si tu n'as pas de raison specifique de choisir Fly.io, Render est probablement le bon choix. Et si tu as cette raison -- utilisateurs multi-continents, contraintes de latence strictes, besoin d'architectures distribuees -- Fly.io offre un niveau de controle que Render ne pretend meme pas avoir.