Airflow's diet: one binary, zero databases, actual YAML

What it does Dagu runs scheduled and event-driven workflows from a single Go binary. You write DAGs in plain YAML, start the server, and get a Web UI for monitoring, retrying, and approving runs. It executes shell commands, Docker containers, Kubernetes Jobs, SSH commands, and even AI-agent harnesses without asking you to install a database or message queue.

The interesting bit The project bets that most teams don’t need Airflow’s six-service architecture. State lives in local files, not PostgreSQL or Redis. That file-backed design is unusual for an orchestrator—it means Dagu can run offline on edge devices, yet still scale out through optional distributed workers when you need parallel ffmpeg transcodes or heavy ETL.

Key highlights

• Single binary, no DBMS, runs on Linux/macOS/Windows
• Declarative YAML DAGs with a visual Web UI for management and approvals
• Built-in MCP server lets AI agents (Claude Code, Codex, etc.) read state, edit workflows, and trigger runs
• Distributed worker mode for scaling beyond one machine
• Secret management with log masking to keep credentials from leaking to agents or the UI
• Managed and hybrid deployment options if you want someone else to run the server

Caveats

• The README is vague on exact throughput limits; “thousands of runs per day” depends heavily on hardware and workflow shape
• Managed instances block Docker daemon access, so container-heavy workflows need self-hosted or hybrid deployment
• RBAC and SSO sit behind a paid self-host license, not in the community edition

Verdict Small teams drowning in cron jobs or bash scripts should look here first. If you’re already deep into Airflow’s plugin ecosystem or need fine-grained Python DAG logic, Dagu’s simplicity is a constraint, not a feature.