The Problem: Ollama’s Open API Endpoint

Ollama has no username, no password, and no API key. By default, it binds to 127.0.0.1:11434, but the moment you change that binding to 0.0.0.0 or expose the port via Docker, the security model evaporates. Anything that can reach TCP port 11434 can list models, pull new ones, and interact with the API. There is no built-in mechanism to reject unauthorized requests. The application assumes it is running in a trusted local environment, and it does not check for credentials before executing expensive GPU operations or accessing sensitive model weights.

This is not a bug; it is a design choice for local development. However, for self-hosters and homelab operators who need to expose these tools to a LAN or WAN, the lack of native authentication creates a critical vulnerability. You cannot rely on network segmentation alone if you need remote access. The solution involves implementing a reverse proxy layer that sits between the client and Ollama, enforcing authentication before any traffic reaches the application.

Why Native Authentication Is Missing

Ollama is designed as a local inference engine. Its primary use case is a developer running models on their machine. Adding complex authentication layers to a local tool increases friction for the primary audience. Consequently, the project does not include a user management system, session handling, or token validation logic. As noted in community documentation, the absence of these features means that any security must be applied externally.

This architectural gap forces administrators to treat Ollama as a stateless backend service. You cannot secure it by changing a configuration flag inside ollama serve. Instead, you must treat the port as an untrusted entry point. The reverse proxy becomes the security boundary. This approach has a significant advantage: it does not require modifying application code or patching the Ollama binary. You can upgrade Ollama without breaking your security setup, and you can apply the same proxy configuration to other local services that lack native auth, such as Jupyter Notebooks or local database clients.

Implementing Basic Auth via Reverse Proxy

Basic Authentication is the simplest method to gate access. It relies on the HTTP Authorization header, where the client sends a username and password encoded in Base64. While Base64 is not encryption, it is sufficient for local networks or when combined with TLS. The reverse proxy intercepts the request, checks the header against a hashed password, and only forwards the request to Ollama if the credentials are valid.

This method works because Ollama does not care about the Authorization header. It simply receives the forwarded HTTP request. The proxy strips the authentication header (or leaves it, depending on configuration) and passes through the API request. If the credentials are missing or incorrect, the proxy returns a 401 Unauthorized response, and Ollama never sees the request.

The trade-off is that Basic Auth is vulnerable to sniffing if transmitted over HTTP. Therefore, this method is only acceptable if you are behind a trusted LAN or if you terminate TLS at the proxy. For WAN exposure, you should prefer token-based methods or ensure end-to-end encryption.

Alternative: Token Validation Strategies

For more robust security, especially when exposing services to the internet, token validation is preferred over Basic Auth. Instead of a username/password pair, the client sends a static API key in a custom header, such as X-API-Key or Authorization: Bearer <token>. The reverse proxy validates this token against a secret stored in its configuration.

This approach offers several advantages:

• Revocation: You can rotate the token without changing user passwords.
• Granularity: Different tokens can be issued for different clients or scripts.
• Compatibility: Many API clients natively support Bearer tokens, making integration smoother than Basic Auth.

The implementation requires the proxy to check the header value against a pre-defined secret. If the match fails, the request is rejected. This method is stateless and scalable, making it suitable for production environments. It also aligns with standard API security practices, where static secrets are preferred over session-based authentication for backend services.

Configuration Examples for Caddy and Nginx

Below are concrete configurations for two popular reverse proxies. These examples assume Ollama is running on localhost:11434.

Caddy Configuration

Caddy provides native support for Basic Auth and token validation via its basic_auth and header directives. For Basic Auth, generate a hashed password using caddy hash-password.

ollama.example.com {
    reverse_proxy localhost:11434

    basic_auth / {
        admin $2a$10$your_hashed_password_here
    }

    # For token validation, use a custom header check
    # header X-API-Key "your-secret-token"
    # respond 401 "Unauthorized"
}

Note: Caddy’s basic_auth directive applies to all paths by default. If you only want to protect specific endpoints, you can scope the directive. For token validation, Caddy does not have a built-in api_key directive in the standard build, so you may need to use a custom header check or a plugin.

Nginx Configuration

Nginx requires the http_auth_basic module for Basic Auth. For token validation, you must use if statements to check the header.

server {
    listen 80;
    server_name ollama.example.com;

    location / {
        # Basic Auth
        auth_basic "Restricted";
        auth_basic_user_file /etc/nginx/.htpasswd;

        # Token Validation (Alternative to Basic Auth)
        # if ($http_x_api_key != "your-secret-token") {
        #     return 401;
        # }

        proxy_pass http://localhost:11434;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

To create the .htpasswd file, use htpasswd -c /etc/nginx/.htpasswd admin. For token validation, the if block is a common pattern, though Nginx documentation warns that if inside location can be tricky. A more robust approach is to use the map directive to validate the header before the location block.

Verifying Access Control

After configuring the proxy, you must verify that unauthenticated requests are rejected. Use curl to test the endpoint without credentials:

curl -i http://ollama.example.com/api/tags

You should receive a 401 Unauthorized response. If you receive a 200 OK or a list of models, the proxy is not enforcing authentication correctly.

Next, test with valid credentials:

curl -i -u admin:your_password http://ollama.example.com/api/tags

For token validation, use:

curl -i -H "X-API-Key: your-secret-token" http://ollama.example.com/api/tags

If the response is successful, the proxy is working. Finally, verify that TLS is enabled if you are exposing the service to the WAN. Use openssl s_client or a browser to confirm that the certificate is valid and that the connection is encrypted.

Limitations: This setup does not protect against compromised credentials. If your password or token is leaked, an attacker can still access the API. Rotate credentials regularly and monitor logs for unauthorized access attempts. And, this does not cover Ollama’s internal model management or GPU acceleration, which are separate concerns. For those topics, refer to Ollama’s official documentation.