Python and Bash execution
Run existing standalone scripts without source-code changes. Add Dagychu JSON input/output only when jobs need to exchange structured data or feed reports.
Flagship product
Dagychu
Run, observe and recover Python and Bash workflows on your own infrastructure.
Bring existing scripts into one control plane for scheduling, per-job inputs and logs, targeted reruns and operator recovery. Start with Community; add Enterprise when you need team-wide governance, external APIs and saved reports.
Self-hostedCommunity + EnterpriseOperational + AI workflows
Raideria Lab includes an example web application with two runs without signing in. Dagychu executes its analysis and exposes the run in the Enterprise 3.4.5 stand. Community capabilities are identified below.
Current release · 3.4.5
See what Dagychu can do today.
The live demo shows the running product. Release notes document the changes behind it.
- Set a result deadline and let the scheduler calculate a start time from run history, its trend and a buffer.
- Inspect failed jobs, their exact input and full log, then rerun a selected step or reconcile orphaned execution state.
- Find pipelines, tasks, jobs and scheduler plans from one search; add notes to tasks, plans and pipelines.
- Export and selectively restore configuration snapshots without deleting unrelated entities; re-enter secrets separately.
- Enterprise: design saved views from structured job output, export reports and optionally sync them to ClickHouse.
See it in an application
See how Dagychu executes work for a web application.
Breakflow is an example web application in Raideria Lab. Describe a workflow; the application sends an analysis request to Dagychu, which runs the pipeline and exposes its execution history. Try two runs without signing in, then open the Dagychu stand to inspect the control plane behind it. You can also open the stand directly.
Origin
Not sold. Extracted.
While building Data Platforms and Execution Systems, the same machinery appeared again and again: queues, workers, retries, schedulers, logs, admin screens. Each team reinvented a weaker version under deadline pressure.
Dagychu is that layer built once, as a product, with the operational discipline Raideria requires of production systems. It is a consequence of the engineering work — not a separate marketing story.
The problem
Your backend should not become an orchestration system.
When applications need imports, exports, reports, AI processing, reconciliation, or bulk updates, teams often build outbox tables, polling workers, status columns, retry scripts, and custom admin screens. That machinery becomes its own system to maintain, and it is rarely observable.
Dagychu is that execution layer, built once and built to be operated. Your application posts a task; Dagychu owns running it and making the result visible.
Why it is a Raideria product
Raideria builds systems. Dagychu powers execution.
Dagychu is one concrete expression of how Raideria thinks about engineering. It is a product of Raideria; it is not the whole company.
What is happening / what changed
Execution state, per-job logs, and history are first-class, not an afterthought.
Who owns it / what next
A scheduler and control plane make ownership and operational state explicit.
How do we recover
Failure and recovery are part of the model: retries, structured outputs, and reconciliation.
What it does
Operate the full execution lifecycle.
These are implemented product capabilities, not a roadmap.
Schedules, events and deadlines
Need a report ready by 09:00? Dagychu uses past execution durations, their trend and a buffer to calculate when to start the next run. Cron, manual, webhook and dependency plans, pause, resume and scheduler diagnostics are also available.
Inputs, outputs and logs
Inspect per-job input, structured output_json, errors, attempts and full logs from one execution record.
Investigation controls
Use an investigation graph, debug step/reset, operations timeline and the ability to freeze external triggers while diagnosing a task.
Targeted recovery
Apply fixed or exponential retries, rerun selected jobs and reconcile orphaned execution state after infrastructure failure.
Worker operations
See worker fleet and queue progress, inspect running work and terminate executions that are stuck.
Find and preserve context
Search for pipelines, tasks, job names and scheduler plans; leave notes on operational objects and export configuration snapshots for selective restore.
Enterprise monitoring
Add health score, concerns, incidents, KPIs, Execution Map and custom workspace dashboards across the installation.
Enterprise APIs and access
Add the External Execution API, callbacks, rate limits, advanced RBAC, OIDC SSO and API security controls.
Reports and ClickHouse
Build saved reports from Dagychu system data or job output_json, export them, share report URLs and optionally sync to ClickHouse for BI.
Enterprise reporting
System data and job outputs become reusable reports.
Dagychu Enterprise includes Table Reports over task and job runs, operations, pipelines, scheduler data, workers, incidents and execution history. These are native product views, not a requirement to query raw application tables yourself.
For structured job results, the Job Output View Designer discovers JSON paths in output_json. Choose fields, filters and sorting; save the report; share its URL; export CSV, JSON, XLSX or SQL; and optionally synchronize the result to ClickHouse for read-only BI access.
What the reporting layer provides
- PostgreSQL remains the authoritative Dagychu state store.
- ClickHouse synchronization is optional and Enterprise-only.
- Saved reports preserve a controlled scope instead of exposing the transactional schema to every BI consumer.
- Execution analytics can surface failure hotspots, retry patterns and duration drift.
Evaluate the fit
Recognize the platform you may already be maintaining.
A runner is only the beginning. Use the buyer guide to identify the status tables, retry endpoints, recovery scripts and operator UI growing around your jobs, then check the exact capability and edition boundary.
Architecture
A control plane around your workloads.
Simplified for clarity; the running system has more moving parts.
Your application
POST task
Core API
FastAPI
Queue + Workers
run jobs
PostgreSQL
state + history
A separate scheduler dispatches runs, and a React control plane (via a UI backend) provides dashboards, task views, and per-job logs. Job logs are shared with the control plane so full output is readable from the UI. PostgreSQL remains the authoritative state store; Enterprise reports can optionally synchronize selected report tables and execution facts to ClickHouse. See also the broader reference architecture for how this plane sits in a Data Platform.
Editions
Community or Enterprise?
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 — public GitHub hosts distribution materials; Apache License 2.0 applies only where those materials are so marked.
Community
Free · self-hosted
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.
- Pipelines, tasks, job runs, local or Docker execution, scheduler, workers and logs
- Cron, manual, webhook, dependency, SLA and deadline plans
- Investigation graph, targeted reruns, trigger freeze and reconciliation
- Structured output_json, optional output-schema validation and 24-hour operational charts
- Self-hosted control plane on your infrastructure
- Free to use — no artificial task or run quotas
Enterprise
Commercial
For organizations that use Dagychu as shared production infrastructure.
Choose Enterprise when multiple people or teams operate workloads and you need stronger organizational controls.
- Advanced RBAC — organization-wide control beyond Community's limited access model
- OIDC SSO, API Security and multi-user governance
- Monitoring Overview, health score, incidents, Execution Map and workspace dashboards
- Saved Table Reports, job output view designer, CSV/JSON/XLSX/SQL export and optional ClickHouse synchronization
- External Execution API with status/results, callbacks and rate limits
- Slack and Telegram notification delivery
- Enterprise support — help with deployment and operating Dagychu in production
Start with Community. Move to Enterprise when Dagychu becomes infrastructure your organization depends on.
Practical evaluation guides
Run the workflow. Understand the tradeoffs.
Architecture, recovery and tool selection for production jobs.
How to Run, Monitor, and Recover Production Python Jobs
A practical operating model for recurring Python and Bash jobs: schedules, execution state, logs, outputs, retries and safe recovery on your own infrastructure.
Read the guideCelery Runs the Task. What Operates the Workflow?
A decision guide for teams using Celery, Kubernetes Jobs or internal workers: when to keep the current system and when to evaluate Dagychu for a separate workflow.
Read the guideDagychu vs Apache Airflow for Python Jobs and Operational Workflows
Compare workload fit, workflow definition, recovery and deployment. Dagychu is an alternative to evaluate for some Python and Bash jobs, not a universal Airflow replacement.
Read the guideContact
Talk to Raideria about Dagychu.
Questions about Community, Enterprise, or how Dagychu fits your execution architecture — email us.