JP1/AJS3 alternative
Batch scheduling without a manager server, a per-node agent, or a per-node licence.
Dagu is a JP1/AJS3 alternative for corporate IT teams that already run batch jobs on their own servers. Jobnets become YAML in git, the manager database disappears, and the operator console is a browser. This page also covers the migration path and the places Dagu is the weaker choice.
# nightly-closing.yaml
schedule: "0 2 * * *"
# Business-day calendar
preconditions:
- eval: "$(date +%u)"
expected: "re:[1-5]"
# Run on the business server without a resident agent
ssh:
user: batch
host: app01.corp.local
key: ~/.ssh/batch_key
steps:
- id: closing
run: /opt/batch/run-closing.sh
retry_policy:
limit: 2
interval_sec: 300
- id: transfer
run: /opt/batch/send-to-core.sh
depends: [closing]
# Recovery job
handler_on:
failure:
run: /opt/batch/recovery.sh
mail_on:
failure: true
Execution order
One binary, no manager database to operate
Licensed per Dagu server, with unlimited workers
Jobnets as reviewable YAML in version control
Runs on-premises and inside closed networks
At a glance
JP1/AJS3 vs. Dagu for corporate batch
One binary with file-backed state; queues and workers are optional.
Manager, per-node agents, and a foundation product with its own database.
Declarative YAML reviewed in git.
GUI-authored definitions, with text export and import as a secondary path.
Browser UI and a CLI, reachable from any OS.
Dedicated operator client installed per user.
Free for unlimited servers; paid plans licensed per Dagu server with unlimited workers.
Licensed per node, with an annual maintenance contract.
Single scheduler instance; HA is a deployment design you own.
Established cluster and standby configurations.
Community Discord, or email support on paid plans.
Vendor maintenance contract with local-language support.
In depth
Where each tool fits
Keep the jobnet, drop the operating cost
JP1/AJS3 splits into a manager, an agent on every executing node, and a dedicated operator client. Dagu keeps the same scheduling concepts inside a single process that stores its state in files.
- Jobnets become DAGs, jobs become steps, and predecessor links become depends.
- Recovery jobs map to handler_on.failure. Reruns use dagu retry for the same run ID or dagu restart for a new one, and a DAG's schedule can be suspended from the UI.
- No manager database to size, back up, or patch alongside the scheduler.
Migrate one jobnet group, not the whole estate
There is no automatic importer, and any vendor promising a one-click conversion of a decade-old estate is overselling. The realistic path is a scripted conversion validated against a pilot.
- Export the unit definitions you already have as text, then map them mechanically: unit to step, predecessor link to depends, recovery unit to handler_on.failure.
- Because the target is plain YAML, the conversion is a script you own and rerun, not a manual re-entry project.
- Run dagu validate on every generated file, then run the pilot group in parallel with the incumbent before cutting over.
Reach existing servers without installing an agent
Batch work usually lives on servers that already exist. Dagu can drive them over SSH, or run a worker process where a persistent executor is the better fit.
- Use the SSH executor to run commands on Linux and UNIX hosts with no resident agent.
- Deploy coordinator and workers when jobs must run inside segmented networks.
- Match steps to labelled workers with worker_selector instead of licensing every node.
Separate the operators from the authors
Corporate IT needs the people who rerun a failed job to be a different set from the people who change its definition. Roles, SSO, and audit logging are part of the licensed self-host tier.
- The operator role can start and stop runs but cannot edit definitions; viewer is read-only; developer and manager can change workflows.
- Sign in through your existing identity provider with OIDC rather than maintaining a second user directory.
- Audit logging records administrative and security-relevant activity for review.
A cost structure without per-node licensing
Community self-host is free forever with unlimited servers and workers. The licensed tier is priced per Dagu server, not per executing node, and workers stay unlimited on every plan.
- Community covers the full orchestration engine, web UI, cron scheduling, and the Docker, SSH, and HTTP executors.
- Licensed self-host starts at $500 per year for three server licenses and adds SSO, RBAC, audit logging, incident routing, and email support.
- Adding an executing host means starting another worker, which changes no licence count.
Where Dagu is the weaker choice
A comparison that only lists wins is not useful during an evaluation. These are the places a JP1 shop should expect to do extra work or stay put.
- The scheduler runs as a single instance. There is no built-in leader election, so an HA design is yours to build around process supervision and shared storage.
- Support is a Discord community on the free tier and standard email support on paid plans. There is no equivalent to a Japanese-language 24/365 vendor maintenance contract.
- JP1 is a suite. If you also depend on it for monitoring, asset management, or integrated operations across the estate, Dagu replaces only the scheduling piece.
FAQ
Practical questions before adopting Dagu
Can Dagu replace every JP1 deployment?
No. JP1 is a suite that also covers monitoring, asset management, and vendor support contracts. Dagu replaces the job scheduling part when your jobs are already scripts, binaries, containers, or service calls and you want a smaller runtime you operate yourself.
Is there a tool that converts existing definitions automatically?
No, and treat any claim otherwise with suspicion. What makes conversion tractable is that the target format is plain YAML: you export the definitions you have, write a script that emits DAG files, and check the output with dagu validate. Budget the pilot as engineering work rather than a data import.
How do calendars and business-day rules carry over?
Dagu schedules with cron expressions and gates execution with preconditions, so business-day and month-end rules are expressed as conditions on the workflow or on individual steps. A calendar that lives in an external system can be queried from a step and used as a precondition.
What replaces a start condition that waits for a file?
Two mechanisms cover most cases. A step can use the wait actions to poll for a file to appear or an HTTP endpoint to become ready before the rest of the workflow proceeds, and a run can be triggered externally through a webhook with the payload available to the workflow.
How does it handle concurrency limits?
DAGs without a named queue allow one active run by default. Use max_active_steps to cap parallel steps inside a run, or assign workflows to a named queue with max_concurrency when jobs must share a limit.
Does it work in a closed network?
Yes. Dagu is a self-contained binary with no required external database or broker, so it runs on-premises and in networks without internet access. Distributed execution uses a coordinator and workers over gRPC inside your own network.
Next step
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.