Overview
The Dagu dashboard timeline
The Dagu web UI dashboard showing recent workflow runs across all DAGs on a timeline, served in the browser behind nginx with a per-instance admin login.
The Dagu dashboard timeline
The workflows list
The run graph and step detail
The run history view
This is a repackaged open source software product wherein additional charges apply for cloudimg support services.
Overview
Dagu is a self-contained workflow and cron orchestration engine. You describe your work as a DAG, a directed acyclic graph of steps, in a single readable YAML file, and Dagu runs it on demand or on a schedule, handling dependencies between steps, retries, timeouts, preconditions and lifecycle hooks. A built-in web UI lets you browse workflows, start and stop runs, watch each step of a run graph in real time, inspect per-run logs and browse execution history, while a REST API and a full command line interface drive the same engine from scripts and automation.
Why This Image vs a Manual Install
Unlike heavyweight schedulers, Dagu needs no database, no message broker and no complex runtime. It ships as a single self-contained binary and keeps all of its state on the local filesystem, so it starts instantly and stays lightweight. This image eliminates the manual binary download and verification, systemd unit authoring, reverse-proxy configuration and credential hardening that a manual install requires. What normally takes several steps across download, service configuration and security hardening is completed for you at image build time. Launch the instance, read your unique credential, and start defining workflows. An example workflow is included so the engine has something to run on first boot.
Application Stack
A single dagu start-all process runs the HTTP server, scheduler and executor together as a dedicated unprivileged system user under a hardened systemd unit, bound to the loopback interface only and fronted by an nginx reverse proxy on port 80. systemd starts the daemon and the web server on boot and restarts them on failure. The workflow definitions, run logs and execution history live on a dedicated data volume, independently resizable and separate from the OS disk.
Security Hardening
This image follows a defence-in-depth approach:
- Network isolation: Dagu binds exclusively to the loopback interface; only the nginx reverse proxy is exposed
- Authentication enforced: the full web UI and REST API sit behind an nginx HTTP Basic Auth gate; only an unauthenticated health endpoint is served anonymously
- No default or shared credentials: a cryptographically random administrator password is generated on each instance's first boot and written only to a root-only file
- Least privilege: the engine runs as an unprivileged system user with NoNewPrivileges, PrivateTmp, ProtectHome and ProtectSystem set
- Dedicated data volume: workflow definitions, logs and run history live on their own disk, surviving OS-disk changes and resizable independently
- Automatic restart: systemd monitors both Dagu and nginx and restarts them on failure
Buyers requiring formal compliance documentation should contact cloudimg to discuss specific requirements.
Concrete Use Cases
- Cron replacement and internal automation: Replace a sprawl of crontab entries with declarative YAML DAGs that carry dependencies, retries and a UI showing exactly which step failed and why
- Data pipelines and batch jobs: Orchestrate nightly extract-transform-load runs, database backups and report generation on a single machine, with cron scheduling, timezone support and per-run logs
- Edge and single-node automation: Run dependable scheduled automation on an edge or IoT host where a full distributed scheduler would be overkill, with all state on the local filesystem and nothing external to manage
AWS Integration
Deploy on any EC2 instance type. Use the unauthenticated health endpoint with an Application Load Balancer for availability monitoring. Back up your workflow definitions and run history using EBS snapshots or AWS Backup. Resize the dedicated data volume independently of the OS disk as your run history grows.
Getting Started
Read your credential from the root-only file, open the web interface in your browser, sign in as admin, and browse the included example workflow. Define your own workflows as YAML DAGs under the data directory, run and monitor them from the UI or the command line, and schedule them with cron expressions. To verify the deployment, launch the instance and run the included example workflow to confirm the full stack is working before building your own.
Resources
cloudimg provides a step-by-step user guide for this image at https://www.cloudimg.co.uk/guides/dagu-aws/ , covering credential retrieval, signing in, defining your first DAG and scheduling. Two example workflows - a hello DAG and an ETL-style pipeline - ship in the image under the data directory so the engine works out of the box.
cloudimg Support
24/7 technical support by email and chat. Help with deployment, reverse-proxy termination with your own domain and certificate, workflow and schedule configuration, and backup planning for your workflow store.
Highlights
- Launch a fully working orchestration UI without editing a single configuration file. This image completes every build and hardening step at image creation time - binary download and verification, systemd unit authoring, reverse-proxy setup and credential generation are all done for you. Start defining and running YAML workflows immediately after reading your unique admin credential.
- Secure by default with no shared passwords. Dagu binds exclusively to the loopback interface behind an nginx HTTP Basic Auth gate. Every instance generates its own cryptographically random admin password on first boot, written only to a root-only file. No default password is baked into the image, and the engine runs as an unprivileged user with systemd sandboxing (NoNewPrivileges, PrivateTmp, ProtectHome, ProtectSystem).
- Lightweight single-binary engine with dedicated storage and 24/7 support. No database or message broker required - all state lives on the local filesystem. Workflow definitions, logs and run history reside on a dedicated independently resizable EBS data volume. Define DAGs in readable YAML with dependencies, retries, timeouts and cron schedules, then monitor them from a live web UI, REST API or CLI. Backed by 24/7 cloudimg email and chat support.
Details
Introducing multi-product solutions
You can now purchase comprehensive solutions tailored to use cases and industries.
Features and programs
Financing for AWS Marketplace purchases
Pricing
Free trial
- ...
Dimension | Description | Cost/hour |
|---|---|---|
m5.large Recommended | m5.large | $0.08 |
t2.micro | t2.micro instance type | $0.04 |
t3.micro | t3.micro instance type | $0.04 |
c5a.12xlarge | c5a.12xlarge instance type | $0.24 |
c5a.16xlarge | c5a.16xlarge instance type | $0.24 |
c5a.24xlarge | c5a.24xlarge instance type | $0.24 |
c5a.2xlarge | c5a.2xlarge instance type | $0.24 |
c5a.4xlarge | c5a.4xlarge instance type | $0.24 |
c5a.8xlarge | c5a.8xlarge instance type | $0.24 |
c5a.large | c5a.large instance type | $0.08 |
Vendor refund policy
Refunds available on request.
How can we make this page better?
Legal
Vendor terms and conditions
Content disclaimer
Delivery details
64-bit (x86) Amazon Machine Image (AMI)
Amazon Machine Image (AMI)
An AMI is a virtual image that provides the information required to launch an instance. Amazon EC2 (Elastic Compute Cloud) instances are virtual servers on which you can run your applications and workloads, offering varying combinations of CPU, memory, storage, and networking resources. You can launch as many instances from as many different AMIs as you need.
Version release notes
Initial release of Dagu as a ready-to-use self-hosted workflow and cron orchestration engine, running as a single Go binary behind an nginx reverse proxy, secured with a unique admin credential generated on each instance's first boot and a dedicated data volume for workflow definitions, logs and run history.
Additional details
Usage instructions
Connect via SSH on port 22 as the default login user for your operating system variant (for the Ubuntu 24.04 variant the user is ubuntu). Read the per-instance admin credential with: sudo cat /root/dagu-credentials.txt. Open the web interface in a browser at http://<instance-public-ip>/ and sign in with the admin username and password from that file. An unauthenticated health endpoint is available at http://<instance-public-ip>/healthz. Workflow definitions live under /var/lib/dagu/dags on the dedicated data volume; edit them in YAML and run them from the UI or with sudo -u dagu env DAGU_HOME=/var/lib/dagu dagu start <dag>.yaml. The instance security group opens ports 22 and 80. The services run under systemd: systemctl status dagu nginx.
Resources
Vendor resources
Support
Vendor support
cloudimg Support
cloudimg provides 24/7 technical support for this product by email and live chat.
Contact: support@cloudimg.co.uk
What we help with:
- Deployment and initial configuration
- Reverse-proxy termination with your own domain and TLS certificate
- Workflow and schedule configuration and troubleshooting
- Backup planning for your workflow store using EBS snapshots or AWS Backup
- Performance tuning and troubleshooting
- Updates and security patching guidance
Refunds: For refund requests, contact support@cloudimg.co.uk with your AWS account ID and subscription details.
AWS infrastructure support
AWS Support is a one-on-one, fast-response support channel that is staffed 24x7x365 with experienced and technical support engineers. The service helps customers of all sizes and technical abilities to successfully utilize the products and features provided by Amazon Web Services.