Comment deployer Ollama en production securisee avec Docker en 7 etapes

La popularite d Ollama pour l inference LLM en local a explose en 2025-2026. Des milliers d equipes francaises l utilisent pour des prototypes RAG, des assistants de code internes, ou des chatbots de support client — le tout en gardant les donnees sur leur propre infrastructure. Le probleme : la transition du laptop de developpement a la production expose des failles de securite critiques. La recente vulnerabilite Bleeding Llama (CVE-2026-7482, CVSS 9.1) a demontre qu un serveur Ollama expose sans protection permet a n importe qui de lire l integralite de sa memoire — cles API, conversations, prompts confidentiels inclus.

Ce guide vous accompagne etape par etape pour transformer un deploiement Ollama fragile en un service de production securise. Chaque etape est illustree par du code fonctionnel, teste sur des infrastructures cloud francaises (OVH, Scaleway) et adapte aux contraintes RGPD. A la fin de ce tutoriel, vous aurez un stack complet : conteneur Docker optimise, reverse proxy avec authentification, TLS, rate limiting, monitoring, et sauvegardes automatiques.

Etape 1 — Dockerfile optimise pour la production

La premiere etape consiste a creer un Dockerfile qui durcit Ollama pour un usage production. L image officielle ollama/ollama est un bon point de depart mais manque de controles de securite. Notre Dockerfile ajoute un utilisateur non-root, des health checks, et un point d entree qui force la configuration securisee :

# Dockerfile.ollama-production
FROM ollama/ollama:0.17.2 AS base

# Securite : utilisateur non-root
RUN groupadd -r ollama && useradd -r -g ollama -d /home/ollama -s /bin/bash ollama

# Repertoires avec permissions correctes
RUN mkdir -p /home/ollama/.ollama /var/log/ollama \
    && chown -R ollama:ollama /home/ollama /var/log/ollama

# Health check integre
HEALTHCHECK --interval=30s --timeout=10s --start-period=60s --retries=3 \
    CMD curl -f http://localhost:11434/api/tags || exit 1

# Variables d'environnement securisees
ENV OLLAMA_HOST=127.0.0.1:11434
ENV OLLAMA_MODELS=/home/ollama/.ollama/models
ENV OLLAMA_KEEP_ALIVE=5m
ENV OLLAMA_NUM_PARALLEL=4
ENV OLLAMA_MAX_LOADED_MODELS=2

# Executer en tant qu'utilisateur non-root
USER ollama
WORKDIR /home/ollama

# Exposition du port (interne au network Docker uniquement)
EXPOSE 11434

ENTRYPOINT ["/bin/ollama"]
CMD ["serve"]

Les points cles de ce Dockerfile : l utilisateur non-root empeche qu une exploitation de vulnerabilite donne un acces root au conteneur. La variable OLLAMA_HOST=127.0.0.1:11434 force Ollama a n ecouter que sur localhost — meme si le conteneur est accidentellement expose sur le reseau, le service n est pas accessible directement. Le health check permet a Docker et aux orchestrateurs de detecter automatiquement si le service est down.

Etape 2 — Docker Compose avec support GPU et reseau isole

Le fichier docker-compose.yml orchestre l ensemble du stack : Ollama, le reverse proxy nginx, et optionnellement le monitoring. L element critique est le reseau Docker isole qui empeche Ollama d etre accessible depuis l exterieur du stack :

# docker-compose.yml
version: '3.8'

services:
  ollama:
    build:
      context: .
      dockerfile: Dockerfile.ollama-production
    container_name: ollama-prod
    restart: unless-stopped
    networks:
      - ollama-internal  # Reseau interne uniquement
    volumes:
      - ollama-models:/home/ollama/.ollama
      - ollama-logs:/var/log/ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
        limits:
          memory: 16G
    # PAS de ports: section -> non accessible depuis l'hote
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp:size=2G

  nginx:
    image: nginx:alpine
    container_name: ollama-proxy
    restart: unless-stopped
    ports:
      - "443:443"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro
      - ./nginx/auth_tokens.conf:/etc/nginx/auth_tokens.conf:ro
      - ./certbot/conf:/etc/letsencrypt:ro
      - ./certbot/www:/var/www/certbot:ro
    networks:
      - ollama-internal
      - ollama-external
    depends_on:
      ollama:
        condition: service_healthy

  certbot:
    image: certbot/certbot
    volumes:
      - ./certbot/conf:/etc/letsencrypt
      - ./certbot/www:/var/www/certbot
    entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'"

networks:
  ollama-internal:
    internal: true  # Pas d'acces Internet
  ollama-external:
    driver: bridge

volumes:
  ollama-models:
  ollama-logs:

Points de securite critiques dans cette configuration. Le reseau ollama-internal est marque internal: true, ce qui signifie qu il n a aucun acces a Internet et n est pas routable depuis l hote. Le conteneur Ollama n a pas de section ports — il n est accessible que via le reseau interne Docker. L option read_only: true monte le filesystem du conteneur en lecture seule, empechant un attaquant d ecrire des fichiers malveillants. Le tmpfs fournit un espace temporaire en RAM pour les operations qui necessitent l ecriture.

Pour les equipes qui deploient sur OVH Public Cloud ou Scaleway GPU Instances, le bloc deploy.resources.reservations.devices configure automatiquement le passthrough GPU NVIDIA. Assurez-vous d avoir installe le nvidia-container-toolkit sur l hote avant de lancer le stack.

Etape 3 — Reverse proxy nginx avec authentification Bearer

Le reverse proxy nginx est la piece maitresse de la securisation. Il gere l authentification, le rate limiting, les headers de securite, et le filtrage des requetes. Voici la configuration complete :

# nginx/nginx.conf
worker_processes auto;
error_log /var/log/nginx/error.log warn;

events {
    worker_connections 1024;
}

http {
    # Rate limiting
    limit_req_zone $binary_remote_addr zone=ollama_limit:10m rate=10r/s;
    limit_req_zone $binary_remote_addr zone=ollama_create:10m rate=1r/m;

    # Logs format avec token (masque)
    log_format secure '$remote_addr - [$time_local] "$request" '
                      '$status $body_bytes_sent '
                      '"$http_referer" token=$http_authorization';

    # Taille max des requetes (modeles GGUF = gros fichiers)
    client_max_body_size 50G;

    # Timeouts pour l'inference LLM (reponses longues)
    proxy_read_timeout 600s;
    proxy_send_timeout 600s;

    upstream ollama_backend {
        server ollama:11434;
    }

    server {
        listen 443 ssl http2;
        server_name ollama.votre-domaine.fr;

        # TLS
        ssl_certificate /etc/letsencrypt/live/ollama.votre-domaine.fr/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/ollama.votre-domaine.fr/privkey.pem;
        ssl_protocols TLSv1.3;
        ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256';

        # Headers securite
        add_header X-Frame-Options DENY always;
        add_header X-Content-Type-Options nosniff always;
        add_header X-XSS-Protection "1; mode=block" always;
        add_header Strict-Transport-Security "max-age=63072000" always;

        # Authentification Bearer Token
        set $auth_valid 0;
        if ($http_authorization = "Bearer VOTRE_TOKEN_SECRET_ICI") {
            set $auth_valid 1;
        }
        if ($auth_valid = 0) {
            return 401 '{"error":"unauthorized"}';
        }

        # Endpoint principal - rate limited
        location /api/ {
            limit_req zone=ollama_limit burst=20 nodelay;
            proxy_pass http://ollama_backend;
            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;
        }

        # Bloquer /api/create et /api/push (vecteurs Bleeding Llama)
        location /api/create {
            limit_req zone=ollama_create burst=2 nodelay;
            # Seuls les admins peuvent creer des modeles
            if ($http_x_admin_token != "ADMIN_TOKEN_SECRET") {
                return 403 '{"error":"admin only"}';
            }
            proxy_pass http://ollama_backend;
            proxy_set_header Host $host;
        }

        location /api/push {
            return 403 '{"error":"push disabled in production"}';
        }

        # Health check (sans auth pour le monitoring)
        location /health {
            proxy_pass http://ollama_backend/api/tags;
            access_log off;
        }
    }
}

Cette configuration implemente plusieurs couches de defense. L authentification Bearer bloque tout acces non authentifie. Le rate limiting differencie avec deux zones : 10 requetes par seconde pour l inference normale, et seulement 1 requete par minute pour /api/create (le vecteur d attaque de Bleeding Llama). Le endpoint /api/push est completement bloque en production — il n y a aucune raison legitime de pousser un modele depuis un serveur de production vers un registre externe.

Pour generer un token Bearer securise, utilisez : openssl rand -base64 48. Stockez ce token dans un fichier .env non versionne et injectez-le via les variables d environnement Docker Compose. Ne le codez jamais en dur dans la configuration nginx — utilisez des templates envsubst ou des secrets Docker.

Etape 4 — TLS avec Let's Encrypt et renouvellement automatique

Le chiffrement TLS est indispensable pour proteger les donnees en transit — notamment les prompts et les reponses du modele qui peuvent contenir des informations sensibles. Voici le script d initialisation pour obtenir le premier certificat :

#!/bin/bash
# init-tls.sh — Premier certificat Let's Encrypt

DOMAIN="ollama.votre-domaine.fr"
EMAIL="devops@votre-domaine.fr"

# Creer les repertoires
mkdir -p ./certbot/conf ./certbot/www

# Obtenir le certificat (mode standalone pour la premiere fois)
docker run --rm -p 80:80 \
  -v ./certbot/conf:/etc/letsencrypt \
  -v ./certbot/www:/var/www/certbot \
  certbot/certbot certonly \
  --standalone \
  --preferred-challenges http \
  --email $EMAIL \
  --agree-tos \
  --no-eff-email \
  -d $DOMAIN

echo "Certificat obtenu. Lancez docker compose up -d"
echo "Le renouvellement est gere automatiquement par le service certbot."

Le service certbot dans le docker-compose gere automatiquement le renouvellement toutes les 12 heures. Les certificats Let's Encrypt expirent apres 90 jours, mais le renouvellement automatique se declenche 30 jours avant l expiration. Pour les entreprises francaises qui preferent un provider TLS europeen, Gandi ou OVH SSL offrent des certificats wildcard compatibles avec cette configuration.

Etape 5 — Hardening reseau et firewall

Meme avec un reverse proxy, il est essentiel de configurer le firewall de l hote pour reduire la surface d attaque. Voici la configuration ufw recommandee :

#!/bin/bash
# setup-firewall.sh

# Reset et politique par defaut
sudo ufw --force reset
sudo ufw default deny incoming
sudo ufw default allow outgoing

# SSH (restreignez a votre IP si possible)
sudo ufw allow from VOTRE_IP/32 to any port 22 proto tcp

# HTTPS uniquement (le seul port public)
sudo ufw allow 443/tcp

# Bloquer explicitement le port Ollama depuis l'exterieur
sudo ufw deny 11434/tcp

# Activer
sudo ufw --force enable

# Verifier
sudo ufw status verbose

Attention : Docker modifie les regles iptables independamment de ufw. Pour empecher Docker d exposer accidentellement des ports, ajoutez cette configuration dans /etc/docker/daemon.json :

{
  "iptables": false,
  "ip6tables": false,
  "default-address-pools": [
    {"base": "172.28.0.0/16", "size": 24}
  ]
}

Avec iptables: false, Docker ne cree plus de regles de forwarding automatiques — vous gardez le controle total de ce qui entre et sort. C est plus contraignant (vous devez configurer manuellement le NAT pour les ports exposes), mais c est la seule facon de garantir que votre firewall ufw est veritablement effectif quand Docker est installe sur la machine.

Etape 6 — Monitoring et alertes

Un serveur de production sans monitoring est un serveur dont on ne detectera les problemes qu une fois qu il sera trop tard. Voici une configuration minimale avec Prometheus pour collecter les metriques et des alertes simples :

# monitoring/prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'ollama-health'
    metrics_path: /health
    static_configs:
      - targets: ['nginx:443']
    scheme: https
    tls_config:
      insecure_skip_verify: true

  - job_name: 'nginx-status'
    static_configs:
      - targets: ['nginx:8080']

# Script de health check custom (cron toutes les minutes)
# check-ollama.sh
# #!/bin/bash
# RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" \
#   -H "Authorization: Bearer $OLLAMA_TOKEN" \
#   https://ollama.votre-domaine.fr/api/tags)
# if [ "$RESPONSE" != "200" ]; then
#   # Envoyer alerte (Slack, email, PagerDuty)
#   curl -X POST "$SLACK_WEBHOOK" \
#     -H 'Content-type: application/json' \
#     -d '{"text":"ALERTE: Ollama production DOWN"}'
# fi

Les metriques a surveiller en priorite pour un serveur Ollama en production : le temps de reponse moyen (une augmentation soudaine peut indiquer une saturation GPU), la memoire GPU utilisee (via nvidia-smi), le nombre de requetes par seconde (pour detecter des tentatives de brute force ou de DDoS), et les codes de reponse HTTP (un pic de 401 indique des tentatives d acces non autorises). Configurez des alertes pour chaque seuil critique et testez-les regulierement — une alerte qui ne se declenche jamais est une alerte cassee.

Etape 7 — Sauvegarde des modeles et plan de reprise

Les modeles Ollama prennent du temps a telecharger et a configurer. Un plan de sauvegarde garantit une reprise rapide en cas de panne ou de corruption :

#!/bin/bash
# backup-ollama.sh — A executer quotidiennement via cron

BACKUP_DIR="/backups/ollama"
S3_BUCKET="s3://votre-bucket/ollama-backups"
DATE=$(date +%Y%m%d)

# Sauvegarder la liste des modeles et leurs configurations
docker exec ollama-prod ollama list > "$BACKUP_DIR/models-$DATE.txt"

# Sauvegarder le volume Docker
docker run --rm \
  -v ollama-models:/source:ro \
  -v $BACKUP_DIR:/backup \
  alpine tar czf "/backup/ollama-models-$DATE.tar.gz" -C /source .

# Upload vers Object Storage (S3-compatible: OVH, Scaleway, MinIO)
aws s3 cp "$BACKUP_DIR/ollama-models-$DATE.tar.gz" \
  "$S3_BUCKET/ollama-models-$DATE.tar.gz" \
  --storage-class STANDARD_IA

# Rotation : garder 7 jours de backups locaux
find $BACKUP_DIR -name "*.tar.gz" -mtime +7 -delete

echo "Backup termine : $DATE"

Pour les equipes francaises soucieuses de la souverainete des donnees, privilegiez un Object Storage localise en France : OVH Object Storage (datacenters Gravelines, Strasbourg), Scaleway Object Storage (Paris, Amsterdam), ou un MinIO auto-heberge. Les modeles eux-memes ne contiennent pas de donnees utilisateur, mais les Modelfiles personnalises avec des prompts systeme peuvent inclure des informations confidentielles qui ne doivent pas quitter le territoire europeen.

Le plan de reprise d activite (PRA) complet pour un serveur Ollama en production doit couvrir : la restauration du stack Docker (15 minutes avec les images en cache), le telechargement des modeles depuis le backup (variable selon la taille, compter 30 minutes pour 50 Go), la verification des health checks, et la rotation des tokens d authentification (par precaution en cas d incident de securite). Documentez ce plan et testez-le trimestriellement — un PRA non teste est un PRA qui ne fonctionne pas. Pour aller plus loin sur l automatisation CI/CD de ce type de deploiement, consultez notre guide sur la configuration d un pipeline CI/CD securise.

Cas d usage pour les entreprises francaises

Cette architecture est directement applicable a plusieurs scenarios courants dans les entreprises francaises :

Chatbot interne d entreprise : Deploiez un modele Llama 3.1 70B ou Mistral Large derriere ce stack pour offrir un assistant IA interne sans envoyer de donnees a des services tiers. Le RGPD impose que les donnees personnelles des employes ne quittent pas l infrastructure maitrisee — un Ollama securise heberge chez OVH ou Scaleway en France repond a cette exigence. L authentification Bearer limite l acces aux seuls services internes autorises.

Pipeline RAG pour la documentation technique : Les equipes qui construisent des systemes de question-reponse sur leur base documentaire utilisent Ollama comme backend d inference combine a un vecteur store (Qdrant, Milvus). Le rate limiting protege contre les requetes massives qui pourraient saturer le GPU, et le monitoring permet de suivre la latence pour garantir une experience utilisateur fluide.

Generation de code securisee : Les equipes de developpement qui utilisent des modeles de code (Code Llama, Devstral, StarCoder) via Ollama pour l autocompletion dans leurs IDE beneficient de l isolation reseau. Les prompts contenant du code proprietaire ne transitent jamais par Internet — ils restent confines dans le reseau Docker interne entre l application cliente et le serveur Ollama.

Pour les equipes qui souhaitent aller plus loin dans la securisation de leurs dependances, notre guide sur Dependabot et Renovate pour l audit des dependances couvre l automatisation des mises a jour de securite — y compris pour les images Docker de ce stack.

Commandes de deploiement complet

Voici la sequence complete de commandes pour deployer le stack de zero sur un serveur Ubuntu 22.04+ avec GPU NVIDIA :

# 1. Installer les prerequis
sudo apt update && sudo apt install -y docker.io docker-compose-v2 nvidia-container-toolkit
sudo systemctl restart docker

# 2. Cloner la configuration
git clone https://github.com/votre-org/ollama-production-stack.git
cd ollama-production-stack

# 3. Configurer les secrets
cp .env.example .env
# Editer .env avec vos tokens et domaine
# OLLAMA_AUTH_TOKEN=$(openssl rand -base64 48)
# OLLAMA_ADMIN_TOKEN=$(openssl rand -base64 48)
# DOMAIN=ollama.votre-domaine.fr

# 4. Obtenir le certificat TLS
chmod +x init-tls.sh && ./init-tls.sh

# 5. Lancer le stack
docker compose up -d

# 6. Telecharger les modeles
docker exec ollama-prod ollama pull llama3.1:70b
docker exec ollama-prod ollama pull mistral:7b

# 7. Verifier le deploiement
curl -s -H "Authorization: Bearer $OLLAMA_AUTH_TOKEN" \
  https://ollama.votre-domaine.fr/api/tags | jq .

# 8. Configurer le backup cron
echo "0 3 * * * /opt/ollama-production/backup-ollama.sh" | sudo crontab -

L ensemble du deploiement prend environ 30 minutes sur un serveur vierge (hors temps de telechargement des modeles). Testez systematiquement chaque composant apres le deploiement : verifiez que les requetes sans token sont rejetees (code 401), que le rate limiting fonctionne (code 429 apres depassement), que les endpoints dangereux sont bloques (code 403 sur /api/push), et que le health check repond correctement.

FAQ