Trigger.dev

Trigger.dev es una plataforma de código abierto para trabajos en segundo plano y flujos de trabajo de IA creada por Matt Aitken y Eric Allam, un equipo con sede en Dublín respaldado por Y Combinator e inversores de Serie A, incluyendo Standard Capital. Resuelve un problema específico y persistente: las funciones serverless como AWS Lambda y Vercel tienen límites estrictos de tiempo de espera de segundos o minutos, pero los pipelines de IA, los trabajos de procesamiento de documentos y los flujos de trabajo de agentes de múltiples pasos habitualmente necesitan ejecutarse durante minutos u horas. Trigger.dev permite a los desarrolladores definir tareas como funciones asíncronas ordinarias de TypeScript y ejecutarlas sin esa restricción, en infraestructura de nube gestionada o en sus propios servidores a través de Docker o Kubernetes.

La plataforma se distribuye como un SDK de TypeScript que se integra con Node.js, Bun, Next.js, NestJS y la mayoría de los demás entornos de servidor TypeScript. Las capacidades principales incluyen ejecución duradera con punto de control y reanudación (las tareas se pausan en los puntos await y se reanudan sin perder el estado), reintentos automáticos con retroceso configurable, colas concurrentes con controles de prioridad, programación cron y una Realtime API que transmite el progreso de las tareas en vivo a las aplicaciones frontend de React. Se integra con Vercel AI SDK, OpenAI Agents SDK, LangChain, LangGraph, LlamaIndex y las API de modelos directos de Anthropic, OpenAI, Google, Cohere y Mistral. Para casos de uso específicos de IA, Trigger.dev también admite puntos de espera con intervención humana (human-in-the-loop), donde las tareas se pausan para la aprobación o entrada humana y se reanudan exactamente donde se quedaron sin consumir tiempo de computación inactivo. La versión estable actual es la v4, con más de 14,800 estrellas en GitHub y licencia Apache 2.0.

Lo que realmente hace Trigger.dev en mayo de 2026

El mecanismo central de Trigger.dev es la ejecución de punto de control y restauración (checkpoint-restore). Cuando una tarea alcanza un punto await (esperando otra tarea, un evento externo, un temporizador o a un humano), la plataforma serializa el estado de la tarea utilizando CRIU (Checkpoint/Restore In Userspace) y suspende el contenedor. La tarea no se factura durante esta pausa. Cuando la condición esperada se resuelve, la tarea se reanuda exactamente desde el estado serializado. Esto es fundamentalmente diferente del serverless tradicional, donde una función termina dentro de su tiempo de espera o falla.

Las tareas se ejecutan en workers basados en Bun (contenedores de larga duración, no invocaciones efímeras al estilo Lambda). Cada tarea puede especificar su propia configuración de máquina: recuento de CPU, RAM y paquetes opcionales a nivel de sistema como FFmpeg, Puppeteer o entornos de Python personalizados a través de extensiones de compilación. Esto significa que una tarea de transcodificación de video y una tarea ligera de correo electrónico pueden compartir el mismo proyecto mientras se ejecutan en máquinas del tamaño adecuado.

La Realtime API, lanzada como GA en diciembre de 2024 y construida sobre Electric SQL (un motor de sincronización de PostgreSQL de código abierto), permite que los hooks de React como useRealtimeRun y useRealtimeBatch transmitan el estado de las tareas en vivo a las interfaces de usuario del navegador. Un pipeline de procesamiento de documentos puede mostrar a los usuarios el progreso en tiempo real: "Extrayendo texto.. Resumiendo el capítulo 3 de 8.." sin necesidad de hacer polling. Más de sesenta organizaciones adoptaron la Realtime API a los pocos días de su disponibilidad general, incluyendo Midday.ai y Papermark.io.

La programación se maneja de forma nativa a través de expresiones cron o disparadores basados en intervalos, y las tareas admiten patrones fan-out: una tarea principal puede generar cientos de subtareas simultáneamente, todas rastreadas en un único árbol de ejecución con observabilidad unificada. El panel de control impulsado por OpenTelemetry muestra árboles de seguimiento completos, registros, historial de reintentos y métricas de rendimiento para cada ejecución.

"Decidimos usar Trigger.dev en lugar de Inngest o configurar nuestra propia solución dedicada.. [para] la automatización de flujos de trabajo, escalabilidad, velocidad de desarrollo, eficiencia de costos y preparación para el futuro." - Sohrab Fadai, Product Hunt, 2024

Dónde se sitúa Trigger.dev frente a Inngest y Temporal

Las tres herramientas más comúnmente comparadas en la ejecución duradera centrada en el desarrollador son Trigger.dev, Inngest y Temporal. Cada una adopta un enfoque arquitectónico fundamentalmente diferente.

Inngest es la superposición funcional más cercana con Trigger.dev, pero la arquitectura difiere en un aspecto crítico: Inngest no ejecuta tu computación. Es una capa de orquestación solo de API que llama a tus endpoints serverless a través de HTTP y entrega eventos. Los desarrolladores deben dividir el trabajo en funciones step.run() discretas, cada una reintentada de forma independiente y con puntos de control en el límite del paso. Esto significa que los trabajos de Inngest siguen limitados por las restricciones de ejecución serverless por paso (aproximadamente 15 minutos por llamada a la función de paso). Trigger.dev ejecuta tu código directamente en su infraestructura gestionada (o en workers autoalojados) en contenedores de larga duración, sin el requisito de división de pasos. Una función asíncrona continua puede ejecutarse durante horas. El plan de pago Hobby de Trigger.dev comienza en $10/mo; el plan de pago de Inngest comienza en $75/mo. Trigger.dev es Apache 2.0 y puede autoalojarse completamente sin restricciones de funciones. Los términos de autoalojamiento de Inngest son más limitados. En el volumen de descargas semanales de npm, Inngest atrae aproximadamente 85,000 descargas semanales frente a las 45,000 de Trigger.dev, lo que refleja la mayor presencia en el mercado de Inngest, aunque Trigger está creciendo más rápido según la trayectoria de estrellas en GitHub.

Temporal se sitúa en un nivel completamente diferente: ejecución duradera de nivel empresarial para flujos de trabajo políglotas extremadamente complejos y de larga duración. Temporal utiliza la reproducción determinista basada en eventos (event-sourced). Cada acción del flujo de trabajo se registra en un historial de solo adición; en la recuperación, el flujo de trabajo se reproduce desde el principio, volviendo a ejecutar todas las actividades hasta el punto actual. Esto requiere un código de flujo de trabajo determinista: nada de Date.now(), números aleatorios ni E/S directa dentro de las funciones del flujo de trabajo. La curva de aprendizaje es sustancialmente más pronunciada, lo que requiere que los desarrolladores comprendan Workflows, Activities, Workers, Task Queues, Namespaces y Signals antes de enviar su primer trabajo. Temporal es políglota (Go, Java, Python, TypeScript, PHP, .NET); Trigger.dev prioriza TypeScript, con soporte para Python solo como una solución alternativa de extensión. Para las empresas que necesitan historiales de flujo de trabajo de varios años, pistas de auditoría completas o flotas de workers en Java/Go, Temporal es la opción correcta. Para un equipo de aplicaciones de IA en TypeScript que necesita trabajos en segundo plano confiables con una sobrecarga de infraestructura mínima, Trigger.dev es más rápido y económico de operar. Como resumió un desarrollador en la página de comparación de Trigger.dev frente a Temporal: "Pasar a Trigger para los trabajos en segundo plano fue más confiable, más barato y más fácil".

Los desarrolladores que construyen pipelines de ML centrados en Python también deberían evaluar Modal, que ofrece computación serverless acelerada por GPU y excelentes herramientas para Python. Para los equipos que ya utilizan n8n o Activepieces para la automatización visual de flujos de trabajo, Trigger.dev no es un reemplazo de herramienta visual, sino un complemento a nivel de código para trabajos que necesitan durabilidad y ejecución de larga duración.

Cómo es la realidad del bucle de agentes en el día a día

La experiencia de desarrollo comienza con la instalación del paquete @trigger.dev/sdk y la adición de un archivo trigger.config.ts para especificar la configuración del proyecto. Las tareas son funciones exportadas decoradas con task(). La CLI de Trigger.dev ejecuta un servidor de desarrollo local que se conecta al panel de control de Trigger.dev Cloud (o autoalojado), donde las ejecuciones aparecen en tiempo real durante el desarrollo. No hay una infraestructura de colas separada que configurar o gestionar localmente.

Para los flujos de trabajo de agentes de IA, el patrón consiste en definir una tarea raíz que orquesta las subtareas. Cada subtarea puede llamar a las API de LLM, escribir en bases de datos, enviar solicitudes HTTP y llamar a wait.forEvent() para pausar hasta que llegue una señal externa. Los flujos de trabajo con intervención humana (human-in-the-loop) añaden una llamada waitpoint que serializa el estado del agente y envía una notificación, para luego reanudarse cuando un humano envía la aprobación a través del panel de control de Trigger.dev o una llamada a una API personalizada.

El despliegue en producción es un único comando de la CLI: npx trigger deploy. La CLI construye una imagen de Docker, la envía a Trigger.dev Cloud (o a un registro autoalojado) y crea un despliegue versionado inmutable. Las tareas que ya se están ejecutando continúan en su versión desplegada; las nuevas tareas adoptan la última versión. Este versionado atómico evita que las ejecuciones en curso se rompan por nuevos despliegues de código, lo cual es un modo de fallo común en los sistemas basados en colas.

"La capacidad de usar TypeScript para definir flujos de trabajo es brillante." - Charlie, Product Hunt, 2024

La observabilidad está integrada a través de OpenTelemetry. Cada ejecución produce un árbol de seguimiento visible en el panel de control: cada paso, su duración, sus entradas y salidas, y cualquier llamada a subtareas anidadas. Las alertas de error configurables se pueden enrutar a Slack o PagerDuty. La retención de registros varía desde 1 día en el nivel Free hasta 30 días en el Pro, con retención personalizada en el Enterprise.

Para quién está diseñado Trigger.dev

Trigger.dev está diseñado específicamente para desarrolladores de TypeScript que construyen aplicaciones impulsadas por IA: aplicaciones Next.js con funciones de IA, backends de NestJS que procesan documentos, cualquier código del lado del servidor que llame a las API de LLM y necesite lógica de reintento y observabilidad. La herramienta es particularmente valiosa cuando los pipelines de IA chocan constantemente con los límites de tiempo de espera del serverless o cuando los desarrolladores se encuentran escribiendo lógica de reintento frágil a mano.

Las startups en etapa inicial encontrarán que el plan Hobby de $10/mo es suficiente para la mayoría de las cargas de trabajo de producción, con la computación facturada por separado según el uso real. Los equipos que procesan grandes volúmenes de trabajos de inferencia de IA encontrarán que las más de 200 ejecuciones simultáneas del nivel Pro y el soporte dedicado en Slack valen los $50/mo. Los despliegues autoalojados en Docker están documentados y son maduros a partir de la v4; el autoalojamiento en Kubernetes está disponible y se describe en una serie de publicaciones oficiales del blog.

Trigger.dev se integra de forma natural en los stacks que ya utilizan Zapier o Make para la automatización sin código (no-code), sirviendo a una capa diferente. Mientras que esas plataformas manejan el enrutamiento de eventos entre aplicaciones sin escribir código, Trigger.dev maneja lo que sucede dentro de la capa de código cuando los trabajos necesitan ejecutarse durante más tiempo del que permite una función Lambda.

Los equipos con compromisos significativos de código abierto aprecian la licencia Apache 2.0. Toda la plataforma se puede autoalojar sin limitaciones de funciones, sin límites de ejecución y sin dependencia del proveedor (vendor lock-in) más allá del propio SDK de TypeScript. El código base tiene más de 14,800 estrellas en GitHub, mantenedores activos y más de 617 lanzamientos a partir de mayo de 2026, lo que indica una verdadera capacidad de permanencia.

Lo que no es Trigger.dev

No es una herramienta de Python. El SDK es solo para TypeScript. Los scripts de Python se pueden llamar como subprocesos dentro de las tareas a través de extensiones de compilación, pero no hay un SDK nativo de Python, ni definición de tareas en Python, ni soporte de primera clase para la gestión de paquetes de Python dentro de las tareas. Los equipos de ML centrados en Python que ejecutan pipelines de inferencia deberían usar Modal, Prefect o Temporal con workers de Python en su lugar.

No es una plataforma no-code o low-code. No hay un constructor visual de flujos de trabajo, nodos de arrastrar y soltar, ni interfaz gráfica para definir trabajos. Todo es código. Los usuarios de negocios o los equipos que no son de ingeniería no pueden usar Trigger.dev sin la participación de los desarrolladores. Para la automatización visual de flujos de trabajo, consulta n8n o Activepieces.

No es un stack de observabilidad completo. Si bien el rastreo integrado de OpenTelemetry es útil, los equipos con infraestructura de observabilidad existente (Datadog, Grafana, Honeycomb) necesitarán integrar los rastreos de Trigger.dev en sus herramientas actuales. El panel de control integrado es funcional, pero no reemplaza a las plataformas de observabilidad creadas para ese propósito.

Aún no está reforzado a nivel empresarial a la escala de Temporal. El incidente de producción de septiembre de 2025, en el que los mensajes de error de gran tamaño de un solo cliente provocaron tres fallos simultáneos en la nube, reveló que la infraestructura aún se estaba estabilizando bajo un rápido crecimiento. El equipo publicó un informe de incidente público exhaustivo y envió correcciones en 48 horas, lo cual es una señal positiva. Pero los equipos para los que los fallos en el flujo de trabajo son críticos para el negocio pueden querer esperar a la migración a MicroVM (planeada para reducir la dependencia de Kubernetes) antes de comprometerse a escala empresarial.

Omite Trigger.dev si tu equipo ya tiene Inngest funcionando bien con flujos de trabajo basados en pasos y sin problemas de tiempo de espera. El costo de migración es real y la diferencia de funciones puede no justificarlo. Omítelo si necesitas pistas de auditoría de flujos de trabajo de varios años probadas en batalla: ese es el dominio de Temporal, no el de Trigger.