Dagychu product reference
Dagychu capabilities
Dagychu is a self-hosted control plane for running and operating Python and Bash jobs. This page states what the product implements and which capabilities belong to Community or Enterprise.
What this page covers
Use this reference when evaluating Dagychu for imports, exports, reports, data processing, reconciliation, AI workflows or other background work that must be observable and recoverable.
Community provides the execution and operating core. Enterprise adds organization-wide monitoring, reporting, access control and integration surfaces for teams using Dagychu as shared production infrastructure.
Execution and runtime control
The execution model keeps the pipeline definition, task, job attempts, inputs, outputs and logs connected under one operational identity.
| Capability | Edition | What it provides |
|---|---|---|
| Pipeline registry and validation | Community + Enterprise | YAML-defined pipelines, validation, project connection and runtime-image preparation before production execution. |
| Python and Bash jobs | Community + Enterprise | Run an existing standalone script without changing its source code; configure the project runtime and pipeline YAML around it. |
| Local and Docker executors | Community + Enterprise | Choose local execution or isolated containers, including a per-project runtime image. |
| Structured inputs and outputs | Community + Enterprise | For jobs that exchange data, read Dagychu JSON input and emit structured stdout as output_json; optionally validate it against an output schema. |
| Parallel execution controls | Community + Enterprise | Run independent jobs in a DAG concurrently and limit parallel copies of the same task. |
| Fixed or exponential retries | Community + Enterprise | Configure retry attempts and backoff policy per job instead of hiding retry behavior in scripts. |
Investigation and recovery
Dagychu treats a failed execution as an object an operator can inspect and recover, not only as a log line or alert.
| Capability | Edition | What it provides |
|---|---|---|
| Investigation graph | Community + Enterprise | See the affected pipeline and job relationships around a failed or suspicious execution. |
| Debug step and reset | Community + Enterprise | Move through controlled diagnostic steps and reset investigation state. |
| Per-job rerun | Community + Enterprise | Rerun selected failed work rather than blindly restarting the whole pipeline. |
| Operations timeline | Community + Enterprise | Retain the sequence of operator and execution events used during an investigation. |
| Freeze external triggers | Community + Enterprise | Stop new externally triggered work for a task while operators investigate, then unfreeze it deliberately. |
| Reconciliation and orphan recovery | Community + Enterprise | Detect and repair execution state that diverged after worker or infrastructure failure. |
Scheduling, deadlines and dependencies
Set when a result must be ready, for example a report due at 09:00. For a deadline plan, Dagychu estimates execution duration from previous runs, accounts for the duration trend and a configured buffer, and calculates the next start time backward from the deadline. As runtime estimates change, the planned start can move earlier or later. The scheduler records runs and deadline compliance; the estimate does not guarantee on-time completion.
Cron, manual, webhook and dependency plans are also available.
| Capability | Edition | What it provides |
|---|---|---|
| Cron and manual plans | Community + Enterprise | Dispatch recurring work on a schedule or start it under operator control. |
| Webhook plans | Community + Enterprise | Accept authenticated external triggers with a secret and rate limits. |
| Dependency plans | Community + Enterprise | Start work when the required upstream execution condition is satisfied. |
| SLA and deadline plans | Community + Enterprise | Set a required finish time. Dagychu uses execution history, runtime trend and a buffer to estimate duration, then calculates when to start work to target that deadline and records whether it was met. |
| Pause, resume and diagnostics | Community + Enterprise | Control plans and inspect scheduler runs and events. |
| Maintenance windows | Community + Enterprise | Represent periods in which planned operational work should not be treated like an ordinary failure. |
Worker and operational visibility
Operators can inspect the worker fleet, queues and individual executions from the same control plane.
- Worker fleet, queue and execution progress views, including termination controls for stuck work.
- Per-job input, output preview, full logs and execution history.
- Global find across pipelines, tasks, job names and scheduler plans; notes on tasks, plans and pipelines.
- Searchable logs, audit history and in-application notifications.
- Admin configuration snapshots with preview and selective, non-destructive restore. Secrets and runtime job code are not included in the archive.
- A 24-hour operational dashboard in Community; expanded cross-system monitoring in Enterprise.
Enterprise monitoring, governance and integrations
Enterprise is for multiple people or teams operating Dagychu as shared production infrastructure.
| Capability | What it provides |
|---|---|
| Monitoring Overview | Health score, operational concerns, incidents and KPIs across executions, workers and pipelines. |
| Execution Map | A system-level view of execution relationships and operational state. |
| Workspace dashboards and Creator view | Saved operational views for different teams and responsibilities. |
| Advanced RBAC and OIDC SSO | Organization-wide permissions beyond Community's limited access model, plus OIDC Authorization Code with PKCE for organization sign-in. |
| API Security | Security telemetry and policy controls for API access. |
| External Execution API | Create executions and retrieve status/results through /ext/*, with callbacks and rate limits. |
| External notifications | Deliver operational notifications to Slack or Telegram in addition to in-product notifications. |
| Table Reports and ClickHouse | Saved reports over Dagychu system data and structured job outputs, exports, shareable URLs and optional ClickHouse synchronization for BI. |
Reports over system data and job outputs
Dagychu Enterprise includes a reporting layer rather than requiring teams to reconstruct execution history from raw logs. Report sources include task and job runs, operations, pipeline registry and drill-down views, scheduler data, workers, incidents and execution history.
The Job Output View Designer discovers JSON paths in output_json. An operator can select fields, filters and sorting, save the configuration, share the report URL, export CSV, JSON, XLSX or SQL, and optionally synchronize the result to ClickHouse for read-only BI access.
Frequently asked questions
Is Dagychu Community open source?
No. Community is free to self-host from published container images. The public GitHub repository contains distribution materials, documentation and examples; it is not an application-source release.
Does Community require ClickHouse?
No. Community uses PostgreSQL for product state and its included operational views. ClickHouse-backed Table Reports are an Enterprise capability.
Does Dagychu replace business-level idempotency?
No. Dagychu can retry and rerun execution, but your job must still make external side effects idempotent or provide a reconciliation strategy.
Can Dagychu run existing scripts unchanged?
Yes. Existing Python and Bash scripts can run as standalone jobs without source-code changes. Dagychu still needs project runtime configuration and pipeline YAML. Modify the script or add an adapter only when it must consume Dagychu JSON input or emit structured output_json for downstream jobs and reports.
Evaluate Dagychu
Start with one real Python or Bash workflow. Verify a successful run, inspect a controlled failure, and test the recovery boundary against your own business result.