How to Expose Ollama Securely with systemd & a Reverse Proxy

As you must know, Ollama has no built-in authentication. If you open port 11434 to the internet, anyone can use your GPU, pull models, and send requests at your cost. This guide shows you exactly how to expose Ollama securely, keeping the raw port locked down, running it as a proper systemd service, and putting Nginx in front with HTTPS and a password.

If you want a server that is already built for this kind of workload, check out PerLod AI Hosting for GPU-optimized plans.

Before starting to expose Ollama securely, make sure you have the following ready:

• A remote Linux server running Ubuntu 22.04 or newer.
• A domain name points to your server's public IP.
• Root or sudo access over SSH.
• Ollama is already installed. You can also check the Open WebUI with Ollama setup guide if you haven't done that yet.
• Nginx and Certbot are available via apt.

Why not just open port 11434? Ollama has no built-in access control. Any exposed instance allows unauthenticated model usage, resource hijacking, and prompt injection from anyone who finds the port. The right way is to keep Ollama on localhost and let Nginx handle the public-facing side.

Before starting, here is the security model you are building:

Ollama listens only on 127.0.0.1:11434. Nginx sits in front, handles SSL termination, checks credentials, and forwards clean requests to Ollama internally.

For more details on platform-specific options and flags, you can also check the official Ollama Linux documentation.

If you do not have Ollama installed yet, run the official installer with the command below:

The install script automatically creates a systemd service file at /etc/systemd/system/ollama.service. It looks like this:

Enable and start the service:

Verify it is running:

Now, follow the steps below to expose Ollama securely.

By default, Ollama listens on 127.0.0.1:11434. You want to make sure this does not accidentally change. The safe way is to set the OLLAMA_HOST environment variable explicitly in the systemd service override, not in the main service file, which gets overwritten on updates.

To do this, run the command below:

This opens a blank override file. Add the following:

Save and exit. Reload and restart:

Important Note: Never set OLLAMA_HOST=0.0.0.0 unless Ollama is inside a private Docker network. Setting it to 0.0.0.0 binds to all interfaces and exposes the API to everyone. That is the unsafe pattern this guide avoids.

Confirm Ollama is only listening on localhost:

You should only see 127.0.0.1:11434, not 0.0.0.0:11434.

When you need to expose Ollama securely, understanding these variables helps you control its behavior through systemd:

To set any of these, add them as Environment= lines inside sudo systemctl edit ollama, then reload and restart.

For example, restrict CORS to your domain only:

Even though Ollama is bound to localhost, it is good practice to block port 11434 at the firewall level too. This adds a second layer of protection:

Make sure port 11434 is NOT in the allow list. Check your rules:

Install Nginx if it is not already on your server:

Start and enable it:

Because this is how you expose Ollama securely to specific users, you need a password file. Install apache2-utils to get the htpasswd tool:

Create the password file and your first user:

You will be prompted to enter and confirm a password. The file stores a hashed version of it.

To add more users later, you can omit the -c so you do not overwrite the file:

Create a new Nginx config file for your domain:

Paste the following content with your domain:

What each directive does:

Enable the site and test the config:

Now you can take your setup from HTTP to proper HTTPS by using Certbot:

Follow the prompts. Certbot will:

• Issue a free Let's Encrypt certificate.
• Automatically update your Nginx config to use HTTPS.
• Set up auto-renewal via a systemd timer.

Test auto-renewal to make sure it works:

After Certbot finishes, your Nginx config will have an updated listen 443 ssl block and HTTP-to-HTTPS redirect, all handled automatically.

Now test that the setup works correctly. From your local machine, not the server, you can run:

Test authentication, which should return 401 without credentials:

You should get 401 Unauthorized.

Test with credentials:

You should get a JSON response listing your installed models.

Test a generate request:

If you get a valid JSON response, your setup to expose Ollama securely is working correctly.

When something does not work, knowing where the logs are is essential.

To check Ollama service logs, you can use:

View logs from the last hour only:

You can enable debug mode for more details by adding this to your systemd override:

Add:

Then restart:

To check Nginx access and error logs, you can use:

Once you expose Ollama securely behind Nginx, here is how to use the API correctly from your applications or scripts:

Python example using requests:

Using the Ollama Python library with a remote host:

Passing credentials in curl for quick tests:

Note: Never hard-code credentials in scripts. Use environment variables or a .env file with restricted permissions:

Getting Ollama to work on localhost is the easy part. The hard part is making it accessible from the internet without creating a security hole. By following this guide, you have the right way to expose Ollama securely for real-world use. You keep full control, your API is password-protected and encrypted, and you can check everything through journalctl when something needs debugging.

For heavy models, multi-user inference, or always-on deployments, a dedicated GPU server makes a real difference. You can check out the best GPU Dedicated Servers, built to run LLMs at scale.