Connecting n8n to a local model

In level 3 you learned how automation works and built a flow in your first n8n workflow that runs by itself. As soon as an AI step sits in such a flow, a piece of your data travels to a provider on every run. At ten runs a day nobody thinks about it. At two thousand they do, and at the latest once there are customer names in the data.

This playbook hangs a model on your own machine in the place where the cloud node usually sits. The hard part about it is not the AI. It is the networking, because n8n and Ollama almost never run in the same place. That is where almost everybody gets stuck, which is why it gets two steps of its own.

1. First work out whether this is even worth it for your flow

There are two cases in which local clearly wins in the automation strand. One is volume: if a flow runs a thousand times a day and costs a few cents each time, a side issue turns into a line item. The other is confidentiality: if data runs through the flow that must not leave the building, the question of which provider does not even arise.

But there is also the case where local is the wrong answer. If your flow runs three times a day and needs a demanding piece of writing each time, the cloud node is cheaper and better. Three requests a day at a large model cost less than the electricity for a machine that has to stand ready around the clock.

Tip: Before you switch, count how often your flow actually ran last month. The estimated number is almost always too high.

2. Put Ollama into local-only mode first

Before we get to the networking, one setting without which the whole purpose of this playbook wobbles. Ollama can run models in its own cloud, and the call for that goes through the very same endpoint on your machine, localhost:11434. From the outside a cloud model therefore looks like a local one. If you pick one, your prompts and the answers leave the machine without anything in your flow changing.

For a privacy playbook that is not a detail, it is the base setting. Set OLLAMA_NO_CLOUD=1 and restart Ollama. On Linux with systemd the variable belongs in the service, not in your shell:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NO_CLOUD=1"

Then sudo systemctl daemon-reload and sudo systemctl restart ollama. In a container you pass the variable at start, so -e OLLAMA_NO_CLOUD=1. There is also a settings file with "disable_ollama_cloud": true, but be careful with it on Linux: the service runs there as its own user ollama and therefore does not read the file in your home directory. The route via the service is the unambiguous one.

And now the part I cannot spare you, uncomfortable as it is: do not rely on the name of the model. Many cloud models carry a -cloud or :cloud in the name, but that is a convention, not a boundary. ollama list does not help you here either, it shows your installed models and not the state of the setting. Whether local-only mode is really in force appears in Ollama's log after the restart, as the line Ollama cloud disabled: true. Look there once and you know.

Tip: Port 11434, on which Ollama provides its service, is by default reachable only from the machine itself. That is a good thing, because this interface has no authentication. Whoever reaches it can pull models, run them and also delete them. Keep that sentence in mind for step 4.

3. Understand that the real problem is called networking

n8n has to be able to reach the Ollama service. Whether that works without further ado depends on whether one of the two, both or neither runs in a container. That is the whole difficulty, and once you have understood it the rest takes ten minutes.

The obvious shortcut is in many guides: simply let Ollama listen on all interfaces, so on 0.0.0.0. That is the line that turns a private service into an open one, because an interface with no authentication is then hanging off your network. This playbook therefore does not show it. For every constellation, the route below manages without it.

Tip: If the n8n node later says "connection refused", that is practically never a problem with the model. It is always this question here.

4. Take the constellation that applies to you

Five cases, and a different address applies to each.

Both installed directly on the machine, no containers. The simplest and the safest case, because nothing has to go outwards. In the Ollama credentials you enter http://localhost:11434, done.

Both in separate containers. The usual case as soon as you work with Compose, and the one I would recommend. Both containers go into the same custom Docker network and talk to each other via the container name. Ollama then needs no published port at all:

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

The address in n8n is then http://ollama:11434, so the container name. Here the most common mistake is entering localhost: that points at the n8n container itself, nothing is listening there, and you get ECONNREFUSED.

Only Ollama runs in a container, n8n directly. You start Ollama with a port that expressly appears only on the machine itself:

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

The 127.0.0.1: in front of the port is the whole difference. Without that prefix Docker publishes the port on all interfaces of the machine. One prerequisite belongs with it: only from Docker Engine 28 onwards does this restriction really hold, in older versions machines on the same network segment could reach such ports anyway. Check with docker version, and if you are below it, upgrade first. The address in n8n stays http://localhost:11434.

Only n8n runs in a container, Ollama directly on the machine. This is the awkward case, because the container does not reach the host's 127.0.0.1. On Linux there is a route for it that manages without 0.0.0.0: you bind Ollama to exactly the address at which the host is visible from inside the container, the gateway of the Docker network. You read that address out rather than guessing it:

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

Usually 172.17.0.1 comes out. That is what goes into the service, again via sudo systemctl edit ollama.service:

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

That address belongs to the Docker network and is not reachable from your own network. The container then still needs the bridge to the host:

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

The address in n8n is then http://host.docker.internal:11434. What matters is that both mean the same network: if your n8n container runs in a network of its own rather than the default one, take that network's gateway address, not the one from bridge.

On macOS and Windows this shortcut does not exist. Docker runs there in a small machine of its own, and the host is reachable for the container only via a binding to all interfaces. Closing it again is then only possible through the operating system's firewall, meaning a rule that rejects incoming connections on 11434 from the rest of the network. That is handwork, and handwork gets forgotten. So on those systems take the two-container constellation from above. That is not a workaround, it is simply the better setup.

Both in the same container. Rare, but it works without anything further, http://localhost:11434 is enough.

There is one more special case, and it looks like a Docker problem but is not one. If the message reads connect ECONNREFUSED ::1:11434, your system has resolved localhost to the IPv6 address while Ollama is listening on IPv4. The two then talk past each other. Enter http://127.0.0.1:11434 as the base address instead of http://localhost:11434 and it is settled. The two colons in front of the port number are the giveaway.

Tip: A fresh container brings no model with it, the volume is empty. Fetch one and check that it is there before you carry on in n8n:

docker exec ollama ollama pull <modelname>
docker exec ollama ollama list

With an installation without containers the two commands are simply ollama pull and ollama list. And note the -d --restart unless-stopped in all the examples: a container you start with -it --rm hangs off your terminal, disappears without a trace when you quit, and after a restart of the machine your automation does not come back up.

5. Create the credentials in n8n

In n8n you create a new Ollama entry under the credentials. The only mandatory field is the base address from step 4. A key is not needed for a local instance, that field stays empty.

After that you can test the connection directly in n8n. If the test passes, the hard part is done.

Tip: If your model runs on another machine on the network, none of the constellations above is enough. Then you need two things together. First an encrypted connection, so https:// with a checked certificate or a tunnel such as WireGuard. Over plain http:// the key, the prompts and the answers travel the network in the clear, and with that the purpose of this playbook is gone. Second a login in front of it, for example Open WebUI, whose Ollama endpoint sits under the path /ollama. The base address then looks like https://yourserver/ollama, and you put the key in the field next to it.

6. Know the difference between the three Ollama nodes

This is the trap that otherwise costs you an evening. n8n has three nodes for Ollama, and two of them look almost identical.

The first is plainly called Ollama Model. It cannot call tools. That is what the documentation says, and the consequence is unambiguous: it does not work with the AI Agent node. It belongs on the Basic LLM Chain.

The second is called Ollama Chat Model. That is the one you take for conversations and for anything that is meant to work with the agent.

The third is called Embeddings Ollama and produces no text at all but vectors. You only need it if you are filling a vector database locally. One rule belongs with it: filling and querying have to run with the same model. What happens otherwise depends on how similar the models are. If their vectors have different lengths, the database usually rejects the query with a clear message. If the lengths happen to match, you get no error at all, only poorer hits, and that is the more annoying case.

But the right node is only half the condition. Tool calls have to be supported by the model itself as well, and by no means all of them are. If you take a model without that ability, the node is wired correctly, the agent runs, and it still never uses a tool. Ollama lists the supported models in a category of their own, and that is the binding list when you pick one.

Tip: Note the rule of thumb in its complete form: chain takes Model, agent takes Chat Model plus a model from Ollama's tools category. Leave the second half out and you will look for the fault in a place where it is not.

7. Build the first flow with the Basic LLM Chain

Deliberately start small, not with an agent. The Basic LLM Chain does exactly one thing: it sends your text to the model and returns the answer. No memory, no tools, no decisions.

For the typical automation step that is exactly right. Filing an incoming message, summarising a text, pulling a field out of free text. The agent is only needed once the model is supposed to decide for itself which tool it uses.

There is one quirk you need to know, because it goes wrong quietly. The chain itself works through your records properly, one after another, each getting its own prompt. The attached model node, however, is a sub-node, and expressions in its own fields always resolve to the first record. So if you work with an expression inside the model node itself, for instance to pick a different model per record, you get the first one's choice five times. The flow runs through and reports nothing. In the chain's prompt this does not happen.

Tip: If you are unsure whether you need chain or agent: if you can write the steps down in advance, take the chain. The agent is for the case where you do not know them, and it costs you predictability in return.

8. Pick a small model with a narrow task

In chat you want the cleverest possible model. In automation you want the most predictable possible one. That is a different yardstick, and it almost always leads to a smaller model.

A flow always calls up the same task. A small model manages that one task reliably if you set the brief narrowly enough. And a small model answers faster, which at a thousand runs is the actual gain. Which size fits your hardware is in Which local model fits your hardware.

Tip: Resist the temptation to take the largest model in the flow that still runs. In bulk processing it is throughput that decides, not the last nuance of phrasing.

One more note on the selection: the model list in the n8n documentation is out of date, as of August 2026 it still shows names from the Llama 2 generation. Which models you really have is what ollama list on your own machine tells you. Take the output, not the list in the docs.

9. Expect different waiting times than with the cloud

A cloud provider answers ten simultaneous requests simultaneously. Your machine does not, in the default setting: Ollama handles one request at a time per model, because OLLAMA_NUM_PARALLEL is set to 1. If your flow runs in parallel, the requests queue up. You can raise the value, but you pay for it in memory.

You do not notice this in testing, because there you trigger one at a time. In live operation a timeout then runs into an error you never saw in the test run.

When looking for the timeout setting, many people end up in the model node. It is not there, the options schema of the Ollama Chat Model node has no request timeout. n8n handles this in three other places, and annoyingly they use different units. N8N_AI_TIMEOUT_MAX applies specifically to the AI nodes, so to Ollama as well, and stands at 3,600,000 milliseconds, which is one hour. EXECUTIONS_TIMEOUT limits every workflow and stands at -1 when self-hosted, so unlimited. EXECUTIONS_TIMEOUT_MAX is the ceiling a user may set in an individual workflow, in seconds, 3600 by default. On top of that come the settings of the workflow itself.

One more misunderstanding, because it costs time: a reverse proxy in front of n8n only limits how long your browser may wait for n8n. It has no influence on the call from n8n to Ollama. Anyone wanting a limit there has to put the proxy in front of Ollama.

A last setting sits with Ollama. OLLAMA_MAX_LOADED_MODELS is three on most platforms for pure processor inference, or three times the number of graphics cards; on Windows with a Radeon card it is currently one. Several models stay loaded at the same time only if they fit into the available memory together, otherwise there is unloading and waiting. On a tightly specified machine that waiting looks like an n8n error. If your workflow works with exactly one model anyway, set the variable to 1.

Tip: Test your flow once with twenty records in a row, not with one. Only then do you see the real behaviour, and specifically before it blows up on you in live operation.

10. Enforce the structure and keep your return ticket

A small model sticks to format requirements less well than a large one. If your next step in the flow expects clean JSON and the model writes an introductory sentence in front of it, the whole workflow breaks. Do not solve that with a politer prompt but with a node that checks the structure and asks again if in doubt. How to do that properly is in Reliable JSON out of AI.

And build the flow so that you can swap the AI node out without touching the rest. If the local route is not enough for a particular step, you want to be able to put a cloud node there and keep everything else.

There is a trap in that which undoes exactly the promise from the beginning. When you swap a local node for a cloud node, the same record travels on that the local model saw before, and in n8n a record often carries more fields than are visible in the prompt. Knowing which step sees what is therefore not enough. Put an Edit Fields node in front of every cloud branch, switch off "Include Other Input Fields" in it and explicitly map only the fields that are allowed to leave. Then look at the test run to see what was actually sent. For data that must not leave the building at all, there is no cloud branch, not even an emergency one.

Tip: Write yourself a note in the flow about which data is present at which node. In three months you will not know any more, and then you will make the decision again without knowing the basis for it.

What next

If you want to use the same connection not only in n8n but for your AI assistant itself, carry on with MCP with local models. If you want to know whether running a permanently powered machine pays off for you, the calculation is in Local or cloud, the honest calculation.

Sources

• n8n, Ollama Chat Model, node parameters and options: https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.lmchatollama/
• n8n, known issues of the Ollama Chat Model node, including the Docker constellations, IPv6 resolution and expression resolution in sub-nodes: https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.lmchatollama/common-issues/
• n8n, Ollama Model, note on the missing tool support: https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.lmollama/
• n8n, agent compared to chain: https://docs.n8n.io/advanced-ai/examples/understand-agents/
• n8n, Ollama credentials including bearer token: https://docs.n8n.io/integrations/builtin/credentials/ollama/
• n8n, the three time limits and their units: https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/executions/
• n8n, Edit Fields and passing fields on: https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.set/
• Ollama, cloud models through the local endpoint: https://docs.ollama.com/cloud
• Ollama, server configuration, disabling cloud, binding and concurrency: https://docs.ollama.com/faq
• Ollama, the local interface has no authentication: https://docs.ollama.com/api/authentication
• Ollama, models with tool support: https://ollama.com/blog/tool-support
• Docker, publishing ports and what changed with Engine 28: https://docs.docker.com/engine/network/port-publishing/
• Docker, starting containers automatically: https://docs.docker.com/engine/containers/start-containers-automatically/
• Open WebUI, the Ollama endpoint under /ollama: https://docs.openwebui.com/reference/api-endpoints/