Comment héberger soi-même Windmill sur un VPS (Guide complet)

Windmill transforme des scripts en webhooks, workflows, tâches planifiées et interfaces internes - une alternative open source à Retool et Temporal. L’auto-hébergement est simple, avec un piège à connaître avant de commencer : il n’utilise pas Redis, quoi qu’en disent bon nombre de guides sur le web.

Pourquoi héberger soi-même Windmill ?

L’offre cloud facture par utilisateur et par exécution. L’auto-hébergement supprime les deux compteurs, ce qui compte pour une plateforme d’automatisation : les tâches que vous voulez le plus faire tourner régulièrement sont précisément celles qui accumuleraient des frais d’exécution. Cela garde aussi vos scripts, vos identifiants et vos journaux de tâches sur votre propre machine - et ces scripts détiennent couramment des clés d’API pour tout le reste de votre infrastructure.

L’édition communautaire est sous AGPL-3.0. L’édition entreprise se trouve derrière une clé de licence et une autre étiquette d’image ; elle n’est pas nécessaire pour exploiter la plateforme.

Choisir le bon VPS

Windmill se dimensionne par worker, pas par application. La règle empirique est d’un worker par vCPU avec 1 à 2 Go de RAM chacun, en plus de Postgres et du processus serveur.

Comme le débit suit le nombre de workers, le nombre de cœurs pèse ici plus que la fréquence. Pour une comparaison détaillée, consultez notre page comparatif VPS complet.

Prérequis

• Un VPS sous Ubuntu 24.04 LTS avec au moins 2 vCPU et 4 Go de RAM
• Docker Engine et Compose v2
• Un domaine pointant vers le serveur si vous voulez du TLS

Étape 1 : préparer le VPS

Connectez-vous et mettez à jour :

ssh root@votre-ip-vps
apt update && apt upgrade -y

Installez Docker et le greffon Compose :

apt install -y docker.io docker-compose-v2
systemctl enable --now docker
docker compose version

Ouvrez les ports qu’utilisera Caddy :

ufw allow OpenSSH && ufw allow 80 && ufw allow 443
ufw enable

Étape 2 : récupérer la pile Compose officielle

N’écrivez pas votre propre fichier Compose pour Windmill. Le projet en publie un, et il câble correctement les workers, l’indexeur et les serveurs de langage :

mkdir -p ~/windmill && cd ~/windmill
curl -fsSL -o docker-compose.yml https://raw.githubusercontent.com/windmill-labs/windmill/main/docker-compose.yml
curl -fsSL -o .env https://raw.githubusercontent.com/windmill-labs/windmill/main/.env
curl -fsSL -o Caddyfile https://raw.githubusercontent.com/windmill-labs/windmill/main/Caddyfile

La pile que vous venez de télécharger fait tourner sept services :

• db - postgres:16, la base de données et la file d’attente
• windmill_server - l’API et l’interface web sur le port 8000
• windmill_worker - exécute les tâches
• windmill_worker_native - tâches légères, environ 0,1 CPU et 128 Mo
• windmill_indexer - recherche plein texte dans l’historique des tâches
• windmill_extra - serveurs de langage qui animent l’éditeur dans le navigateur
• caddy - proxy inverse sur le port 80

Il n’y a pas de Redis dans cette liste, et il ne devrait pas y en avoir dans la vôtre.

Étape 3 : définir mot de passe et domaine

Le fichier .env fourni contient une valeur par défaut délibérément faible :

DATABASE_URL=postgres://postgres:changeme@db/windmill?sslmode=disable
WM_IMAGE=ghcr.io/windmill-labs/windmill:main

Remplacez changeme par un secret généré avant le premier démarrage, car la base est créée à ce démarrage précis :

openssl rand -hex 24

Définissez BASE_URL sur votre domaine dans le même fichier. Caddy le lit pour demander un certificat.

Étape 4 : démarrer

docker compose up -d
docker compose ps

Le premier démarrage télécharge plusieurs images et applique les migrations de base, laissez-lui une minute. Ouvrez votre domaine et créez le premier compte : il devient le superadministrateur de l’instance.

Étape 5 : ajouter des workers au besoin

C’est ce qui distingue Windmill de la plupart des applications auto-hébergées. Vous ne montez pas en charge en grossissant un processus, mais en ajoutant des conteneurs worker. Copiez le bloc windmill_worker du docker-compose.yml, donnez-lui un nouveau nom de service, conservez la même DATABASE_URL et MODE=worker, puis appliquez :

docker compose up -d

Les workers se coordonnent via Postgres, aucune autre configuration ne change. Comptez environ un vCPU et 1 à 2 Go de RAM pour chacun.

Étape 6 : sauvegarder la base

Tout ce qui compte - scripts, flux, planifications, ressources, historique des tâches - vit dans Postgres. Le volume de cache des dépendances contient des données dérivées et se reconstruit tout seul.

docker compose exec db pg_dump -U postgres windmill | gzip > windmill-$(date +%F).sql.gz

Copiez-le hors du serveur. Notez que Windmill stocke les identifiants de vos autres systèmes : traitez ce dump comme un secret et chiffrez-le au repos.

Là où les gens se font piéger

Recopier depuis un blog un fichier Compose fondé sur Redis. Windmill n’en a jamais eu besoin. Le conteneur démarrera et restera simplement inactif pendant que vous vous demandez pourquoi la file d’attente ne l’utilise pas.

Dimensionner sur le régime permanent. L’installation des dépendances est le pic de mémoire. Une tâche Python important pandas réclame bien plus de RAM au premier lancement qu’aux suivants : une pile qui semble saine au repos peut échouer sur une tâche à froid.

Laisser changeme en place. C’est le mot de passe Postgres du .env publié, et la première chose qu’essaie un balayage opportuniste si vous exposez un jour le port 5432.

Windmill récompense une machine dotée de plus de cœurs plutôt que de cœurs plus rapides, ce qui rend les offres européennes multicœurs bon marché particulièrement intéressantes ici. Dimensionnez selon le nombre de tâches que vous voulez voir tourner ensemble, gardez le dump Postgres chiffré ailleurs, et le service se fera oublier.

Pour d’autres projets et conseils d’auto-hébergement, parcourez la liste awesome-selfhosted ou la communauté r/selfhosted.