JournalindeksDockup / feltnotat
Note / self-host-homarr

Slik self-hoster du Homarr i 2026: Dashbord, hemmeligheter og live-fliser

En praktisk guide til self-hosting av Homarr med Docker, porter, persistent data, TLS, sikkerhet, sikkerhetskopiering og feilene som hindrer produksjonsbruk. Steg for steg.

En Homarr-container kan være grønn selv om funksjonen brukerne bryr seg om, er ødelagt. For Homarr er den skjulte feilen vanligvis at widgets ikke får kontakt med tjenester fordi de bruker adresser som bare fungerer lokalt på verten. Denne guiden bruker «opprett et board, legg til en tjenesteflis, konfigurer én integrasjon med credentials og bekreft live-status og søk etter omstart» som akseptansetest, og bygger utrullingen bakover fra dette resultatet.

Homarr har en spesifikk rolle i stacken: et søkbart dashbord med live-fliser for self-hostede tjenester. Produksjonsspørsmålet er derfor ikke om port 7575 svarer én gang, men om state, avhengigheter og den offentlige adressen fortsatt stemmer overens etter en omstart, oppdatering og gjenoppretting.

Definer hva som er vellykket for Homarr først

Ikke la Homarr-imaget velge produksjonsarkitekturen ved et uhell. Imaget leverer en prosess på 7575; lagring, ruting og eksterne krav trenger fortsatt bevisste livssykluser. Kravet til det lokale runtime-miljøet er persistent appdata pluss credentials for live-integrasjoner. Dette hører hjemme i planen for kapasitet og mounts, med en eier og en målbar grense.

Utrullingen er klar for grundigere testing når den kan opprette et board, legge til en tjenesteflis, konfigurere én integrasjon med credentials og bekrefte live-status og søk etter omstart. Følg transaksjonen i loggene og følg med på fan-out for widget-forespørsler, latency mot downstream-API-er, størrelsen på appdata og samtidige dashbordklienter. Disse observasjonene viser om den nåværende topologien isolerer riktig komponent.

Øv på den risikable Homarr-endringen

En grønn container er nødvendig, men ikke tilstrekkelig. Tjenesteindikatoren er vellykket gjennomføring av «opprett et board, legg til en tjenesteflis, konfigurer én integrasjon med credentials og bekreft live-status og søk etter omstart», mens de sannsynlige belastningssignalene er fan-out for widget-forespørsler, latency mot downstream-API-er, størrelsen på appdata og samtidige dashbordklienter.

Endringskontroll er viktig fordi Homarr-skjemamigreringer og kontinuitet for krypteringsnøkler kan påvirke lagrede integrasjonscredentials. Behold det gamle imaget, test migreringer på en kopi av state og dokumenter om rollback støttes etter at skjemaet er flyttet. Hvis widgets ikke får kontakt med tjenester fordi de bruker adresser som bare fungerer lokalt på verten, må du diagnostisere den første grensen som avviker fra miljøet som fungerer.

Dokumenter en Homarr-utrulling du vet fungerer

Ikke bruk trafikk fra de første brukerne som akseptansetest for Homarr. Forbered ufarlig eksempeldata og kjør hele handlingen «opprett et board, legg til en tjenesteflis, konfigurer én integrasjon med credentials og bekreft live-status og søk etter omstart». Noter den nøyaktige offentlige URL-en, resultatet, imagereferansen og loggintervallet som er knyttet til kjøringen.

Bytt ut containeren og gjenta uten å bygge data på nytt. Gjenopprett deretter til en tom vert; gjenopprettingskravet er at boards, brukere, integrasjoner og egendefinerte ressurser kommer tilbake, og at widgets med credentials kobler seg til igjen. Følg med på fan-out for widget-forespørsler, latency mot downstream-API-er, størrelsen på appdata og samtidige dashbordklienter i hver gjennomgang, og definer et varsel rundt forringelse av transaksjonen i stedet for rundt inaktive containermålinger.

Én siste kontroll bør feile med vilje: send ufarlig input nær ressurs- eller formatgrensen som er knyttet til denne grensen: widgets får ikke kontakt med tjenester fordi de bruker adresser som bare fungerer lokalt på verten. Bekreft at Homarr-meldingen som oppstår, identifiserer den relevante grensen i stedet for å utløse sletting av data eller en endeløs omstart. Gjenopprett den gyldige tilstanden og bekreft at den samme eksempeltransaksjonen lykkes. Ta med denne korte øvelsen i release-sjekklisten.

Kjør den første produksjonslignende instansen

Den første containeren bør være enkel å slette og opprette på nytt. Hold data utenfor det skrivbare laget, bind port 7575 bare der proxien kan nå den, og send konfigurasjon ved runtime.

docker run -d \
  --name homarr \
  --restart unless-stopped \
  -p 127.0.0.1:7575:7575 \
  -v homarr-data:/appdata \
  -e SECRET_ENCRYPTION_KEY=replace-with-a-long-random-value \
  ghcr.io/homarr-labs/homarr:latest

Lås imaget etter den første testen. Les den tidligste oppstartsfeilen i stedet for den siste omstartsmeldingen, bekreft hvert mount med docker inspect, og følg loggene mens du oppretter et board, legger til en tjenesteflis, konfigurerer én integrasjon med credentials og bekrefter live-status og søk etter omstart. Denne sekvensen skiller en feil i image-kommandoen fra et problem med avhengigheter eller tillatelser.

Volumes er bare det første laget i gjenopprettingen

For Homarr starter sikker redeploy med boards, brukere, integrasjoner, hemmeligheter og egendefinerte ressurser. Mount /appdata før bootstrap, skriv ufarlige eksempeldata og bytt ut containeren for å bevise at denne banen faktisk er persistent. Test banen ved å bytte ut containeren mens ufarlige eksempeldata fortsatt finnes; dette avdekker mounts som peker én katalog for høyt eller lavt.

Test deretter disaster recovery på en tom vert. Bruk en applikasjonskonsistent databaseeksport når det er nødvendig, og bekreft at boards, brukere, integrasjoner og egendefinerte ressurser kommer tilbake, og at widgets med credentials kobler seg til igjen. Guiden for sikkerhetskopiering av databaser som faktisk er gjenopprettet gir et bedre mål enn bare å kontrollere at en arkivfil ble opprettet.

Hindre at vellykket proxy skjuler feil i applikasjonen

Nettleseren, API-klienten og Homarr må være enige om én origin. For å sikre dette angir du det eksterne HTTPS-vertsnavnet og tillatte origins. Bevar den opprinnelige hosten og protokollen, samtidig som port 7575 ikke er tilgjengelig som en konkurrerende offentlig adresse.

Guiden for feilsøking av et nettsted som er nede hjelper deg med å skille en utilgjengelig route fra en applikasjon som svarer. Dette skillet er viktig her: widgets får ikke kontakt med tjenester fordi de bruker adresser som bare fungerer lokalt på verten. Bare det første problemet løses med endringer i ingress; det andre krever inspeksjon av Homarr-logger, state eller workload.

Steng midlertidig tilgang for oppsett

En sikker Homarr-utrulling starter med å fjerne tilgangsnivåer. Unngå å endre krypteringsnøkkelen etter at integrasjonshemmeligheter er lagret; hold i stedet SECRET_ENCRYPTION_KEY stabil, beskytt redigering av boards og begrens hvert enkelt widget-credential til nødvendig omfang.

Generer SECRET_ENCRYPTION_KEY én gang, hold den utenfor Git og bevar den sammen med gjenopprettingsmanifestet, fordi en endring kan gjøre kryptert eller signert applikasjons-state ugyldig. Begrens administrative routes, bruk privat DNS for avhengigheter og gå gjennom hvert bind mount. Når logger sendes til et sentralt system, må du filtrere bort hemmeligheter og privat innhold før de forlater serveren.

Flytt det repeterbare infrastrukturarbeidet til Dockup

For Homarr er Dockup mest nyttig i grensen mellom et image og en persistent tjeneste. Dockup holder routen til 7575, TLS, secret-verdier og lagring tilknyttet gjennom utskifting av containere, enten compute-ressursene tilhører Dockup eller den tilkoblede serveren din.

Avslutt med applikasjonskunnskap: angi det eksterne HTTPS-vertsnavnet og tillatte origins; bekreft det lokale kravet — persistent appdata pluss credentials for live-integrasjoner; og kjør denne verifiseringen: opprett et board, legg til en tjenesteflis, konfigurer én integrasjon med credentials og bekreft live-status og søk etter omstart. Behold resultatet som en utrullingssjekk, slik at neste image-oppdatering vurderes etter funksjon og ikke etter containerstatus.

Vanlige spørsmål

Hva trenger Homarr for en produksjonsutrulling?

Rout Homarr-containeren på port 7575 gjennom én HTTPS-origin. Kravet til det lokale runtime-miljøet er persistent appdata pluss credentials for live-integrasjoner. Ikke regn Homarr som klar før du kan opprette et board, legge til en tjenesteflis, konfigurere én integrasjon med credentials og bekrefte live-status og søk etter omstart.

Hvilke Homarr-data bør inngå i en sikkerhetskopi?

Gjør /appdata persistent, og inkluder boards, brukere, integrasjoner, hemmeligheter og egendefinerte ressurser i det samme gjenopprettingsmanifestet. En ren Homarr-gjenoppretting er bare vellykket når boards, brukere, integrasjoner og egendefinerte ressurser kommer tilbake, og widgets med credentials kobler seg til igjen.

Krever Homarr HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Homarr-originen, og behold port 7575 på den interne routen. Bruk Homarr-innstillingen riktig: angi det eksterne HTTPS-vertsnavnet og tillatte origins. For Homarr beskytter HTTPS credentials eller brukerinnhold under overføring og sørger for konsistent klientoppførsel som er avhengig av origin.

Hvordan bør en Homarr-oppgradering testes?

Gjenopprett gjeldende Homarr-state til en isolert utrulling, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom, fordi Homarr-skjemamigreringer og kontinuitet for krypteringsnøkler kan påvirke lagrede integrasjonscredentials. Behold det forrige Homarr-imaget til grensene for datamigrering og rollback er forstått.