n8n vs trigger.dev: cuándo un flujo necesita código de verdad

Resuelven problemas con forma distinta

Ya escribimos sobre cómo elegir entre n8n, Make y Zapier. Esa comparación termina justo donde empieza esta, porque las tres son editores visuales y aquí la pregunta real es cuándo ninguna de ellas tiene la forma correcta.

La distinción que importa es si el trabajo tiene forma de integración o forma de código.

El trabajo con forma de integración es sobre todo fontanería. Llega un formulario, así que crea el registro en el CRM, avisa en un canal, añade una fila, manda un correo. La lógica es fina y el valor está en las conexiones. Un lienzo visual es de verdad la mejor representación de eso, porque el dibujo es la documentación y alguien sin perfil técnico puede mirarlo y entender qué pasa.

El trabajo con forma de código tiene fontanería fina y lógica gruesa. Itera, se bifurca con condiciones incómodas de dibujar, dura lo bastante como para que fallar a mitad importe, y hay que probarlo antes de que toque datos reales. Dibujar eso en un lienzo produce un diagrama que nadie puede leer y que nadie puede probar.

Dónde n8n es la respuesta correcta

n8n es la opción por defecto para la mayoría de automatización de negocio, y eso no es una concesión.

Gana en autoalojamiento, que importa cuando los datos no pueden salir de tu infraestructura por motivos regulatorios o contractuales, y elimina del todo el precio por tarea: ejecuciones ilimitadas sobre hardware que ya pagas. Para un flujo que se dispara miles de veces al día, esa diferencia es el caso de negocio entero.

Gana en visibilidad para el equipo. Un lienzo que tu responsable de operaciones puede abrir, seguir y editar vale más que la elegancia. Una automatización que solo entiende un desarrollador se convierte en un riesgo en cuanto ese desarrollador se va de vacaciones.

Y gana en variedad. Ya existen cientos de integraciones con la autenticación resuelta. Escribir tú ese pegamento es trabajo que no produce ningún valor diferencial.

Cuatro señales de que un flujo se quedó grande para el lienzo

No se migra un parque de automatizaciones entero. Notas que un flujo concreto va forzado, y con una de estas cuatro señales suele bastar.

Duración. El flujo dura lo suficiente como para que un tiempo de espera agotado o un fallo a mitad sean un problema de negocio y no una molestia. Todo lo que espera a un sistema externo lento, procesa un lote grande o retoma tras un reinicio cae aquí.

Control de versiones. Necesitas revisión de cambios, ver qué cambió y por qué, y poder volver atrás. Un editor visual puede exportar JSON, pero revisar el diff de un flujo en JSON no es revisar código, es arqueología.

Poder probarlo. Necesitas ejecutar el flujo contra datos de prueba antes de que toque producción. Si tu único entorno de pruebas es producción con una bandera activada, esta señal ya está sonando.

Observabilidad. Necesitas saber qué paso falló, con qué dato de entrada, cuántas veces reintentó y cuánto tardó cada paso. "El flujo dio error" no da para operar.

Dónde toma el relevo trigger.dev

trigger.dev es un framework para escribir trabajos en segundo plano con TypeScript, y lo que compra es exactamente las cuatro cosas de arriba.

La ejecución duradera es el titular. Un trabajo guarda puntos de control de su avance, así que un reinicio retoma donde se quedó en vez de repetir pasos ya completados. Para cualquier cosa larga o costosa, esa es la diferencia entre que un reintento sea seguro y que sea un segundo cargo en la tarjeta de un cliente.

Lo demás sale de que es código. Vive en tu repositorio, pasa por revisión, se prueba en integración continua y produce registros estructurados por paso. Versionar prompts y montar bancos de pruebas para los pasos con IA son asuntos de código normales, no algo que atornillas después.

El coste es honesto y conviene decirlo: es código, así que necesita un desarrollador. Tu responsable de operaciones ya no puede abrir un lienzo y ver qué pasa. Cambias visibilidad por durabilidad, que es un buen trato para los flujos que lo necesitan y malo para los que no.

La comparación, condensada

Usar los dos es la respuesta normal

El encuadre que más ayuda a los clientes es que son capas, no alternativas.

n8n lleva la superficie de integración: los disparadores desde formularios, CRMs y webhooks, el enrutado entre servicios, los avisos. Se queda visible, y el equipo de operaciones conserva un mapa vivo del proceso sin leer código.

trigger.dev lleva las partes que no pueden ser frágiles. Cuando n8n llega a un paso largo, costoso o que hay que probar antes de ejecutarlo de verdad, llama a un trabajo de trigger.dev y espera el resultado. La frontera es un solo nodo del lienzo.

Ese reparto te da las dos propiedades: el equipo sigue viendo el proceso de punta a punta, y el veinte por ciento arriesgado vive en código revisado, probado y observable.

Cómo decidir en la práctica

Hazte tres preguntas sobre el flujo concreto, no sobre tu stack.

1. Si esto falla a mitad, ¿sale caro? Dinero, acciones duplicadas de cara al cliente, datos corrompidos. Si sí, necesita ejecución duradera.
2. ¿Me quedaría tranquilo si esto se publicara sin revisión ni pruebas? Si no, tiene que vivir en un repositorio.
3. ¿Alguien fuera de desarrollo necesita entenderlo o cambiarlo? Si sí, deja visible lo visible y mueve a código solo el paso arriesgado.

La mayoría de flujos responden no, sí, sí y se quedan en n8n. Los que responden que sí a la primera son los que vale la pena mover, y normalmente solo en parte.

Si quieres esa evaluación sobre tus procesos reales y no en abstracto, para eso está la auditoría con la que arranca un proyecto de automatización de flujos. Mapeamos lo que ya corre antes de recomendar nada, porque la herramienta es la última decisión, no la primera.