SSD Nodes Learn
Gidsen Matt ConnorDoor Matt Connor · Bijgewerkt 2026-07-24

Ollama op een VPS hosten en beveiligen

Leer hoe u Ollama veilig op een VPS installeert. Een 7B model vereist 8 GB RAM en levert 4 tot 10 tokens per seconde op via 127.0.0.1:11434/v1.

Wat u bouwt

Een enkel open-weight taalmodel dat draait op een eigen server. U communiceert hiermee via een HTTP API en optioneel via een chatpagina in uw browser. Ollama is de component die het model downloadt, in het geheugen laadt en verzoeken afhandelt op http://127.0.0.1:11434. De installatie gebeurt met één commando. De complexe onderdelen liggen elders: het kiezen van een model dat binnen het RAM-geheugen van uw VPS past, en het voorkomen dat u per ongeluk een onbeveiligde inference server publiceert op het internet.

Eerst twee belangrijke waarschuwingen. Een VPS zonder GPU draait kleine modellen traag. Daarnaast heeft de API geen ingebouwde authenticatie. Beide punten worden hieronder uitgebreid behandeld, omdat dit de meest voorkomende fouten zijn.

De realiteit van de schaalbaarheid, in eenvoudige getallen

Het geheugengebruik van een model is ongeveer gelijk aan de bestandsgrootte, plus circa één gigabyte aan runtime overhead, plus extra geheugen voor het context window. De standaardmodellen van Ollama zijn 4-bit gekwantiseerd (gelabeld als Q4). Dit verbruikt ongeveer een half gigabyte RAM voor elke miljard parameters. De berekening is dus eenvoudig en bepalend voor de rest.

Een 3B model zoals llama3.2:3b heeft een downloadgrootte van ~2 GB en vereist ongeveer 4 GB vrij RAM om te draaien. Een 7B of 8B model zoals mistral:7b of llama3.1:8b neemt ~5 GB in beslag op de schijf en vereist ongeveer 8 GB RAM, met 16 GB voor optimale prestaties. Een 13B of 14B model vereist ongeveer 16 GB. Alles in de range van 30B tot 70B vereist een systeem met veel RAM of, realistisch gezien, een GPU. Op een CPU VPS past het model ofwel niet, of de antwoorden zijn zo traag dat het systeem onbruikbaar is.

Wat betreft de snelheid: dit onderdeel wordt vaak onderschat. CPU-inferentie wordt beperkt door de geheugenbandbreedte, niet door de kloksnelheid. Een vCPU VPS met gedeelde resources heeft een beperkte bandbreedte. Reken op een snelheid van enkele eenheden tot lage dubbele cijfers tokens per seconde: een 7-8B Q4 model haalt mogelijk 4 tot 10 tokens per seconde, een 3B model 10 tot 25. Een GPU is ongeveer een factor 10 sneller. Dit zijn ruwe schattingen. De enige betrouwbare methode is het meten van uw eigen systeem, zoals wordt uitgelegd bij de run-stap hieronder. Vertrouw op uw eval rate, niet op een getal in een artikel, inclusief dit artikel.

De praktische conclusie: kleine gekwantiseerde modellen op een CPU zijn nuttig voor het opstellen van concepten, samenvatten en classificatie, mits u de snelheid accepteert. Voor alles wat groter of sneller moet, dient u te rekenen op een GPU-instantie.

Om een specifiek model te vergelijken met een specifiek systeem, kunt u het geheugengebruik hier schatten:

ToolLLM VRAM and model-size calculator

Ollama installeren

Er zijn twee eenvoudige methoden. Het officiële script is de makkelijkste optie op een bare VPS:

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

Hiermee wordt een systeemgebruiker genaamd ollama aangemaakt, wordt het binary geïnstalleerd in /usr/local/bin/ollama, en wordt een systemd-service genaamd ollama.service geregistreerd. Deze service start automatisch bij het opstarten en bindt aan 127.0.0.1:11434. Controleer of de service actief is:

systemctl status ollama
ollama --version

Als u al Docker gebruikt, gebruik dan de container:

docker run -d --name ollama \
  -p 127.0.0.1:11434:11434 \
  -v ollama:/root/.ollama \
  --restart always \
  ollama/ollama

Let op het 127.0.0.1: prefix bij de port mapping. Dit bindt de port uitsluitend aan localhost. Het gebruik van -p 11434:11434 in plaats daarvan publiceert de port op elke interface; dit is de fout waar de sectie over beveiliging voor waarschuwt. Kies één installatiemethode; voer het script en de container niet tegelijkertijd uit, anders ontstaan er conflicten over de port.

Haal uw eerste model op en start het

ollama pull llama3.2:3b
ollama run llama3.2:3b

pull downloadt de modellagen naar de schijf (ongeveer 2 GB voor dit model). run laadt deze in het geheugen en start een >>> prompt. Typ een vraag. Het eerste token kan enkele seconden duren omdat de gewichten van de schijf naar het RAM worden geladen. Daarna wordt het antwoord gestreamd. Typ /bye om de chat te verlaten; Ollama blijft op de achtergrond draaien.

Bekijk wat er geladen is en hoe het geheugen wordt gebruikt:

ollama ps

De PROCESSOR kolom geeft de werkelijke status aan. 100% CPU betekent dat er geen GPU wordt gebruikt, wat de oorzaak is van de lage snelheid. Meet de werkelijke snelheid met de verbose flag:

ollama run --verbose llama3.2:3b "Write two sentences about Linux."

De eval rate regel die aan het einde wordt weergegeven, toont het aantal tokens per seconde op deze hardware. Dit is de waarde waar u rekening mee moet houden bij het plannen.

Locatie van modellen en benodigde schijfruimte

Modellen die via het script zijn geïnstalleerd en als service draaien, staan in de home-directory van de ollama-gebruiker:

sudo du -sh /usr/share/ollama/.ollama/models

Modellen die interactief met uw eigen gebruiker worden uitgevoerd, staan in ~/.ollama/models. In de container staan ze in de ollama genaamde volume. Dit is belangrijk omdat gekwantiseerde weights snel in omvang toenemen: een 3B is ~2 GB, een 7-8B is ~5 GB, een 14B is ~9 GB. Als u vier modellen downloadt om ze te vergelijken, heeft u ongemerkt al 20 GB verbruikt. Bereken de schijfruimte op basis van de modellen die u wilt bewaren en verwijder de rest met ollama rm <model>.

Voer het uit als een service die u beheert

Het installatiescript heeft ollama.service al geregistreerd, waardoor het zonder verdere actie opnieuw start bij het opstarten. De instelling die het waard is om aan te passen, is hoe lang een model in het geheugen blijft staan. Bij sommige configuraties is ook het bind address relevant. Beide instellingen worden in een systemd drop-in geplaatst, zodat een Ollama upgrade deze niet overschrijft:

sudo systemctl edit ollama.service

Voeg dit toe onder de [Service] header die de editor weergeeft:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE bepaalt hoe lang een model in het geheugen blijft staan na de laatste aanvraag (standaard 5 minuten). Verhoog deze waarde op een systeem dat u de hele dag gebruikt om te voorkomen dat de weights telkens opnieuw geladen moeten worden. Stel deze in op 0 op een systeem met beperkte middelen om RAM direct vrij te maken zodra een aanvraag is voltooid. systemctl edit herlaadt de unit files voor u; herstart het systeem om de wijziging toe te passen:

sudo systemctl restart ollama

Het belangrijkste beveiligingspunt

Standaard bindt Ollama aan 127.0.0.1:11434, waardoor alleen processen op de VPS zelf erbij kunnen. Deze standaardinstelling is correct. Laat deze zo staan.

De API heeft geen authenticatie. Geen enkele. Er is geen API-key, geen login, geen rate limit en geen allow-list. Iedereen die poort 11434 kan bereiken, kan elk model dat u heeft gedownload uitvoeren, nieuwe modellen downloaden, deze verwijderen, en uw CPU of GPU onbeperkt op volledige belasting zetten. Scanners zoals Shodan indexeren duizenden openstaande Ollama-instanties; een blootgestelde instantie wordt binnen enkele uren gevonden en misbruikt.

Dit is de enige fout die u nooit mag maken: stel OLLAMA_HOST=0.0.0.0 niet in en open poort 11434 niet in uw firewall. Hiermee publiceert u een ongeauthenticeerde inference server naar het gehele internet. Geen enkele configuratie maakt een directe verbinding via 11434 op 0.0.0.0 veilig, omdat er geen instellingen zijn voor authenticatie in Ollama — de authenticatie bestaat simpelweg niet.

Er zijn drie veilige manieren om het model te bereiken vanaf een andere locatie dan de server:

  • Houd het lokaal. Als de enige aanroeper een ander programma op dezelfde VPS is — een cron-script, een bot, of een MCP-server die uw tools verbindt met het model — laat de bind-instelling dan op 127.0.0.1 staan en laat dat programma http://127.0.0.1:11434 aanroepen. Er wordt niets blootgesteld en er is niets extra's nodig.
  • Gebruik een private tunnel. Plaats de VPS op een WireGuard VPN die u zelf host, stel OLLAMA_HOST in op het tunnel-adres (bijvoorbeeld 10.8.0.1, niet 0.0.0.0), en alleen VPN-peers kunnen verbinding maken. Het publieke internet ziet nog steeds niets op poort 11434.
  • Gebruik een authenticerende reverse proxy. Gebruik TLS en vereis een wachtwoord of token via nginx, Traefik of Caddy, en gebruik daarna een proxy naar 127.0.0.1:11434. Ollama behoudt de localhost-bind; de proxy is het enige dat luistert op de publieke poort. Dit is vergelijkbaar met het plaatsen van een Let's Encrypt-certificaat op nginx voor een lokale service.

De optie met de reverse proxy is precies wat de chat UI u in de volgende stap biedt, inclusief een echte login.

Voeg een chat UI toe met Open WebUI, achter TLS

Open WebUI is een self-hosted chatinterface. Draai deze in Docker en verbind deze met de lokale Ollama:

docker run -d \
  --name open-webui \
  --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data \
  --restart always \
  ghcr.io/open-webui/open-webui:main

De --network=host flag is het cruciale detail op een Linux VPS. Deze plaatst de container in de network namespace van de host. Hierdoor is 127.0.0.1 binnen de container de loopback van de host zelf. De container bereikt Ollama op 127.0.0.1:11434 zonder dat Ollama op een andere interface hoeft te luisteren. De bridge-network methode die elders wordt beschreven — --add-host=host.docker.internal:host-gateway met OLLAMA_BASE_URL=http://host.docker.internal:11434 — werkt hier niet. Die naam verwijst naar de Docker bridge gateway. Een service die gebonden is aan 127.0.0.1 op de host is niet bereikbaar via de bridge. Open WebUI geeft daarom de foutmelding dat er geen verbinding met Ollama mogelijk is.

Het nadeel van host networking is dat Open WebUI nu op poort 8080 op elke interface van de host luistert. Elke -p mapping wordt genegeerd en Docker geeft hiervoor een waarschuwing. Sluit daarom poort 8080 in zowel de host- als de provider-firewall. Gebruik de TLS reverse proxy als de enige publieke toegangspoort. Bij het eerste bezoek vraagt Open WebUI om een admin-account aan te maken. Dit account dient als uw authenticatielaag; kies daarom een sterk wachtwoord.

Om de chat via HTTPS vanaf uw laptop te openen, plaatst u een TLS reverse proxy voor 127.0.0.1:8080. Als u al meerdere Docker-apps op de server draait, is Traefik met automatische TLS voor meerdere apps de meest efficiënte oplossing. Eén label-blok regelt het certificaat en routeert chat.example.com naar Open WebUI. De regel uit de security-sectie blijft van kracht: de proxy beheert de publieke poort en de login, terwijl Ollama op localhost blijft en de eigen 8080 van Open WebUI achter de firewall blijft.

Gebruik de OpenAI-compatibele endpoint vanuit uw code

Ollama ondersteunt een subset van de OpenAI chat API op /v1. Hierdoor werken de meeste OpenAI client libraries na het aanpassen van twee zaken: de base URL en een tijdelijke key.

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama")

resp = client.chat.completions.create(
    model="llama3.2:3b",
    messages=[{"role": "user", "content": "Name three Linux distributions."}],
)
print(resp.choices[0].message.content)

De api_key is vereist door de client library, maar wordt door Ollama genegeerd; elke string is geldig. model moet een naam zijn die u al heeft gedownload; een onbekende naam resulteert in model "x" not found, try pulling it first. Een standaard curl-opdracht werkt volgens hetzelfde principe:

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Hello"}]}'

Dit is ook de methode om het model te koppelen aan agent- en editor-tools. Als u al op de machine ontwikkelt, kan een lokaal model scripts en plugins ondersteunen naast Claude Code die draait op de VPS binnen tmux. Hierdoor blijft privaat conceptwerk goedkoop en gescheiden van een betaalde API, terwijl zware redeneringen worden uitgevoerd door een gehost model.

Foutmodi, met de exacte strings die u zult zien

Het proces wordt halverwege de generatie "Killed". U start een groot model en de terminal print Killed, of het serverlog laat llama runner process has terminated: signal: killed zien. De Linux OOM killer heeft het proces gestopt omdat het model meer RAM nodig heeft dan de machine beschikbaar heeft. Bevestig de oorzaak met sudo dmesg | grep -i oom, waar u een regel ziet zoals Out of memory: Killed process ... (ollama). De oplossing is een kleiner of zwaarder gekwantiseerd model — llama3.2:3b in plaats van een 13B — of het toevoegen van swap. Met swap overleeft een belasting die net de fysieke RAM overschrijdt het proces traag in plaats van dat het crasht. Swap maakt een directe crash een traag antwoord; het maakt een 70B model niet praktisch op 4 GB.

"Error: model requires more system memory". Ollama weigert het model te starten en print Error: model requires more system memory (X GiB) than is available (Y GiB). Dit is de beleefde versie van de bovenstaande crash: Ollama heeft de berekening uitgevoerd en gestopt in plaats van de OOM killer te laten crashen. Het geeft u zelfs de twee getallen. Kies een model waarvan de vereisten lager zijn dan uw vrije RAM (controleer met free -h), verklein de context length, of stap over naar een grotere VPS. Geen enkele flag zorgt dat het model past — het geheugen is een fysieke limiet.

Het eerste token duurt erg lang, daarna werkt het goed. Een koud model print vijf tot dertig seconden niets, en streamt daarna normaal. Die pauze is het laden van de weights van de disk naar het RAM voor de eerste keer; trage opslag maakt dit probleem groter. Eenmaal geladen blijft het model aanwezig gedurende OLLAMA_KEEP_ALIVE, waardoor de tweede prompt direct antwoordt. Verhoog die waarde als de pauzes storend zijn, en gebruik ollama ps om te zien of een model momenteel geladen is.

Alles is simpelweg traag. Tien tokens per seconde of minder, zonder enige foutmelding. Dat is CPU inference die doet wat CPU inference doet. ollama ps toont 100% CPU, wat betekent dat er geen GPU aanwezig is. Dit is geen bug en geen instelling lost dit op, omdat de limiet de geheugenbandbreedte is en geen misconfiguratie. Gebruik een kleiner model, accepteer de snelheid, of stap over naar een GPU instance — en meet uw werkelijke snelheid met --verbose voordat u concludeert dat er iets kapot is.

Connection refused van een andere machine. U krijgt curl: (7) Failed to connect to <ip> port 11434: Connection refused vanaf uw laptop. Dit werkt volgens ontwerp: Ollama bindt alleen aan localhost. "Fix" dit niet door te binden aan 0.0.0.0, wat precies de beveiligingsfout is die hierboven wordt beschreven. Bereik het model via de VPN of via de authentiserende proxy.

U heeft 11434 blootgesteld aan het internet. Als u OLLAMA_HOST=0.0.0.0 heeft ingesteld, de firewall heeft geopend, en u nu model pulls ziet die u nooit heeft gestart of een CPU die op 100% staat door onbekende clients, dan bent u ontdekt en misbruikt. Dit is de belangrijkste fout, geen uitzondering. Bind opnieuw aan 127.0.0.1 of het VPN-adres, sluit 11434 in de firewall, en plaats authenticatie ervoor. Ga ervan uit dat alles dat bereikbaar was op dat adres terwijl het openstond, is opgevraagd door vreemden.

Backups en upgrades

Er is weinig data die verloren kan gaan. De modellen kunnen opnieuw worden gedownload. De enige zaken die een backup waard zijn, zijn de data volume van Open WebUI — accounts, chatgeschiedenis, instellingen — en eventuele zelfgeschreven systemd drop-in bestanden. Maak een backup van de volume met een tijdelijke container:

docker run --rm -v open-webui:/data -v "$PWD":/backup alpine \
  tar czf /backup/open-webui.tgz -C /data .

Upgrade Ollama door het install script opnieuw uit te voeren; upgrade Open WebUI met docker pull ghcr.io/open-webui/open-webui:main gevolgd door het opnieuw aanmaken van de container. Gebruik geen vaste versies voor de lange termijn: zowel de modelkwaliteit als de runtime veranderen snel. Lees daarom de release notes en voer nieuwe benchmarks uit op uw eigen systeem in plaats van te vertrouwen op de cijfers van het vorige kwartaal.

FAQ

Kan ik echt een LLM draaien op een VPS zonder GPU?

Ja, maar met beperkingen. Kleine gekwantiseerde modellen in de range van 3B tot 8B draaien op de CPU en zijn nuttig voor het opstellen van teksten, samenvatten en classificatie. Dit gebeurt echter traag, met een snelheid van enkele tot lage dubbele cijfers aan tokens per seconde op een gedeelde vCPU. Alles vanaf 13B is extreem traag of past niet in het RAM. Voor hoge snelheden of grotere modellen is een GPU-instance vereist.

Hoeveel RAM heeft elk model nodig?

Een vuistregel voor de standaard 4-bit gekwantiseerde modellen: ongeveer 0.5 GB RAM per miljard parameters voor de weights, plus ongeveer 1 GB overhead en extra ruimte voor de context. Een 3B model vereist dus ongeveer 4 GB vrije ruimte, een 7-8B model ongeveer 8 GB, en een 14B model ongeveer 16 GB. Controleer de beschikbare ruimte met free -h en houd rekening met het besturingssysteem en andere processen op de server.

Is de Ollama API beveiligd met authenticatie?

Nee. Ollama heeft geen ingebouwde authenticatie, API-key of rate limit. Iedereen die toegang heeft tot port 11434 heeft volledige controle. Daarom bindt Ollama standaard aan 127.0.0.1 en moet u port 11434 nooit blootstellen aan het internet via 0.0.0.0. Gebruik lokale toegang, een privé VPN, of een reverse proxy die een login toevoegt.

Hoe voeg ik een web chat interface toe?

Draai Open WebUI in Docker met --network=host zodat de loopback van de host wordt gedeeld en de native Ollama bereikbaar is op http://127.0.0.1:11434. Gebruik vervolgens een TLS reverse proxy voor port 8080 om toegang vanaf uw laptop mogelijk te maken. Houd 8080 gesloten in de firewall zodat de proxy de enige publieke toegangspoort is. Het eigen admin-account van Open WebUI verzorgt de login; u stelt het wachtwoord in bij de eerste keer opstarten.

Hoe kan ik het aanroepen vanuit mijn eigen applicatie?

Gebruik de OpenAI-compatibele endpoint op http://127.0.0.1:11434/v1. Wijs een OpenAI SDK toe aan deze base URL, gebruik een willekeurige string als API-key (deze wordt genegeerd) en stel model in op een model dat u heeft gedownload. Bestaande OpenAI-code werkt meestal zonder wijzigingen, behalve voor de base URL en de key.