Installer Sablier sur un VPS Linux avec Docker : démarrer ses conteneurs à la demande

Sablier : demarrer ses conteneurs Docker a la demande sur un serveur VPS

Sur un serveur VPS Linux, chaque conteneur Docker qui tourne en permanence consomme de la RAM et du CPU, meme sans utilisateur connecte. Un conteneur Nextcloud inactif, une instance Ollama en attente, un serveur web de test, un panel d'administration visite une fois par jour, une base de donnees MySQL reservee au developpement : autant de ressources monopolisees sur votre serveur virtuel qui pourraient servir aux services critiques.

Sablier est un outil open source qui resout ce probleme. Il s'intercale entre votre reverse proxy (Traefik, Nginx, Caddy) et vos conteneurs Docker. Quand un utilisateur accede a un service arrete, Sablier le demarre automatiquement et affiche une page d'attente pendant le chargement. Apres une periode d'inactivite configurable, il arrete le conteneur pour liberer les ressources du VPS Linux. L'ensemble se pilote en ligne de commande, sans interface graphique : c'est un binaire Go leger qui surveille l'etat des conteneurs via le socket Docker.

Le projet, maintenu depuis quatre ans sur GitHub (sablierapp/sablier), en est a la version 1.19.1 sortie le 28 octobre 2026. Il supporte Docker, Docker Swarm, Podman, Kubernetes, Proxmox LXC, SystemD, AWS ECS et Nomad comme fournisseurs, et s'integre avec Traefik, Nginx, Caddy, Envoy, Istio et Apache APISIX cote reverse proxy.

Ce guide couvre l'installation de Sablier avec Docker Compose sur un VPS Linux, l'integration avec Traefik et Nginx, la configuration des timeouts par service, et un cas concret : n'allumer Ollama, Nextcloud ou vos bases de donnees que quand on en a besoin.

Pourquoi utiliser Sablier sur un serveur VPS ou dedie

Un serveur VPS repose sur la virtualisation : votre machine virtuelle partage les ressources physiques (CPU, RAM, bande passante) de l'hyperviseur avec d'autres serveurs virtuels. Contrairement a un serveur dedie ou l'integralite du materiel vous est reservee, un VPS dispose d'une enveloppe fixe de memoire et de puissance de calcul. Chaque service inutile qui tourne en permanence greve directement la memoire disponible pour vos services actifs.

Sur un serveur dedie avec 64 Go de RAM, laisser tourner un conteneur Ollama de 1,5 Go au repos est un detail. Sur un serveur VPS a 4 Go, c'est plus d'un tiers de la memoire totale de la machine virtuelle. Sablier permet d'heberger davantage de services sur le meme serveur virtuel en ne demarrant chacun que lorsqu'un utilisateur y accede reellement. L'administrateur configure un delai d'inactivite par service : a l'expiration, le conteneur s'arrete et la RAM est restituee au systeme.

L'interet va au-dela de la seule RAM. Un conteneur arrete ne consomme ni cycles CPU, ni bande passante reseau, ni operations d'entree-sortie sur le disque. Sur un VPS facture aux ressources, c'est autant d'economise. Meme sur un serveur dedie, reduire le nombre de processus actifs limite la surface d'attaque : un service eteint ne peut pas etre exploite par un attaquant qui scanne votre adresse IP.

Prerequis

• Un serveur VPS Linux sous Ubuntu 22.04/24.04 LTS ou Debian 12 (les distributions Linux les plus courantes chez les hebergeurs VPS) ;
• Au moins 2 Go de RAM sur la machine virtuelle ;
• Docker et Docker Compose installes (guide d'installation Docker sur VPS) ;
• Un acces SSH avec un utilisateur disposant des droits sudo pour executer les commandes d'administration en ligne de commande ;
• Un reverse proxy en place : Traefik v3 ou Nginx (configurer Nginx en reverse proxy) ;
• Un nom de domaine ou sous-domaine avec un enregistrement DNS de type A pointant vers l'adresse IP publique de votre serveur VPS ;
• Un certificat TLS valide (publier un service en HTTPS sur VPS Linux) ;
• Les ports 80 et 443 ouverts dans le firewall du serveur (UFW ou nftables).

Comment Sablier fonctionne

Sablier agit comme un middleware entre le reverse proxy (serveur web frontal) et les conteneurs Docker de votre serveur VPS. Le mecanisme repose sur trois etapes :

1. Requete entrante : un utilisateur accede a l'URL d'un service (par exemple nextcloud.mondomaine.fr). Le serveur web (Traefik ou Nginx) transmet la requete au middleware Sablier.
2. Demarrage a la demande : si le conteneur cible est arrete, Sablier envoie une commande docker start et affiche une page d'attente au visiteur. Quand le healthcheck du conteneur passe, Sablier redirige la requete vers le service.
3. Arret apres inactivite : une session demarre a chaque requete. A l'expiration du delai configure (par defaut 5 minutes), Sablier arrete ou met en pause le conteneur pour liberer la RAM et le CPU du serveur virtuel.

Deux strategies d'attente existent. La strategie dynamic affiche une page HTML personnalisable avec un compteur pendant le demarrage du conteneur. La strategie blocking maintient la connexion HTTP ouverte jusqu'a ce que le conteneur soit pret, sans page intermediaire. La strategie dynamic convient aux sites web et applications accessibles via un navigateur. La strategie blocking convient aux appels API et aux scripts d'automatisation.

Sablier offre aussi deux modes d'arret. Le mode stop (par defaut) arrete completement le conteneur et libere toute la memoire. Le mode pause gele les processus du conteneur sans liberer la RAM, ce qui permet un redemarrage quasi instantane. Le choix depend du compromis entre economie de ressources et vitesse de reprise.

Installer Sablier avec Docker Compose

Creez un repertoire de travail pour Sablier et le fichier de configuration Docker Compose :

mkdir -p ~/sablier && cd ~/sablier
nano docker-compose.yml

Contenu du fichier Docker Compose pour deployer Sablier avec le fournisseur Docker :

services:
  sablier:
    image: sablierapp/sablier:1.19.1
    container_name: sablier
    command:
      - start
      - --provider.name=docker
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - "127.0.0.1:10000:10000"
    restart: unless-stopped

Sablier ecoute sur le port 10000. En le liant a 127.0.0.1, seuls les services locaux (le reverse proxy) peuvent y acceder : aucun port supplementaire a ouvrir dans le firewall. Lancez le conteneur :

docker compose up -d
docker compose logs -f sablier

Les logs doivent afficher Sablier started et la connexion au socket Docker. Si vous obtenez une erreur de permission sur /var/run/docker.sock, ajoutez votre utilisateur au groupe docker avec sudo usermod -aG docker $USER puis reconnectez-vous en SSH. Sur certaines distributions Linux, verifiez aussi les permissions du socket avec sudo ls -la /var/run/docker.sock.

Configurer les labels Docker sur vos conteneurs

Pour qu'un conteneur soit gere par Sablier, ajoutez deux labels Docker dans son fichier docker-compose.yml. Voici un exemple avec un conteneur Nextcloud :

services:
  nextcloud:
    image: nextcloud:30
    labels:
      - "sablier.enable=true"
      - "sablier.group=nextcloud"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:80"]
      interval: 10s
      timeout: 5s
      retries: 3
    # ... reste de la configuration

Le label sablier.enable=true active la gestion par Sablier. Le label sablier.group definit un groupe : tous les conteneurs d'un meme groupe demarrent et s'arretent ensemble. C'est indispensable pour les applications composees de plusieurs conteneurs (par exemple un serveur web et sa base de donnees MySQL). Un healthcheck est obligatoire : sans lui, Sablier ne peut pas distinguer un conteneur demarre d'un conteneur pret a recevoir des requetes.

Sablier propose aussi des labels avances pour un controle plus fin :

• sablier.running-hours=08:00-20:00 : maintient le conteneur actif pendant une plage horaire definie, pratique pour les sites web professionnels ;
• sablier.running-days=Mon,Tue,Wed,Thu,Fri : limite les plages horaires aux jours ouvrables ;
• sablier.idle.cpu=0.1 et sablier.idle.memory=64m : en mode scale, reduit les ressources allouees au conteneur au repos au lieu de l'arreter completement.

Integration avec Traefik

Sablier fournit un plugin natif pour Traefik v3. Ajoutez le plugin dans la configuration statique de Traefik :

# traefik.yml (extrait)
experimental:
  localPlugins:
    sablier:
      moduleName: github.com/sablierapp/sablier-traefik-plugin

Puis configurez le middleware Sablier sur le service cible via des labels Docker. Voici un exemple complet pour un conteneur Nextcloud gere par Sablier derriere Traefik :

services:
  nextcloud:
    image: nextcloud:30
    labels:
      - "sablier.enable=true"
      - "sablier.group=nextcloud"
      - "traefik.enable=true"
      - "traefik.docker.allownonrunning=true"
      - "traefik.http.routers.nextcloud.rule=Host(`nextcloud.mondomaine.fr`)"
      - "traefik.http.routers.nextcloud.entrypoints=websecure"
      - "traefik.http.routers.nextcloud.tls.certresolver=letsencrypt"
      - "traefik.http.routers.nextcloud.middlewares=nextcloud-sablier"
      - "traefik.http.middlewares.nextcloud-sablier.plugin.sablier.sablierUrl=http://sablier:10000"
      - "traefik.http.middlewares.nextcloud-sablier.plugin.sablier.group=nextcloud"
      - "traefik.http.middlewares.nextcloud-sablier.plugin.sablier.sessionDuration=10m"
      - "traefik.http.middlewares.nextcloud-sablier.plugin.sablier.dynamic.displayName=Nextcloud"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:80"]
      interval: 10s
      timeout: 5s
      retries: 3

Le label traefik.docker.allownonrunning=true est essentiel : il autorise Traefik a router vers des conteneurs qui ne sont pas en cours d'execution. Sans ce label, Traefik ignore les conteneurs arretes et la requete n'atteint jamais Sablier. Le parametre sessionDuration=10m fixe la duree d'inactivite avant arret a 10 minutes.

Integration avec Nginx

Pour Nginx, Sablier fonctionne via un plugin Proxy-WASM. L'approche la plus simple sur un serveur VPS est d'utiliser l'API HTTP de Sablier directement dans la configuration du serveur web Nginx, sans package supplementaire. Ajoutez un bloc location qui interroge Sablier avant de transmettre la requete :

# /etc/nginx/sites-available/nextcloud.conf
upstream nextcloud_backend {
    server 127.0.0.1:8080;
}

server {
    listen 443 ssl;
    server_name nextcloud.mondomaine.fr;

    # ... configuration TLS

    location / {
        # Demander a Sablier de demarrer le groupe
        set $sablier_url "http://127.0.0.1:10000/api/strategies/dynamic?names=nextcloud&session_duration=10m";

        proxy_pass http://nextcloud_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

L'API de Sablier expose aussi un endpoint /api/strategies/blocking pour les appels API et les scripts qui ne tolerent pas de page d'attente. Pour une integration native avec le module WASM, consultez le depot sablierapp/sablier-proxywasm-plugin sur GitHub.

Quels services demarrer a la demande

Tous les conteneurs Docker ne beneficient pas de la meme facon d'un demarrage a la demande. Voici les categories de services les plus adaptees a cette approche sur un serveur VPS ou dedie :

En regle generale, ne placez pas derriere Sablier les services qui doivent traiter des requetes en continu : reverse proxy, base de donnees de production, serveur de jeu public avec des joueurs connectes, collecteur de metriques. Les services a acces intermittent ou reserves a l'administration sont les meilleurs candidats.

Configurer les timeouts par service

Chaque service peut avoir sa propre duree de session. Avec Traefik, le parametre sessionDuration du middleware controle la duree d'inactivite avant arret. Les formats acceptes sont les durees Go : 30s, 5m, 1h, 24h.

Les timeouts se configurent aussi globalement dans le fichier sablier.yml a la racine du projet. La configuration par defaut fixe la session a 5 minutes et le delai de blocage a 1 minute :

# sablier.yml
sessions:
  defaultDuration: 5m
  expirationInterval: 20s
strategy:
  blocking:
    defaultTimeout: 1m

Pour surveiller la consommation de ressources de vos conteneurs et ajuster les timeouts en consequence, utilisez htop ou btop depuis la ligne de commande de votre serveur VPS.

Cas concret : Ollama, Nextcloud et MySQL a la demande

Prenons un serveur VPS Linux avec 4 Go de RAM sous la distribution Ubuntu 24.04. Voici la consommation typique au repos sans Sablier :

Sans Sablier, le total depasse 2,5 Go en permanence sur un serveur VPS a 4 Go. Avec Sablier, seuls le systeme, Traefik et Sablier tournent en continu (~465 Mo). Nextcloud, sa base de donnees MySQL et Ollama ne demarrent que quand un utilisateur y accede, ce qui libere pres de 2 Go de RAM pour d'autres services, pour le cache disque du systeme ou pour optimiser les performances du VPS.

Pour que Nextcloud et sa base MySQL demarrent ensemble, placez-les dans le meme groupe Sablier. Sablier gere automatiquement l'ordre de demarrage grace aux directives depends_on de Docker Compose. Voici le fichier docker-compose.yml complet :

services:
  sablier:
    image: sablierapp/sablier:1.19.1
    container_name: sablier
    command:
      - start
      - --provider.name=docker
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      - traefik

  nextcloud:
    image: nextcloud:30
    depends_on:
      mysql:
        condition: service_healthy
    labels:
      - "sablier.enable=true"
      - "sablier.group=nextcloud"
      - "traefik.enable=true"
      - "traefik.docker.allownonrunning=true"
      - "traefik.http.routers.nextcloud.rule=Host(`nextcloud.mondomaine.fr`)"
      - "traefik.http.routers.nextcloud.middlewares=nextcloud-sablier"
      - "traefik.http.middlewares.nextcloud-sablier.plugin.sablier.sablierUrl=http://sablier:10000"
      - "traefik.http.middlewares.nextcloud-sablier.plugin.sablier.group=nextcloud"
      - "traefik.http.middlewares.nextcloud-sablier.plugin.sablier.sessionDuration=30m"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:80"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 30s
    networks:
      - traefik

  mysql:
    image: mysql:8.4
    labels:
      - "sablier.enable=true"
      - "sablier.group=nextcloud"
    environment:
      MYSQL_ROOT_PASSWORD: motdepasse_securise
      MYSQL_DATABASE: nextcloud
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 5
    volumes:
      - mysql_data:/var/lib/mysql
    networks:
      - traefik

  ollama:
    image: ollama/ollama:latest
    labels:
      - "sablier.enable=true"
      - "sablier.group=ollama"
      - "traefik.enable=true"
      - "traefik.docker.allownonrunning=true"
      - "traefik.http.routers.ollama.rule=Host(`ollama.mondomaine.fr`)"
      - "traefik.http.routers.ollama.middlewares=ollama-sablier"
      - "traefik.http.middlewares.ollama-sablier.plugin.sablier.sablierUrl=http://sablier:10000"
      - "traefik.http.middlewares.ollama-sablier.plugin.sablier.group=ollama"
      - "traefik.http.middlewares.ollama-sablier.plugin.sablier.sessionDuration=5m"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:11434"]
      interval: 10s
      timeout: 5s
      retries: 5
    volumes:
      - ollama_data:/root/.ollama
    networks:
      - traefik

networks:
  traefik:
    external: true

volumes:
  mysql_data:
  ollama_data:

Arretez les conteneurs geres par Sablier une fois la configuration en place :

docker stop nextcloud mysql ollama

La prochaine requete HTTP vers nextcloud.mondomaine.fr declenchera le demarrage de MySQL puis de Nextcloud via Sablier. Une requete vers ollama.mondomaine.fr demarrera le conteneur Ollama independamment.

Healthchecks : le piege a eviter

Sans healthcheck Docker, Sablier considere le conteneur comme pret des qu'il passe en etat running. Le probleme : un conteneur peut etre running sans que l'application a l'interieur soit prete a recevoir des requetes. Le visiteur recevrait alors une erreur 502 ou une page blanche au lieu du site web attendu.

Chaque conteneur gere par Sablier doit avoir un healthcheck dans son docker-compose.yml. Sablier attend que le statut passe a healthy avant de rediriger le trafic. Pour les services lents au demarrage (Nextcloud, bases de donnees, Ollama), augmentez le nombre de retries et le start_period :

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:80"]
  interval: 10s
  timeout: 5s
  retries: 10
  start_period: 30s

Exemples de healthchecks adaptes par type de service :

• Serveur web (Nginx, Apache) : curl -f http://localhost:80
• Base de donnees MySQL ou MariaDB : mysqladmin ping -h localhost
• Base de donnees PostgreSQL : pg_isready -U postgres
• Ollama : curl -f http://localhost:11434
• Redis : redis-cli ping

Sauvegardes des volumes Docker

Les conteneurs geres par Sablier s'arretent regulierement. Cet arret automatique est une opportunite pour les sauvegardes : un conteneur arrete ne risque pas de corrompre ses fichiers pendant la copie. Les volumes Docker (mysql_data, ollama_data, etc.) contiennent les donnees persistantes de vos services.

Un script de sauvegarde peut copier les volumes lorsque les conteneurs sont a l'arret. Voici un exemple de script bash :

#!/bin/bash
# Script de sauvegarde des volumes Docker geres par Sablier
BACKUP_DIR="/backup/docker-volumes"
DATE=$(date +%Y-%m-%d)

# Sauvegarder le volume MySQL
docker run --rm -v mysql_data:/source -v $BACKUP_DIR:/backup \
  alpine tar czf /backup/mysql-$DATE.tar.gz -C /source .

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

Automatisez ce script avec une tache cron ou un timer systemd. Pour envoyer vos sauvegardes sur un serveur distant, consultez notre guide sauvegarder un VPS avec rsync. Si vos conteneurs utilisent une base de donnees MySQL, pensez a faire un dump logique avec mysqldump en complement de la copie du volume (sauvegardes MySQL avec mysqldump et cron).

Securite et firewall

Sablier apporte un avantage de securite souvent neglige : un conteneur arrete ne presente aucune surface d'attaque. Un serveur web ou une base de donnees qui ne tourne que quelques heures par jour est invisible pour les scripts de scan automatises le reste du temps.

Quelques precautions a prendre lors de la mise en place :

• Socket Docker : Sablier a besoin du socket Docker (/var/run/docker.sock) pour demarrer et arreter les conteneurs. Ce socket donne un acces complet au daemon Docker. Sur un serveur VPS de production, envisagez un proxy de socket (comme docker-socket-proxy) pour limiter les appels API autorises.
• Firewall : le port 10000 de Sablier ne doit jamais etre expose sur l'adresse IP publique du serveur. Verifiez avec sudo ss -tlnp | grep 10000 que le port n'ecoute que sur 127.0.0.1. En cas de doute, securisez votre VPS avec UFW et Fail2ban.
• Reseau Docker : placez Sablier et les conteneurs geres sur un reseau Docker interne. Evitez d'exposer les ports des conteneurs directement sur l'adresse IP publique du serveur VPS.

Maintenance et nettoyage

Les conteneurs geres par Sablier s'arretent et redemarrent regulierement. Avec le temps, les images obsoletes et les volumes orphelins s'accumulent sur le disque du serveur virtuel. Pensez a nettoyer Docker periodiquement pour recuperer de l'espace disque.

Si votre serveur VPS manque de RAM malgre Sablier, verifiez que le swap est correctement configure. Un swap de 2 a 4 Go sur un SSD offre un filet de securite lors du demarrage simultane de plusieurs conteneurs sur la machine virtuelle.

Pour mettre a jour Sablier vers une nouvelle version, modifiez le tag de l'image dans docker-compose.yml et relancez depuis la ligne de commande :

docker compose pull sablier
docker compose up -d sablier

Pensez aussi a mettre a jour les packages systeme de votre distribution Linux avec sudo apt update && sudo apt upgrade pour maintenir la securite du serveur VPS.

Conclusion

Sablier permet d'heberger plus de services sur un meme serveur VPS ou serveur dedie en ne consommant des ressources que quand ils sont reellement utilises. L'installation se fait en quelques minutes avec Docker Compose, et l'integration avec le serveur web Traefik ou Nginx s'effectue via des labels Docker ou l'API HTTP. Pour les administrateurs de serveurs virtuels qui hebergent des services occasionnels (bases de donnees de developpement, Nextcloud, Ollama, panels d'administration, sites web internes, environnements de test), c'est un moyen concret d'optimiser l'utilisation de la RAM et du CPU sans sacrifier la disponibilite.

Les prochaines etapes pour aller plus loin : maitriser les commandes de base du VPS Linux et surveiller les ressources pour ajuster les timeouts de Sablier au fil du temps.