My Ollama BASE URL keeps resetting to "http://ollama:11434"

Using self-hosted-ai-starter-kit and can’t connect to my Ollama

Hi all, total newbie here, I’m running into some critical blocker right away…
I’m sure I’m missing something obvious.

What is the error message (if any)?

In the default example workflow of a chat, I keep getting the error:

You have a connection issue or the server is down.
n8n should reconnect automatically once the issue is resolved.

I noticed that the BASE URL of Ollama (set in the Credentials tab) keeps returning to the default value which is not the right value for me.
I’m guessing it should be saved in a DB or file but it seems that it’s not…

I’m running n8n in a docker on a dedicated machine, using self-hosted-ai-starter-kit and my Ollama runs on another local machine.

The docker CAN connect to the Ollama server but as soon as I configure the URL in the credentials, it doesn’t stick.

Information on your n8n setup

  • n8n version: 1.83.2
  • Database (default: SQLite): Not sure but maybe PostgreSQL that comes with the docker?
  • n8n EXECUTIONS_PROCESS setting (default: own, main): not sure, but doesn’t seem related?
  • Running n8n via (Docker, npm, n8n cloud, desktop app): n8n on docker and Ollama on another reachable, local machine
  • Operating system: Raspberry pi 64bit Lite

Hi @Zohar

You’re on the right track, and this issue sounds familiar: the Ollama base URL in n8n keeps resetting, which breaks your connection to your local Ollama instance running on another machine. The fact that your Docker container can reach Ollama but the credential doesn’t persist confirms it’s a config issue, not a network one.

What’s happening

n8n stores credentials (like the Ollama base URL) in the database — likely PostgreSQL in your case — but it won’t save them properly if:

  1. You’re editing them inside the UI without clicking “Save”.
  2. Your environment is using read-only credentials (e.g. predefined via env or Docker volume and not editable).
  3. Your Ollama base URL gets overwritten at container startup due to the Docker Compose config.

And yes, the OLLAMA_HOST env variable will override the URL you enter in the UI if it’s defined.


How to fix this

Since you’re running Ollama on a different machine, you need to do two things:

1. Set the OLLAMA_HOST variable correctly in Docker Compose

In your docker-compose.yml, find the n8n service section and update like this:

environment:
  - OLLAMA_HOST=http://<your-ollama-ip>:11434

If you’re using Docker on the same machine (Mac/Linux), you can also try:

  - OLLAMA_HOST=http://host.docker.internal:11434

2. Remove or clear the default Ollama credential if it’s stuck

Sometimes the credential created by the starter kit has a default value hardcoded in the database. To reset it:

  • Go to n8n UI → Credentials
  • Find the Local Ollama Service credential
  • Update the base URL manually
  • Click Save
  • Then test it by opening a workflow and running a simple Ollama call

If it still resets, delete the credential entirely and re-add it with the correct base URL.


Final check

Once you’ve updated the OLLAMA_HOST env var and saved the correct value in the credentials:

  • Restart the container: docker compose restart n8n
  • Open n8n UI
  • Run the chat workflow again

It should now connect successfully to the correct Ollama instance and the error message should disappear.

Let me know if you need help checking the IP or hostname of your other machine where Ollama is running.

I hope this helps.

1 Like

@Miquel_Colomer that’s one of the best replies I ever got in a community forum! :star2:

Alas, I’m still experiencing the same problem. Let me try and first reply to your suggestions, then see if I can identify the root cause of the problem:

  1. You’re editing them inside the UI without clicking “Save”.

I did click “save”, but it gets overridden. See the next bullet for the solution I came up with.

  1. Your environment is using read-only credentials (e.g. predefined via env or Docker

So in order to overcome this and the previous bullet point, I created a new Credential for the same Ollama server - this config persists after a restart (saved only in DB and not in a file). As can be seen below, the couple of models I’m hosting locally are identified.

What’s next?

So I managed to have persistent Ollama credentials for my workflow (even though I only bypassed the problem, and haven’t really solved it).
The UI still shows the following error messages:

I’m asking myself what is this server I lost connection with. If it’s not Ollama, is it n8n itself?
What is the proper way to debug this message?

Another place where I suspect my config may be wrong, and based on a guts feeling I’d like to verify, is the nginx reverse proxy config.
In my case, n8n is running on the same machine as nginx (so localhost).
The main line I’m not sure about is
location /api/websocket/ {
:point_down:

server {
    listen 443;
    server_name n8n.example.com;
    ssl_certificate /etc/letsencrypt/live/n8n.example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/n8n.example.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; 

    location / {
        proxy_pass http://localhost:5678;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
    
    # WebSocket support 
    location /api/websocket/ {
        proxy_pass http://localhost:5678/api/websocket/;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }

}

Does that give any clues I should check out?

Hi @Zohar

You’re spot on suspecting both the reverse proxy and the “server lost connection” message — that’s a classic WebSocket disconnection issue, and yes, it refers to n8n, not Ollama.

Here’s how to debug and improve your setup.


What “Lost Connection” Actually Means

That message usually shows up in the UI when the WebSocket connection between your browser and n8n server is lost, often due to:

A misconfigured NGINX reverse proxy

WebSocket traffic not being upgraded correctly

Timeout or low memory (esp. on 512MB droplets)


Let’s Review Your NGINX Config

Your config looks mostly right, but here’s a refined version with a few fixes and clarifications:

:white_check_mark: Updated NGINX Config

server {
listen 443 ssl;
server_name n8n.example.com;

ssl_certificate /etc/letsencrypt/live/n8n.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/n8n.example.com/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

# Increase buffer size for large payloads (optional, but good for AI/large responses)
client_max_body_size 100M;

location / {
    proxy_pass http://localhost:5678;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

# Explicit WebSocket path
location /api/websocket/ {
    proxy_pass http://localhost:5678/api/websocket/;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

}


Other Things to Check

  1. ENV Vars

Make sure n8n knows it’s behind a proxy. Add these in your .env:

VUE_APP_URL_BASE_API=https://n8n.example.com/
WEBHOOK_TUNNEL_URL=https://n8n.example.com/
N8N_HOST=localhost
N8N_PORT=5678
N8N_PROTOCOL=http
N8N_EDITOR_BASE_URL=https://n8n.example.com
N8N_DIAGNOSTICS_ENABLED=false

  1. Memory & Swap

Still on 512MB? If so, add swap (as in the previous message), or upgrade to 1GB minimum.

  1. Check Browser Console

When you see that “lost connection” error, press F12 → Console and check network tab for /api/websocket/. If it’s red with 101 or timeout errors, it confirms the WebSocket upgrade failed.


How to Debug Properly

Use curl to test WebSocket connection:

curl -i -N -H “Connection: Upgrade” -H “Upgrade: websocket”
-H “Host: n8n.example.com” -H “Origin: https://n8n.example.com
http://localhost:5678/api/websocket/

Run nginx -t && sudo systemctl reload nginx

Watch logs: tail -f /var/log/nginx/error.log and n8n logs

I hope this helps.

2 Likes

YES! The connection error is gone and I can now connect to my Ollama server :slight_smile:
Unfortunately I made several changes in a bulk so I don’t know exactly which one solved the problem:

  1. Increased my SWAP memory to 1GB (running on a rpi4 with 4gb RAM)
  2. Used your proposed nginx config above
  3. Added some missing variables to .env

My chat now works… sort of. I’m getting a Problem in node Basic LLM Chain. fetch failed error, but I’ll probably create a separate issue for that if I don’t find the cause myself.

Many thanks @Miquel_Colomer ! :pray:

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.