Slik selvhoster du Navidrome i 2026: musikkmonteringer, skanninger og Subsonic-apper

Hvis du allerede har prøvd å selvhoste Navidrome, kjenner du sannsynligvis den frustrerende situasjonen: Grensesnittet vises, men skanningen finner ingen filer fordi musikkstien på verten er montert feil. Det hjelper sjelden å opprette containeren på nytt når det er uoverensstemmelse mellom URL-er, state og avhengigheter.

Denne gjennomgangen bruker ett konkret kriterium for å regnes som fullført — skann et skrivebeskyttet musikkbibliotek, bekreft metadata og omslagsbilder, strøm avspilling av et spor gjennom en Subsonic-klient og lagre en spilleliste. Hvert konfigurasjonsvalg vurderes mot dette kriteriet, ikke mot et grønt containermerke.

Sikkerhetskopier state som Navidrome ikke kan gjenskape

Definer gjenopprettingspunkt og gjenopprettingstid for Navidrome med utgangspunkt i Navidrome-databasen, hurtigbufferen for omslagsbilder, spillelister og det opprinnelige musikkbiblioteket. Monter /data før bootstrap, skriv ufarlige eksempeldata og erstatt containeren for å bevise at stien faktisk er persistent. Et navngitt volume løser persistens ved redeploy; det løser ikke kompromittering eller tap av serveren.

Bygg et rent restore-miljø, bruk den samme låste applikasjonsversjonen og bevis at brukere, spillelister, avspillingshistorikk og metadata kommer tilbake, og at den samme Subsonic-klienten strømmer et kjent spor. Dokumenter kommandoer, endringer av eierskap og medgått tid. Guiden for sikkerhetskopiering er en nyttig standard: En sikkerhetskopi er til å stole på etter gjenoppretting, ikke etter opplasting.

Start Navidrome uten å skjule de viktige delene

Bruk containeren som en utskiftbar runtime, ikke som stedet der fasiten ligger.

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

Bekreft det lokale kravet før eksponering: et skrivebeskyttet musikkbibliotek montert som volume, samt skrivbare applikasjonsdata. Kontroller containerbrukeren, skrivbare stier og bundet listener før du eksponerer tjenesten. Kjør hele handlingen — skann et skrivebeskyttet musikkbibliotek, bekreft metadata og omslagsbilder, strøm avspilling av et spor gjennom en Subsonic-klient og lagre en spilleliste — og ta vare på den nøyaktige imagereferansen som produserte resultatet.

Velg den minste brukbare Navidrome-topologien

Start med Navidromes network namespace: Web-listeneren bruker port 4533, ikke en host-port kopiert fra en laptop-veiledning. Det lokale runtime-kravet er et skrivebeskyttet musikkbibliotek montert som volume, samt skrivbare applikasjonsdata. Dokumenter dette sammen med image og port, slik at en ny vert får samme lokale funksjonalitet.

Når kravet er oppfylt, kjører du hele scenariet — skann et skrivebeskyttet musikkbibliotek, bekreft metadata og omslagsbilder, strøm avspilling av et spor gjennom en Subsonic-klient og lagre en spilleliste. Dokumenter logger og målinger for skanningstid for biblioteket, CPU-bruk ved transcoding, hurtigbuffer for omslagsbilder, samtidige strømmer og disk-gjennomstrømning. Dette blir den første kjente gode arkitekturen og gjør senere flyttinger mellom Dockup compute og en tilkoblet server testbare.

TLS er enkelt; genererte URL-er er det ikke

Angi ND_BASEURL når tjenesten leveres fra en substi; ellers bør du foretrekke en dedikert HTTPS-host. Send det valgte hostnavnet til containerport 4533, videresend den opprinnelige hosten og HTTPS-skjemaet, og unngå å publisere en ekstra direkte origin.

Test Navidrome fra en ren ekstern klient. Skill feil i ingress fra den kjente applikasjonsgrensen — skanninger finner ingen filer fordi musikkstien på verten er montert feil. En sertifikat-, DNS- eller 502-feil hører til rutingen; en forespørsel som når Navidrome og feiler senere, hører til applikasjons-state, kapasitet eller den tilhørende forutsetningen. Veiledningen for TLS med egendefinert domene dekker den første gruppen.

Fem kontroller som er bedre enn container health

Før de faktiske brukerne kommer, lager du et release-regneark for Navidrome. Det må angi låst image, port 4533, kanonisk origin, persistente stier og eieren av et skrivebeskyttet musikkbibliotek montert som volume, samt skrivbare applikasjonsdata. Legg ved forventet resultat for denne transaksjonen: skann et skrivebeskyttet musikkbibliotek, bekreft metadata og omslagsbilder, strøm avspilling av et spor gjennom en Subsonic-klient og lagre en spilleliste.

Bruk regnearket etter en vanlig utskifting og etter en ren gjenoppretting. Gjenoppretting godtas bare hvis brukere, spillelister, avspillingshistorikk og metadata kommer tilbake, og den samme Subsonic-klienten strømmer et kjent spor. Samle også inn en kort ressursmåling som dekker skanningstid for biblioteket, CPU-bruk ved transcoding, hurtigbuffer for omslagsbilder, samtidige strømmer og disk-gjennomstrømning. Oppbevar den sammen med releasen, slik at fremtidige kapasitetsendringer sammenlignes med samme arbeidsbelastning.

Ta med én kontrollert feil: send ufarlig input nær ressurs- eller formatgrensen som er knyttet til denne grensen: skanninger finner ingen filer fordi musikkstien på verten er montert feil. Bekreft at Navidrome rapporterer problemet ved riktig grense, gjenopprett den gyldige tilstanden og kjør transaksjonen på nytt. Dette kontrollerer feilsynlighet, ikke bare suksess, og hindrer et tilsynelatende friskt grensesnitt i å skjule en ødelagt worker, callback eller databaseforbindelse.

Logger som besvarer det neste spørsmålet

Bruk «skann et skrivebeskyttet musikkbibliotek, bekreft metadata og omslagsbilder, strøm avspilling av et spor gjennom en Subsonic-klient og lagre en spilleliste» som Navidromes smoke test etter hver deployment. De tilhørende målingene er skanningstid for biblioteket, CPU-bruk ved transcoding, hurtigbuffer for omslagsbilder, samtidige strømmer og disk-gjennomstrømning. Sett varsler der ressursbruken nærmer seg et nivå som forringer brukerhandlingen.

Den største endringsrisikoen er at Navidromes databasemigreringer og scanner-atferd må testes mens de opprinnelige musikkfilene forblir urørt. En trygg release starter fra et gjenopprettbart snapshot og validerer alle irreversible state-endringer før trafikken flyttes. Når skanninger ikke finner filer fordi musikkstien på verten er montert feil, lar du den feilede containeren stå lenge nok til å lese konfigurasjonen og den første feilen.

Ikke gi Navidrome tilgang til hele verten

Lukk bootstrap-vinduet så snart den første betrodde administratoren finnes. Den konkrete fellen i Navidrome er å montere musikkbiblioteket med skriveadgang uten en god grunn. Den sikrere grensen er å montere musikk skrivebeskyttet, beskytte kontoene og bare eksponere strømmetjenesten, ikke vertens bibliotek.

ND_BASEURL er konfigurasjon, ikke en hemmelighet; hold verdien eksplisitt, samtidig som du beskytter de separate legitimasjonene som Navidrome bruker. Privat nettverk bør transportere credentials for avhengigheter, og roller i Navidrome bør gi minst mulig nyttig tilgang. Sørg for at sensitive request bodies og svar fra leverandører ikke havner i vanlige logger.

Hold Navidrome eksplisitt mens Dockup håndterer ruting

Ruting, sertifikater, utskifting av tjenester og tilkoblet lagring er fornuftige mål for automatisering. Dockup håndterer dette for Navidrome og kan klargjøre den tilhørende managed databasen eller koble til tjenester på kundens egen server.

Det Dockup ikke bør finne på, er Navidromes trust policy. Etter deployment angir du ND_BASEURL når tjenesten leveres fra en substi; ellers bør du foretrekke en dedikert HTTPS-host. Håndhev denne grensen — monter musikk skrivebeskyttet, beskytt kontoene og eksponer bare strømmetjenesten, ikke vertens bibliotek — og bekreft resultatet av dette scenariet: skann et skrivebeskyttet musikkbibliotek, bekreft metadata og omslagsbilder, strøm avspilling av et spor gjennom en Subsonic-klient og lagre en spilleliste. Resultatet er infrastruktur med ett klikk og en applikasjonsspesifikk godkjenningstest.

Ofte stilte spørsmål

Hva trenger Navidrome for en produksjonsdeployment?

Rout Navidrome-containeren på port 4533 gjennom én HTTPS-origin. Det lokale runtime-kravet er et skrivebeskyttet musikkbibliotek montert som volume, samt skrivbare applikasjonsdata. Ikke erklær Navidrome klar før du kan skanne et skrivebeskyttet musikkbibliotek, bekrefte metadata og omslagsbilder, strømme et spor gjennom en Subsonic-klient og lagre en spilleliste.

Hvilke Navidrome-data hører hjemme i en sikkerhetskopi?

Gjør /data persistent, og inkluder Navidrome-databasen, hurtigbufferen for omslagsbilder, spillelister og det opprinnelige musikkbiblioteket i det samme gjenopprettingsmanifestet. En ren Navidrome-gjenoppretting er bare vellykket når brukere, spillelister, avspillingshistorikk og metadata kommer tilbake, og den samme Subsonic-klienten strømmer et kjent spor.

Krever Navidrome HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Navidrome-originen, og behold port 4533 på den interne ruten. Bruk Navidrome-innstillingen riktig: Angi ND_BASEURL når tjenesten leveres fra en substi; ellers bør du foretrekke en dedikert HTTPS-host. For Navidrome beskytter HTTPS credentials eller brukerinnhold under transport og sørger for konsistent klientatferd som avhenger av origin.

Hvordan bør en Navidrome-oppgradering testes?

Gjenopprett gjeldende Navidrome-state i en isolert deployment, bruk kandidatversjonen og gjenta godkjenningstransaksjonen. Vær spesielt oppmerksom på at Navidromes databasemigreringer og scanner-atferd må testes mens de opprinnelige musikkfilene forblir urørt. Behold det forrige Navidrome-imaget til grensen for datamigrering og rollback er forstått.