Self-hosting: opt-in setting to keep an instance updated automatically

(#1457) Feature Under consideration self-hosting

Current problem

I run a self-hosted instance set up with install.sh and want it to stay current without manual work. Today the only way is to run install.sh --update on a schedule, which has some drawbacks:
  • Every --update runs the full procedure (DB dump, uploads copy with the stack stopped, pull, recreate), even when nothing changed. A nightly cron job means downtime and a new backup every night.
  • Every run creates a new backups/record-<timestamp> directory that is never cleaned up. Each record contains an uploads tarball, so disk usage grows without limit.
  • There is no way to check whether an update is available without running it. With the moving v1 tag only the image ID changes, and GitHub releases are per component and happen several times a day, so they are not a usable trigger.
  • There is no built-in way to get notified when an unattended update fails.

Proposed change

An official, opt-in auto-update mode for self-hosted instances. Rough idea (names are only suggestions):
  • A setting in .env, e.g. FLUXER_AUTO_UPDATE=true plus a schedule / maintenance window. install.sh sets up a systemd timer or cron entry when it is enabled.
  • install.sh --check: pull and compare image IDs and stack files with what is running, report without changing anything, and use a distinct exit code when an update is available.
  • The scheduled run only does backup + recreate when something actually changed. No change means no downtime and no new record.
  • Retention for backup records, e.g. FLUXER_BACKUP_KEEP=3.
  • Keep the previous images so --rollback keeps working.
  • Optional notification hook (webhook URL or command) for success and failure.
  • Cases that are intentionally manual today (e.g. a PostgreSQL major version change) stay manual and trigger a notification instead.

Additional information

I currently solve this with a wrapper around install.sh, attached as a reference:
  • autoupdate.sh: pulls, compares the image IDs of the stack with the state saved after the last successful update (and docker-compose.yml with main for v1/latest), and only runs install.sh --update if something changed. It refreshes install.sh before updating, keeps the last 3 records, sends ntfy pushes on failure, and has --check and --record modes.
  • crontab.example.txt: the cron entry.
One observation that might be relevant: after one update, docker compose up -d did not recreate the edge container although a newer caddy image had been pulled. The script therefore checks for containers running an older image than their tag and warns about it. I don't know the cause. autoupdate.sh cronjob.txt

Comments

Sign in with Fluxer to comment and vote.

No comments yet.