Slik selvhoster du File Browser i 2026: Volumer, kontoer og trygg deling
En praktisk guide til selvhosting av File Browser med Docker, porter, vedvarende data, TLS, sikkerhet, sikkerhetskopier og feilene som hindrer produksjonsbruk.
Behandle File Browser som et lite system, ikke som et Docker-image. Målet for brukeren av File Browser er tydelig: en webbasert filbehandler for et tilkoblet volum. Distribusjonen er bare akseptabel når du kan opprette en begrenset bruker, laste opp og gi nytt navn til en fil, redigere tekst, generere en deling og bekrefte at brukeren ikke kan komme seg utenfor det tildelte rotområdet.
Dette skiller ut feilen operatører møter etter lokal testing: De monterte filene bruker filtillatelser fra vertsmaskinen som containeren ikke kan lese. Det gjør også planen for sikkerhetskopiering og oppgradering konkret nok til å testes.
Finn alle vedvarende byte i File Browser
Et container-image kan lastes ned på nytt. Filene som leveres, samt File Browser-databasen og innstillingene, kan ikke det. Monter /srv før oppstart, skriv noen ufarlige eksempeldata og erstatt containeren for å bevise at banen faktisk er vedvarende. Inspiser det effektive mountet i stedet for å stole på et Compose-filnavn, og kontroller at runtime-brukeren kan skrive der File Browser forventer det.
Velg oppbevaringsperiode og en ekstern destinasjon, og øv deretter på gjenoppretting uten å berøre produksjonen. Øvelsen er godkjent først når filene som leveres, brukere, scopes, delinger og innstillinger er tilbake, og en begrenset konto fortsatt er avgrenset. For databasedrevet tilstand bør du kombinere lagringssnapshots med applikasjonskonsistente eksporter, som beskrevet i gjenoppretting til et bestemt tidspunkt kontra snapshots.
Kjør den første produksjonslignende instansen
Hold den første File Browser-oppstarten så reproduserbar at den kan gjennomgås i en pull request.
docker run -d \
--name file-browser \
--restart unless-stopped \
-p 127.0.0.1:80:80 \
-v file-browser-data:/srv \
-v file-browser-db:/database \
-v file-browser-config:/config \
filebrowser/filebrowser:latest
Ikke stol på latest etter at du har fått virkelige data. Dokumenter digest-en som fungerer, container-brukeren og eierskapet til mountene. Følg applikasjonsloggen gjennom en fullstendig test — opprett en begrenset bruker, last opp og gi nytt navn til en fil, rediger tekst, generer en deling og bekreft at brukeren ikke kan komme seg utenfor det tildelte rotområdet — og noter eventuelle migreringer før du legger ruten bak produks_jonstrafikk.
Tegn opp runtime-grensen for File Browser
Prosesshelse og produkthelse er to forskjellige ting for File Browser. Port 80 kan svare selv om brukertransaksjonen fortsatt mislykkes. Det lokale runtime-kravet er en separat vedvarende bane for databasen og innstillingene. Valider dette med den faktiske godkjenningsbelastningen. En inaktiv health check kan ikke bevise at ressursen er tilstrekkelig.
Bruk denne readiness-øvelsen etter vesentlige konfigurasjonsendringer: opprett en begrenset bruker, last opp og gi nytt navn til en fil, rediger tekst, generer en deling og bekreft at brukeren ikke kan komme seg utenfor det tildelte rotområdet. Hold kostbare eksterne kontroller utenfor liveness-prober, slik at et leverandørutfall ikke fører til en restart-loop. Kapasitetsarbeidet bør følge underliggende disk-ytelse, opplastingsstørrelse, samtidige nedlastinger og antall kataloger. Dette ligger nærmere File Browsers reelle belastning enn sideforespørsler.
Gjør det offentlige opphavet entydig
Eksponer ett HTTPS-vertsnavn for File Browser, og hold rå port 80 privat. Publiser brukergrensesnittet over HTTPS, men avgrens rotområdet som leveres nøye. Dette hindrer nettlesere og API-klienter i å lære to konkurrerende adresser.
Kjør den kjente, fungerende transaksjonen fra en ren klient, og inspiser den første forespørselen som feiler. Bruk guiden for egendefinert domene når DNS eller TLS er feil. Behandle «de monterte filene bruker filtillatelser fra vertsmaskinen som containeren ikke kan lese» som en separat applikasjonsdiagnose når ruten er bekreftet.
Utrullingskontrollen for File Browser
Opprett en liten, midlertidig File Browser-testinstallasjon og behold den for hver release. Testinstallasjonen bør dekke den faktiske arbeidsflyten: opprett en begrenset bruker, last opp og gi nytt navn til en fil, rediger tekst, generer en deling og bekreft at brukeren ikke kan komme seg utenfor det tildelte rotområdet. Dokumenter image-digest, eksternt vertsnavn, avhengighetsadresse og forventet resultat, slik at en senere operatør kan gjenta testen uten å tolke denne veiledningen.
Kjør testinstallasjonen tre ganger. Først bruker du den nye distribusjonen. Deretter erstatter du containeren uten å berøre vedvarende tilstand. Til slutt gjenoppretter du sikkerhetskopien i et tomt miljø. Den tredje kjøringen er godkjent først når filene som leveres, brukere, scopes, delinger og innstillinger er tilbake, og en begrenset konto fortsatt er avgrenset. Registrer ventetid og ressursbruk rundt underliggende disk-ytelse, opplastingsstørrelse, samtidige nedlastinger og antall kataloger under hver kjøring. Dette blir grunnlaget for varsler, i stedet for en vilkårlig CPU-prosent.
Test til slutt den negative banen med hensikt: send ufarlige data nær ressurs- eller formatgrensen som gjelder for denne avgrensningen: de monterte filene bruker filtillatelser fra vertsmaskinen som containeren ikke kan lese. Bekreft at File Browser feiler synlig uten å ødelegge tilstanden, gjenopprett riktig tilstand og gjenta den vellykkede transaksjonen. En release-post som inneholder disse fire resultatene, er sterkere dokumentasjon enn skjermbilder av et dashboard eller et enkelt curl-svar.
Kontroller kapasitet og oppgraderinger
En inaktiv health check sier lite om File Browser. Følg med på underliggende disk-ytelse, opplastingsstørrelse, samtidige nedlastinger og antall kataloger, og varsle på symptomet brukerne faktisk opplever: at handlingen «opprett en begrenset bruker, last opp og gi nytt navn til en fil, rediger tekst, generer en deling og bekreft at brukeren ikke kan komme seg utenfor det tildelte rotområdet» mislykkes. Hold liveness lokal og enkel, og la readiness rapportere migreringer eller initialisering uten å utløse en restart-storm.
Det risikable ved en oppgradering er at migreringer av File Browser-databasen og innstillingene er viktige, selv om filene som leveres, ligger på et separat mount. Les release-notater, ta et snapshot av tilstanden, distribuer målversjonen mot en gjenopprettet kopi og gjenta godkjenningshandlingen. Hvis de monterte filene bruker filtillatelser fra vertsmaskinen som containeren ikke kan lese, bør du koble klientforespørselen til den første relevante applikasjonsloggen i stedet for å slette tilstand eller legge til redirects uten videre.
Begrens privilegiene File Browser har
Bootstrap-legitimasjon er midlertidig, men tillitsmodellen er permanent. For File Browser bør du passe på at du ikke leverer / eller en katalog med secrets i stedet for en dedikert deling, og levere en dedikert katalog i stedet for vertens rotkatalog. Gi hver konto det smaleste filomfanget den trenger.
File Browser har ingen obligatorisk bootstrap-hemmelighet i denne grunnkonfigurasjonen. Beskytt i stedet den faktiske administratorkontoen eller autentiseringen oppstrøms. Kjør imaget uten unødvendige Linux-funksjoner, og eksponer bare den offentlige applikasjonsruten. Sørg for at administratoraktivitet er synlig uten å logge hemmelige verdier.
Bruk Dockup for plattformlaget
For File Browser er Dockup mest nyttig i grensesnittet mellom et image og en vedvarende tjeneste. Det holder ruten til port 80, TLS, hemmelige verdier og lagring tilkoblet gjennom containerutskiftninger, uavhengig av om compute-ressursene tilhører Dockup eller den tilkoblede serveren din.
Avslutt med applikasjonskunnskap: publiser brukergrensesnittet over HTTPS, men avgrens rotområdet som leveres nøye; bekreft det lokale kravet — en separat vedvarende bane for databasen og innstillingene; og kjør denne verifiseringen: opprett en begrenset bruker, last opp og gi nytt navn til en fil, rediger tekst, generer en deling og bekreft at brukeren ikke kan komme seg utenfor det tildelte rotområdet. Behold resultatet som en utrullingskontroll, slik at neste image-oppdatering vurderes etter funksjonalitet og ikke containerstatus.
Ofte stilte spørsmål
Hva trenger File Browser for en produksjonsdistribusjon?
Rout File Browser-containeren på port 80 gjennom ett HTTPS-opphav. Det lokale runtime-kravet er en separat vedvarende bane for databasen og innstillingene. Ikke erklær File Browser klar før du kan opprette en begrenset bruker, laste opp og gi nytt navn til en fil, redigere tekst, generere en deling og bekrefte at brukeren ikke kan komme seg utenfor det tildelte rotområdet.
Hvilke File Browser-data hører hjemme i en sikkerhetskopi?
Gjør /srv vedvarende, og inkluder filene som leveres, samt File Browser-databasen og innstillingene, i det samme gjenopprettingsmanifestet. En ren File Browser-gjenoppretting er godkjent først når filene som leveres, brukere, scopes, delinger og innstillinger er tilbake, og en begrenset konto fortsatt er avgrenset.
Krever File Browser HTTPS bak en reverse proxy?
Bruk HTTPS for det offentlige File Browser-opphavet, og hold port 80 på den interne ruten. Bruk File Browser-innstillingen riktig: publiser brukergrensesnittet over HTTPS, men avgrens rotområdet som leveres nøye. For File Browser beskytter HTTPS legitimasjon eller brukerinnhold under overføring og sørger for konsistent klientatferd som er avhengig av opphavet.
Hvordan bør en File Browser-oppgradering testes?
Gjenopprett gjeldende File Browser-tilstand i en isolert distribusjon, bruk kandidatversjonen og gjenta godkjenningstransaksjonen. Vær spesielt oppmerksom på dette, fordi migreringer av File Browser-databasen og innstillingene er viktige, selv om filene som leveres, ligger på et separat mount. Behold det forrige File Browser-imaget til grensen for datamigrering og rollback er forstått.