Navidrome v0.64.0 is worth upgrading to for most self-hosted operators already on the 0.63.x line, but only with a verified database backup first: the release re-encodes every internal ID and touches every table. This review is based on the project’s release notes and repository, not a live install. Skip the upgrade if you depend on plugins that call Extism’s built-in HTTP.

when to upgrade, and when to wait

Navidrome v0.64.0 was published on 2026-09-12 by the navidrome/navidrome maintainers. Two groups should move quickly. Operators on 0.63.x whose instance is reachable from the internet have the clearer case, because this release fixes a SQL injection in the Native API, several share and plugin authorization flaws, and a login rate-limit bypass. Operators running large libraries also gain from index-backed genre and artist filtering and faster playlist import, on top of the database work landed in 0.63.x.

Two groups should wait. Anyone whose deployment depends on a plugin that calls Extism’s built-in HTTP (through pdk.NewHTTPRequest in Go, http::request in Rust, or the equivalent in other PDKs) will see those calls fail after the upgrade until the plugin is rewritten to use the host HTTP service. And anyone who cannot restore a verified database backup on the same day should finish that work first, because the ID re-encoding migration is not something to attempt blind.

key facts at a glance

what actually changed in v0.64.0

the id re-encode is the real decision point

The maintainers describe the change plainly: all internal IDs are re-encoded to a single canonical 128-bit base62 format, and the migration touches every table. The same release notes instruct operators to back up the database before upgrading and warn that clients caching item IDs (offline downloads are the example given) may need to re-sync. Treat that as the boundary condition for the whole upgrade. The code change is routine; the data migration is what decides whether you upgrade this week or after a rehearsal.

What the release notes do not state is how long the migration takes on a large library, whether it can be interrupted and resumed, or how to roll back afterwards. Those are unknowns to resolve against a copy of your own database, not by reading a changelog.

security fixes change the cost of staying put

The release ships fixes for a set of reported issues, attributed by the maintainers as follows. A SQL injection through the artist role sort and filter parameters in the Native API was fixed by validating the role against a known list. Share-ownership spoofing (IDOR), where a client-supplied userId on share creation could expose other users’ private libraries, was fixed. A plugin HTTP client SSRF guard bypass via DNS names and redirects was closed by disabling Extism’s built-in HTTP and checking the resolved IP at dial time, and the same class of bypass was fixed in the plugin WebSocket host service. A login rate-limit bypass using spoofed X-Forwarded-For, X-Real-IP and True-Client-IP headers was closed by keying the limit on the trust-aware client IP. A memory-exhaustion path through a negative size parameter on getCoverArt and share images was closed by rejecting negative and oversized dimensions before decoding. Track membership is now enforced on public share streams, every resource ID in a share is validated, login request bodies are capped, the log file is created with mode 0600, and the Last.fm auth token is no longer logged.

Those fixes are the strongest reason to upgrade an internet-facing instance. They are also the reason a delayed upgrade is a decision with a cost, not a neutral default.

plugin http, shares, and configuration validation

Three behaviour changes will break setups that work on 0.63.x. Extism’s built-in HTTP is disabled, so plugins must call the host HTTP service instead; plugin HTTP and WebSocket connections to private or loopback addresses are now blocked for named hosts unless the address or CIDR is listed in the manifest’s requiredHosts. Shares are always owned by the user who creates them, so an admin can no longer pass userId to create a share on another user’s behalf. And configuration durations are validated at startup: negative values are rejected, and unrecognised options now produce a warning instead of failing silently.

The configuration change deserves attention in containerised deployments. A navidrome.toml or environment set that contained a harmless typo under 0.63.x may now log warnings, and a negative duration that previously appeared to work will now stop the server from starting. Check your configuration against the configuration options documentation before pulling the new image rather than after.

jellyfin api, artwork, and new defaults

Navidrome v0.64.0 adds an experimental Jellyfin Music API, off by default at Jellyfin.Enabled = false, so Jellyfin-compatible music clients such as Finamp and Jellify can connect. The maintainers note that Jellyfin tokens never expire, are scoped to the Jellyfin API, and are revoked when the user changes password, a condition worth weighing on any multi-user instance. Other additions include a new artwork pipeline that resolves images in the background, shows a blurred low-quality placeholder until the real image arrives, rate-limits external providers behind a circuit breaker, and adds an artwork command group for diagnosing and re-driving resolution. New configuration options include MaxImageSize (default 20MB), EnableScheduledDBAnalyze (default true) and EnableNaturalSorting (default false). The build moved to Go 1.27 and a Docker base image on Alpine 3.22, the Windows MSI now remembers install properties across upgrades, and a missing hyphen in the OpenRC service script that caused startup crashes was fixed. The restore command no longer wipes the database when the backup file does not exist.

deployment concerns and a safe upgrade path

Because this is a source and documentation review rather than a tested deployment, the sequence below is a checklist to adapt, not a claim about your instance.

1. Record the current version, install method (binary, Docker, .deb, .rpm, or Windows MSI), and the exact database location. In a default layout this is the database file under the configured DataFolder.
2. Stop the service and copy the database, then verify the copy actually opens. For a SQLite file, an integrity check through sqlite3 is the minimum. A copy you have not opened is not a backup.
3. Snapshot the configuration file and plugin list, and compare both against the v0.64.0 configuration table before starting. Look for negative durations and unrecognised keys.
4. Rehearse the upgrade against a copy of the database first. Confirm that the scan completes, users can log in, and clients holding cached IDs can re-sync.
5. After the real upgrade, run the new doctor command and, if search looks wrong, search rebuild. For artwork that stays blank, artwork explain reports what the pipeline decided.
6. Keep the previous binary or image tag available. If the migration turns out not to be reversible, that is a fact you want to know before you need it.

Deployment shape changes the risk profile. Docker users inherit the Alpine 3.22 base and a newer Go runtime. Windows MSI users gain install-property persistence across upgrades. OpenRC (Alpine init) users who hit the 0.63.x startup crash are picking up the service-script fix. And anyone running a plugin that talks to a LAN service should prepare a manifest update in the same window, because the private-address guard now applies. Where no one in-house can rehearse a database migration and document a rollback, that work fits the software development services I provide around existing-system upgrades.

maintenance signals from the repository

The project is actively maintained as of the snapshot. Repository metadata collected on 2026-09-17 shows 23,633 stars, 1,708 forks, and 276 open issues, with the last push at 2026-09-17T21:18 UTC; the repository was created in February 2016. Release cadence in the reviewed window is roughly monthly: v0.63.0 on 2026-07-08, v0.63.1 on 2026-07-09, v0.63.2 on 2026-07-11, and v0.64.0 on 2026-09-12. Patch releases landing within days of a feature release, followed by a security-heavy minor release, is the pattern to plan around.

Two signals are worth separating. A high open-issue count alongside active releases usually means triage lag rather than abandonment, but 276 open issues does mean you should not assume the specific problem you hit has a fix. Separately, the licence is GPL-3.0, which matters if you intend to embed or redistribute Navidrome rather than run it internally.

limitations and open questions

• The Jellyfin Music API is labelled experimental by the maintainers, and Jellyfin tokens do not expire on their own. Multi-user deployments need a revocation plan.
• LDAP and Active Directory authentication is still an open enhancement request (issue #141, opened in April 2020, with 148 reactions at the snapshot). This release does not provide directory-based login.
• Podcast support is an open request (issue #793), not a shipped feature.
• Jukebox control has a long-running open bug report (issue #2771, last updated 2026-07-22).
• Several advisories referenced in the release notes were still in draft on GitHub, so their public pages may not resolve yet even though the fixes ship in v0.64.0.
• This review contains no rehearsal of the ID migration on a real database, so migration timing and failure behaviour remain unverified.

alternatives and questions to settle before committing

If you only need a music server for yourself and the library is small, a managed Navidrome host is a legitimate alternative to owning the upgrade path: the project’s README names PikaPods as an officially supported cloud-hosted option, and the release notes also point to Zenith hosting. If your users are already on Jellyfin music clients such as Finamp or Jellify, enabling the experimental Jellyfin API may let you drop a second stack, but treat it as a trial rather than a migration.

Questions worth settling in writing before you commit:

1. How long does the ID migration take on a database of my size, and what happens if it is interrupted?
2. Which installed plugins call Extism’s HTTP APIs, and who rewrites them?
3. Which clients cache Navidrome item IDs locally, and how do those clients recover after re-encoding?
4. Does my current configuration contain options that are now invalid or newly rejected?
5. What is my documented restore procedure, and when was it last exercised?

who should and should not upgrade

Upgrade if you self-host on 0.63.x, your instance is reachable from the internet, and you can back up and restore the database on the same day. Upgrade if you run a large library and index-backed filtering plus faster playlist import justify a maintenance window. Upgrade if you want to evaluate Jellyfin music clients against a Navidrome backend.

Do not rush if you depend on a plugin that will break under the new HTTP rules and have nobody to port it, if your instance is not internet facing and stability outranks new features, or if nobody on the team has ever restored the database from a backup. In those cases, plan the work rather than skipping it: the security fixes in this release do not migrate backwards, and staying on an older version is a deliberate trade with its own cost.

verdict

Navidrome v0.64.0 is a maintenance release with enough security content to justify moving off 0.63.x, and one migration risk that needs a rehearsal first. The decision is not about whether the release is good. It comes down to whether you can absorb an all-table ID migration with a tested rollback path. If you can, upgrade in a planned window. If you cannot, the honest answer is to build that capability first and then upgrade.

sources

• Navidrome v0.64.0 release notes (release)
• navidrome/navidrome repository (repository)
• Navidrome configuration options documentation (documentation)
• Navidrome installation documentation (documentation)
• Pull request #5824: canonical 128-bit ID migration (issue)
• Issue #141: Add LDAP Support (issue)

The upgrade mechanics are routine; the ID migration is the part I would not run against a live instance without a rehearsal, and I take on this kind of work as system upgrades and migrations. Before quoting anything I would need your current Navidrome version, install method, database and library size, configuration file, plugin list, and a description of how you restore a backup today. With access to a copy of the database I can stage the migration and document the rollback path, and I would not promise a timetable until I have seen it. If you are planning a v0.64.0 upgrade, send me the details.