Pourquoi self-héberger Windmill sur un VPS
Contrairement aux outils purement no-code, Windmill s'adresse aux équipes qui veulent écrire du vrai code mais sans réinventer l'orchestration, la gestion des secrets, les schedules et les UI. Vous déposez une fonction Python ou TypeScript, Windmill en déduit automatiquement un formulaire d'entrée, l'expose en API et l'ajoute au catalogue. Self-héberger sur un VPS a un intérêt particulier ici : vos scripts touchent souvent à des bases de données internes, des secrets sensibles et des réseaux privés. En gardant Windmill sur votre infrastructure, ces scripts s'exécutent au plus près de vos ressources, sans exposer vos credentials à un tiers. Le moteur est écrit en Rust, donc rapide et léger, et le projet est conçu pour le self-hosting dès le départ.
Bénéfices concrets du self-hosting
- Code natif Python/TypeScript/Go/Bash versionné dans Git, pas de logique enfermée dans une UI propriétaire.
- Gestion des secrets et variables chiffrés, accessibles uniquement depuis votre serveur.
- Génération automatique d'UI et d'API à partir de vos fonctions, sans front à écrire.
- Workers scalables : ajoutez des conteneurs worker pour absorber plus de jobs en parallèle.
- Exécution au plus près de vos bases internes, latence minimale et réseau privé respecté.
- Aucune limite d'exécutions imposée par un éditeur SaaS.
Prérequis techniques
Windmill repose sur PostgreSQL et un ou plusieurs workers. Pour une instance de production légère, prévoyez 2 vCPU et 4 Go de RAM ; le moteur Rust est sobre, mais chaque worker exécute du code utilisateur et peut consommer ponctuellement de la mémoire selon vos scripts. Comptez 4 vCPU / 8 Go si vous prévoyez plusieurs workers et des jobs Python lourds (data, pandas). Disque : 20 à 40 Go selon le cache des dépendances. Il vous faut Docker et Docker Compose, un domaine (windmill.votredomaine.ma), et les ports 80/443 ouverts. PostgreSQL est inclus dans le compose officiel.
Déployer Windmill avec Docker Compose
Initialiser le serveur
Sur le VPS, installez Docker (curl -fsSL https://get.docker.com | sh), créez /opt/windmill et placez-vous dedans. Vérifiez la mémoire disponible avec free -h avant de continuer.
Télécharger le compose et le .env
Récupérez le fichier de référence : curl -O https://raw.githubusercontent.com/windmill-labs/windmill/main/docker-compose.yml et le .env associé. Le compose définit le serveur, les workers et PostgreSQL.
Configurer base et URL de base
Dans le .env, fixez DATABASE_URL avec un mot de passe fort et BASE_URL=https://windmill.votredomaine.ma. Ajustez NUM_WORKERS selon vos vCPU (commencez à 2). Laissez le worker native pour les jobs légers.
Démarrer la stack
Lancez docker compose up -d. Windmill applique automatiquement ses migrations PostgreSQL au premier démarrage. Surveillez avec docker compose logs -f windmill_server jusqu'à l'apparition du message d'écoute.
Reverse proxy et HTTPS
Le compose inclut souvent un service Caddy. Sinon, ajoutez votre propre Caddy : windmill.votredomaine.ma { reverse_proxy windmill_server:8000 }. Caddy gère le certificat Let's Encrypt sans configuration supplémentaire.
Premier login et test de script
Connectez-vous avec les identifiants par défaut (admin@windmill.dev / changeme), changez immédiatement le mot de passe, créez un workspace, puis écrivez un script Python def main(name: str): return f'Hello {name}' pour vérifier l'auto-génération d'UI et l'exécution sur un worker.
Pour les scripts Python lourds, créez des workers dédiés à un tag (worker_tags=gpu ou heavy) et routez les jobs gourmands vers ces workers via le champ tag du script. Vous évitez ainsi qu'un job pandas n'occupe tous les workers et ne bloque les automatisations rapides. Windmill met aussi en cache les dépendances pip/npm dans un volume : montez-le sur un disque rapide pour accélérer drastiquement les premiers démarrages de jobs.
