- Local Ollama has no API key. The server at
http://localhost:11434accepts every request without authentication, by design. - If an OpenAI-compatible client demands a key, enter any non-empty string —
ollamais the convention. It is never checked. - A real Ollama API key exists only for Ollama Cloud, created in your ollama.com account and sent as a
Bearertoken. - To secure a local instance, put a reverse proxy with authentication in front of it. Never expose port 11434 directly to the internet.
A local Ollama installation has no API key and no built-in way to set one. The HTTP server it runs at http://localhost:11434 answers any request that reaches it. People searching for an “Ollama API key” usually need one of three things: something to type into a client app’s mandatory key field, a way to secure an instance that other machines can reach, or a key for Ollama’s hosted cloud service — the one place a real key exists. This guide covers all three.
- Why Local Ollama Ships Without Authentication
- What to Put in the API Key Field of OpenAI-Compatible Clients
- Adding Real Authentication with a Reverse Proxy
- Changing Where Ollama Listens: Windows, macOS, Linux
- Ollama Cloud: Where a Real API Key Applies
- The Actual Danger: An Unauthenticated Instance on the Internet
- Frequently Asked Questions
Why Local Ollama Ships Without Authentication
By default, Ollama binds to the loopback address 127.0.0.1 on port 11434. Only processes on the same machine can connect, so an API key would add friction without adding security: any local program that could read a key file could just as easily call the API directly. This is the same trust model used by most local development servers.
The consequence: there is no OLLAMA_API_KEY variable, no key flag, and no password option anywhere in the configuration. As of this writing, the local Ollama server has no built-in authentication mechanism at all — securing a network-reachable instance is your job, covered below. If you are still getting set up, start with our Ollama installation guide or the broader Ollama complete guide.
What to Put in the API Key Field of OpenAI-Compatible Clients
Ollama exposes OpenAI-compatible endpoints under /v1, which is why chat UIs, coding assistants, and the official OpenAI SDKs can talk to it. Those SDKs refuse to construct a client without a non-empty API key — the check happens client-side, before any request is sent. Ollama then ignores the resulting Authorization header entirely, so any string works. The convention is ollama.
| Setting | Value for local Ollama |
|---|---|
| Base URL | http://localhost:11434/v1 |
| API key | Any non-empty string, e.g. ollama |
| Model | A tag you have pulled, e.g. llama3.2 |
Python, using the official OpenAI SDK:
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:11434/v1",
api_key="ollama", # required by the SDK, ignored by Ollama
)
response = client.chat.completions.create(
model="llama3.2",
messages=[{"role": "user", "content": "Hello"}],
)
print(response.choices[0].message.content)JavaScript / TypeScript:
import OpenAI from "openai";
const client = new OpenAI({
baseURL: "http://localhost:11434/v1",
apiKey: "ollama",
});
const response = await client.chat.completions.create({
model: "llama3.2",
messages: [{ role: "user", content: "Hello" }],
});
console.log(response.choices[0].message.content);The model must already be pulled (ollama pull llama3.2) or the request will fail with a model-not-found error. If you are unsure what to run, see our picks for the best local models for Ollama.
Adding Real Authentication with a Reverse Proxy
Since Ollama cannot check keys itself, the standard pattern is to keep Ollama on its default loopback bind and put a reverse proxy in front. The proxy terminates TLS, checks a token, and forwards valid requests to 127.0.0.1:11434. A minimal nginx configuration that requires a bearer token:
server {
listen 443 ssl;
server_name ollama.example.com;
# ssl_certificate and ssl_certificate_key lines omitted
location / {
if ($http_authorization != "Bearer YOUR-LONG-RANDOM-TOKEN") {
return 401;
}
proxy_pass http://127.0.0.1:11434;
proxy_set_header Host $host;
proxy_read_timeout 600s;
}
}Two details matter. Generate the token with something like openssl rand -hex 32 rather than inventing one. And the long proxy_read_timeout is deliberate: streamed generations can run for minutes, and default proxy timeouts will cut them off mid-response.
The elegant part: OpenAI SDKs already send the key as Authorization: Bearer <key>. Point your client at https://ollama.example.com/v1, set the API key to the real token, and the formerly ignored key field becomes genuine authentication with no client-side changes. Caddy and Traefik can enforce the same header check or HTTP basic auth with a few lines of their own configuration; if you already run one of them, use it instead of adding nginx.
Changing Where Ollama Listens: Windows, macOS, Linux
A proxy on the same machine needs no Ollama changes. But if other machines must reach Ollama directly — a proxy on another host, Docker containers, or LAN clients — set OLLAMA_HOST=0.0.0.0 so it listens on all interfaces. How you set it differs by platform.
Windows
Quit Ollama from the system tray. Open Settings, search for “environment variables,” and choose “Edit environment variables for your account.” Add a variable named OLLAMA_HOST with the value 0.0.0.0, save, and relaunch Ollama.
macOS
Recent desktop builds include a settings toggle in the Ollama app to expose it on the network — check the app’s settings first. On older installs, run launchctl setenv OLLAMA_HOST "0.0.0.0" and restart the Ollama app.
Linux
For the systemd service installed by the official script, run sudo systemctl edit ollama.service and add:
[Service]
Environment="OLLAMA_HOST=0.0.0.0"Then run sudo systemctl daemon-reload && sudo systemctl restart ollama.
One warning before you flip that switch: 0.0.0.0 on a machine with a public IP address turns your GPU into a public utility. Firewall port 11434 so only the hosts that need it can connect.
Ollama Cloud: Where a Real API Key Applies
Ollama Cloud runs models too large for most local hardware on Ollama’s own datacenter GPUs, and it is the one part of the ecosystem with genuine API keys. There are two ways in.
Through the local CLI. Run ollama signin to connect your ollama.com account, then run cloud-hosted models by their cloud tags — at the time of writing, for example, ollama run gpt-oss:120b-cloud. Requests are tied to your account; no manual key handling required.
Directly over HTTPS. Create an API key in the API keys section of your ollama.com account settings and send it as a bearer token. The hosted API mirrors the local one, with https://ollama.com as the base URL instead of localhost:11434:
curl https://ollama.com/api/chat
-H "Authorization: Bearer $OLLAMA_API_KEY"
-d '{
"model": "gpt-oss:120b",
"messages": [{"role": "user", "content": "Hello"}],
"stream": false
}'The cloud model lineup, endpoints, and plan limits change over time, so treat Ollama’s own cloud documentation as the authority on current model names and quotas. When deciding whether hosted inference or local hardware makes more sense for your workload, our self-hosting vs API break-even calculator puts numbers on it, and the VRAM calculator tells you whether a given model fits your GPU at all.
The Actual Danger: An Unauthenticated Instance on the Internet
The real security story around the Ollama API key is not the placeholder string in your Python script — it is the thousands of Ollama servers that internet-wide scans routinely find listening on port 11434 with no authentication. Anyone who finds yours can run inference on your GPU for free, enumerate your models via /api/tags, pull models until your disk fills, or delete them. And any future server vulnerability becomes exploitable without credentials: CVE-2024-37032, a remote code execution flaw patched in 2024, is the precedent.
- Leave the default
127.0.0.1bind unless something genuinely needs remote access. - For personal remote access, prefer an SSH tunnel (
ssh -N -L 11434:127.0.0.1:11434 user@server) or a VPN such as WireGuard or Tailscale over opening the port. - If it must be publicly reachable, front it with an authenticated, TLS-terminating reverse proxy as shown above.
- Keep Ollama updated so known vulnerabilities stay patched.
Frequently Asked Questions
Does Ollama require an API key?
No. A local Ollama server has no authentication and no option to enable any. The only real Ollama API keys are for Ollama Cloud, created in your ollama.com account.
What should I type into a client’s required API key field?
Any non-empty string — ollama by convention. The requirement is purely client-side; Ollama discards the header. If you have put an authenticating reverse proxy in front of Ollama, enter the proxy’s real token instead, since OpenAI-style clients send the key as a bearer token the proxy can verify.
Can I make Ollama itself require an API key?
Not as of this writing. There is no environment variable, flag, or configuration option that enables authentication on the local server, despite long-standing user requests for one. A reverse proxy in front of the server is the accepted solution.
How do I get an Ollama Cloud API key?
Create an account at ollama.com and generate a key in the API keys section of your account settings. Send it as Authorization: Bearer <key> with requests to https://ollama.com. For CLI use, ollama signin links your machine to your account without manual key handling.
Why does the OpenAI SDK throw an authentication error before sending anything?
The SDK validates that an API key is present when the client is constructed, so an empty or missing key fails locally even though Ollama would not care. Set api_key="ollama" (or any string) and make sure the base URL ends in /v1.
Is it safe to expose Ollama on my home network?
On a trusted home LAN behind NAT, exposing Ollama with OLLAMA_HOST=0.0.0.0 is a common and reasonable setup. Confirm your router is not forwarding port 11434 to that machine, and remember that every device on the network — including guests’ phones — can then use and manage your models.

