github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-07 08:30:05 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[GH-ISSUE #849] How to secure the API with api key #46918

New Issue
Closed
opened 2026-04-28 02:05:40 -05:00 by GiteaMirror · 36 comments
GiteaMirror commented 2026-04-28 02:05:40 -05:00
Owner
Copy Link

Originally created by @ajasingh on GitHub (Oct 20, 2023).
Original GitHub issue: https://github.com/ollama/ollama/issues/849

We have deployed OLLAMA container with zephyr model inside kubernetes , so as a best practice we want to secure the endpoints via api key similar way to OpenAI , so is there any way to do this ?

Originally created by @ajasingh on GitHub (Oct 20, 2023). Original GitHub issue: https://github.com/ollama/ollama/issues/849 We have deployed OLLAMA container with zephyr model inside kubernetes , so as a best practice we want to secure the endpoints via api key similar way to OpenAI , so is there any way to do this ?
GiteaMirror commented 2026-04-28 02:05:42 -05:00
Author
Owner
Copy Link

@BruceMacD commented on GitHub (Oct 20, 2023):

The solution to this for the time being would be to add an authenticating proxy in front of Ollama (ex: nginx with basic auth)

<!-- gh-comment-id:1772900688 --> @BruceMacD commented on GitHub (Oct 20, 2023): The solution to this for the time being would be to add an authenticating proxy in front of Ollama (ex: nginx with basic auth)
GiteaMirror commented 2026-04-28 02:05:43 -05:00
Author
Owner
Copy Link

@coolaj86 commented on GitHub (Oct 21, 2023):

Here's how you add HTTP Basic Auth with caddy as a reverse proxy to localhost:11434, and also handle HTTPS automatically:

  1. Install caddy 
    # Mac, Linux
curl https://webi.sh/caddy | sh

# Windows
curl.exe https://webi.ms/caddy | powershell
  2. Put your password (which could be an API Token) in a password.txt
  3. Digest the password 
    caddy hash-password < ./password.txt
  4. Put the username and digest in an ENV file
    caddy.env: 
    BASIC_AUTH_USER='apitoken'
BASIC_USER_AUTH='$2a$14$sI1j0RbhzKHMZ4cHU8otHOkB3Dgl9egF2D.CXB6C0/Qk5dtaMHS/u'
  5. Create a Caddyfile with basic auth using the ENVs 
    api.example.com {
    handle /* {
        basicauth {
            {env.BASIC_AUTH_USERNAME} {env.BASIC_AUTH_DIGEST}
        }
        reverse_proxy localhost:11434
    }
}
  6. Run caddy 
    caddy run --config ./Caddyfile --envfile ./caddy.env

And if you want to run it as a system service, or without HTTPS or need other details, I've got a bunch of snippets up at https://webinstall.dev/caddy.

<!-- gh-comment-id:1773697189 --> @coolaj86 commented on GitHub (Oct 21, 2023): Here's how you add HTTP Basic Auth with `caddy` as a reverse proxy to `localhost:11434`, and also handle HTTPS automatically: 0. Install caddy ```sh # Mac, Linux curl https://webi.sh/caddy | sh # Windows curl.exe https://webi.ms/caddy | powershell ``` 1. Put your password (which could be an API Token) in a `password.txt` 2. Digest the password ```sh caddy hash-password < ./password.txt ``` 3. Put the username and digest in an ENV file \ `caddy.env`: ``` BASIC_AUTH_USER='apitoken' BASIC_USER_AUTH='$2a$14$sI1j0RbhzKHMZ4cHU8otHOkB3Dgl9egF2D.CXB6C0/Qk5dtaMHS/u' ``` 4. Create a `Caddyfile` with basic auth using the ENVs ```Caddyfile api.example.com { handle /* { basicauth { {env.BASIC_AUTH_USERNAME} {env.BASIC_AUTH_DIGEST} } reverse_proxy localhost:11434 } } ``` 5. Run caddy ```sh caddy run --config ./Caddyfile --envfile ./caddy.env ``` And if you want to run it as a system service, or _without_ HTTPS or need other details, I've got a bunch of snippets up at <https://webinstall.dev/caddy>.
GiteaMirror commented 2026-04-28 02:05:45 -05:00
Author
Owner
Copy Link

@ParisNeo commented on GitHub (Jan 9, 2024):

With caddy you can also do multiple users. You can create a little interface to add users and serve it with the tool. That makes using ollama much safer

<!-- gh-comment-id:1882654877 --> @ParisNeo commented on GitHub (Jan 9, 2024): With caddy you can also do multiple users. You can create a little interface to add users and serve it with the tool. That makes using ollama much safer
GiteaMirror commented 2026-04-28 02:05:46 -05:00
Author
Owner
Copy Link

@DimIsaev commented on GitHub (Jan 15, 2024):

why the authorization mechanism cannot be built into the ollama server?

<!-- gh-comment-id:1891786135 --> @DimIsaev commented on GitHub (Jan 15, 2024): why the authorization mechanism cannot be built into the ollama server?
GiteaMirror commented 2026-04-28 02:05:46 -05:00
Author
Owner
Copy Link

@ParisNeo commented on GitHub (Jan 16, 2024):

If you are interested, I have built a proxy server for ollama:
https://github.com/ParisNeo/ollama_proxy_server

It allows those features:
1 - Authentication with user:key Bearer
2 - Adding new users
3 - Logging access to the service (useful for statictics). By default the proxy doesn't log your requests, it only logs that you requested generation which is useful for statistics and for dimensionning the network.
4 - Routing to multiple ollama instances. For example you can have multiple ollama servers and use a single endpoint that will take care of dispatching the generation requests to the different servers . Each server has its own generation queue and the proxy will always forward the request to the server with the least number of requests in the queue. This makes it possible to serve simultaniously multiple clients while garanteeing a minimum latency.

Ollama is a very powerful and fast generation tool. But I think with the new proxy, it takes the potential to a new level.

As client I use lollms (obviously) :)
https://github.com/ParisNeo/lollms-webui

<!-- gh-comment-id:1893574114 --> @ParisNeo commented on GitHub (Jan 16, 2024): If you are interested, I have built a proxy server for ollama: https://github.com/ParisNeo/ollama_proxy_server It allows those features: 1 - Authentication with user:key Bearer 2 - Adding new users 3 - Logging access to the service (useful for statictics). By default the proxy doesn't log your requests, it only logs that you requested generation which is useful for statistics and for dimensionning the network. 4 - Routing to multiple ollama instances. For example you can have multiple ollama servers and use a single endpoint that will take care of dispatching the generation requests to the different servers . Each server has its own generation queue and the proxy will always forward the request to the server with the least number of requests in the queue. This makes it possible to serve simultaniously multiple clients while garanteeing a minimum latency. Ollama is a very powerful and fast generation tool. But I think with the new proxy, it takes the potential to a new level. As client I use lollms (obviously) :) https://github.com/ParisNeo/lollms-webui
GiteaMirror commented 2026-04-28 02:05:47 -05:00
Author
Owner
Copy Link

@jamieduk commented on GitHub (Mar 11, 2024):

by default does it require api key for it to work how do i find this api key or it not use any api key for the web ui that i have working with ollama ? im on linux and use http://localhost:8080/ but ofc it has a backend port and python code im trying to use as an agent is asking for an api key any one help clarify please?

p.s i may of solved it

cd ~/Documents/Scripts/AI/Ollama/open-webui/backend

cat .webui_secret_key

<!-- gh-comment-id:1988585028 --> @jamieduk commented on GitHub (Mar 11, 2024): by default does it require api key for it to work how do i find this api key or it not use any api key for the web ui that i have working with ollama ? im on linux and use http://localhost:8080/ but ofc it has a backend port and python code im trying to use as an agent is asking for an api key any one help clarify please? p.s i may of solved it cd ~/Documents/Scripts/AI/Ollama/open-webui/backend cat .webui_secret_key
GiteaMirror commented 2026-04-28 02:05:48 -05:00
Author
Owner
Copy Link

@alx-xlx commented on GitHub (May 30, 2024):

@coolaj86 Hey I tried to use your steps, I am running it on macos, but I get this error

Error: loading initial config: loading new config: loading http app module: provision http: server srv0: setting up route handlers: route 0: loading handler modules: position 0: loading module 'subroute': provision http.handlers.subroute: setting up subroutes: route 0: loading handler modules: position 0: loading module 'subroute': provision http.handlers.subroute: setting up subroutes: route 0: loading handler modules: position 0: loading module 'authentication': provision http.handlers.authentication: loading authentication providers: module name 'http_basic': provision http.authentication.providers.http_basic: account 0: username and password are required

HERE is my config

BASIC_AUTH_USER='apitoken'
BASIC_USER_AUTH='$2a$14$Z7jW916wS4WAmpUBBuuEreMu51s09pC1I/exwdaHtPENtsxAhuniK'

api-ollama.example.org {
    tls {
        dns cloudflare _Q*************************-VP
    }
    handle /* {
        basicauth {
            {env.BASIC_AUTH_USERNAME} {env.BASIC_AUTH_DIGEST}
        }
        reverse_proxy localhost:11434
    }
}
<!-- gh-comment-id:2139258343 --> @alx-xlx commented on GitHub (May 30, 2024): @coolaj86 Hey I tried to use your steps, I am running it on macos, but I get this error ``` Error: loading initial config: loading new config: loading http app module: provision http: server srv0: setting up route handlers: route 0: loading handler modules: position 0: loading module 'subroute': provision http.handlers.subroute: setting up subroutes: route 0: loading handler modules: position 0: loading module 'subroute': provision http.handlers.subroute: setting up subroutes: route 0: loading handler modules: position 0: loading module 'authentication': provision http.handlers.authentication: loading authentication providers: module name 'http_basic': provision http.authentication.providers.http_basic: account 0: username and password are required ``` HERE is my config ``` BASIC_AUTH_USER='apitoken' BASIC_USER_AUTH='$2a$14$Z7jW916wS4WAmpUBBuuEreMu51s09pC1I/exwdaHtPENtsxAhuniK' ``` ``` api-ollama.example.org { tls { dns cloudflare _Q*************************-VP } handle /* { basicauth { {env.BASIC_AUTH_USERNAME} {env.BASIC_AUTH_DIGEST} } reverse_proxy localhost:11434 } } ```
GiteaMirror commented 2026-04-28 02:05:49 -05:00
Author
Owner
Copy Link

@tandriamil commented on GitHub (May 31, 2024):

The environment variables do not match in this example. Try replacing env.BASIC_AUTH_USERNAME by env.BASIC_AUTH_USER and env.BASIC_AUTH_DIGEST by BASIC_USER_AUTH. 😉

<!-- gh-comment-id:2141459897 --> @tandriamil commented on GitHub (May 31, 2024): The environment variables do not match in this example. Try replacing `env.BASIC_AUTH_USERNAME` by `env.BASIC_AUTH_USER` and `env.BASIC_AUTH_DIGEST` by `BASIC_USER_AUTH`. 😉
GiteaMirror commented 2026-04-28 02:05:49 -05:00
Author
Owner
Copy Link

@alx-xlx commented on GitHub (May 31, 2024):

I am using this configuration and it does prompt me to enter username and password, however when I do so it gives ERROR : 403

api-ollama.example.org {
    tls {
        dns cloudflare _QRi******************5u-VP
    }
    handle /* {
        basicauth {
            {env.BASIC_AUTH_USER} {env.BASIC_USER_AUTH}
        }
        reverse_proxy localhost:11434
    }
    log {
        output file /Users/USERNAME/Server/data/customcaddy/api-ollama.log {
            roll_size 100mb
            roll_keep 5
            roll_keep_for 720h
        }
    }
}

Logs when I enter the username and password

2024/05/31 09: 36: 37.104	error	http.log.access.log0	handled request	{
    "request": {
        "remote_ip": "192.168.0.122",
        "remote_port": "62601",
        "client_ip": "192.168.0.122",
        "proto": "HTTP/2.0",
        "method": "GET",
        "host": "api-ollama.example.org",
        "uri": "/",
        "headers": {
            "User-Agent": [
                "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36"
            ],
            "Sec-Fetch-User": [
                "?1"
            ],
            "Sec-Fetch-Dest": [
                "document"
            ],
            "Sec-Ch-Ua-Mobile": [
                "?0"
            ],
            "Sec-Ch-Ua": [
                "\"Google Chrome\";v=\"125\", \"Chromium\";v=\"125\", \"Not.A/Brand\";v=\"24\""
            ],
            "Sec-Fetch-Mode": [
                "navigate"
            ],
            "Accept-Encoding": [
                "gzip, deflate, br, zstd"
            ],
            "Save-Data": [
                "on"
            ],
            "Authorization": [],
            "Accept-Language": [
                "en-US,en;q=0.9,hi;q=0.8"
            ],
            "Priority": [
                "u=0, i"
            ],
            "Sec-Ch-Ua-Platform": [
                "\"Windows\""
            ],
            "Upgrade-Insecure-Requests": [
                "1"
            ],
            "Accept": [
                "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7"
            ],
            "Sec-Fetch-Site": [
                "none"
            ],
            "Cache-Control": [
                "max-age=0"
            ]
        },
        "tls": {
            "resumed": false,
            "version": 772,
            "cipher_suite": 4865,
            "proto": "h2",
            "server_name": "api-ollama.example.org"
        }
    },
    "bytes_read": 0,
    "user_id": "admin",
    "duration": 0.994463625,
    "size": 0,
    "status": 403,
    "resp_headers": {
        "Date": [
            "Fri, 31 May 2024 09:36:37 GMT"
        ],
        "Content-Length": [
            "0"
        ],
        "Server": [
            "Caddy"
        ],
        "Alt-Svc": [
            "h3=\":443\"; ma=2592000"
        ]
    }
}
<!-- gh-comment-id:2141621168 --> @alx-xlx commented on GitHub (May 31, 2024): I am using this configuration and it does prompt me to enter username and password, however when I do so it gives `ERROR : 403` ``` api-ollama.example.org { tls { dns cloudflare _QRi******************5u-VP } handle /* { basicauth { {env.BASIC_AUTH_USER} {env.BASIC_USER_AUTH} } reverse_proxy localhost:11434 } log { output file /Users/USERNAME/Server/data/customcaddy/api-ollama.log { roll_size 100mb roll_keep 5 roll_keep_for 720h } } } ``` Logs when I enter the username and password ``` 2024/05/31 09: 36: 37.104 error http.log.access.log0 handled request { "request": { "remote_ip": "192.168.0.122", "remote_port": "62601", "client_ip": "192.168.0.122", "proto": "HTTP/2.0", "method": "GET", "host": "api-ollama.example.org", "uri": "/", "headers": { "User-Agent": [ "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36" ], "Sec-Fetch-User": [ "?1" ], "Sec-Fetch-Dest": [ "document" ], "Sec-Ch-Ua-Mobile": [ "?0" ], "Sec-Ch-Ua": [ "\"Google Chrome\";v=\"125\", \"Chromium\";v=\"125\", \"Not.A/Brand\";v=\"24\"" ], "Sec-Fetch-Mode": [ "navigate" ], "Accept-Encoding": [ "gzip, deflate, br, zstd" ], "Save-Data": [ "on" ], "Authorization": [], "Accept-Language": [ "en-US,en;q=0.9,hi;q=0.8" ], "Priority": [ "u=0, i" ], "Sec-Ch-Ua-Platform": [ "\"Windows\"" ], "Upgrade-Insecure-Requests": [ "1" ], "Accept": [ "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7" ], "Sec-Fetch-Site": [ "none" ], "Cache-Control": [ "max-age=0" ] }, "tls": { "resumed": false, "version": 772, "cipher_suite": 4865, "proto": "h2", "server_name": "api-ollama.example.org" } }, "bytes_read": 0, "user_id": "admin", "duration": 0.994463625, "size": 0, "status": 403, "resp_headers": { "Date": [ "Fri, 31 May 2024 09:36:37 GMT" ], "Content-Length": [ "0" ], "Server": [ "Caddy" ], "Alt-Svc": [ "h3=\":443\"; ma=2592000" ] } } ```
GiteaMirror commented 2026-04-28 02:05:51 -05:00
Author
Owner
Copy Link

@dheavy commented on GitHub (Jun 2, 2024):

Sorry, this isn't solving the precise issue discussed on the couple of previous messages, but as an alternative solution for the subject of this thread -- I have developed a quickly deployable solution to not have to deal with nginx

https://github.com/dheavy/ollama-secure-proxy

<!-- gh-comment-id:2143814918 --> @dheavy commented on GitHub (Jun 2, 2024): Sorry, this isn't solving the precise issue discussed on the couple of previous messages, but as an alternative solution for the subject of this thread -- I have developed a quickly deployable solution to not have to deal with nginx https://github.com/dheavy/ollama-secure-proxy
GiteaMirror commented 2026-04-28 02:05:51 -05:00
Author
Owner
Copy Link

@bartolli commented on GitHub (Jun 6, 2024):

I was playing for a few days to get the Ollama Go and the llama.cpp server to work with native api_key authentication but didn't have much luck with the custom build. It seems Ollama build does not rebuild llama.cpp, or at least I didn't figure it out how. So, I created a Docker image with a Caddy server to securely manage authentication and proxy requests to a local Ollama instance. You can choose between two methods: environment-based API key validation or using multiple API keys stored in a .conf file for extra security. Check out these repos:

For using OLLAMA_API_KEY as a local environment variable:
https://github.com/bartolli/ollama-bearer-auth

For supporting multiple API keys stored in a config file, check out this repo:
https://github.com/bartolli/ollama-bearer-auth-caddy.

<!-- gh-comment-id:2152140905 --> @bartolli commented on GitHub (Jun 6, 2024): I was playing for a few days to get the Ollama Go and the llama.cpp server to work with native `api_key` authentication but didn't have much luck with the custom build. It seems Ollama build does not rebuild llama.cpp, or at least I didn't figure it out how. So, I created a Docker image with a Caddy server to securely manage authentication and proxy requests to a local Ollama instance. You can choose between two methods: environment-based API key validation or using multiple API keys stored in a `.conf` file for extra security. Check out these repos: For using `OLLAMA_API_KEY` as a local environment variable: https://github.com/bartolli/ollama-bearer-auth For supporting multiple API keys stored in a config file, check out this repo: https://github.com/bartolli/ollama-bearer-auth-caddy.
GiteaMirror commented 2026-04-28 02:05:52 -05:00
Author
Owner
Copy Link

@chigkim commented on GitHub (Jun 22, 2024):

It would be great for Ollama to directly support api token with ssl!

<!-- gh-comment-id:2183599391 --> @chigkim commented on GitHub (Jun 22, 2024): It would be great for Ollama to directly support api token with ssl!
GiteaMirror commented 2026-04-28 02:05:53 -05:00
Author
Owner
Copy Link

@SomeoneSerge commented on GitHub (Sep 20, 2024):

The solution to this for the time being would be to add an authenticating proxy in front of Ollama (ex: nginx with basic auth)

Note: https://github.com/ollama/ollama/issues/739 would allow to accomplish this in a simple systemd unit, without doing anything cursed about network namespaces

<!-- gh-comment-id:2362446501 --> @SomeoneSerge commented on GitHub (Sep 20, 2024): > The solution to this for the time being would be to add an authenticating proxy in front of Ollama (ex: nginx with basic auth) Note: https://github.com/ollama/ollama/issues/739 would allow to accomplish this in a simple systemd unit, without doing anything cursed about network namespaces
GiteaMirror commented 2026-04-28 02:05:55 -05:00
Author
Owner
Copy Link

@kesor commented on GitHub (Oct 11, 2024):

I also created "The Solution" using nginx and an authentication check, sitting inside a docker container. Using Cloudflare Tunnel has the added benefit of SSL encryption as well. https://github.com/kesor/ollama-proxy

<!-- gh-comment-id:2407831864 --> @kesor commented on GitHub (Oct 11, 2024): I also created "The Solution" using nginx and an authentication check, sitting inside a docker container. Using Cloudflare Tunnel has the added benefit of SSL encryption as well. https://github.com/kesor/ollama-proxy
GiteaMirror commented 2026-04-28 02:05:55 -05:00
Author
Owner
Copy Link

@KaKi87 commented on GitHub (Feb 9, 2025):

Hello @mxyng,
Why is this feature discarded ?
Thank you

<!-- gh-comment-id:2646431245 --> @KaKi87 commented on GitHub (Feb 9, 2025): Hello @mxyng, Why is this feature discarded ? Thank you
GiteaMirror commented 2026-04-28 02:05:56 -05:00
Author
Owner
Copy Link

@frederikb96 commented on GitHub (Feb 25, 2025):

Here's how you add HTTP Basic Auth with caddy as a reverse proxy to localhost:11434, and also handle HTTPS automatically:

0. Install caddy
   # Mac, Linux
   curl https://webi.sh/caddy | sh
   
   # Windows
   curl.exe https://webi.ms/caddy | powershell

1. Put your password (which could be an API Token) in a `password.txt`

2. Digest the password
   caddy hash-password < ./password.txt

3. Put the username and digest in an ENV file 
   `caddy.env`:
   ```
   BASIC_AUTH_USER='apitoken'
   BASIC_USER_AUTH='$2a$14$sI1j0RbhzKHMZ4cHU8otHOkB3Dgl9egF2D.CXB6C0/Qk5dtaMHS/u'
   ```

4. Create a `Caddyfile` with basic auth using the ENVs
   api.example.com {
       handle /* {
           basicauth {
               {env.BASIC_AUTH_USERNAME} {env.BASIC_AUTH_DIGEST}
           }
           reverse_proxy localhost:11434
       }
   }

5. Run caddy
   caddy run --config ./Caddyfile --envfile ./caddy.env

And if you want to run it as a system service, or without HTTPS or need other details, I've got a bunch of snippets up at https://webinstall.dev/caddy.

This is deprecated by now. You can instead try this, which works for me together with API Key auth and I am able to use it with openai connectors which require API Key auth:

nano caddy.env

API_KEY='some-key'

nano Caddyfile

api.example.com {
	# if you have 80 and 443 open on the ollama server, you can specify tls and caddy automatically sets up SSL for you such that external connectors securely connect to your Ollama API with SSL and do not complain about certificates
	# tls somemail@mail.com
	
	@requireAuth {
		not header Authorization "Bearer {env.API_KEY}"
	}

	respond @requireAuth "Unauthorized" 401

	reverse_proxy localhost:11434
}
<!-- gh-comment-id:2681692243 --> @frederikb96 commented on GitHub (Feb 25, 2025): > Here's how you add HTTP Basic Auth with `caddy` as a reverse proxy to `localhost:11434`, and also handle HTTPS automatically: > > 0. Install caddy > # Mac, Linux > curl https://webi.sh/caddy | sh > > # Windows > curl.exe https://webi.ms/caddy | powershell > > 1. Put your password (which could be an API Token) in a `password.txt` > > 2. Digest the password > caddy hash-password < ./password.txt > > 3. Put the username and digest in an ENV file > `caddy.env`: > ``` > BASIC_AUTH_USER='apitoken' > BASIC_USER_AUTH='$2a$14$sI1j0RbhzKHMZ4cHU8otHOkB3Dgl9egF2D.CXB6C0/Qk5dtaMHS/u' > ``` > > 4. Create a `Caddyfile` with basic auth using the ENVs > api.example.com { > handle /* { > basicauth { > {env.BASIC_AUTH_USERNAME} {env.BASIC_AUTH_DIGEST} > } > reverse_proxy localhost:11434 > } > } > > 5. Run caddy > caddy run --config ./Caddyfile --envfile ./caddy.env > > > And if you want to run it as a system service, or _without_ HTTPS or need other details, I've got a bunch of snippets up at https://webinstall.dev/caddy. This is deprecated by now. You can instead try this, which works for me together with API Key auth and I am able to use it with openai connectors which require API Key auth: ``` nano caddy.env ``` ``` API_KEY='some-key' ``` ``` nano Caddyfile ``` ``` api.example.com { # if you have 80 and 443 open on the ollama server, you can specify tls and caddy automatically sets up SSL for you such that external connectors securely connect to your Ollama API with SSL and do not complain about certificates # tls somemail@mail.com @requireAuth { not header Authorization "Bearer {env.API_KEY}" } respond @requireAuth "Unauthorized" 401 reverse_proxy localhost:11434 } ```
GiteaMirror commented 2026-04-28 02:05:58 -05:00
Author
Owner
Copy Link

@vadimkantorov commented on GitHub (Apr 3, 2025):

I agree, supporting a basic API key / basic auth would be a great feature for basic bootstrapping / testing ollama (without having to also configure/test nginx for proxy). Similar to how Jupyter Hub supports a username/password out of the box - to avoid bots scanning the internet for ollama endpoints

<!-- gh-comment-id:2775425699 --> @vadimkantorov commented on GitHub (Apr 3, 2025): I agree, supporting a basic API key / basic auth would be a great feature for basic bootstrapping / testing ollama (without having to also configure/test nginx for proxy). Similar to how Jupyter Hub supports a username/password out of the box - to avoid bots scanning the internet for ollama endpoints
GiteaMirror commented 2026-04-28 02:06:01 -05:00
Author
Owner
Copy Link

@sanjibnarzary commented on GitHub (Apr 8, 2025):

APISix from Apache is very Good in this scenario.

<!-- gh-comment-id:2787228800 --> @sanjibnarzary commented on GitHub (Apr 8, 2025): APISix from Apache is very Good in this scenario.
GiteaMirror commented 2026-04-28 02:06:03 -05:00
Author
Owner
Copy Link

@hansenz42 commented on GitHub (May 14, 2025):

Here's how you add HTTP Basic Auth with caddy as a reverse proxy to localhost:11434, and also handle HTTPS automatically:

0. Install caddy
   # Mac, Linux
   curl https://webi.sh/caddy | sh
   
   # Windows
   curl.exe https://webi.ms/caddy | powershell

1. Put your password (which could be an API Token) in a `password.txt`

2. Digest the password
   caddy hash-password < ./password.txt

3. Put the username and digest in an ENV file 
   `caddy.env`:

BASIC_AUTH_USER='apitoken'
BASIC_USER_AUTH='$2a$14$sI1j0RbhzKHMZ4cHU8otHOkB3Dgl9egF2D.CXB6C0/Qk5dtaMHS/u'


4. Create a `Caddyfile` with basic auth using the ENVs
api.example.com {
    handle /* {
        basicauth {
            {env.BASIC_AUTH_USERNAME} {env.BASIC_AUTH_DIGEST}
        }
        reverse_proxy localhost:11434
    }
}

5. Run caddy
caddy run --config ./Caddyfile --envfile ./caddy.env

And if you want to run it as a system service, or without HTTPS or need other details, I've got a bunch of snippets up at https://webinstall.dev/caddy.

This is deprecated by now. You can instead try this, which works for me together with API Key auth and I am able to use it with openai connectors which require API Key auth:

nano caddy.env

API_KEY='some-key'

nano Caddyfile

api.example.com {
	# if you have 80 and 443 open on the ollama server, you can specify tls and caddy automatically sets up SSL for you such that external connectors securely connect to your Ollama API with SSL and do not complain about certificates
	# tls somemail@mail.com
	
	@requireAuth {
		not header Authorization "Bearer {env.API_KEY}"
	}

	respond @requireAuth "Unauthorized" 401

	reverse_proxy localhost:11434
}

After testing with curl, I found that when accessing via some "api.example.com", you need to set the reverse proxy header to localhost. Otherwise, Ollama will deny the request with a 403 error:

api.example.com {
	# if you have 80 and 443 open on the ollama server, you can specify tls and caddy automatically sets up SSL for you such that external connectors securely connect to your Ollama API with SSL and do not complain about certificates
	# tls somemail@mail.com
	
	@requireAuth {
		not header Authorization "Bearer {env.API_KEY}"
	}

	respond @requireAuth "Unauthorized" 401

	reverse_proxy localhost:11434 {
               header_up Host 127.0.0.1:11434
        }
}
<!-- gh-comment-id:2879102916 --> @hansenz42 commented on GitHub (May 14, 2025): > > Here's how you add HTTP Basic Auth with `caddy` as a reverse proxy to `localhost:11434`, and also handle HTTPS automatically: > > ``` > > 0. Install caddy > > # Mac, Linux > > curl https://webi.sh/caddy | sh > > > > # Windows > > curl.exe https://webi.ms/caddy | powershell > > > > 1. Put your password (which could be an API Token) in a `password.txt` > > > > 2. Digest the password > > caddy hash-password < ./password.txt > > > > 3. Put the username and digest in an ENV file > > `caddy.env`: > > ``` > > BASIC_AUTH_USER='apitoken' > > BASIC_USER_AUTH='$2a$14$sI1j0RbhzKHMZ4cHU8otHOkB3Dgl9egF2D.CXB6C0/Qk5dtaMHS/u' > > ``` > > > > 4. Create a `Caddyfile` with basic auth using the ENVs > > api.example.com { > > handle /* { > > basicauth { > > {env.BASIC_AUTH_USERNAME} {env.BASIC_AUTH_DIGEST} > > } > > reverse_proxy localhost:11434 > > } > > } > > > > 5. Run caddy > > caddy run --config ./Caddyfile --envfile ./caddy.env > > ``` > > > > > > > > > > > > > > > > > > > > > > > > And if you want to run it as a system service, or _without_ HTTPS or need other details, I've got a bunch of snippets up at https://webinstall.dev/caddy. > > This is deprecated by now. You can instead try this, which works for me together with API Key auth and I am able to use it with openai connectors which require API Key auth: > > ``` > nano caddy.env > ``` > > ``` > API_KEY='some-key' > ``` > > ``` > nano Caddyfile > ``` > > ``` > api.example.com { > # if you have 80 and 443 open on the ollama server, you can specify tls and caddy automatically sets up SSL for you such that external connectors securely connect to your Ollama API with SSL and do not complain about certificates > # tls somemail@mail.com > > @requireAuth { > not header Authorization "Bearer {env.API_KEY}" > } > > respond @requireAuth "Unauthorized" 401 > > reverse_proxy localhost:11434 > } > ``` After testing with curl, I found that when accessing via some "api.example.com", you need to set the reverse proxy header to localhost. Otherwise, Ollama will deny the request with a 403 error: ``` api.example.com { # if you have 80 and 443 open on the ollama server, you can specify tls and caddy automatically sets up SSL for you such that external connectors securely connect to your Ollama API with SSL and do not complain about certificates # tls somemail@mail.com @requireAuth { not header Authorization "Bearer {env.API_KEY}" } respond @requireAuth "Unauthorized" 401 reverse_proxy localhost:11434 { header_up Host 127.0.0.1:11434 } } ```
GiteaMirror commented 2026-04-28 02:06:04 -05:00
Author
Owner
Copy Link

@PJ-568 commented on GitHub (May 16, 2025):

Reply

Here's how you add HTTP Basic Auth with caddy as a reverse proxy to localhost:11434, and also handle HTTPS automatically:

0. Install caddy
   # Mac, Linux
   curl https://webi.sh/caddy | sh
   
   # Windows
   curl.exe https://webi.ms/caddy | powershell

1. Put your password (which could be an API Token) in a `password.txt`

2. Digest the password
   caddy hash-password < ./password.txt

3. Put the username and digest in an ENV file 
   `caddy.env`:

BASIC_AUTH_USER='apitoken'
BASIC_USER_AUTH='$2a$14$sI1j0RbhzKHMZ4cHU8otHOkB3Dgl9egF2D.CXB6C0/Qk5dtaMHS/u'


4. Create a `Caddyfile` with basic auth using the ENVs
api.example.com {
    handle /* {
        basicauth {
            {env.BASIC_AUTH_USERNAME} {env.BASIC_AUTH_DIGEST}
        }
        reverse_proxy localhost:11434
    }
}

5. Run caddy
caddy run --config ./Caddyfile --envfile ./caddy.env

And if you want to run it as a system service, or without HTTPS or need other details, I've got a bunch of snippets up at https://webinstall.dev/caddy.

This is deprecated by now. You can instead try this, which works for me together with API Key auth and I am able to use it with openai connectors which require API Key auth:

nano caddy.env

API_KEY='some-key'

nano Caddyfile

api.example.com {
	# if you have 80 and 443 open on the ollama server, you can specify tls and caddy automatically sets up SSL for you such that external connectors securely connect to your Ollama API with SSL and do not complain about certificates
	# tls somemail@mail.com
	
	@requireAuth {
		not header Authorization "Bearer {env.API_KEY}"
	}

	respond @requireAuth "Unauthorized" 401

	reverse_proxy localhost:11434
}

After testing with curl, I found that when accessing via some "api.example.com", you need to set the reverse proxy header to localhost. Otherwise, Ollama will deny the request with a 403 error:

api.example.com {
	# if you have 80 and 443 open on the ollama server, you can specify tls and caddy automatically sets up SSL for you such that external connectors securely connect to your Ollama API with SSL and do not complain about certificates
	# tls somemail@mail.com
	
	@requireAuth {
		not header Authorization "Bearer {env.API_KEY}"
	}

	respond @requireAuth "Unauthorized" 401

	reverse_proxy localhost:11434 {
               header_up Host 127.0.0.1:11434
        }
}

Yet another approach: curl -sSL https://raw.githubusercontent.com/PJ-568/ollama-proxy/refs/heads/master/install.sh | bash

Form PJ-568/ollama-proxy.

<!-- gh-comment-id:2885682628 --> @PJ-568 commented on GitHub (May 16, 2025): <details> <summary> Reply </summary> > > > Here's how you add HTTP Basic Auth with `caddy` as a reverse proxy to `localhost:11434`, and also handle HTTPS automatically: > > > ``` > > > 0. Install caddy > > > # Mac, Linux > > > curl https://webi.sh/caddy | sh > > > > > > # Windows > > > curl.exe https://webi.ms/caddy | powershell > > > > > > 1. Put your password (which could be an API Token) in a `password.txt` > > > > > > 2. Digest the password > > > caddy hash-password < ./password.txt > > > > > > 3. Put the username and digest in an ENV file > > > `caddy.env`: > > > ``` > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > BASIC_AUTH_USER='apitoken' > > > BASIC_USER_AUTH='$2a$14$sI1j0RbhzKHMZ4cHU8otHOkB3Dgl9egF2D.CXB6C0/Qk5dtaMHS/u' > > > ``` > > > > > > 4. Create a `Caddyfile` with basic auth using the ENVs > > > api.example.com { > > > handle /* { > > > basicauth { > > > {env.BASIC_AUTH_USERNAME} {env.BASIC_AUTH_DIGEST} > > > } > > > reverse_proxy localhost:11434 > > > } > > > } > > > > > > 5. Run caddy > > > caddy run --config ./Caddyfile --envfile ./caddy.env > > > ``` > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And if you want to run it as a system service, or _without_ HTTPS or need other details, I've got a bunch of snippets up at https://webinstall.dev/caddy. > > > > > > This is deprecated by now. You can instead try this, which works for me together with API Key auth and I am able to use it with openai connectors which require API Key auth: > > ``` > > nano caddy.env > > ``` > > > > > > > > > > > > > > > > > > > > > > > > ``` > > API_KEY='some-key' > > ``` > > > > > > > > > > > > > > > > > > > > > > > > ``` > > nano Caddyfile > > ``` > > > > > > > > > > > > > > > > > > > > > > > > ``` > > api.example.com { > > # if you have 80 and 443 open on the ollama server, you can specify tls and caddy automatically sets up SSL for you such that external connectors securely connect to your Ollama API with SSL and do not complain about certificates > > # tls somemail@mail.com > > > > @requireAuth { > > not header Authorization "Bearer {env.API_KEY}" > > } > > > > respond @requireAuth "Unauthorized" 401 > > > > reverse_proxy localhost:11434 > > } > > ``` > > After testing with curl, I found that when accessing via some "api.example.com", you need to set the reverse proxy header to localhost. Otherwise, Ollama will deny the request with a 403 error: > > ``` > api.example.com { > # if you have 80 and 443 open on the ollama server, you can specify tls and caddy automatically sets up SSL for you such that external connectors securely connect to your Ollama API with SSL and do not complain about certificates > # tls somemail@mail.com > > @requireAuth { > not header Authorization "Bearer {env.API_KEY}" > } > > respond @requireAuth "Unauthorized" 401 > > reverse_proxy localhost:11434 { > header_up Host 127.0.0.1:11434 > } > } > ``` </details> Yet another approach: `curl -sSL https://raw.githubusercontent.com/PJ-568/ollama-proxy/refs/heads/master/install.sh | bash` Form [PJ-568/ollama-proxy](https://github.com/PJ-568/ollama-proxy).
GiteaMirror commented 2026-04-28 02:06:06 -05:00
Author
Owner
Copy Link

@Ccocconut commented on GitHub (Sep 3, 2025):

why the authorization mechanism cannot be built into the ollama server?

It is not ollama's job. It is yours to use whatever you can, i.e. nginx or Caddy to secure your shit. It is out of scope of ollama and it adds friction and unnecessary code that may introduce bugs.

<!-- gh-comment-id:3249551170 --> @Ccocconut commented on GitHub (Sep 3, 2025): > why the authorization mechanism cannot be built into the ollama server? It is not ollama's job. It is yours to use whatever you can, i.e. nginx or Caddy to secure your shit. It is out of scope of ollama and it adds friction and unnecessary code that may introduce bugs.
GiteaMirror commented 2026-04-28 02:06:06 -05:00
Author
Owner
Copy Link

@KaKi87 commented on GitHub (Sep 3, 2025):

It is not ollama's job.

When one serves content on a port, it is.

<!-- gh-comment-id:3249932298 --> @KaKi87 commented on GitHub (Sep 3, 2025): > It is not ollama's job. When one serves content on a port, it is.
GiteaMirror commented 2026-04-28 02:06:08 -05:00
Author
Owner
Copy Link

@Ccocconut commented on GitHub (Sep 3, 2025):

It is not ollama's job.

When one serves content on a port, it is.

No. Ollama should not implement authentication. Its focus is on serving models. Security (auth, TLS) should be handled by a reverse proxy like Nginx or Caddy. This separation is standard in web architecture: application logic vs. access control.

To elaborate: serving content on a port does NOT automatically imply that it is responsible for access control or authentication. The act of binding to a port and responding to requests is a technical requirement for providing a service, but securing that service (via Basic Auth, TLS, or other mechanisms) is generally delegated to a reverse proxy or security layer. Expecting the service itself to implement authentication conflates the responsibilities of service delivery and access control, which are typically separated for maintainability and security reasons.

Expecting every service to implement access control would be absurd. What's next, fork OpenBSD for every port it opens? If listening on a port meant you needed built-in security, every daemon on Unix would come bundled with its own firewall. Spoiler: they don't, and that's how sane system architecture works. Protect the service yourself, you are responsible!

The idea that (opening) a port automatically makes a program responsible for security is as misguided as thinking a toaster should handle fire suppression.

<!-- gh-comment-id:3249964041 --> @Ccocconut commented on GitHub (Sep 3, 2025): > > It is not ollama's job. > > When one serves content on a port, it is. No. Ollama should not implement authentication. Its focus is on serving models. Security (auth, TLS) should be handled by a reverse proxy like Nginx or Caddy. This separation is standard in web architecture: application logic vs. access control. To elaborate: serving content on a port does NOT automatically imply that it is responsible for access control or authentication. The act of binding to a port and responding to requests is a technical requirement for providing a service, but securing that service (via Basic Auth, TLS, or other mechanisms) is generally delegated to a reverse proxy or security layer. Expecting the service itself to implement authentication conflates the responsibilities of service delivery and access control, which are typically separated for maintainability and security reasons. Expecting every service to implement access control would be absurd. What's next, fork OpenBSD for every port it opens? If listening on a port meant you needed built-in security, every daemon on Unix would come bundled with its own firewall. Spoiler: they don't, and that's how sane system architecture works. Protect the service yourself, you are responsible! The idea that (opening) a port automatically makes a program responsible for security is as misguided as thinking a toaster should handle fire suppression.
GiteaMirror commented 2026-04-28 02:06:09 -05:00
Author
Owner
Copy Link

@KaKi87 commented on GitHub (Sep 3, 2025):

The act of binding to a port and responding to requests is a technical requirement for providing a service

Absolutely not.

Ever heard of inter-process communication (IPC), especially Unix domain sockets (UDS), which a lot of services use, like Docker, to respond to requests from a huge variety of clients ?

<!-- gh-comment-id:3249998171 --> @KaKi87 commented on GitHub (Sep 3, 2025): > The act of binding to a port and responding to requests is a technical requirement for providing a service Absolutely not. Ever heard of [inter-process communication (IPC)](https://en.wikipedia.org/wiki/Inter-process_communication), especially [Unix domain sockets (UDS)](https://en.wikipedia.org/wiki/Unix_domain_socket), which a lot of services use, like Docker, to respond to requests from a huge variety of clients ?
GiteaMirror commented 2026-04-28 02:06:10 -05:00
Author
Owner
Copy Link

@Ccocconut commented on GitHub (Sep 3, 2025):

The act of binding to a port and responding to requests is a technical requirement for providing a service

Absolutely not.

Ever heard of inter-process communication (IPC), especially Unix domain sockets (UDS), which a lot of services use, like Docker, to respond to requests from a huge variety of clients ?

Yes, I'm aware of IPC and Unix Domain Sockets. Many services, especially on Unix, indeed use UDS or other IPC mechanisms to receive requests locally without opening a network port. My point wasn't that every service must bind to a TCP port, it was that whatever mechanism a service uses to accept requests, it is not inherently responsible for authentication or access control. Whether it's a TCP port, a UDS, or another IPC channel, securing access is still the responsibility of a security layer (reverse proxy, firewall, system permissions, etc.), not the service itself.

The underlying principle remains: serving requests ≠ handling authentication.

To reiterate: Ollama serves models. Protect the service yourself, you are responsible. Ports or sockets don't confer magical security duties.

<!-- gh-comment-id:3250007241 --> @Ccocconut commented on GitHub (Sep 3, 2025): > > The act of binding to a port and responding to requests is a technical requirement for providing a service > > Absolutely not. > > Ever heard of [inter-process communication (IPC)](https://en.wikipedia.org/wiki/Inter-process_communication), especially [Unix domain sockets (UDS)](https://en.wikipedia.org/wiki/Unix_domain_socket), which a lot of services use, like Docker, to respond to requests from a huge variety of clients ? Yes, I'm aware of IPC and Unix Domain Sockets. Many services, especially on Unix, indeed use UDS or other IPC mechanisms to receive requests locally without opening a network port. My point wasn't that every service must bind to a TCP port, it was that whatever mechanism a service uses to accept requests, it is not inherently responsible for authentication or access control. Whether it's a TCP port, a UDS, or another IPC channel, securing access is still the responsibility of a security layer (reverse proxy, firewall, system permissions, etc.), not the service itself. The underlying principle remains: serving requests ≠ handling authentication. To reiterate: Ollama serves models. Protect the service yourself, you are responsible. Ports or sockets don't confer magical security duties.
GiteaMirror commented 2026-04-28 02:06:13 -05:00
Author
Owner
Copy Link

@KaKi87 commented on GitHub (Sep 3, 2025):

whatever mechanism a service uses to accept requests, it is not inherently responsible for authentication or access control [...] Whether it's a TCP port, a UDS, or another IPC channel, securing access is still the responsibility of a security layer (reverse proxy, firewall, system permissions, etc.), not the service itself.

That's where I disagree.

If you use IPC, you're already protected.

If you use a port, you are responsible for protecting it.

<!-- gh-comment-id:3250026696 --> @KaKi87 commented on GitHub (Sep 3, 2025): > whatever mechanism a service uses to accept requests, it is not inherently responsible for authentication or access control [...] Whether it's a TCP port, a UDS, or another IPC channel, securing access is still the responsibility of a security layer (reverse proxy, firewall, system permissions, etc.), not the service itself. That's where I disagree. If you use IPC, you're already protected. If you use a port, you are responsible for protecting it.
GiteaMirror commented 2026-04-28 02:06:19 -05:00
Author
Owner
Copy Link

@Ccocconut commented on GitHub (Sep 3, 2025):

whatever mechanism a service uses to accept requests, it is not inherently responsible for authentication or access control [...] Whether it's a TCP port, a UDS, or another IPC channel, securing access is still the responsibility of a security layer (reverse proxy, firewall, system permissions, etc.), not the service itself.

That's where I disagree.

If you use IPC, you're already protected.

If you use a port, you are responsible for protecting it.

Yes, I couldn't agree more: if you use a port, you are responsible for protecting it - that's literally my point. Whether it's a TCP port, a UDS, or any other interface, the service itself doesn't enforce security - the responsibility always lies with whoever exposes it, i.e. YOU. IPC like Unix Domain Sockets may reduce exposure via OS-level permissions, but any interface has boundaries that must be consciously secured. Thinking ports make a program responsible while UDS absolves it is oversimplified. Ollama serves models - you are responsible.

<!-- gh-comment-id:3250047083 --> @Ccocconut commented on GitHub (Sep 3, 2025): > > whatever mechanism a service uses to accept requests, it is not inherently responsible for authentication or access control [...] Whether it's a TCP port, a UDS, or another IPC channel, securing access is still the responsibility of a security layer (reverse proxy, firewall, system permissions, etc.), not the service itself. > > That's where I disagree. > > If you use IPC, you're already protected. > > If you use a port, you are responsible for protecting it. Yes, I couldn't agree more: if you use a port, you are responsible for protecting it - that's literally my point. Whether it's a TCP port, a UDS, or any other interface, the service itself doesn't enforce security - the responsibility always lies with whoever exposes it, i.e. YOU. IPC like Unix Domain Sockets may reduce exposure via OS-level permissions, but any interface has boundaries that must be consciously secured. Thinking ports make a program responsible while UDS absolves it is oversimplified. Ollama serves models - you are responsible.
GiteaMirror commented 2026-04-28 02:06:23 -05:00
Author
Owner
Copy Link

@vadimkantorov commented on GitHub (Sep 3, 2025):

I think, basic auth support (built-in) or via an official python wrapper is important, but not for production use - for testing and tinkering ollama in small teams, like JupyterLab does it (having some basic password protection support). So that it's a bit harder to have a footgun by default...

<!-- gh-comment-id:3250052375 --> @vadimkantorov commented on GitHub (Sep 3, 2025): I think, basic auth support (built-in) or via an official python wrapper is important, but not for production use - for testing and tinkering ollama in small teams, like JupyterLab does it (having some basic password protection support). So that it's a bit harder to have a footgun by default...
GiteaMirror commented 2026-04-28 02:06:25 -05:00
Author
Owner
Copy Link

@kesor commented on GitHub (Sep 3, 2025):

The least ollama could do is reference third party solutions, many of which were mentioned in this thread, in some kind of documentation or wiki or something. So that anyone raising this issue again can be referred to the list of existing solutions.

<!-- gh-comment-id:3250087748 --> @kesor commented on GitHub (Sep 3, 2025): The least ollama could do is reference third party solutions, many of which were mentioned in this thread, in some kind of documentation or wiki or something. So that anyone raising this issue again can be referred to the list of existing solutions.
GiteaMirror commented 2026-04-28 02:06:26 -05:00
Author
Owner
Copy Link

@Ccocconut commented on GitHub (Sep 3, 2025):

I think, basic auth support (built-in) or via an official python wrapper is important, but not for production use - for testing and tinkering ollama in small teams, like JupyterLab does it (having some basic password protection support). So that it's a bit harder to have a footgun by default...

I see where you're coming from, having lightweight password protection for local testing or small teams can make experimentation safer and reduce accidental exposure.

That said, I would still argue that this is fundamentally different from built-in authentication for production-level security. Even "lightweight" protection can give a false sense of safety / security if someone assumes it's robust. In practice, any serious deployment should rely on standard access controls - reverse proxies, TLS, OS-level permissions - rather than expecting the model server itself to handle authentication.

The least ollama could do is reference third party solutions, many of which were mentioned in this thread, in some kind of documentation or wiki or something. So that anyone raising this issue again can be referred to the list of existing solutions.

I agree, having a section in the documentation or wiki that references third-party solutions for securing Ollama (Nginx, Caddy[1], reverse proxies, OS permissions, etc.) would be very helpful. It doesn't change the principle that Ollama itself should focus on serving models, but it would make it easier for users to find safe ways to deploy it without reinventing the wheel or misunderstanding responsibilities. I would probably add a section for various methods of doing this.

[1] Something like https://github.com/ollama/ollama/issues/849#issuecomment-1773697189, for example.

<!-- gh-comment-id:3250095174 --> @Ccocconut commented on GitHub (Sep 3, 2025): > I think, basic auth support (built-in) or via an official python wrapper is important, but not for production use - for testing and tinkering ollama in small teams, like JupyterLab does it (having some basic password protection support). So that it's a bit harder to have a footgun by default... I see where you're coming from, having lightweight password protection for local testing or small teams can make experimentation safer and reduce accidental exposure. That said, I would still argue that this is fundamentally different from built-in authentication for production-level security. Even "lightweight" protection can give a false sense of safety / security if someone assumes it's robust. In practice, any serious deployment should rely on standard access controls - reverse proxies, TLS, OS-level permissions - rather than expecting the model server itself to handle authentication. > The least ollama could do is reference third party solutions, many of which were mentioned in this thread, in some kind of documentation or wiki or something. So that anyone raising this issue again can be referred to the list of existing solutions. I agree, having a section in the documentation or wiki that references third-party solutions for securing Ollama (Nginx, Caddy[1], reverse proxies, OS permissions, etc.) would be very helpful. It doesn't change the principle that Ollama itself should focus on serving models, but it would make it easier for users to find safe ways to deploy it without reinventing the wheel or misunderstanding responsibilities. I would probably add a section for various methods of doing this. [1] Something like https://github.com/ollama/ollama/issues/849#issuecomment-1773697189, for example.
GiteaMirror commented 2026-04-28 02:06:27 -05:00
Author
Owner
Copy Link

@KaKi87 commented on GitHub (Sep 4, 2025):

Yes, I couldn't agree more: if you use a port, you are responsible for protecting it - that's literally my point.

I meant you as the developer.

<!-- gh-comment-id:3253080719 --> @KaKi87 commented on GitHub (Sep 4, 2025): > Yes, I couldn't agree more: if you use a port, you are responsible for protecting it - that's literally my point. I meant *you* as the developer.
GiteaMirror commented 2026-04-28 02:06:29 -05:00
Author
Owner
Copy Link

@KaKi87 commented on GitHub (Sep 4, 2025):

basic auth support [...] is important, but not for production use - for testing

having lightweight password protection for local testing or small teams can make experimentation safer and reduce accidental exposure [...] this is fundamentally different from built-in authentication for production-level security. Even "lightweight" protection can give a false sense of safety / security if someone assumes it's robust

What's the difference between built-in BasicAuth and Caddy's BasicAuth ?

<!-- gh-comment-id:3253095626 --> @KaKi87 commented on GitHub (Sep 4, 2025): > basic auth support [...] is important, but not for production use - for testing > having lightweight password protection for local testing or small teams can make experimentation safer and reduce accidental exposure [...] this is fundamentally different from built-in authentication for production-level security. Even "lightweight" protection can give a false sense of safety / security if someone assumes it's robust What's the difference between built-in BasicAuth and Caddy's BasicAuth ?
GiteaMirror commented 2026-04-28 02:06:30 -05:00
Author
Owner
Copy Link

@ParisNeo commented on GitHub (Sep 6, 2025):

I have just finished building the new version of my ollama proxy with multi servers support, multi users, multi keys and with rate limiting and a full dashboard that shows statistics and stuff.

Have fun!

<!-- gh-comment-id:3263221036 --> @ParisNeo commented on GitHub (Sep 6, 2025): I have just finished building the new version of my ollama proxy with multi servers support, multi users, multi keys and with rate limiting and a full dashboard that shows statistics and stuff. Have fun!
GiteaMirror commented 2026-04-28 02:06:32 -05:00
Author
Owner
Copy Link

@flan7 commented on GitHub (Sep 24, 2025):

Auth with api key is standard for every other provider and requiring a home brewed reverse proxy breaks many endpoints such as home assistant. Home assistant will never be able to add compatibility for ollama auth if every user has a different implementation.

Not adding auth to software you created requiring open ports is just contributing to a terrible greater security ecosystem. You can see this from the vast amount of open ollama instances on the internet. Basic security should not be considered out of scope

<!-- gh-comment-id:3330784776 --> @flan7 commented on GitHub (Sep 24, 2025): Auth with api key is standard for every other provider and requiring a home brewed reverse proxy breaks many endpoints such as home assistant. Home assistant will never be able to add compatibility for ollama auth if every user has a different implementation. Not adding auth to software you created requiring open ports is just contributing to a terrible greater security ecosystem. You can see this from the vast amount of open ollama instances on the internet. Basic security should not be considered out of scope
GiteaMirror commented 2026-04-28 02:06:34 -05:00
Author
Owner
Copy Link

@Cranke commented on GitHub (Sep 26, 2025):

"out of scope" to secure an api with authentication?
is it still 1995?
if you want to create a product and not just a toy, you will need auth.

<!-- gh-comment-id:3338312215 --> @Cranke commented on GitHub (Sep 26, 2025): "out of scope" to secure an api with authentication? is it still 1995? if you want to create a product and not just a toy, you will need auth.
GiteaMirror commented 2026-04-28 02:06:36 -05:00
Author
Owner
Copy Link

@ParisNeo commented on GitHub (Oct 31, 2025):

The new version of my ollama proxy server is ready for those who need security. it is packed with alot of functionality with an administrative ui, statistics, load balancing and more:

Image Image

It took me a long time to build, So hope you find it useful.

https://github.com/ParisNeo/ollama_proxy_server

<!-- gh-comment-id:3471096249 --> @ParisNeo commented on GitHub (Oct 31, 2025): The new version of my ollama proxy server is ready for those who need security. it is packed with alot of functionality with an administrative ui, statistics, load balancing and more: <img width="1898" height="893" alt="Image" src="https://github.com/user-attachments/assets/7c1aca53-ea5c-4411-a901-c6c66b9e952f" /> <img width="1916" height="905" alt="Image" src="https://github.com/user-attachments/assets/c8f14991-8f2d-41ef-a1d2-c4dc27455da0" /> It took me a long time to build, So hope you find it useful. [https://github.com/ParisNeo/ollama_proxy_server](https://github.com/ParisNeo/ollama_proxy_server)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#46918
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?