Héberger Ollama sur un VPS : guide opérationnel avancé

Déployer Ollama prend quelques minutes. Le faire tourner de façon fiable sur la durée demande davantage d'attention. En production, trois points concentrent l'essentiel des problèmes : la gestion des modèles (lequel charger, lequel retirer pour libérer du disque), la surface d'attaque de l'API (non authentifiée par défaut sur le port 11434), et la consommation mémoire (un modèle mal dimensionné sature la RAM et fait tuer le processus par le noyau). Ce guide part du principe que le conteneur ollama tourne déjà et se concentre sur ces trois axes, plus l'intégration avec les outils de votre stack.

La taille d'un modèle s'exprime en milliards de paramètres (B) et détermine la RAM nécessaire. Un modèle 1B/3B tient en 2 à 3 Go et convient aux tâches simples (classification, résumé court) sur un VPS modeste. Un 7B/8B demande 5 à 6 Go en Q4 : c'est le rapport qualité/ressources le plus courant. Un 13B nécessite 9 à 10 Go, et un 70B dépasse 40 Go — réservé aux VPS hautes mémoire ou aux configurations GPU. Pour chaque taille, la quantisation ajuste le compromis qualité/vitesse : Q4_K_M offre un bon compromis qualité/vitesse sur CPU, Q8 conserve plus de précision au prix d'une RAM doublée. Avant de pull un modèle, vérifiez l'espace libre avec df -h et la RAM disponible avec free -h.

Par défaut, Ollama écoute sur 127.0.0.1:11434 sans authentification. Pour l'exposer à vos outils (Open WebUI, n8n, un script distant), placez nginx en frontal avec un jeton Bearer. Le bloc de configuration ci-dessous délègue l'accès à un jeton secret défini dans la variable $api_token, vérifie l'en-tête Authorization et proxifie vers Ollama. Le CORS est configuré pour accepter les requêtes de votre interface sans exposer l'API à tous les origines.

Dans /etc/nginx/sites-available/ollama :

map $http_authorization $api_token_valid {
    default 0;
    "Bearer VOTRE_TOKEN_SECRET" 1;
}
server {
    listen 443 ssl;
    server_name api-ia.votre-domaine.com;
    ssl_certificate /etc/letsencrypt/live/api-ia.votre-domaine.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api-ia.votre-domaine.com/privkey.pem;
    location / {
        if ($api_token_valid = 0) { return 401; }
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
        add_header Access-Control-Allow-Origin "https://ui.votre-domaine.com";
    }
}

Activez la configuration avec ln -s /etc/nginx/sites-available/ollama /etc/nginx/sites-enabled/ puis nginx -t && systemctl reload nginx.

Quatre situations reviennent régulièrement en production.

Modèle trop lent. La génération dépasse 2-3 tokens par seconde sur CPU pour un 7B ? Vérifiez que OLLAMA_NUM_THREADS n'est pas à 1 (défaut si non défini sur certaines images). Vérifiez aussi qu'un seul modèle est chargé (OLLAMA_MAX_LOADED_MODELS=1) : deux modèles simultanés se disputent les cœurs et la bande passante mémoire.

VRAM insuffisante (GPU). Si le journal Docker affiche CUDA out of memory ou ROCm error, le modèle ne tient pas en VRAM. Passez au tag q4_K_M ou réduisez OLLAMA_CONTEXT_SIZE. Ollama bascule en CPU si la VRAM est insuffisante, mais sans l'indiquer clairement : comparez les vitesses de génération pour le détecter.

Connexion API refusée. curl: (7) Failed to connect depuis l'extérieur alors que le service écoute ? Le pare-feu bloque le port 11434, ou nginx n'est pas démarré. Vérifiez avec ss -tlnp | grep 11434 (doit montrer 127.0.0.1, pas 0.0.0.0) et systemctl status nginx.

Signal killed / OOM. Le processus est tué par le noyau (OOM killer). La RAM du VPS est insuffisante pour le modèle sélectionné. Repassez à une taille inférieure ou activez un swap de 4 à 8 Go comme tampon : fallocate -l 4G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile. Le swap ralentit la génération mais évite les arrêts brutaux.

Ollama est un backend : il prend toute sa valeur quand d'autres services s'y connectent. Trois outils s'intègrent naturellement sur le même VPS.

Open WebUI expose une interface de conversation comparable à ChatGPT, branchée sur l'API Ollama locale. Dans son fichier d'environnement, définissez OLLAMA_BASE_URL=http://ollama:11434 (si les deux conteneurs partagent un réseau Docker) ou OLLAMA_BASE_URL=http://127.0.0.1:11434 si Open WebUI tourne sur le même hôte. Open WebUI gère la sélection du modèle, l'historique des conversations et la gestion des utilisateurs. Attention : le couplage Ollama ↔ Open WebUI expose une surface d'attaque supplémentaire à surveiller — voir la section CVE-2026-45672 ci-dessous.

LangFlow est un constructeur visuel de pipelines LLM. Ajoutez un nœud Ollama dans votre flow, renseignez http://127.0.0.1:11434 comme base URL et sélectionnez le modèle dans la liste déroulante. LangFlow appelle directement l'endpoint /api/generate sans authentification interne — placez-le sur le réseau privé du VPS, pas exposé publiquement.

n8n permet de déclencher des appels Ollama depuis un workflow d'automatisation. Utilisez le nœud HTTP Request pointant sur http://127.0.0.1:11434/api/chat avec un corps JSON contenant model et messages. Depuis n8n, vous pouvez chaîner un appel Ollama à une étape de récupération de données, d'envoi d'e-mail ou de webhook sortant sans écrire de code.

Publiée le 21 mai 2026 (GHSA-482j-2pq6-q5w4), cette vulnérabilité affecte toutes les versions d'Open WebUI antérieures à 0.8.12. Score CVSS : 8.8 (élevé).

Mécanique de l'attaque. Un utilisateur authentifié peut exécuter du code Python arbitraire via l'endpoint /api/v1/utils/code/execute, même si l'administrateur a désactivé l'exécution de code dans les réglages (ENABLE_CODE_EXECUTION=false). La garde est déclarée dans la configuration mais n'est jamais vérifiée côté API : n'importe quel compte vérifié sur l'instance peut déclencher l'exécution.

Impact. L'attaquant accède au backend Jupyter sous-jacent et peut lire des fichiers arbitraires sur le VPS, voler des secrets (clés d'API, jeton Ollama, variables d'environnement), ou établir une persistance. La confidentialité, l'intégrité et la disponibilité du serveur sont compromises.

Pourquoi c'est critique dans un couplage Ollama ↔ Open WebUI. Ollama et Open WebUI tournent souvent sur le même VPS, parfois dans le même réseau Docker, avec des secrets partagés (clé d'API OpenAI de repli, jeton Bearer de l'API Ollama). Un accès RCE sur Open WebUI donne donc un accès direct à l'API Ollama et aux modèles en mémoire, sans passer par le reverse proxy.

Correction. Mettez à jour Open WebUI vers la version 0.8.12 ou supérieure. Cette version applique la vérification de ENABLE_CODE_EXECUTION au niveau de l'endpoint API, là où elle aurait toujours dû l'être.

Vérifier votre version. Depuis le conteneur : docker exec open-webui cat /app/package.json | grep '"version"'. Si la sortie est inférieure à 0.8.12, la mise à jour est urgente : docker pull ghcr.io/open-webui/open-webui:main && docker stop open-webui && docker rm open-webui puis relancez avec les mêmes paramètres d'environnement.