La idea
Cada proyecto mío terminaba pidiendo lo mismo: un webhook que reciba algo, una integración puntual con otro servicio, un aviso cuando pasa X. Montarlo dentro de cada sistema es repetir código; montar un n8n por proyecto es repetir servidores.
Así que levanté un solo n8n, compartido por todos mis proyectos, y le puse una regla antes de escribir el primer workflow.
n8n solo emite eventos o hace integraciones puntuales. La lógica de negocio vive en cada producto, no en el lienzo.
Cómo está montado
- n8n con la versión fijada, sobre PostgreSQL 17 y no sobre SQLite, en Docker y detrás de nginx con TLS.
- Task runners externos para los nodos de código, en JavaScript y en Python: el código de un workflow no corre dentro del proceso principal. n8n y sus runners se actualizan juntos, siempre a la misma versión.
- Respaldo diario a las 3:45, con 14 días de historia. Los secretos viven fuera del repositorio; sin la llave de cifrado, un respaldo restaurado no puede leer las credenciales, así que esa llave se guarda aparte.
- Un workflow de errores que vigila a los demás: si cualquier workflow falla, se dispara solo.
Cuando algo falla
El workflow de errores tiene tres pasos. El fragmento de arriba es el primero: arma el evento con el workflow, el nodo y el error, y una dedupe_key que sale del id de la ejecución. El segundo lo firma con HMAC-SHA256 y el tercero lo manda a FRIDAY, mi asistente.
Del otro lado, cada workflow que falla abre su propio incidente en Telegram. Si está en la lista de críticos, avisa al momento y con botones; si no, entra al resumen del día. El incidente se cierra solo después de 25 horas sin fallas nuevas. Un reenvío con la misma dedupe_key no hace nada, y una firma mala recibe un 404, como si el endpoint no existiera.
Lo que ya funciona
La instancia está en producción desde el 16 de octubre, con el workflow de errores publicado y uno de prueba que falla a propósito para revisar la cadena completa cuando quiero. Cada workflow nuevo, de cualquier proyecto, se conecta a ese reporte de errores antes de publicarse.
Lo aprendido
Una alerta que no suena también es una falla. En n8n 2.x el workflow de errores tiene que estar publicado. Si no lo está, n8n deja una línea en el log («is not active and cannot be executed») y no avisa nada: el sistema que debía avisarme de los errores fallaba en silencio. Por eso existe el workflow de prueba.
La CLI no es la interfaz. Importar y publicar workflows por línea de comandos funciona, pero los cambios de publicación recién se toman al reiniciar el contenedor, y n8n execute no convive con los runners externos. Lo anoté en el runbook en vez de recordarlo.
La regla vale más que el lienzo. n8n hace muy fácil meter un if más, y otro. Si un workflow empieza a decidir cosas del negocio, esa decisión se va al código del producto y n8n se queda con el evento.
Siguiente paso
Que los primeros workflows de mis productos corran aquí, cada uno conectado al reporte de errores desde el primer día.