v2.4.8

Changed

• lissy93/dashy:4.7.8 moved to lissy93/dashy:4.7.10. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

What upstream changed

Read by fleet triage from the upstream release notes (or the commits between the tags) against this compose file, before the bump was applied.

Upstream changes 4.7.7 -> 4.7.8

Verdict: SAFE TO APPLY — no release notes exist for these tags, but the raw commit log shows only a localization addition and a version bump, and the image configuration is unchanged between versions.

Breaking changes

• none found in the notes

Variables

• none

Data and dependencies

• none — the commits are: feat(i18n): add Indonesian localization, the merge of that PR, and 🔖 Bump version to 4.7.8. No dependency, port, path, or database version is touched.

Before applying

• No manual steps required. Note the compose file's .env.example and x-images block still reference 4.6.7 as the example override version, which is stale/unrelated to this upgrade and not something this move requires touching.
• After pulling, bump the DASHY_IMAGE_VERSION/digest default in the compose file's x-images block from 4.7.7@sha256:45fd7ba903d64d55b4eafcdd00b0b99934d9c6fa36da019c6a2083f68dae5479 to the corresponding 4.7.8 tag and digest, since that pin is the actual mechanism controlling what gets deployed.

Notes read

• No GitHub Release notes exist for 4.7.7 or 4.7.8 under Lissy93/dashy. Read instead: the compare-API commit list between the two tags (3 commits, quoted above in full). No UPGRADING, BREAKING_CHANGES, or CHANGELOG file was supplied for this range — none could be checked.

Upstream changes 4.7.8 -> 4.7.10

Verdict: SAFE TO APPLY — no companion service versions are named, no breaking changes are recorded, and the image configurations do not differ in any behaviour-relevant field.

Breaking changes

• none found in the notes

Variables

• none. No renamed, removed, or newly-required variables are mentioned in the commit list, and the compose file / .env.example are unaffected.

Data and dependencies

• none. The commits are dependency bumps (CodeMirror, Sentry, simple-icons, Vue, vue-i18n, eslint, autoprefixer — all frontend/build tooling) plus two new features: ✨ Adds alias functionality, to jump strait to app from URL path and ✨ Implements OpenSearch protocol for browser address bar, with a follow-up ✨ Server-side item launch alias, much faster and 🛂 Applies header auth checks to the alias load route. None of these name a database, cache, search engine, or other companion service version, and none mention migrations, removed defaults, or changed ports/paths.

Before applying

• None required by the notes. As routine practice for any host using header-based auth (traefik.http.middlewares.authtraefik... or an upstream auth proxy in front of Dashy): the commit 🛂 Applies header auth checks to the alias load route shows the new alias/launch route was retrofitted with auth checks after being merged — worth a quick manual check post-upgrade that alias links still respect your auth setup, since this is new attack surface even though the notes don't flag it as breaking.

Notes read

• Compare-API commit list between 4.7.8 and 4.7.10 under Lissy93/dashy (no dedicated GitHub Releases or CHANGELOG/UPGRADING/BREAKING_CHANGES entries exist for these tags — the 10 commits shown are the full record for this range).

v2.4.7

Changed

• lissy93/dashy:4.7.7 moved to lissy93/dashy:4.7.8. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

What upstream changed

Read by fleet triage from the upstream release notes (or the commits between the tags) against this compose file, before the bump was applied.

Upstream changes 4.7.7 -> 4.7.8

Verdict: SAFE TO APPLY — no release notes exist for these tags, but the raw commit log shows only a localization addition and a version bump, and the image configuration is unchanged between versions.

Breaking changes

• none found in the notes

Variables

• none

Data and dependencies

• none — the commits are: feat(i18n): add Indonesian localization, the merge of that PR, and 🔖 Bump version to 4.7.8. No dependency, port, path, or database version is touched.

Before applying

• No manual steps required. Note the compose file's .env.example and x-images block still reference 4.6.7 as the example override version, which is stale/unrelated to this upgrade and not something this move requires touching.
• After pulling, bump the DASHY_IMAGE_VERSION/digest default in the compose file's x-images block from 4.7.7@sha256:45fd7ba903d64d55b4eafcdd00b0b99934d9c6fa36da019c6a2083f68dae5479 to the corresponding 4.7.8 tag and digest, since that pin is the actual mechanism controlling what gets deployed.

Notes read

• No GitHub Release notes exist for 4.7.7 or 4.7.8 under Lissy93/dashy. Read instead: the compare-API commit list between the two tags (3 commits, quoted above in full). No UPGRADING, BREAKING_CHANGES, or CHANGELOG file was supplied for this range — none could be checked.

v2.4.6

Fixed

• Dashy stayed down after a host reboot. The application service had no restart policy while Traefik did, so after a reboot the proxy returned and answered for a dashboard that was not running. It now restarts on its own.

Changed

• The README's Testing section describes the workflows as they are. It still listed the freshness check inside Deployment Verification after that check moved to its own workflow.

• The freshness check has its own workflow, Pin Freshness. It ran inside Deployment Verification, whose badge is the one at the top of this README. Across the fleet, nine red runs in ten were a pin one version behind - which the fleet's triage moves within the day - and a reader cannot tell that from a stack that does not boot. The badge now says whether the stack boots. The job itself is unchanged.

• Checked daily, as the security policy already said. This template's schedule was weekly while its SECURITY.md said the pins are re-resolved daily, and nothing recorded a reason for the difference. It now runs daily like the rest of the fleet.

• lissy93/dashy:4.7.5 moved to lissy93/dashy:4.7.7. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.

  Upstream's notes for 4.7.7 carry a line worth reading twice — "Use UID/GID=1000
  instead of node as default" — and upstream added documentation for overriding
  --user because of it. Asked of the images instead of the notes, nothing
  changes for this deployment: 4.7.5 declares User=node and runs as
  uid=1000(node) gid=1000(node); 4.7.7 declares User=1000:1000 and runs as
  uid=1000(node) gid=1000(node). The same two numbers, written differently.
  The bind-mounted ./config.yml needs no chown, and this compose file sets no
  user: override. If you added one, yours is the deployment that note is about.

v2.4.5

Changed

• lissy93/dashy:4.7.4 moved to lissy93/dashy:4.7.5. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

What upstream changed

Read by fleet triage from the upstream release notes (or the commits between the tags) against this compose file, before the bump was applied.

Upstream changes 4.7.4 -> 4.7.5

Verdict: SAFE TO APPLY — the only change is a UI string fix; no breaking changes, no variable or dependency changes.

Breaking changes

• none found in the notes

Variables

• none

Data and dependencies

• none

Before applying

• No manual steps required. Standard git pull / re-deploy with the updated digest is sufficient.
• Optional: if you use the Norwegian (nb) locale, note the visible fix — "Fix {brukernavn} placeholder in Norwegian sign-in welcome (should be {username})" — you may notice the sign-in welcome text changing for that locale.

Notes read

• Compare/commit list between 4.7.4 and 4.7.5 from Lissy93/dashy (no dedicated GitHub Release notes exist for these tags; the 3 commits in the compare API were used as the record).

v2.4.4

Changed

• lissy93/dashy:4.7.3 moved to lissy93/dashy:4.7.4. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

What upstream changed

Read by fleet triage from the upstream release notes (or the commits between the tags) against this compose file, before the bump was applied.

Upstream changes 4.6.14 -> 4.7.3

Verdict: SAFE TO APPLY — commit log shows only bug fixes, a units-display fix, dependency bumps, and build/tooling changes; no breaking changes, no config/variable changes, no companion-service version bumps.

Breaking changes

• none found in the notes

Variables

• none

Data and dependencies

• none. The only version-relevant item is the Dockerfile base image: "📦 Set engines to Node LTS 22/24/26, and pin Dockerfile version" and "🐳 Dockerfile use latest version of Node 24" — this is Dashy's own internal build image, not a companion service the compose file pins separately, so it doesn't change what this repo needs to track.

Before applying

• No manual steps required. Update the digest/tag pin for lissy93/dashy in the compose file's x-images block to 4.7.3 and its corresponding sha256, matching the repo's existing pin-by-digest convention.
• Optional: verify the SABnzbd widget (if used) — "🐛 SABnzbd widget mb/s to MB/s (#2343)" changes a displayed unit label; not a config change, but worth a glance if that widget is on the dashboard.

Notes read

• Commit log from the compare API between 4.6.14 and 4.7.3 under Lissy93/dashy (20 commits). No dedicated release notes exist for these tags, and no UPGRADING/BREAKING_CHANGES/CHANGELOG document was supplied or found for this range — the commit list is the only record available.

Upstream changes 4.7.3 -> 4.7.4

Verdict: SAFE TO APPLY — the recorded commits are a docs addition and a bug fix, with no breaking changes, variable changes, or companion-service version requirements.

Breaking changes

• none found in the notes

Variables

• none

Data and dependencies

• none

Before applying

• No manual steps required beyond the normal pull/redeploy. Optionally confirm the stock price history widget (fixed in this release, per "🐛 Fixes stock price history widget") now works as expected if in use.

Notes read

• No formal release notes exist for 4.7.3 or 4.7.4 on Lissy93/dashy; read the compare-API commit list between the two tags (5 commits: Hostinger deployment docs, stock widget fix, and their merge/version-bump commits).

v2.4.3

Changed

• lissy93/dashy:4.6.14 moved to lissy93/dashy:4.7.3. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.

Security

• traefik:3.7 was rebuilt upstream; the pin moved from sha256:f86a2cab1b5c… to sha256:24841fe2de73…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

What upstream changed

Read by fleet triage from the upstream release notes (or the commits between the tags) against this compose file, before the bump was applied.

Upstream changes 4.6.14 -> 4.7.3

Verdict: SAFE TO APPLY — commit log shows only bug fixes, a units-display fix, dependency bumps, and build/tooling changes; no breaking changes, no config/variable changes, no companion-service version bumps.

Breaking changes

• none found in the notes

Variables

• none

Data and dependencies

• none. The only version-relevant item is the Dockerfile base image: "📦 Set engines to Node LTS 22/24/26, and pin Dockerfile version" and "🐳 Dockerfile use latest version of Node 24" — this is Dashy's own internal build image, not a companion service the compose file pins separately, so it doesn't change what this repo needs to track.

Before applying

• No manual steps required. Update the digest/tag pin for lissy93/dashy in the compose file's x-images block to 4.7.3 and its corresponding sha256, matching the repo's existing pin-by-digest convention.
• Optional: verify the SABnzbd widget (if used) — "🐛 SABnzbd widget mb/s to MB/s (#2343)" changes a displayed unit label; not a config change, but worth a glance if that widget is on the dashboard.

Notes read

• Commit log from the compare API between 4.6.14 and 4.7.3 under Lissy93/dashy (20 commits). No dedicated release notes exist for these tags, and no UPGRADING/BREAKING_CHANGES/CHANGELOG document was supplied or found for this range — the commit list is the only record available.

v2.4.2

Changed

• lissy93/dashy:4.6.13 moved to lissy93/dashy:4.6.14. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

v2.4.1

Changed

• update.sh names any new required variable before it moves. An update can add a required variable; docker compose up used to stop on it after the checkout, with the tree already on the new tag. The script now lists the variables that appeared in .env.example since your version and refuses, before anything has moved, when a required one is not in your .env. Names only, never values.
• lissy93/dashy:4.6.9 moved to lissy93/dashy:4.6.13 (automated: the freshness check reported the lag, the deploy job booted the stack on the new image before this landed).

Upgrading

git pull (or ./update.sh). Nothing running changes: this release adds or extends the update script and touches no image pin.

Full history in CHANGELOG.md.

v2.4.0

Added

• Per-image version overrides. Every pin in the x-images block is
  now ${<PREFIX>_IMAGE_TAG:-repo:${<PREFIX>_IMAGE_VERSION:-tag@sha256:digest}}.
  Set <PREFIX>_IMAGE_VERSION in .env to run a different version of one
  image while every other pin stays as tested (Compose pulls that tag
  without a digest), or <PREFIX>_IMAGE_TAG to replace the whole
  reference as before. A deployment that sets neither is unchanged. The
  freshness job, the Trivy matrix and the fleet digest automation resolve
  the nested default before reading a pin. Needs Docker Compose v2.5 or
  newer (2022): v2.0 to v2.4 leave the inner ${...} unexpanded and
  docker compose up fails with an invalid reference instead of
  deploying something unexpected.

Changed

• lissy93/dashy 4.6.7 to 4.6.9.

Upgrading

git pull (or ./update.sh). A deployment that sets no _IMAGE_VERSION or _IMAGE_TAG variable renders exactly the same image references as before, so docker compose up -d recreates nothing. Requires Docker Compose v2.5 or newer.

Full history in CHANGELOG.md.

v2.3.0

Security

• Container hardening. Every service runs with
  security_opt: no-new-privileges:true (no privilege escalation via
  setuid binaries even if a process escapes its initial capability
  set). Infrastructure containers (the reverse proxy, databases,
  caches, backups) drop every Linux capability and add back only what
  their entrypoints need (bind :80/:443, chown a data directory, drop to
  the service user). Application containers keep the default capability
  set: upstream images assume it, and a wrong guess there is a boot loop
  in production, not a hardening win. CI boots the stack under these
  settings on every push.

Upgrading

git pull and docker compose up -d (or ./update.sh). Containers are recreated once with the new security settings; data volumes are untouched.

Full history in CHANGELOG.md.