Conectar n8n con un modelo local

En el nivel 3 aprendiste cómo funciona la automatización y en tu primer flujo de n8n construiste un proceso que corre solo. En cuanto en un proceso así hay un paso de IA, en cada pasada un trozo de tus datos viaja hasta un proveedor. Con diez pasadas al día uno no piensa en ello. Con dos mil sí, y como muy tarde cuando en los datos hay nombres de clientes.

Este playbook cuelga un modelo de tu propio ordenador en el sitio donde normalmente está el nodo de nube. La parte difícil no es la IA. Es la red, porque n8n y Ollama casi nunca corren en el mismo sitio. Ahí es donde se atasca casi todo el mundo, y por eso eso se lleva dos pasos propios.

1. Aclara primero si esto merece la pena para tu flujo

Hay dos casos en los que lo local gana con claridad en la parte de automatización. Uno es el volumen: si un flujo corre mil veces al día y cada vez cuesta unos céntimos, lo accesorio se convierte en una partida. El otro es la confidencialidad: si por el flujo pasan datos que no pueden salir de casa, la pregunta por el proveedor ni siquiera se plantea.

Pero también existe el caso en el que lo local es la respuesta equivocada. Si tu flujo corre tres veces al día y cada vez necesita una redacción exigente, el nodo de nube es más barato y mejor. Tres peticiones diarias a un modelo grande cuestan menos que la electricidad de un ordenador que tiene que estar disponible las veinticuatro horas.

Consejo: Antes de cambiar, cuenta cuántas veces corrió realmente tu flujo el mes pasado. La cifra estimada casi siempre es demasiado alta.

2. Pon Ollama primero en modo solo local

Antes de meternos con la red, un ajuste sin el cual todo el propósito de este playbook se tambalea. Ollama puede ejecutar modelos en su propia nube, y la llamada para eso pasa por el mismo punto de acceso de tu ordenador, localhost:11434. Desde fuera, un modelo de nube parece por tanto uno local. Si eliges uno, tus peticiones y las respuestas salen del ordenador sin que en tu flujo cambie absolutamente nada.

Para un playbook de protección de datos eso no es un detalle, es el ajuste de partida. Pon OLLAMA_NO_CLOUD=1 y reinicia Ollama. En Linux con systemd la variable va en el servicio, no en tu shell:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NO_CLOUD=1"

Después sudo systemctl daemon-reload y sudo systemctl restart ollama. En un contenedor pasas la variable al arrancar, es decir -e OLLAMA_NO_CLOUD=1. Existe además un archivo de ajustes con "disable_ollama_cloud": true, pero cuidado con él en Linux: allí el servicio corre como usuario propio ollama y por eso no lee el archivo de tu directorio personal. El camino por el servicio es el que no deja dudas.

Y ahora la parte que no te puedo ahorrar, por incómoda que sea: no te fíes del nombre del modelo. Muchos modelos de nube llevan un -cloud o :cloud en el nombre, pero eso es una convención, no una frontera. ollama list tampoco te ayuda aquí, enseña los modelos que tienes instalados y no el estado del ajuste. Si el modo solo local está realmente en vigor aparece tras el reinicio en el registro de Ollama, como la línea Ollama cloud disabled: true. Míralo una vez y lo sabrás.

Consejo: El puerto 11434, en el que Ollama ofrece su servicio, solo es accesible por defecto desde el propio ordenador. Eso está bien, porque esa interfaz no tiene autenticación. Quien llegue a ella puede descargar modelos, ejecutarlos y también borrarlos. Quédate con esa frase para el paso 4.

3. Entiende que el problema real se llama red

n8n tiene que poder llegar al servicio de Ollama. Si eso funciona sin más depende de si uno de los dos, los dos o ninguno corre en un contenedor. Esa es toda la dificultad, y quien la ha entendido una vez tiene el resto en diez minutos.

El atajo obvio está en muchas guías: dejar que Ollama escuche sin más en todas las interfaces, es decir en 0.0.0.0. Esa es la línea que convierte un servicio privado en uno abierto, porque entonces cuelga de tu red una interfaz sin autenticación. Por eso este playbook no la enseña. Para cada constelación, el camino de abajo se las arregla sin ella.

Consejo: Si más tarde en el nodo de n8n pone "connection refused", eso prácticamente nunca es un problema del modelo. Siempre es esta cuestión de aquí.

4. Coge la constelación que se aplica a tu caso

Cinco casos, y para cada uno vale una dirección distinta.

Los dos instalados directamente en el ordenador, sin contenedores. El caso más sencillo y el más seguro, porque nada tiene que salir hacia fuera. En las credenciales de Ollama pones http://localhost:11434 y listo.

Los dos en contenedores separados. El caso habitual en cuanto trabajas con Compose, y el que yo recomendaría. Los dos contenedores van a la misma red propia de Docker y hablan entre ellos por el nombre del contenedor. Ollama no necesita entonces ningún puerto publicado:

docker network create ollama-net
docker run -d --restart unless-stopped --network ollama-net -e OLLAMA_NO_CLOUD=1 \
  -v ollama:/root/.ollama --name ollama ollama/ollama
docker run -d --restart unless-stopped --network ollama-net --name n8n \
  -p 127.0.0.1:5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n

La dirección en n8n es entonces http://ollama:11434, es decir el nombre del contenedor. Aquí el error más frecuente es poner localhost: eso apunta al propio contenedor de n8n, ahí no escucha nada, y te llevas un ECONNREFUSED.

Solo Ollama corre en un contenedor, n8n directo. Arrancas Ollama con un puerto que aparece expresamente solo en el propio ordenador:

docker run -d --restart unless-stopped -e OLLAMA_NO_CLOUD=1 \
  -v ollama:/root/.ollama -p 127.0.0.1:11434:11434 \
  --name ollama ollama/ollama

El 127.0.0.1: delante del puerto es toda la diferencia. Sin ese prefijo, Docker publica el puerto en todas las interfaces del ordenador. Va con ello un requisito: solo a partir de Docker Engine 28 esa restricción aguanta de verdad; en versiones anteriores, ordenadores del mismo segmento de red podían alcanzar igualmente esos puertos. Míralo con docker version, y si estás por debajo, actualiza primero. La dirección en n8n sigue siendo http://localhost:11434.

Solo n8n corre en un contenedor, Ollama directo en el ordenador. Este es el caso incómodo, porque el contenedor no llega al 127.0.0.1 del anfitrión. En Linux hay para esto un camino que se las arregla sin 0.0.0.0: enlazas Ollama exactamente a la dirección con la que el anfitrión es visible desde dentro del contenedor, la puerta de la red de Docker. Esa dirección la lees en vez de adivinarla:

docker network inspect bridge -f '{{(index .IPAM.Config 0).Gateway}}'

Normalmente sale 172.17.0.1. Eso es lo que va en el servicio, otra vez con sudo systemctl edit ollama.service:

[Service]
Environment="OLLAMA_HOST=172.17.0.1:11434"
Environment="OLLAMA_NO_CLOUD=1"

Esa dirección pertenece a la red de Docker y no es accesible desde tu red. El contenedor necesita entonces todavía el puente hacia el anfitrión:

docker run -d --restart unless-stopped --add-host host.docker.internal:host-gateway \
  --name n8n -p 127.0.0.1:5678:5678 -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

La dirección en n8n es entonces http://host.docker.internal:11434. Lo importante es que los dos se refieran a la misma red: si tu contenedor de n8n corre en una red propia en vez de en la estándar, coge la dirección de la puerta de esa red, no la de bridge.

En macOS y en Windows este atajo no existe. Allí Docker corre en una pequeña máquina propia y el anfitrión solo es accesible para el contenedor a través de un enlace a todas las interfaces. Cerrarlo de nuevo solo es posible entonces con el cortafuegos del sistema operativo, es decir una regla que rechace las conexiones entrantes al 11434 desde el resto de la red. Eso es trabajo manual, y el trabajo manual se olvida. Así que en esos sistemas coge la constelación de dos contenedores de arriba. No es un apaño, es sencillamente lo mejor.

Los dos en el mismo contenedor. Es poco frecuente, pero funciona sin nada más, con http://localhost:11434 basta.

Queda un caso especial, y parece un problema de Docker pero no lo es. Si el mensaje dice connect ECONNREFUSED ::1:11434, tu sistema ha resuelto localhost a la dirección IPv6 mientras Ollama escucha en IPv4. Los dos hablan entonces sin encontrarse. Pon como dirección base http://127.0.0.1:11434 en vez de http://localhost:11434 y queda resuelto. Ese :: delante del número de puerto es la señal para reconocerlo.

Consejo: Un contenedor recién creado no trae ningún modelo, el volumen está vacío. Consigue uno y comprueba que está ahí antes de seguir en n8n:

docker exec ollama ollama pull <nombredelmodelo>
docker exec ollama ollama list

Con una instalación sin contenedores, los dos comandos son sencillamente ollama pull y ollama list. Y fíjate en el -d --restart unless-stopped de todos los ejemplos: un contenedor que arrancas con -it --rm cuelga de tu terminal, desaparece del todo al salir, y después de reiniciar el ordenador tu automatización no vuelve a levantarse.

5. Crea las credenciales en n8n

En n8n creas una nueva entrada de Ollama en las credenciales. El único campo obligatorio es la dirección base del paso 4. Para una instancia local no hace falta ninguna clave, ese campo se queda vacío.

Después puedes probar la conexión directamente en n8n. Si la prueba pasa, la parte difícil está hecha.

Consejo: Si tu modelo corre en otro ordenador de la red, ninguna de las constelaciones de arriba basta. Entonces necesitas dos cosas juntas. Primero una conexión cifrada, es decir https:// con certificado comprobado o un túnel como WireGuard. Por http:// a secas, la clave, las peticiones y las respuestas viajan legibles por la red, y con eso el propósito de este playbook se ha ido. Segundo, un acceso con autenticación delante, por ejemplo Open WebUI, cuyo punto de acceso a Ollama está bajo la ruta /ollama. La dirección base queda entonces como https://tuservidor/ollama, y la clave la pones en el campo de al lado.

6. Conoce la diferencia entre los tres nodos de Ollama

Esta es la trampa que si no te cuesta una tarde entera. n8n tiene tres nodos para Ollama, y dos de ellos parecen casi iguales.

El primero se llama simplemente Ollama Model. No puede llamar a herramientas. Así lo dice la documentación, y la consecuencia es inequívoca: con el nodo AI Agent no funciona. Su sitio es la Basic LLM Chain.

El segundo se llama Ollama Chat Model. Ese es el que coges para conversaciones y para todo lo que deba colaborar con el agente.

El tercero se llama Embeddings Ollama y no genera texto en absoluto, sino vectores. Solo lo necesitas si estás llenando una base de datos vectorial en local. Con él va una regla: llenar y consultar tienen que correr con el mismo modelo. Lo que pasa si no, depende de lo parecidos que sean los modelos. Si sus vectores tienen longitudes distintas, la base de datos suele rechazar la consulta con un mensaje claro. Si las longitudes coinciden por casualidad, no recibes ningún error, solo peores resultados, y ese es el caso más molesto.

Pero el nodo correcto es solo la mitad de la condición. Las llamadas a herramientas tiene que saber hacerlas también el propio modelo, y ni mucho menos todos pueden. Si coges un modelo sin esa capacidad, el nodo está bien conectado, el agente corre, y aun así no usa nunca una herramienta. Ollama lista los modelos compatibles en una categoría propia, y esa es la lista vinculante a la hora de elegir.

Consejo: Quédate con la regla en su forma completa: la chain lleva Model, el agente lleva Chat Model más un modelo de la categoría de herramientas de Ollama. Si falta la segunda mitad, buscarás el fallo en un sitio en el que no está.

7. Construye el primer flujo con la Basic LLM Chain

Empieza pequeño a propósito, no con un agente. La Basic LLM Chain hace exactamente una cosa: manda tu texto al modelo y devuelve la respuesta. Sin memoria, sin herramientas, sin decisiones.

Para el paso de automatización típico eso es justo lo correcto. Clasificar un mensaje entrante, resumir un texto, sacar un campo de un texto libre. El agente solo hace falta cuando el modelo tiene que decidir por sí mismo qué herramienta usa.

Hay una peculiaridad que tienes que conocer, porque falla en silencio. La propia chain procesa tus registros como es debido, uno detrás de otro, y cada uno recibe su propio prompt. Pero el nodo de modelo que le cuelga es un subnodo, y las expresiones en sus propios campos se resuelven siempre al primer registro. Así que si trabajas con una expresión dentro del propio nodo de modelo, por ejemplo para elegir un modelo distinto por registro, recibes cinco veces la elección del primero. El flujo pasa entero y no avisa de nada. En el prompt de la chain esto no ocurre.

Consejo: Si no tienes claro si necesitas chain o agente: si puedes escribir los pasos de antemano, coge la chain. El agente es para el caso en el que no los conoces, y a cambio te cuesta previsibilidad.

8. Elige un modelo pequeño con una tarea estrecha

En el chat quieres un modelo lo más listo posible. En la automatización quieres uno lo más previsible posible. Ese es otro criterio, y lleva casi siempre a un modelo más pequeño.

Un flujo invoca siempre la misma tarea. Esa única tarea la resuelve un modelo pequeño de forma fiable si planteas el encargo lo bastante estrecho. Y un modelo pequeño responde más rápido, que con mil pasadas es la ganancia de verdad. Qué tamaño encaja con tu hardware está en Qué modelo local encaja con tu hardware.

Consejo: Resiste la tentación de coger en el flujo el modelo más grande que todavía funcione. En el procesamiento masivo decide el rendimiento, no el último matiz de la redacción.

Otro apunte sobre la elección: la lista de modelos de la documentación de n8n está desfasada, a fecha de agosto de 2026 sigue enseñando nombres de la generación Llama 2. Qué modelos tienes de verdad te lo dice ollama list en tu propio ordenador. Coge esa salida, no la lista de la documentación.

9. Cuenta con tiempos de espera distintos a los de la nube

Un proveedor de nube responde diez peticiones simultáneas de forma simultánea. Tu ordenador, con la configuración por defecto, no: Ollama atiende una petición cada vez por modelo, porque OLLAMA_NUM_PARALLEL está en 1. Si tu flujo corre en paralelo, las peticiones hacen cola. Puedes subir ese valor, pero lo pagas en memoria.

Eso no lo notas en la prueba, porque allí las lanzas de una en una. En funcionamiento real, un tiempo de espera agotado desemboca entonces en un error que en la prueba no viste nunca.

Al buscar el ajuste del tiempo de espera, mucha gente acaba en el nodo del modelo. Allí no está, el esquema de opciones del nodo Ollama Chat Model no tiene ningún límite de tiempo para la petición. n8n lo regula en otros tres sitios, y estos, para fastidiar, usan unidades distintas. N8N_AI_TIMEOUT_MAX vale justamente para los nodos de IA, es decir también para Ollama, y está en 3.600.000 milisegundos, o sea una hora. EXECUTIONS_TIMEOUT limita cada workflow y en autoalojado está en -1, es decir sin límite. EXECUTIONS_TIMEOUT_MAX es el techo que un usuario puede poner en un workflow concreto, en segundos, por defecto 3600. A eso se suman los ajustes del propio workflow.

Un malentendido más, porque cuesta tiempo: un proxy inverso delante de n8n solo limita cuánto puede esperar tu navegador a n8n. Sobre la llamada de n8n a Ollama no tiene ninguna influencia. Quien quiera poner ahí un límite tiene que poner el proxy delante de Ollama.

Un último ajuste está en Ollama. OLLAMA_MAX_LOADED_MODELS está en la mayoría de plataformas en tres con cálculo solo por procesador, o en el triple del número de tarjetas gráficas; en Windows con una tarjeta Radeon es actualmente uno. Pero varios modelos solo permanecen cargados a la vez si caben juntos en la memoria disponible, si no se descarga y se espera. En una máquina justa de recursos, esa espera parece un error de n8n. Si tu proceso trabaja de todos modos con exactamente un modelo, pon la variable en 1.

Consejo: Prueba tu flujo una vez con veinte registros seguidos, no con uno. Solo entonces ves el comportamiento real, y además antes de que te estalle en producción.

10. Impón la estructura y guárdate el billete de vuelta

Un modelo pequeño se ciñe peor a las indicaciones de formato que uno grande. Si tu paso siguiente en el flujo espera un JSON limpio y el modelo le pone una frase introductoria delante, se rompe el proceso entero. No lo resuelvas con un prompt más educado, sino con un nodo que compruebe la estructura y en caso de duda vuelva a preguntar. Cómo se hace eso bien está en JSON fiable a partir de la IA.

Y construye el flujo de manera que puedas cambiar el nodo de IA sin tocar el resto. Si el camino local no da para un paso concreto, quieres poder poner allí un nodo de nube y conservar todo lo demás.

Ahí hay una trampa que echa por tierra justamente la promesa del principio. Cuando cambias un nodo local por uno de nube, sigue viajando el mismo registro que antes veía el modelo local, y en n8n un registro suele llevar más campos de los que se ven en el prompt. Saber qué paso ve qué no basta, por tanto. Pon delante de cada rama de nube un nodo Edit Fields, desactiva en él "Include Other Input Fields" y asigna expresamente solo los campos que pueden salir. Después mira en la pasada de prueba qué se envió realmente. Para datos que no pueden salir de casa en absoluto no hay rama de nube, tampoco una de emergencia.

Consejo: Escríbete una nota dentro del flujo sobre qué datos hay en qué nodo. Dentro de tres meses ya no lo sabrás, y entonces tomarás la decisión de nuevo sin conocer la base.

Qué sigue

Si quieres usar la misma conexión no solo en n8n sino para tu propio asistente de IA, sigue por MCP con modelos locales. Si quieres saber si te sale a cuenta tener un ordenador encendido de forma permanente, la cuenta está en Local o nube, la cuenta honesta.

Fuentes

• n8n, Ollama Chat Model, parámetros y opciones del nodo: https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.lmchatollama/
• n8n, problemas conocidos del nodo Ollama Chat Model, entre ellos las constelaciones de Docker, la resolución IPv6 y la resolución de expresiones en subnodos: https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.lmchatollama/common-issues/
• n8n, Ollama Model, aviso sobre la falta de soporte de herramientas: https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.lmollama/
• n8n, el agente en comparación con la chain: https://docs.n8n.io/advanced-ai/examples/understand-agents/
• n8n, credenciales de Ollama incluido el bearer token: https://docs.n8n.io/integrations/builtin/credentials/ollama/
• n8n, los tres límites de tiempo y sus unidades: https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/executions/
• n8n, Edit Fields y el paso de campos: https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.set/
• Ollama, modelos de nube a través del punto de acceso local: https://docs.ollama.com/cloud
• Ollama, configuración del servidor, desactivar la nube, enlace y paralelismo: https://docs.ollama.com/faq
• Ollama, la interfaz local no tiene autenticación: https://docs.ollama.com/api/authentication
• Ollama, modelos con soporte de herramientas: https://ollama.com/blog/tool-support
• Docker, publicar puertos y qué cambió con Engine 28: https://docs.docker.com/engine/network/port-publishing/
• Docker, arrancar contenedores automáticamente: https://docs.docker.com/engine/containers/start-containers-automatically/
• Open WebUI, el punto de acceso a Ollama bajo /ollama: https://docs.openwebui.com/reference/api-endpoints/