Auto-héberger Windmill en 2026 : workers, PostgreSQL, isolation et mises à niveau sûres
Un article de suivi actuel et orienté production, qui traduit la documentation des éditeurs en contrôles opérationnels, décisions de migration et critères de mise en service vérifiables.
Ce qui a changé en 2026
Nous revenons sur ce sujet parce que les limites opérationnelles ont évolué. Les principes durables restent pertinents, mais les versions actuelles rendent certains anciens raccourcis incomplets ou risqués. Ce suivi part de la documentation des éditeurs disponible au 14 juillet 2026, distingue les faits des choix locaux et traite chaque modification de configuration comme une intervention contrôlée en production.
Sources primaires actuelles
Comment exploiter cette mise à jour
Nous commençons par les sources primaires, consignons les versions réellement déployées et définissons le résultat observable avant toute modification. La plus petite intervention réversible est testée dans un environnement représentatif. Une commande réussie ne constitue pas un critère de validation : l’état du service, l’intégrité des données, la latence, les frontières de sécurité et le délai de retour arrière le sont. La séquence de diagnostic encore valable de l’ancien article est conservée ci-dessous comme socle opérationnel ; chaque exemple dépendant d’une version doit être vérifié dans la documentation actuelle.
Avant la mise en service, nous conservons le diff de configuration, une sauvegarde dont la restauration a déjà été testée et les commandes nécessaires au retour arrière. Une personne observe la première fenêtre de production et une autre autorise l’escalade si les indicateurs évoluent dans le mauvais sens. Les alertes doivent décrire le risque visible pour l’utilisateur, pas seulement le composant qui les émet. Pendant la période de contrôle, nous comparons les taux d’erreur, la profondeur des files, la saturation des ressources, la latence de traitement et l’exhaustivité des données à la référence convenue. Moyennes et valeurs extrêmes sont examinées, car une moyenne stable peut masquer des échecs touchant une part réduite mais importante des opérations. Le changement n’est clos qu’après l’achèvement des tâches différées, reprises, planifications et exportations en aval. Toute intervention manuelle de récupération est documentée : si elle manque au runbook, celui-ci reste incomplet.
- La décision d'auto-hébergement : quand le SaaS coûte plus cher que votre propre infrastructure
- Reprise après sinistre pour les services auto-hébergés : notre stratégie de sauvegarde
- Héberger plusieurs instances de base de données sur un seul serveur
Socle opérationnel
Les plateformes d'automatisation de workflows sont essentielles pour les équipes de développement modernes, mais les solutions cloud comme Windmill Cloud peuvent devenir coûteuses à mesure que l'utilisation augmente. Nous vous montrons comment configurer votre propre instance Windmill sur Ubuntu avec Docker Compose et l'intégration Traefik, en surmontant les problèmes critiques d'authentification PostgreSQL qui peuvent faire échouer votre installation.
Ce que vous allez construire
À la fin de ce tutoriel, vous disposerez de :
- Une installation Windmill entièrement fonctionnelle avec HTTPS
- Certificats SSL automatiques via Let's Encrypt à travers Traefik
- Base de données PostgreSQL prête pour la production avec authentification correcte
- Configuration de workers optimisée en ressources
- Intégration avec l'infrastructure Docker existante
- Configuration prête pour la production pour l'automatisation professionnelle des workflows
Coût mensuel : 4,51 € (serveur CX11) + coûts de domaine – la même infrastructure peut gérer plusieurs outils d'automatisation
Prérequis
- Serveur Ubuntu 24.04 LTS avec Docker et Docker Compose installés
- Configuration existante du proxy inverse Traefik (voir notre guide de configuration n8n pour la configuration Traefik)
- Nom de domaine pointant vers l'IP de votre serveur
- Au moins 4 Go de RAM et 2 vCPU recommandés
- Accès SSH et connaissances de base en ligne de commande
Comprendre Windmill
Windmill est un moteur de workflows open source qui fournit :
- Éditeur visuel de workflows avec support TypeScript/Python/Go
- Planification de tâches et gestion de l'exécution
- Capacités d'intégration API
- Fonctionnalités de collaboration d'équipe
- Auto-hébergeable sans limites d'utilisation
Contrairement à l'approche par nœuds de n8n, Windmill se concentre sur les workflows orientés code avec un puissant environnement de développement.
Étape 1 : Préparation du serveur et structure des répertoires
Tout d'abord, préparons notre environnement serveur. Nous utiliserons une convention de nommage basée sur la nourriture pour les instances Windmill afin d'éviter les conflits :
Convention de nommage : Utilisez des noms de plats simples pour les instances Windmill multiples :
- Première instance : pizza
- Instances supplémentaires : pasta, salad, soup, burger, etc.
- Cela évite les conflits et facilite la gestion
Étape 2 : Configuration de l'environnement
Créez un fichier d'environnement sécurisé avec des identifiants adéquats :
cat > /opt/windmill-pizza/docker-compose.yml Important : Mettez à jour le domaine dans les labels Traefik pour correspondre à votre configuration !
Étape 4 : Le problème des mots de passe PostgreSQL (problème critique)
C'est ici que la plupart des installations Windmill échouent, et il a fallu un dépannage considérable pour identifier la cause profonde :
Le problème : les caractères spéciaux dans les mots de passe
Lors de l'utilisation de openssl rand -base64 32 pour générer des mots de passe, vous obtenez souvent des caractères spéciaux comme =, @, #, %, etc. Ces caractères causent des échecs d'authentification PostgreSQL dans les environnements Docker, même lorsqu'ils sont correctement échappés.
Exemple de mot de passe problématique :
La solution : des mots de passe hexadécimaux uniquement
Utilisez des mots de passe hexadécimaux qui ne contiennent aucun caractère spécial :
Problèmes de configuration PostgreSQL supplémentaires
- Configuration utilisateur : Utilisez postgres comme utilisateur par défaut, pas des utilisateurs personnalisés comme windmill_user
- Persistance des volumes : PostgreSQL ignore les variables d'environnement POSTGRES_PASSWORD lorsque les volumes de données existants contiennent des identifiants différents
- Format d'URL : Incluez ?sslmode=disable dans l'URL de la base de données pour les environnements Docker
Étape 5 : Installation et démarrage
Installons maintenant Windmill avec notre configuration corrigée :
Vous devriez voir une sortie comme :
Étape 6 : Résolution des problèmes courants
Problème 1 : Échecs d'authentification PostgreSQL
Symptômes :
Solution :
Problème 2 : Le conteneur ne démarre pas
Symptômes :
- Le conteneur se ferme immédiatement
- Erreurs d'allocation de ressources
Solution :
Problème 3 : Problèmes de certificat SSL
Symptômes :
- HTTPS ne fonctionne pas
- Erreurs de certificat
Solution :
Étape 7 : Accès et configuration initiale
Une fois l'installation terminée :
- Accédez à Windmill : https://windmill.yourdomain.com
- Identifiants par défaut :
Email : [email protected]
- Mot de passe : changeme
- Complétez la configuration :
Changez le mot de passe administrateur
- Configurez l'URL de base
- Créez les comptes utilisateurs
Étape 8 : Optimisation des ressources
Allocation mémoire (pour un serveur de 8 Go)
Notre configuration alloue les ressources efficacement :
- Serveur Windmill : ~800 Mo
- Worker Windmill : 2 Go (limité)
- PostgreSQL : ~500 Mo
- Réserve système : ~4,7 Go
Allocation CPU (pour un serveur 4 vCPU)
- Worker : 1 vCPU (limité)
- Autres services : 3 vCPU (partagés)
Règle de dimensionnement : 1 worker par vCPU avec 1-2 Go de RAM chacun
Étape 9 : Renforcement pour la production
Créer un script de sauvegarde
Configurer la surveillance
Configurer les mises à jour automatisées
# Container status docker compose ps | grep -E "(healthy|Up)"
# Network connectivity docker network inspect proxy
# Database connection docker compose exec windmill-db psql -U postgres -d windmill_pizza -c "SELECT version();"
# Log analysis docker compose logs --tail 50 windmill-server | grep -E "(ERROR|WARN)"
# Update containers cd /opt/windmill-pizza ./update.sh
# Clean old data docker system prune -f
# Backup database ./backup.sh
# Container health docker compose ps | grep -E "(healthy|Up)"
# Network connectivity docker network inspect proxy
# Database connection docker compose exec windmill-db psql -U postgres -d windmill_pizza -c "SELECT version();"
# Log analysis docker compose logs --tail 50 windmill-server | grep -E "(ERROR|WARN)"
# Add additional workers windmill-worker-2: image: ${WM_IMAGE} container_name: windmill-pizza-worker-2 environment:
- DATABASE_URL=${DATABASE_URL}
- MODE=worker
- WORKER_GROUP=heavy
deploy: resources: limits: cpus: '2' memory: 4G
Évolutivité verticale
Augmentez les ressources du serveur :
- CX31 (8 Go de RAM) : 16,07 €/mois pour les charges de travail lourdes
- CX41 (16 Go de RAM) : 29,75 €/mois pour un usage entreprise
Intégration avec l'infrastructure existante
Travail avec n8n
Si vous utilisez déjà n8n (de nos tutoriels précédents) :
- Windmill gère les workflows orientés code
- n8n gère les automatisations visuelles et simples
- Les deux partagent le même proxy Traefik
- Des bases de données séparées évitent les conflits
Services partagés
Exploitez l'infrastructure existante :
- Traefik : Gère le SSL pour tous les services
- Serveur de messagerie : SMTP partagé pour les notifications
- Surveillance : Journalisation et métriques unifiées
- Sauvegardes : Stratégie de sauvegarde centralisée
Conclusion
L'auto-hébergement de Windmill fournit une automatisation des workflows de niveau entreprise à une fraction des coûts d'hébergement cloud. La clé du succès est de comprendre les exigences d'authentification PostgreSQL et d'utiliser des mots de passe hexadécimaux uniquement pour éviter les problèmes de caractères spéciaux qui peuvent faire échouer les installations.
Principaux avantages de cette configuration
- Rentable : Économisez des centaines de dollars par an par rapport aux solutions cloud
- Prêt pour la production : Gère de manière fiable les charges de travail entreprise
- Sécurisé : HTTPS, réseaux isolés et limites de ressources
- Évolutif : Facile d'ajouter des workers et des ressources selon les besoins
- Privé : Votre code et vos données ne quittent jamais votre infrastructure
Cette configuration a été testée dans des environnements de production et offre la fiabilité nécessaire pour l'automatisation de workflows critiques. Les étapes de dépannage répondent aux problèmes rencontrés en conditions réelles lors du déploiement, en particulier les problèmes d'authentification PostgreSQL qui affectent de nombreuses installations auto-hébergées.
Pour des exigences de workflows complexes ou des déploiements d'entreprise, envisagez une consultation professionnelle pour optimiser votre cas d'utilisation spécifique et garantir une allocation optimale des ressources.
Prochaines étapes
- Explorez les techniques de dépannage des webhooks applicables à Windmill
- Consultez l'optimisation des charges utiles pour la gestion de grands ensembles de données
- Envisagez l'intégration avec les installations n8n existantes
À propos de tva
tva assure la gestion complète de l'infrastructure des systèmes de bases de données, des environnements cloud et des chaînes d'approvisionnement mondiales. Notre approche méthodique combine des protocoles de sécurité rigoureux avec l'optimisation des performances, tandis que nos services de conseil stratégique permettent une coordination précise des capacités numériques et des actifs physiques – maintenant les plus hauts standards d'excellence opérationnelle et de conformité dans tous nos engagements.
Visitez tva.sg pour plus d'informations sur nos services et nos tutoriels d'automatisation supplémentaires.
De la configuration à la décision opérationnelle
La vraie question n’est pas de savoir si une plateforme peut être configurée. L’équipe doit pouvoir attribuer les responsabilités, détecter les dérives, restaurer le service sans improviser et démontrer l’effet recherché. Nous associons donc chaque changement à un responsable, une référence initiale, une procédure de retour arrière et une fenêtre de contrôle. Une correction ponctuelle devient ainsi une capacité opérationnelle durable. Ce même dossier offre au prochain responsable un point de départ fiable et transforme l’optimisation ultérieure en décision mesurée plutôt qu’en nouvelle série d’hypothèses.