n8n con Ollama: conectar modelos de IA locales sin la nube

n8n se conecta con Ollama a través de su propia credencial de Ollama, en la que solo debe indicar una URL base (por defecto: http://localhost:11434) y, opcionalmente, una API key. Después, los modelos de lenguaje locales pueden integrarse en workflows mediante el nodo Ollama Model o el nodo Ollama Chat Model, sin que los datos del prompt se envíen a un proveedor en la nube. El nodo Ollama Model es adecuado para cadenas sencillas con la Basic LLM Chain, pero según la documentación de n8n no admite tool-calling. Para agentes de IA con acceso a herramientas, el nodo Ollama Chat Model es la opción correcta, aunque no todos los modelos locales manejan de forma fiable las llamadas a funciones. Fecha: julio de 2026.

¿Cómo se configuran las credenciales de Ollama en n8n?

En n8n, primero se crea una credencial de Ollama, compuesta por dos campos: la URL base de su instancia de Ollama y una API key opcional para la autenticación por bearer token en instalaciones remotas o protegidas mediante proxy. La URL base por defecto es http://localhost:11434. Si en su servidor Ollama ha definido la variable de entorno OLLAMA_HOST, introduzca en su lugar exactamente ese valor, tal como describe la documentación oficial de n8n sobre las credenciales de Ollama. Ante errores de conexión con el mensaje IPv6 "ECONNREFUSED ::1:11434", suele ayudar sustituir localhost por la dirección IPv4 127.0.0.1.

¿Cuál es el escollo más frecuente en entornos Docker?

El error clásico se produce porque cada contenedor Docker tiene su propio espacio de nombres localhost, por lo que n8n y Ollama en contenedores separados no pueden alcanzarse automáticamente. Si solo Ollama se ejecuta en Docker y n8n directamente en el host, basta con exponer el puerto con -p 11434:11434 y mantener http://localhost:11434 en n8n. Si, en cambio, n8n se ejecuta en un contenedor y Ollama en el sistema host, debe usar http://host.docker.internal:11434 en lugar de localhost en la credencial de Ollama. En Linux, el contenedor de n8n necesita además el flag --add-host host.docker.internal:host-gateway, o la entrada extra_hosts correspondiente en el archivo Docker Compose, ya que Docker Desktop proporciona esta resolución de nombres automáticamente, pero las instalaciones de servidor Linux puras no. Si ambos servicios se ejecutan como contenedores separados en la misma red Docker, use en su lugar el nombre del contenedor de Ollama como host, por ejemplo http://my-ollama:11434. Esta distinción está documentada en las notas sobre problemas conocidos del nodo Ollama Chat Model.

Nodo Ollama Model o nodo Ollama Chat Model: ¿cuál necesita?

n8n ofrece dos sub-nodos diferentes para Ollama, y la elección determina directamente si su workflow podrá llamar a herramientas más adelante. El nodo Ollama Model no admite explícitamente tool-calling según la documentación y, por tanto, no puede conectarse al nodo AI Agent; pertenece más bien a la Basic LLM Chain para tareas sencillas de prompt-respuesta sin acceso a herramientas. El nodo Ollama Chat Model, en cambio, está pensado para escenarios de conversación y la conexión con workflows de agentes, y ofrece parámetros como Sampling Temperature, Top K y Top P para controlar la diversidad de las respuestas. El modelo concreto se selecciona en un desplegable con los modelos descargados localmente mediante ollama pull.

¿Dónde están los límites del tool-calling con modelos locales?

Sinceramente, el tool-calling es el mayor punto débil del funcionamiento local: no todos los modelos disponibles a través de Ollama admiten llamadas a funciones fiables, aunque el nodo Ollama Chat Model pueda conectarse técnicamente a un Tools Agent. Los modelos más antiguos o más pequeños tienden a formatear mal las llamadas a herramientas, inventar parámetros o simplemente ignorar las herramientas, lo que puede provocar errores silenciosos en automatizaciones productivas. Quien necesite un tool-calling fiable debería probar específicamente modelos entrenados para ello y verificar los resultados mediante muestreo antes del uso productivo, en lugar de confiar ciegamente en la salida. Para empresas que necesitan una evaluación sólida sobre qué combinación de modelos cloud y locales se ajusta a su caso de uso, NordFlux ofrece asesoría sobre agentes de IA que incluye precisamente este equilibrio entre soberanía de datos, costes y fiabilidad.

Preguntas frecuentes sobre n8n y Ollama

¿Tiene Ollama que ejecutarse necesariamente en el mismo servidor que n8n?

No, Ollama también puede ejecutarse en una máquina o servidor independiente, siempre que n8n pueda alcanzar la URL base de esa instancia. En ese caso, introduzca en la credencial de Ollama la dirección IP o el nombre de host del servidor Ollama, y proteja la conexión si es necesario mediante la API key opcional.

¿Por qué n8n muestra "ECONNREFUSED" aunque Ollama esté en ejecución?

Este mensaje de error suele aparecer cuando n8n se conecta mediante IPv6 a la dirección ::1 en lugar de usar IPv4 en 127.0.0.1, mientras que Ollama solo escucha en la dirección IPv4. Sustituya localhost por 127.0.0.1 en la URL base para solucionar el error.

¿Funciona el nodo Ollama Model con el nodo AI Agent?

No, según la documentación de n8n, al nodo Ollama Model le falta soporte de herramientas, por lo que no funciona con el nodo AI Agent. Para workflows de agentes con acceso a herramientas, use en su lugar el nodo Ollama Chat Model, aunque deberá comprobar usted mismo la capacidad de tool-calling del modelo elegido.

¿Admite n8n también conexiones por proxy a Ollama?

Solo de forma limitada: Ollama en sí no admite agentes HTTP personalizados, por lo que las configuraciones clásicas de proxy HTTP o HTTPS entre n8n y Ollama pueden ser problemáticas. Para conexiones remotas seguras, la autenticación por bearer token mediante la API key opcional de la credencial es el método más fiable.