Auto-update¶

DUMB includes a comprehensive auto-update system that keeps your services current with the latest releases. Each service can be configured independently with different update strategies, from fully automatic updates to version pinning.

Overview¶

The auto-update system supports multiple update strategies:

How it works¶

%%{ init: { "flowchart": { "curve": "basis" } } }%%
flowchart TD
    A([Service startup])
    B{Auto-update enabled?}
    C[Check for updates]
    D([Start service])
    E{Update available?}
    F{Scheduled action?}
    L[Show pending update on dashboard]
    M[Download and verify update]
    N[Build and verify candidate]
    G[Stop service]
    H[Atomically activate or apply update]
    I([Start and stabilize service])
    R{Healthy?}
    S[Commit replacement]
    T[Restore previous runtime]
    J[Schedule next check]
    K[Wait for interval]

    A ==> B
    B -- No --> D
    B -- Yes --> C
    C ==> E
    E -- No --> D
    E -- Yes --> F
    F -- Check only --> L
    L ==> J
    F -- Install automatically --> M
    M ==> N
    N ==> G
    G ==> H
    H ==> I
    I ==> R
    R -- Yes --> S
    R -- No --> T
    S ==> J
    T ==> J
    J ==> K
    K ==> C

Update lifecycle¶

1. Initial check - When a service starts, DUMB checks for available updates
2. Version comparison - Current version is compared with the latest available
3. Act - In check_only mode, DUMB leaves the service untouched and records the pending update; in install mode, it downloads and applies the update
4. Dashboard - Pending check-only results appear in the dashboard Updates badge, service card, and Updates panel
5. Notify - Configured DUMB notifications can emit the update.available event, while project update notices cover DUMB backend/frontend updates
6. Schedule - Future update checks are scheduled based on the configured interval

Downloads, package-manager inputs, and supported compiled runtimes are reused through the verified install cache. A failed build retains or restores the previous runtime instead of accepting partial output. Services with candidate-native layouts are not stopped until their replacement has finished building.

The DUMB Frontend uses this candidate-first lifecycle for release, branch, commit, and configured-target installs. Its current Nuxt server remains online during download and build, then DUMB stops it only long enough to atomically activate and health-check the replacement. If activation fails, DUMB restores and verifies the prior frontend. When an operator starts the update from the dashboard itself, the loaded page reconnects through the restarted frontend, reads the terminal result retained by the DUMB API, and reloads to use the new assets. A temporary request disconnect is therefore shown as reconnection and verification, not immediately as a failed install.

Manual dashboard installs and scheduled update installs record total install duration plus observed service downtime. Total duration covers the complete installer and health-stabilization operation. Downtime covers only intervals from stopping the managed process until its application readiness probe first succeeds, including an additional interruption if a candidate regresses and rollback is required. A result distinguishes completed, ongoing/unverified, and not-observed downtime instead of assuming that every update caused an outage. Current dmbdb versions show these values in both the dashboard Updates panel and each service's Updates panel when the backend advertises update_timing_metrics.

When an update affects storage used by Plex, Jellyfin, or Emby, Media Library Protection runs before the service is stopped. Scheduled updates are deferred while playback is active or activity cannot be verified. Manual installs show explicit protect, keep-running, stop-now, and defer choices in dmbdb.

Frontend notices¶

The DUMB Frontend polls GET /api/process/update-notices for project-level update notices. DUMB retains the last terminal DUMB API and DUMB Frontend update state, plus applied and informational notices, in /config/update_notices.json. Available-update notices therefore survive an API restart and do not depend on the browser that happened to perform the check. If a later GitHub check temporarily fails, DUMB keeps showing the last known available update and marks the recheck failure instead of silently removing the notice.

The global DUMB Updates banner and review dialog show the current and available API/frontend versions. The Settings About rows reuse the same backend-retained state and open the same dialog. For ordinary published releases, they also show how many releases the installed version is behind when the current tag can be found in GitHub's bounded release history. Branch builds, rolling dev builds, and very old or missing tags may omit the count rather than guess.

DUMB API release checks are always enabled: the backend checks once during startup and then daily in check-only mode. This does not opt the deployment into automatic container replacement or API self-installation. Applying an API update remains an operator-owned image/stack update. DUMB Frontend checking and installation continue to follow its normal manual and configured auto-update controls.

DUMB dev images use rolling versions such as v2.4.2-dev.5. These are treated as dev builds, not production release tags, so their notice action points to the rolling dev-build reference instead of a per-version release page. Production semver releases still link to their release notes, and branch builds with commit markers link to the relevant commit or comparison.

Dismissals are stored in browser local storage and only hide the global banner for that browser. They do not remove the backend's retained available state or applied-update history. The About page continues to show the retained status, and its review dialog can restore a dismissed banner; a different browser can also still review the notice.

Configuration¶

Auto-update settings are configured per-service in dumb_config.json:

{
  "service_name": {
    "enabled": true,
    "auto_update": true,
    "auto_update_mode": "check_only",
    "auto_update_start_time": "04:00",
    "auto_update_interval": 24,
    "release_version_enabled": false,
    "release_version": "latest",
    "commit_sha": "",
    "branch_enabled": false,
    "branch": "main",
    "pinned_version": "",
    "clear_on_update": true,
    "exclude_dirs": []
  }
}

Configuration options¶

After saving a fixed release, branch, or commit selection, the Updates panel shows Install configured release, Install configured branch, or Install configured commit without requiring a successful update check. Check for updates remains useful for resolving the exact current branch head and refreshing displayed version details. Applying the configured target keeps the saved selection active. Override + latest is a separate escape hatch that temporarily bypasses any saved release, branch, commit, or pinned-version selection and installs the latest stable release. DUMB restores the saved configuration after that one installation.

Check only and review on the dashboard¶

Set auto_update to true and auto_update_mode to check_only when you want DUMB to check on schedule without stopping, restarting, or changing the service. When a newer ordinary release is found, the dashboard Updates button shows a count, the service card exposes its update shortcut, and the Updates panel includes the current and available versions. You can then install one update or select several for sequential installation.

The dashboard refreshes the cached results while it remains open. A later scheduled or manual check clears the pending state when the service is current. Existing configurations that do not contain auto_update_mode retain the legacy install behavior.

Update strategies¶

Latest release (default)¶

The default strategy fetches the latest stable release from GitHub:

{
  "frontend": {
    "auto_update": true,
    "auto_update_mode": "install",
    "auto_update_start_time": "04:00",
    "auto_update_interval": 24
  }
}

This checks GitHub's /releases/latest endpoint and downloads the newest stable version.

Nightly builds¶

For testing cutting-edge features, enable nightly builds:

{
  "service_name": {
    "release_version_enabled": true,
    "release_version": "nightly"
  }
}

Prerelease versions¶

To receive beta or release candidate versions:

{
  "service_name": {
    "release_version_enabled": true,
    "release_version": "prerelease"
  }
}

Branch-based deployment¶

Track a specific Git branch for development or testing:

{
  "service_name": {
    "branch_enabled": true,
    "branch": "dev"
  }
}

Exact commit pinning¶

Source-build services can be pinned to an immutable GitHub revision:

{
  "infinidysk": {
    "commit_sha": "0123456789abcdef0123456789abcdef01234567"
  }
}

commit_sha must be the complete 40-character hexadecimal SHA. When non-empty, it takes precedence over release and branch settings. DUMB downloads that exact GitHub source archive, builds it through the service's normal source-build path, records a commit-<short-sha> version marker where supported, and disables automatic updates until the field is changed or cleared. This block applies to scheduled checks, the initial post-setup check, and normal direct update checks. When the configured commit differs from the installed version, use Install configured commit to build and restart on that SHA without clearing or bypassing the pin. Override + latest is a separate explicit action that temporarily bypasses the pin and installs the moving latest release; it does not clear the saved SHA. If source settings are saved while an update is already running, DUMB preserves the newer saved selection rather than restoring the update operation's older selection over it.

Supported source-build services are:

• DUMB Frontend
• Traefik Proxy Admin
• CLI Debrid
• Decypharr
• InfiniDysk
• Phalanx DB
• Tautulli
• Pulsarr
• Maintainerr
• NeutArr
• Profilarr
• Seerr
• Riven Backend and Riven Frontend
• Zilean

Arr applications and binary-only services such as Zurg do not use this source commit strategy.

Version pinning¶

Lock a service to a specific version:

{
  "service_name": {
    "pinned_version": "v1.30.0"
  }
}

Update intervals¶

The auto_update_start_time and auto_update_interval settings control update cadence:

{
  "frontend": {
    "auto_update": true,
    "auto_update_start_time": "04:00",
    "auto_update_interval": 24
  }
}

With this example, checks run once per day at 04:00. If you set auto_update_interval to another value (for example 12), checks run every 12 hours anchored from the configured start time.

Preserving data during updates¶

Clear on update¶

By default, DUMB clears the service directory before applying updates. This ensures a clean installation:

{
  "service_name": {
    "clear_on_update": true
  }
}

Excluding directories¶

To preserve specific directories during updates (like configuration or data):

{
  "service_name": {
    "clear_on_update": true,
    "exclude_dirs": ["config", "data", "logs"]
  }
}

GitHub API integration¶

Rate limiting¶

GitHub's API has rate limits:

Using a GitHub token¶

For higher rate limits, add a GitHub token to your configuration:

{
  "dumb": {
    "github_token": "ghp_xxxxxxxxxxxxxxxxxxxx"
  }
}

Service-specific behavior¶

Different services have specialized update handling:

Monitoring updates¶

Dashboard update center¶

The dashboard Updates button provides an on-demand alternative to enabling automatic updates. It checks all enabled update-capable services sequentially, shows the services with available versions, and lets you install some or all of those ordinary updates. Each service card also gains an Update shortcut while an ordinary update is recorded as available.

Bulk installation is deliberately conservative: saved release, branch, commit, and pinned-version selections appear as Review source and cannot be selected. Use the individual service page when you need Install configured target or Override + latest. Selected services install one at a time and restart as needed; the frontend and API are placed last to reduce control-plane interruption. If the selection includes DUMB Frontend, its replacement is prepared while the old UI stays online. The bulk runner resumes after the brief activation restart and reloads the dashboard only after the remaining selected updates have been processed.

The individual service Updates panel also retains active check/install state if you close it or navigate to another service page. A background-progress banner reopens the operation, and returning to the service shows the same live progress or completed result.

See Dashboard for the complete workflow.

Check current versions¶

View installed versions in the frontend:

1. Navigate to Settings
2. Check the Version display for each service

Update logs¶

Update activity is logged to the DUMB logs:

INFO - [Auto-Update] Checking for updates: frontend
INFO - [Auto-Update] Update available: v1.32.0 -> v1.33.0
INFO - [Auto-Update] Downloading update...
INFO - [Auto-Update] Update complete: frontend v1.33.0

Troubleshooting¶

Updates not running¶

1. Verify auto_update is enabled in the service configuration
2. Check the interval - updates may not be due yet
3. Review logs for error messages
4. Verify network connectivity to GitHub

Update fails repeatedly¶

1. Check GitHub API rate limits - add a token if needed
2. Verify disk space is available
3. Check file permissions in the service directory
4. Review logs for specific error messages

Service won't start after update¶

1. Check compatibility between the new version and your configuration
2. Review the service's changelog for breaking changes
3. Consider pinning to the previous working version
4. Check logs for startup errors

Best practices¶

Related pages¶

• Configuration Guide
• Auto-restart
• Settings Page