Navidrome 2026 selbst hosten: Musik-Mounts, Scans und Subsonic-Apps

Wenn du bereits versucht hast, Navidrome selbst zu hosten, kennst du wahrscheinlich diesen frustrierenden Zustand: Die UI wird angezeigt, aber Scans finden keine Dateien, weil der Musikpfad des Hosts falsch eingebunden ist. Den Container neu zu erstellen, behebt nur selten eine Abweichung zwischen URLs, Status und Abhängigkeiten.

Diese Anleitung verwendet ein konkretes Abnahmekriterium: eine schreibgeschützte Musikbibliothek scannen, Metadaten und Cover prüfen, einen Titel über einen Subsonic-Client streamen und eine Playlist speichern. Jede Konfigurationsentscheidung wird an diesem Kriterium gemessen, nicht an einem grünen Container-Badge.

Den Status sichern, den Navidrome nicht wiederherstellen kann

Definiere Wiederherstellungspunkt und Wiederherstellungszeit für Navidrome anhand der Navidrome-Datenbank, des Cover-Caches, der Playlists und der ursprünglichen Musikbibliothek. Binde /data vor dem Bootstrap ein, schreibe harmlose Beispieldaten und ersetze den Container, um zu beweisen, dass dieser Pfad tatsächlich persistent ist. Ein benanntes Volume löst die Persistenz bei einem Redeploy, schützt aber weder vor einer Kompromittierung noch vor dem Verlust des Servers.

Baue eine saubere Restore-Umgebung auf, verwende dieselbe gepinnte Anwendungsversion und beweise, dass Benutzer, Playlists, Wiedergabeverlauf und Metadaten zurückkehren und derselbe Subsonic-Client einen bekannten Titel streamt. Halte Befehle, Anpassungen der Besitzrechte und die verstrichene Zeit fest. Der Backup-Leitfaden bietet dafür einen nützlichen Standard: Ein Backup gilt erst nach einer Wiederherstellung als vertrauenswürdig, nicht nach dem Upload.

Navidrome starten, ohne die beweglichen Teile zu verbergen

Verwende den Container als austauschbare Laufzeitumgebung, nicht als Ort der Wahrheit.

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

Bestätige die lokale Voraussetzung vor der Veröffentlichung: ein schreibgeschützter Mount der Musikbibliothek sowie schreibbare Anwendungsdaten. Prüfe den Benutzer des Containers, die schreibbaren Pfade und den gebundenen Listener, bevor du den Dienst veröffentlichst. Führe den vollständigen Ablauf aus — eine schreibgeschützte Musikbibliothek scannen, Metadaten und Cover prüfen, einen Titel über einen Subsonic-Client streamen und eine Playlist speichern — und sichere die exakte Image-Referenz, mit der das Ergebnis erzielt wurde.

Die kleinstmögliche sinnvolle Navidrome-Topologie wählen

Beginne mit dem Netzwerk-Namespace von Navidrome: Der Web-Listener verwendet Port 4533, nicht einen Host-Port, der aus einem Laptop-Tutorial kopiert wurde. Die lokale Laufzeitvoraussetzung ist ein schreibgeschützter Mount der Musikbibliothek sowie schreibbare Anwendungsdaten. Halte diese Voraussetzung zusammen mit Image und Port fest, damit ein Ersatz-Host dieselben lokalen Möglichkeiten erhält.

Sobald die Voraussetzung erfüllt ist, führe das vollständige Szenario aus — eine schreibgeschützte Musikbibliothek scannen, Metadaten und Cover prüfen, einen Titel über einen Subsonic-Client streamen und eine Playlist speichern. Erfasse Logs und Messwerte für die Dauer des Bibliotheksscans, die Transcoding-CPU, den Cover-Cache, parallele Streams und den Festplatten-Durchsatz. Diese Daten bilden die erste nachweislich funktionierende Architektur und machen spätere Umzüge zwischen Dockup-Compute und einem angeschlossenen Server testbar.

TLS ist einfach – generierte URLs sind es nicht

Setze ND_BASEURL, wenn du den Dienst über einen Subpath bereitstellst; andernfalls ist ein eigener HTTPS-Host vorzuziehen. Leite den gewählten Hostnamen an Container-Port 4533 weiter, übermittle den ursprünglichen Host und das HTTPS-Schema und veröffentliche keinen zweiten direkten Origin.

Teste Navidrome mit einem sauberen externen Client. Trenne Fehler beim Ingress von der bekannten Anwendungsgrenze — Scans finden keine Dateien, weil der Musikpfad des Hosts falsch eingebunden ist. Ein Zertifikats-, DNS- oder 502-Fehler gehört zum Routing; eine Anfrage, die Navidrome erreicht und erst danach fehlschlägt, gehört zum Anwendungsstatus, zur Kapazität oder zu einer unterstützenden Voraussetzung. Der Leitfaden zu TLS mit eigener Domain behandelt die erste Gruppe.

Fünf Prüfungen, die aussagekräftiger sind als der Container-Health-Status

Erstelle vor dem Eintreffen echter Benutzer ein Release-Arbeitsblatt für Navidrome. Es muss das gepinnte Image, Port 4533, den kanonischen Origin, persistente Pfade und die verantwortliche Stelle für einen schreibgeschützten Mount der Musikbibliothek sowie schreibbare Anwendungsdaten benennen. Füge das erwartete Ergebnis dieser Transaktion hinzu: eine schreibgeschützte Musikbibliothek scannen, Metadaten und Cover prüfen, einen Titel über einen Subsonic-Client streamen und eine Playlist speichern.

Verwende das Arbeitsblatt nach einem normalen Austausch und nach einer sauberen Wiederherstellung. Die Wiederherstellung gilt nur dann als erfolgreich, wenn Benutzer, Playlists, Wiedergabeverlauf und Metadaten zurückkehren und derselbe Subsonic-Client einen bekannten Titel streamt. Erfasse außerdem einen kurzen Ressourcen-Trace mit Dauer des Bibliotheksscans, Transcoding-CPU, Cover-Cache, parallelen Streams und Festplatten-Durchsatz; bewahre ihn zusammen mit dem Release auf, damit künftige Kapazitätsänderungen mit derselben Workload verglichen werden.

Füge einen kontrollierten Fehler hinzu: Übermittle harmlose Eingaben nahe dem Ressourcen- oder Formatlimit, das mit dieser Grenze verbunden ist: Scans finden keine Dateien, weil der Musikpfad des Hosts falsch eingebunden ist. Bestätige, dass Navidrome das Problem an der richtigen Grenze meldet, stelle den gültigen Zustand wieder her und führe die Transaktion erneut aus. Damit prüfst du die Sichtbarkeit von Fehlern, nicht nur den Erfolg, und verhinderst, dass eine gesund aussehende Oberfläche einen defekten Worker, Callback oder eine fehlerhafte Datenbankverbindung verbirgt.

Logs, die die nächste Frage beantworten

Verwende „eine schreibgeschützte Musikbibliothek scannen, Metadaten und Cover prüfen, einen Titel über einen Subsonic-Client streamen und eine Playlist speichern“ nach jedem Deployment als Navidrome-Smoke-Test. Die zugehörigen Messwerte sind Dauer des Bibliotheksscans, Transcoding-CPU, Cover-Cache, parallele Streams und Festplatten-Durchsatz; löse Alerts dort aus, wo diese Ressourcen einen Punkt erreichen, an dem die Benutzeraktion beeinträchtigt wird.

Das größte Änderungsrisiko besteht darin, dass Migrationen der Navidrome-Datenbank und das Verhalten des Scanners getestet werden müssen, während die ursprünglichen Musikdateien unverändert bleiben. Ein sicheres Release beginnt mit einem wiederherstellbaren Snapshot und validiert jede nicht umkehrbare Statusänderung, bevor Traffic weitergeleitet wird. Wenn Scans keine Dateien finden, weil der Musikpfad des Hosts falsch eingebunden ist, bewahre den fehlerhaften Container lange genug auf, um seine Konfiguration und den ersten Fehler zu lesen.

Navidrome nicht den gesamten Host überlassen

Schließe das Bootstrap-Fenster, sobald der erste vertrauenswürdige Administrator existiert. Die konkrete Falle bei Navidrome besteht darin, die Musikbibliothek ohne triftigen Grund mit Schreibzugriff einzubinden; die sicherere Grenze ist, Musik schreibgeschützt zu mounten, Konten zu schützen und ausschließlich den Streaming-Dienst statt der Host-Bibliothek zu veröffentlichen.

ND_BASEURL ist eine Konfiguration und kein Secret; halte seinen Wert explizit, während du die separaten Zugangsdaten für Navidrome schützt. Private Netzwerke sollten Zugangsdaten für Abhängigkeiten transportieren, und Rollen innerhalb von Navidrome sollten nur die kleinstmögliche sinnvolle Aktion erlauben. Halte sensible Request-Bodies und Provider-Antworten aus den regulären Logs heraus.

Navidrome explizit halten, während Dockup das Routing übernimmt

Routing, Zertifikate, das Ersetzen von Services und angebundener Storage sind sinnvolle Ziele für Automatisierung. Dockup übernimmt diese Aufgaben für Navidrome und kann die zugehörige Managed Database bereitstellen oder Verbindungen zu Services auf dem eigenen Server eines Kunden herstellen.

Was es nicht erfinden sollte, ist die Trust Policy von Navidrome. Setze nach dem Deployment ND_BASEURL, wenn du den Dienst über einen Subpath bereitstellst; andernfalls ist ein eigener HTTPS-Host vorzuziehen. Erzwinge diese Grenze — mounte Musik schreibgeschützt, schütze Konten und veröffentliche ausschließlich den Streaming-Dienst statt der Host-Bibliothek — und überprüfe das Ergebnis dieses Szenarios: eine schreibgeschützte Musikbibliothek scannen, Metadaten und Cover prüfen, einen Titel über einen Subsonic-Client streamen und eine Playlist speichern. Das Ergebnis ist eine One-Click-Infrastruktur mit einem anwendungsspezifischen Abnahmetest.

Häufig gestellte Fragen

Was benötigt Navidrome für ein produktives Deployment?

Leite den Navidrome-Container auf Port 4533 über einen einzigen HTTPS-Origin weiter. Die lokale Laufzeitvoraussetzung ist ein schreibgeschützter Mount der Musikbibliothek sowie schreibbare Anwendungsdaten. Erkläre Navidrome erst dann für einsatzbereit, wenn du eine schreibgeschützte Musikbibliothek scannen, Metadaten und Cover prüfen, einen Titel über einen Subsonic-Client streamen und eine Playlist speichern kannst.

Welche Navidrome-Daten gehören in ein Backup?

Mache /data persistent und nimm die Navidrome-Datenbank, den Cover-Cache, die Playlists und die ursprüngliche Musikbibliothek in dasselbe Recovery-Manifest auf. Ein sauberes Navidrome-Restore ist nur dann erfolgreich, wenn Benutzer, Playlists, Wiedergabeverlauf und Metadaten zurückkehren und derselbe Subsonic-Client einen bekannten Titel streamt.

Benötigt Navidrome hinter einem Reverse Proxy HTTPS?

Verwende HTTPS für den öffentlichen Navidrome-Origin und halte Port 4533 auf der internen Route. Wende die Navidrome-Einstellung korrekt an: Setze ND_BASEURL, wenn du den Dienst über einen Subpath bereitstellst; andernfalls ist ein eigener HTTPS-Host vorzuziehen. Bei Navidrome schützt HTTPS Zugangsdaten oder Benutzerinhalte während der Übertragung und sorgt für ein konsistentes Client-Verhalten, das vom Origin abhängt.

Wie sollte ein Navidrome-Upgrade getestet werden?

Stelle den aktuellen Navidrome-Status in einem isolierten Deployment wieder her, wende die geplante Version an und wiederhole die Abnahmetransaktion. Gehe dabei besonders sorgfältig vor, da Migrationen der Navidrome-Datenbank und das Verhalten des Scanners getestet werden müssen, während die ursprünglichen Musikdateien unverändert bleiben. Bewahre das vorherige Navidrome-Image auf, bis die Grenzen für Datenmigration und Rollback verstanden sind.