Cloudflare Containers: Cuando los Workers son demasiado pequeños
Cloudflare Containers está disponible de forma general. Lo que el stack de Workers ofrece ahora, dónde se aplica la ventaja del edge y cuándo vale la…
5 Min. Tiempo de lectura
Quien ha construido sobre Cloudflare Workers conoce el muro: a partir del momento en que el código necesita más de 128 MB de RAM o una cadena de herramientas Linux real, el despliegue se vuelve feo. Con Containers GA desde el 13 de abril de 2026, Cloudflare desplaza este muro. Los desarrolladores web que hasta ahora han recurrido a EC2, Fly.io o Render obtienen una capa de borde intermedia, sin clúster de Kubernetes y sin contrato de centro de datos.
10.05.2026
Lo más importante en resumen
- Precio de CPU activa como palanca real: Los contenedores solo se facturan cuando la CPU realmente consume ciclos. Los contenedores inactivos solo cuestan memoria más almacenamiento, no computación. Para cargas de trabajo en ráfaga, este es un marco de precios diferente al de AWS Fargate o Fly.io.
- Nombres de host, Docker Hub, SSH: Workers se comunican con contenedores a través de enlaces de servicio, las imágenes provienen de Docker Hub o una registry, SSH funciona para depuración en vivo. La pila se siente como Linux clásico, no como una sandbox de borde.
- Brecha entre Workers y EC2: Para navegadores sin cabeza, ffmpeg, Pandoc o pequeños endpoints de inferencia, Workers era demasiado pequeño y EC2 demasiado pesado. Los contenedores llenan exactamente esta capa intermedia y reducen el salto de pila a un solo proveedor.
Relacionado:Mini-PCs reemplazan a servidores 1HE: Edge en el centro de datos 2026 / Documentación de Cloudflare Containers
Qué trae realmente Containers GA
¿Qué es un contenedor de Cloudflare? Un contenedor de Cloudflare es un contenedor Linux efímero que se ejecuta en la red de borde de Cloudflare y se comunica con un Worker a través de enlaces de servicio. Se encuentra funcionalmente entre una función de Workers y una máquina virtual en la nube clásica y cubre cargas de trabajo que requieren más tiempo de ejecución, más memoria o una cadena de herramientas Linux completa.
La versión GA trae tres mejoras importantes en comparación con la beta pública. El precio de CPU activa solo factura los ciclos de CPU realmente consumidos, no el tiempo de reloj. Los límites se encuentran en miles de contenedores en ejecución paralela por cuenta. Los enlaces de servicio direccionan contenedores por nombre de host en lugar de por IP, lo que elimina la lógica DNS y el código de descubrimiento del Worker.
Además, se incluyen soporte para Docker Hub para extraer imágenes directamente, SSH para depuración en vivo y sandboxes como producto hermano para cargas de trabajo de agentes de IA con sesiones de sistema de archivos persistentes. Quien tiene un Worker que necesita un navegador sin cabeza para capturas de pantalla o una canalización de Pandoc para PDF, ahora llama a un contenedor a través de enlace de servicio, en lugar de interponer un proveedor de API externo.
Donde se aplica la ventaja de Edge, donde no
Los contenedores no se ejecutan en cada ubicación de Edge, sino que se inician en la región disponible más cercana cuando es necesario. Para aplicaciones web interactivas con usuarios en DACH, esto suele significar Frankfurt o Düsseldorf. Las latencias entre Worker y contenedor se encuentran así en el rango de milisegundos de un solo dígito, y se elimina el salto a un backend clásico en Frankfurt o Dublín. La documentación oficial de la plataforma enumera explícitamente las regiones y límites admitidos.
Donde realmente duele es en el procesamiento de imágenes y PDF. Un Worker que invoca un contenedor con ImageMagick se ahorra un salto a un Lambda o un servicio de renderizado más su inicio en frío. De manera similar, para cargas de trabajo de navegador sin cabeza: Playwright en un contenedor junto al Worker entrega capturas de pantalla en una latencia total de 700 a 1.200 ms, mientras que el desvío a través de un endpoint de navegador sin cabeza externo a menudo necesita el doble.
Lo que los contenedores no reemplazan son servicios de larga duración con su propio estado. Una instancia de Postgres sigue perteneciendo a una plataforma de base de datos, un broker de Kafka a una VM. Los contenedores son efímeros, se apagan cuando están inactivos y se reinician en frío. Quien no tenga esto en cuenta, construirá arquitecturas que sorprenden en la factura a fin de mes.
Workers, contenedores, EC2: qué cuándo
Cuándo los contenedores son adecuados
- Navegador sin cabeza, Pandoc, ffmpeg, Tesseract junto a un Worker
- Endpoints de inferencia pequeños que no caben en una función de Workers AI
- Herramientas CLI que necesitan un Linux completo
- Cargas de trabajo en ráfaga con largas fases de inactividad, gracias a la tarificación por CPU activa
Cuándo no
- Bases de datos u otros servicios de larga duración con estado local
- Cargas de trabajo que necesitan garantías de región fijas (cumplimiento normativo)
- Inferencia con GPU para modelos grandes, aquí queda Workers AI o un proveedor de hyperscale
- Stacks existentes que ya se ejecutan en Kubernetes y están consolidados
Un plan de 60 días para equipos de DACH
Quien quiera examinar seriamente la pila, no comienza con una migración, sino con una carga de trabajo concreta que hoy duele.
Preguntas frecuentes
¿Necesito un plan de Cloudflare de pago para Containers?
Sí, Containers se ejecutan en el Workers Paid Plan, que comienza en 5 US-Dollar al mes. El precio de CPU activa se suma, y se factura con precisión de segundos. Para pruebas puras, el Paid Plan es suficiente, pero para configuraciones productivas con alta carga, Workers Enterprise merece la pena debido a sus mejores límites y SLA de soporte.
¿Puedo utilizar mis imágenes Docker existentes directamente?
En la mayoría de los casos, sí. Cloudflare admite pulls de Docker Hub y registros privados, y se pueden manejar tamaños de imagen de hasta varios gigabytes. Lo que no funciona son imágenes que dependen del modo privilegiado o módulos del kernel especiales, y cargas de trabajo con requisitos de GPU más allá de lo que ofrecen los contenedores de Cloudflare hoy en día.
¿Cómo se comporta la pila con respecto al RGPD y la residencia de datos?
Cloudflare ofrece opciones de afinidad regional, con las que se pueden fijar contenedores en ubicaciones de la UE. Quien necesite una residencia de datos estricta (sector público, bancos) debe verificar la configuración de Enterprise y obtener una garantía por escrito. Las configuraciones estándar se ubican de manera pragmática en Frankfurt o Ámsterdam, lo que es suficiente para la mayoría de las cargas de trabajo de DACH.
Sobre el autor
Adrian Garcia-Kunz es desarrollador web en Evernine. Procede del stack de frontend, pero conoce el punto en el que un Worker o una Lambda ya no es suficiente. No le gusta el teatro de moda en cuanto a stacks, pero sí las herramientas que seguirán funcionando dentro de seis meses.
Más del MBF Media Netzwerk
Más de la red MBF Media
cloudmagazinMini-PCs desplazan a servidores 1HE: Edge en el centro de datos 2026MyBusinessFutureSAP-BPC: La puerta trasera SQL en el balance trimestralDigital ChiefsLa pregunta del 40 por ciento: De dónde viene realmente el presupuesto para IASecurityTodayAuditoría NIS2: Donde la lista de proveedores se rompe en dos horasFuente imagen de título: Generada con Google Imagen 4 Fast, verificada con SynthID
Fuente de imagen: generada por IA (mayo de 2026), certificado C2PA integrado en la imagen
