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:
| Strategy | Description | Use Case |
|---|---|---|
| Latest Release | Tracks the latest stable GitHub release with scheduled checks | Production environments |
| Nightly Builds | Tracks nightly GitHub releases with scheduled checks | Testing new features |
| Prerelease | Tracks prerelease GitHub builds with scheduled checks | Beta testing |
| Branch-based | Downloads directly from a Git branch on setup/startup | Development |
| Version Pinning | Locks to a specific version without scheduled updates | Stability critical |
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[Download update]
G[Stop service]
H[Apply update]
I([Start service])
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 ==> G
G ==> H
H ==> I
I ==> J
J ==> K
K ==> C
Update lifecycle¶
- Initial check - When a service starts, DUMB checks for available updates
- Version comparison - Current version is compared with the latest available
- Download - If an update is available, the new version is downloaded
- Apply - The service is stopped, updated, and restarted
- Schedule - Future update checks are scheduled based on the configured interval
Configuration¶
Auto-update settings are configured per-service in dumb_config.json:
{
"service_name": {
"enabled": true,
"auto_update": true,
"auto_update_start_time": "04:00",
"auto_update_interval": 24,
"release_version_enabled": false,
"release_version": "latest",
"branch_enabled": false,
"branch": "main",
"pinned_version": "",
"clear_on_update": true,
"exclude_dirs": []
}
}
Configuration options¶
| Option | Type | Default | Description |
|---|---|---|---|
auto_update |
boolean | false |
Enable automatic updates for this service |
auto_update_start_time |
string | "04:00" |
24-hour schedule anchor time (HH:MM) |
auto_update_interval |
number | 24 |
Hours between update checks |
release_version_enabled |
boolean | false |
Use release version strategy |
release_version |
string | "latest" |
Target version: latest, nightly, prerelease, or specific version |
branch_enabled |
boolean | false |
Use branch-based deployment |
branch |
string | "main" |
Git branch to track |
pinned_version |
string | "" |
Pin to specific version (disables auto-update) |
clear_on_update |
boolean | true |
Clear working directory before update |
exclude_dirs |
array | [] |
Directories to preserve during updates |
Auto-update and strategy interaction
Automatic scheduling is disabled when pinned_version, release_version_enabled, or branch_enabled are set.
The only exception is when release_version is nightly or prerelease, which keeps scheduled checks enabled.
Update strategies¶
Latest release (default)¶
The default strategy fetches the latest stable release from GitHub:
{
"frontend": {
"auto_update": true,
"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"
}
}
Nightly version format
Nightly builds use date-based versioning like v2025.01.22.nightly. Version comparison checks the first three parts (year, month, day).
Prerelease versions¶
To receive beta or release candidate versions:
{
"service_name": {
"release_version_enabled": true,
"release_version": "prerelease"
}
}
Prerelease scheduling
When release_version is prerelease, scheduled auto-update checks continue to run at your configured interval.
Branch-based deployment¶
Track a specific Git branch for development or testing:
{
"service_name": {
"branch_enabled": true,
"branch": "dev"
}
}
Branch-based updates
Branch-based deployment downloads the latest commit from the specified branch during setup/startup.
Scheduled auto-update checks are disabled when branch_enabled is true.
Version pinning¶
Lock a service to a specific version:
{
"service_name": {
"pinned_version": "v1.30.0"
}
}
When to pin versions
Pin versions when:
- A specific version is required for compatibility
- You need to prevent unexpected changes
- Testing a specific release
- Production stability is critical
Pinned versions and auto-update
Setting pinned_version disables scheduled updates for that service.
Update intervals¶
The auto_update_start_time and auto_update_interval settings control update cadence:
| Interval | Check Frequency | Recommended For |
|---|---|---|
6 |
Every 6 hours | Nightly/prerelease testing |
24 |
Daily (default) | Most services |
168 |
Weekly | Stable, critical services |
{
"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:
| Authentication | Requests per Hour |
|---|---|
| Unauthenticated | 60 |
| With token | 5,000 |
Using a GitHub token¶
For higher rate limits, add a GitHub token to your configuration:
{
"dumb": {
"github_token": "ghp_xxxxxxxxxxxxxxxxxxxx"
}
}
Token permissions
The GitHub token only needs public_repo read access for checking releases.
Protect your token
Treat GitHub tokens as secrets. Never commit them to source control or share them in logs/screenshots.
Service-specific behavior¶
Different services have specialized update handling:
| Service Type | Update Method |
|---|---|
| Arr Suite (Sonarr, Radarr, etc.) | Binary installation |
| Plex Media Server | System package installer |
| Jellyfin | System package installer |
| Emby | System package installer |
| GitHub-based (Frontend, NeutArr, etc.) | Release download and extraction |
Strategy support varies
Not every service supports every strategy. For example, Arr services and Plex/Jellyfin/Emby use native installers, while GitHub-based services rely on release or branch downloads.
Monitoring updates¶
Check current versions¶
View installed versions in the frontend:
- Navigate to Settings
- 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¶
- Verify auto_update is enabled in the service configuration
- Check the interval - updates may not be due yet
- Review logs for error messages
- Verify network connectivity to GitHub
Update fails repeatedly¶
- Check GitHub API rate limits - add a token if needed
- Verify disk space is available
- Check file permissions in the service directory
- Review logs for specific error messages
Service won't start after update¶
- Check compatibility between the new version and your configuration
- Review the service's changelog for breaking changes
- Consider pinning to the previous working version
- Check logs for startup errors
Best practices¶
Recommendations
- Test updates in a non-production environment first
- Use version pinning for critical services
- Set appropriate intervals based on service stability needs
- Monitor logs after updates for any issues
- Keep backups of configuration files
- Add a GitHub token to avoid rate limiting