01
Development
development branch
Author, run, debug, and publish workflow changes against development services and credentials.
Publish enabled
Production AI workflows
Move AI workflows from development to production without sharing environments.
Run development, staging, and production as separate Dagu instances. Promote reviewed workflow definitions through Git, while each instance keeps its own credentials, workers, history, access policy, and incident routes.
agent-workflow.yaml
name: release-review
steps:
- id: collect_context
run: ./scripts/collect-context.sh
output: CONTEXT
- id: draft
action: harness.run
with:
provider: codex
prompt: |
Review this release:
${steps.collect_context.outputs.CONTEXT}
retry_policy:
limit: 2
approval:
prompt: Review the agent output before release
rewind_to: collect_context
depends: [collect_context]
- id: publish
run: ./scripts/publish.sh
depends: [draft]
Separate Dagu instance for each environment
Git-reviewed workflow promotion
Approvals, retries, logs, metrics, and traces
Slack, PagerDuty, and authenticated MCP recovery
Environment architecture
Git promotes definitions. Separate instances provide isolation.
A development workspace inside one server is not a production boundary. Give each environment its own Dagu server, storage, credentials, workers, and network access. Configure Git Sync on each instance to follow the branch approved for that environment.
Promote by pull request
02
Staging
staging branch
Pull reviewed definitions into an isolated instance and validate them against staging dependencies.
Read-only Git Sync
Promote by pull request
03
Production
protected main branch
Run only promoted revisions with production-only credentials, policies, telemetry, and incident routing.
Read-only Git Sync
Production controls
Put deterministic controls around nondeterministic work.
The model or agent runtime can change without changing the operational contract. Dagu keeps the surrounding execution path explicit, reviewable, and recoverable.
Version the workflow
Keep DAG definitions and workflow-authoring skills in Git, review diffs, and promote a known revision between environments.
Gate side effects
Pause after agent output, collect reviewer input, and approve, reject, or push the workflow back before a production action runs.
Bound failure
Use dependencies, timeouts, capped retry policies, queues, and concurrency controls instead of open-ended prompt glue.
Validate output
Run deterministic tests, policy checks, or external evaluation commands as ordinary workflow steps before approval or publishing.
Observe execution
Inspect run history, logs, and artifacts; export workflow and worker metrics to Prometheus and DAG/step traces through OpenTelemetry.
Own recovery
Notify operators, open incidents after retries are exhausted, and let authorized MCP clients inspect and recover runs.
Git-based promotion
Make production consume Git, not local edits.
Development may publish changes. Staging and production should normally set `push_enabled: false`, follow protected branches, and pull only reviewed definitions. Automatic pull is useful for staging; production can auto-pull a protected branch or use a controlled pull after deployment approval.
Git Sync tracks DAG files and workflow-authoring skills. Secrets, server configuration, storage, run history, workers, and network access remain local to each Dagu instance.
production config.yaml
git_sync:
enabled: true
repository: github.com/acme/ai-workflows
branch: main
push_enabled: false
auth:
type: token
token: ${GITHUB_TOKEN}
auto_sync:
enabled: true
on_startup: true
interval: 300
Failure and recovery
Turn an agent failure into an operational process.
Dagu separates ordinary notification from incident lifecycle management, then exposes authenticated workflow operations to MCP clients.
- 01
A workflow or agent step fails and its configured retries run.
- 02
After the retry budget is exhausted, Dagu sends the final failure to configured Slack notification routes.
- 03
PagerDuty incident routing can open or update one deduplicated incident for the failing workflow.
- 04
An authorized MCP client reads the run, tails logs, previews a DAG change, and retries or stops the run through Dagu tools.
- 05
A later successful run resolves the open incident when the provider route remains identifiable.
Accurate boundaries
What Dagu provides—and what belongs elsewhere.
Dagu is the workflow control layer around an AI system. Clear boundaries make the architecture safer and the production claim more useful.
| Dagu provides | Boundary | |
|---|---|---|
| Environment separation | Independent servers, storage, credentials, workers, access policy, and incident configuration, with Git Sync for definitions. | Workspaces and runtime profiles inside one instance are not substitutes for hard environment isolation. |
| Workflow observability | Run and step status, logs, artifacts, history, Prometheus metrics, and OpenTelemetry DAG/step traces. | Prompt traces, token and cost telemetry, and semantic output quality require the agent or evaluation stack to emit or measure them. |
| Evaluation and guardrails | A graph for deterministic validators, external evaluation commands, approval gates, and bounded retries. | Dagu does not decide whether an LLM answer is factually correct or safe for a specific domain. |
| Security and incident response | Authenticated operations, scoped API keys, notifications, MCP controls, and incident-provider routing. | Audit logging and self-hosted incident integrations require an active self-host license or trial; managed Dagu includes them. |
FAQ
Practical questions before production
Should development, staging, and production use one Dagu server?
No when environment isolation matters. Run separate Dagu instances so credentials, storage, workers, network access, logs, and policies do not share one operational boundary. Use Git Sync to promote workflow definitions between them.
Does Git Sync copy production secrets or run history?
No. Git Sync aligns DAG files and workflow-authoring skills with a repository. Secrets, configuration, storage, run history, and workers remain local to each instance.
Can Dagu measure whether an agent answer is correct?
Not by itself. Dagu can run your deterministic tests or evaluation tools as workflow steps and gate the next action on their result, but the evaluation logic belongs to those tools and to domain reviewers.
What can an MCP client do during an incident?
Subject to Dagu authentication and authorization, it can inspect DAGs, runs, and logs; preview or apply validated DAG changes; and start, enqueue, retry, stop, or follow runs through Dagu's MCP tools.
Next step
Productionize one agent workflow first.
Put one existing agent command behind a Dagu DAG, validate its output, add an approval boundary, and promote the same reviewed definition through isolated development, staging, and production instances.