Despliegue 24/7: cómo poner tu proyecto en internet con Cloudflare Workers, GitHub y Vercel

Tiempo: unos 30 min de lectura + 45 min de práctica

Lo esencial

Imagina que construiste un cartero mecánico que funciona de maravilla en tu casa. Ahora hay que mandarlo a trabajar por su cuenta: a una oficina a la que llegará todos los días a las 9 de la mañana, sin depender de ti. Desplegar (deploy) es justo eso: pasar tu automatización de "funciona en mi computadora" a "funciona siempre, en la nube, sin mí".

Conceptos clave

• La diferencia entre ejecutar algo en tu computadora y desplegarlo en la nube
• Cloudflare Workers como plataforma edge (cómputo en los servidores más cercanos al usuario) para automatizaciones 24/7
• Lo desplegado es determinista: el código hace exactamente lo escrito, sin autocorregirse
• Rate limiting (límite de frecuencia de solicitudes) y las cuotas de las claves de API (interfaz de programación de aplicaciones) en producción
• Vercel para desplegar aplicaciones web
• Alternativas: Trigger.dev, Modal, Railway (comparación)

Teoría

Qué cambia al desplegar

Cuando desarrollas un workflow (flujo de trabajo) con Claude Code, el agente (un programa ejecutor autónomo) puede corregir un error sobre la marcha. ¿Escribiste mal la ruta de un archivo? El agente lo nota, lo corrige y sigue. A esto se le llama ejecución adaptativa.

Al desplegar eso no existe. Despliegas código y herramientas, no al agente con su capacidad de razonar y corregir. El código se ejecuta de forma determinista: paso 1 → paso 2 → paso 3. Si en el paso 2 algo sale mal, aparece un error. Nada de "espera, lo voy a repensar".

🎨 Imagínalo así: desarrollar con Claude es como un ensayo con el director a tu lado. Te equivocas, el director te corrige y sigues. Desplegar es como la función en vivo sin el director en la sala. Te equivocas en el tercer acto y la obra se cae: telón.

Conclusión: todas las pruebas hay que hacerlas durante el desarrollo, no esperar a que "en producción se arregle solo".

Cloudflare Workers: tu fábrica de automatizaciones en el edge

🎨 Imagínalo así: Cloudflare Workers es una fábrica que nunca duerme. Te vas a casa a las 6 de la tarde y la línea de producción sigue: reúne datos, envía reportes, escribe en la base de datos. Tú no estás, y la producción sigue.

Cloudflare Workers son funciones edge que corren en los servidores de Cloudflare en cientos de ciudades del mundo. No es una plataforma SaaS (software como servicio) aparte, sino parte de la infraestructura de Cloudflare.

Qué pueden hacer los Workers:

• Cron Triggers (programación con cron, un planificador de tareas): cada lunes a las 08:00, el primer día del mes, cada 15 minutos
• Webhooks HTTP (un webhook es un aviso por HTTP): llega una solicitud → el Worker ejecuta la lógica
• KV Storage (almacenamiento clave-valor): guardar datos entre ejecuciones (estado, resultados, caché)
• Avisos a un chat: enviar los resultados directo a un bot de mensajería, por ejemplo de Telegram

¿Por qué Cloudflare Workers y no Trigger.dev?

Los precios y límites de Cloudflare en la tabla están a octubre de 2026. Precios y versiones vigentes: Lo vigente.

Cuándo conviene más Trigger.dev: si la tarea calcula o procesa datos durante más tiempo del que permiten los límites de CPU de Workers (scraping pesado, procesamiento de video). Para la mayoría de las automatizaciones ligeras, Workers es más barato y rápido.

Trigger.dev es una buena herramienta. Usamos Workers porque a pequeña escala sale más barato y está integrado en el ecosistema que ya usamos. Compara con tus propias cifras.

El proceso de despliegue: 5 pasos

Paso 1: Crear el proyecto del Worker

npm create cloudflare@latest -- my-automation
cd my-automation

La herramienta te hará algunas preguntas: elige "Hello World example", "Worker only" y el lenguaje TypeScript. Creará la estructura del proyecto con wrangler.jsonc (la configuración; en proyectos viejos es wrangler.toml, y el formato toml también se admite) y src/index.ts (el código). Abajo la configuración se muestra en formato toml; el sentido de los ajustes es el mismo.

Paso 2: Configurar los secretos

Los secretos se agregan con la CLI (interfaz de línea de comandos), no en archivos:

wrangler secret put ANTHROPIC_API_KEY
# Escribes la clave en la terminal: se cifra y se guarda en Cloudflare
wrangler secret put TELEGRAM_BOT_TOKEN

🎨 Imagínalo así: los secretos en wrangler secret put son como una caja fuerte en el banco. La clave existe, pero no la traes en el bolsillo: está en un almacén protegido. Nadie la va a sacar del repositorio de git (un sistema de control de versiones) ni de la carpeta del proyecto.

Nunca guardes claves en el código. Solo con wrangler secret put.

Paso 3: Configurar el horario en wrangler.toml

name = "weekly-job-scraper"
main = "src/index.ts"
compatibility_date = "2026-10-01"  # pon la fecha de hoy

[triggers]
crons = ["0 9 * * 1"]  # cada lunes a las 09:00 UTC

[[kv_namespaces]]
binding = "CACHE"
id = "your-kv-namespace-id"

Paso 4: Escribir el Worker

export default {
  async scheduled(event, env, ctx) {
    // 1. Leemos el estado anterior desde KV
    const lastRun = await env.CACHE.get("last-run");
    
    // 2. Llamamos a la API de Anthropic
    const response = await fetch("https://api.anthropic.com/v1/messages", {
      method: "POST",
      headers: {
        "x-api-key": env.ANTHROPIC_API_KEY,
        "content-type": "application/json",
        "anthropic-version": "2023-06-01"
      },
      body: JSON.stringify({
        model: "claude-sonnet-5-5",  // el identificador vigente del modelo está en la página Lo vigente
        max_tokens: 1024,
        messages: [{ role: "user", content: "Genera un resumen..." }]
      })
    });
    const data = await response.json();
    const result = data.content.map((b) => (b.type === "text" ? b.text : "")).join("");
    
    // 3. Lo enviamos a Telegram
    await fetch(`https://api.telegram.org/bot${env.TELEGRAM_BOT_TOKEN}/sendMessage`, {
      method: "POST",
      headers: { "content-type": "application/json" },
      body: JSON.stringify({
        chat_id: env.TELEGRAM_CHAT_ID,
        text: result,
        parse_mode: "Markdown"
      })
    });
    
    // 4. Guardamos el estado
    await env.CACHE.put("last-run", new Date().toISOString());
  }
};

Paso 5: Despliegue y monitoreo

# Despliegue
wrangler deploy

# Monitoreo en tiempo real
wrangler tail

La prueba del cron se hace en tu computadora: ejecuta npx wrangler dev --test-scheduled y, en otra ventana de la terminal, corre:

curl "http://localhost:8787/cdn-cgi/local/scheduled"

En el Cloudflare Dashboard ves los registros de cada ejecución, los errores y las métricas.

Un ejemplo real: el resumen semanal de vacantes

La tarea: cada viernes reunir vacantes de empleo y enviar un resumen a un chat (en el ejemplo, un bot de Telegram).

Arquitectura del Worker:
1. Cron Trigger: "0 17 * * 5" (viernes 17:00 UTC)
2. Leer los resultados anteriores desde KV (para quitar duplicados)
3. Obtener datos de 5 APIs de vacantes
4. Llamar a la API de Anthropic para estructurar + analizar
5. Quitar duplicados (lo que ya salió la semana pasada)
6. Guardar los resultados nuevos en KV
7. Enviar el resumen a Telegram
8. Registrar métricas (tokens, la unidad mínima de texto para la IA; costo) en un KV de auditoría

Una limitación importante: el límite de CPU time (tiempo de procesador). En el plan Free son 10 ms de CPU por ejecución; en el de pago (mínimo $5/mes), el límite para un cron es mucho mayor y depende de cada cuánto se ejecuta (consulta la página de límites de Cloudflare). Esperar la respuesta de la red (llamar a una API, leer KV) no cuenta como CPU time, así que para la mayoría de los workflows con APIs alcanza. Para scraping pesado con Playwright necesitas Trigger.dev o un servidor aparte.

Rate limiting: la pared invisible

En producción trabajas con los límites reales de las APIs:

Anthropic:

• Los límites de solicitudes y de tokens por minuto dependen del nivel (tier) de tu cuenta y del modelo; los valores exactos están en Claude Console y en la sección Rate limits de la documentación
• Las cuentas nuevas empiezan en un nivel bajo, y los límites suben conforme las usas

🎨 Imagínalo así: el rate limit es la fila en la caja. Si llegas corriendo con productos nuevos demasiado rápido, el cajero te dice "espérate". Sin lógica de retry (reintento), te das la vuelta y te vas. Con retry, esperas un segundo y lo vuelves a intentar.

Si se rebasa el límite: la API devuelve el error 429. Sin lógica de retry, el workflow se cae.

La solución: agregar pausas entre solicitudes y usar retry con espera exponencial:

async function callWithRetry(fn, maxRetries = 3) {
  for (let i = 0; i < maxRetries; i++) {
    try {
      return await fn();
    } catch (e) {
      if (e.status === 429 && i < maxRetries - 1) {
        await new Promise(r => setTimeout(r, 1000 * Math.pow(2, i)));
        continue;
      }
      throw e;
    }
  }
}

Planear las cuotas: si el workflow procesa 500 documentos al día, calcula cuántos tokens se van a gastar. No rebases las cuotas diarias.

Vercel: para aplicaciones web

Cloudflare Workers es para automatizaciones y tareas en segundo plano. Vercel es para aplicaciones web y APIs:

• Despliegue de apps de Next.js / React
• Serverless functions (sin administrar un servidor): endpoints de REST API (puntos de entrada)
• Edge Functions: se ejecutan cerca del usuario
• El plan gratis Hobby: sirve para prototipos personales, pero solo para proyectos no comerciales. Para proyectos comerciales necesitas el plan de pago Pro (a octubre de 2026: $20 al mes por desarrollador)

Una combinación típica:

Vercel (interfaz web) ←→ Cloudflare Workers (tareas en segundo plano) ←→ KV Storage
                                      ↓
                              Bot de chat (avisos)

El usuario presiona un botón en el sitio → Vercel recibe la solicitud → un Cloudflare Worker lanza la tarea → el resultado va a KV + al bot.

Una nota aparte sobre sitios estáticos: para ellos y para apps full-stack, Cloudflare ahora recomienda Workers con archivos estáticos (Workers Static Assets); Pages sigue funcionando, pero las funciones nuevas aparecen en Workers (a octubre de 2026).

Cloudflare Workers: planes

Para empezar: el plan Free alcanza para 1 a 3 automatizaciones. El de pago (desde $5/mes) es para un uso serio. Las cifras son a octubre de 2026.

Precios vigentes: Cloudflare Workers Pricing

Comparación de todas las plataformas de despliegue

Errores comunes al desplegar

1. Olvidar configurar los secretos con wrangler secret put. El error más común: copiaste el código, lo desplegaste y el Worker falla con "undefined", porque las claves de API no están configuradas. Siempre revisa wrangler secret list antes de desplegar.

2. No probar en tu computadora antes de desplegar. wrangler dev ejecuta el Worker localmente: úsalo. Una corrida con wrangler dev te ahorra una hora de depuración en producción.

3. Guardar secretos en wrangler.toml. El archivo wrangler.toml suele terminar en git. Los secretos (claves de API, tokens) van solo con wrangler secret put, nunca en wrangler.toml ni en el código.

4. Ignorar el límite de CPU time. Free tier = 10 ms de CPU time. Esperar la red no cuenta, pero procesar respuestas grandes y la lógica compleja lo rebasan fácil. Revisa con wrangler tail cuánto CPU time gasta el Worker.

5. Olvidar el retry ante errores 429. En producción, los servicios de API devuelven 429 (rate limit) con regularidad. Sin lógica de retry, el Worker simplemente se cae a las 3 de la mañana y te enteras en la mañana.

Un wrangler.toml real: la configuración del Worker

name = "my-weekly-digest"
main = "src/index.ts"
compatibility_date = "2026-10-01"   # pon la fecha de hoy

# Horario: cada lunes a las 09:00 UTC
[triggers]
crons = ["0 9 * * 1"]

# Almacenamiento KV para el estado entre ejecuciones
[[kv_namespaces]]
binding = "CACHE"
id = "abc123def456"        # el ID que da `wrangler kv namespace create CACHE`
preview_id = "xyz789"      # para wrangler dev

# Variables de entorno (NO son secretos: pueden ir en la configuración)
[vars]
TELEGRAM_CHAT_ID = "123456789"
ENVIRONMENT = "production"

# Los secretos se agregan con la CLI:
# wrangler secret put ANTHROPIC_API_KEY
# wrangler secret put TELEGRAM_BOT_TOKEN

Atención: el id del KV namespace lo obtienes con wrangler kv namespace create CACHE. Los secretos (ANTHROPIC_API_KEY, etc.) se configuran solo con wrangler secret put.

Lista de verificación antes de desplegar

🎨 Imagínalo así: desplegar sin lista de verificación es como lanzar un cohete sin la revisión previa al vuelo. El cohete va a despegar, pero si regresa es otra historia.

Antes de desplegar, revisa sin falta:

• Todas las claves de API con wrangler secret put (no en el código, no en wrangler.toml)
• El workflow se probó en tu computadora con wrangler dev al menos 3 veces
• Se manejan los edge cases (casos límite): respuesta vacía de la API, servicio caído, sin datos
• Hay pausas entre solicitudes (rate limiting)
• El Worker cabe en el límite de CPU time (10 ms en Free; el límite de cron en el de pago, en la página de límites)
• El KV namespace está creado y vinculado en wrangler.toml
• Se registran los pasos clave (console.log → se ve en wrangler tail)
• Hay avisos de errores configurados (por ejemplo, un bot de chat)

Práctica

Tarea: desplegar una automatización sencilla en Cloudflare Workers

1. Instala Node.js (lo necesitas para los comandos de abajo). Wrangler viene en el proyecto, no hace falta instalarlo de forma global: usa npx wrangler ...
2. Crea el proyecto: npm create cloudflare@latest -- quote-bot (Hello World, Worker only, TypeScript)
3. Inicia sesión: npx wrangler login
4. Escribe el Worker: cada 5 minutos, obtener un registro de una API pública de prueba (por ejemplo, jsonplaceholder.typicode.com) y registrar el resultado
5. Configura el cron en la configuración de Wrangler: crons = ["*/5 * * * *"]
6. Prueba en tu computadora: wrangler dev --test-scheduled
7. Despliega: wrangler deploy
8. Observa la ejecución: wrangler tail
9. Extra: agrega un secreto (wrangler secret put MY_SECRET) y úsalo en el Worker como env.MY_SECRET
10. Extra 2: crea un KV namespace y guarda el número del último registro, para no repetir

Resultado esperado: en wrangler tail se ven ejecuciones exitosas regulares con los registros.

Herramientas y recursos

• Cloudflare Workers: plataforma edge para automatizaciones
• Wrangler CLI: la CLI para crear, probar y desplegar Workers
• Cloudflare KV: almacenamiento clave-valor para el estado entre ejecuciones
• Cloudflare D1: base de datos SQL (SQLite) para Workers, si KV no alcanza
• Cloudflare R2: almacenamiento de archivos (parecido a S3), con un volumen gratis (condiciones en la página de precios)
• Cloudflare Workers Pricing: tarifas vigentes
• Vercel: despliegue de apps web; el plan gratis Hobby es solo para proyectos no comerciales
• Trigger.dev: alternativa para tareas largas
• Railway: un servidor completo, si necesitas un VPS
• Render: despliegue sencillo de web services + cron jobs
• GitHub Actions: alternativa para pipelines de CI/CD (integración y entrega continuas)

Ideas clave

Al desplegar envías código, no al agente. El código no se corrige solo: por eso prueba DURANTE el desarrollo, no después.

El rate limiting es un problema real en producción. Agrega pausas y lógica de retry antes de que algo se caiga a las 3 de la mañana.

Cloudflare Workers = velocidad del edge + almacenamiento KV + cron listos para usar. A pequeña escala sale notablemente más barato que Trigger.dev. Para la mayoría de las tareas ligeras es una buena elección.

Lecciones relacionadas

• → Loop vs. Scheduled Tasks: programar las ejecuciones de Workers con cron y Trigger.dev
• → Headless Mode y CI/CD: despliegue automático de Workers con GitHub Actions
• ← APIs e integraciones: los Workers hacen llamadas a APIs de servicios externos; entender las APIs es indispensable

Siguiente lección

→ Multimodalidad: imágenes, PDF y audio en el trabajo con Claude