No shared execution contract
The backend knows it requested work, the worker knows it started something, logs live elsewhere, and operators see only fragments. Status, output, retry history, and recovery are not one object.
DAGYCHU
Self-hosted execution control plane
Your application creates the task. Dagychu owns execution, recovery, visibility, and operational state.
Use Dagychu when your systems need durable execution, observable recovery, and operational visibility across long-running workflows.
For backend applications
When applications need imports, exports, reports, AI processing, document handling, marketplace sync, billing reconciliation, or bulk updates, teams often build outbox tables, polling workers, status columns, retry scripts, logs, and custom admin screens.
Dagychu gives the application one execution contract: create a task, track status, inspect job runs, read structured output, rerun or recover failed stages, and let operators see what happened.
External Execution API
Enterprise surface for backend systems, agents, and automation clients.
POST /ext/tasks
GET /ext/tasks/{task_id}
GET /ext/tasks/{task_id}/resultThe problem
Backend applications, cron jobs, scripts, Airflow DAGs, Celery workers, and AI agents often start work without one shared execution contract.
The backend knows it requested work, the worker knows it started something, logs live elsewhere, and operators see only fragments. Status, output, retry history, and recovery are not one object.
Status, retries, and outputs live in different places — outbox tables, columns, polling loops, and ad-hoc admin pages — until jobs become multi-step, long-running, or operator-facing.
AI jobs often call tools, wait for external systems, retry model steps, or require review. Without persisted execution state and structured outputs, failures are expensive to debug.
Operational logic spreads across cron, scripts, queues, dashboards, and manual checks. Dagychu brings task state, job runs, logs, outputs, and recovery into one control plane.
Dagychu is the execution layer between task creation and operational completion — one task_id across API, database, queue, worker, logs, scheduler, and operator UI.
Positioning
Dagychu sits between task creation and operational completion. It accepts work from an API, UI, scheduler, or webhook, then tracks the full task lifecycle through job runs, logs, outputs, retries, recovery, and operator actions. Enterprise adds the External Execution API for backends and agents.
Platform
A control plane for teams that need to operate long-running jobs, not only start them.
Tasks and job runs persist in PostgreSQL — status, I/O, errors, retries, and log metadata as one durable execution record.
Create tasks, monitor pipelines, inspect job I/O and logs, rerun, cancel, terminate, and reconcile from one operational surface.
Job-level retries, idempotent reruns, partial job rerun, cancel/terminate, and status reconciliation when execution diverges.
Project runtime images, Docker isolation, runtime configuration, and container telemetry tied to task_id and job_run_id.
Also built in
Runtime isolation
Dagychu supports local execution for simple deployments and Docker execution for production isolation. In Docker mode, Dagychu builds a project runtime image, injects project runtime configuration, mounts allowed project paths, labels containers with task_id and job_run_id, and records container execution telemetry for monitoring.
Architecture
The same task_id connects the request, database state, queue dispatch, worker execution, job logs, structured outputs, scheduler history, and operator UI.
React UI, Core API, authentication, pipelines, dashboard, and operator surfaces. Advanced roles & RBAC on Enterprise.
Consumes queue events, resolves the pipeline DAG, runs jobs, writes runs, logs, outputs, and terminal status.
Cron, webhook, dependency, and SLA triggers with scheduler runs, events, and diagnostics.
PostgreSQL for tasks, job runs, pipelines, scheduler history, and audit. Workspace dashboards on Enterprise.
RabbitMQ decouples task creation from worker execution with persisted dispatch state.
Projects with runtime config, validation gates, and Docker execution per pipeline group.
Control plane demo
Mock data only — the flow mirrors production usage: create a task, track job runs, inspect input/output and logs, rerun with edited JSON, and show operators the current execution state. External Execution API and Monitoring Overview are Enterprise surfaces.
Input and output for the selected pipeline job — edit input to rerun with JSON (same as Job detail).
| Task | Pipeline | Status | Last job | Duration |
|---|
Audience
Run imports, exports, reports, sync jobs, billing reconciliation, document processing, and other long-running product operations without building custom execution tracking.
Replace invisible cron, scattered workers, custom status tables, and ad-hoc rerun scripts with one execution control plane.
Run ETL, validation, marketplace sync, monitoring, and scheduled operational pipelines with job-level visibility and recovery.
Track AI jobs, tool calls, structured outputs, retries, and review steps as operational execution instead of opaque model-side activity.
Standardize execution governance, recovery, and visibility across backend jobs, schedulers, and operator workflows without building a custom control plane.
Use cases
A user requests a large export. Backend creates a Dagychu task. Dagychu runs validation, data collection, file generation, upload, structured output, and operator notification.
Customer uploads a file or integration payload. Dagychu validates, transforms, loads, records warnings, and returns final output to the application.
Long-running AI classification, enrichment, extraction, or tool-call workflows with persisted state, retries, structured outputs, and optional review stages.
Scheduled catalog checks, retries, hidden listing detection, report generation, and operator alerts.
Dependency-aware data jobs with per-stage input/output, retry policy, SLA-oriented schedules, and failure investigation.
Human-in-the-loop operations where a task can wait for review and continue with visible state and output history.
Deployment
No mandatory cloud control plane. Run Dagychu on your servers with full ownership of execution data and logs.
Core API, UI backend, worker, scheduler, PostgreSQL, RabbitMQ, and frontend. The stack can run privately without a mandatory cloud control plane.
Pipeline YAML lives on disk, syncs into the pipeline registry, and defines jobs, dependencies, inputs, outputs, retry policies, tags, and launch order.
Connect pipeline groups as projects, validate dagychu-config, configure runtime variables, and execute jobs locally or in Docker containers.
Health endpoints, queue visibility, stuck task checks, scheduler diagnostics, audit log, notifications, and operator dashboard for daily operations.
Plans
Both editions run on your infrastructure and provide the core Dagychu execution experience. Community is free to self-host and is not an open-source release of application source.
For teams that need to run and monitor their own jobs and pipelines.
Use Community when you want to bring scheduled and background workloads under control without building execution infrastructure into your applications.
For organizations that use Dagychu as shared production infrastructure.
Choose Enterprise when multiple people or teams operate workloads and you need stronger organizational controls.
Start with Community. Move to Enterprise when Dagychu becomes infrastructure your organization depends on.
Durable execution, observable recovery, and operational visibility for backend-triggered workflows and AI systems.