Windmill est une plateforme open source pour développeurs qui transforme des scripts en webhooks, workflows, tâches planifiées et interfaces internes - positionnée face à Retool et Temporal, non face à un hébergeur de sites statiques. L’édition communautaire est sous licence AGPL-3.0, l’édition entreprise derrière une clé de licence.
Son dimensionnement diffère de celui d’une application web ordinaire, car l’unité de capacité est le worker, pas l’application.
L’architecture qui détermine vos specs
Le docker-compose.yml officiel démarre sept services :
| Service | Image | Rôle |
|---|---|---|
db | postgres:16 | Base de données et file d’attente |
windmill_server | ghcr.io/windmill-labs/windmill:main | API et interface web, port 8000 |
windmill_worker | même image, MODE=worker | Exécute les tâches |
windmill_worker_native | même image, NATIVE_MODE=true | Tâches légères uniquement |
windmill_indexer | même image, MODE=indexer | Recherche plein texte sur les tâches |
windmill_extra | ghcr.io/windmill-labs/windmill-extra:latest | Serveurs de langage pour l’éditeur |
caddy | ghcr.io/windmill-labs/caddy-l4:2.11.4-1 | Proxy inverse sur le port 80 |
Deux éléments de ce tableau comptent plus que les autres.
Il n’y a pas de Redis. Windmill utilise PostgreSQL comme file d’attente. Bon nombre de guides tiers ajoutent un conteneur Redis et une REDIS_URL ; le fichier Compose officiel ne contient ni l’un ni l’autre, et recopier un tel guide revient à faire tourner un service auquel Windmill ne parle jamais.
Les workers sont le poste de dépense. Le serveur reste relativement inoccupé. Ce que vous payez réellement, c’est de la capacité de worker.
RAM et CPU : dimensionner par worker
La règle pratique est un worker par vCPU, 1 à 2 Go de RAM chacun, plus une marge pour Postgres et le serveur.
| Configuration | vCPU / RAM | Ce que cela vous donne |
|---|---|---|
| Essai, un worker | 2 / 2 Go | Fonctionne, mais une tâche à la fois et aucune marge pour une grosse installation de dépendances |
| Pile par défaut, 1-2 workers | 2-4 / 4 Go | Le minimum praticable en usage réel |
| Plusieurs tâches simultanées | 4 / 8 Go | La cible confortable pour une petite équipe |
Les workers natifs sont l’exception à connaître : ils exécutent les tâches légères avec environ 0,1 CPU et 128 Mo, raison pour laquelle la pile par défaut en embarque un aux côtés d’un worker standard sans réclamer un cœur supplémentaire.
La variable que personne n’anticipe est l’installation des dépendances. Une tâche Python qui tire pandas, ou une tâche TypeScript avec un gros fichier de verrouillage, fait grimper la mémoire bien au-delà du régime permanent. Si des tâches échouent seulement au premier lancement puis passent, vous assistez à la construction du cache de dépendances avec trop peu de RAM.
Stockage : la croissance vient du cache de dépendances
La base reste modeste longtemps - métadonnées de tâches, scripts, flux et journaux sont du texte. Le volume qui grossit est worker_dependency_cache, où sont conservés chaque wheel Python et chaque paquet npm importés par vos tâches, afin que les exécutions suivantes évitent l’installation.
Démarrez à 40 Go. Surveillez le volume de cache plutôt que la base au moment d’envisager un redimensionnement, et privilégiez le NVMe ou le SSD : Postgres assure ici le service de file d’attente en plus du stockage et reste sensible à la latence des entrées-sorties.
Les offres VPS correspondant à ces prérequis
| Hébergeur | Offre | vCPU / RAM / Disque | Prix | Verdict | Lien |
|---|---|---|---|---|---|
| Contabo | Cloud VPS 4 | 4 / 8 Go / 100 Go SSD | 5,50 EUR/mois HT | De quoi loger quatre workers au prix d’une offre d’entrée | Contabo |
| Hetzner Cloud | CX23 | 2 / 4 Go / 40 Go NVMe | 5,49 EUR/mois HT | Convient à la pile par défaut à deux workers | Hetzner |
| DigitalOcean | Basic 4 Go | 2 / 4 Go / 80 Go SSD | 24 USD/mois | Mêmes specs que le CX23, quatre fois le prix | DigitalOcean |
| Vultr | Regular 4 Go | 2 / 4 Go / 80 Go SSD | 20 USD/mois | Le plus large choix de régions | Vultr |
| Linode | Linode 4 Go | 2 / 4 Go / 80 Go SSD | 24 USD/mois | Performances prévisibles, API solide | Linode |
Windmill est l’une des rares applications auto-hébergées pour lesquelles une offre à 1 Go n’est pas disqualifiée d’office : un unique worker natif y tient vraiment. Mais vous ne pouvez pas y héberger un worker standard, ce qui exclut toute tâche Python ou TypeScript avec dépendances. C’est une démonstration, pas un déploiement.
Monter en charge
Windmill s’étend horizontalement en ajoutant des conteneurs worker, pas en grossissant un processus. Pour doubler le débit, ajoutez un second service windmill_worker pointant sur la même DATABASE_URL et donnez un cœur de plus à la machine.
Cela a une conséquence pratique sur le choix du VPS : ici, plus de cœurs valent mieux que des cœurs plus rapides. Les 4 vCPU de Contabo à 5,50 EUR HT achètent la parallélisation de quatre workers, là où le CX23 de Hetzner en achète deux à un prix quasi identique. Si votre charge est faite de nombreuses petites tâches plutôt que de quelques lourdes, ce rapport constitue toute la décision.
- Surveillez avec
docker statsquel worker sature avant de redimensionner. - Regroupez les workers par étiquettes pour que les tâches lourdes atterrissent sur la machine dimensionnée pour elles.
- Postgres porte la file d’attente : donnez-lui du disque rapide avant de lui donner plus de RAM.
Pour un panorama plus large des offres, voyez notre comparatif VPS complet.
Frequently asked questions
De combien de RAM une instance Windmill auto-hébergée a-t-elle besoin ?
Dimensionnez par worker plutôt que 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. Une instance à un seul worker tourne sur 2 Go, la pile Compose par défaut avec deux workers est à l'aise sur 4 Go, et 8 Go avec 4 vCPU constituent la cible raisonnable dès que plusieurs tâches s'exécutent en parallèle.
Combien de cœurs CPU faut-il allouer à Windmill ?
Commencez avec 2 vCPU et ajoutez un cœur par worker supplémentaire, puisqu'un worker standard exécute une seule tâche à la fois. Les workers natifs font exception : ils traitent les tâches légères avec environ 0,1 CPU et 128 Mo, ce qui permet à la pile par défaut d'en embarquer un aux côtés du worker standard sans exiger de cœur en plus.
Windmill nécessite-t-il Redis ou un autre courtier de messages ?
Non. Windmill utilise PostgreSQL à la fois comme base de données et comme file d'attente de tâches. C'est inhabituel et bon à savoir, car de nombreux guides tiers ajoutent un service Redis absent du fichier Compose officiel. PostgreSQL 14 ou plus récent est le seul entrepôt de données requis, et ajouter Redis ne rapporte qu'un conteneur inutile.