v1.1.1

Security

• The HTTPS entry point's read timeout is no longer zero. NAVIDROME_STREAM_TIMEOUT and
  the fleet-wide TRAEFIK_READ_TIMEOUT defaulted to 0s, which tells
  Traefik to wait for a request body for ever. A request that carries a
  Content-Length and sends no body then holds its connection until the
  connections run out, the shape of CVE-2024-28869, which Traefik closed in
  2.11.2 by giving that timeout a default. The comment justified the zero
  with the length of the responses this stack serves; a long response is
  the write timeout's business, and that stays 0s. The default is now
  60s. A transcoded stream is a long response, not a long request, so Traefik's own 60 seconds is enough here.

v1.1.0

Added

• Traefik's timeouts also answer to the fleet-wide names.
  TRAEFIK_READ_TIMEOUT, TRAEFIK_WRITE_TIMEOUT and TRAEFIK_IDLE_TIMEOUT now
  set the HTTPS entry point's timeouts here as in every other Traefik template
  in the fleet. When set they win; NAVIDROME_STREAM_TIMEOUT, NAVIDROME_IDLE_TIMEOUT keep working exactly as before,
  and a deployment that sets neither gets the same defaults.

v1.0.9

Changed

• deluan/navidrome:0.64.1 moved to deluan/navidrome:0.64.2. 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 0.64.1 -> 0.64.2

Verdict: SAFE TO APPLY — a bug-fix and security-hardening release with no config, variable or companion-service changes; the image configurations are identical in every field that matters.

Breaking changes

• none found in the notes

Variables

• none

Data and dependencies

• A migration runs automatically on startup to reset invalid track/disc/BPM values that previously caused scan failures on 32-bit builds: "Fix scans failing with value out of range on 32-bit builds when a file has an invalid track number, disc number or BPM. A migration resets existing invalid values." This is a data migration, not a schema-breaking one, and it runs on all architectures (not just 32-bit) since migrations aren't conditional on platform — expect no manual action, but note that a handful of affected fields will be silently reset to valid defaults on first boot.
• No companion service (database, cache, search engine) is named in the notes, so the "no unpinned companion" rule does not apply here.

Before applying

• None required beyond the normal restart. If you rely on exact track/disc/BPM metadata for a small number of previously-broken files, it's worth spot-checking those after the upgrade, since the migration referenced in "Fix scans failing with value out of range... A migration resets existing invalid values" changes them in place.
• Take your usual SQLite backup before restarting, as the backups sidecar in this compose file already provides — no extra step beyond letting that run once before you upgrade if you want an immediate pre-migration snapshot.

Notes read

• v0.64.2 (full text above, covering the 0.64.1 -> 0.64.2 range)

v1.0.8

Fixed

• CI had never run the restore script. The test restored with its own
  copy of the commands. The script read DATA_PATH and DATA_BACKUPS_PATH
  from the shell that ran it rather than from .env or the stack, so a path
  set in .env was not the one it listed or cleared, and it cleared with
  rm -rf dir/*, which leaves every dotfile of the newer state in place. It
  now takes every path and name from the running backups container, accepts
  the backup file name as an argument, starts the application again whatever
  happens, and CI runs it: a file written before a backup and deleted after it
  must be back once that backup is restored.

Changed

• 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.

v1.0.7

Changed

• deluan/navidrome:0.64.0 moved to deluan/navidrome:0.64.1. 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 0.64.0 -> 0.64.1

Verdict: NEEDS ATTENTION — this is a security release fixing five vulnerabilities, including an unauthenticated brute-force path and an authenticated SSRF; it should be applied promptly, and one artwork-storage permission change is worth checking against local expectations.

Breaking changes

• none found in the notes

Variables

• Two new optional config options, neither required and neither exposed in this template's .env.example today: Jellyfin.AutoDiscovery (default false) and Jellyfin.QuickConnect (default true), per the "Configuration Changes" table. Not adding them changes nothing: defaults apply. If the operator wants LAN auto-discovery for Jellyfin clients, note the release's own caveat: "Docker users need host networking for the UDP broadcast to reach the container." This compose file does not use host networking, so Jellyfin.AutoDiscovery cannot work as deployed without a compose change — out of scope for this upgrade, just flagging it.
• No renamed or removed variables.

Data and dependencies

• none — no database, cache, or search-engine version requirement is named in the notes. Navidrome's data store here is SQLite inside the navidrome-data volume, already covered by the compose file's backup service.
• Artwork cache file permissions change: "Store artwork files as group-readable (mode 0640) instead of owner-only, so other services on the same host can read the image cache." This affects files under /data. In this template's default configuration (named volume, no user: override), the container runs as the image's built-in root/default user, so this is a lower-impact permission loosening rather than a breakage. If the operator has applied the .env.example-documented non-root user: override on a bind-mounted /data, no action is needed either — this only widens read access, it does not narrow it.

Before applying

• No manual migration or config edit is required.
• Take the normal precaution: the backups service already archives /data on a schedule: confirm a recent backup exists before pulling the new digest, since this is standard practice regardless of what the notes say.
• After upgrading, watch the log for the new warning introduced by "Log a warning when a nowPlaying scrobble sends more than one id" — informational only, not an error to act on.

Notes read

• v0.64.1 release notes (deluan/navidrome), the only version in the range being moved through (0.64.0 -> 0.64.1). No separate UPGRADING/BREAKING_CHANGES section was supplied for this range.

v1.0.6

Security

• traefik:3.7 was rebuilt upstream; the pin moved from sha256:1c32e7c36820… 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.

v1.0.5

Security

• alpine:3.22 was rebuilt upstream; the pin moved from sha256:365499d9dccb… to sha256:5291449c3df7…. 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.

v1.0.4

Security

• traefik:3.7 was rebuilt upstream; the pin moved from sha256:f86a2cab1b5c… to sha256:1c32e7c36820…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.
• alpine:3.22 was rebuilt upstream; the pin moved from sha256:14358309a308… to sha256:365499d9dccb…. 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.

v1.0.3

The pre-upgrade backup v1.0.2 recommended was the wrong kind of backup.

It told you to tar the data directory before 0.64.0. The backup loop does the same every day, and what it produces is a copy of a live navidrome.db with its -wal and -shm beside it, taken by an ordinary archiver. For a daily copy that is fine. For the one backup you take before a migration that rewrites every table, a snapshot that was not atomic can refuse to open on exactly the day it is the only copy that matters.

navidrome backup create goes through SQLite's online backup API and writes one consistent file:

docker compose -f navidrome-traefik-letsencrypt-docker-compose.yml -p navidrome \
  exec navidrome navidrome backup create -d /data/pre-0.64.0

Two more things the README now says, both from running this exact upgrade on a real library. Check your settings before the upgrade rather than after: 0.64.0 validates configuration at startup, rejects a negative duration in any ND_* value, and warns on unknown keys. And prove the migration by state rather than by the absence of an error: 249 songs, 51 albums, 115 artists and 28 annotations before, the same to the number after, every annotation still pointing at a row that exists, every id now 22 characters of base62.

Upgrading: documentation only. Nothing in the stack changed.

v1.0.1

Changed

• deluan/navidrome:0.63.2 moved to deluan/navidrome:0.64.0. 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 0.63.2 -> 0.64.0

Verdict: NEEDS ATTENTION — the release re-encodes every internal ID in the database and the release notes explicitly say to back up first; this stack's automated backup runs on a 24h interval so a fresh, on-demand backup is needed immediately before the upgrade.

Breaking changes

• All internal IDs are re-encoded to a canonical 128-bit format, touching every table: "The migration touches every table, so back up your database before upgrading. Clients that cache item IDs (for example, offline downloads) may need to re-sync." This runs automatically on first start of 0.64.0 against the existing SQLite database in /data.
• Shares are now always owned by the creator: "Admins can no longer create shares on behalf of another user via userId." Only relevant if this deployment has admins creating shares for other users.
• Config durations are now validated at startup: "Negative values are rejected at startup." This template's durations (60s, 24h, 600s, 0s) are all valid, so no action needed, but any custom .env overrides with a stray - will now fail to start instead of being silently accepted.
• Plugin HTTP behavior changed (Extism built-in HTTP disabled, private/loopback addresses blocked). Not applicable — this template does not configure any Navidrome plugins.

Variables

• None renamed or removed. The compose file's ND_* environment block (ND_LOGLEVEL, ND_SCANSCHEDULE, ND_SESSIONTIMEOUT, ND_BASEURL, ND_ENABLETRANSCODINGCONFIG, ND_ENABLEEXTERNALSERVICES) and .env.example are unaffected.
• New optional options were added (Jellyfin.Enabled, Jellyfin.ServerName, Jellyfin.ExposedPublicUsers, Jellyfin.MaxConcurrentStreams, EnableNaturalSorting, MaxImageSize, EnableScheduledDBAnalyze), all with defaults per the "Configuration Changes" table — none are required, and none are wired into this template's .env.example. No edit needed unless the operator wants to opt in to Jellyfin API support or natural sorting.

Data and dependencies

• No companion service (database/cache/search engine) is involved — Navidrome uses its embedded SQLite file in /data; the compose file pins no separate DB image, so this is not a version-mismatch case.
• Irreversible migration: the ID re-encoding is a one-way schema change across every table. Per the notes, back up before upgrading.
• No port or path changes noted for the container (still serves on 4533; /ping healthcheck behavior unchanged).
• Base image bumped to Alpine 3.22 with curl added — informational only, no compose action required.

Before applying

• Trigger a fresh manual backup of the navidrome-data volume before starting the new image, don't rely on the backups service's next scheduled run (BACKUP_INTERVAL=24h by default). E.g.:

  docker compose exec backups sh -c 'tar -zcpf /srv/navidrome-data/backups/pre-0.64.0-manual.tar.gz /data'
  

  or stop the stack and copy the navidrome-data volume directly.
• Expect the first startup after the upgrade to run the ID-migration; on a large library this may take noticeably longer than a normal restart — do not kill it mid-migration (the existing 60s stop_grace_period is for normal shutdown, not for this one-time migration; let it finish before restarting again).
• Warn users of any client that caches item IDs (offline-synced apps) that a re-sync may be required after the upgrade.
• No .env or compose edits are required to apply this upgrade; bump NAVIDROME_IMAGE_VERSION (or the pinned digest in the compose file) to 0.64.0.

Notes read

• v0.64.0 (2026-09-12) release notes, covering the 0.63.2 → 0.64.0 range in full, including the "⚠️ Breaking Changes / Migration Notes" and "Configuration Changes" sections used above.