image for Hvordan du kan kjøre LLMs som Deepseek selv med OpenWebUI og Ollama

Hvordan du kan kjøre LLMs som Deepseek selv med OpenWebUI og Ollama

Kanskje du har hørt om DeepSeek V3 og tenkt: Ja, kult, men så kommer den umiddelbare bekymringen – jeg kan jo ikke bruke det til noe sensitivt eller firmainformasjon, det kjører sikkert på en eller annen kinesisk server et sted! Men hva om jeg fortalte deg at det ikke trenger å være sånn?

Du kan faktisk få en opplevelse som ligner på ChatGPT eller DeepSeek, men fullstendig selvhostet – enten på din egen virtuelle maskin eller rett på egen maskin. Her er et skjermbilde av hvordan det ser ut når alt er satt opp.

Hvis du kun vil kjøre dette lokalt, trenger du ikke noe av dette. Da trenger du kun Docker installert på maskinen, som beskrevet senere i artikkelen. Hvis du vil kjøre tjenesten slik at andre folk kan bruke den, gjør vi noen antakelser først.

  1. Du har en (virtuell) Linux-maskin med en offentlig IP-adresse
  2. Du har tilgang til internett fra denne maskinen
  3. Maskinen er tilgjengelig på port 80 og 443
  4. Du kan SSH'e inn på maskinen under konfigurasjonen

Det sier seg selv at jo kraftigere maskin du har tilgang til (eller kan installere on-prem), jo bedre og kraftigere modeller kan du kjøre. I vårt eksempel bruker vi en Azure VM StandardB8ms maskin uten GPU-støtte (fordi du må be pent til Azure Support for å få GPU, og vi trenger egentlig ikke det for denne demoen).

Merk også at selv om vi bruker en maskin som koster 300 dollar i måneden, er dette rimelig tregt (2 minutter for denne spørringen). Da skjønner man også at det ikke er bare-bare å kjøre disse svære modellene.

La oss installere de teknologier vi trenger

Først trenger vi både ollama, som er en åpen kildekode "runner" for LLM-er og veldig enkel å bruke, og OpenWebUI, som er et chat-grensesnitt – en åpen kildekode frontend for å snakke med LLM-er. Fra dokumentasjonen til OpenWebUI ser vi at det faktisk finnes et Docker-image som kapsler inn både Ollama og OpenWebUI, noe som gjør installasjonen trivielt enkel. Før vi kan gjøre det, må vi installere Docker først:
Slik gjør du det på Ubuntu 24.04 LTS (som vi bruker i dette inlegget), men flere installasjonsinstruksjoner finner du her.

# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
# Add the repository to Apt sources:
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
# Followed by
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin


Nå kan vi kjøre Ollama+OpenWebUI Docker-imaget slik:

docker run -d -p 8080:8080 -v ollama:/root/.ollama -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:ollama

Hvis du ikke er kjent med Docker, kan du tenke på denne kommandoen som å starte et lettvekts, isolert virtuelt miljø (kalt en container) på maskinen din. Inni denne containeren kjører Ollama og OpenWebUI som om de var installert direkte på systemet ditt—men de er pent pakket inn og atskilt fra ditt hovedmiljø. Containeren lytter på port 8080, noe som er viktig senere når vi skal konfigurere Nginx til å peke til denne containeren. Hvis du kjører Docker lokalt på maskinen din, bør du nå kunne besøke localhost:8080 og logge deg inn. Hvis du gjør dette på en VM, feks på Azure, må vi nå gjøre den sikkert tilgjengelig over internett.

La oss få ut tjenesten på nett

I eksemplene brukes chat.snokam.no. Du må selvfølgelig bytte dette ut med et domene som du selv kontrollerer. Merk også at vi ikke har serveren oppe nå, da VM-en vi bruker i praksis er altfor svak til å faktisk kjøre noen brukbare modeller og kun ble brukt som en demo.

Vi bruker nginx som webserver og certbot for å håndtere TLS-sertifikater (slik at vi får den fine "grønne låsen" på nettstedet vårt)

Først installerer vi nginx som og konfigurerer noen grunnleggende innstillinger for å peke til OpenWebUI.

#!/bin/bash
# Define your domain name
deepseek_domain="your_domain_here" # Replace with your actual domain
# Install Nginx
sudo apt update
sudo apt install -y nginx
# Create Nginx configuration file
sudo bash -c "cat > /etc/nginx/sites-available/${deepseek_domain}" <<EOL
server {
server_name ${deepseek_domain};
access_log /var/log/nginx/${deepseek_domain}.access.log;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_redirect off;
proxy_set_header Host \$http_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 900;
}
# Proxy for WebSocket connections
location /ws/ {
proxy_pass http://127.0.0.1:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade \$http_upgrade;
proxy_set_header Connection "Upgrade";
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 900;
}
}
EOL
# Set permissions for the configuration file
sudo chmod 644 /etc/nginx/sites-available/${deepseek_domain}
# Enable Nginx configuration
sudo ln -s /etc/nginx/sites-available/${deepseek_domain} /etc/nginx/sites-enabled/${deepseek_domain}
# Test Nginx configuration for syntax errors
sudo nginx -t
# Reload Nginx to apply changes
sudo systemctl reload nginx

Nginx-konfigurasjonen er ikke 100 % ferdig ennå og fungerer mer som en plassholder, men den vil bli fullført etter at vi har installert sertifikatene og konfigurert serveren til å håndtere TLS med certbot sitt nginx-plugin.
Nginx må konfigureres til å videresende innkommende trafikk til OpenWebUI-tjenesten som kjører i bakgrunnen.

For å sikre sikker kommunikasjon må vi også konfigurere Nginx til å lytte på portene 80 (HTTP) og 443 (HTTPS). I tillegg må vi generere TLS-sertifikater for å verifisere eierskapet til domenet "chat.snokam.no" og etablere tillit med klienter som besøker siden. Hele denne prosessen håndteres med Certbot i kombinasjon med Let's Encrypt.

Certbot forenkler prosessen med å få og fornye TLS-sertifikater. For å begynne må vi generere en sertifikatforespørsel, hvor vi spesifiserer at vi vil bevise domenets eierskap via DNS. Siden vi kontrollerer DNS-serveren og kan redigere oppføringene for "chat.snokam.no", kan vi legge til de nødvendige TXT-records for verifisering. Dette gjøres som regel ved at du logger deg inn der du har kjøpt domenet, og finner frem til et sted hvor du kan legge til DNS-poster.

Kjør følgende kommando for å starte sertifikatforespørselen:

certbot certonly --manual --preferred-challenges=dns -d {your_domain_here}
# In our case, {your_domain_here} is then chat.snokam.no

Etter det, vil du få en prompt som forteller deg hva du skal gjøre.

Certbot vil be deg om å legge til en spesifikk TXT-record i DNS-konfigurasjonen din under subdomenet _acme-challenge.chat.snokam.no. Denne posten fungerer som bevis på at du kontrollerer domenet. Når TXT-recorden er lagt til og har blitt propagert, vil Certbot automatisk verifisere den og utstede sertifikatet fra Let's Encrypt.

Etter å ha mottatt sertifikatet, konfigurer DNS-serveren din til å legge til en "A"-record for "chat.snokam.no", som peker til den offentlige IP-adressen til din virtuelle maskin.

Som et siste steg kan vi nå bruke Certbot sin nginx-integrasjon for automatisk å oppdatere nginx-konfigurasjonen slik at den hanterar TLS riktig. Dette gjøres med den enkle kommandoen
certbot --nginx -d chat.snokam.no

Denne kommandoen konfigurerer nå nginx-serveren slik at vi får ønsket oppførsel:

# contents of /etc/nginx/sites-enabled/chat.snokam.no
server {
server_name chat.snokam.no;
access_log /var/log/nginx/chat.snokam.no.access.log;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_redirect off;
proxy_set_header Host $http_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 900;
}
# Proxy for WebSocket connections (Denne var vansklig att finna ut att den trengtes hehe!)
location /ws/ {
proxy_pass http://127.0.0.1:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
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 900;
}
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/chat.snokam.no/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/chat.snokam.no/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = chat.snokam.no) {
return 301 https://$host$request_uri;
} # managed by Certbot
server_name chat.snokam.no;
listen 80;
return 404; # managed by Certbot
}

Med disse stegene fullført er din selvhostede versjon av applikasjonen fullt funksjonell og sikret med HTTPS. Selv om vi stoler på at Azure ivaretar sikkerheten og ikke sender dataene våre fra VM-en til USA, kan disse stegene også utføres på en lokal Linux-server eller en hjemmeserver for fullstendig isolasjon og kontroll. Dette sikrer at ingen eksterne skyleverandører har tilgang til ditt miljø. Merk at den første brukeren som logger inn på OpenWebUI etter installasjonen blir administrator, så sørg for at du er den første som oppretter en konto. Merk også at sertifikatet fra Let's Encrypt utløper etter 3 måneder, så det må fornyes. Dette kan automatiseres, men er utenfor omfanget av dette blogginnlegget.

Noen avsluttende ord

Er dette oppsettet egentlig nyttig? Vel, hvis du har en kraftig maskin on-prem som ikke blir brukt, kan du kjøre denne koden på den, eller bruke enda kraftigere modeller med flere vekter, som deepseek:671b-modellen. Mer praktisk er det kanskje å bruke OpenWebUI i kombinasjon med OpenAI sine API-endepunkter som er tilgjengelige i Azure. Disse AI-modellene kan velges sån at de kjører i Stockholm og er dermed GDPR-kompatible (så lenge du stoler på at Azure overholder dette), og kan også integreres med OpenWebUI. Dette er også betydelig billigere og raskare.

Ulempen er at du ikke kan kjøre det helt isolert eller "offline", og du må bruke OpenAI-modeller som ikke er mulige att laste ned. Hvis du er interessert i støtte eller veiledning om hvordan AI kan integreres trygt og GDPR-kompatibelt i ditt miljø, ta kontakt med hei@snokam.no for en prat – vi hjelper deg gjerne!

En annen ting: Hvis dere fortsatt er usikre på hva Deepseek handler om, kan dere sjekke ut artikkelen som min kollega Simen skrev for noen uker siden!