Durable DAG workflows
in one Rust binary.
Define a workflow as a graph of tasks in plain YAML. dagron validates it, then runs each task the moment its dependencies succeed — concurrently, with retries and exponential backoff. No control plane, no cluster to operate, a database as the only state.
Apache-2.0 Single static binary SQLite or Postgres Kubernetes-native
| Time | Workflow | Task | Runner | Status |
|---|
Waiting / retrying Failed → dead-letter Succeeded illustrative board — not live data
Everything to run workflows.
Nothing you don't need.
A lean trade: one Rust binary, plain YAML, and a database — durable orchestration without the operational weight of Airflow or a Celery fleet.
A graph of tasks, and what each one waits for.
The spec is validated and cycle-checked server-side before a single task runs, so a broken graph fails at submission rather than halfway through a nightly load.
A failed task retries. A parked task holds nothing.
Per-task max_attempts with exponential backoff, timeouts and trigger rules. Approval gates and wait sensors park a run while it occupies no worker slot.
Runs stream into a live DAG view.
Inspect the graph and read per-task logs while the work is still moving — over the same engine the CLI drives.
The storage backend is a build flag.
Start on an embedded SQLite file, then move to Postgres for multi-node without touching the workflow.
Three executors, routed by runner class.
Run tasks in-process, as Docker containers, or as one-shot Kubernetes Pods — and send the expensive hardware only the steps that need it.
Reconciled from a repository, or driven by an agent.
A dedicated worker reconciles versioned workflows from a repository; the MCP server exposes submit, inspect and cancel to an AI agent over the same authenticated API the console uses.
Lineage that downstream work can act on.
produces: records which run wrote which dataset. Sense one, or fire a whole workflow when it updates.
Concurrency caps, dispatch order, and a cache key.
Cap concurrency per pool, order the ready queue by dispatch priority, and memoize a step so an unchanged key never runs again.


One binary at the edge.
The same YAML in the cluster.
The spec in the middle does not change between them. Only what it is pointed at does.
One process, one file
A static binary against a local SQLite file. State is local, so the site keeps running while disconnected and resumes from its own database after a reboot.
- State
- site.db (SQLite)
- Executor
- local subprocess
- Arch
- arm64 · amd64
- Operates
- nothing
# workflow.yaml — unchanged in both columns name: nightly-etl tasks: - name: extract command: ["extract.sh"] max_attempts: 3 - name: transform depends_on: [extract] - name: load depends_on: [transform] produces: ["s3://dw/daily"]
Multi-node, Kubernetes
The same spec against Postgres, dispatching one-shot Pods by runner class, installed from the OCI Helm chart.
- State
- Postgres
- Executor
- Kubernetes Pods
- Install
- helm · OCI chart
- Operates
- no control plane
Six shapes it fits.
dagron scales down as well as it scales out: the workflow you run on a gateway is the workflow you run on Postgres and Kubernetes, unchanged.
AI & ML workloads
Training, fine-tuning, batch inference, agent-driven runs
- Long tasks aren't reclaimed. A running task renews a heartbeat lease, so an hours-long step is never mistaken for a dead one.
- Resume, don't restart. A task that reported a checkpoint gets it back on retry via DAGRON_RESUME_FROM.
- Route the expensive hardware with runner classes; co-schedule N ranks all-or-nothing with gang scheduling Enterprise.
- Drive it from an agent. The MCP server exposes submit/inspect/cancel over the same authenticated API the console uses.
Data engineering
Nightly loads, backfills, warehouse pipelines
- Schedules and backfills with cron, plus a dead-letter queue you can inspect and redrive.
- Fair sharing. Concurrency pools and dispatch priority stop a wide backfill starving the nightly load.
- Lineage that means something. produces: records which run wrote which dataset; downstream work can wait on it or fire from it.
- Reuse whole pipelines as a single step with template: — a DAG of DAGs, expanded at run creation.
Data science
Feature builds, evaluation, reproducible notebooks-as-jobs
- Don't recompute what hasn't changed. cache: memoizes a successful step by key; a later run with the same key reuses the output and skips execution entirely.
- A human in the loop. An approval gate parks the run, holding no worker, until someone approves or rejects it.
- Per-task environments. Each step can be its own container image with its own CPU and memory request.
Event-driven & streaming
CDC, sensor feeds, per-event pipelines
- A stream of workflows. Follow an NDJSON file or FIFO: each line submits a run; a directory of shards splits across consumers by lease.
- Exactly once. The run and the source offset commit in the same transaction, so a crash can neither duplicate a run nor lose one.
- Poison lines don't stall the feed: they dead-letter, and you redrive them once fixed.
- Managed broker connectors for Redis, SQS, Kafka and NATS Enterprise; the file and FIFO source is open.
Edge & IoT
Gateways, retail sites, vehicles, remote plant
- Nothing to operate. One static binary and a SQLite file. No control plane, no broker, no cluster.
- Small enough to co-locate. Published for arm64 and amd64; the engine container idles around 10 MB resident.
- Survives the uplink. State is local, so a site keeps running while disconnected and resumes from its own database after a reboot.
- Lint before you ship. dagron validate parses, expands and graph-checks a spec offline, with no server and no network.
Lightweight compute
Small teams, side services, anything that doesn't deserve Airflow
- Zero infra to start. dagron dev brings up the engine, the management API and Swagger on localhost.
- No idle daemon. A one-shot run drains and exits; it only stays resident when you configure it to.
- Room to grow. Move the same YAML to Postgres for multi-node: a build flag, not a rewrite.
Free and open.
Enterprise when you scale.
The core engine, UI, and Helm chart are Apache-2.0 and free forever. The Enterprise edition adds the identity, tenancy, and operations layer teams need in production.
| Capability | Open Source | Enterprise |
|---|---|---|
| DAG engine, retries, scheduling, web UI | ||
| SQLite / Postgres, Docker & Kubernetes executors | ||
| Approval gates, GitOps sync, MCP, dead-letter queue | ||
| Datasets — produces:, lineage, sensors, single-dataset triggers | ||
| Pools, dispatch priority, result memoization, wait sensors | ||
| Streaming ingestion — file/FIFO source, sharded consumers | ||
| Multi-dataset composition & external dataset events | ||
| Managed broker sources — Redis, SQS, Kafka, NATS | ||
| Gang scheduling — all-or-nothing co-scheduled ranks | ||
| Encryption at rest — envelope / BYOK-KMS + key rotation | ||
| SSO — OIDC, SAML, LDAP / Active Directory | ||
| Multi-tenant control plane & tenant router | ||
| RBAC roles + full audit trail | ||
| Auto-backfill & self-healing reruns | ||
| GitOps operator + Workflow/CronWorkflow CRDs | ||
| Air-gapped install & signed offline licensing | ||
| Usage metering & billing export | ||
| Priority support & SLA |
Running dagron across teams?
Enterprise adds single sign-on, a multi-tenant control plane with per-tenant isolation, RBAC and audit, air-gapped deployment, and a support agreement — self-hosted on your infrastructure. Metered or flat-license pricing.
Up and running in minutes.
Deploy the full stack with the Helm chart, or run the whole thing from one binary for local development.
# multi-arch images + OCI chart on Docker Hub $ helm install dagron \ oci://registry-1.docker.io/mancube/dagron # point at your own Postgres $ helm install dagron oci://…/mancube/dagron \ --set postgres.enabled=false \ --set externalDatabaseSecret.name=dagron-db
# full stack: engine + API + web UI $ git clone https://github.com/lucheeseng827/dagron $ cd dagron && docker compose up # open the UI http://localhost:3000
Questions, answered.
What is dagron?
dagron is an open-source DAG workflow engine and scheduler. Define a workflow as a graph of tasks in YAML; dagron validates it and runs each task as soon as its dependencies succeed — concurrently, with retries and exponential backoff — from a single static Rust binary, using a database as its only state.
How is dagron different from Airflow?
dagron is a lightweight Airflow alternative: one Rust binary and plain YAML instead of a Python/Celery stack. No control plane, no cluster to operate — an embedded SQLite file works to start, and you switch to Postgres for multi-node. Tasks run as local subprocesses, Docker containers, or Kubernetes pods.
Is dagron free and open source?
Yes. The core engine, web UI, and Helm chart are Apache-2.0 and free to self-host indefinitely. An optional Enterprise edition adds SSO (SAML/OIDC/LDAP), a multi-tenant control plane, RBAC and audit, air-gapped install, and support.
How do I install dagron?
Install the Helm chart from Docker Hub (OCI): helm install dagron oci://registry-1.docker.io/mancube/dagron. For local development, run the full stack with docker compose up, or run the single dagron binary directly. See the get-started section.