Willy: El capítulo de hoy es: CloudFlare: Plataforma de desarrollo.

Willy: Patty, hoy llegamos al corazón de programar en Cloudflare: la Developer Platform. La idea es ejecutar código y guardar datos en su red global sin administrar servidores. Y ojo: todo depende del plan Workers, Free o Paid, no del plan que tenga la zona del dominio.

Patty: Ah, o sea que puedo tener un dominio en cierto plan y, por separado, elegir cómo pago Workers. ¿Pero qué es exactamente un Worker?

Willy: Es una función que responde a una petición HTTP o a un evento programado y se ejecuta cerca del usuario. No levanta una máquina virtual ni un contenedor: usa isolates de V8, el motor de Chrome. Son entornos ligeros que arrancan prácticamente al instante.

Patty: Como abrir una ventanilla justo donde llega el cliente, en vez de mandarlo hasta un servidor en otro continente. ¿Con qué se programa?

Willy: Normalmente con JavaScript o TypeScript, aunque Rust y Python pueden llegar mediante WebAssembly. Despliegas con wrangler deploy a un subdominio workers.dev o a una ruta de tu dominio. El Worker puede servir HTTP, consumir Queues, ejecutarse con Cron Triggers o recibir llamadas de otro Worker mediante Service Bindings.

Patty: ¿Y si necesita datos, secretos o una base de datos?

Willy: Le conectas bindings: KV, D1, R2, Durable Objects, variables de entorno y secretos. Se declaran en wrangler.toml o wrangler.jsonc. Es como darle al código enchufes directos a los servicios que necesita.

Patty: Hablemos de límites, porque ahí suelen aparecer las sorpresas. En Free hay cien mil peticiones diarias y solo diez milisegundos de CPU por invocación, ¿verdad?

Willy: Sí. Diez milisegundos de CPU parecen poquísimos, pero no cuentan el tiempo esperando una base de datos o un fetch. Además, cada isolate tiene 128 megabytes de memoria. Free permite 50 subpeticiones por invocación, seis conexiones salientes simultáneas, 100 Workers, cinco cron y 64 variables de entorno. El Worker puede ocupar hasta 64 MiB sin comprimir.

Patty: En Paid cambia bastante: peticiones sin límite duro, con diez millones mensuales incluidas y luego treinta centavos por millón; 30 segundos de CPU por defecto, configurables hasta cinco minutos; diez mil subpeticiones, 500 Workers y 250 cron. La memoria y las seis conexiones simultáneas, en cambio, siguen iguales.

Willy: También hay límites compartidos: arranque máximo de un segundo, URL de 16 KB, cabeceras de 128 KB y hasta 256 KB de logs por petición. El cuerpo permitido depende del plan de zona: 100 MB en Free o Pro y 200 MB en Business.

Patty: ¿Y el tiempo total? Porque CPU y duración real no son lo mismo.

Willy: Exacto. Una petición HTTP puede seguir viva mientras el cliente permanezca conectado. Pero cron, consumidores de colas y alarmas de Durable Objects tienen un máximo de 15 minutos. Y con ctx.waitUntil puedes responder primero y continuar hasta 30 segundos, por ejemplo para guardar analíticas.

Patty: Si te pasas de cien mil peticiones en Free aparece el error 1027. Si excedes CPU o memoria, aparece el 1102; en métricas puedes distinguir exceededCpu de exceededMemory.

Willy: En resumen, frente a un VPS que vive encendido en un datacenter y exige escalado manual, Workers arranca bajo demanda, corre cerca del usuario en más de 300 ciudades y escala solo. Y si no hay tráfico, no pagas capacidad ociosa. Es menos administrar máquinas y más concentrarse en la lógica.

Willy: Soy Willy. Hoy seguimos con Cloudflare y una advertencia importante: aunque una variable global puede sobrevivir entre peticiones dentro de un isolate de Worker, no debes usarla como almacenamiento fiable.

Patty: Soy Patty. Ah, o sea que puede parecer que el dato sigue ahí, pero Cloudflare puede reciclar ese isolate o atender la siguiente petición en otro distinto.

Willy: Exacto. Para contenido web tenemos Pages. Es hosting para archivos estáticos ya compilados: HTML, CSS y JavaScript, por ejemplo el build de React o Vite. Puedes desplegar desde Git automáticamente o ejecutar wrangler pages deploy.

Patty: ¿Y cada visita consume la cuota diaria de Workers?

Willy: No si solo entrega archivos estáticos: esas peticiones son gratuitas e ilimitadas. Pero si añades Pages Functions, como código dentro de la carpeta functions o un Worker asociado, esas ejecuciones sí se facturan como Workers. En Free comparten el límite habitual de cien mil solicitudes diarias.

Patty: ¿Qué tan grande puede ser un proyecto?

Willy: En Free admite veinte mil archivos; en pago, cien mil. Cada archivo puede pesar hasta veinticinco mebibytes. Hay hasta cien proyectos por cuenta, un límite separado del de Workers.

Patty: Y si hago muchos push, ¿me quedo sin builds?

Willy: En Free tienes quinientas compilaciones mensuales y una simultánea. Pro ofrece cinco mil y cinco simultáneas; Business, veinte mil y veinte. Cada build puede durar como máximo veinte minutos. Las vistas previas son ilimitadas: cada push genera una URL única e inmutable en pages.dev, mientras la rama de producción conserva su dirección principal.

Patty: También están los dominios y las reglas, ¿no?

Willy: Sí. Free permite cien dominios personalizados por proyecto; los planes pagos llegan aproximadamente a entre doscientos cincuenta y quinientos. En _redirects caben dos mil reglas estáticas y cien dinámicas, y en _headers, cien reglas.

Patty: Ojo: eso es Pages. Compilar Workers normales desde Git usa Workers Builds.

Willy: Correcto. Su cuota gratuita separada es de tres mil minutos al mes, un build concurrente y máquinas con dos vCPU, ocho gigabytes de RAM y veinte de disco.

Patty: Pasemos a Workers KV. Yo lo imaginaría como un diccionario global: una clave apunta a un valor.

Willy: Buena imagen. Se organiza en namespaces, parecidos a colecciones. Desde un Worker puedes hacer get, put, delete o list; también poner expiración con expirationTtl. Está distribuido y optimizado para lectura, así que funciona bien para configuración, sesiones o JSON pequeño que cambia poco.

Patty: Pero tiene consistencia eventual: una escritura puede tardar hasta sesenta segundos en verse en todas las regiones.

Willy: Esa es la trampa que afectó a Racing Ecuador. Si guardas todo el estado en una única clave y varias peticiones lo actualizan, no hay transacciones: solo se permite una escritura por segundo sobre esa clave y termina ganando la última. Para contadores exactos o concurrencia, usa Durable Objects.

Patty: ¿Cuáles son las cuotas gratuitas principales?

Willy: Cien mil lecturas diarias, pero solo mil escrituras, mil eliminaciones y mil listados. Hay hasta mil operaciones KV por invocación y mil namespaces. El almacenamiento gratuito es de un gigabyte; cada clave llega a 512 bytes y cada valor a veinticinco mebibytes. Además, el cacheTtl mínimo es de treinta segundos.

Patty: En resumen: Pages sirve archivos estáticos a gran escala; Functions añade cómputo, y KV aporta lecturas globales rápidas, pero no reemplaza una base transaccional.

Willy: Patty, retomemos el problema del ranking guardado entero dentro de una sola clave de KV. Si dos usuarios actualizan casi al mismo tiempo, ambos pueden leer la versión anterior y el último guardado termina pisando al primero.

Patty: Ah, o sea que es como si dos personas editaran el mismo archivo y una sobrescribiera los cambios de la otra. Y además ese JSON va creciendo.

Willy: Exacto. Cada lectura obliga al Worker a parsear un JSON grande, y cada escritura a serializarlo de nuevo. Eso consume CPU y puede acercarnos al límite de 10 milisegundos. Para datos que crecen y cambian seguido, la recomendación es D1; KV queda mejor para configuración o caché principalmente de lectura.

Patty: ¿Y D1 sería la base SQL de Cloudflare?

Willy: Sí. Es SQLite gestionado en el borde, con réplicas de lectura distribuidas. Vendría a ocupar el lugar de MySQL o Postgres cuando buscas algo sencillo y serverless. Creas la base con wrangler d1 create, aplicas migraciones con wrangler d1 migrations apply y consultas desde el Worker con prepare, bind y, por ejemplo, first.

Patty: Entonces puedo usar parámetros, algo como seleccionar un usuario por id, sin concatenar valores manualmente.

Willy: Correcto. También tiene Time Travel: puedes recuperar la base a un punto anterior sin preparar backups manuales. La ventana es de siete días en Free y treinta en Paid.

Patty: ¿Qué tan generoso es el plan gratuito?

Willy: Incluye cinco millones de filas leídas y cien mil escritas por día, cinco gigabytes totales, hasta diez bases de datos y quinientos megabytes por base. En Paid se incluyen veinticinco mil millones de lecturas y cincuenta millones de escrituras al mes; permite cincuenta mil bases y hasta diez gigabytes por base. Los excedentes cuestan 0,001 dólares por millón de lecturas, un dólar por millón de escrituras y 0,75 por gigabyte-mes.

Patty: Pero una fila leída no necesariamente es una fila que recibo, ¿verdad?

Willy: Exactamente. Si buscas usuarios por created_at sin índice, D1 puede escanear toda la tabla aunque devuelva tres resultados. Todo lo escaneado cuenta. Un índice reduce cuota, costo y tiempo. Además, cada invocación admite cincuenta consultas en Free o mil en Paid; una consulta puede durar hasta treinta segundos. Hay cien columnas por tabla, filas ilimitadas y un máximo de dos megabytes por fila, string o BLOB. No se cobra egress ni extra por réplicas.

Patty: ¿Y para imágenes, videos o backups usamos D1 también?

Willy: No, ahí entra R2, el almacenamiento de objetos compatible con S3. Su gran ventaja es que la salida a Internet siempre es gratis. La cuota mensual incluye diez gigabytes-mes, un millón de operaciones Clase A, como escribir o listar, y diez millones Clase B, como leer o consultar metadatos.

Patty: ¿Y después de esa cuota?

Willy: En Standard: 0,015 dólares por gigabyte-mes, 4,50 por millón de operaciones Clase A y 0,36 por millón de Clase B. También existe Infrequent Access: almacenamiento más barato, pero operaciones más caras. Cada objeto puede medir hasta cinco tebibytes. En resumen: D1 para datos estructurados y cambiantes; R2 para archivos; KV para valores pequeños, configuración y caché.

Willy: Patty, terminemos R2 con algunos límites prácticos. Una cuenta puede tener hasta un millón de buckets y cada clave de objeto puede medir 1.024 bytes. O sea, difícilmente te quedarás corto por cantidad de buckets.

Patty: ¿Y por tamaño de archivo? Porque ahí suele estar la pregunta importante.

Willy: Una subida normal, en una sola parte, admite hasta 5 GiB. Con subida multipartes puedes llegar a 4,995 TiB. Eso sí: si varios procesos intentan escribir exactamente el mismo objeto, el límite es una escritura por segundo.

Patty: Ah, o sea que R2 encaja para videos, PDFs o paquetes de assets grandes, especialmente cuando superan los 25 MiB que permite un archivo de Pages.

Willy: Exacto. También para servir archivos públicos mediante r2.dev o un dominio propio; puedes asociar hasta cien dominios personalizados por bucket. Y cobra especial sentido si calculaste que el tráfico de salida sería caro en otro proveedor.

Patty: Ahora, Durable Objects. ¿Qué cambia frente a un Worker normal?

Willy: Un Worker es stateless y puede ejecutarse en paralelo. En cambio, un Durable Object es una instancia única con nombre y procesa un solo hilo de ejecución a la vez para ese nombre. Por ejemplo, “sala-ABCDE”. Así mantienes orden y consistencia fuerte.

Patty: Como darle un único árbitro a cada sala de juego.

Willy: Tal cual. Ese árbitro puede coordinar chats, partidas, documentos colaborativos, contadores exactos o locks. Cada instancia tiene su ID y almacenamiento privado en SQLite. Además, todos los WebSockets de una sala pueden conectarse al mismo objeto.

Patty: ¿SQLite es ya la opción recomendada?

Willy: Sí. Desde 2024–2025 es el backend recomendado. El backend key-value anterior solo continúa para cuentas que ya lo tenían y no está disponible en Free.

Patty: ¿Qué incluye el plan gratuito?

Willy: Cien mil peticiones diarias, contando HTTP, RPC, mensajes WebSocket y alarmas; además, 13.000 GB-segundo de duración de cómputo al día. En SQL tienes cinco millones de filas leídas y cien mil escritas por día, igual que D1, y 5 GB totales.

Patty: ¿Y en Paid?

Willy: Incluye un millón de peticiones mensuales y luego 0,15 dólares por millón. Para cómputo, 400.000 GB-segundo al mes y después 12,50 dólares por millón. El almacenamiento total no tiene límite; desde enero de 2026 cuesta 0,20 dólares por GB-mes.

Patty: ¿Hay límites por objeto?

Willy: Diez GB de almacenamiento por instancia, objetos ilimitados y mensajes WebSocket recibidos de hasta 32 MiB. Puedes crear cien clases en Free o quinientas en Paid. La CPU por petición es de 30 segundos por defecto, configurable hasta cinco minutos.

Patty: Y si una sala queda quieta, ¿sigue consumiendo?

Willy: Puede hibernar: sale de memoria, conserva las conexiones WebSocket y no cobra duración mientras duerme. Ojo: cada setAlarm, es decir, cada temporizador, cuenta como una fila escrita.

Patty: Entonces, resumen mental: KV para configuración o caché de muchas lecturas; D1 para datos relacionales, reportes y escrituras; Durable Objects para estado vivo con un dueño lógico; y R2 para archivos grandes.

Willy: Exacto. Y si quieres desacoplar tareas, entran Queues: un Worker productor publica mensajes y otro consumidor los procesa por lotes, con reintentos automáticos.

Patty: Como recibir pedidos ahora y generar las facturas después, sin bloquear al usuario.

Willy: Sí. La facturación es por operación: cada bloque de 64 KB escrito, leído o eliminado cuenta como una operación.

Willy: Patty, sigamos con las herramientas de Cloudflare para montar aplicaciones más completas. Empecemos por las colas de mensajes: en el plan Free tienes diez mil operaciones diarias y los mensajes se conservan durante veinticuatro horas.

Patty: ¿Y puedo ampliar esa retención sin cambiar de plan?

Willy: No. En Free esas veinticuatro horas son fijas. En Paid puedes configurarla hasta catorce días. Y ojo con el cálculo: entregar un mensaje normalmente consume tres operaciones, una para escribirlo, otra para leerlo y otra para eliminarlo.

Patty: Ah, o sea que diez mil operaciones no equivalen necesariamente a diez mil mensajes completos; serían alrededor de tres mil trescientos si cada uno recorre el ciclo normal.

Willy: Exacto. Luego están los Workflows, pensados para orquestar procesos durables de varios pasos. Por ejemplo: cobrar un pago, esperar una confirmación y, cuando llegue, enviar un correo. El proceso puede sobrevivir reinicios, reintentos y esperas largas.

Patty: Eso evita programar a mano toda la lógica de “me quedé a mitad, ¿por dónde continúo?”. ¿Qué incluye Free?

Willy: Cien mil peticiones diarias compartidas con Workers, diez milisegundos de CPU por invocación, un gigabyte-mes de almacenamiento y tres mil pasos al día.

Patty: ¿Y para ejecutar algo cada noche, como limpiar registros?

Willy: Ahí usarías Cron Triggers. Ejecutan un Worker según una expresión cron, sin recibir una petición HTTP. Free permite cinco disparadores por cuenta y Paid, doscientos cincuenta. Cada ejecución puede durar como máximo quince minutos de tiempo real.

Patty: Ahora, si mi Worker consulta un Postgres o MySQL que ya existe fuera de Cloudflare, ¿cómo evito abrir una conexión nueva constantemente?

Willy: Con Hyperdrive: funciona como pool de conexiones y caché de consultas. No es una base de datos, sino un proxy acelerador hacia la tuya. Free ofrece cien mil consultas diarias; en Paid son ilimitadas.

Patty: Pasemos a IA. Workers AI permite ejecutar modelos de texto, imagen, voz o embeddings sin administrar GPUs, ¿verdad?

Willy: Sí. El consumo se mide en “neuronas”. Hay diez mil neuronas gratis al día tanto en Free como en Paid. Si te pasas, Free falla; en Paid cuesta 0,011 dólares por cada mil neuronas adicionales. Además, algunos modelos grandes, como Kimi K2, GLM o DeepSeek, requieren un método de pago activo incluso usando Free.

Patty: ¿Y AI Gateway ejecuta esos modelos?

Willy: No exactamente. Es una capa de proxy y observabilidad para llamadas a servicios propios o de terceros, como OpenAI o Anthropic. Aporta caché, límites, analítica y reintentos. Sus funciones núcleo —dashboard, caché y rate limiting— son gratuitas en todos los planes.

Patty: Para RAG necesitaríamos guardar embeddings.

Willy: Eso es Vectorize, la base vectorial para búsqueda semántica. Solo está disponible en Workers Paid e incluye treinta millones de dimensiones consultadas al mes y cinco millones almacenadas.

Patty: También podemos controlar un Chrome real con Browser Rendering: capturas, PDFs, scraping y automatización con Puppeteer o Playwright.

Willy: Correcto. Free da diez minutos de navegador al día y hasta tres navegadores concurrentes. Paid incluye diez horas mensuales, cobra 0,09 dólares por hora adicional y permite diez concurrentes.

Patty: Terminemos con Images.

Willy: Puedes transformar imágenes alojadas en cualquier lugar: redimensionar o convertir formato. Hay cinco mil transformaciones únicas gratis al mes en ambos planes. Al superar el límite, las nuevas devuelven el error 9422, aunque las ya cacheadas continúan sirviéndose. En cambio, almacenar y servir imágenes directamente desde Cloudflare Images requiere Paid.

Willy: Patty, hoy toca la parte más operativa del ecosistema de Cloudflare. Empecemos por Analytics Engine: imagina que tu Worker genera métricas propias, como tiempos de respuesta, compras o vueltas completadas en una carrera. Escribes esos puntos de datos y luego los consultas con SQL.

Patty: Ah, o sea que no son solo las métricas estándar del dashboard. En el plan Free puedo guardar mi propia telemetría: hasta cien mil puntos escritos al día y diez mil consultas de lectura diarias. Aunque hay un matiz: Cloudflare dice que actualmente no cobra el servicio; los precios publicados son orientativos para cuando comience la facturación.

Willy: Y si necesito investigar qué hizo el Worker, están Workers Logs. Son logs estructurados, con búsqueda y filtros desde el dashboard. Free permite doscientos mil eventos diarios y los conserva tres días. En Paid se incluyen veinte millones al mes y siete días de retención.

Patty: Suficiente para detectar, por ejemplo, por qué falló una inscripción ayer. Ahora, para audio y video en vivo está Realtime, con infraestructura WebRTC, SFU y TURN. Los primeros mil gigabytes mensuales de tráfico son gratuitos y se comparten entre SFU y TURN.

Willy: ¿Y subir el video también consume esa cuota?

Patty: No: el tráfico entrante, es decir, publicar audio o video, siempre es gratis. Se contabiliza la salida hacia los espectadores. Y RealtimeKit, antes llamado Cloudflare Calls, es la capa de más alto nivel, con SDK completo. Tiene límites propios, así que conviene consultar su página específica.

Willy: Pasemos a Agents. Es un framework para bots o agentes de IA que necesitan memoria y estado, algo parecido a un Durable Object especializado. Cada agente puede almacenar hasta un gigabyte y dispone de treinta segundos de cómputo por petición o mensaje; el tiempo se renueva con cada entrada nueva.

Patty: Y la escala es enorme: una cuenta puede llegar a tener decenas de millones de agentes concurrentes. Luego están Pipelines, todavía en beta, para recibir streams de eventos, transformarlos con SQL y enviarlos, por ejemplo, a R2 como Parquet o Iceberg.

Willy: Eso ya exige Workers Paid. Ingresar datos al stream es gratis, pero se cobran la transformación SQL y la salida al destino; el plan incluye cincuenta gigabytes mensuales de cada concepto.

Patty: También hay servicios exclusivamente de pago: Containers para ejecutar Docker; Stream, como un YouTube privado; Vectorize y Email Sending. Y en seguridad avanzada aparecen Advanced Certificate Manager, Keyless SSL, Bot Management completo y WAF avanzado, normalmente como complemento o en planes Business y Enterprise.

Willy: La clave para combinar todo son los bindings. En wrangler.toml o wrangler.jsonc declaras los recursos y, dentro del Worker, aparecen como propiedades de env: env.KV, env.DB, env.ASSETS o env.ROOM_DO. Es el patrón usado, por ejemplo, en Racing Ecuador.

Patty: Y con Service Bindings un Worker llama directamente a otro de la misma cuenta, sin salir a Internet. No hay un coste adicional por petición; solo se cobra el CPU consumido en ambos. En resumen, puedes ensamblar almacenamiento, métricas, tiempo real e IA como piezas internas de una misma aplicación.

Willy: Creado por wrcp20@gmail.com. Sígueme para más contenido.