Alternatives à Fly.io pour ceux qui ne veulent pas debug des VMs Firecracker à 2h du mat

Pourquoi les fondateurs cherchent des alternatives à Fly.io

Le pitch de Fly.io est séduisant : on deploy son app dans 30+ régions mondiales, et les utilisateurs reçoivent les réponses depuis le data center le plus proche. Pour un produit distribué mondialement où la latence compte — outils de collaboration temps réel, backends de jeu, APIs edge — c'est un vrai avantage. L'API Machines, les VMs Firecracker et le scale-to-zero sont techniquement impressionnants.

Les problèmes apparaissent quand on essaie de l'utiliser en tant que fondateur solo qui shippe un produit SaaS.

La taxe de complexité est bien réelle. Déployer sur Fly.io implique d'apprendre flyctl, d'écrire des fichiers de configuration fly.toml, de comprendre la différence entre Fly Machines et Fly Apps v2, de gérer les volumes pour le stockage persistant et de configurer WireGuard pour le réseau interne. Sur Railway, on connecte un repo GitHub et on clique sur deploy. L'écart en time-to-first-deploy se mesure en heures, pas en minutes.

Le debug est pénible. Quand quelque chose plante sur Fly.io — et ça arrivera — l'expérience de debug est rude. Les logs passent par la CLI ou le dashboard de monitoring basé sur Grafana, qui demande une configuration supplémentaire. Le SSH sur une machine en cours d'exécution fonctionne, mais on se retrouve à troubleshooter un serveur distant, pas un PaaS moderne. Sur Railway ou Render, on ouvre le dashboard et on lit les logs en temps réel sans rien configurer.

La tarification est un casse-tête. Fly.io facture le temps CPU, la mémoire, les volumes persistants, la bande passante sortante et les adresses IPv4 — chacun avec son propre tarif et son palier gratuit. Une petite app peut coûter 3 $/mois ou 15 $/mois selon le nombre de machines, le comportement au repos et les patterns de trafic. On ne connaît souvent le vrai coût qu'après le premier cycle complet de facturation. Pour un fondateur bootstrapé qui surveille son burn rate, cette incertitude est inconfortable.

La plupart des apps indie n'ont pas besoin du multi-régions. Si les utilisateurs sont principalement en Amérique du Nord ou en Europe et que l'app est un SaaS classique avec une base de données, un serveur web et peut-être un worker en arrière-plan, on ne tire aucun bénéfice de 30+ régions mondiales. Un déploiement mono-région sur Railway ou un VPS Hetzner offre les mêmes performances pratiques avec une fraction de la complexité.

Ce ne sont pas des raisons pour dire que Fly.io est mauvais. C'est une plateforme puissante qui résout de vrais problèmes. Mais elle résout des problèmes que la majorité des fondateurs solo n'ont pas, et la complexité se paie quand même.

Comment on a évalué ces alternatives

On s'est concentré sur ce qui compte pour un indie founder qui deploy une app web classique — une API Node.js ou Python, une base Postgres, peut-être Redis et un worker en arrière-plan :

• Time to first deploy : Combien de temps entre "j'ai créé un compte" et "mon app est live avec une URL" ?
• Expérience de debug : Quand quelque chose casse, à quelle vitesse on comprend pourquoi ?
• Prévisibilité des coûts : Est-ce qu'on peut estimer sa facture mensuelle à 5 $ près avant qu'elle n'arrive ?
• Charge opérationnelle : Combien d'heures par mois la plateforme exige en maintenance ?
• Capacité de croissance : Que se passe-t-il quand le trafic fait x10 ? Les prix scalent linéairement ou exponentiellement ?

On a volontairement mis de côté le déploiement multi-régions et les fonctionnalités d'edge computing parce que ce sont les points forts de Fly.io. L'objectif est de trouver des alternatives qui échangent ces capacités contre de la simplicité et des économies.

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

Railway — le champion de la simplicité

Railway, c'est ce dont la plupart des fondateurs solo ont réellement besoin : on connecte un repo GitHub, on obtient un deploy. La détection automatique gère Node.js, Python, Go, Ruby, Rust et tout ce qui a un Dockerfile. Le build se termine typiquement en 60-90 secondes. L'app est live avec une URL, du SSL et la gestion des variables d'environnement out of the box.

Là où Railway brille par rapport à Fly.io, c'est sur la charge opérationnelle — ou plutôt, l'absence de charge opérationnelle. Pas de CLI à apprendre, pas de fichier de config à écrire (sauf si on le veut), pas de gestion de VMs. Le dashboard affiche logs, métriques, déploiements et variables d'environnement au même endroit. Quand l'app crash, on ouvre le dashboard et on lit l'erreur. Pas de SSH, pas de flyctl logs, pas de setup Grafana.

Le provisionnement de bases intégrées est l'autre gros avantage. Un clic, une instance Postgres avec la connection string automatiquement injectée dans l'environnement de l'app. Pareil pour MySQL, Redis et MongoDB. Sur Fly.io, mettre en place Postgres implique fly postgres create, de la gestion de volumes et la compréhension de la configuration de clustering. Sur Railway, ça prend 30 secondes.

Le plan Hobby coûte 5 $/mois et inclut 5 $ de crédits d'usage. Un petit SaaS (un service web, Postgres, peu de trafic) consomme typiquement 5-10 $/mois en usage, ce qui signifie que les crédits inclus couvrent la plupart ou la totalité d'une app à faible trafic. Le plan Pro à 20 $/mois par siège supprime les limites de ressources et ajoute les fonctionnalités d'équipe.

Le compromis, c'est la géographie. Railway sert principalement depuis une infrastructure US avec des options régionales limitées. Si les utilisateurs sont dispersés dans le monde et qu'on a besoin de temps de réponse sous les 100 ms à Singapour et Sao Paulo, Railway ne peut pas rivaliser avec le déploiement multi-régions de Fly.io. Pour la majorité des produits SaaS indie qui ciblent un seul marché, ça ne compte pas.

Quand choisir Railway : On veut l'expérience de deploy la plus fluide possible, des coûts prévisibles, et on accepte de sacrifier le déploiement edge mondial pour la simplicité. Idéal pour les MVP SaaS et les produits early-stage.

Render — le plan gratuit qui marche vraiment

Render occupe un sweet spot entre le polish de Railway et les capacités infra de Fly.io. Le plan gratuit est réellement utile : hébergement de sites statiques avec 100 Go de bande passante par mois, et des services web avec 750 heures de compute par mois. Pour un environnement de staging, une app de démo ou un side project à faible trafic, c'est du vrai hébergement gratuit.

Le piège des services web gratuits, c'est la mise en veille. Après 15 minutes sans requête, le service s'endort. La première requête après le sommeil déclenche un cold start qui prend 30 à 60 secondes. C'est rédhibitoire pour une app de production face aux utilisateurs — personne n'attend une minute qu'une page charge. Mais pour un environnement de staging que l'équipe consulte quelques fois par jour, ou une démo qu'on partage avec des prospects, ça fait le job.

Le plan Individual payant à 7 $/mois par service supprime la mise en veille et donne une instance dédiée. La tarification est transparente : on sait ce qu'on paie, et pas de surprises de bande passante aux niveaux de trafic d'une app indie classique.

Le Postgres managé a un point d'attention : la base gratuite expire après 90 jours. On migre vers une nouvelle instance gratuite (fastidieux) ou on passe au plan payant à 7 $/mois. C'est clairement documenté, mais ça surprend quand même en plein projet.

Comparé à Fly.io, l'attrait de Render c'est la simplicité. Le dashboard montre tout. Les deploys sont automatiques depuis Git. Les logs sont là. Pas besoin d'apprendre une CLI ni d'écrire des fichiers de configuration. Le compromis, c'est la vitesse de build — les builds Render sont sensiblement plus lents que Fly.io et Railway, les gros projets prenant parfois 5+ minutes.

Quand choisir Render : On a besoin d'un vrai plan gratuit pour les side projects ou le staging, ou on veut une tarification par service simple sans la complexité de la facturation à l'usage.

Coolify — possédez tout votre stack

Coolify, c'est la réponse auto-hébergée. On l'installe sur n'importe quel VPS — Hetzner, DigitalOcean, Vultr — et on obtient un dashboard web pour déployer des applications depuis des repos Git, provisionner des bases de données, gérer les certificats SSL et monitorer les services. L'expérience utilisateur est étonnamment proche de Railway pour un outil auto-hébergé.

C'est sur le plan économique que Coolify gagne haut la main. Un CX22 Hetzner (2 vCPU, 4 Go de RAM) coûte environ 4 $/mois. On installe Coolify et on peut faire tourner 5-8 petites applications web, quelques instances Postgres, Redis et des workers en arrière-plan — le tout pour ce forfait de 4 $/mois. La même charge de travail sur Railway revient à 30-60 $/mois. Sur Fly.io, 20-40 $/mois selon les configurations des machines. Les économies s'accumulent chaque mois.

Le déploiement utilise Nixpacks (le même builder que Railway) ou des Dockerfiles. On connecte un repo GitHub, Coolify détecte le framework, build et deploy. SSL automatique via Let's Encrypt. Provisionnement de bases en un clic avec sauvegardes automatiques configurables. Ça coche toutes les cases d'un PaaS managé, sur son propre hardware.

Les compromis sont ceux de l'auto-hébergement. On gère les mises à jour OS, les correctifs de sécurité, le monitoring de l'espace disque et la vérification des sauvegardes. Si le serveur tombe, toutes les apps tombent. Pas de CDN mondial, pas de déploiement multi-régions, pas de failover automatique. Pour des apps en production avec des clients payants, il faut ajouter du monitoring d'uptime (Coolify peut déployer Uptime Kuma pour vous) et tester sa procédure de recovery.

Pour un fondateur technique qui fait tourner plusieurs projets, Coolify est l'option avec le meilleur rapport qualité-prix de cette liste. La courbe d'apprentissage est modeste, et la maintenance continue représente quelques heures par mois.

Quand choisir Coolify : On est à l'aise avec l'administration Linux de base et on veut minimiser les coûts d'hébergement sur plusieurs projets.

DigitalOcean App Platform — le choix sans surprises

DigitalOcean App Platform ne va pas vous éblouir. L'expérience de deploy est correcte. Le dashboard est fonctionnel. La tarification est claire. Et pour beaucoup de fondateurs, c'est exactement ce qu'ils cherchent.

La valeur d'App Platform, c'est l'écosystème DigitalOcean derrière. Si on utilise déjà des Droplets, des bases managées ou Spaces (stockage S3-compatible), App Platform se connecte à tout ça sur un réseau privé. On deploy un service web qui communique avec une instance Postgres managée et un bucket Spaces, et le réseau fonctionne sans configuration de firewall ni de VPN.

L'hébergement statique gratuit couvre 3 sites avec des limites de bande passante modestes. Les conteneurs payants démarrent à 5 $/mois pour une instance Basic. Les conteneurs Professional à 12 $/mois ajoutent l'auto-scaling et plus de ressources. La tarification par conteneur rend la facture prévisible mais elle grimpe linéairement avec chaque service ajouté.

Par rapport à Fly.io, App Platform échange la portée mondiale et la sophistication technique contre la simplicité et la prévisibilité. On obtient 8 régions au lieu de 30+. Des déploiements en conteneurs au lieu de VMs Firecracker. Un dashboard qui montre exactement ce qui tourne et ce que ça coûte.

Quand choisir DigitalOcean App Platform : On est déjà dans l'écosystème DigitalOcean, on valorise la fiabilité plus que les features de pointe, et on veut un PaaS qui fonctionne sans drame.

Hetzner avec Docker ou Kamal — la valeur maximale

Hetzner n'est pas un PaaS. C'est un fournisseur d'infrastructure cloud qui propose des serveurs virtuels et dédiés à des prix qui donnent l'impression que les autres fournisseurs se moquent du monde. Un CX22 avec 2 vCPU, 4 Go de RAM et 40 Go de stockage NVMe coûte 4,15 $/mois. Un CX32 avec 4 vCPU, 8 Go de RAM et 80 Go de stockage coûte 7,49 $/mois. Ce sont des ressources qui coûteraient 40-80 $/mois sur une plateforme managée.

Le piège est évident : on fait tout soi-même. Pas de dashboard de deploy, pas de git push to deploy, pas de bases managées. On obtient un serveur avec un accès root et une clé SSH.

C'est là que Kamal entre en jeu. Construit par l'équipe Rails (anciennement connu sous le nom de MRSK), Kamal offre des déploiements Docker zero-downtime à partir d'un seul fichier de config YAML. On le pointe vers son serveur Hetzner, on lance kamal setup, et il configure Traefik comme reverse proxy, pull l'image Docker et deploy l'app avec des health checks et des rolling updates. Les deploys suivants se font avec kamal deploy — rapide, fiable et reproductible.

Kamal fonctionne avec n'importe quelle application Docker, pas seulement Rails. Une API Node.js, un service Python, un binaire Go — si ça a un Dockerfile, Kamal le deploy. On ajoute des accessories (le terme Kamal pour les services annexes) pour faire tourner Postgres, Redis ou n'importe quelle image Docker à côté de l'app principale.

L'alternative à Kamal, c'est du Docker Compose classique avec un pipeline CI/CD (GitHub Actions qui push vers le serveur). Ca fonctionne très bien et c'est agnostique au framework, mais on gère le SSL (avec Caddy ou Traefik), les health checks et le zero-downtime deploy soi-même.

Pour les fondateurs à l'aise avec Docker, Hetzner offre le plus de ressources par euro de toutes les options de cette liste. Le payback period du temps investi dans le setup est généralement d'un à deux mois d'économies d'hébergement.

Quand choisir Hetzner : On est à l'aise avec Docker, on veut le maximum de performance par euro, et on ne rechigne pas à passer une journée sur le setup initial du serveur.

Vercel — pour les workloads edge et serverless

Vercel n'est pas un remplacement direct de Fly.io. Il couvre un créneau spécifique : déployer des frameworks frontend et des fonctions serverless sur un réseau edge mondial avec zéro configuration. Si l'app Fly.io est un frontend Next.js avec des routes API, Vercel est une cible de migration naturelle.

L'expérience développeur est la référence dans son créneau. Git push, deploy preview sur chaque PR, SSL automatique, optimisation d'images et edge middleware — le tout sans configuration. L'intégration avec Next.js est inégalée puisque Vercel construit Next.js.

Les fonctions serverless et edge tournent proches des utilisateurs dans le monde entier, de façon similaire au modèle multi-régions de Fly.io mais sans conteneurs ni VMs. On écrit une fonction, on la deploy, et elle tourne à l'edge. Pour des routes API qui n'ont pas besoin de connexions persistantes ou de processus long-running, c'est plus simple que de gérer des Fly Machines.

Les limites sont claires. Pas de processus serveur long-running. Pas de serveurs WebSocket (au-delà de connexions éphémères). Pas de workers en arrière-plan. Pas de Postgres ni Redis managé en natif (Vercel les propose en add-ons payants avec des fonctionnalités limitées). Si le workload Fly.io inclut l'un de ces éléments, Vercel ne peut pas tout remplacer seul — on le combine avec Railway ou un VPS Hetzner pour le backend.

Le modèle de tarification a sa propre complexité. Tarification par siège en équipe (20 $/mois par membre), surcoûts de bande passante, limites d'invocations de fonctions et frais d'optimisation d'images s'additionnent de manière difficile à prévoir. Pour un fondateur solo sur le plan gratuit ou Pro avec un trafic modéré, les coûts sont raisonnables. A grande échelle, ça devient cher.

Quand choisir Vercel : L'app Fly.io est principalement un framework frontend avec des routes API, et on veut l'expérience de deploy la plus fluide possible pour ce type de workload.

Ce que coûte réellement un MVP SaaS typique

Voici la facture mensuelle pour un stack SaaS indie standard — service web, base Postgres, cache Redis, worker en arrière-plan — sur chaque plateforme :

• Fly.io : Facturation à l'usage, typiquement 10-20 $/mois (varie selon le nombre de machines, les régions et le trafic)
• Railway : Facturation à l'usage, typiquement 8-15 $/mois pour cette charge
• Render : 7 $ (web) + 7 $ (Postgres) + 7 $ (Redis) + 7 $ (worker) = 28 $/mois
• Coolify sur Hetzner : 4-10 $/mois (coût VPS uniquement, tous services inclus)
• DigitalOcean App Platform : 5 $ (web) + 7 $ (BD) + 5 $ (Redis) + 5 $ (worker) = 22 $/mois
• Hetzner avec Docker/Kamal : 4-8 $/mois (coût VPS uniquement)
• Vercel + backend externe : 0-20 $ (frontend) + coûts du backend ailleurs

Les options auto-hébergées (Coolify sur Hetzner, Docker/Kamal sur Hetzner) sont radicalement moins chères pour les workloads multi-services. On paie le serveur, pas par service. Un VPS Hetzner à 8 $/mois qui fait tourner quatre services fait économiser 20-50 $/mois par rapport aux plateformes managées — soit 240-600 $/an de plus dans la poche.

Les plateformes managées (Railway, Render) facturent par service mais gèrent toute l'infra. Le choix revient à ce qu'on valorise le plus : son temps ou son argent. Pour un side project pré-MRR, l'auto-hébergement fait de vraies économies. Pour un produit qui génère du revenu, la plateforme managée libère des heures qu'on peut investir dans la croissance.

Quand rester sur Fly.io

Fly.io reste le bon choix si :

• Les utilisateurs sont véritablement mondiaux et le temps de réponse depuis 30+ régions compte pour l'expérience produit
• On a besoin du scale-to-zero avec des cold starts rapides — les Fly Machines redémarrent en 1-3 secondes contre 30-60 secondes sur le plan gratuit de Render
• On fait tourner des workloads edge comme du multijoueur temps réel, des APIs basse latence ou des services CDN-like qui bénéficient de l'isolation des VMs Firecracker
• On utilise LiteFS pour du SQLite distribué — le SQLite répliqué mondialement de Fly.io est genuinement unique et puissant pour les apps à lecture intensive
• On a déjà investi le temps pour apprendre la plateforme et le pipeline de deploy fonctionne de manière fiable

La capacité de déploiement mondial de Fly.io n'est pas un gadget. Pour le bon workload, faire tourner son API dans 30+ régions avec du routage automatique des requêtes est un avantage concurrentiel réel. La question est de savoir si le workload en a besoin. La plupart des produits SaaS indie, non.

Si le deploy fonctionne et que la facture est prévisible, ne changez pas pour le plaisir de changer. La meilleure infra, c'est celle à laquelle on ne pense pas.

Conseils pratiques pour la migration

1. Commencez par une app non critique. Déployez un environnement de staging ou un side project sur la nouvelle plateforme d'abord. Familiarisez-vous avec le pipeline de deploy, les logs et le monitoring avant de toucher à la production.

2. Exportez vos données Fly Postgres. Utilisez fly postgres connect pour accéder à la base, puis pg_dump pour créer un backup. Importez-le sur la nouvelle plateforme avec pg_restore. Vérifiez que toutes les données, contraintes, index et extensions ont été transférés correctement.

3. Mappez votre fly.toml vers la nouvelle plateforme. Variables d'environnement, chemins de health check, ports internes et configuration de scaling ont tous besoin d'équivalents. Railway lit la plupart de la config depuis les variables d'environnement. Render utilise un blueprint render.yaml. Kamal utilise deploy.yml.

4. Gérez les secrets avec précaution. Utilisez fly secrets list pour inventorier tous les secrets de l'app Fly.io. Recréez-les sur la nouvelle plateforme. N'en sautez aucun — une clé API ou une URL de base de données manquante provoquera des erreurs subtiles.

5. Mettez en place le monitoring avant le basculement. Déployez un monitoring d'uptime (Uptime Robot, Better Uptime, ou Uptime Kuma en auto-hébergé) pointant vers le nouveau déploiement. Faites tourner les deux plateformes en parallèle pendant au moins 48 heures.

6. Utilisez le DNS pour le basculement. Configurez le TTL DNS de votre domaine à 300 secondes (5 minutes) la veille de la migration. Pointez le DNS vers la nouvelle plateforme. Si quelque chose ne va pas, rebasculez vers Fly.io. Gardez le déploiement Fly.io actif pendant une semaine en fallback.

7. Supprimez les ressources Fly.io après avoir confirmé la stabilité. Une fois le nouveau déploiement stable depuis une semaine, réduisez et supprimez vos machines, volumes et clusters Postgres Fly.io pour arrêter la facturation. N'oubliez pas les frais d'adresse IPv4 à 2 $/mois — libérez-les aussi.