Fly.io, Cloud Run and Fargate pricing: what an always-on app costs

Docker's example voting app runs as five containers. A Python web app takes the votes and hands them to Redis. A .NET worker moves each vote into Postgres. A Node.js page shows the results as they come in. We ran it on a test VM (not a DreamHost server) to see how much server you'd need for it. Ten minutes after it started, the five containers together used 177 MiB.

All five containers have to stay up, so on Fly.io, Google Cloud Run and AWS Fargate you pay for each of them around the clock. Each platform also bills you for the database, Redis, networking and data out as separate lines. For the bills below, we picked each platform's smallest size that holds what the stack used, so all three price the same workload.

What the stack used on our test VM

The VM was the same size as our Stack 4 plan. We started the stack from Docker's published images, let it settle, then used k6 to send 20 votes and 2 results-page views each second for five minutes. All 6,602 requests got an answer, and 95 percent came back within 7.8 ms.

Settled is the median of 12 docker stats readings after ten minutes, and peak is the highest reading at 20 votes a second. The peaks come from two runs. In the first, on the 4 GB VM, Redis peaked at 6 MiB and all five containers together at 197 MiB. In a repeat on an 8 GB VM, Redis reached 29 MiB, the figure in its row.

No container went above about 105 MiB, even at 200 votes a second, so the smallest size each platform sells still gives each one more than twice its peak memory. The bills below use those smallest sizes, except where Cloud Run's CPU rules ask for more.

CPU barely moved at 20 votes a second. The vote container's median was 4% of one CPU in the repeat run and 9.3% in the first run. A Fly shared vCPU can use 6.25% before it draws on its burst balance, so the vote app would dip into that balance some of the time. We also capped the vote, results, worker and Redis containers at 0.25 vCPU and 512 MiB, the smallest Fargate task, using Linux limits on our second test VM. We didn't cap Postgres, since the bills put it on RDS. In that repeat, the stack's p95 latency was 6.8 ms capped and 8.6 ms uncapped, a gap inside the normal spread between runs. The vote app would probably be the first to hit that cap as traffic grows.

With the stack and Portainer running, the whole VM used 595 MiB and still had 3,309 MiB available. So you'd be fine running this stack on Stack 4, which costs less than Stack 8. We'd still pick Stack 8, which the Docker page labels for apps running in production, because it leaves room for a much busier version of this stack and for a database that grows.

Monthly bills at three sizes

Fly.io is priced in Ashburn, Virginia, Cloud Run in Iowa and AWS in US East (N. Virginia). Each uses its published on-demand rates, read Oct 20, 2026, for a 730-hour month, before tax. Fly.io quotes Machines per 30 days, so their prices are scaled up to 730 hours; Managed Postgres is counted at its listed monthly price.

• Scenario 1: the stack above without the results page, with 1 million requests, 50 GB of data out and a 5 GB database a month.
• Scenario 2: adds the results page as a second web service, with 3 million requests, 150 GB out and a 10 GB database.
• Scenario 3: two copies of each web service, with 10 million requests, 1 TB out and a 20 GB database.

Each platform bill includes a managed database with backups, while on the server you run Postgres and back it up yourself. From scenario 1 to scenario 3, Cloud Run's bill roughly triples and Fargate's nearly does. Fly.io's rises by about 60%.

Where scenario 1's money goes

Most of Fly.io's bill is the database. Managed Postgres with its storage comes to $39.40, and $38 of that is the Basic plan. The three Machines cost $6.66 together. Every Managed Postgres plan includes high availability, backups and connection pooling.

On Cloud Run, you'd keep one minimum instance on the web service so requests don't wait for a cold start. It gets 1 vCPU because a service can use less than 1 vCPU only if each instance takes one request at a time. We assumed 100 ms of active time per request, since Cloud Run rounds billed time up to the nearest 100 ms. The worker runs as a worker pool, Google's option for continuous background work, and a worker pool starts at 1 vCPU. We priced it from Google's rate table. Google's own worked example for a 1 vCPU, 512 MiB worker pool, priced in Belgium, comes to $16.83 a month before the free tier. That's lower than Google's rate table gives, so check Google's pricing calculator for yours.

On Google, Redis is the biggest line you'll pay. A Redis container could run as a worker pool, which accepts connections from your VPC on a private IP, but it would also start at a full vCPU, about $31 a month. So we priced Memorystore for Redis, Google's managed Redis, where the smallest Basic instance holds 1 GiB.

On AWS, you'll pay more for networking than for the containers. The three Fargate tasks cost $21.63 together, while the load balancer and IP addresses come to $35.08. We priced the tasks as Linux/ARM; on x86, each one would cost about $9.01 instead of $7.21. An Application Load Balancer bills by the hour and has to use at least two Availability Zones. AWS charges $0.005 an hour, about $3.65 a month, for every public IPv4 address. We counted five addresses: one for each of the three tasks, plus two for the load balancer, one in each Availability Zone.

Data out takes over as traffic grows. At scenario 3's 1 TB a month, it's the biggest single line on Google, at $111.64. On AWS it comes to $81.00 after the free 100 GB. Fly.io charges $0.02 a GB, which makes the terabyte $20.00. On a Docker VPS you don't pay per GB, though fair use applies.

What each price includes

Running Postgres yourself as a Fly.io app lowers Fly.io's bill too, and you take on the same database work you'd have on a server. For a database-only comparison, see what managed Postgres costs on its own. If your always-on app is a single Laravel app, Laravel Cloud and Forge pricing for one app works through that case, scheduler and queue worker included. And if Portainer is more dashboard than you need, we measured Portainer against lighter Docker dashboards on a small server.

Price your own stack

1. List the containers that run all month

   If a container has to answer at any hour or works through a queue, it'll run all month, so price it as always on. Keep anything that can sleep on a platform that bills by the request: a single small container like that can often run inside Cloud Run's monthly free tier.

2. Measure what each container uses

   Run this on a machine where the stack's running, once after it settles and again under your normal traffic:

   bashCopy

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

   Our stack used 335 MiB two minutes after it started and about half that after ten, so give yours time before you read it.

3. Pick the smallest size that holds it

   You'll want about 1.5 times each container's highest reading. Then check each platform's minimums in the table above.

4. Add the lines outside the containers

   Then add the database, Redis, load balancer, IP addresses and data out. In our three scenarios, they're bigger than the compute on every platform. Your last invoice's breakdown by service shows which of them you already pay.

5. If you move, back up Postgres before you switch over

   A dump from the database container takes one command. Put it in a small script that cron runs every night. For the voting app's database:

   bashCopy

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

   Copy each dump to storage off the server, and restore one into a spare container now and then to check it works.

How we measured

DreamHost ran the test on October 20, 2026, on a Colima VM on an Apple-silicon Mac. It ran Ubuntu 24.04 on aarch64 with Docker 29.5.2. It had 3,904 MiB of usable memory and no swap. The capped run and a repeat of the load test ran on a second VM with the same CPU count and twice the memory, since the extra memory doesn't change what each container uses. k6 sent the load from the same VM, so it shared the CPU with the stack. Under load, docker stats ran every 3 to 5 seconds, so it could miss a spike shorter than that. The 200-votes-a-second step ran on an already warm stack, right after the lighter steps.

DreamHost's VPS plans list AMD EPYC processors, which are x86, while the VM ran arm64. We didn't run anything on Fly.io, Cloud Run or Fargate, so their cold starts and CPU behavior aren't in these numbers. The capped run only imitates a Fargate task, and it leaves out the Service Connect agent, which shares each task's CPU and memory on Fargate. Cloud SQL is priced with 10 GiB of SSD storage, our choice. The bills leave out tax, logging, container registry storage, sign-up credits and paid support plans. They apply Google's free tier to both its services and its worker pools. If Google counts them as one allowance, its bills come out higher. Every platform price was read on October 16 and again on October 20, 2026, with no changes.

Always-on container cost FAQs