Tarifs de Fly.io, Cloud Run et Fargate : combien coûte une app toujours active

L'application de vote d'exemple de Docker tourne sous forme de cinq conteneurs. Une application web Python reçoit les votes et les transmet à Redis. Un worker .NET transfère chaque vote dans Postgres. Une page Node.js affiche les résultats au fur et à mesure. Nous l'avons fait tourner sur une VM de test (qui n'est pas un serveur DreamHost) pour savoir quelle taille de serveur il lui faut. Dix minutes après le démarrage, les cinq conteneurs utilisaient 177 Mio à eux tous.

Les cinq conteneurs doivent rester actifs : sur Fly.io, Google Cloud Run et AWS Fargate, vous payez donc chacun d'eux 24 h/24. Chaque plateforme facture aussi la base de données, Redis, le réseau et le trafic sortant sur des lignes séparées. Pour les factures ci-dessous, nous avons retenu sur chaque plateforme la plus petite taille capable d'absorber ce que la pile a consommé. Les trois plateformes chiffrent ainsi la même charge de travail.

Ce qu'a consommé la stack sur notre VM de test

La VM avait la même taille que notre offre Stack 4. Nous avons lancé la pile à partir des images publiées par Docker et l'avons laissée se stabiliser. Nous avons ensuite utilisé k6 pour envoyer 20 votes et 2 affichages de la page de résultats par seconde pendant cinq minutes. Les 6 602 requêtes ont toutes obtenu une réponse, et 95 % d'entre elles en moins de 7,8 ms.

La valeur stabilisée est la médiane de 12 relevés docker stats après dix minutes. Le pic est le relevé le plus élevé à 20 votes par seconde. Les pics proviennent de deux tests. Lors du premier, sur la VM de 4 Go, Redis a culminé à 6 Mio et les cinq conteneurs réunis à 197 Mio. Lors d'un second test sur une VM de 8 Go, Redis a atteint 29 Mio, le chiffre indiqué sur sa ligne.

Aucun conteneur n'a dépassé environ 105 Mio, même à 200 votes par seconde. La plus petite taille vendue par chaque plateforme offre donc encore à chacun plus du double de sa mémoire au pic. Les factures ci-dessous utilisent ces plus petites tailles, sauf lorsque les règles de CPU de Cloud Run en imposent davantage.

Le CPU a à peine bougé à 20 votes par seconde. La médiane du conteneur de vote était de 4 % d'un CPU lors du second test et de 9,3 % lors du premier. Un vCPU partagé Fly peut utiliser 6,25 % avant de puiser dans son crédit de burst : l'application de vote entamerait donc ce crédit une partie du temps. Nous avons aussi limité les conteneurs de vote, de résultats, du worker et de Redis à 0,25 vCPU et 512 Mio, soit la plus petite tâche Fargate, à l'aide des limites Linux sur notre seconde VM de test. Nous n'avons pas limité Postgres, puisque les factures le placent sur RDS. Lors de ce second test, la latence p95 de la pile était de 6,8 ms avec limites et de 8,6 ms sans. Cet écart reste dans la variation normale d'un test à l'autre. L'application de vote serait probablement la première à atteindre cette limite à mesure que le trafic augmente.

Avec la pile et Portainer en marche, la VM entière utilisait 595 Mio et disposait encore de 3 309 Mio. Vous pourriez donc faire tourner cette pile sur Stack 4, moins cher que Stack 8. Nous choisirions tout de même Stack 8, que la page Docker recommande pour les applications en production. Cette offre laisse de la marge pour une version bien plus sollicitée de cette pile et pour une base de données qui grossit.

Factures mensuelles pour trois tailles

Les prix de Fly.io sont ceux d'Ashburn (Virginie), ceux de Cloud Run ceux de l'Iowa et ceux d'AWS ceux de US East (Virginie du Nord). Chaque prix utilise les tarifs à la demande publiés, relevés le 20 octobre 2026, pour un mois de 730 heures, hors taxes. Fly.io affiche le prix des Machines pour 30 jours. Nous l'avons donc ajusté à 730 heures. Managed Postgres est compté à son prix mensuel affiché.

• Scénario 1 : la pile ci-dessus sans la page de résultats, avec 1 million de requêtes, 50 Go de trafic sortant et une base de données de 5 Go par mois.
• Scénario 2 : ajoute la page de résultats comme second service web, avec 3 millions de requêtes, 150 Go de trafic sortant et une base de données de 10 Go.
• Scénario 3 : deux copies de chaque service web, avec 10 millions de requêtes, 1 To de trafic sortant et une base de données de 20 Go.

Chaque facture de plateforme inclut une base de données gérée avec sauvegardes. Sur le serveur, c'est vous qui gérez Postgres et ses sauvegardes. Du scénario 1 au scénario 3, la facture de Cloud Run triple environ et celle de Fargate presque. Celle de Fly.io augmente d'environ 60 %.

Où va l'argent du scénario 1

La base de données représente l'essentiel de la facture de Fly.io. Managed Postgres et son stockage reviennent à 39,40 $, dont 38 $ pour l'offre Basic. Les trois Machines coûtent 6,66 $ à elles toutes. Chaque offre Managed Postgres inclut la haute disponibilité, les sauvegardes et le pooling de connexions.

Sur Cloud Run, vous garderiez une instance minimale sur le service web pour que les requêtes n'attendent pas un démarrage à froid. Elle reçoit 1 vCPU, car un service ne peut utiliser moins de 1 vCPU que si chaque instance traite une seule requête à la fois. Nous avons supposé 100 ms de temps actif par requête, puisque Cloud Run arrondit le temps facturé aux 100 ms supérieures. Le worker tourne sous forme de pool de workers, l'option de Google pour les tâches d'arrière-plan continues. Or un pool de workers démarre à 1 vCPU. Nous l'avons chiffré à partir de la grille tarifaire de Google. L'exemple chiffré de Google pour un pool de workers de 1 vCPU et 512 Mio, en Belgique, revient à 16,83 $ par mois avant l'offre gratuite. C'est moins que ce que donne la grille tarifaire de Google : vérifiez donc votre cas dans le simulateur de prix de Google.

Chez Google, Redis est la ligne la plus chère de la facture. Un conteneur Redis pourrait tourner sous forme de pool de workers, qui accepte les connexions provenant de votre VPC sur une IP privée. Mais il démarrerait lui aussi à un vCPU complet, soit environ 31 $ par mois. Nous avons donc chiffré Memorystore for Redis, le Redis géré de Google, dont la plus petite instance Basic contient 1 Gio.

Chez AWS, vous paierez davantage pour le réseau que pour les conteneurs. Les trois tâches Fargate coûtent 21,63 $ à elles toutes, alors que l'équilibreur de charge et les adresses IP reviennent à 35,08 $. Nous avons chiffré les tâches en Linux/ARM. En x86, chacune coûterait environ 9,01 $ au lieu de 7,21 $. Un Application Load Balancer est facturé à l'heure et doit utiliser au moins deux zones de disponibilité. AWS facture 0,005 $ de l'heure, soit environ 3,65 $ par mois, pour chaque adresse IPv4 publique. Nous avons compté cinq adresses : une pour chacune des trois tâches, plus deux pour l'équilibreur de charge, une par zone de disponibilité.

Le trafic sortant prend le dessus à mesure que le trafic augmente. Avec le 1 To mensuel du scénario 3, c'est la ligne la plus chère chez Google, à 111,64 $. Chez AWS, il revient à 81,00 $ après les 100 Go gratuits. Fly.io facture 0,02 $ le Go, soit 20,00 $ le téraoctet. Sur un Docker VPS, vous ne payez pas au Go, sous réserve d'un usage raisonnable.

Ce que comprend chaque prix

Faire tourner Postgres vous-même comme application Fly.io réduit aussi la facture de Fly.io, mais vous prenez alors en charge le même travail sur la base de données que sur un serveur. Pour une comparaison portant uniquement sur la base de données, voyez ce que coûte Postgres géré à lui seul. Si votre application active en permanence est une seule application Laravel, les prix de Laravel Cloud et Forge pour une application détaillent ce cas, planificateur et worker de file d'attente compris. Et si Portainer est plus complet que nécessaire, nous avons comparé Portainer à des tableaux de bord Docker plus légers sur un petit serveur.

Estimez le coût de votre propre stack

1. Listez les conteneurs qui tournent tout le mois

   Si un conteneur doit répondre à toute heure ou traite une file d'attente, il tournera tout le mois : chiffrez-le comme actif en permanence. Laissez tout ce qui peut se mettre en veille sur une plateforme qui facture à la requête. Un seul petit conteneur de ce type peut souvent tenir dans l'offre gratuite mensuelle de Cloud Run.

2. Mesurez ce que consomme chaque conteneur

   Exécutez cette commande sur une machine où la pile tourne, une première fois après sa stabilisation, puis sous votre trafic habituel :

   bashCopier

   docker stats --no-stream \
     --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"

   Notre pile utilisait 335 Mio deux minutes après son démarrage et environ la moitié au bout de dix minutes. Laissez donc à la vôtre le temps de se stabiliser avant de relever les chiffres.

3. Choisissez la plus petite taille suffisante

   Prévoyez environ 1,5 fois le relevé le plus élevé de chaque conteneur. Vérifiez ensuite les minimums de chaque plateforme dans le tableau ci-dessus.

4. Ajoutez les postes hors conteneurs

   Ajoutez ensuite la base de données, Redis, l'équilibreur de charge, les adresses IP et le trafic sortant. Dans nos trois scénarios, ces lignes dépassent le calcul sur toutes les plateformes. Le détail par service de votre dernière facture montre celles que vous payez déjà.

5. Si vous migrez, sauvegardez Postgres avant de basculer

   Un dump du conteneur de base de données tient en une commande. Placez-la dans un petit script que cron exécute chaque nuit. Pour la base de données de l'application de vote :

   bashCopier

   docker compose exec -T db \
     pg_dump -U postgres -Fc postgres \
     > votes-$(date +%F).dump

   Copiez chaque dump vers un stockage hors du serveur, et restaurez-en un de temps en temps dans un conteneur de rechange pour vérifier qu'il fonctionne.

Notre méthode de mesure

DreamHost a réalisé le test le 20 octobre 2026 sur une VM Colima, sur un Mac à puce Apple. Elle exécutait Ubuntu 24.04 en aarch64 avec Docker 29.5.2. Elle disposait de 3 904 Mio de mémoire utilisable et d'aucun swap. Le test avec limites et la répétition du test de charge ont tourné sur une seconde VM avec le même nombre de CPU et deux fois plus de mémoire, car la mémoire supplémentaire ne change pas ce qu'utilise chaque conteneur. k6 envoyait la charge depuis la même VM et partageait donc le CPU avec la pile. Sous charge, docker stats s'exécutait toutes les 3 à 5 secondes et pouvait donc manquer un pic plus court. Le palier à 200 votes par seconde a tourné sur une pile déjà chaude, juste après les paliers plus légers.

Les offres VPS de DreamHost indiquent des processeurs AMD EPYC, donc x86, alors que la VM tournait en arm64. Nous n'avons rien exécuté sur Fly.io, Cloud Run ou Fargate : leurs démarrages à froid et le comportement de leur CPU ne figurent donc pas dans ces chiffres. L'exécution plafonnée ne fait qu'imiter une tâche Fargate et laisse de côté l'agent Service Connect, qui partage le CPU et la mémoire de chaque tâche sur Fargate. Cloud SQL est chiffré avec 10 Gio de stockage SSD, un choix de notre part. Les factures excluent les taxes, la journalisation, le stockage du registre de conteneurs, les crédits d'inscription et les offres de support payantes. Elles appliquent l'offre gratuite de Google à la fois à ses services et à ses pools de workers. Si Google les compte comme une seule franchise, ses factures sont plus élevées. Tous les tarifs des plateformes ont été relevés le 16 octobre puis le 20 octobre 2026, sans aucun changement.

FAQ sur le coût des conteneurs toujours actifs