Dagu vs Windmill

Dagu vs Windmill : YAML déclaratif face à une plateforme de scripts et d'apps.

Les deux tournent en self-hosted et sont rapides. Windmill transforme des scripts en workflows, webhooks et apps low-code et utilise PostgreSQL. Dagu est un seul binaire qui exécute vos commandes via du YAML déclaratif, sans base à exploiter.

Un workflow qui appelle vos commandes
name: nightly-ops
schedule: "0 2 * * *"

steps:
  - id: extract
    run: python scripts/extract.py

  - id: transform
    run: ./bin/transform
    retry_policy:
      limit: 3
    depends: [extract]

  - id: notify
    run: ./scripts/slack-success.sh
    depends: [transform]

Un binaire unique, sans PostgreSQL

Les workflows sont du YAML déclaratif sur des commandes existantes

Executors pour shell, Docker, HTTP, SSH, SQL, sous-workflows et agents IA

Exécution locale, par file ou distribuée

Deux façons de définir le travail

Windmill est une plateforme code-first. Vous écrivez des scripts en Python, TypeScript, Go, Bash ou SQL, et elle ajoute à chacun un webhook et une UI générée. Dagu garde le workflow en YAML et traite vos scripts et binaires comme des étapes.

  • Windmill stocke et exécute les scripts dans la plateforme avec des formulaires d'entrée générés.
  • Dagu définit le graphe en YAML versionné et appelle des commandes.
  • Les deux offrent dépendances, retries, planification et historique d'exécution.

Ce qu'il faut pour l'exploiter

Windmill a besoin de PostgreSQL pour l'état et sa file de jobs, et le montage type lance des conteneurs server et worker dessus. Dagu est un binaire unique qui garde l'état dans des fichiers, donc aucune base à provisionner, sauvegarder ou mettre à jour.

  • Dagu démarre comme un processus appuyé sur des fichiers locaux.
  • Ajoutez une file et des workers plus tard sans changer le modèle de workflow.
  • Windmill passe bien à l'échelle mais suppose PostgreSQL présent et géré.

Quand choisir Windmill

Windmill fait plus que de l'orchestration, et cette ampleur est l'intérêt. Si vous voulez héberger des scripts comme des endpoints partageables et bâtir des apps internes et des UI autour, Windmill couvre un terrain où Dagu ne va pas.

  • Vous voulez un constructeur d'apps et d'UI low-code, pas seulement un exécuteur.
  • Vous voulez des formulaires générés, des étapes d'approbation et beaucoup d'intégrations intégrées.
  • Votre équipe préfère écrire la logique comme des scripts gérés plutôt qu'appeler des commandes externes.

Windmill vs. Dagu en bref

Dimension
Dagu
Typical alternative
Écriture
YAML déclaratif qui appelle vos commandes.
Scripts en Python, TypeScript, Go, Bash ou SQL hébergés dans la plateforme.
Runtime
Binaire unique, état sur fichiers, sans base.
Services Rust et workers appuyés sur une file PostgreSQL.
Portée
Orchestration avec étapes shell, Docker, HTTP, SSH, SQL et agents IA.
Workflows plus un constructeur d'apps et d'UI low-code avec approbations.

FAQ

Practical questions before adopting Dagu

Dagu remplace-t-il Windmill ?

Pas entièrement. Dagu remplace la partie orchestration : planification, dépendances, retries, logs et UI des exécutions. Il ne fournit pas le constructeur d'apps low-code de Windmill, ses UI générées ni son large catalogue d'intégrations. Si vous voulez seulement planifier et observer des commandes, Dagu est plus léger.

Dagu a-t-il besoin de PostgreSQL ?

Non. Dagu garde l'état dans des fichiers locaux et tourne comme un binaire unique, donc aucune base à installer ou gérer. Windmill s'appuie sur PostgreSQL pour l'état et sa file de jobs.

Dagu peut-il exécuter des scripts Python et TypeScript ?

Oui. Une étape peut lancer n'importe quelle commande, donc Python, TypeScript, Bash ou un binaire compilé fonctionnent. La différence est que Dagu appelle les scripts sur le disque au lieu de les héberger et de les gérer comme le fait Windmill.

Start with one workflow.

Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.

Install Dagu