v5.0.1

v5.0.1 — "TemperMatters"

A stability + polish release that tempers v5.0.0. No breaking changes — every change is a bug fix or a quality-of-life improvement, and existing installs keep working unchanged. Hard-reload the dashboard once after upgrading (the service worker cache is remotepower-shell-v5.0.1).

Backend-correctness sweep (SQLite / PostgreSQL)

v5.0.0 shipped on a JSON-file backend by default, but installs running the optional SQLite or PostgreSQL backend hit a class of bugs where a feature guarded its data read with Path.exists(). On a database backend the .json files never exist on disk — the data lives in a table — so those guards always saw "no data" and the feature silently did nothing. This is the same root cause as the v5.0.0 backup-runaway fix; v5.0.1 sweeps the remaining read paths to the backend-aware backend_exists() check:

• SSH-key drift audit — the per-device host-config read that feeds the new-key / changed-key audit ran on every heartbeat but read empty under a DB backend, so the audit never fired. Fixed.
• Proxmox stale-snapshot alerts — the Needs-Attention scan for old Proxmox snapshots read an empty cache under a DB backend and never raised. Fixed.
• Host-config "current state" view + export — the device drawer's current host-config tab and the fleet host-config export read empty under a DB backend. Fixed.
• Deleting a device now also clears its host-config row on a DB backend (no orphaned state).

Quieter alerts (especially during upgrades)

• Duplicate alerts coalesce. A repeat firing of the same condition (same event, same device/target) now folds into the existing open alert — refreshing its timestamp and bumping an occurrence count — instead of stacking a second identical row. Previously, anything that reset a flap-dampening flag (such as a server restart during an upgrade) could leave two identical open alerts that had to be resolved separately. Recovery still auto-resolves the single open alert cleanly.
• Agent stop/start is quiet by default. Every server or agent upgrade restarts the agent, which used to raise an alert + webhook + Needs-Attention card for each host. agent_stopped / agent_started are now off on the alerts, webhook and needs-attention channels by default — they remain in Recent Activity as an audit trail, and you can re-enable any channel under Settings → Notifications.

Edit in place — API keys & custom checks

• API keys gained an Edit button. You can now change a key's name, role, expiry and rate limit in place — the key secret is never touched, so consumers keep working. Previously the only way to change a key was delete + regenerate, which minted a new secret and broke every script using the old one.
• Custom checks gained an Edit button (the modal and update-by-id backend already existed — now there's a front-door for it).

Operations

• Backups survive redeploys. RP_BACKUP_PASSPHRASE (and other server secrets like SMTP/LDAP passwords) now load from /etc/remotepower/api.env via the API unit's EnvironmentFile=. Put secrets there — not as an inline Environment= line in the unit, which deploy-server.sh / install-server.sh overwrite on every update (silently dropping backup encryption on the next upgrade).
• Turnkey self-update script. A ready-made, install-aware update script ships at packaging/remotepower-server-update.sh for the Settings → Install → "Run update now" button. It auto-detects the install type (git checkout, pacman/AUR, or apt), pulls the new version and restarts the SCGI worker. Because the API runs unprivileged, it re-execs itself under a scoped, passwordless sudo; its header has the two install commands. See upgrading.

Upgrading

Drop-in. Pull the new version (or use the self-update script above), restart the service, and hard-reload the dashboard once. No data migration is required; the storage layout is unchanged from v5.0.0.