Ejemplo

La integración de herramientas de automatización como n8n en entornos .NET ofrece una forma sencilla, extensible y visual de orquestar flujos entre microservicios. En este artículo aprenderás a:

  1. Instalar n8n localmente con Docker.

  2. Exponerlo en localhost:5678.

  3. Crear un flujo (HTTP Trigger ➝ Webhook a un servicio .NET ➝ Respuesta dinámica).

  4. Usarlo como puente entre servicios: .NET → n8n → .NET.

Paso 1: Instalar n8n con Docker en Localhost

Primero, asegúrate de tener Docker instalado. Luego, lanza el siguiente contenedor para exponer n8n en http://localhost:5678.

docker run -it --rm \
  -p 5678:5678 \
  -e N8N_BASIC_AUTH_ACTIVE=true \
  -e N8N_BASIC_AUTH_USER=admin \
  -e N8N_BASIC_AUTH_PASSWORD=admin123 \
  -e N8N_HOST=localhost \
  -e N8N_PORT=5678 \
  -v ~/.n8n:/home/node/.n8n \
  n8nio/n8n

Si te diera error debes lanzar desde tu linea de comandos (usando linux):

mkdir -p ~/.n8n
sudo chown -R 1000:1000 ~/.n8n

Accede vía navegador a: http://localhost:5678, y sigue los pasos hasta que tengas disponible la aplicación:

Paso 2: Crear un flujo en n8n

  1. Crea un nuevo workflow.

  2. Añade un nodo HTTP Trigger:

    • Método: GET

    • Path: /webhook/test-flow

  3. Añade un nodo HTTP Request:

    • Método: GET

    • URL: http://host.docker.internal:5000/api/backend

    • Nota: host.docker.internal permite que n8n (en Docker) acceda a tu host Windows/Mac.

  4. Conecta ambos nodos.

  5. Guarda y activa el flujo.

Este sería el workflow:

Y lo activamos:

Paso 3: Servicio .NET de prueba

Vamos a crear dos endpoints .NET:

Servicio 1: Simula una llamada a n8n

// http://localhost:5000/api/sayhello
[HttpGet("sayhello")]
public IActionResult SayHello()
{
    var client = new HttpClient();
    var response = client.GetAsync("http://localhost:5678/webhook/test-flow").Result;
    var content = response.Content.ReadAsStringAsync().Result;
    return Ok($"Respuesta de n8n: {content}");
}

Servicio 2: Recibe la segunda llamada desde n8n

// http://localhost:5000/api/backend
[HttpGet("backend")]
public IActionResult Backend()
{
    return Ok("Hola desde el servidor .NET Backend");
}

Paso 4: Prueba de la integración completa

  • Abre un navegador o usa Postman para llamar al primer servicio .NET:

http://localhost:5000/api/sayhello

  • Este servicio llamará al HTTP Trigger de n8n (/webhook/test-flow).

  • n8n reenviará la petición al segundo servicio .NET (/api/backend).

  • La respuesta viajará de vuelta a través de n8n → servicio inicial → cliente.

Resultado esperado:

«Respuesta de n8n: Hola desde el servidor .NET Backend»

Y para terminar si quieres ver el estado de la que salió bien:

Más cosas

Dejemos de rascar la superficie: n8n vs Logic Apps a nivel de lógica

Funcionalidad Azure Logic Apps n8n
Condicional simple (if) Sí (bloque Condition) Sí (IF node o Set → Expression + ruta condicional)
Condicional múltiple (switch) Sí (bloque Switch con cases y default) Sí (Switch node con múltiples ramas)
Bucles (foreach, while) Sí (ForEach, Until) integrados Sí (nodos SplitInBatches, Loop con IF/Set combinados)
Evaluación booleana compleja Sí (expresiones con @and, @or, @greater, etc.) Sí (expressions con JS en campos como {{$json["key"] > 5}})
Expresiones y lenguaje Lenguaje propio basado en Workflow Definition Language (WDL) JavaScript en expresiones ({{$json["prop"] + 1}}, {{$now}})
Acceso a variables de contexto Sí, mediante @triggerOutputs()?['body/value'] Sí, mediante {{$json["key"]}}, {{$node["X"].json["value"]}}
Scope y manejo de errores por bloque Sí (bloques Scope, Try/Catch, Run After) Parcial (se puede simular Try/Catch con ramas + control manual)
Paralelismo y ejecución condicional Sí (puedes paralelizar ramas, runAfter, control de errores) Sí (puedes paralelizar nodos, usar IF, manejar errores)
Reintentos, timeout, fallbacks Nativo por acción: política de reintentos, timeout, fallback Parcial (reintentos configurables por nodo, o usando Error Trigger)
Persistencia de estado / resumible Sí, totalmente gestionado por Azure No (en local o self-hosted necesitas persistencia propia)
Diseño declarativo vs visual Declarativo en JSON + diseñador visual en portal Azure 100% visual (drag & drop) con expresiones JS
Complejidad creciente mantenible Difícil (bloques anidados crecen mucho) Más flexible (puedes modularizar con sub-flujos, folders, etc.)

Escalabilidad en n8n vs. Azure Logic Apps

Característica n8n Azure Logic Apps
Modelo de ejecución Self-hosted o cloud (n8n.io) Serverless gestionado 100% por Azure
Escalado horizontal automático No nativo. Requiere clúster (ej. Docker Swarm, Kubernetes, etc.) Sí. Escalado automático gestionado por Azure
Alta disponibilidad (HA) Necesita configuración activa (K8s, Redis queue, DB externa) Inherente al modelo serverless
Colas y concurrencia Redis o PostgreSQL para workflows distribuidos Nativo con control de concurrencia y ejecución paralela
Ejecución en paralelo Sí, con workers y triggers escalados Sí, múltiples instancias en paralelo
Persistencia y reanudación tras fallo Limitada en self-hosted (puede perder estado si no se configura bien) Azure mantiene el estado y puede reanudar flujos automáticamente
Tolerancia a errores / reintentos Parcial (requiere configuración por nodo o lógica adicional) Completa (configurable por acción, con runAfter, retries, timeouts)
Tiempo de arranque (cold start) Inmediato (si está en ejecución continua) Puede tener latencia si el plan es Consumption
Seguridad y gobernanza empresarial Depende de tu infraestructura y procesos Nativo con Azure Policy, RBAC, DLP, etc.
Multi-tenant / segregación de entornos Necesita instancias por entorno o uso de workspaces (solo SaaS Pro) Integrado (RG, entornos, slots, etc.)
Monitoreo y logging Requiere herramientas externas (Prometheus, Loki, Datadog, etc.) Integrado con Application Insights, Log Analytics, Alerts
Backup y restore de workflows Manual (export JSON, uso de Git, DB backups) Versionado automático en Logic Apps Standard con GitHub/Azure DevOps
Escalabilidad coste-eficiente Muy buena si es bien gestionado (especialmente en uso intensivo) Costes imprevisibles si hay muchos triggers/eventos/fallos

¿Cuándo usar cada uno?

Caso Recomendación
Flujos críticos con SLA y HA garantizado Azure Logic Apps
Integración rápida en Azure con conectores nativos Azure Logic Apps
Workflows internos con lógica personalizada compleja n8n
Casos on-prem o air-gapped n8n self-hosted
Entornos con infraestructura DevOps madura (K8s, GitOps) n8n escalado
Casos donde el coste de eventos Azure es prohibitivo n8n
Necesidad de lógica visual + scripting JS flexible n8n

Complejidad y costes ocultos de usar n8n en entornos reales

Aunque n8n se presenta como una alternativa open-source, visual y ligera para orquestación, cuando das el salto de probarlo en localhost a mantenerlo en producción, aparecen desafíos que deben considerarse cuidadosamente.

Infraestructura: No todo es gratis

Elemento Detalle
Servidor (VM o contenedor) Necesitas un entorno estable, con alta disponibilidad y backups
Base de datos PostgreSQL recomendado (SQLite solo para pruebas)
Cola de ejecución Redis si quieres concurrencia real o workers distribuidos
Almacenamiento seguro Variables sensibles y credenciales se almacenan en plano si no se cifra
Autenticación SSO / RBAC No disponible en la edición OSS; solo en el plan Enterprise Cloud

Seguridad y compliance

Tema Detalles críticos
Cifrado de datos en reposo No habilitado por defecto
Auditoría de acciones No disponible en OSS (sí en Enterprise)
SSO y control granular de acceso Solo en la versión empresarial
Dependencia de plugins o nodos externos Posibles riesgos si se usan integraciones de terceros no revisadas

Monitorización y trazabilidad

Elemento ¿Qué falta?
Observabilidad nativa No tiene integración con Prometheus, Grafana o logs estructurados
Histórico de ejecuciones Sí, pero sin métricas agregadas o correlación con sistemas externos
Alertas o dashboards Debes integrarlo tú con herramientas externas

Costes ocultos de usar n8n OSS

Categoría ¿Qué implica?
Tiempo de despliegue Infraestructura, seguridad, escalado, backups, CI/CD
Tiempo de mantenimiento Actualizaciones, dependencias, limpieza de flujos antiguos
Coste en personal Necesitas un DevOps y un responsable de plataforma
Compliance adicional Cifrado, SSO, control de cambios, trazabilidad
Licencias opcionales Si quieres soporte o seguridad avanzada, debes pagar por ello

El problema: ejecución distribuida no controlada

Supongo que ya sabeis que me encantan los sistemas distribuidos y en n8n no dejaré de hablar de este tema.

n8n o es «stateless» por completo. Si despliegas múltiples pods de n8n sin configurar un sistema de colas y coordinación, puedes encontrarte con estos problemas:

Problema Detalle
Race conditions Dos pods intentan ejecutar el mismo webhook o flujo
Estado perdido Si una ejecución empieza en un pod y se reinicia/crashea, la ejecución se pierde si no hay persistencia bien montada
Saltos entre pods Un trigger entra por un pod y el siguiente paso se intenta ejecutar en otro, lo que no es posible en n8n sin workers
Memoria compartida Cada pod mantiene su propio runtime y contexto, no hay sincronización entre ellos

Arquitectura escalable en K8s para n8n

Para que n8n escale correctamente en entornos Kubernetes, es esencial diseñar una arquitectura basada en el modelo de ejecución distribuido con colas. Escalar verticalmente no tiene sentido en un entorno cloud-native: lo que nos interesa es aumentar capacidad horizontalmente de forma controlada, resiliente y sin duplicar flujos.

Componentes necesarios

Componente Función clave
n8n Main Pod Web UI, recepción de triggers (HTTP, cron…), coordinación general del flujo.
PostgreSQL Persistencia del estado de workflows, ejecuciones y configuración.
Redis Cola de trabajos para distribuir la ejecución entre múltiples workers.
n8n Worker Pods Procesan los flujos asincrónicamente, sin arrancar UI ni triggers.

Modo Main

Este modo lanza UI + API + triggers: n8n start

Modo Worker

Solo ejecuta trabajos desde Redis: n8n worker

Configuración compartida (ej. values.yaml, Deployment.yaml, etc.)

N8N_QUEUE_MODE: "true"
QUEUE_MODE_REDIS_HOST: "redis-service"
DB_TYPE: postgresdb
DB_POSTGRESDB_HOST: postgres-service

Asegúrate de que todos los pods comparten la misma base de datos PostgreSQL y el mismo Redis. No hagas réplicas sin coordinación.

¿Es obligatorio Redis y PostgreSQL para n8n?

Buena pregunta:

Componente ¿Es obligatorio? ¿Qué pasa si lo cambio?
PostgreSQL Sí, en producción Solo se admite SQLite en modo local o de pruebas. Otros motores no son soportados oficialmente.
Redis Sí, para queue mode (escalado horizontal) Solo Redis es compatible con queue mode. No puedes usar RabbitMQ, Kafka, ni alternativas.

n8n requiere una base de datos relacional persistente para guardar:

  • Workflows

  • Credenciales

  • Logs de ejecución

  • Usuarios

Opciones soportadas oficialmente:

Motor Soporte Comentario
PostgreSQL Sí Recomendado en todos los entornos
SQLite Parcial Solo para pruebas locales
MySQL / MariaDB / SQL Server No No soportados oficialmente
MongoDB / NoSQL No n8n no es compatible

Por tanto: en Kubernetes o cualquier entorno multi-pod, PostgreSQL es obligatorio. SQLite no es seguro porque no puede ser accedido por múltiples instancias concurrentemente.

Redis (Cola de ejecución)

Redis se usa en queue mode, que es lo que permite que:

  • Un pod main reciba triggers.

  • Los jobs se encolen.

  • Múltiples pods worker ejecuten tareas de forma concurrente.

Alternativas como RabbitMQ, NATS, Kafka, etc. NO son compatibles.
n8n está diseñado específicamente con Redis como único backend de colas por ahora.

Conclusión

Si quieres escalar horizontalmente, usar workers y mantener consistencia entre pods, Redis + PostgreSQL es la única arquitectura soportada hoy.

Por tanto si estas en Azure y tienes que montar un PostgreSQL y una Redis, te obliga a meter otro coste oculto para cuando quieres trabajar en entornos distribuidos.

Nota sobre PostrgreSQL

Si no vas a distribuir n8n (es decir, no usas múltiples pods ni workers), podrías funcionar con una única instancia sin Redis, pero la base de datos PostgreSQL sigue siendo necesaria en producción.

¿Es obligatorio usar PostgreSQL en producción?

Sí, en la práctica es obligatorio usar PostgreSQL si:

  • Quieres un entorno estable y persistente en producción

  • Deseas recuperar workflows, ejecuciones, credenciales, usuarios tras reinicios

  • Usas n8n con Docker, Kubernetes o servidores reiniciables

  • Planeas hacer backups, CI/CD o migraciones

¿Puedo usar SQL Server?

No. n8n no es compatible con SQL Server ni con MySQL, MariaDB, Oracle ni bases NoSQL.

n8n utiliza TypeORM internamente, pero solo está oficialmente soportado y probado con PostgreSQL y SQLite.

Puntos clave de la licencia de n8n que debes tener en cuenta

No puedes usar RBAC, SSO, LDAP, audit logs ni workspaces multiusuario

  • Estas funcionalidades están exclusivamente disponibles en la edición Enterprise.

  • Si trabajas en una empresa que necesita control de accesos por roles, integración corporativa o trazabilidad de cambios: sí o sí necesitas pagar la licencia Enterprise.

No puedes ofrecer n8n como servicio SaaS a terceros usando la edición OSS

  • Si pones n8n a disposición de tus clientes para que creen o editen sus propios workflows, estás construyendo un servicio basado en n8n.

  • Esto viola la n8n Sustainable Use License, salvo que tengas un acuerdo comercial firmado con n8n GmbH.

Es decir: no puedes montar un portal donde los clientes gestionan flujos sin pagar la licencia Enterprise.

Puedes usarlo gratis si…

  • Solo lo usas internamente en tu empresa

  • No revendes n8n como producto o servicio

  • No necesitas funciones enterprise

  • Aceptas implementar tú mismo RBAC o control de cambios si te hace falta (vamos que te toca trabajar un poco más de lo que pensabas, otro coste oculto).

Me planteo un caso de uso (y sí, termino ya)

«Quiero montar en una instancia de n8n donde mis clientes entren y gestionen sus propios flujos (tipo ‘pinta y colorea’)».

¿Puedes hacerlo legalmente con la edición OSS?

No. No puedes hacerlo.Dar acceso a terceros (clientes) para que creen o editen workflows, aunque sea dentro de tu suscripción o infraestructura, se considera ofrecer n8n como servicio (SaaS), me he repetido, ya lo se.
Y eso requiere una licencia Enterprise y un contrato con n8n GmbH.

Entonces, ¿qué opciones tengo si quiero algo similar sin usar Zapier o herramientas cerradas… y sin caer en costes ocultos?

Aquí es donde la realidad se impone:

n8n OSS parece libre, pero cuando quieres hacer algo serio con múltiples usuarios, acceso externo, roles, auditoría o SSO, aparecen los costes ocultos.

Ya sabéis: primero te dan la herramienta gratis, y cuando estás enganchado… es cuando toca pasar por caja.

n8n OSS no es legal ni viable para ofrecer acceso a clientes sin pagar licencia Enterprise.

Azure Logic Apps sí lo permite, sin preocuparte por licencias, con:

  • Seguridad de nivel enterprise

  • SSO con Azure AD

  • Trazabilidad y logging integrado

  • Gobernanza clara y soporte legal

Si necesitas un entorno multiusuario gobernado, seguro y sin letra pequeña, Logic Apps es la opción correcta para escenarios B2B o SaaS.