Skip to main content
Local model runtimes were not built for multi-user auth. Ollama has no API-key mechanism at all — its maintainers point users toward fronting it with a reverse proxy like nginx or Caddy. vLLM, llama.cpp, and LM Studio each offer at most 1 static, optional key. Tokios gives every registered model a real, scoped sk-tok- key per person or service, with no reverse proxy, TLS certificate, or firewall rule for you to manage.

​
Ollama API key — the short answer

Ollama does not have API keys. When you run ollama serve, the API at http://localhost:11434 accepts requests from anyone who can reach the port. There is no --api-key flag, no Authorization header check, and no per-user scoping in Ollama itself. If you need to control who can call your Ollama model, you have 2 options:
  1. Reverse proxy (nginx, Caddy) — add HTTP basic auth or token validation in front of Ollama. You manage the proxy config, TLS certificates, and key rotation yourself.
  2. Tokios connector — pair a connector next to Ollama, register a deployment, and create scoped sk-tok-… keys in the dashboard. No proxy config, no TLS, no inbound ports. See How Tokios adds keys below.

​
What each runtime gives you today

These aren’t shortcomings — the runtimes below are built for serving models, not for multi-tenant access control. That’s the layer Tokios adds on top. Per each project’s own documentation: None of these give you per-person keys, scoping to specific models, or a way to revoke one caller without breaking the others. That’s the gap Tokios fills.

​
How Tokios adds keys

Tokios sits between your clients and your local runtime. Once your connector is paired and your model is registered as a deployment, every request to it authenticates with a Tokios API key — not with anything Ollama, vLLM, llama.cpp, or LM Studio issued.
1

Register your model

Pair a connector and give your model a public name (the deployment) in the Models tab. See Register Model if you haven’t done this yet.
2

Create a key on the Keys tab

Open the Keys tab and click Create key. Give it a display name, and optionally scope it with model patterns — comma-separated globs like gemma*, gpt-4* — so the key only reaches the deployments it needs. Leave it as * to allow all your models.
3

Copy the key

The key is shown only once, as sk-tok-.... Copy it immediately and store it in a password manager or secrets vault. You can hold up to 50 active keys, and each one can be edited, rotated, disabled, or deleted later.
4

Authenticate requests

Send the key as a Bearer token in the Authorization header:
For the full mechanics of creating, rotating, and revoking keys, see API Keys.

​
Give each teammate or service its own key

Because a shared static key (or no key at all) can’t tell one caller from another, treat Tokios keys the way you’d treat any credential handed to more than one person:
  • One key per person or environment. Issue a separate key for each teammate, CI job, or service. If someone leaves the team or a laptop goes missing, disable that one key on the Keys tab — everyone else keeps working.
  • Scope keys to only the models they need. Set model patterns per key. A key scoped to gemma* can’t touch a gpt-4* deployment, even if both run behind the same connector.
  • A leaked key can’t reach another tenant. Keys are scoped to your account and, optionally, to specific deployments — so a key that leaks can’t be used to reach models outside what it was issued for.
The fastest way to hand someone a scoped key is Share Key on the Keys tab — it mints a dedicated key and emails them a one-time reveal link (the key is never in the email), with its own model scope, optional passphrase and expiry, and one-click revoke. See Share a key by email.
When a key tries to call a deployment it isn’t scoped for, Tokios rejects the request with HTTP 403:
A 403 means the key isn’t allowed to use that model (or the account is suspended); a 404 means the deployment name doesn’t exist. See API endpoints for the full list.
Rotate a key the same way you’d rotate any credential: create a replacement, update the caller, then disable the old key once traffic has moved over.

​
What’s next?

You cannot generate an API key from Ollama itself — it has no key mechanism. To add auth in front of Ollama, use Tokios: create a key on the Keys tab, copy the sk-tok-… value, and send it as Authorization: Bearer sk-tok-YOUR_KEY in your API requests. Tokios handles auth, scoping, and revocation.
vLLM supports 1 static --api-key flag when you start the server (for example vllm serve model --api-key my-key). It is a single shared key for all users, and vLLM’s own security guidance says not to rely on it exclusively. For per-user keys, add Tokios on top.
The llama.cpp server accepts an optional --api-key flag, but it is a single shared key with no per-user scoping. Tokios gives each person or service their own sk-tok-… key, scoped to specific models.

API keys

Full mechanics of creating, scoping, rotating, and revoking keys.

Quickstart

Pair a connector, register a model, and make your first authenticated request end to end.

Register model

Give your local model the public name clients will call.

Ollama remote access

Reach an Ollama instance from another machine without opening inbound ports.