Preise von Fly.io, Cloud Run und Fargate: Was eine dauerhaft laufende App kostet

Die Beispiel-Voting-App von Docker läuft als fünf Container. Eine Python-Web-App nimmt die Stimmen entgegen und gibt sie an Redis weiter. Ein .NET-Worker überträgt jede Stimme in Postgres. Eine Node.js-Seite zeigt die Ergebnisse, sobald sie eingehen. Wir haben die App auf einer Test-VM (kein DreamHost-Server) laufen lassen, um zu sehen, wie viel Server du dafür brauchst. Zehn Minuten nach dem Start belegten die fünf Container zusammen 177 MiB.

Alle fünf Container müssen dauerhaft laufen, also zahlst du bei Fly.io, Google Cloud Run und AWS Fargate rund um die Uhr für jeden einzelnen. Jede Plattform berechnet dir außerdem Datenbank, Redis, Networking und ausgehenden Datenverkehr als separate Posten. Für die Rechnungen unten haben wir auf jeder Plattform die kleinste Größe gewählt, die den Verbrauch des Stacks abdeckt, sodass alle drei dieselbe Arbeitslast bepreisen.

Was der Stack auf unserer Test-VM verbraucht hat

Die VM war genauso groß wie unser Tarif Stack 4. Wir haben den Stack aus den veröffentlichten Images von Docker gestartet, ihn sich einpendeln lassen und dann mit k6 fünf Minuten lang pro Sekunde 20 Stimmen und 2 Aufrufe der Ergebnisseite gesendet. Alle 6.602 Anfragen wurden beantwortet, 95 Prozent davon innerhalb von 7,8 ms.

„Eingependelt“ ist der Median aus 12 Messwerten von docker stats nach zehn Minuten, „Spitze“ ist der höchste Messwert bei 20 Stimmen pro Sekunde. Die Spitzenwerte stammen aus zwei Durchläufen. Im ersten, auf der 4-GB-VM, erreichte Redis maximal 6 MiB und alle fünf Container zusammen 197 MiB. In einer Wiederholung auf einer 8-GB-VM kam Redis auf 29 MiB, den Wert in seiner Zeile.

Kein Container ging über etwa 105 MiB hinaus, selbst bei 200 Stimmen pro Sekunde. Die kleinste Größe, die jede Plattform anbietet, gibt also jedem Container immer noch mehr als das Doppelte seines Spitzenspeichers. Die Rechnungen unten verwenden diese kleinsten Größen, außer wo die CPU-Regeln von Cloud Run mehr verlangen.

Die CPU-Last bewegte sich bei 20 Stimmen pro Sekunde kaum. Der Median des Vote-Containers lag im Wiederholungsdurchlauf bei 4 % einer CPU und im ersten Durchlauf bei 9,3 %. Eine Shared vCPU bei Fly kann 6,25 % nutzen, bevor sie auf ihr Burst-Guthaben zugreift. Die Vote-App würde also zeitweise auf dieses Guthaben zurückgreifen. Außerdem haben wir die Container für Vote, Ergebnisse, Worker und Redis auf unserer zweiten Test-VM per Linux-Limits auf 0,25 vCPU und 512 MiB begrenzt, die kleinste Fargate-Task. Postgres haben wir nicht begrenzt, da es in den Rechnungen auf RDS läuft. In dieser Wiederholung lag die p95-Latenz des Stacks bei 6,8 ms mit und 8,6 ms ohne Begrenzung, ein Unterschied innerhalb der normalen Streuung zwischen Durchläufen. Bei wachsendem Traffic würde wahrscheinlich die Vote-App als Erste an diese Grenze stoßen.

Mit laufendem Stack und Portainer belegte die gesamte VM 595 MiB und hatte noch 3.309 MiB frei. Du könntest diesen Stack also problemlos auf Stack 4 betreiben, der weniger kostet als Stack 8. Wir würden trotzdem Stack 8 wählen, den die Docker-Seite für Apps im Produktivbetrieb empfiehlt, weil er Platz für eine deutlich stärker ausgelastete Version dieses Stacks und für eine wachsende Datenbank lässt.

Monatliche Rechnungen in drei Größen

Fly.io ist für Ashburn, Virginia, bepreist, Cloud Run für Iowa und AWS für US East (N. Virginia). Grundlage sind jeweils die veröffentlichten On-Demand-Tarife, abgerufen am 20. Oktober 2026, für einen Monat mit 730 Stunden, ohne Steuern. Fly.io gibt die Preise für Machines pro 30 Tage an, deshalb haben wir sie auf 730 Stunden hochgerechnet. Managed Postgres ist mit seinem gelisteten Monatspreis angesetzt.

• Szenario 1: der Stack oben ohne Ergebnisseite, mit 1 Million Anfragen, 50 GB ausgehendem Datenverkehr und einer 5-GB-Datenbank pro Monat.
• Szenario 2: zusätzlich die Ergebnisseite als zweiter Webdienst, mit 3 Millionen Anfragen, 150 GB ausgehendem Datenverkehr und einer 10-GB-Datenbank.
• Szenario 3: zwei Instanzen jedes Webdienstes, mit 10 Millionen Anfragen, 1 TB ausgehendem Datenverkehr und einer 20-GB-Datenbank.

Jede Plattformrechnung enthält eine verwaltete Datenbank mit Backups, während du auf dem Server Postgres selbst betreibst und sicherst. Von Szenario 1 zu Szenario 3 verdreifacht sich die Rechnung bei Cloud Run ungefähr und bei Fargate fast. Bei Fly.io steigt sie um etwa 60 %.

Wohin das Geld in Szenario 1 fließt

Den Großteil der Rechnung bei Fly.io macht die Datenbank aus. Managed Postgres mit Speicher kommt auf 39,40 $, davon entfallen 38 $ auf den Basic-Tarif. Die drei Machines kosten zusammen 6,66 $. Jeder Managed-Postgres-Tarif umfasst Hochverfügbarkeit, Backups und Connection Pooling.

Bei Cloud Run würdest du für den Webdienst eine Mindestinstanz vorhalten, damit Anfragen nicht auf einen Kaltstart warten müssen. Sie bekommt 1 vCPU, weil ein Dienst nur dann weniger als 1 vCPU nutzen kann, wenn jede Instanz jeweils nur eine Anfrage bearbeitet. Wir haben 100 ms aktive Zeit pro Anfrage angenommen, da Cloud Run die abgerechnete Zeit auf die nächsten 100 ms aufrundet. Der Worker läuft als Worker-Pool, die Option von Google für kontinuierliche Hintergrundarbeit, und ein Worker-Pool beginnt bei 1 vCPU. Wir haben ihn anhand der Preistabelle von Google bepreist. Das eigene Rechenbeispiel von Google für einen Worker-Pool mit 1 vCPU und 512 MiB, bepreist in Belgien, kommt vor Abzug des kostenlosen Kontingents auf 16,83 $ im Monat. Das ist weniger, als die Preistabelle von Google ergibt. Prüf deine Kosten also im Preisrechner von Google.

Bei Google ist Redis der größte Posten, den du bezahlst. Ein Redis-Container könnte als Worker-Pool laufen, der über eine private IP Verbindungen aus deiner VPC annimmt, würde aber ebenfalls bei einer vollen vCPU beginnen, also bei rund 31 $ im Monat. Deshalb haben wir Memorystore for Redis bepreist, den verwalteten Redis-Dienst von Google, bei dem die kleinste Basic-Instanz 1 GiB fasst.

Bei AWS zahlst du für Networking mehr als für die Container. Die drei Fargate-Tasks kosten zusammen 21,63 $, Load Balancer und IP-Adressen kommen auf 35,08 $. Wir haben die Tasks als Linux/ARM bepreist; auf x86 würde jede etwa 9,01 $ statt 7,21 $ kosten. Ein Application Load Balancer wird stundenweise abgerechnet und muss mindestens zwei Availability Zones nutzen. AWS berechnet für jede öffentliche IPv4-Adresse 0,005 $ pro Stunde, also etwa 3,65 $ im Monat. Wir haben fünf Adressen gezählt: eine für jede der drei Tasks plus zwei für den Load Balancer, eine pro Availability Zone.

Mit wachsendem Traffic dominiert der ausgehende Datenverkehr. Bei 1 TB im Monat in Szenario 3 ist er bei Google mit 111,64 $ der größte Einzelposten. Bei AWS kommt er nach den kostenlosen 100 GB auf 81,00 $. Fly.io berechnet 0,02 $ pro GB, das Terabyte kostet also 20,00 $. Auf einem Docker VPS zahlst du nicht pro GB, es gilt allerdings Fair Use.

Was in jedem Preis enthalten ist

Wenn du Postgres selbst als Fly.io-App betreibst, sinkt auch die Rechnung bei Fly.io, und du übernimmst dieselbe Datenbankarbeit wie auf einem Server. Für einen reinen Datenbankvergleich sieh dir an, was verwaltetes Postgres allein kostet. Ist deine dauerhaft laufende App eine einzelne Laravel-App, behandelt Preise von Laravel Cloud und Forge für eine App genau diesen Fall, inklusive Scheduler und Queue-Worker. Und falls Portainer mehr Dashboard ist, als du brauchst: Wir haben Portainer mit schlankeren Docker-Dashboards verglichen, auf einem kleinen Server.

Berechne die Kosten für deinen eigenen Stack

1. Liste die Container auf, die den ganzen Monat laufen

   Wenn ein Container zu jeder Uhrzeit antworten muss oder eine Warteschlange abarbeitet, läuft er den ganzen Monat. Bepreise ihn also als dauerhaft laufend. Alles, was schlafen kann, bleibt besser auf einer Plattform, die pro Anfrage abrechnet: Ein einzelner kleiner Container dieser Art passt oft in das monatliche kostenlose Kontingent von Cloud Run.

2. Miss, was jeder Container verbraucht

   Führe das auf einem Rechner aus, auf dem der Stack läuft, einmal nachdem er sich eingependelt hat und noch einmal bei deinem normalen Traffic:

   bashKopieren

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

   Unser Stack belegte zwei Minuten nach dem Start 335 MiB und nach zehn Minuten etwa die Hälfte davon. Lass deinem Stack also Zeit, bevor du die Werte abliest.

3. Wähle die kleinste Größe, die dafür reicht

   Plane etwa das 1,5-Fache des höchsten Messwerts jedes Containers ein. Prüf dann die Mindestgrößen jeder Plattform in der Tabelle oben.

4. Ergänze die Posten außerhalb der Container

   Rechne dann Datenbank, Redis, Load Balancer, IP-Adressen und ausgehenden Datenverkehr dazu. In unseren drei Szenarien sind diese Posten auf jeder Plattform größer als die Rechenleistung. Die Aufschlüsselung nach Diensten auf deiner letzten Rechnung zeigt, welche davon du bereits bezahlst.

5. Wenn du umziehst, sichere Postgres vor dem Wechsel

   Ein Dump aus dem Datenbank-Container braucht nur einen Befehl. Pack ihn in ein kleines Skript, das Cron jede Nacht ausführt. Für die Datenbank der Voting-App:

   bashKopieren

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

   Kopiere jeden Dump auf einen Speicher außerhalb des Servers und spiel ab und zu einen davon in einen Ersatz-Container ein, um zu prüfen, ob er funktioniert.

So haben wir gemessen

DreamHost hat den Test am 20. Oktober 2026 auf einer Colima-VM auf einem Mac mit Apple Silicon durchgeführt. Darauf lief Ubuntu 24.04 auf aarch64 mit Docker 29.5.2. Die VM hatte 3.904 MiB nutzbaren Arbeitsspeicher und keinen Swap. Der begrenzte Durchlauf und eine Wiederholung des Lasttests liefen auf einer zweiten VM mit gleicher CPU-Anzahl und doppeltem Arbeitsspeicher, da der zusätzliche Speicher nichts daran ändert, was jeder Container belegt. k6 erzeugte die Last von derselben VM aus und teilte sich daher die CPU mit dem Stack. Unter Last lief docker stats alle 3 bis 5 Sekunden und konnte daher kürzere Spitzen verpassen. Die Stufe mit 200 Stimmen pro Sekunde lief auf einem bereits aufgewärmten Stack, direkt nach den leichteren Stufen.

Die VPS-Tarife von DreamHost nennen AMD-EPYC-Prozessoren, also x86, während die VM auf arm64 lief. Auf Fly.io, Cloud Run und Fargate haben wir nichts ausgeführt. Kaltstarts und CPU-Verhalten dieser Plattformen sind deshalb nicht in den Zahlen enthalten. Der gedrosselte Lauf ahmt einen Fargate-Task nur nach. Er lässt den Service-Connect-Agent weg, der sich auf Fargate CPU und Arbeitsspeicher mit jedem Task teilt. Für Cloud SQL haben wir 10 GiB SSD-Speicher angesetzt, das war unsere Wahl. Nicht enthalten sind Steuern, Logging, Speicher für die Container-Registry, Startguthaben und kostenpflichtige Supportpläne. Das kostenlose Kontingent von Google haben wir sowohl auf die Dienste als auch auf die Worker-Pools angerechnet. Zählt Google beides als ein Kontingent, fallen die Rechnungen höher aus. Alle Plattformpreise haben wir am 16. Oktober und erneut am 20. Oktober 2026 abgerufen. Geändert hatte sich nichts.

FAQ zu den Kosten dauerhaft laufender Container