¿Por qué importa esta migración?
Browser Run permite a los devs controlar navegadores headless programáticamente en la red global de Cloudflare. Se usa para pruebas end-to-end, investigación de URLs, renderizado de PDF y, cada vez más, como base para agentes de IA que interactúan con la web. Con la explosión de demanda (especialmente de builders de agentes), la infraestructura compartida con Browser Isolation (BISO) se convirtió en un cuello de botella.
Problemas antes de la migración:
- Startup más lento por las imágenes grandes de BISO.
- Distribución global deficiente, causando picos de latencia.
- Conflictos de escala entre sesiones largas de BISO y el uso corto y explosivo de Browser Run.
La solución: construir sobre la propia plataforma de Cloudflare: Contenedores con Durable Objects.
Fuente: Blog oficial de Cloudflare Browser Run
La Migración: Contenedores + DO
El equipo comenzó insertando un Worker en la ruta de las peticiones para dirigir a una parte de los usuarios a Contenedores, manteniendo BISO como fallback. Este enfoque dual permitió comparar rendimiento y aislar bugs.
Desafío Arquitectónico Principal
Los Contenedores con DO crean un Durable Object cerca de la petición, pero el contenedor puede levantarse al otro lado del mundo. Para peticiones de screenshot que intercambian decenas de mensajes WebSocket, esos milisegundos extra se acumulan.
Solución: Pools regionales precalentados de contenedores con DO. Cuando llega una petición, el sistema elige el par DO-contenedor más cercano al usuario dentro de la región.
// Simplificado: elige el mejor contenedor basado en región y latencia
async function pickContainer(userLocation) {
const region = getNearestRegion(userLocation);
const pool = await getWarmPool(region);
// Usa D1 para tomar un contenedor atómicamente
const container = await claimContainer(pool, region);
return container;
}
De KV a D1 + Queues
Inicialmente, el estado de los contenedores se almacenaba en KV. Pero la consistencia eventual de KV (~30s de cache TTL) causaba race conditions: un contenedor marcado como "disponible" podía ya estar ocupado cuando la petición llegaba.
La solución: Migrar a D1 con semántica transaccional SQLite. Aquí está la query de adquisición:
WITH candidate_pool AS (
-- reglas para elegir basado en latencia
)
UPDATE containers
SET status = 'picked'
WHERE sessionId IN (
SELECT sessionId
FROM candidate_pool
ORDER BY RANDOM()
LIMIT ?5
)
RETURNING data;
Writes en Lote para Escalar
Cada contenedor actualiza su estado cada 5 segundos. Con 1ms por write, una instancia D1 solo aguanta ~5.000 contenedores. Agrupando writes via Queues (100 filas por lote), alcanzaron 0.1ms P95, soportando hasta 500.000 contenedores por ubicación.
{
"queues": {
"consumers": [
{
"queue": "production-core-containers-queue-weur",
"max_batch_size": 100,
"max_batch_timeout": 1,
"max_retries": 1
}
]
}
}
Esta arquitectura les dio 4x más navegadores concurrentes (hasta 120) y 50% menos tiempo de respuesta en las Quick Actions.
¿Quieres saber cómo proteger usuarios de enlaces maliciosos? Checa Cómo la Protección Avanzada de Navegación verifica URLs sin comprometer la privacidad.
Beneficios Adicionales y Resultados
Quick Actions Optimizadas
Con contenedores dedicados, el equipo pasó a enviar todos los parámetros en una sola petición HTTP, en lugar de un baile de WebSocket en múltiples pasos. Esto redujo drásticamente el tiempo promedio de respuesta.
Upgrades de Navegador Más Rápidos
Sin depender del cronograma de updates de BISO, ahora lanzan actualizaciones de Chrome y nuevas features (como WebGL y WebMCP) a su propio ritmo.
Limitaciones y Riesgos
- Backlogs en las colas aún pueden causar estado desactualizado. Regiones de fallback mitigan, pero añaden complejidad.
- Sharding de D1 por ubicación requiere planeación cuidadosa de capacidad. El equipo recalca que los writes en lote son esenciales.
- Distancia DO-Contenedor sigue siendo un desafío para operaciones sensibles a latencia, aunque los pools regionales ayudan.
Próximos Pasos
- Sumérgete en la Documentación de Cloudflare Workers para entender DO y D1.
- Experimenta con las Quick Actions de Browser Run para ver las mejoras de rendimiento.
- Explora el Agents SDK si estás construyendo agentes de IA.
Conclusión
El equipo de Browser Run transformó una crisis de escala en una historia de éxito de plataforma. Migrando de la infraestructura compartida de BISO a Contenedores con Durable Objects, y resolviendo el manejo de estado en tiempo real con D1 + Queues, lograron mejoras dramáticas de rendimiento. La lección principal: cuando escalas, sé dueño de tu infraestructura y haz writes en lote.
Si te interesan los agentes de IA autónomos, échale un ojo al REA de Meta: el agente de IA autónomo 5x más productivo en experimentación de ML.