openSUSE Leap Private AI Inference on a VPS

What you will build

This tutorial shows you how to run private AI inference on openSUSE Leap for internal teams, customer support flows, or prototype apps that should never send prompts to a third-party API. You will install Ollama, bind it to localhost, put Nginx in front of it, open only the ports you need, and verify everything with real requests.

The setup uses Hostperl VPS hosting, which fits private model serving well when you want predictable resources, responsive support, and simple upgrades. If your workload grows into larger models or higher concurrency, Hostperl’s dedicated server hosting is the better next step.

This guide is written for openSUSE Leap 15.6. That matters because Leap uses zypper, firewalld, systemd, and AppArmor defaults that differ from Debian and RHEL-family instructions. If your server is not openSUSE Leap, stop here and use the matching distro-specific tutorial instead of mixing commands.

Before you start

You need a fresh openSUSE Leap VPS with root SSH access, DNS for server.example.com if you want TLS later, and at least 8 GB RAM for a small model or 16 GB and more for comfortable local testing. CPU-only inference works for light internal use, but it will not match a GPU-backed node. For model selection and capacity planning, Hostperl’s article AI model serving on dedicated servers: what buyers check is a useful companion.

Start with control. Keep the model server private, verify the network path, and only then expose a reverse proxy to the outside world. That order avoids the most common lockout and data-leak mistakes.

Connect and confirm the operating system

On your local computer:

ssh root@203.0.113.10

203.0.113.10 is a reserved documentation address. Replace it with the real public IP assigned to your Hostperl server. If your provider uses a default non-root login, connect with that account first and then use sudo for privileged commands.

On the VPS as root:

cat /etc/os-release

You should see openSUSE Leap details in the output. If you do not, stop and use the correct OS guide. Mixing package managers or firewall tools will lead to avoidable failure.

Create a sudo user before you change SSH access

Do not work from root alone. Create a non-root administrator first, test the login in a second terminal, and keep the original root session open until the new account works.

On the VPS as root:

useradd -m -s /bin/bash deploy
passwd deploy
usermod -aG wheel deploy
mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

This creates the deploy account, sets a password in case you need console access, grants wheel-based sudo access, and copies your current SSH key so you can log in without password prompts. If your root account does not use key auth, replace the copy step with a proper key upload from your local machine.

On your local computer, open a second terminal and test the new login:

ssh deploy@203.0.113.10

Then verify sudo:

sudo -v

If sudo asks for the password and accepts it, the account is ready. Keep the root session open until you finish the rest of the guide.

Update Leap, install the model server, and enable the firewall

On the VPS as the non-root sudo user:

sudo zypper refresh
sudo zypper update -y
sudo zypper install -y curl firewalld nginx
sudo systemctl enable --now firewalld
sudo systemctl enable --now nginx

This refreshes package metadata, updates the server, installs the tools you need, and brings up the firewall plus Nginx. On openSUSE Leap, the service names are exactly as shown. After this, check versions so you know what you are running:

zypper --version
nginx -v
systemctl --version

Now install Ollama. As of 2026, the cleanest path on Leap is still the official Linux install script or packaged binary workflow from Ollama’s project, followed by a dedicated systemd unit. Use the upstream installation method that your change-control policy allows. For a production VPS, keep the service bound to localhost only.

On the VPS as root or the non-root sudo user with sudo:

curl -fsSL https://ollama.com/install.sh | sh

That script installs the Ollama binary and service files. If your policy does not allow remote install scripts, fetch the release package manually instead. After installation, confirm the service exists:

systemctl status ollama --no-pager

You should see an installed unit, even if it is not yet listening on the right address.

Bind Ollama to localhost only

Private inference should not listen on the public interface. Create a systemd override that forces Ollama to listen only on 127.0.0.1:11434.

On the VPS as root:

systemctl edit ollama

Add this content, then save and exit the editor:

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

Reload systemd and restart the service:

systemctl daemon-reload
systemctl restart ollama
systemctl enable ollama

Verify the binding:

ss -ltnp | grep 11434

The output should show Ollama on 127.0.0.1:11434, not on 0.0.0.0 or your public IP. That is the correct private posture.

Pull one small model for a smoke test. Pick a model size that matches your RAM. For a modest VPS, start small.

ollama pull llama3.2:3b

After the pull completes, confirm the local chat API answers:

curl http://127.0.0.1:11434/api/tags

You should see JSON that lists available models.

Place Nginx in front of the model API

Nginx gives you a stable entry point, clearer logs, and an easy TLS path later. Keep it as a reverse proxy to the localhost-only Ollama service.

On the VPS as root:

mkdir -p /etc/nginx/vhosts.d

Edit the main Nginx configuration so it includes drop-in vhost files if it does not already.

sed -n '1,220p' /etc/nginx/nginx.conf

Look for an http block with include /etc/nginx/vhosts.d/*.conf;. If it is missing, add it under the existing include /etc/nginx/conf.d/*.conf; line.

Now create the reverse proxy file:

cat > /etc/nginx/vhosts.d/ollama.conf <<'EOF'
server {
    listen 80;
    server_name server.example.com;

    access_log /var/log/nginx/ollama_access.log;
    error_log /var/log/nginx/ollama_error.log;

    location / {
        proxy_pass http://127.0.0.1:11434;
        proxy_http_version 1.1;
        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;
        proxy_read_timeout 300;
    }
}
EOF

Replace server.example.com with your real hostname if you are using one. Run a syntax test before reloading:

nginx -t

If the test reports success, reload Nginx:

systemctl reload nginx

Check that Nginx is serving the proxy path:

curl -I http://127.0.0.1/

For more context on reading reverse-proxy logs during support work, see Nginx reverse proxy logs that speed up app support.

Open only the required ports in firewalld

Keep the public attack surface small. Open HTTP now, and add HTTPS later if you wire up TLS. Do not expose Ollama’s port directly.

On the VPS as root:

firewall-cmd --permanent --add-service=http
firewall-cmd --reload
firewall-cmd --list-all

You should see the http service allowed. There should be no public rule for 11434. If you later add TLS, open https the same way before closing port 80.

Test the private model endpoint

Use the local model API first. This isolates server problems from network problems.

On the VPS as the non-root sudo user:

curl http://127.0.0.1:11434/api/generate -d '{"model":"llama3.2:3b","prompt":"Write one sentence about safe private AI hosting."}'

You should receive streamed JSON tokens and a final response. Then test the public proxy from the server itself:

curl http://127.0.0.1/api/tags

If that works, test it from your local computer:

On your local computer:

curl http://203.0.113.10/api/tags

Replace 203.0.113.10 with your server’s real public IP. If DNS is already pointing to the host, you can use the hostname instead. A successful response proves the model API is reachable without exposing Ollama itself.

Add a minimal TLS layer later, not before the base path works

If this service will be used beyond an internal LAN, issue a certificate after the HTTP proxy is stable. For production, use your normal DNS and certificate workflow, then move Nginx to port 443 and redirect 80 to 443. Hostperl’s guide DNS, SSL, and email: what hosting buyers must check is helpful if you are validating the domain setup first.

Use Certbot only if it matches your operational standards on Leap. The important part is not the tool name. The important part is the sequence: confirm the proxy works on HTTP, issue the certificate, validate renewal, and then tighten the firewall to include HTTPS.

Check systemd, logs, and reboot persistence

At this point, verify the services and look for any warnings in the logs.

On the VPS as root:

systemctl status ollama --no-pager
systemctl status nginx --no-pager
journalctl -u ollama -n 50 --no-pager
journalctl -u nginx -n 50 --no-pager

You want both services active and no repeated restarts. Then confirm they survive a reboot:

reboot

After the server returns, reconnect and check:

systemctl is-active ollama
systemctl is-active nginx
ss -ltnp | grep 11434

If the service does not come back cleanly, use the log output before making changes. That is faster and safer than guessing.

Common failures and exact fixes

Ollama listens on the public IP

Diagnostic command:

ss -ltnp | grep 11434

If you see 0.0.0.0:11434, your override was not applied. Re-open the systemd edit file, confirm the OLLAMA_HOST value, then run:

systemctl daemon-reload
systemctl restart ollama

Nginx returns 502 Bad Gateway

Diagnostic command:

journalctl -u nginx -n 50 --no-pager
curl http://127.0.0.1:11434/api/tags

If the local API fails, restart Ollama and verify the model exists. If Nginx cannot reach localhost, check the proxy_pass target in /etc/nginx/vhosts.d/ollama.conf.

The firewall blocks remote access

Diagnostic command:

firewall-cmd --list-all

If http is missing, re-add it and reload firewalld. Do not open 11434 to the internet.

firewall-cmd --permanent --add-service=http
firewall-cmd --reload

The model pull is too large for your VPS

Diagnostic command:

free -h
dmesg -T | tail -n 30

If memory pressure is severe, use a smaller model, add swap, or move the workload to a larger node. For sustained private inference, a dedicated server is often the cleaner answer.

When to move this workload to a larger server

Small internal chat bots and prompt helpers can run well on a modest Leap VPS. Once you need multi-user concurrency, larger context windows, or heavier model files, the memory and I/O pattern changes quickly. At that point, a dedicated machine with more RAM, faster NVMe, or GPU access makes sense.

If you are planning that move, Hostperl’s dedicated server hosting and AI model serving on dedicated servers: what buyers check are the right next reads. They help you match model size, concurrency, and hardware before you cut over.

FAQ

Can I run private AI inference on openSUSE Leap without a GPU?

Yes. A small model will run on CPU-only hardware for internal testing or light workloads. Expect slower responses and choose a smaller model.

Should I expose port 11434 to the public internet?

No. Keep Ollama on localhost and place Nginx or another reverse proxy in front of it. That gives you authentication, logging, and TLS control.

What is the safest first model to test?

Start with a small model such as llama3.2:3b or another lightweight option that fits your RAM. Confirm memory pressure before scaling up.

How do I know the setup survived a reboot?

Use systemctl is-active ollama, systemctl is-active nginx, and ss -ltnp | grep 11434 after restart. All three should return the expected running state.

What should I do if the service starts but the model API is slow?

Check CPU, RAM, swap, disk throughput, and model size. If the server is undersized, move the workload to a larger VPS or dedicated server instead of trying to tune around the limit.