Preços do Fly.io, Cloud Run e Fargate: quanto custa um app sempre ativo

O app de votação de exemplo do Docker roda em cinco contêineres. Um app web em Python recebe os votos e os repassa ao Redis. Um worker em .NET move cada voto para o Postgres. Uma página em Node.js mostra os resultados à medida que chegam. Rodamos tudo em uma VM de teste (que não é um servidor da DreamHost) para ver de quanto servidor você precisaria. Dez minutos depois de iniciados, os cinco contêineres usavam juntos 177 MiB.

Os cinco contêineres precisam ficar no ar, então no Fly.io, no Google Cloud Run e no AWS Fargate você paga por cada um deles 24 horas por dia. Cada plataforma também cobra o banco de dados, o Redis, a rede e os dados de saída em linhas separadas. Nas faturas abaixo, escolhemos o menor tamanho de cada plataforma que comporta o que a stack usou, para que as três precifiquem a mesma carga de trabalho.

O que a stack usou na nossa VM de teste

A VM tinha o mesmo tamanho do nosso plano Stack 4. Iniciamos a stack a partir das imagens publicadas pelo Docker, esperamos que ela estabilizasse e usamos o k6 para enviar 20 votos e 2 visualizações da página de resultados por segundo durante cinco minutos. Todas as 6.602 requisições foram respondidas, e 95% voltaram em até 7,8 ms.

Estabilizado é a mediana de 12 leituras do docker stats após dez minutos, e pico é a maior leitura a 20 votos por segundo. Os picos vêm de duas execuções. Na primeira, na VM de 4 GB, o Redis chegou a 6 MiB e os cinco contêineres juntos a 197 MiB. Em uma repetição em uma VM de 8 GB, o Redis chegou a 29 MiB, o valor que aparece na linha dele.

Nenhum contêiner passou de cerca de 105 MiB, nem a 200 votos por segundo, então o menor tamanho que cada plataforma vende ainda dá a cada um mais que o dobro do seu pico de memória. As faturas abaixo usam esses menores tamanhos, exceto onde as regras de CPU do Cloud Run exigem mais.

A CPU quase não se mexeu a 20 votos por segundo. A mediana do contêiner de votação foi de 4% de uma CPU na repetição e de 9,3% na primeira execução. Uma vCPU compartilhada do Fly pode usar 6,25% antes de recorrer ao saldo de burst, então o app de votação usaria esse saldo parte do tempo. Também limitamos os contêineres de votação, resultados, worker e Redis a 0,25 vCPU e 512 MiB, a menor tarefa do Fargate, usando limites do Linux na nossa segunda VM de teste. Não limitamos o Postgres, já que as faturas o colocam no RDS. Nessa repetição, a latência p95 da stack foi de 6,8 ms com limite e 8,6 ms sem limite, uma diferença dentro da variação normal entre execuções. O app de votação provavelmente seria o primeiro a bater nesse limite conforme o tráfego cresce.

Com a stack e o Portainer rodando, a VM inteira usou 595 MiB e ainda tinha 3.309 MiB disponíveis. Ou seja, você poderia rodar esta stack tranquilamente no Stack 4, que custa menos que o Stack 8. Mesmo assim, escolheríamos o Stack 8, que a página de Docker indica para apps em produção, porque ele deixa espaço para uma versão bem mais movimentada desta stack e para um banco de dados que cresce.

Faturas mensais em três tamanhos

Os preços do Fly.io são de Ashburn, Virgínia; os do Cloud Run, de Iowa; e os da AWS, de US East (N. Virginia). Cada um usa as tarifas sob demanda publicadas, consultadas em 20 de outubro de 2026, para um mês de 730 horas, sem impostos. O Fly.io cota as Machines por 30 dias, então os preços delas foram ajustados para 730 horas; o Managed Postgres foi contado pelo preço mensal listado.

• Cenário 1: a stack acima sem a página de resultados, com 1 milhão de requisições, 50 GB de dados de saída e um banco de dados de 5 GB por mês.
• Cenário 2: acrescenta a página de resultados como um segundo serviço web, com 3 milhões de requisições, 150 GB de saída e um banco de dados de 10 GB.
• Cenário 3: duas cópias de cada serviço web, com 10 milhões de requisições, 1 TB de saída e um banco de dados de 20 GB.

A fatura de cada plataforma inclui um banco de dados gerenciado com backups, enquanto no servidor você roda o Postgres e faz o backup por conta própria. Do cenário 1 para o cenário 3, a fatura do Cloud Run praticamente triplica e a do Fargate quase isso. A do Fly.io sobe cerca de 60%.

Para onde vai o dinheiro do cenário 1

A maior parte da fatura do Fly.io é o banco de dados. O Managed Postgres com o armazenamento sai por US$ 39,40, e US$ 38 disso são do plano Basic. As três Machines custam juntas US$ 6,66. Todos os planos do Managed Postgres incluem alta disponibilidade, backups e pool de conexões.

No Cloud Run, você manteria uma instância mínima no serviço web para que as requisições não esperem por uma inicialização a frio. Ela recebe 1 vCPU porque um serviço só pode usar menos de 1 vCPU se cada instância atender uma requisição por vez. Consideramos 100 ms de tempo ativo por requisição, já que o Cloud Run arredonda o tempo cobrado para cima, para os 100 ms mais próximos. O worker roda como um pool de workers, a opção do Google para trabalho contínuo em segundo plano, e um pool de workers começa em 1 vCPU. Calculamos o preço pela tabela de tarifas do Google. O próprio exemplo do Google para um pool de workers de 1 vCPU e 512 MiB, com preços da Bélgica, chega a US$ 16,83 por mês antes do nível gratuito. Isso é menos do que a tabela de tarifas do Google indica, então confira o seu caso na calculadora de preços do Google.

No Google, o Redis é a maior linha da sua fatura. Um contêiner Redis poderia rodar como um pool de workers, que aceita conexões da sua VPC em um IP privado, mas ele também começaria com uma vCPU inteira, cerca de US$ 31 por mês. Por isso, calculamos o Memorystore for Redis, o Redis gerenciado do Google, cuja menor instância Basic comporta 1 GiB.

Na AWS, você paga mais pela rede do que pelos contêineres. As três tarefas do Fargate custam juntas US$ 21,63, enquanto o balanceador de carga e os endereços IP chegam a US$ 35,08. Calculamos as tarefas como Linux/ARM; em x86, cada uma custaria cerca de US$ 9,01 em vez de US$ 7,21. Um Application Load Balancer é cobrado por hora e precisa usar pelo menos duas Availability Zones. A AWS cobra US$ 0,005 por hora, cerca de US$ 3,65 por mês, por cada endereço IPv4 público. Contamos cinco endereços: um para cada uma das três tarefas, mais dois para o balanceador de carga, um em cada Availability Zone.

Os dados de saída dominam conforme o tráfego cresce. Com 1 TB por mês no cenário 3, eles são a maior linha individual no Google, com US$ 111,64. Na AWS, chegam a US$ 81,00 depois dos 100 GB gratuitos. O Fly.io cobra US$ 0,02 por GB, o que faz o terabyte sair por US$ 20,00. Em uma Docker VPS você não paga por GB, embora se aplique a política de uso justo.

O que cada preço inclui

Rodar o Postgres por conta própria como um app no Fly.io também reduz a fatura do Fly.io, e você assume o mesmo trabalho de banco de dados que teria em um servidor. Para uma comparação só de bancos de dados, veja quanto custa o Postgres gerenciado por si só. Se o seu app sempre ativo é um único app Laravel, os preços do Laravel Cloud e do Forge para um app analisam esse caso, com scheduler e queue worker incluídos. E se o Portainer for mais painel do que você precisa, medimos o Portainer em comparação com painéis Docker mais leves em um servidor pequeno.

Calcule o preço da sua stack

1. Liste os contêineres que rodam o mês todo

   Se um contêiner precisa responder a qualquer hora ou processa uma fila, ele vai rodar o mês inteiro, então calcule o preço como sempre ativo. Deixe o que pode hibernar em uma plataforma que cobra por requisição: um único contêiner pequeno assim muitas vezes cabe no nível gratuito mensal do Cloud Run.

2. Meça o que cada contêiner usa

   Rode isto em uma máquina onde a stack esteja rodando, uma vez depois que ela estabilizar e outra sob seu tráfego normal:

   bashCopiar

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

   Nossa stack usou 335 MiB dois minutos depois de iniciar e cerca da metade disso após dez, então dê um tempo à sua antes de fazer a leitura.

3. Escolha o menor tamanho que comporte cada um

   O ideal é cerca de 1,5 vez a maior leitura de cada contêiner. Depois, confira os mínimos de cada plataforma na tabela acima.

4. Some os itens fora dos contêineres

   Depois, some o banco de dados, o Redis, o balanceador de carga, os endereços IP e os dados de saída. Nos nossos três cenários, esses itens custam mais que a computação em todas as plataformas. O detalhamento por serviço da sua última fatura mostra quais deles você já paga.

5. Se for migrar, faça backup do Postgres antes da troca

   Um dump do contêiner do banco de dados leva um único comando. Coloque-o em um pequeno script que o cron execute toda noite. Para o banco de dados do app de votação:

   bashCopiar

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

   Copie cada dump para um armazenamento fora do servidor e, de vez em quando, restaure um em um contêiner reserva para confirmar que funciona.

Como medimos

A DreamHost fez o teste em 20 de outubro de 2026, em uma VM Colima em um Mac com Apple silicon. Ela rodava Ubuntu 24.04 em aarch64 com Docker 29.5.2. Tinha 3.904 MiB de memória utilizável e nenhum swap. A execução com limites e uma repetição do teste de carga rodaram em uma segunda VM com o mesmo número de CPUs e o dobro da memória, já que a memória extra não muda o que cada contêiner usa. O k6 enviou a carga da mesma VM, então dividiu a CPU com a stack. Sob carga, o docker stats rodava a cada 3 a 5 segundos, então pode ter deixado passar um pico mais curto que isso. A etapa de 200 votos por segundo rodou em uma stack já aquecida, logo depois das etapas mais leves.

Os planos VPS da DreamHost indicam processadores AMD EPYC, que são x86, enquanto a VM rodava arm64. Não executamos nada no Fly.io, no Cloud Run nem no Fargate, então as inicializações a frio e o comportamento de CPU dessas plataformas não aparecem nestes números. A execução com CPU limitada apenas imita uma tarefa do Fargate e deixa de fora o agente do Service Connect, que divide a CPU e a memória de cada tarefa no Fargate. Precificamos o Cloud SQL com 10 GiB de armazenamento SSD, por escolha nossa. As faturas não incluem impostos, logs, armazenamento no registro de contêineres, créditos de cadastro nem planos de suporte pagos. Elas aplicam o nível gratuito do Google tanto aos serviços quanto aos worker pools. Se o Google contar os dois como uma única cota, as faturas dele ficam mais altas. Todos os preços das plataformas foram consultados em 16 de outubro e novamente em 20 de outubro de 2026, sem alterações.

Perguntas frequentes sobre o custo de contêineres sempre ativos