Héberger sa propre IA sur un VPS Linux avec Ollama et Open WebUI, c'est garder ses conversations chez soi et ne plus payer à la requête. Mais l'API d'Ollama n'a aucune authentification : un port 11434 ouvert sur Internet, c'est une IA offerte à tout le monde. Ce guide vous montre une installation où seul Nginx, en HTTPS, est joignable de l'extérieur.
Pourquoi une instance Ollama exposée pose problème
Ollama fournit une API REST très pratique, mais sans mot de passe ni clé. Quiconque atteint le port peut lister vos modèles, en télécharger de nouveaux jusqu'à remplir le disque, en supprimer, ou lancer des générations qui occupent tout le processeur de votre VPS. Les mainteneurs considèrent que l'authentification doit être confiée à un reverse proxy : c'est donc à vous de la mettre en place.
Le risque n'a rien de théorique. En février 2026, le moteur de recherche de fuites LeakIX recensait plus de 12 000 instances Ollama accessibles sans authentification, dont plus de 1 400 hébergées en France. La même année, une faille de gravité élevée (CVE-2026-7482, surnommée « Bleeding Llama ») permettait de lire la mémoire d'un serveur Ollama joignable, sans aucun identifiant. Une instance qui n'écoute qu'en local n'est tout simplement pas atteignable par ce genre d'attaque.
L'architecture que nous allons mettre en place
- Ollama écoute uniquement sur
127.0.0.1:11434. - Open WebUI tourne dans Docker et écoute uniquement sur
127.0.0.1:3000. - Nginx est le seul service public : il reçoit le trafic en HTTPS (port 443) et le transmet à Open WebUI.
- Le pare-feu n'autorise que SSH, HTTP (pour le certificat) et HTTPS.
- Open WebUI gère les comptes : un administrateur, inscriptions fermées.
Le guide suppose un VPS Linux sous Ubuntu 24.04 ou Debian 12, un accès sudo, Docker déjà installé (voir notre guide d'installation de Docker sur VPS Linux) et un sous-domaine, par exemple ia.votre-domaine.fr, pointant vers l'adresse IP du serveur.
Quel VPS choisir : grille RAM et CPU sans GPU
Sur un VPS sans carte graphique, tout se joue sur la RAM et le nombre de cœurs. Le modèle doit tenir entièrement en mémoire, avec une marge pour le contexte de conversation, Open WebUI (prévoyez environ 1 Go) et le système. Les tailles ci-dessous sont celles des versions par défaut (quantifiées en 4 bits) publiées dans la bibliothèque d'Ollama.
| VPS | Modèles réalistes | Exemples (taille du téléchargement) | Usage |
|---|---|---|---|
| 4 Go de RAM, 2 vCPU | 1 à 3 milliards de paramètres | gemma3:1b (806 Mo), qwen3:1.7b (1,4 Go), llama3.2:3b (2,0 Go) | Tests, résumés courts, petit assistant |
| 8 Go de RAM, 3 vCPU | Jusqu'à 4B confortablement, 8B possible mais juste | qwen3:4b (2,5 Go), gemma3:4b (3,4 Go), qwen3:8b (5,2 Go) | Usage personnel quotidien |
| 12 Go de RAM, 4 vCPU | 8B confortablement, 12-14B possible mais juste | qwen3:8b (5,2 Go), gemma3:12b (8,2 Go), qwen3:14b (9,3 Go) | Rédaction, code, petite équipe |
| 32 Go de RAM et plus (serveur dédié) | 27 à 32B | gemma3:27b (17 Go), qwen3:32b (20 Go) | Qualité supérieure, réponses lentes sans GPU |
Chez SoLinux, cela correspond au VPS Linux 04G (4 Go, 2 cœurs, 45 Go NVMe), au VPS Linux 08G (8 Go, 3 cœurs, 50 Go NVMe) et au VPS Linux 12G (12 Go, 4 cœurs, 70 Go NVMe), sans engagement, à partir de 7 € par mois pour le 04G, en France, en Allemagne ou à New York. Pour un usage régulier, le 08G est le meilleur point de départ ; le 12G devient intéressant dès que vous voulez un modèle 8B à l'aise ou plusieurs utilisateurs.
Soyez réaliste sur la vitesse : sans GPU, un modèle 7-8B produit sa réponse mot après mot, à quelques mots par seconde, et le processeur est occupé à 100 % pendant la génération. Les modèles de 3-4B offrent souvent le meilleur compromis. Le stockage NVMe compte surtout pour le chargement initial du modèle en mémoire.
Étape 1 : préparer le serveur et le pare-feu
Commencez par mettre le système à jour, puis fermez tout ce qui n'est pas indispensable. Avec UFW :
sudo apt update && sudo apt upgrade -y
sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verboseSi vous préférez nftables directement (et pas en même temps qu'UFW), voici l'équivalent minimal pour la chaîne d'entrée, à placer dans /etc/nftables.conf :
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
ct state established,related accept
iif "lo" accept
ip protocol icmp accept
ip6 nexthdr icmpv6 accept
tcp dport { 22, 80, 443 } accept
}
}sudo nft -c -f /etc/nftables.conf # vérifie la syntaxe
sudo systemctl enable --now nftablesPiège classique : un port publié par Docker avec -p 3000:8080 est ouvert sur toutes les interfaces et contourne les règles UFW, car Docker écrit ses propres règles de pare-feu. C'est pour cette raison que nous ne publierons aucun port Docker dans ce guide.
Étape 2 : installer Ollama et le garder en local
Ollama s'installe sur Linux avec son script officiel, qui crée un utilisateur ollama et un service systemd :
curl -fsSL https://ollama.com/install.sh | shVérifiez ensuite que le service tourne :
ollama --version
sudo systemctl enable --now ollama
sudo systemctl status ollamaPar défaut, Ollama écoute sur 127.0.0.1:11434. Beaucoup de tutoriels vous font passer OLLAMA_HOST à 0.0.0.0 pour que Docker puisse le joindre : c'est précisément ce qui expose l'API. Fixez plutôt l'adresse locale de façon explicite, avec un fichier d'override systemd qui survivra aux mises à jour :
sudo systemctl edit ollamaAjoutez ces lignes dans la zone prévue :
[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_NUM_PARALLEL=1"Les deux dernières variables limitent Ollama à un modèle chargé et une requête à la fois : sur un VPS sans GPU, cela évite de saturer la RAM. Rechargez et contrôlez l'écoute :
sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -tlnp | grep 11434
# attendu : 127.0.0.1:11434, jamais 0.0.0.0:11434 ni [::]:11434
curl http://127.0.0.1:11434
# attendu : Ollama is runningTéléchargez ensuite un modèle adapté à votre VPS et testez-le en ligne de commande :
ollama pull qwen3:4b
ollama run qwen3:4b "Explique en une phrase ce qu'est un reverse proxy."
ollama listÉtape 3 : lancer Open WebUI avec Docker, sans port public
La commande de démarrage rapide d'Open WebUI publie le port 3000 et joint Ollama via host.docker.internal, ce qui oblige Ollama à écouter sur toutes les interfaces. Nous faisons autrement : le conteneur partage la pile réseau de l'hôte (--network=host), joint Ollama sur 127.0.0.1 et n'écoute lui-même que sur 127.0.0.1:3000 grâce aux variables HOST et PORT.
# clé secrète fixe : sans elle, les sessions sautent à chaque redémarrage
sudo mkdir -p /etc/open-webui
openssl rand -hex 32 | sudo tee /etc/open-webui/secret > /dev/null
sudo chmod 600 /etc/open-webui/secret
DOMAINE=ia.votre-domaine.fr # votre sous-domaine
sudo docker run -d --name open-webui \
--network=host \
-e HOST=127.0.0.1 \
-e PORT=3000 \
-e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
-e WEBUI_SECRET_KEY="$(sudo cat /etc/open-webui/secret)" \
-e CORS_ALLOW_ORIGIN="https://$DOMAINE" \
-v open-webui:/app/backend/data \
--restart always \
ghcr.io/open-webui/open-webui:mainLe volume open-webui conserve les comptes, les conversations et les réglages. Pour la production, vous pouvez remplacer l'étiquette main par un numéro de version précis afin de choisir vous-même le moment des mises à jour. Vérifiez l'écoute après une minute (le premier démarrage est un peu long) :
sudo ss -tlnp | grep 3000
# attendu : 127.0.0.1:3000
curl -I http://127.0.0.1:3000Étape 4 : créer le compte administrateur avant toute exposition
Le premier compte créé sur Open WebUI devient administrateur. Ne laissez pas cette place à un inconnu qui tomberait sur votre sous-domaine avant vous : créez-le avant de configurer Nginx, à travers un tunnel SSH. Depuis votre ordinateur :
ssh -L 3000:127.0.0.1:3000 utilisateur@IP_DU_VPSOuvrez ensuite http://localhost:3000 dans le navigateur de votre ordinateur et créez le compte administrateur avec un mot de passe long et unique. Puis, dans les réglages d'administration (section des utilisateurs ou des inscriptions, selon la version) :
- désactivez les nouvelles inscriptions ;
- si vous devez les laisser ouvertes un moment, gardez le rôle par défaut des nouveaux utilisateurs sur « en attente » (pending) : chaque compte devra être validé par vous ;
- créez vous-même les comptes de vos collaborateurs depuis la gestion des utilisateurs.
Ne désactivez jamais l'authentification (WEBUI_AUTH=False) sur une instance accessible depuis Internet.
Étape 5 : Nginx en HTTPS devant Open WebUI
Installez Nginx et Certbot :
sudo apt install -y nginx certbot python3-certbot-nginxAjoutez une limite de tentatives de connexion, dans /etc/nginx/conf.d/limites.conf :
limit_req_zone $binary_remote_addr zone=owui_login:10m rate=5r/m;Puis créez /etc/nginx/sites-available/open-webui. Open WebUI utilise des WebSockets et diffuse ses réponses en continu : il faut donc passer en HTTP/1.1, transmettre les en-têtes Upgrade et désactiver la mise en tampon, sans quoi les réponses arrivent d'un bloc ou se coupent.
server {
listen 80;
server_name ia.votre-domaine.fr;
client_max_body_size 50M;
# limite les essais de mot de passe
location = /api/v1/auths/signin {
limit_req zone=owui_login burst=5 nodelay;
proxy_pass http://127.0.0.1:3000;
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;
}
location / {
proxy_pass http://127.0.0.1:3000;
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_buffering off;
proxy_cache off;
proxy_read_timeout 1800s;
proxy_send_timeout 1800s;
}
}Activez le site, testez la configuration et demandez le certificat. Certbot ajoute lui-même le bloc HTTPS sur le port 443 et la redirection depuis HTTP :
sudo ln -s /etc/nginx/sites-available/open-webui /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d ia.votre-domaine.fr --redirect
sudo certbot renew --dry-runPour une petite équipe, vous pouvez ajouter une seconde barrière avec auth_basic dans le bloc location /, ou restreindre l'accès à quelques adresses IP avec allow et deny. Ces protections s'ajoutent au compte Open WebUI, elles ne le remplacent pas.
Vérifier que rien n'est exposé
Sur le serveur, listez les ports en écoute : seuls 22, 80 et 443 doivent apparaître sur une adresse publique.
sudo ss -tlnpDepuis votre ordinateur, testez l'adresse IP du VPS : les ports 11434 et 3000 doivent refuser la connexion ou ne pas répondre. Seul votre sous-domaine en HTTPS, ouvert dans votre navigateur, doit afficher la page de connexion.
nc -zv -w 3 IP_DU_VPS 11434 # doit échouer
nc -zv -w 3 IP_DU_VPS 3000 # doit échouerMaintenir l'installation à jour
- Ollama : relancez le script d'installation officiel. Votre override systemd est conservé ; contrôlez quand même l'écoute avec
ss -tlnpaprès chaque mise à jour. La faille CVE-2026-7482 est corrigée depuis la version 0.17.1 : vérifiez la vôtre avecollama --versionet ne laissez pas traîner une version ancienne. - Open WebUI :
docker pullde l'image, puisdocker stop,docker rmet relance de la même commandedocker run. Le volume garde vos données. - Sauvegardes : sauvegardez régulièrement le volume
open-webui(comptes et conversations) ; les modèles, eux, se retéléchargent. - Journaux :
journalctl -u ollama,docker logs open-webuiet/var/log/nginx/pour repérer les tentatives de connexion répétées.
Questions fréquentes
Faut-il un GPU pour faire tourner Ollama sur un VPS ?
Non. Ollama fonctionne sur processeur seul. Les réponses sont plus lentes qu'avec une carte graphique, mais un modèle de 3 à 8 milliards de paramètres reste tout à fait utilisable sur un VPS de 8 à 12 Go de RAM.
Comment utiliser l'API d'Ollama depuis une autre machine sans l'exposer ?
Passez par un tunnel SSH : ssh -L 11434:127.0.0.1:11434 utilisateur@IP_DU_VPS, puis interrogez http://localhost:11434 depuis votre ordinateur. Pour une application tierce, Open WebUI peut aussi fournir des clés d'API par utilisateur, derrière votre Nginx en HTTPS.
Open WebUI n'affiche aucun modèle, que faire ?
Vérifiez que ollama list renvoie bien des modèles, que curl http://127.0.0.1:11434 répond, et que le conteneur a été lancé avec --network=host et OLLAMA_BASE_URL=http://127.0.0.1:11434. La connexion se contrôle aussi dans les réglages d'administration, rubrique des connexions.
Combien de personnes peuvent l'utiliser en même temps ?
Sans GPU, comptez une génération à la fois : les autres requêtes attendent leur tour. Pour deux ou trois utilisateurs occasionnels, un VPS 12G avec un modèle 4B ou 8B convient ; au-delà, un serveur dédié avec plus de cœurs et de RAM devient nécessaire.