DEV Community: Artemy Andruschak

Ollama has no authentication: 5 ways to share it with your team safely

Artemy Andruschak — Mon, 12 Oct 2026 13:00:00 +0000

Ollama has no API keys. It listens on 127.0.0.1:11434 and answers whoever connects. On a laptop that's fine. The trouble starts when someone sets OLLAMA_HOST=0.0.0.0 so a colleague can use the GPU box under the desk, and from then on every endpoint is open to anyone who can reach it. Not only chat, but also pull, delete, create and push.

A few numbers from this year:

In January, SentinelOne and Censys counted about 175,000 Ollama servers open to the internet in 130 countries. 48% of them had models with tool calling.
In May, Cyera published Bleeding Llama (CVE-2026-7482). Two unauthenticated requests, /api/create with a crafted GGUF file and then /api/push to the attacker's registry, leak the server's memory: environment variables, API keys, other people's prompts. The fix shipped in 0.17.1 back in February, but the release notes didn't call it a security fix, so plenty of servers never got updated.

Don't wait for keys in Ollama itself. In 2025 a maintainer wrote under a PR that added them: "In the short-term we don't plan to add an API key system to the Ollama server itself. Usually I recommend using a VPN like tailscale." As of 0.40.3 (October 2026) there is still no server-side setting for it. There is an OLLAMA_AUTH variable, but it only makes the ollama client sign the requests it sends.

So the protection has to sit in front of Ollama. Here are five ways to do that, from the simplest to the most complete, and what each one leaves open.

First, check that yours isn't open

From a machine outside your network:

curl -s --max-time 5 http://YOUR_PUBLIC_IP:11434/api/tags

If that prints a list of models, anyone can use them. Also run ollama -v: anything older than 0.17.1 needs an update whatever else you decide.

If Ollama runs in Docker, look at how the port is published. -p 11434:11434 listens on every interface, and Docker writes its own iptables rules, so a ufw rule that denies 11434 doesn't block it. Use -p 127.0.0.1:11434:11434, or don't publish the port at all when only other containers need it.

1. Keep it on localhost and use SSH or Tailscale

The least work: Ollama stays private and people come in over a channel that already has authentication.

For one or two people, an SSH tunnel is enough:

ssh -N -L 11434:localhost:11434 you@gpu-box

Clients then use http://localhost:11434 as if Ollama ran on their own machine.

For a team, Tailscale is the usual answer, and it's what the Ollama maintainer suggested. Let Ollama listen on all interfaces (sudo systemctl edit ollama):

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

and let the firewall accept the port only from the tailnet:

sudo ufw allow in on tailscale0 to any port 11434 proto tcp

With ufw on and its default of denying incoming traffic, nothing else gets through. Tailscale ACLs then decide which people or devices can reach the box at all.

What it leaves open: anyone who gets in can use the whole API, including deleting models. Every request looks the same to Ollama, so you can't tell who is using the GPU or how much, and you can't take access away from one script without taking it from the person who runs it. Every user also has to install and sign in to Tailscale, and tools running in the cloud, like a hosted n8n, can't easily join.

2. A reverse proxy that checks a token

If clients need a normal HTTPS address, put a proxy in front that refuses requests without a token. With Caddy, which gets the certificate by itself:

ollama.example.com {
    @no_token not header Authorization "Bearer {$OLLAMA_TOKEN}"
    respond @no_token 401

    # Nobody outside needs to create, push or delete models
    @model_admin {
        path /api/create /api/push /api/pull
        path /api/delete /api/copy /api/blobs/*
    }
    respond @model_admin 403

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

Start Caddy with a long random OLLAMA_TOKEN in its environment. Ollama itself stays on 127.0.0.1. The Host line matters: Ollama listening on localhost refuses requests addressed to any other host name, which is why the Ollama FAQ sets Host localhost:11434 in its nginx example. Without that line, Ollama answers 403 to any request that comes in under a real domain name. Streaming works as is.

OpenAI-compatible clients (Continue, Cursor, n8n, the OpenAI SDKs) take the token as their API key with https://ollama.example.com/v1 as the base URL.

Closing the model management endpoints is worth doing even with a token: they are the ones Bleeding Llama needed.

What it leaves open: one token for everyone. When someone leaves, you change it on every machine. You still can't see who sent what. You can give each person their own token with a map in nginx or several matchers in Caddy, but then you are writing your own small gateway in a config file.

3. Open WebUI as the front door

If your team already chats through Open WebUI, it can be the only way in. Ollama stays private, everyone gets an Open WebUI account (or signs in through your SSO), and people who need the API create personal keys.

An admin turns keys on under Admin Settings → Authentication → API Keys, non-admins also need the API Keys permission, and then each person creates a key in Settings → Account. According to the docs, a key works with the same endpoints as the web interface: OpenAI-style /api/chat/completions, and /ollama/api/* passed through to Ollama.

What it leaves open: a key gets all the rights of the person who created it. Endpoint restrictions exist, but they apply to every key on the instance, not to one. The docs don't mention spending or rate limits per key, so an agent stuck in a loop can hold the GPU all day.

4. A proxy built for this: LoLLMs Hub or LiteLLM

Two existing projects give each person a key without a hand-written config.

LoLLMs Hub by ParisNeo (it started as ollama_proxy_server, and the Ollama README lists it as "Ollama Fortress") puts keys, rate limits and per-user usage stats in front of one or many Ollama servers, spreads load across several GPU machines, and lets you pull and delete models from its admin page. Apache-2.0. Pick it if you have more than one box.

LiteLLM proxy gives each person a virtual key with a budget and a rate limit, and it talks to Ollama and to about a hundred cloud providers. Virtual keys need a Postgres database next to it, and it has a lot of settings. Pick it if someone on the team will look after it.

What they leave open: one more service to run and update. That's true of options 2 and 3 as well, but these are bigger.

5. Spillway (I built this one)

Full disclosure: I wrote Spillway, so take this section with that in mind.

I built it for a 10–50 person company that has Ollama on one GPU box, also pays for Claude or OpenAI, and has nobody whose job is to run infrastructure. It's free and open source, single sign-on included, and nothing in it is held back for a paid plan. One container with SQLite and an admin page:

mkdir spillway && cd spillway
curl -fsSLO https://raw.githubusercontent.com/Artemy-And/spillway/main/docker-compose.yml
echo "OLLAMA_URL=http://ollama:11434" >> .env
docker compose --profile ollama up -d
docker compose logs spillway    # prints the setup link

The Ollama container in that compose file publishes no port, so only Spillway can reach it. Spillway answers in Ollama's own format (/api/chat, /api/generate, /api/embed, /api/tags), as well as OpenAI's and Anthropic's, so Open WebUI, Claude Code, Codex and n8n connect with a key, without changes on their side. It doesn't forward /api/create, /api/push or /api/delete at all.

Every person, laptop or n8n workflow gets its own key with a daily and a monthly limit in dollars, which matter once cloud models sit behind the same key. For the GPU itself there's a rule that caps agent keys at so many requests per minute. The request log shows who sent what, with card numbers and similar personal data masked, and another rule blocks prompts with such data from cloud models while local ones still answer. When a team runs out of its cloud budget or a provider goes down, requests go to the local model instead of failing.

What it leaves open: it's young (version 0.4) and I'm the only maintainer. It's AGPL-3.0, which some companies don't allow. It doesn't spread load across several GPU machines. And if two people just share one GPU, it's more than you need: use option 1.

Which one to pick

	Access per person	Limits per key	Setup
SSH / Tailscale	per device, in Tailscale	no	minutes
Proxy with a token	one shared token	no	an hour
Open WebUI keys	yes	no	minutes, if you already run it
LoLLMs Hub	yes	rate	an evening
LiteLLM	yes	budget and rate	an evening, plus Postgres
Spillway	yes	dollars, and rate for agents	minutes

A rule of thumb: two or three people who trust each other, Tailscale. People and scripts that need an HTTPS address, a proxy with the model management endpoints closed. More people than you can track in your head, or a mix of local and cloud models, something with a key per person.

Whatever you choose, run Ollama 0.17.1 or later and make sure port 11434 doesn't answer from the internet. If you've got Ollama shared in another way that works well, I'd like to hear about it in the comments.

A self-hosted accessibility monitor that turns 66 errors into 13 things to fix

Artemy Andruschak — Tue, 29 Sep 2026 12:14:01 +0000

Since the European Accessibility Act started applying in June 2025, a lot of shops, agencies and small product teams have the same question: where do our sites actually stand, and is it getting better or worse?

The tools for that tend to fall into two groups. Enterprise monitors do the whole job, at enterprise prices, with your data on their servers. Open-source scanners are free, but they either run once, or keep a history only for the URLs you add one by one.

I wanted checking a site to be quick and easy, with a report that's clear and honest about what it covers. And I wanted it free, on my own server. So I built Tabwalk.

TL;DR: Tabwalk scans whole sites daily or weekly with Playwright and axe-core, turns one template bug into one row instead of hundreds, and runs on your own server with one docker compose up -d. Free and AGPL-3.0.

What it does

Finds pages. Tabwalk reads sitemap.xml (or sitemap_index.xml). With no sitemap, it takes the links from the home page. Tracking parameters like utm_* are stripped so the same page isn't checked twice.
Checks each page. A worker opens it in headless Chromium through Playwright and runs axe-core with the WCAG 2.2 A/AA rules.
Does it again. Every site is rescanned daily or weekly, and each scan is compared with the previous one: what's new, what got fixed, and how the count trends.

One mistake counts once

A template bug shows up on every page that uses the template. If a scanner reports it 500 times, nobody reads the report.

So Tabwalk fingerprints every finding. It takes the element's markup, blanks out everything that changes from page to page, and hashes the result together with the rule id:

export function fingerprint(ruleId: string, html: string): string {
  const normalized = html
    .replace(/\s+/g, ' ')
    .replace(
      /\b(id|for|href|src|srcset|value|aria-labelledby|aria-describedby|aria-controls|data-[\w-]+)="[^"]*"/gi,
      '$1="*"',
    )
    .replace(/>[^<>]{1,400}</g, '><')
    .trim()
    .slice(0, 800);

  return createHash('sha256').update(`${ruleId}|${normalized}`).digest('hex').slice(0, 16);
}

Two product cards with an empty link, <a href="/p/1042" class="card-link"> and <a href="/p/2077" class="card-link">, both become <a href="*" class="card-link">. Same rule, same fingerprint, one row with a page count.

In the demo shop that ships with the repo, that turns 66 failing elements into 13 rows.

It says what it can't judge

axe-core returns a third category next to passes and violations: incomplete. These are checks it can't decide on its own, like contrast over a background image.

Tabwalk keeps them and labels them "needs a human". Automated checks cover only part of WCAG, so the honest thing for a tool to do is say which parts it measured and which parts are yours.

No Redis, no cron container

Scans are background jobs, and the usual answer is Redis + BullMQ, plus cron for the schedule. Tabwalk uses pg-boss for both: the queue and the schedule live in the same Postgres as the data. Every 15 minutes the worker queues a scan for each site that is due.

The whole thing is four containers: Postgres, API (Hono), worker and web (nginx serving the React dashboard):

git clone https://github.com/Artemy-And/tabwalk.git
cd tabwalk
cp .env.example .env
docker compose up -d

Because it runs on your network, it can check staging and internal sites a cloud service can't reach. There's no account and no telemetry; results stay in your Postgres.

In CI

The same checker runs as a GitHub Action, without the dashboard:

- uses: Artemy-And/tabwalk@v0.2.1
  with:
    url: https://staging.example.com
    fail-on: serious

The job summary lists every problem. "Needs a human" results are listed too, but they never fail the build.

Try it without a real site

The repo includes a small demo shop with problems built in: images without alt text, icon buttons without names, a heading jump, unlabeled form fields, a video without captions.

docker compose -f docker-compose.yml -f docker-compose.demo.yml up -d

Add http://acmestore.example/ as a site and run a scan.

What it doesn't do

It doesn't make a site compliant, and it doesn't change anything on it: no overlay, no widget. There's no login yet, pages behind a login aren't scanned, and reports can't be exported yet.

Next up: plain-language explanations, turning the "needs a human" results into a checklist, and suggested code fixes. Suggested, never applied automatically.

Tabwalk is free and AGPL-3.0. If you try it, I'd love to hear what's missing. Issues, discussions and pull requests are open, and there are a few good first issues if you'd like to help. And if it's useful to you, a star on GitHub helps other people find it.