How to Self-Host Navidrome in 2026: Music Mounts, Scans and Subsonic Apps

If you already tried to self-host Navidrome, the frustrating state is probably familiar: the UI appears, but scans find no files because the host music path is mounted incorrectly. Recreating the container rarely fixes a disagreement between URLs, state and dependencies.

This walkthrough uses one concrete completion criterion — scan a read-only music library, verify metadata and artwork, stream a track through a Subsonic client and save a playlist. Every configuration choice is evaluated against that criterion rather than against a green container badge.

Back up the state Navidrome cannot recreate

Define recovery point and recovery time for Navidrome in terms of Navidrome database, artwork cache, playlists and the original music library. Mount /data before bootstrap, write harmless sample data and replace the container to prove that path is actually persistent. A named volume solves redeploy persistence; it does not solve compromise or server loss.

Build a clean restore environment, use the same pinned application version and prove that users, playlists, play history and metadata return and the same Subsonic client streams a known track. Record commands, ownership fixes and elapsed time. The backup guide is a useful standard: a backup is trusted after restoration, not after upload.

Start Navidrome without hiding the moving parts

Use the container as a replaceable runtime, not as the location of truth.

docker run -d \
  --name navidrome \
  --restart unless-stopped \
  -p 127.0.0.1:4533:4533 \
  -v navidrome-data:/data \
  -v /srv/music:/music:ro \
  -e ND_BASEURL=/ \
  deluan/navidrome:latest

Confirm the local requirement before exposure: a read-only music library mount plus writable application data. Inspect the container user, writable paths and bound listener before exposing it. Run the complete action — scan a read-only music library, verify metadata and artwork, stream a track through a Subsonic client and save a playlist — and save the exact image reference that produced the result.

Choose the smallest viable Navidrome topology

Start with the Navidrome network namespace: its web listener is port 4533, not a host port copied from a laptop tutorial. The local runtime requirement is a read-only music library mount plus writable application data. Record it beside the image and port so a replacement host receives the same local capability.

After the requirement is satisfied, run the complete scenario — scan a read-only music library, verify metadata and artwork, stream a track through a Subsonic client and save a playlist. Record logs and measurements for library scan time, transcoding CPU, artwork cache, concurrent streams and disk throughput. That evidence becomes the first known-good architecture and makes later moves between Dockup compute and an attached server testable.

TLS is easy; generated URLs are not

Set ND_BASEURL when serving from a subpath; otherwise prefer a dedicated HTTPS host. Send the chosen hostname to container port 4533, forward the original host and HTTPS scheme, and avoid publishing a second direct origin.

Test Navidrome from a clean external client. Separate ingress failure from the known application boundary — scans find no files because the host music path is mounted incorrectly. A certificate, DNS or 502 error belongs to routing; a request that reaches Navidrome and fails later belongs to application state, capacity or its supporting requirement. The custom-domain TLS guide covers the first group.

Five checks stronger than container health

Before real users arrive, make a release worksheet for Navidrome. It must name the pinned image, port 4533, canonical origin, persistent paths and the owner of a read-only music library mount plus writable application data. Attach the expected result of this transaction: scan a read-only music library, verify metadata and artwork, stream a track through a Subsonic client and save a playlist.

Use the worksheet after a normal replacement and after a clean restore. Recovery is accepted only if users, playlists, play history and metadata return and the same Subsonic client streams a known track. Also collect a short resource trace covering library scan time, transcoding CPU, artwork cache, concurrent streams and disk throughput; keep it beside the release so future capacity changes are compared with the same workload.

Include one controlled failure: submit harmless input near the resource or format limit associated with this boundary: scans find no files because the host music path is mounted incorrectly. Confirm Navidrome reports the problem at the correct boundary, put the valid condition back and rerun the transaction. This checks error visibility, not merely success, and prevents a healthy-looking interface from concealing a broken worker, callback or database connection.

Logs that answer the next question

Use scan a read-only music library, verify metadata and artwork, stream a track through a Subsonic client and save a playlist as the Navidrome smoke test after every deployment. Its supporting metrics are library scan time, transcoding CPU, artwork cache, concurrent streams and disk throughput; alert where those resources approach a point that degrades the user action.

The main change risk is that Navidrome database migrations and scanner behavior should be tested while the original music files remain untouched. A safe release starts from a restorable snapshot and validates any one-way state change before traffic moves. When scans find no files because the host music path is mounted incorrectly, keep the failed container long enough to read its configuration and first error.

Do not give Navidrome the whole host

Close the bootstrap window as soon as the first trusted administrator exists. Navidrome's concrete trap is mounting the music library read-write without a reason; the safer boundary is to mount music read-only, protect accounts and expose only the streaming service rather than the host library.

ND_BASEURL is configuration rather than a secret; keep its value explicit while protecting the separate credentials used by Navidrome. Private networking should carry dependency credentials, and roles inside Navidrome should grant the smallest useful action. Keep sensitive request bodies and provider responses out of routine logs.

Keep Navidrome explicit while Dockup handles routing

Routing, certificates, service replacement and attached storage are reasonable automation targets. Dockup handles those for Navidrome and can provision the related managed database or connect to services on a customer's own server.

What it should not invent is the Navidrome trust policy. After deployment, set ND_BASEURL when serving from a subpath; otherwise prefer a dedicated HTTPS host, enforce this boundary — mount music read-only, protect accounts and expose only the streaming service rather than the host library — and verify the result of this scenario: scan a read-only music library, verify metadata and artwork, stream a track through a Subsonic client and save a playlist. The outcome is one-click infrastructure with an application-specific acceptance test.

Frequently asked questions

What does Navidrome need for a production deployment?

Route the Navidrome container on port 4533 through one HTTPS origin. The local runtime requirement is a read-only music library mount plus writable application data. Do not call Navidrome ready until you can scan a read-only music library, verify metadata and artwork, stream a track through a Subsonic client and save a playlist.

Which Navidrome data belongs in a backup?

Persist /data and include Navidrome database, artwork cache, playlists and the original music library in the same recovery manifest. A clean Navidrome restore passes only when users, playlists, play history and metadata return and the same Subsonic client streams a known track.

Does Navidrome require HTTPS behind a reverse proxy?

Use HTTPS for the public Navidrome origin and keep port 4533 on the internal route. Apply the Navidrome setting correctly: set ND_BASEURL when serving from a subpath; otherwise prefer a dedicated HTTPS host. For Navidrome, HTTPS protects credentials or user content in transit and keeps origin-sensitive client behavior consistent.

How should a Navidrome upgrade be tested?

Restore current Navidrome state into an isolated deployment, apply the candidate version and repeat its acceptance transaction. Pay particular attention because Navidrome database migrations and scanner behavior should be tested while the original music files remain untouched. Keep the previous Navidrome image until its data-migration and rollback boundary are understood.