Sådan hoster du Homarr selv i 2026: Dashboards, secrets og live-fliser

En Homarr-container kan være grøn, selv om den funktion, brugerne faktisk er afhængige af, er gået i stykker. I Homarr skyldes den skjulte fejl typisk, at widgets ikke kan nå tjenester, fordi de bruger host-lokale adresser. Denne guide bruger “opret et board, tilføj en serviceflise, konfigurér én integration med credentials, og bekræft live-status og søgning efter en genstart” som acceptancetest og bygger deploymentet baglæns ud fra det resultat.

Homarr har en specifik rolle i stacken: et søgbart dashboard med live-fliser til self-hostede tjenester. Produktionsspørgsmålet er derfor ikke, om port 7575 svarer én gang, men om state, dependencies og den offentlige adresse fortsat stemmer overens efter en genstart, opdatering og restore.

Definér først, hvad succes betyder for Homarr

Lad ikke Homarr-imaget ved et tilfælde bestemme produktionsarkitekturen. Imaget leverer en proces på 7575; storage, routing og eksterne krav skal stadig have bevidste livscyklusser. Kravet til det lokale runtime-miljø er persistent app-data plus credentials til live-integrationer. Det hører hjemme i planen for kapacitet og mounts, med en ansvarlig ejer og en målbar grænse.

Deploymentet er klar til mere dybdegående test, når det kan oprette et board, tilføje en serviceflise, konfigurere én integration med credentials og bekræfte live-status og søgning efter en genstart. Følg transaktionen i logs, og hold øje med widget-request-fan-out, downstream API-latency, størrelsen på app-data og antallet af samtidige dashboard-klienter. Observationerne viser, om den aktuelle topologi isolerer den rigtige komponent.

Øv den risikofyldte Homarr-ændring

En grøn container er nødvendig, men ikke tilstrækkelig. Service-level-indikatoren er en vellykket gennemførelse af “opret et board, tilføj en serviceflise, konfigurér én integration med credentials, og bekræft live-status og søgning efter en genstart”, mens de sandsynlige belastningssignaler er widget-request-fan-out, downstream API-latency, størrelsen på app-data og antallet af samtidige dashboard-klienter.

Change control er vigtigt, fordi Homarr-schema-migrationer og kontinuiteten i encryption key kan påvirke gemte integrationscredentials. Bevar det gamle image, test migrationer på en kopi af state, og dokumentér, om rollback understøttes, efter at schemaet er flyttet. Hvis widgets ikke kan nå tjenester, fordi de bruger host-lokale adresser, skal du diagnosticere den første grænse, der adskiller sig fra det fungerende miljø.

Dokumentér et kendt velfungerende Homarr-deployment

Lad ikke trafik fra den første bruger være acceptancetesten for Homarr. Forbered ufarlig eksempel-state, og kør hele handlingen “opret et board, tilføj en serviceflise, konfigurér én integration med credentials, og bekræft live-status og søgning efter en genstart”. Notér den nøjagtige offentlige URL, resultatet, image-referencen og det log-interval, der er knyttet til kørslen.

Erstat containeren, og gentag uden at genopbygge data. Gendan derefter på en tom host; recovery-betingelsen er, at boards, brugere, integrationer og custom assets kommer tilbage, og at widgets med credentials forbinder igen. Observer widget-request-fan-out, downstream API-latency, størrelsen på app-data og antallet af samtidige dashboard-klienter i hver gennemgang, og definér en alarm omkring forringelse af transaktionen i stedet for omkring idle container-metrics.

Én sidste kontrol bør fejle med vilje: indsend ufarligt input tæt på den ressource- eller formatgrænse, der er knyttet til denne grænse: widgets kan ikke nå tjenester, fordi de bruger host-lokale adresser. Kontrollér, at den resulterende Homarr-meddelelse identificerer den relevante grænse i stedet for at udløse sletning af data eller en endeløs genstart. Gendan den gyldige tilstand, og bekræft, at den samme eksempeltransaktion lykkes. Bevar denne korte øvelse i release-checklisten.

Kør den første produktionslignende instans

Den første container skal være nem at slette og oprette igen. Hold data væk fra det skrivbare layer, bind kun port 7575 dér, hvor proxyen kan nå den, og send konfigurationen ind 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

Fastlås imaget efter den indledende test. Læs den tidligste startup-fejl i stedet for den sidste restart-meddelelse, verificér hvert mount med docker inspect, og følg logs, mens du opretter et board, tilføjer en serviceflise, konfigurerer én integration med credentials og bekræfter live-status og søgning efter en genstart. Sekvensen skelner mellem en forkert image-kommando og et problem med en dependency eller permissions.

Volumes er kun det første recovery-lag

For Homarr begynder sikkerheden ved redeploy med boards, brugere, integrationer, secrets og custom assets. Mount /appdata før bootstrap, skriv ufarlige eksempeldata, og erstat containeren for at bevise, at stien faktisk er persistent. Test stien ved at erstatte containeren, mens de ufarlige eksempeldata stadig findes; det afslører mounts, der peger én mappe for højt eller lavt.

Test derefter disaster recovery på en tom host. Brug om nødvendigt et application-consistent database-export, og verificér, at boards, brugere, integrationer og custom assets kommer tilbage, og at widgets med credentials forbinder igen. Guiden til database-backups, du har testet restore af giver et stærkere mål end blot at kontrollere, at der blev oprettet en archive-fil.

Undgå, at proxy-succes skjuler fejl i applikationen

Browseren, API-klienten og Homarr skal være enige om én origin. For at sikre det skal du angive det eksterne HTTPS-hostnavn og de tilladte origins. Bevar den oprindelige host og protokol, og sørg samtidig for, at port 7575 ikke er tilgængelig som en konkurrerende offentlig adresse.

Guiden til fejlfinding, når sitet er nede hjælper med at skelne mellem en utilgængelig route og en applikation, der svarer. Den skelnen er vigtig her: widgets kan ikke nå tjenester, fordi de bruger host-lokale adresser. Kun det første problem løses med ændringer i ingress; det andet kræver inspektion af Homarr-logs, state eller workload.

Luk midlertidig adgang under opsætningen

Et sikkert Homarr-deployment begynder med at fjerne privilegier. Undgå at ændre encryption key, efter at integrationssecrets er gemt; hold i stedet SECRET_ENCRYPTION_KEY stabil, beskyt redigering af boards, og begræns hvert widget-credential til det nødvendige.

Generér SECRET_ENCRYPTION_KEY én gang, hold den ude af Git, og bevar den sammen med recovery-manifestet, fordi en ændring kan gøre krypteret eller signeret application state ugyldig. Begræns administrative routes, brug private DNS-navne til dependencies, og gennemgå hvert bind mount. Når logs sendes centralt, skal secrets og privat indhold filtreres, før de forlader serveren.

Flyt det gentagelige infrastrukturarbejde til Dockup

For Homarr er Dockup mest nyttig i grænsefladen mellem et image og en durable service. Den holder route til 7575, TLS, secret-værdier og storage tilknyttet på tværs af containerudskiftninger, uanset om compute leveres af Dockup eller af din tilknyttede server.

Afslut med applikationsviden: angiv det eksterne HTTPS-hostnavn og de tilladte origins; bekræft det lokale krav — persistent app-data plus credentials til live-integrationer; og kør denne verifikation: opret et board, tilføj en serviceflise, konfigurér én integration med credentials, og bekræft live-status og søgning efter en genstart. Gem resultatet som et deployment-check, så den næste image-opdatering vurderes ud fra adfærd i stedet for containerstatus.

Ofte stillede spørgsmål

Hvad skal Homarr bruge til et produktionsdeployment?

Route Homarr-containeren på port 7575 gennem én HTTPS-origin. Kravet til det lokale runtime-miljø er persistent app-data plus credentials til live-integrationer. Kald ikke Homarr klar, før du kan oprette et board, tilføje en serviceflise, konfigurere én integration med credentials og bekræfte live-status og søgning efter en genstart.

Hvilke Homarr-data skal med i en backup?

Gør /appdata persistent, og medtag boards, brugere, integrationer, secrets og custom assets i det samme recovery-manifest. En ren Homarr-restore er først godkendt, når boards, brugere, integrationer og custom assets er kommet tilbage, og widgets med credentials forbinder igen.

Kræver Homarr HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Homarr-origin, og behold port 7575 på den interne route. Anvend Homarr-indstillingen korrekt: angiv det eksterne HTTPS-hostnavn og de tilladte origins. For Homarr beskytter HTTPS credentials eller brugerindhold under transport og sikrer en ensartet origin-følsom client-adfærd.

Hvordan skal en Homarr-opgradering testes?

Gendan den aktuelle Homarr-state i et isoleret deployment, anvend kandidatversionen, og gentag dens acceptancetransaktion. Vær særligt opmærksom, fordi Homarr-schema-migrationer og kontinuiteten i encryption key kan påvirke gemte integrationscredentials. Behold det tidligere Homarr-image, indtil grænserne for datamigration og rollback er forstået.