Dagu vs Kestra

Dagu vs Kestra: same YAML idea, very different footprint.

Dagu and Kestra both describe workflows declaratively in YAML, so the real choice is about runtime and dependencies. Dagu is one self-contained binary that calls commands you already have. Kestra runs on the JVM with a database behind it and a large plugin catalog on top.

A workflow that calls commands you already have
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]

Single binary with no JVM to run

No external database or broker to operate

Executors for shell, Docker, HTTP, SSH, SQL, sub-workflows, and Agent Harness steps

Runs local, queue-based, or distributed

At a glance

Dagu vs Kestra at a glance

Runtime
Dagu

Single Go binary, no JVM.

Kestra

Java application on the JVM.

Dependencies
Dagu

Local files, no external database or broker.

Kestra

Database for the core; Kafka and Elasticsearch for scale.

Extending steps
Dagu

Call commands directly with built-in executors.

Kestra

Large plugin catalog with 1400+ plugins.

In depth

Where each tool fits

01

What the two tools share

Both Dagu and Kestra are declarative. You write a workflow in YAML, version it in git, and run it on your own infrastructure. The difference shows up in what has to run underneath each one.

  • Declarative YAML workflows you can review in pull requests
  • A web UI for runs, logs, and history
  • Self-hosted, so your data stays in your environment
02

Where Dagu is lighter to operate

Dagu ships as one binary written in Go and keeps its state in local files. There is no JVM to tune and no separate datastore to keep healthy. Kestra runs on Java and needs a database for its core, and high-availability setups add components such as Kafka and Elasticsearch.

  • One binary backed by files, with no JVM and no external database
  • Each step runs the command, container, or script it already uses
  • Start on a single host and move to queue-based or distributed workers later
03

When to choose Kestra instead

Kestra is a strong fit when you want a broad plugin catalog and a UI-driven editing experience at scale. Its plugin ecosystem and the company behind it are larger than Dagu's, and that matters for some teams.

  • You want a large catalog of ready-made plugins instead of calling commands directly
  • You prefer building and editing flows from a UI editor backed by an API
  • You are planning a high-availability platform and are fine running Kafka and Elasticsearch

FAQ

Practical questions before adopting Dagu

Does Dagu replace Kestra?

For many teams, yes. If your workflows run as commands, containers, HTTP calls, SSH tasks, or SQL, Dagu covers them with a much smaller footprint. If you rely on Kestra's large plugin catalog or its UI editor at scale, Kestra is still the better fit.

Both use YAML, so what actually differs?

The YAML is similar in spirit. The difference is underneath. Dagu is one binary with no JVM and no external database, while Kestra runs on Java with a database and adds Kafka and Elasticsearch for high availability.

Does Dagu have as many integrations as Kestra?

No. Kestra has a larger plugin catalog and a plugin marketplace. Dagu has a smaller set of built-in executors and expects you to call existing commands, scripts, and containers instead of installing plugins.

Next step

Start with one workflow.

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