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

Willy: Patty, hoy toca el 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 una zona en un plan y contratar Workers por separado. ¿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. Usa isolates de V8, el motor de Chrome, en lugar de levantar una máquina virtual o un contenedor. Por eso el inicio real suele ser rapidísimo, aunque la plataforma establece un límite de startup de un segundo.

Patty: Como tener pequeñas funciones repartidas por más de trescientas ciudades. ¿Con qué se escriben?

Willy: Normalmente con JavaScript o TypeScript; también puedes usar Rust o Python compilados a WebAssembly. Despliegas con wrangler deploy y publicas en workers.dev o en una ruta de tu dominio.

Patty: ¿Solo atienden páginas y APIs?

Willy: No. Pueden consumir Queues, ejecutarse mediante Cron Triggers o recibir llamadas de otro Worker usando Service Bindings. Además, les conectas recursos mediante bindings: KV, la base SQL D1, almacenamiento R2, Durable Objects, variables y secretos. Todo se declara en wrangler.toml o wrangler.jsonc.

Patty: Vale. ¿Hasta dónde llega el plan gratuito?

Willy: Incluye cien mil peticiones diarias, hasta cien Workers y cinco tareas cron. Cada invocación dispone de 128 megabytes de memoria y solo diez milisegundos de CPU. Parece poquísimo, pero esperar una respuesta de red no consume CPU continuamente.

Patty: Ah, entonces CPU no es lo mismo que tiempo total.

Willy: Exacto. Una petición HTTP puede seguir viva mientras el cliente permanezca conectado. Cron, consumidores de colas y alarmas de Durable Objects tienen hasta quince minutos. Y con ctx.waitUntil puedes continuar hasta treinta segundos después de responder; por ejemplo, entregas la página enseguida y luego guardas analíticas.

Patty: ¿Y el plan Paid?

Willy: No limita el número de peticiones: incluye diez millones al mes y después cuesta treinta centavos por millón. Ofrece treinta segundos de CPU por defecto, configurables hasta cinco minutos, quinientos Workers y doscientos cincuenta cron. La memoria sigue siendo de 128 megabytes.

Patty: ¿Hay otros topes prácticos?

Willy: Sí. En Free tienes cincuenta subpeticiones y cincuenta llamadas a Cache API por invocación; en Paid suben a diez mil y mil. Ambos permiten seis conexiones salientes simultáneas, Workers de hasta 64 MiB y 256 KB de logs por petición. Las cabeceras llegan a 128 KB y la URL a 16 KB. El cuerpo depende del plan de zona: 100 MB en Free o Pro y 200 MB en Business.

Patty: ¿Qué ocurre si me paso?

Willy: Superar las cien mil peticiones diarias produce el error 1027. Pasarte de CPU o memoria genera el 1102; en Metrics aparece como exceededCpu o exceededMemory.

Patty: Entonces, frente a un VPS, no pago una máquina encendida todo el día, ni configuro escalado o balanceadores.

Willy: Exacto: el VPS vive en un datacenter fijo y cuesta incluso en reposo. Workers arranca bajo demanda, se ejecuta cerca del usuario, escala automáticamente y, si no hay tráfico, no hay cómputo que pagar.

Willy: Soy Willy. Hoy seguimos con Cloudflare y una advertencia rápida: aunque una variable global de un Worker puede sobrevivir entre peticiones, ese estado no está garantizado. El isolate puede reciclarse en cualquier momento.

Patty: Soy Patty. Ah, o sea que una variable global puede servir como caché oportunista, pero no como base de datos ni como contador fiable.

Willy: Exactamente. Ahora sí: Pages. Es el hosting de Cloudflare para sitios estáticos, por ejemplo el resultado ya compilado de React o Vite. Puedes conectarlo a Git para desplegar automáticamente o subirlo con wrangler pages deploy.

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

Willy: Si solo entrega HTML, CSS, JavaScript o imágenes, no. Las peticiones a archivos estáticos son gratuitas e ilimitadas. Pero si añades Pages Functions, como código dentro de la carpeta functions, esas ejecuciones sí se cobran y limitan como Workers; en Free, comparten el límite de cien mil solicitudes diarias.

Patty: Entonces conviene separar mentalmente el escaparate estático de la lógica dinámica. ¿Qué límites tiene el escaparate?

Willy: En Free admite veinte mil archivos por sitio; en pago, cien mil. Cada archivo puede pesar hasta veinticinco MiB. Hay cien proyectos por cuenta, un límite separado del de Workers. También tienes quinientos builds mensuales gratis, frente a cinco mil en Pro y veinte mil en Business.

Patty: ¿Y pueden compilarse varios a la vez?

Willy: Uno en Free, cinco en Pro y veinte en Business; 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 mantiene su URL principal. Además, hay hasta cien dominios personalizados por proyecto en Free, dos mil redirecciones estáticas más cien dinámicas, y cien reglas de headers.

Patty: Ojo: eso es Pages. Los builds de Workers normales tienen otra bolsa: tres mil minutos gratuitos al mes, una compilación simultánea y máquinas de dos vCPU, ocho gigas de RAM y veinte de disco.

Willy: Pasemos a Workers KV. Imagínalo como un diccionario global: una clave apunta a un valor. Está optimizado para lecturas y se replica por distintas regiones, así que encaja con configuración, sesiones o JSON pequeño que cambia poco.

Patty: Un namespace sería como una colección. Desde el Worker usamos get, put, delete y list; además, put puede llevar expirationTtl para que el dato caduque.

Willy: Sí, pero KV tiene consistencia eventual: una escritura puede tardar hasta sesenta segundos en aparecer en todas partes. Por eso no sirve para contadores exactos, reservas de la última entrada o control de concurrencia. Para eso, Durable Objects.

Patty: ¿Qué ofrece el plan gratuito?

Willy: Cien mil lecturas diarias, pero solo mil escrituras, mil eliminaciones y mil operaciones list. Permite mil operaciones KV por invocación, mil namespaces y un GB total. Las claves llegan a 512 bytes, los valores a veinticinco MiB y el cacheTtl mínimo es de treinta segundos.

Patty: Y está la trampa que afectó a Racing Ecuador: guardar todo el estado en una sola clave.

Willy: Claro. Solo puedes escribir una vez por segundo sobre la misma clave, KV no es transaccional y, si dos procesos actualizan a la vez, gana la última escritura. Es como dos personas editando una misma nota: una puede borrar sin querer los cambios de la otra. Mejor repartir los datos entre claves o usar Durable Objects cuando necesitas coordinación fuerte.

Willy: Patty, retomemos el problema de guardar todo un ranking en una sola clave de KV, como un JSON gigante llamado “db”. Parece práctico, ¿no?

Patty: Sí, hasta que llegan dos actualizaciones al mismo tiempo. Ambas leen la versión anterior, hacen cambios y guardan; la última puede pisar a la otra. Además, cada operación obliga al Worker a parsear y serializar todo el JSON.

Willy: Ah, o sea que aunque solo cambie la puntuación de una persona, proceso el ranking completo. Y eso puede acercarme al límite de 10 milisegundos de CPU.

Patty: Exacto. Por eso KV encaja mejor con configuración o caché que se lee mucho y cambia poco. Para datos crecientes, con escrituras frecuentes, la opción natural es D1.

Willy: D1 es la base SQL de Cloudflare, basada en SQLite y con réplicas de lectura distribuidas. Vendría a ser una alternativa sencilla y serverless a MySQL o Postgres.

Patty: Y el flujo es familiar: creas la base con Wrangler, aplicas migraciones SQL y consultas desde el Worker. Por ejemplo, preparas un SELECT por identificador, enlazas el valor con bind y pides la primera fila.

Willy: También tiene Time Travel: puedes recuperar la base a un punto anterior sin gestionar backups manuales. Son siete días en Free y treinta en Paid.

Patty: En el plan gratuito tienes 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 sube a cincuenta mil bases y diez gigabytes por base.

Willy: ¿Y las consultas desde un Worker?

Patty: Hasta cincuenta por invocación en Free y mil en Paid. Una consulta puede durar como máximo treinta segundos. Además, hay cien columnas por tabla, sin límite de filas, y cada fila, string o BLOB puede ocupar hasta dos megabytes.

Willy: Importante: “filas leídas” no significa “filas devueltas”. Si busco usuarios por fecha sin índice, quizá obtenga tres resultados, pero SQLite tuvo que recorrer toda la tabla.

Patty: Así que un índice no solo mejora velocidad: reduce consumo y costo. En Paid se incluyen veinticinco mil millones de lecturas y cincuenta millones de escrituras mensuales; luego se cobra por uso adicional. El almacenamiento incluye cinco gigabytes. No hay cobro de egress ni extra por las réplicas de lectura.

Willy: Perfecto para datos estructurados. ¿Y para imágenes, videos o backups?

Patty: Ahí entra R2, el almacenamiento de objetos compatible con S3. Su gran ventaja es que la salida de datos a Internet siempre es gratuita. En S3, ese egress puede convertirse en la parte más cara.

Willy: La cuota mensual gratuita incluye diez gigabytes-mes, un millón de operaciones Clase A —como escribir o listar— y diez millones de Clase B, como leer o consultar metadatos.

Patty: Después, el nivel Standard cuesta 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.

Willy: ¿Algún límite importante?

Patty: Cada objeto puede alcanzar cinco tebibytes. En resumen: D1 para registros consultables y actualizados con frecuencia; R2 para archivos; y KV para configuración o caché. Elegir según el patrón de acceso evita pisadas, CPU desperdiciada y facturas inesperadas.

Willy: Patty, cerramos R2 con algunos límites importantes. Puedes tener hasta un millón de buckets por cuenta y las claves de los objetos pueden medir hasta 1.024 bytes.

Patty: O sea, capacidad de sobra para organizar archivos. ¿Y qué tan grandes pueden ser?

Willy: Una subida simple llega a 5 GiB. Con subida multiparte, el objeto puede alcanzar 4,995 TiB. Eso sí: al escribir concurrentemente sobre el mismo objeto, el límite es una escritura por segundo. Y cada bucket admite hasta cien dominios personalizados.

Patty: Entonces R2 encaja cuando Pages se queda corto: videos, PDFs o paquetes de assets mayores de 25 MiB. También para servir archivos públicos mediante r2.dev o un dominio propio.

Willy: Exacto. Y especialmente si calculaste que otro proveedor te cobraría mucho por tráfico de salida. Ahora pasemos a Durable Objects, que resuelven un problema distinto: estado con consistencia fuerte.

Patty: Un Worker normal no guarda estado y puede ejecutarse en paralelo. ¿Qué cambia aquí?

Willy: Cada Durable Object es una única instancia identificada por un nombre, por ejemplo, sala-ABCDE. Para ese nombre solo procesa un hilo de ejecución a la vez y tiene almacenamiento SQLite privado. Por eso sirve para chats, juegos online, locks y contadores exactos.

Patty: Ah, o sea que todos los jugadores de una carrera pueden conectarse por WebSocket al mismo objeto, como si fuera el árbitro único de esa sala.

Willy: Tal cual. El backend recomendado desde 2024 y 2025 es SQLite. El backend key-value anterior solo permanece en 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; 13.000 GB-segundo de cómputo al día; cinco millones de filas leídas y cien mil escritas. Además, 5 GB totales, cien clases y objetos ilimitados. Cada instancia puede guardar hasta 10 GB.

Patty: ¿Y en Paid?

Willy: Incluye un millón de peticiones y 400.000 GB-segundo al mes; después cuesta 0,15 dólares por millón de peticiones y 12,50 por millón de GB-segundo. Hay hasta quinientas clases y almacenamiento total sin límite, con cobro de 0,20 dólares por GB-mes desde enero de 2026.

Patty: Los WebSockets aceptan mensajes de 32 MiB, ¿verdad? Y la CPU son 30 segundos por petición, ampliables hasta cinco minutos.

Willy: Sí. Además, un objeto con WebSockets puede hibernar si no hay actividad: conserva la conexión, sale de memoria y no cobra duración. Ideal para una sala con jugadores inactivos. Ojo: cada setAlarm, es decir, cada temporizador, cuenta como una fila escrita.

Patty: Regla rápida: KV para configuración o caché muy leída y poco cambiante; D1 para datos relacionales, reportes y muchas escrituras; Durable Objects para una sala o documento colaborativo con un dueño lógico; y R2 para archivos grandes.

Willy: Y falta Queues. Un Worker productor mete mensajes en una cola y otro consumidor los procesa por lotes, con reintentos automáticos. Así desacoplas, por ejemplo, subir una imagen de generar sus miniaturas.

Patty: Y el cobro es por operación: cada bloque de 64 KB escrito, leído o eliminado cuenta como una. En resumen, no haces esperar al usuario mientras termina el trabajo pesado.

Willy: Soy Willy, y hoy seguimos recorriendo las herramientas de Cloudflare para montar aplicaciones sin llevarnos sorpresas con los límites.

Patty: Y yo soy Patty. Empecemos por los mensajes: en el plan gratuito tienes 10 000 operaciones diarias y una retención fija de 24 horas. En Paid puede llegar hasta 14 días.

Willy: Pero ojo: ¿10 000 operaciones equivalen a 10 000 mensajes?

Patty: No. Entregar un mensaje normalmente consume tres operaciones: escribirlo, leerlo y eliminarlo. Así que, como cálculo rápido, serían unas 3 300 entregas completas al día.

Willy: Ah, o sea que hay que presupuestar el ciclo entero, no solo el envío. Pasemos a Workflows. ¿Para qué sirven?

Patty: Para orquestar procesos de varios pasos que deben sobrevivir reinicios, reintentos o esperas largas. Por ejemplo: cobras un pedido, esperas la confirmación del banco y después envías el correo. Si algo se interrumpe, el flujo puede continuar sin empezar desde cero.

Willy: En Free hay 100 000 peticiones al día, compartidas con Workers, 10 milisegundos de CPU por invocación, un GB-mes de almacenamiento y 3 000 pasos diarios.

Patty: Y si el proceso debe arrancar a una hora concreta, entran los Cron Triggers. Ejecutan un Worker con una expresión cron, sin necesidad de recibir una petición HTTP.

Willy: Como generar un informe cada madrugada. Free permite cinco triggers por cuenta y Paid, 250. Cada ejecución puede durar hasta 15 minutos de tiempo real.

Patty: Ahora, Hyperdrive: no es una base de datos. Es un proxy con pool de conexiones y caché para acelerar el acceso desde Workers a una base Postgres o MySQL externa.

Willy: Así evitas abrir una conexión nueva desde el borde en cada petición. Free incluye 100 000 consultas diarias y en Paid son ilimitadas.

Patty: Para inteligencia artificial está Workers AI, que permite ejecutar modelos ya entrenados de texto, imagen, voz o embeddings sin gestionar GPUs. El consumo se mide en “neuronas”.

Willy: Ambos planes reciben 10 000 neuronas gratis al día. Si te pasas, Free falla; en Paid cuesta 0,011 dólares por cada 1 000 neuronas adicionales. Y algunos modelos grandes, como Kimi K2, GLM o DeepSeek, exigen un método de pago activo incluso usando Free.

Patty: ¿Y AI Gateway?

Willy: Es la capa de control para llamadas a servicios como OpenAI o Anthropic: ofrece analítica, caché, límites y reintentos. Sus funciones núcleo son gratuitas en todos los planes.

Patty: Para RAG y búsqueda semántica está Vectorize, que almacena embeddings y encuentra los más parecidos. Aquí sí necesitas Workers Paid: incluye 30 millones de dimensiones consultadas y cinco millones almacenadas al mes.

Willy: También tenemos Browser Rendering: un Chrome real, sin interfaz, controlado con Puppeteer o Playwright para capturas, PDFs o scraping. Free da 10 minutos diarios y hasta tres navegadores simultáneos. Paid incluye 10 horas mensuales, cobra 0,09 dólares por hora adicional y admite diez concurrentes.

Patty: Terminamos con Images. Transformar imágenes alojadas en cualquier sitio es gratis hasta 5 000 transformaciones únicas al mes, tanto en Free como en Paid.

Willy: Si superas el límite, las transformaciones nuevas devuelven el error 9422, aunque las ya cacheadas siguen funcionando. Y almacenar y servir imágenes directamente desde Cloudflare Images requiere Paid.

Patty: En resumen: conviene distinguir qué servicio almacena, cuál acelera, cuál ejecuta y, sobre todo, qué unidad factura cada uno.

Willy: Patty, hoy toca revisar varias piezas de Cloudflare que suelen quedar fuera del radar. Empecemos por Analytics Engine. ¿Es como tener Google Analytics dentro de un Worker?

Patty: Se parece más a una base de métricas para tu propia telemetría. Tú escribes series de tiempo o puntos de datos —por ejemplo, latencia, ventas o partidas iniciadas— y luego los consultas con SQL.

Willy: Ah, o sea que podría guardar cuánto tarda cada endpoint y después agruparlo por país o por hora.

Patty: Exactamente. En Free tienes cien mil puntos escritos y diez mil consultas de lectura al día. Eso sí, Cloudflare aclara que actualmente no cobra por el uso; los precios publicados son informativos para cuando empiece la facturación.

Willy: ¿Y para investigar errores tenemos Workers Logs?

Patty: Sí. Guarda logs estructurados de los Workers y permite buscarlos y filtrarlos desde el dashboard. Free incluye doscientos mil eventos diarios con tres días de retención. En Paid son veinte millones al mes incluidos y siete días de retención.

Willy: Pasemos a video. Realtime ofrece SFU, TURN y WebRTC. Traducido al mundo real: ¿videollamadas y transmisiones en vivo?

Patty: Correcto. Los primeros mil gigabytes mensuales de tráfico son gratis, compartidos entre SFU y TURN. Además, publicar tráfico hacia Cloudflare siempre es gratis; lo que se cobra es la salida hacia los espectadores o participantes.

Willy: ¿Y RealtimeKit?

Patty: Es la capa de más alto nivel, antes llamada Cloudflare Calls: trae un SDK más completo para construir la experiencia. Tiene límites propios de API y SDK, así que conviene consultar la página específica de límites de RealtimeKit.

Willy: También aparecen Cloudflare Agents. ¿Son Durable Objects con vocación de chatbot?

Patty: Buena forma de imaginarlo. Es un framework para agentes de IA con memoria y estado. Cada agente puede tener hasta un gigabyte de estado y dispone de treinta segundos de cómputo por petición o mensaje; ese tiempo se renueva cuando llega otra petición. Una cuenta puede manejar decenas de millones de agentes concurrentes.

Willy: Luego está Pipelines, todavía en beta.

Patty: Sirve para recibir streams de eventos, transformarlos con SQL y enviarlos, por ejemplo, a R2 en Parquet o Iceberg. Solo está disponible en Workers Paid. La entrada al stream es gratis; incluye cincuenta gigabytes mensuales de transformación SQL y cincuenta de salida a destinos, y después se cobra.

Willy: Hay servicios que directamente no entran en Free, ¿verdad?

Patty: Sí: Containers para ejecutar Docker; Stream, como un YouTube privado, donde ingesta y encoding son gratis pero pagas almacenamiento y entrega; además de Vectorize y Email Sending. Advanced Certificate Manager y Keyless SSL son complementos o servicios Enterprise. Y el Bot Management completo, junto con el WAF avanzado y la detección por comportamiento y machine learning, queda para Business o Enterprise.

Willy: Para cerrar: ¿cómo se conecta todo esto con un Worker?

Patty: Mediante bindings definidos en wrangler.toml o wrangler.jsonc. En el código aparecen como propiedades de env: env.KV, env.DB, env.ASSETS o env.ROOM_DO. Un solo Worker puede combinar varios, justo como en el patrón de Racing Ecuador.

Willy: Y si necesito llamar a otro Worker de mi cuenta...

Patty: Usas Service Bindings: la comunicación es directa, sin salir a Internet y sin coste adicional por petición. Solo se contabiliza el CPU consumido por ambos Workers.

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