Precios de Fly.io, Cloud Run y Fargate: lo que cuesta una app siempre activa

La aplicación de votación de ejemplo de Docker se ejecuta en cinco contenedores. Una aplicación web en Python recoge los votos y se los pasa a Redis. Un worker de .NET traslada cada voto a Postgres. Una página en Node.js muestra los resultados a medida que llegan. La ejecutamos en una VM de prueba (no es un servidor de DreamHost) para ver cuánto servidor necesitarías. Diez minutos después de arrancar, los cinco contenedores juntos usaban 177 MiB.

Los cinco contenedores tienen que estar siempre en marcha, así que en Fly.io, Google Cloud Run y AWS Fargate pagas por cada uno de ellos las 24 horas del día. Además, cada plataforma te factura la base de datos, Redis, la red y los datos salientes como líneas aparte. Para las facturas de abajo, elegimos en cada plataforma el tamaño más pequeño que cubre lo que usó el stack, para que las tres coticen la misma carga de trabajo.

Lo que usó el stack en nuestra VM de prueba

La VM tenía el mismo tamaño que nuestro plan Stack 4. Arrancamos el stack con las imágenes publicadas por Docker, dejamos que se estabilizara y luego usamos k6 para enviar 20 votos y 2 visitas a la página de resultados por segundo durante cinco minutos. Las 6602 solicitudes recibieron respuesta, y el 95 % volvió en 7,8 ms o menos.

El valor estable es la mediana de 12 lecturas de docker stats tras diez minutos, y el pico es la lectura más alta a 20 votos por segundo. Los picos salen de dos ejecuciones. En la primera, en la VM de 4 GB, Redis alcanzó un pico de 6 MiB y los cinco contenedores juntos, de 197 MiB. En una repetición en una VM de 8 GB, Redis llegó a 29 MiB, la cifra que aparece en su fila.

Ningún contenedor pasó de unos 105 MiB, ni siquiera a 200 votos por segundo, así que el tamaño más pequeño que vende cada plataforma les da a todos más del doble de su memoria máxima. Las facturas de abajo usan esos tamaños mínimos, salvo donde las reglas de CPU de Cloud Run exigen más.

La CPU apenas se movió a 20 votos por segundo. La mediana del contenedor de votación fue del 4 % de una CPU en la repetición y del 9,3 % en la primera ejecución. Una vCPU compartida de Fly puede usar el 6,25 % antes de tirar de su saldo de ráfaga, así que la aplicación de votación recurriría a ese saldo parte del tiempo. También limitamos los contenedores de votación, resultados, worker y Redis a 0,25 vCPU y 512 MiB, la tarea de Fargate más pequeña, con límites de Linux en nuestra segunda VM de prueba. No limitamos Postgres, porque en las facturas va en RDS. En esa repetición, la latencia p95 del stack fue de 6,8 ms con límite y de 8,6 ms sin límite, una diferencia dentro de la variación normal entre ejecuciones. Probablemente, la aplicación de votación sería la primera en toparse con ese límite a medida que crezca el tráfico.

Con el stack y Portainer en marcha, toda la VM usaba 595 MiB y aún tenía 3309 MiB disponibles. Así que podrías ejecutar este stack sin problema en Stack 4, que cuesta menos que Stack 8. Aun así, nosotros elegiríamos Stack 8, que la página de Docker recomienda para aplicaciones en producción, porque deja margen para una versión mucho más concurrida de este stack y para una base de datos que crece.

Facturas mensuales en tres tamaños

Los precios de Fly.io son de Ashburn (Virginia); los de Cloud Run, de Iowa, y los de AWS, de US East (N. Virginia). En cada caso usamos sus tarifas bajo demanda publicadas, consultadas el 20 de octubre de 2026, para un mes de 730 horas y sin impuestos. Fly.io cotiza las Machines por 30 días, así que sus precios se escalan a 730 horas; Managed Postgres se cuenta a su precio mensual de lista.

• Escenario 1: el stack anterior sin la página de resultados, con 1 millón de solicitudes, 50 GB de datos salientes y una base de datos de 5 GB al mes.
• Escenario 2: añade la página de resultados como segundo servicio web, con 3 millones de solicitudes, 150 GB de datos salientes y una base de datos de 10 GB.
• Escenario 3: dos copias de cada servicio web, con 10 millones de solicitudes, 1 TB de datos salientes y una base de datos de 20 GB.

La factura de cada plataforma incluye una base de datos administrada con copias de seguridad, mientras que en el servidor tú ejecutas Postgres y haces sus copias de seguridad. Del escenario 1 al 3, la factura de Cloud Run se triplica, más o menos, y la de Fargate casi. La de Fly.io sube alrededor de un 60 %.

En qué se va el dinero del escenario 1

La mayor parte de la factura de Fly.io es la base de datos. Managed Postgres con su almacenamiento suma 39,40 $, y 38 $ de eso corresponden al plan Basic. Las tres Machines cuestan 6,66 $ en total. Todos los planes de Managed Postgres incluyen alta disponibilidad, copias de seguridad y agrupación de conexiones.

En Cloud Run, mantendrías una instancia mínima en el servicio web para que las solicitudes no tengan que esperar a un arranque en frío. Tiene 1 vCPU porque un servicio solo puede usar menos de 1 vCPU si cada instancia atiende una sola solicitud a la vez. Supusimos 100 ms de tiempo activo por solicitud, ya que Cloud Run redondea al alza el tiempo facturado a los 100 ms más cercanos. El worker se ejecuta como grupo de workers (worker pool), la opción de Google para trabajo continuo en segundo plano, y un grupo de workers parte de 1 vCPU. Lo calculamos con la tabla de tarifas de Google. El propio ejemplo de Google para un grupo de workers de 1 vCPU y 512 MiB, con precios de Bélgica, sale a 16,83 $ al mes antes del nivel gratuito. Es menos de lo que da la tabla de tarifas de Google, así que consulta la calculadora de precios de Google para tu caso.

En Google, Redis es la línea más cara que pagarás. Un contenedor de Redis podría ejecutarse como grupo de workers, que acepta conexiones desde tu VPC en una IP privada, pero también partiría de una vCPU completa, unos 31 $ al mes. Así que calculamos Memorystore for Redis, el Redis administrado de Google, cuya instancia Basic más pequeña tiene 1 GiB.

En AWS, pagarás más por la red que por los contenedores. Las tres tareas de Fargate cuestan 21,63 $ en total, mientras que el balanceador de carga y las direcciones IP suman 35,08 $. Calculamos las tareas como Linux/ARM; en x86, cada una costaría unos 9,01 $ en lugar de 7,21 $. Un Application Load Balancer se factura por horas y tiene que usar al menos dos zonas de disponibilidad. AWS cobra 0,005 $ por hora, unos 3,65 $ al mes, por cada dirección IPv4 pública. Contamos cinco direcciones: una para cada una de las tres tareas, más dos para el balanceador de carga, una en cada zona de disponibilidad.

Los datos salientes mandan a medida que crece el tráfico. Con el 1 TB al mes del escenario 3, son la línea individual más grande en Google, con 111,64 $. En AWS salen a 81,00 $ después de los 100 GB gratuitos. Fly.io cobra 0,02 $ por GB, así que el terabyte cuesta 20,00 $. En un Docker VPS no pagas por GB, aunque se aplica una política de uso razonable.

Qué incluye cada precio

Ejecutar Postgres tú mismo como aplicación de Fly.io también reduce la factura de Fly.io, aunque asumes el mismo trabajo de base de datos que tendrías en un servidor. Para una comparación solo de bases de datos, consulta cuánto cuesta Postgres administrado por sí solo. Si tu aplicación siempre activa es una única aplicación Laravel, en los precios de Laravel Cloud y Forge para una aplicación analizamos ese caso, con el programador de tareas y el worker de colas incluidos. Y si Portainer es más panel del que necesitas, comparamos Portainer con paneles de Docker más ligeros en un servidor pequeño.

Calcula el precio de tu propio stack

1. Enumera los contenedores que funcionan todo el mes

   Si un contenedor tiene que responder a cualquier hora o procesa una cola, estará en marcha todo el mes, así que calcúlalo como siempre activo. Deja lo que pueda dormir en una plataforma que facture por solicitud: un único contenedor pequeño de ese tipo suele caber en el nivel gratuito mensual de Cloud Run.

2. Mide lo que usa cada contenedor

   Ejecuta esto en una máquina donde esté funcionando el stack, una vez cuando se haya estabilizado y otra con tu tráfico habitual:

   bashCopiar

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

   Nuestro stack usaba 335 MiB dos minutos después de arrancar y más o menos la mitad a los diez, así que dale tiempo al tuyo antes de medir.

3. Elige el tamaño más pequeño que lo cubra

   Conviene que reserves unas 1,5 veces la lectura más alta de cada contenedor. Después, revisa los mínimos de cada plataforma en la tabla de arriba.

4. Añade las partidas de fuera de los contenedores

   Después, suma la base de datos, Redis, el balanceador de carga, las direcciones IP y los datos salientes. En nuestros tres escenarios, cuestan más que la computación en todas las plataformas. El desglose por servicio de tu última factura te muestra cuáles ya pagas.

5. Si te cambias, haz una copia de seguridad de Postgres antes del cambio

   Hacer un volcado desde el contenedor de la base de datos requiere un solo comando. Ponlo en un pequeño script que cron ejecute cada noche. Para la base de datos de la aplicación de votación:

   bashCopiar

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

   Copia cada volcado a un almacenamiento fuera del servidor y, de vez en cuando, restaura uno en un contenedor de repuesto para comprobar que funciona.

Cómo lo medimos

DreamHost hizo la prueba el 20 de octubre de 2026 en una VM de Colima sobre un Mac con Apple silicon. Ejecutaba Ubuntu 24.04 en aarch64 con Docker 29.5.2. Tenía 3904 MiB de memoria utilizable y no tenía memoria de intercambio. La ejecución con límites y una repetición de la prueba de carga se hicieron en una segunda VM con el mismo número de CPU y el doble de memoria, ya que la memoria adicional no cambia lo que usa cada contenedor. k6 generó la carga desde la misma VM, así que compartía la CPU con el stack. Bajo carga, docker stats se ejecutaba cada 3 a 5 segundos, por lo que podía pasar por alto un pico más corto. El paso de 200 votos por segundo se ejecutó con el stack ya en caliente, justo después de los pasos más ligeros.

Los planes VPS de DreamHost indican procesadores AMD EPYC, que son x86, mientras que la VM funcionaba con arm64. No ejecutamos nada en Fly.io, Cloud Run ni Fargate, así que sus arranques en frío y su comportamiento de CPU no aparecen en estas cifras. La ejecución con límite de CPU solo imita una tarea de Fargate y deja fuera el agente de Service Connect, que en Fargate comparte la CPU y la memoria de cada tarea. Cloud SQL tiene precio con 10 GiB de almacenamiento SSD, una elección nuestra. Las facturas no incluyen impuestos, registros, almacenamiento en el registro de contenedores, créditos de alta ni planes de soporte de pago. Aplican el nivel gratuito de Google tanto a sus servicios como a sus grupos de workers. Si Google los cuenta como una sola asignación, sus facturas salen más caras. Consultamos todos los precios de las plataformas el 16 de octubre y de nuevo el 20 de octubre de 2026, sin cambios.

Preguntas frecuentes sobre el coste de los contenedores siempre activos