Navidrome is a self-hosted music streaming server written in Go that indexes your tagged audio files and serves them over its own web UI and the Subsonic API. It replaces Spotify and Apple Music for a library you already own, and replaces Plex or Jellyfin if music is the only thing you care about.
Our verdict on Navidrome#
Navidrome's real product decision is that it does not ship mobile apps. It implements the Subsonic API, and you use Symfonium, play:Sub, substreamer, Amperfy or Feishin against it, which means the app quality problem is solved by someone else and you get a choice. The second decision is that it trusts your file tags absolutely: it reads them, it never writes them, and a library with inconsistent album artist or missing MusicBrainz IDs will look broken in ways no Navidrome setting fixes. Fix the tags with Picard or beets first. v0.60 (February 2026) added a WebAssembly plugin system for metadata providers and integrations, with 0.63.2 the current release as of July 2026. It is still pre-1.0 after six years, and the honest caveat is the scanner: full scans on very large libraries have driven resident memory into multiple GB, which is why an external-scanner subprocess mode exists.
Who Navidrome is for#
Choose it if
- You have a properly tagged FLAC or MP3 collection and want it on your phone without uploading it to anyone.
- You want to pick your own client app rather than accept the one bundled with your server.
- You are running on a small box: a Pi 4 or a 1 GB VPS handles a single-household music library without effort.
- You are dropping Plex or Jellyfin entirely and music was the only thing keeping you there.
Look elsewhere if
- Your library is badly tagged and you are not willing to fix it, because Navidrome will not organize files for you.
- You need video, podcasts or audiobooks in the same app: Navidrome is music only by design.
- You want a first-party mobile app with vendor support rather than a third-party Subsonic client.
What running it actually looks like#
One container or one static binary, and there is genuinely nothing else. Mount your music directory read-only at /music and a data directory at /data, expose 4533, done. Configuration is environment variables prefixed ND_ or a navidrome.toml; the settings you will actually touch are ND_SCANSCHEDULE, ND_MUSICFOLDER, ND_LOGLEVEL and the transcoding defaults. The first user you create becomes the admin, and the first scan is the only slow part: expect roughly an hour per 100,000 tracks on spinning disks, much less on SSD, with artwork extraction dominating. Upgrades are a tag bump; the schema migrates forward on start with no ceremony. If you front it with Authelia or Authentik, set ND_REVERSEPROXYWHITELIST to the proxy's CIDR or the header trust is wide open.
Resource profile#
- Memory
- 70 MB idle, around 200 MB in ordinary use. A Go binary with a small resident set at rest; full library scans are the outlier and can allocate far beyond the steady-state figure on very large collections.
- CPU and acceleration
- Serving is nearly free because most clients stream the original file. CPU only matters during a full scan (tag reading and artwork extraction) and when on-the-fly transcoding to Opus or MP3 for bandwidth-limited clients.
- Storage growth
- The database and artwork cache stay in the tens to low hundreds of MB for a typical library; your music files are the only thing that really grows, and Navidrome never writes to them.
- Operational load
- 1 of 5, Set and forget. One static binary or one container, one SQLite file, no external database, and backup is copying a directory. Upgrades are a tag bump. The only recurring attention is scanner behavior on large libraries and keeping your file tags sane.
Figures describe a small single-household install and are the working assumptions behind our stack planner. Your numbers will differ with library size, user count and hardware. See methodology.
Data and backup surface#
Back up the data directory: navidrome.db plus its -wal and -shm files, and the cache/ subdirectory if you want to skip re-extracting artwork. cache/ is fully regenerable, so excluding it is fine and usually smaller. The database holds users, playlists, play counts, ratings, starred items and scrobble history, and none of that is recoverable from your audio files. Use SQLite's .backup or stop the container rather than copying the db file live under WAL. Smart playlists are .nsp JSON files in the music folder rather than database rows, so they travel with your library. Navidrome never modifies your audio files, so the music tree itself needs no special handling.
Derived backup shape
SQLite backup. sqlite3 <db> ".backup out.db" while running, or stop the container and copy. A live cp of a WAL-mode SQLite file can restore corrupt.
Traps and surprises#
Full scans can use gigabytes of RAM
Steady-state memory is tiny, but full rescans on libraries in the hundreds of thousands of tracks have been reported pushing container RSS past 10 GB and getting OOM killed. That is why Navidrome grew an external scanner that runs scanning in a subprocess so the memory is released when it exits. If your container dies during a scan, enable the external scanner and set a memory limit high enough to survive it rather than fighting the scan schedule.
Compilations split unless the tags say otherwise
Navidrome groups by album artist, so a compilation with a different artist per track becomes many one-track albums. The fix is in the files: set ALBUMARTIST consistently and use the compilation flag (TCMP / COMPILATION). No Navidrome setting rescues badly tagged rips, and re-scanning does nothing until the tags change. Run the library through Picard or beets before you blame the server.
Reverse proxy auth trusts a header, so whitelist the proxy
ND_REVERSEPROXYUSERHEADER makes Navidrome accept an identity from a header (Remote-User by default). If ND_REVERSEPROXYWHITELIST is not set to the proxy's IP CIDR, anything that can reach port 4533 can set that header and log in as anyone. Users authenticated this way are auto-created with a random password, and the first one created becomes an admin.
Subsonic clients do not use your SSO
Even with forward auth in front of the web UI, third-party Subsonic apps authenticate against Navidrome's own user database with a password or token. That means every SSO user still needs a Navidrome password for mobile use, and your proxy has to let the /rest endpoints through unauthenticated for those clients to work at all. Plan the proxy rules around that split rather than discovering it on a phone.
Specifications#
- Category
- Media servers and libraries
- Licence
- GPL-3.0 (Copyleft)
- Written in
- Go
- First release
- 2020
- Maturity
- Stable
- Datastore
- SQLite
- Default ports
4533- Ships as
- docker, single static binary, deb/rpm package
- arm64 builds
- Yes
- Identity
- Trusted proxy header. Reverse proxy authentication via ND_REVERSEPROXYUSERHEADER (default Remote-User) with an ND_REVERSEPROXYWHITELIST CIDR; there is no native OIDC, and Subsonic clients still authenticate with a Navidrome password regardless.
- Replaces
- Spotify, Apple Music, Plexamp, Google Play Music
- Project site
- www.navidrome.org
- Source
- github.com/navidrome/navidrome
- Documentation
- www.navidrome.org/docs
Alternatives to Navidrome#
Everything else in media servers and libraries, closest in operational weight first.
| Tool | Ops load | Idle RAM | Licence |
|---|---|---|---|
| Audiobookshelf | 2, Light | 200 MB | GPL-3.0 |
| Calibre-Web | 2, Light | 120 MB | GPL-3.0 |
| Emby | 2, Light | 350 MB | Proprietary |
| Jellyfin | 2, Light | 280 MB | GPL-2.0-only |
| Jellyseerr | 2, Light | 220 MB | MIT |
| Kavita | 2, Light | 250 MB | GPL-3.0 |
Where Navidrome comes up elsewhere#
Head to head
Migration guides
Guides
Research
Reference
Sources#
Facts on this page were checked against the project's own material. Where a number is our own estimate rather than a published figure, the text says so.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.