n8n with Ollama: connect local AI models without the cloud

How to connect n8n to local AI models via the Ollama credential, including a Docker pitfall and tool-calling limits.

n8n connects to Ollama via its own Ollama credential, in which you only need to enter a base URL (default: http://localhost:11434) and optionally an API key. Local language models can then be integrated into workflows via the Ollama Model Node or the Ollama Chat Model Node, without prompt data being sent to a cloud provider. The Ollama Model Node is suitable for simple chains with the Basic LLM Chain, but according to the n8n documentation it does not support tool-calling. For AI agents with tool access, the Ollama Chat Model Node is the right choice, although not every local model reliably handles function calls. As of: July 2026.

How do you set up the Ollama credentials in n8n?

In n8n, you first create an Ollama credential, which consists of two fields: the base URL of your Ollama instance and an optional API key for bearer token authentication for remote or proxy-secured installations. The default base URL is http://localhost:11434. If you have set the environment variable OLLAMA_HOST on your Ollama server, enter exactly that value instead, as described by the official n8n documentation on Ollama credentials. If you encounter connection errors with the IPv6 message "ECONNREFUSED ::1:11434", it often helps to replace localhost with the IPv4 address 127.0.0.1.

What is the most common pitfall in Docker environments?

The classic error occurs because each Docker container has its own localhost namespace, meaning n8n and Ollama in separate containers cannot reach each other automatically. If only Ollama runs in Docker and n8n runs directly on the host, it is enough to expose the port with -p 11434:11434 and keep http://localhost:11434 entered in n8n. If, on the other hand, n8n runs in a container and Ollama on the host system, you must use http://host.docker.internal:11434 instead of localhost in the Ollama credential. On Linux, the n8n container additionally requires the flag --add-host host.docker.internal:host-gateway, or the matching extra_hosts entry in the Docker Compose file, since Docker Desktop provides this name resolution automatically, but plain Linux server installations do not. If both services run as separate containers in the same Docker network, use the container name of Ollama as the host instead, for example http://my-ollama:11434. This distinction is documented in the notes on known issues of the Ollama Chat Model Node.

Ollama Model Node or Ollama Chat Model Node: which node do you need?

n8n offers two different sub-nodes for Ollama, and the choice directly determines whether your workflow can later call tools. The Ollama Model Node explicitly does not support tool-calling according to the documentation and therefore cannot be connected to the AI Agent Node; instead, it belongs to the Basic LLM Chain for simple prompt-response tasks without tool access. The Ollama Chat Model Node, on the other hand, is designed for conversation scenarios and connecting to agent workflows, and offers parameters such as Sampling Temperature, Top K, and Top P to control response diversity. You select the specific model from a dropdown of models downloaded locally via ollama pull.

What are the limits of tool-calling with local models?

Honestly, tool-calling is the biggest weakness of local operation: not every model provided via Ollama supports reliable function calls, even if the Ollama Chat Model Node can technically be connected to a Tools Agent. Older or smaller models tend to format tool calls incorrectly, invent parameters, or simply ignore tools, which can lead to silent errors in production automations. Anyone who needs reliable tool-calling should specifically test models that were trained for it and spot-check the results before productive use instead of blindly trusting the output. For companies that need a solid assessment of which setup of cloud and local models fits their use case, NordFlux offers consulting on AI agents that includes exactly this trade-off between data sovereignty, cost, and reliability.

Frequently asked questions about n8n and Ollama

Does Ollama have to run on the same server as n8n?

No, Ollama can also run on a separate machine or server, as long as n8n can reach the base URL of that instance. In this case, enter the IP address or hostname of the Ollama server in the Ollama credential and secure the connection if needed via the optional API key.

Why does n8n report "ECONNREFUSED" even though Ollama is running?

This error message often occurs when n8n connects via IPv6 to the address ::1 instead of via IPv4 to 127.0.0.1, but Ollama only listens on the IPv4 address. Replace localhost with 127.0.0.1 in the base URL to fix the error.

Does the Ollama Model Node work with the AI Agent Node?

No, according to the n8n documentation, the Ollama Model Node lacks tool support, which is why it does not work with the AI Agent Node. For agent workflows with tool access, use the Ollama Chat Model Node instead, but you must check the tool-calling capability of the chosen model yourself.

Does n8n also support proxy connections to Ollama?

Only to a limited extent: Ollama itself does not support custom HTTP agents, so classic HTTP or HTTPS proxy configurations between n8n and Ollama can be problematic. For secured remote connections, bearer token authentication via the optional API key in the credential is the more reliable approach.

About NordFlux

NordFlux UG (haftungsbeschränkt)

NordFlux builds digital employees for organisations: automations and AI agents that take over repetitive work. You stay in control.

More about us
Free initial analysis

Concrete questions about automation or AI?

In a free initial analysis we discuss your case directly. No strings attached.