Dagu vs Argo Workflows

Argo Workflows vive en Kubernetes. Dagu corre en una máquina normal.

Ambos definen DAGs y ejecutan pasos en orden. Argo Workflows está integrado en Kubernetes y planifica cada paso como un pod. Dagu es un binario único que llama a los comandos que ya tienes, sin clúster que operar.

Un workflow que corre en un solo host
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 binario único y autónomo, sin clúster Kubernetes

YAML declarativo que ejecuta comandos existentes

Sin base de datos externa ni message broker

Executors para shell, Docker, HTTP, SSH, SQL, sub-workflows y agentes de IA

Orquestación sin un clúster debajo

Argo Workflows asume un clúster Kubernetes en marcha y un controller que convierte cada paso en un pod. Dagu no tiene ese requisito. Pones un binario en un servidor, un portátil o una VM y funciona.

  • Corre en una máquina normal, sin Kubernetes, sin controller y sin etcd.
  • Guarda el estado en archivos locales en vez de una base de datos o broker aparte.
  • Empieza en local y pasa al modo en cola o distribuido cuando crezca la carga.

Los pasos son comandos, no solo contenedores

En Argo Workflows cada paso es un contenedor que corre en un pod. Dagu también puede correr un contenedor, pero además llama directamente a un script shell, un endpoint HTTP, un comando SSH, una consulta SQL, un sub-workflow o un paso de agente de IA.

  • Reutiliza scripts y binarios que ya tienes sin empaquetar cada uno como image.
  • Mezcla pasos Docker con shell, HTTP y SSH en el mismo workflow.
  • Consulta ejecuciones, logs e historial en una Web UI integrada.

Cuándo elegir Argo Workflows

Argo Workflows encaja mejor cuando Kubernetes ya es tu plataforma. Es Kubernetes-native, planifica cada paso como un pod propio y está hecho para container fan-out pesado. Dagu no hace nada de eso.

  • Corres en Kubernetes y quieres workflows definidos como CRDs junto a tus otros manifiestos.
  • Necesitas pod scheduling, node selectors y autoscaling de clúster por cada tarea.
  • Tus pipelines se expanden a miles de contenedores en muchos nodos a la vez.

Argo Workflows vs. Dagu de un vistazo

Dimension
Dagu
Typical alternative
Runtime
Un binario único en una máquina normal, apoyado en archivos locales.
Un clúster Kubernetes con un workflow controller.
Qué es un paso
Un comando: shell, Docker, HTTP, SSH, SQL, sub-workflow o agente de IA.
Un contenedor que corre como pod en el clúster.
Mejor encaje
Jobs de ops, scripts y pipelines mixtos en hosts que ya mantienes.
Pipelines Kubernetes-native, pesados en contenedores o de ML a escala.

FAQ

Practical questions before adopting Dagu

¿Dagu reemplaza a Argo Workflows?

No para todos los equipos. Si estás estandarizado en Kubernetes y quieres que cada paso corra como un pod, Argo Workflows es la herramienta correcta. Dagu encaja mejor cuando quieres orquestar comandos en una máquina normal sin operar un clúster.

¿Dagu funciona sin Kubernetes?

Sí. Dagu es un binario único y autónomo que corre en servidor, VM o portátil. No necesita clúster Kubernetes, base de datos externa ni message broker.

¿Dagu todavía puede correr contenedores?

Sí. Dagu tiene un executor Docker para pasos que necesitan un contenedor. La diferencia es que el contenedor es una opción entre pasos shell, HTTP, SSH, SQL y sub-workflow, no la única unidad de ejecución.

Start with one workflow.

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

Install Dagu