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 y persistir el evento en almacenamiento durable.
3. Confirmar recepción dentro del plazo del canal solo después de persistir; procesar desde la cola sin hacer esperar al webhook a la inferencia.
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.

Plan de prueba antes de pagar

Descarga plan-despliegue.md y completa los límites del plan que vas a contratar. Es una ficha de diseño y ensayo, no evidencia de un despliegue realizado por el sitio. Una sola restricción incompatible —por ejemplo, un proceso persistente en un runtime por petición— puede descartar una opción; no necesitas acumular dos fallos.

[ ] ¿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 ensayo útil: recibe un evento de desarrollo, persístelo y retrasa artificialmente el modelo ocho segundos. El webhook debe confirmar según el plazo documentado de su canal sin esperar al modelo. Ocho segundos es una perturbación del experimento, no un timeout universal de Telegram, WhatsApp o Slack.

La ventana de fallo que debes probar

Imagina tres momentos: A, recibiste el evento; B, lo guardaste en la cola; C, el agente terminó. Si respondes 200 entre A y B y el proceso cae, el proveedor puede dar el evento por entregado aunque nunca lo guardaste. Si respondes después de B y cae antes de C, un worker puede recuperar el trabajo pendiente.

La segunda secuencia tampoco garantiza un único efecto externo. Puede caer después de enviar un mensaje o crear un pedido, pero antes de guardar la confirmación. Usa una clave de idempotencia estable y conciliación con el proveedor; no marques una tarea como “fallida, reintentar” cuando su efecto es desconocido.

Prueba con un endpoint de desarrollo y datos ficticios:

Fallo inyectado	Qué debe ocurrir	Evidencia a guardar
Firma incorrecta	Rechazo antes de guardar o inferir	Estado HTTP y cero tareas nuevas
Evento repetido	Un registro lógico y un efecto	ID de evento y clave de idempotencia
Modelo lento	Webhook confirma tras persistir	Tiempos de entrada, persistencia y ack
Worker interrumpido	Trabajo recuperable desde la cola	Estado antes y después del reinicio
Envío externo ambiguo	Conciliación antes de repetir	ID del proveedor y estado pendiente
Presupuesto agotado	No iniciar más inferencia	Motivo de corte y derivación

CPU no es duración end-to-end

Registra por separado tiempo de CPU, tiempo total, memoria máxima y tamaño de dependencias. Un handler que espera red puede consumir poca CPU y seguir excediendo un límite de duración, conexión o evento. Los 30 segundos de CPU de un plan de Workers no son intercambiables con 300 segundos de duración de una Function.

Las cifras de la tabla anterior son una referencia fechada, no una garantía contractual. Anota runtime, plan, flags de ejecución y enlace consultado en la ficha descargable. No bases un compromiso con clientes en un límite beta ni en que la versión local haya terminado una vez.

Qué puedes mover y qué no

La lógica del agente y sus schemas suelen ser portables. Disco local, procesos hijos, SQLite en archivo, sockets persistentes y tareas en segundo plano no lo son automáticamente. Si tu prototipo es el bot Python con polling, necesita un proceso activo; no basta subir ese mismo archivo a una Function y asumir que seguirá escuchando.

Empieza por la plataforma que cumple los requisitos con menos operación. Puedes añadir una cola o un worker dedicado cuando una medición lo justifique, no porque todas las arquitecturas deban tener el mismo diagrama.

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.