Open WebUI unter Ubuntu 24.04 mit Ollama, Qwen3, Nginx und SSL installieren

Wir richteten openwebui.ekasunucu.com auf den Test-VPS und prüften die DNS-Auflösung. Für Anwendungsdaten wurde das Named Volume openwebui_data erstellt.

Zusätzlich wurde ein WEBUI_SECRET_KEY erzeugt. In Produktion sollte dieser Wert sicher in einer geschützten Datei oder einem Secret Manager gespeichert und bei Container-Neuerstellung wiederverwendet werden.

dig +short openwebui.ekasunucu.com @1.1.1.1
dig +short openwebui.ekasunucu.com @8.8.8.8

docker volume create openwebui_data

umask 077
[ -s /root/.openwebui_secret_key ] || openssl rand -hex 32 > /root/.openwebui_secret_key
WEBUI_SECRET_KEY="$(cat /root/.openwebui_secret_key)"

Im realen Test kam ghcr.io/open-webui/open-webui:main zum Einsatz. Host-Port 3000 wurde auf 127.0.0.1 begrenzt, intern blieb Port 8080 und openwebui_data wurde nach /app/backend/data gemountet.

Da Ollama dasselbe Netzwerk eka-ai nutzt, setzten wir OLLAMA_BASE_URL auf http://ollama:11434. Docker-DNS löst den Containernamen auf, ohne Ollama öffentlich zu veröffentlichen.

docker pull ghcr.io/open-webui/open-webui:main

WEBUI_SECRET_KEY="$(cat /root/.openwebui_secret_key)"
docker run -d --name open-webui --restart unless-stopped --network eka-ai -p 127.0.0.1:3000:8080 -e OLLAMA_BASE_URL=http://ollama:11434 -e WEBUI_SECRET_KEY="$WEBUI_SECRET_KEY" -v openwebui_data:/app/backend/data ghcr.io/open-webui/open-webui:main

docker ps --filter name='^/open-webui$'

Beim ersten Start kann Open WebUI Datenbankmigrationen ausführen und lokale Hilfsmodelle vorbereiten. In unserem Test erschienen zunächst connection reset und HTTP 000, obwohl der Container-Prozess bereits lief.

Nach Abschluss der Migrationen und dem Laden des Embedding-Modells lieferte /health HTTP 200 mit {"status":true}. Während dieser Initialisierung ist Log-Beobachtung sinnvoller als wiederholtes Löschen und Neuerstellen des Containers.

docker logs -f --tail 150 open-webui

until [ "$(curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:3000/health || true)" = "200" ]; do sleep 5; done
curl -sS http://127.0.0.1:3000/health

docker inspect open-webui --format 'Status={{.State.Status}} Health={{if .State.Health}}{{.State.Health.Status}}{{else}}none{{end}}'

Ein erfolgreicher Ollama-Test auf dem Host reicht nicht; auch der Open-WebUI-Container muss die API erreichen. Im gemeinsamen Docker-Netzwerk lautet das Ziel ollama:11434.

Open WebUI bezieht die Modellliste über diese Verbindung. Fehlt qwen3:4b, prüfen Sie zuerst /api/tags in Ollama, dann die Connection-Einstellung und die Mitgliedschaft beider Container in eka-ai.

docker exec open-webui python -c "import urllib.request; print(urllib.request.urlopen('http://ollama:11434/api/tags').read().decode())"

docker network inspect eka-ai --format '{{range .Containers}}{{.Name}} {{.IPv4Address}}{{println}}{{end}}'

Statt den Open-WebUI-Hostport ins Internet zu veröffentlichen, wurde Nginx zum öffentlichen Einstieg. Nginx lauscht auf 80/443, leitet an 127.0.0.1:3000 weiter und erhält die WebSocket-Upgrade-Header.

Verwenden Sie den korrekten server_name und führen Sie vor jedem Reload nginx -t aus.

cat >/etc/nginx/sites-available/openwebui.ekasunucu.com <<'EOF'
server {
    listen 80;
    listen [::]:80;
    server_name openwebui.ekasunucu.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        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_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 3600;
    }
}
EOF
ln -sfn /etc/nginx/sites-available/openwebui.ekasunucu.com /etc/nginx/sites-enabled/openwebui.ekasunucu.com
nginx -t
systemctl reload nginx

Nachdem der Nginx-Reverse-Proxy bereit war, stellte Certbot erfolgreich ein Let's-Encrypt-Zertifikat für openwebui.ekasunucu.com aus und integrierte es in Nginx.

Sowohl Origin-HTTPS als auch die öffentliche Domain lieferten im finalen Test HTTP 200. Benutzer greifen damit über den sicheren Hostnamen statt über einen Docker-Port zu.

certbot --nginx -d openwebui.ekasunucu.com

curl -I https://openwebui.ekasunucu.com

certbot certificates

Am Ende lauschte Ollama auf 127.0.0.1:11434 und Open WebUI auf 127.0.0.1:3000; Nginx war öffentlich auf 80 und 443 erreichbar. Dadurch wird die rohe Ollama-API nicht direkt ins Internet gestellt.

Docker-Portpublishing kann Firewall-Regeln beeinflussen. Prüfen Sie daher tatsächliche Sockets mit ss und veröffentlichte Containerports zusätzlich mit docker ps.

ss -lntp | grep -E ':80 |:443 |:3000 |:11434' || true

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'

Wir führten certbot renew --dry-run aus, statt automatische Erneuerung nur anzunehmen. Die simulierten Renewals für Open WebUI und Portainer waren erfolgreich.

Im finalen Zustand war Open WebUI healthy, Ollama lief, die HTTPS-Domain antwortete mit 200 und systemctl --failed meldete keine fehlgeschlagenen Units.

certbot renew --dry-run

curl -sS -o /dev/null -w '%{http_code}\n' https://openwebui.ekasunucu.com

docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'
systemctl --failed

Nach Abschluss der Infrastruktur öffneten wir https://openwebui.ekasunucu.com und erreichten die Open-WebUI-Willkommensseite. Über den Start-Button ging es zur Kontoeinrichtung.

Der Browser sollte direkt den Hostnamen verwenden. Öffentlicher Zugriff auf Port 3000 ist nicht erforderlich, da Nginx und TLS den Benutzerverkehr übernehmen.

Auf der ersten Registrierungsseite legten wir den Administrator mit Name, E-Mail und starkem Kennwort an. Das erste Konto erhält Zugriff auf die Administration.

Verwenden Sie in Produktion ein eindeutiges Kennwort und prüfen Sie die Registrierungs- und Freigaberichtlinie, bevor weitere Benutzer zugelassen werden.

Nach der Kontoeinrichtung stand qwen3:4b in der Modellauswahl von Open WebUI bereit. Damit war die Kette Browser → Open WebUI → Ollama → qwen3:4b vollständig funktionsfähig.

Die Inferenz läuft auf der Ollama-Seite des Servers; Open WebUI stellt Oberfläche, Benutzer- und Gesprächsebene bereit. Für größere Modelle oder mehr parallele Nutzer müssen CPU/RAM/GPU erneut dimensioniert werden.

Ollama-Modelldaten liegen in ollama_data, Open-WebUI-Anwendungsdaten in openwebui_data. VPS-Snapshot und Volume-Backups vor Updates erleichtern ein Rollback.

Der reale Test nutzte :main. Dokumentieren oder pinnen Sie für Produktion die Image-Version, sichern Sie Daten, erstellen Sie Container bewusst neu und prüfen Sie danach /health, Ollama /api/tags, HTTPS, lokale Port-Bindings und Autostart nach einem Reboot.

docker run --rm -v ollama_data:/quelle -v /root:/backup alpine sh -c 'tar czf /backup/ollama_data-$(date +%F).tar.gz -C /quelle .'

docker run --rm -v openwebui_data:/quelle -v /root:/backup alpine sh -c 'tar czf /backup/openwebui_data-$(date +%F).tar.gz -C /quelle .'

docker restart ollama open-webui
curl -sS http://127.0.0.1:3000/health
curl -sS http://127.0.0.1:11434/api/tags