Så self-hostar du Homarr 2026: dashboards, secrets och live tiles

En Homarr-container kan vara grön samtidigt som det användarna bryr sig om inte fungerar. För Homarr är det dolda felet oftast att widgets inte kan nå tjänster eftersom de använder lokala adresser på värden. Den här guiden utgår från att ”skapa en board, lägga till en service tile, konfigurera en credentialed integration och bekräfta live-status och sökning efter en omstart” är acceptanstestet, och bygger deploymenten bakifrån utifrån det resultatet.

Homarr har en specifik roll i stacken: en sökbar dashboard med live tiles för self-hostade tjänster. Produktionsfrågan är därför inte om port 7575 svarar en gång, utan om state, dependencies och den publika adressen fortsätter att stämma efter en omstart, uppdatering och restore.

Definiera först vad som räknas som lyckat för Homarr

Låt inte Homarr-imagen av misstag bestämma produktionsarkitekturen. Imagen tillhandahåller en process på 7575, men storage, routing och externa krav behöver fortfarande ha medvetna livscykler. Det lokala runtime-kravet är persistent appdata plus credentials för live-integrations. Detta hör hemma i planen för kapacitet och mounts, med en ansvarig och en mätbar gräns.

Deploymenten är redo för djupare testning när den kan skapa en board, lägga till en service tile, konfigurera en credentialed integration och bekräfta live-status och sökning efter en omstart. Följ transaktionen i loggarna och övervaka widget request fan-out, downstream API-latens, storleken på appdata och antalet samtidiga dashboard-klienter. Dessa observationer visar om den aktuella topologin isolerar rätt komponent.

Repetera den riskfyllda Homarr-ändringen

En grön container är nödvändig men inte tillräcklig. Service-level-indikatorn är att ”skapa en board, lägga till en service tile, konfigurera en credentialed integration och bekräfta live-status och sökning efter en omstart” slutförs, medan de sannolika belastningssignalerna är widget request fan-out, downstream API-latens, storleken på appdata och antalet samtidiga dashboard-klienter.

Change control är viktigt eftersom Homarrs schema migrations och kontinuiteten för encryption key kan påverka lagrade integration credentials. Spara den gamla imagen, testa migrations på en kopia av state och dokumentera om rollback stöds efter att schemat har flyttats. Om widgets inte kan nå tjänster eftersom de använder lokala adresser på värden, felsök den första gräns där miljön skiljer sig från den fungerande miljön.

Dokumentera en Homarr-deployment som du vet fungerar

Låt inte trafik från den första användaren vara acceptanstestet för Homarr. Förbered ofarlig sample state och kör hela åtgärden ”skapa en board, lägga till en service tile, konfigurera en credentialed integration och bekräfta live-status och sökning efter en omstart”. Notera den exakta publika URL:en, resultatet, image-referensen och det loggintervall som hör till körningen.

Byt ut containern och upprepa utan att bygga om data. Återställ därefter på en tom värd; återställningsvillkoret är att boards, users, integrations och custom assets kommer tillbaka och att credentialed widgets ansluter igen. Observera widget request fan-out, downstream API-latens, storleken på appdata och antalet samtidiga dashboard-klienter i varje körning, och definiera en alert utifrån försämring av transaktionen i stället för utifrån metrics från en idle container.

En sista kontroll ska medvetet misslyckas: skicka ofarlig input nära resurs- eller formatgränsen som hör till denna gräns: widgets kan inte nå tjänster eftersom de använder lokala adresser på värden. Kontrollera att Homarr-meddelandet som uppstår identifierar den relevanta gränsen i stället för att radera data eller starta om utan slut. Återställ det giltiga tillståndet och bekräfta att samma sample-transaktion lyckas. Ha kvar denna korta övning i release-checklistan.

Kör den första produktionsliknande instansen

Den första containern ska vara enkel att ta bort och skapa på nytt. Håll data borta från det skrivbara lagret, bind port 7575 endast där proxyn kan nå den och skicka konfiguration vid 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 imagen efter det första testet. Läs det tidigaste startup-felet i stället för det sista omstartsmeddelandet, verifiera varje mount med docker inspect och följ loggarna medan du skapar en board, lägger till en service tile, konfigurerar en credentialed integration och bekräftar live-status och sökning efter en omstart. Den sekvensen skiljer ett felaktigt image-kommando från ett dependency- eller rättighetsproblem.

Volumes är bara det första återställningslagret

För Homarr börjar säker redeployment med boards, users, integrations, secrets och custom assets. Moun­ta /appdata före bootstrap, skriv ofarlig sample data och byt ut containern för att bevisa att sökvägen faktiskt är persistent. Testa sökvägen genom att byta ut containern medan ofarlig sample data finns kvar; då upptäcks mounts som pekar en katalog för högt eller lågt.

Testa därefter disaster recovery på en tom värd. Använd en applikationskonsistent database export där det behövs och verifiera att boards, users, integrations och custom assets kommer tillbaka och att credentialed widgets ansluter igen. Guiden om database backuper som har återställts ger ett starkare mål än att bara kontrollera att en archive-fil skapades.

Låt inte proxy-success dölja fel i applikationen

Webbläsaren, API-klienten och Homarr måste vara överens om en och samma origin. För att säkerställa det anger du det externa HTTPS-värdnamnet och tillåtna origins. Behåll den ursprungliga hosten och protokollet, samtidigt som port 7575 inte är tillgänglig som en konkurrerande publik adress.

Guiden för felsökning när webbplatsen ligger nere hjälper dig att skilja en route som inte kan nås från en applikation som svarar. Den skillnaden är viktig här: widgets kan inte nå tjänster eftersom de använder lokala adresser på värden. Endast det förstnämnda åtgärdas med ingress-ändringar; det sistnämnda kräver inspektion av Homarrs loggar, state eller workload.

Stäng tillfällig åtkomst för setup

En säker Homarr-deployment börjar med att ta bort behörigheter. Undvik att ändra encryption key efter att integration secrets har lagrats. Håll i stället SECRET_ENCRYPTION_KEY stabil, skydda redigering av boards och begränsa varje widget credential till minsta möjliga scope.

Generera SECRET_ENCRYPTION_KEY en gång, håll den utanför Git och spara den tillsammans med recovery-manifestet eftersom en ändring kan göra krypterad eller signerad applikations-state ogiltig. Begränsa administrativa routes, använd private DNS för dependencies och granska varje bind mount. När loggar skickas till en central tjänst ska du filtrera secrets och privat innehåll innan de lämnar servern.

Flytta det repeterbara infrastrukturarbetet till Dockup

För Homarr är Dockup mest användbart i gränsen mellan en image och en durable service. Det håller route till 7575, TLS, secret-värden och storage kopplade över containerbyten, oavsett om compute tillhandahålls av Dockup eller av din anslutna server.

Avsluta med applikationskunskap: ange det externa HTTPS-värdnamnet och tillåtna origins; bekräfta det lokala kravet – persistent appdata plus credentials för live-integrations – och kör denna verifiering: skapa en board, lägg till en service tile, konfigurera en credentialed integration och bekräfta live-status och sökning efter en omstart. Spara resultatet som en deployment-kontroll så att nästa image-uppdatering bedöms utifrån beteende i stället för containerstatus.

Vanliga frågor

Vad behöver Homarr för en produktionsdeployment?

Routa Homarr-containern på port 7575 genom en enda HTTPS-origin. Det lokala runtime-kravet är persistent appdata plus credentials för live-integrations. Kalla inte Homarr redo förrän du kan skapa en board, lägga till en service tile, konfigurera en credentialed integration och bekräfta live-status och sökning efter en omstart.

Vilken Homarr-data ska ingå i en backup?

Gör /appdata persistent och inkludera boards, users, integrations, secrets och custom assets i samma recovery-manifest. En ren Homarr-restore är godkänd först när boards, users, integrations och custom assets kommer tillbaka och credentialed widgets ansluter igen.

Kräver Homarr HTTPS bakom en reverse proxy?

Använd HTTPS för den publika Homarr-originen och behåll port 7575 på den interna routen. Använd Homarr-inställningen korrekt: ange det externa HTTPS-värdnamnet och tillåtna origins. För Homarr skyddar HTTPS credentials eller användarinnehåll under överföring och håller origin-känsligt klientbeteende konsekvent.

Hur ska en Homarr-uppgradering testas?

Återställ aktuell Homarr-state till en isolerad deployment, applicera kandidatversionen och upprepa dess acceptanstransaktion. Var särskilt uppmärksam eftersom Homarrs schema migrations och kontinuiteten för encryption key kan påverka lagrade integration credentials. Behåll den föregående Homarr-imagen tills gränsen för data migration och rollback är förstådd.