Cloudflare Workers: computo en el edge sin contenedores
Actualizado: 2026-05-03
Cloudflare Workers[1] es la plataforma serverless edge más madura disponible. Ejecuta tu código JavaScript o WebAssembly en más de 300 datacenters globales sin gestionar regiones, contenedores ni cold starts perceptibles. Su arquitectura difiere fundamentalmente de AWS Lambda — y esa diferencia define exactamente dónde brilla y dónde no llega.
Puntos clave
- Workers usa V8 isolates en lugar de contenedores: cold start de 0-5 ms frente a los 100 ms-2 s de Lambda.
- El stack de storage edge (KV, Durable Objects, R2, D1) cubre la mayoría de necesidades sin llamar al origin.
- JavaScript/TypeScript y WebAssembly están soportados; módulos Node.js con bindings nativos, no.
- Para edge logic, A/B testing y proxies inteligentes, Workers es la mejor opción disponible.
- Para workloads CPU-intensivas largas o dependencias npm pesadas, Lambda o un servidor tradicional.
La arquitectura: V8 isolates
AWS Lambda lanza un contenedor (o microVM como Firecracker) para cada función, lo que produce cold starts de 100 ms a varios segundos. Workers usa V8 isolates, la misma tecnología que aísla pestañas en Chrome. Las consecuencias:
- Cold start de 0-5 ms — crear un isolate es mucho más barato que un contenedor.
- Footprint de memoria muy bajo — cientos de Workers coexisten en el mismo proceso.
- Coste muy bajo por invocación — la capa gratuita de Cloudflare es generosa.
- Sin APIs de sistema operativo, threads nativos ni módulos npm con bindings nativos.
Para casos donde el modelo encaja, esto es transformador. Para casos donde no, es bloqueante.
Qué se puede ejecutar
Workers acepta:
- JavaScript ES Modules moderno.
- TypeScript (compilado a JS antes del deploy).
- WebAssembly: Rust, Go (TinyGo), C y AssemblyScript compilados a Wasm, ideal para lógica CPU-intensiva.
No acepta:
- Módulos Node.js con bindings C nativos (sharp, bcrypt nativo, etc.).
- Acceso al filesystem local.
- Spawn de procesos.
- Escucha en sockets TCP arbitrarios (excepto los outbound permitidos).
Storage edge: KV, Durable Objects, R2 y D1
Workers no es solo cómputo — Cloudflare ha construido un stack de storage edge completo:
Workers KV es un almacén key-value distribuido globalmente, eventualmente consistente. Las lecturas son muy rápidas y se cachean en cada datacenter; las escrituras se propagan en segundos. Ideal para configuración, feature flags y cache de respuestas frecuentes.
Durable Objects son objetos con estado consistente y único globalmente. Cada objeto vive en un datacenter y procesa todas las requests de esa instancia secuencialmente. Son el patrón correcto para sesiones de usuario, salas de chat y contadores precisos.
R2 es object storage compatible con S3 pero sin egress fees — una ventaja real frente a S3 cuando sirves contenido directamente a Internet.
D1 es una base de datos SQLite distribuida (en maduración). Permite queries SQL para apps edge con lecturas desde réplicas locales y escrituras hacia una región primaria.
Esta combinación cubre la mayoría de necesidades de aplicaciones edge sin llamar a un origin tradicional.
Casos donde Workers brilla
El modelo encaja perfectamente para:
- Edge logic en frontend: routing inteligente, A/B testing, redirects basados en geo o bot detection.
- API gateway personalizado: validar tokens, rate limiting, transformar requests antes de enviarlas al origin.
- APIs simples sin backend tradicional: CRUD ligero con KV o D1.
- Streaming y procesamiento de respuestas: transformar el response del origin en el edge.
- Webhooks de alto throughput: reciben muchas requests por segundo a coste mínimo.
- Proxies inteligentes: Workers delante de un origin añadiendo cache, auth y telemetría.
Casos donde no es la herramienta
- APIs con dependencias npm pesadas: Workers no soporta gran parte del ecosistema Node nativo.
- Workloads CPU-intensivas largas: hay límites de tiempo de CPU por request.
- Long-running tasks: Workers están diseñados para responder rápido, no para procesos largos.
- Datos transaccionales fuertes: KV es eventualmente consistente; las garantías ACID son más débiles que Postgres.
- Workloads con estado complejo: Durable Objects ayudan pero no resuelven todo.
| Aspecto | Workers | AWS Lambda | Vercel/Netlify |
|---|---|---|---|
| Cold start | ~0-5 ms | 100 ms-2 s | Similar a Lambda |
| Distribución global | 300+ datacenters | Por región AWS | Edge en algunos casos |
| Lenguajes | JS/TS/Wasm | Casi todos | Mayormente JS/TS |
| Storage edge integrado | Sí | No | Limitado |
| Soporte Node.js completo | Limitado | Completo | Completo |
Workflow de desarrollo
Cloudflare ha invertido en developer experience. La CLI wrangler gestiona el ciclo completo: wrangler dev ofrece desarrollo local con hot reload y simulación de KV y Durable Objects; el deploy es prácticamente instantáneo; wrangler tail muestra logs en vivo. El loop de iteración es mucho más rápido que desplegar Lambda + API Gateway + IAM + CloudFront.
Relacionado: si tu arquitectura combina Workers con Kubernetes en el backend, la guía sobre service mesh es relevante. Y para seguridad en el pipeline que construye y despliega los Workers, Sigstore y cosign cubren la firma de artefactos.
Conclusión
Cloudflare Workers ha consolidado el edge serverless como categoría madura. Para casos que encajan con el modelo — JavaScript o WebAssembly, lógica corta, storage edge — es la mejor opción disponible: más rápida, más barata y más distribuida que las alternativas. Para casos que no encajan, no fuerces el modelo. La clave es identificar cuándo el edge aporta y cuándo un servidor tradicional o Lambda sigue siendo la respuesta correcta.
