Dónde desplegar un agente de IA: Vercel, Cloudflare Workers o VPS

La pregunta no es “cuál plataforma es mejor”. Es qué hace tu agente cuando llega un webhook y cuánto tiempo puede tardar en terminar. Un bot que clasifica un mensaje y responde cabe en una función. Un agente que llama tres APIs, espera un humano y reintenta durante una hora no. Esta guía compara Vercel, Cloudflare Workers y un VPS (o un PaaS tipo Railway) con límites publicados, no con marketing.

Si todavía no tienes el bucle de entrada, cola y handoff, lee primero la arquitectura mínima de producción. El costo de tokens es otro eje: cuánto cuesta un agente en 2026. Aquí el foco es runtime y hosting.

Qué tiene que hacer el runtime (antes de elegir logo)

Un agente en un canal de mensajería suele ser esto:

1. Recibir un POST (WhatsApp, Telegram, Slack, un cron).
2. Validar firma o secreto. Responder 200 rápido si la plataforma lo exige.
3. Encolar el trabajo si la inferencia tarda más que el timeout del webhook.
4. Llamar al modelo y a tools. Escribir estado. Mandar la respuesta al usuario.

El hosting solo gana o pierde en los puntos 2 a 4: tiempo máximo de la invocación, memoria, estado entre requests y quién opera el proceso.

Comparativa corta (límites que sí puedes citar)

Cifras de la documentación oficial consultada el 3 de septiembre de 2026. Los planes cambian: verifica la página vigente antes de comprometer un SLA.

Criterio	Vercel Functions	Cloudflare Workers	VPS / PaaS (p. ej. Railway)
Modelo	Función por request, escala a cero. Fluid compute reutiliza instancias y cobra CPU activa + memoria provisionada	Worker por request; el tiempo de espera de red no cuenta como CPU	Proceso largo: Node, Python, Docker. Tú (o el PaaS) administras el servicio
Duración / CPU	Hobby: máx. 300 s. Pro/Enterprise: 300 s por defecto, 800 s de máximo (1800 s en beta extendida). Limits	Plan Free: 10 ms de CPU. Plan Paid: 30 s de CPU por defecto, hasta 5 min. I/O no cuenta. Limits	Lo que aguante el proceso y tu watchdog
Memoria	Hobby 2 GB; Pro/Ent hasta 4 GB	128 MB por Worker	La RAM que pagues
Encaja si	Webhook + una pasada de modelo + tools HTTP, o streaming corto	Edge, baja latencia, I/O pesado y poco CPU local	Colas, workers nocturnos, browsers, sandboxes, sockets
Duele si	El trabajo supera maxDuration o necesitas un daemon	El loop del agente es CPU-bound (parseo pesado, crypto larga) o quieres 2 GB de deps	Operación: parches, backups, un IP fijo, y el costo fijo aunque no haya tráfico

Railway y similares no son “el VPS”: son un contenedor gestionado. Sirven cuando quieres proceso largo sin SSH. El VPS gana cuando necesitas control de red, un browser headless o un runtime que no cabe en 128 MB.

Cuándo Vercel es la decisión correcta

Vercel encaja si tu agente es un handler HTTP (Next.js, un fetch handler) pegado a un front o a un webhook. Fluid compute está pensado para trabajo I/O-bound: el modelo tarda, tú esperas, no pagas esa espera como CPU al mismo ritmo que un servidor encendido.

Usa Vercel si:

• ya despliegas el sitio o la API ahí;
• cada tarea cabe en 5 minutos (Hobby) o puedes subir maxDuration en Pro;
• el estado vive fuera (Turso, Postgres, KV), no en memoria del proceso;
• puedes ack el webhook y seguir en otra invocación o en un workflow durable si el trabajo se alarga.

No uses Vercel como “servidor 24/7” para polling, Playwright persistente o un bot que abre un socket todo el día. Eso no es un fallo de Vercel: es otro tipo de proceso.

Cuándo Cloudflare Workers es la decisión correcta

Workers brilla en el borde: validar el webhook cerca del usuario, firmar, escribir en KV o D1, y llamar al proveedor de modelos. El truco que la gente se salta: el límite es CPU, no reloj de pared. Esperar a Gemini o a WhatsApp no gasta esos 30 s. Un bucle que parsea un PDF enorme sí.

Usa Workers si:

• el handler es liviano y el trabajo pesado está en APIs externas;
• quieres un edge global sin regiones que configurar a mano;
• 128 MB y el tamaño del Worker (3 MB free / 10 MB paid) te bastan.

No metas el orquestador completo (historial, retries, human-in-the-loop de horas) dentro de una sola invocación. Parte: Worker recibe, cola o Durable Object guarda el paso, otra invocación continúa. Si tu “agente” es un script de 200 MB con Chromium, esto no es el sitio.

Cuándo el VPS (o un contenedor siempre encendido) gana

Elige proceso largo cuando el trabajo no es una request:

• cola con workers que tardan más que cualquier maxDuration;
• sandbox o agente de código que ejecuta tests;
• browser, ffmpeg, o un binario que no cabe en el bundle serverless;
• necesidad de IP estable, VPN o puertos que el PaaS no abre.

El costo es operacional: actualizaciones, disco, backups, y que un proceso caído no se “reescala solo” como una función. Un PaaS reduce SSH; no elimina la necesidad de healthchecks y de no guardar estado solo en RAM.

Evidencia propia: checklist de 20 minutos antes de pagar

Copia esto a una nota. Si fallas dos filas, cambia de plataforma antes de escribir el prompt bonito.

[ ] ¿El proveedor del canal exige 200 en menos de N segundos?
[ ] ¿Una pasada modelo + tools cabe en el límite publicado (300 s / 30 s CPU)?
[ ] ¿El estado sobrevive a un restart? (DB, no memoria del isolate)
[ ] ¿Los secretos están fuera del repo y rotan?
[ ] ¿Hay tope de pasos y de tokens por tarea?
[ ] ¿Puedo ver la invocación (logs) de un webhook fallido?
[ ] ¿El trabajo largo va a una cola, no al request del usuario?

Un prototipo honesto: el mismo handler en local, un webhook de Telegram, y un timeout artificial de 8 s. Si a los 8 s todavía no ack, en producción WhatsApp o Slack te van a reintentar. Eso no se arregla “subiendo el modelo”.

Decisión en una frase

• Webhook corto + sitio en Next.js: Vercel.
• Validación en el borde + I/O, poco CPU: Cloudflare Workers.
• Cola, browser, daemon o trabajo de horas: VPS o contenedor siempre encendido.

Puedes mezclar: Worker o Function reciben; el trabajo pesado corre atrás. Mezclar mal es lo contrario: un solo request que “espera al agente entero”.

El hub de seguridad, coste y operación junta esta decisión con costos y observabilidad. Si todavía estás instalando el runtime y los canales, el curso gratuito cubre WhatsApp y Telegram sobre un proceso que puedes mover después a cualquiera de estas tres opciones.