Upgrades

This page is the procedure for upgrading a production server. Self-Upgrade describes the dagu upgrade command itself.

Only the latest stable release series receives fixes. See the support policy.

Before you upgrade

1. Read the release notes for every version between yours and the target: https://github.com/dagucloud/dagu/releases
2. Back up configuration, DAGs, and the data directory.
3. Install the target version on a staging server first if your workflows are critical. See Multi-Environment Deployments.

Single server

dagu upgrade --version v2.26.0
sudo systemctl restart dagu
dagu version

Without internet access, replace the binary by hand as described in Closed Networks.

Runs in progress end when the service restarts unless its process manager leaves them running. Restart when no critical run is in progress, or set KillMode=process as in High Availability.

Active and standby pair

Upgrade the standby first. The upgraded instance then takes over once, and an older version never takes over from a newer one.

1. Find the standby:

   curl -s http://host-a:8090/health
   curl -s http://host-b:8090/health

2. On the standby host, stop Dagu, replace the binary, and start it. It comes back as a standby:

   sudo systemctl stop dagu-scheduler dagu-server
   # install the new binary at /usr/local/bin/dagu
   sudo systemctl start dagu-scheduler dagu-server

3. On the active host, do the same. The scheduler releases the lock when it stops, so the upgraded standby becomes active within scheduler.lock_retry_interval, plus startup.

4. Confirm that every host reports the new version, and that exactly one is active:

   dagu version
   curl -s -o /dev/null -w '%{http_code}\n' 'http://host-a:8090/health?role=active'
   curl -s -o /dev/null -w '%{http_code}\n' 'http://host-b:8090/health?role=active'

Upgrading from 2.26.0 or earlier

Later releases change how the scheduler behaves in four ways:

• Run IDs of cron slots have a new format. The new version cannot recognize a run the old version started, so a slot that ran in the same minute as the handover can run again. Hand over in a minute with no schedule due.
• The data directory must have the same path on every host, because it is now part of each slot's run ID.
• A scheduler that loses the lock exits with status 1, not 0. It needs a supervisor that restarts it.
• Stopping the scheduler no longer stops runs it started from a queue. scheduler.failover_recovery_window is new and on by default, at 2 minutes.

Kubernetes

See Kubernetes. A new chart version can change the default image, so read its appVersion first:

helm repo update
helm show chart dagu/dagu | grep -E '^(version|appVersion):'

Roll back

Dagu does not promise that an older version can read state written by a newer one, and downgrades are not tested. To roll back:

1. Stop Dagu on every host.
2. Restore the backup taken before the upgrade.
3. Install the previous binary and start Dagu.

Runs made since the backup are lost from the history.