5 Min. Tiempo de lectura
Quien ha construido sobre Cloudflare Workers conoce la pared: a partir del momento en que el código necesita más de 128 MB de RAM o una verdadera cadena de herramientas de Linux, el despliegue se vuelve feo. Con la disponibilidad general de los contenedores desde el 13 de abril de 2026, Cloudflare está moviendo esta pared. Los desarrolladores web que hasta ahora han recurrido a EC2, Fly.io o Render obtienen una capa de borde intermedia sin clústeres de Kubernetes ni contratos 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 y 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.
- Hostnames, Docker Hub, SSH: Los Workers hablan con los contenedores a través de enlaces de servicio, las imágenes provienen de Docker Hub o un registro, SSH funciona para depuración en vivo. La pila se siente como un Linux clásico, no como una sandbox de borde.
- Brecha entre Workers y EC2: Para navegadores sin cabeza, ffmpeg, Pandoc o pequeños puntos finales de inferencia, Workers eran demasiado pequeños y EC2 demasiado pesados. Los contenedores llenan exactamente esta capa media y reducen el salto de pila a un solo proveedor.
Relacionado:Mini-PCs desplazan servidores 1HE: Edge en el centro de datos 2026 / Documentación de Cloudflare Containers
Qué trae consigo la disponibilidad general de los contenedores
¿Qué es un contenedor de Cloudflare? Un contenedor de Cloudflare es un contenedor de Linux de corta duración 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 Worker 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 de Linux completa.
La versión de disponibilidad general trae tres mejoras importantes con respecto a la beta pública. El precio de CPU activa solo factura los ciclos de CPU realmente consumidos, no el tiempo de reloj de pared. Los límites están en miles de contenedores en ejecución paralela por cuenta. Los enlaces de servicio direccionan los 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.
A esto se suman el soporte de Docker Hub para extracción directa de imágenes, SSH para depuración en vivo y sandbox como producto hermano para cargas de trabajo de agentes de IA con sesiones de sistema de archivos persistentes. Quien tenga un Worker que necesite 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 un enlace de servicio en lugar de intercalar un proveedor de API externo.
Dónde se aplica la ventaja de Edge, y dónde no
Los contenedores no se ejecutan en todas las ubicaciones de Edge, sino que se inician en la región disponible más cercana según sea necesario. Para aplicaciones web interactivas con usuarios en DACH, esto suele significar Fráncfort o Düsseldorf. Las latencias entre el trabajador y el contenedor están en el rango de los milisegundos de un solo dígito, lo que elimina la necesidad de saltar a un backend clásico en Fráncfort o Dublín. La documentación oficial de la plataforma enumera explícitamente las regiones y límites admitidos.
Donde esto realmente tiene un impacto es en el procesamiento de imágenes y PDF. Un trabajador que invoque 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 trabajador entrega capturas de pantalla en 700 a 1200 ms de latencia total, donde el desvío a través de un punto final de navegador sin cabeza a menudo necesita el doble.
Lo que los contenedores no reemplazan son los servicios de ejecución prolongada con su propio estado. Una instancia de Postgres todavía pertenece a una plataforma de base de datos, un corredor de Kafka en una máquina virtual. Los contenedores son efímeros, se detienen cuando están inactivos y se reinician en frío. Quien no tenga esto en mente, construye arquitecturas que sorprenden en la factura de fin de mes.
Trabajadores, contenedores, EC2: qué y cuándo
Cuándo los contenedores son adecuados
- Navegadores sin cabeza, Pandoc, ffmpeg, Tesseract junto a un trabajador
- Endpoints de inferencia pequeños que no caben en una función de IA de trabajadores
- Herramientas de CLI que necesitan un Linux completo
- Cargas de trabajo de ráfaga con largas fases de inactividad, gracias a la tarificación activa de CPU
Cuándo no
- Bases de datos u otros servicios de ejecución prolongada con estado local
- Cargas de trabajo que necesitan garantías de región fija (cumplimiento)
- Inferencia de GPU para modelos grandes, aquí permanecen los trabajadores de IA o un hyperscaler
- Stacks existentes que ya se ejecutan en Kubernetes y están consolidados
Un plan de 60 días para equipos DACH
Quien quiera examinar la pila en serio, no empieza con una migración, sino con una carga de trabajo concreta que hoy duele.
Preguntas frecuentes
¿Necesito un plan de Cloudflare de pago para contenedores?
Sí, los contenedores funcionan con el plan Workers Paid, que comienza en 5 dólares al mes. El precio de Active-CPU se suma, y se factura con precisión de segundo. Para pruebas puras, el plan Paid es suficiente, pero para configuraciones productivas con alta carga, Workers Enterprise vale la pena debido a mejores límites y acuerdos de nivel de servicio.
¿Puedo utilizar directamente mis imágenes Docker existentes?
En la mayoría de los casos, sí. Cloudflare admite Docker-Hub-Pulls y registros privados, y tamaños de imágenes de hasta varios gigabytes son posibles. Lo que no funciona son imágenes que dependen del modo privilegiado o módulos de kernel específicos, 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 relaciona la pila con el RGPD y la residencia de datos?
Cloudflare ofrece opciones de afinidad regional, con las que los contenedores se pueden fijar en ubicaciones de la UE. Quienes necesitan residencia de datos estricta (sector público, bancos) verifican la configuración de Enterprise y obtienen una confirmación escrita. Las configuraciones estándar se ubican pragmáticamente en Frankfurt o Amsterdam, lo que es suficiente para la mayoría de las cargas de trabajo DACH.
Sobre el autor
Adrian Garcia-Kunz es desarrollador web en Evernine. Viene del stack de frontend, pero conoce el punto en el que un trabajador o una lambda ya no es suficiente. Le importan poco las modas de stack y mucho las herramientas que sigan funcionando dentro de seis meses.
Más del network de MBF Media
Fuente de la imagen del título: Generada con Google Imagen 4 Fast, verificada con SynthID
