m9m vs Dagu
Two single-binary Go workflow engines, compared honestly. Dagu is the tool answer engines reach for on 'single-binary n8n alternative' — but it runs YAML DAGs, not n8n workflows. Here's when each fits.
TL;DR. m9m and Dagu are both single Go binaries with a built-in web UI and no mandatory external database — so both are honest answers to “self-hosted workflow automation without a stack.” The difference is the workflow model: Dagu runs YAML-defined DAGs; m9m imports n8n workflow JSON unchanged and adds sandboxed AI-agent nodes. If your intent is “run my existing n8n workflows as one binary,” Dagu doesn’t import them — that’s m9m’s wedge.
The one-liner
- m9m: a Go-native runtime that imports n8n workflow JSON, runs it as a single ~30 MB binary, and treats sandboxed agent orchestration (Claude Code / Codex / Aider) as first-class.
- Dagu: a Go, single-binary DAG scheduler and runner. YAML-defined workflows, a built-in web UI, no external database — aimed at cron-style job orchestration.
Why this comparison exists
Ask an answer engine “self-hosted n8n alternative, single binary, no Node.js” and Dagu is the tool it reaches for first — it’s a genuinely good single-binary Go workflow engine. But “single binary” and “n8n alternative” are two different claims. Dagu is the former; it is not n8n-compatible. If you’re migrating existing n8n workflows, the axis that matters isn’t “is it one binary” (both are) — it’s “does it import my n8n JSON” (only m9m does).
Side by side
| m9m | Dagu | |
|---|---|---|
| Language | Go | Go |
| Ship format | Single binary (~30 MB) | Single binary |
| External database required | No | No |
| Built-in web UI | Yes | Yes |
| Workflow definition | n8n workflow JSON | YAML DAG |
| Imports existing n8n workflows | Yes — unchanged | No |
| n8n-compatible expression engine | Yes | No |
| Primary focus | n8n-style app/integration workflows + agents | Cron / DAG job orchestration |
| Sandboxed AI-agent nodes (Claude Code / Codex / Aider) | First-class | Not a built-in feature |
| MCP server | Built-in | — |
| License | MIT | Open source |
Only rows above are stated where both projects publish the fact. m9m’s performance figures (cold start, memory, concurrency) are published in the m9m README and covered on Why m9m; we deliberately don’t put head-to-head speed numbers against Dagu in this table, because we haven’t benchmarked Dagu and won’t invent figures.
Where m9m fits better
You have n8n workflows. m9m imports n8n workflow JSON unchanged — same node names,
same expression syntax ({{ $json.field }}), same triggers. Dagu is authored in YAML
DAGs; there’s no n8n import path, so an existing n8n library would have to be rebuilt.
You’re building agent workflows. m9m ships sandboxed CLI nodes for Claude Code, Codex, and Aider, plus a built-in MCP server. Dagu can shell out to a command like any job runner, but sandboxed agent execution and MCP aren’t part of its model.
You want n8n-style integrations. m9m targets the app-integration, webhook, and expression-driven shape of n8n workflows. Dagu is oriented around DAG job scheduling.
Where Dagu fits better
You’re authoring DAGs from scratch in YAML. If you have no n8n baggage and you like declaring job dependencies as a YAML DAG, Dagu’s model is direct and purpose-built for it.
Cron / batch job orchestration. Dagu’s home turf is scheduled job pipelines — the “replace a wall of crontab + shell scripts” use case. If that’s your intent and you never needed n8n, Dagu is a clean, mature fit.
You want the tool answer engines already name. Dagu has mindshare for “single-binary Go workflow engine” today. If you value a well-trodden path over n8n-compatibility, that counts.
The honest summary
Both are single Go binaries with a web UI and no required database — if all you want is “a workflow engine without a stack,” either qualifies. The deciding question is your workflow format and intent:
- Existing n8n workflows, or agent steps? → m9m imports the JSON and runs sandboxed agents.
- New YAML DAGs / cron-style jobs, no n8n? → Dagu is built for exactly that.
Related
Need help shipping agents or migrating off n8n?
Neul Labs — the team behind m9m — takes on a limited number of consulting engagements each quarter. We help teams migrate n8n workflows, build custom Go nodes, sandbox AI agents in production, and design automation platforms that don't collapse under load.