The starting point for most self-hosted Ollama setups in Dubai is the same: Ollama is running on a Windows or Linux machine – on-premise at the office, at a home office, or on a local server inside a UAE data centre – it works perfectly over localhost, and at some point there is a legitimate need to access it from somewhere else. Another device. A browser-based frontend. An automation workflow that runs from a different machine. So a tunnel gets created, a domain gets pointed at port 11434, and everything works.

Then the logs appear.

Ollama’s GIN logs start showing public IP addresses hitting /api/tags and /api/generate. Those are not your requests. /api/tags returns your installed model list. /api/generate invokes inference. Anyone who can reach your domain can use your hardware, consume your resources, and query your models – without a single credential. Automated scanning tools find open inference endpoints within hours of them going live. For a Dubai business running sensitive workflows – invoice processing, client document extraction, internal knowledge queries – that exposure is not acceptable.

This is not a hypothetical. It happened to us. The fix took under two hours to build and has been running in production on UAE infrastructure since. Here is exactly how it works.

Why Ollama Has No Built-In Authentication – and Why That Matters in Dubai

Ollama is designed as a local inference server. Its entire architecture assumes it is running on a trusted network – typically just localhost. Authentication was not in scope for the original design, and that is a reasonable trade-off for a tool built to run locally. The problem is that as soon as you put it behind a public domain – even through a tunnel – that localhost assumption no longer holds.

For Dubai businesses, the stakes are higher than just compute costs. Clients processing financial documents, legal records, or any data covered by the Federal Decree-Law No. 45 of 2021 (UAE Personal Data Protection Law – PDPL) are sending that material through the inference pipeline. An open Ollama endpoint means that data is accessible to anyone who finds the URL. The PDPL places the obligation to protect personal data on the data controller – the business running the model. “The tunnel was open by default” is not a defence.

The three obvious solutions each have a problem:

The solution that avoids all three problems: build a tiny authentication proxy that sits between Cloudflare and Ollama, runs entirely on your local machine, and requires nothing beyond Python and three packages.

The Architecture Before and After

The insecure architecture that most tunneled Ollama setups start with looks like this:

The secured architecture after this guide:

Cloudflare knows nothing about Ollama. It only knows about the proxy on port 8080. Ollama remains bound to 127.0.0.1 and is unreachable from the network at all – only the proxy accepts connections, and only through the tunnel. An unauthenticated request gets a 401 response from the proxy and stops there.

Step-by-Step: Building the Authentication Proxy

Step 1 – Install the proxy dependencies

You need three Python packages. Run this on the machine where Ollama is running:

python -m pip install fastapi uvicorn httpx

FastAPI handles the HTTP layer. Uvicorn is the ASGI server that runs it. HTTPX is the async HTTP client used to forward authenticated requests to Ollama.

Step 2 – Create the proxy script

Create a file at a path you will remember – for example C:\ai\ollama_proxy.py – and paste this:

import os
import httpx
from fastapi import FastAPI, Request, Response

app = FastAPI()
API_KEY = os.environ["OLLAMA_API_KEY"]
OLLAMA_BASE = "http://127.0.0.1:11434"

@app.api_route("/{path:path}", methods=["GET","POST","PUT","DELETE","PATCH","HEAD","OPTIONS"])
async def proxy(request: Request, path: str):
    auth_header = request.headers.get("Authorization", "")
    provided_key = auth_header.removeprefix("Bearer ").strip()
    if provided_key != API_KEY:
        return Response(
            content='{"error":"Unauthorized"}',
            status_code=401,
            media_type="application/json"
        )
    async with httpx.AsyncClient(timeout=120.0) as client:
        body = await request.body()
        upstream = await client.request(
            method=request.method,
            url=f"{OLLAMA_BASE}/{path}",
            headers={k: v for k, v in request.headers.items()
                     if k.lower() not in ("host", "authorization")},
            content=body,
            params=dict(request.query_params)
        )
        return Response(
            content=upstream.content,
            status_code=upstream.status_code,
            headers=dict(upstream.headers),
            media_type=upstream.headers.get("content-type")
        )

This proxy does exactly one thing: extract the bearer token from the Authorization header and check it against the environment variable. If the key matches, the request is forwarded to Ollama with the Authorization header stripped (Ollama does not need to see it). If the key is missing or wrong, the request ends at the proxy with a 401. Ollama is never touched.

Step 3 – Set the API key as an environment variable

Before starting the proxy, set the environment variable in the same terminal session:

$env:OLLAMA_API_KEY="your-key-here-make-it-long-and-random"

export OLLAMA_API_KEY="your-key-here-make-it-long-and-random"

Use a key that is at least 32 characters. A UUID works well – you can generate one with python -c "import uuid; print(uuid.uuid4())". This value becomes the credential every client must present.

Step 4 – Start the proxy

python -m uvicorn ollama_proxy:app --host 127.0.0.1 --port 8080

The --host 127.0.0.1 flag is important. It binds the proxy only to the loopback interface – it is not reachable from your local network, only from the machine itself and through the Cloudflare Tunnel. If you bind to 0.0.0.0, the proxy is reachable from your LAN without authentication, which defeats part of the purpose.

Step 5 – Verify authentication locally before touching the tunnel

Test the proxy before routing tunnel traffic to it. From the same machine, run both of these:

curl http://127.0.0.1:8080/api/tags
# Expected: {"error":"Unauthorized"}

curl http://127.0.0.1:8080/api/tags \
  -H "Authorization: Bearer your-key-here-make-it-long-and-random"
# Expected: {"models":[...]}

If the first returns a model list, the proxy is not running or the port is wrong. Fix that before proceeding. If both return the model list, something is misconfigured in the key comparison – check that the environment variable is set in the same terminal session where you started uvicorn.

Step 6 – Update the Cloudflare Tunnel ingress

Open your Cloudflare Tunnel configuration file. The default location on Windows is C:\Users\USERNAME\.cloudflared\config.yml.

Change the service target from Ollama’s port to the proxy’s port:

tunnel: YOUR_TUNNEL_ID
credentials-file: C:\Users\USERNAME\.cloudflared\YOUR_TUNNEL_ID.json

ingress:
  - hostname: api.yourdomain.com
    service: http://localhost:11434   # direct to Ollama - INSECURE
  - service: http_status:404

tunnel: YOUR_TUNNEL_ID
credentials-file: C:\Users\USERNAME\.cloudflared\YOUR_TUNNEL_ID.json

ingress:
  - hostname: api.yourdomain.com
    service: http://localhost:8080    # FastAPI proxy - auth enforced
  - service: http_status:404

Restart the tunnel for the change to take effect. On Windows, restart the Cloudflare Tunnel Windows service, or stop and restart the cloudflared process if you are running it manually.

Step 7 – Verify the full chain end-to-end

Now test from a different machine or from your phone on a mobile network – anything that routes through the public internet rather than your LAN:

curl https://api.yourdomain.com/api/tags
# Expected: {"error":"Unauthorized"}

curl https://api.yourdomain.com/api/tags \
  -H "Authorization: Bearer your-key-here-make-it-long-and-random"
# Expected: {"models":[...]}

The full chain is now: Internet request arrives at Cloudflare – Cloudflare forwards it to your tunnel – the tunnel delivers it to the FastAPI proxy on port 8080 – the proxy validates the key – on success, it forwards to Ollama on port 11434 – the response travels back the same way. Ollama never saw an unauthenticated request.

The Architecture Comparison

Securing the Frontend

If you have a browser-based frontend that calls the Ollama API, the proxy solves the backend but leaves an open question: where does the key go? The wrong answer is to hardcode it on the server side or embed it in the frontend JavaScript bundle where any user can read it from the source.

The approach that works for internal tools: the key lives in the user’s browser and travels with their requests. The server never holds it.

The Nginx configuration (on your VPS or reverse proxy)

If you have an Nginx instance serving your frontend at chat.yourdomain.com, update the /api/ location block to pass the Authorization header through rather than injecting a key server-side:

location /api/ {
    proxy_pass https://api.yourdomain.com;
    proxy_set_header Host api.yourdomain.com;
    proxy_set_header Authorization $http_authorization;  # forward from browser
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_ssl_server_name on;
}

The key difference is $http_authorization – this is the value the browser sent, not a value stored on the server. The VPS does not know the key. It forwards whatever the browser presented, and the FastAPI proxy on the other end validates it.

The frontend key management

The frontend needs three behaviors: show a key entry screen before the chat loads, validate the key against the live API, and store it for the session. Here is the JavaScript that handles this:

async function validateAndStoreKey(key) {
  const res = await fetch("/api/tags", {
    headers: { "Authorization": `Bearer ${key}` }
  });
  if (res.ok) {
    localStorage.setItem("ollama_api_key", key);
    showChat();                        // key is valid - load the chat UI
  } else {
    showError("Invalid key. Check your credentials and try again.");
  }
}

function getAuthHeader() {
  const key = localStorage.getItem("ollama_api_key") || "";
  return `Bearer ${key}`;
}

// Every API call sends the stored key as a bearer token
async function generate(prompt) {
  const res = await fetch("/api/generate", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "Authorization": getAuthHeader()
    },
    body: JSON.stringify({ model: "qwen2.5:1.5b", prompt, stream: false })
  });
  if (res.status === 401) {
    localStorage.removeItem("ollama_api_key");
    showKeyScreen();                   // key expired or rotated - re-prompt
    return;
  }
  return res.json();
}

The result is that the key lives in exactly two places: the environment variable on the machine running the proxy, and the user’s own localStorage. It never sits on the VPS. It never appears in server logs. Someone opening chat.yourdomain.com without the key sees only the key prompt and cannot reach the API at any point in the chain.

The Complete Data Flow After This Guide

Operational Details That Matter

Key rotation

Rotate the key if it is ever exposed – shared accidentally, visible in a browser console, or included in a bug report. The rotation process is:

Running the proxy as a persistent service on Windows

A proxy that stops when you close the terminal is not production-ready. Register it as a Windows service using NSSM (Non-Sucking Service Manager), available at nssm.cc:

# Run in an elevated PowerShell terminal
nssm install OllamaProxy "python" "-m uvicorn ollama_proxy:app --host 127.0.0.1 --port 8080"
nssm set OllamaProxy AppDirectory "C:\ai"
nssm set OllamaProxy AppEnvironmentExtra "OLLAMA_API_KEY=your-key-here"
nssm start OllamaProxy

NSSM handles restart on failure, logging, and service start on boot. The proxy now survives reboots and does not require a terminal window to stay open.

On Linux, use a systemd unit

[Unit]
Description=Ollama API Authentication Proxy
After=network.target

[Service]
User=your-user
WorkingDirectory=/home/your-user/ai
Environment=OLLAMA_API_KEY=your-key-here
ExecStart=python -m uvicorn ollama_proxy:app --host 127.0.0.1 --port 8080
Restart=always

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable ollama-proxy
sudo systemctl start ollama-proxy

What This Architecture Does Not Cover

Single-key authentication is the right starting point for internal tools, personal deployments, and small team access. It is not a complete security posture. Four gaps are worth knowing before you ship this to production – two are easy to close, two require a deliberate decision.

The Practical Security Baseline for Dubai Local LLM Deployments

A self-hosted Ollama instance without authentication is a free inference endpoint for anyone who finds your domain. Automated scanners do not care that your server is running in Dubai – they probe public IPs globally and log every open port they find. The FastAPI proxy described here closes that gap with a single Python file, three pip packages, and one configuration change to your Cloudflare Tunnel. The authentication layer is completely independent of Ollama, completely independent of Cloudflare, and entirely under your control.

For Dubai businesses running local LLMs for data-sovereign AI workflows – invoice processing, email triage, document extraction, internal knowledge queries – this architecture gives you a secure foundation that satisfies both the operational requirement (remote access to the model) and the compliance requirement (data stays on UAE infrastructure, access is controlled). The step from this foundation to a production AI integration – connecting the model to your actual business systems, building the document pipelines, handling Arabic-English workflows – is where The Orange Club’s AI integration practice picks up.

If you are still in the model selection stage – evaluating which Ollama models actually perform on Dubai B2B tasks before committing to infrastructure – see our Llama vs Qwen Dubai comparison, which covers exactly that ground with real output data and prompt engineering results.