Så kör du Homepage själv 2026: tillåtna värdar, widgets och konfiguration

Det finns två versioner av att ”köra Homepage”: en container existerar, eller så utför tjänsten faktiskt sitt jobb. Det är bara den andra som spelar roll. Här är beviset att läsa in tjänster och bokmärken, anropa flera live-widgets, testa sökning och starta om efter redigering av en YAML-konfigurationsfil.

Homepage fyller följande syfte: en startsida med live-widgets för self-hosted-tjänster. Driftsättningen måste bevara delarna bakom det beteendet; en port, en volym och ett certifikat är indata, inte resultatet.

Välj den minsta fungerande Homepage-topologin

Ett användbart Homepage-diagram visar den publika routen, den privata porten 3000, state-gränsen och alla stödkrav. Markera vilka pilar som transporterar autentiseringsuppgifter och vilka som är vanlig användartrafik. Det externa kravet för Homepage är skrivskyddad konfiguration samt autentiseringsuppgifter för valfria service-widgets. Testa utgående DNS, TLS och leverantörsbeteende utan att publicera ytterligare en inkommande tjänst.

Bevisa diagrammet med en verklig åtgärd: läs in tjänster och bokmärken, anropa flera live-widgets, testa sökning och starta om efter redigering av en YAML-konfigurationsfil. Den troliga belastningen kommer från widget-fan-out, långsamma nedströms-API:er, DNS-upplösning och uppdateringsfrekvensen för webbläsarens dashboard; övervaka den sökvägen i stället för att behandla alla HTTP-anrop som likvärdiga.

Uppgradera Homepage utan att gissa

Det första användbara driftmåttet för Homepage är om tjänsten kan läsa in tjänster och bokmärken, anropa flera live-widgets, testa sökning och starta om efter redigering av en YAML-konfigurationsfil. Kombinera det med mättnadssignaler för widget-fan-out, långsamma nedströms-API:er, DNS-upplösning och uppdateringsfrekvensen för webbläsarens dashboard. En processbaserad probe ska inte anropa dyra beroenden eller starta om containern bara för att en upstream-tjänst tillfälligt inte är tillgänglig.

Behandla uppgraderingar som dataändringar eftersom konfigurationsnycklar och widget-integrationer kan ändras. Validera därför YAML och leverantörsbeteende före en image-uppdatering. Lås versionerna, repetera proceduren på återställt state och behåll den föregående imagen tills en rollback fortfarande är möjlig. När värden avvisas eller YAML-indragning hindrar konfigurationen från att läsas in ska du spara loggarna från före omstarten; de innehåller vanligtvis det orsakande meddelandet.

En produktionskontroll för Homepage

Innan riktiga användare kommer till, skapa ett releaseformulär för Homepage. Det måste ange den låsta imagen, port 3000, den kanoniska origin, beständiga sökvägar samt ägaren till skrivskyddad konfiguration och autentiseringsuppgifter för valfria service-widgets. Bifoga det förväntade resultatet av denna transaktion: läs in tjänster och bokmärken, anropa flera live-widgets, testa sökning och starta om efter redigering av en YAML-konfigurationsfil.

Använd formuläret efter ett normalt byte och efter en ren återställning. Återställningen är godkänd endast om tjänster, bokmärken, widgets och anpassade tillgångar kommer tillbaka och alla kritiska widgets hanterar fel i nedströms-beroenden på ett synligt sätt. Samla också in ett kort resursmått som täcker widget-fan-out, långsamma nedströms-API:er, DNS-upplösning och uppdateringsfrekvensen för webbläsarens dashboard; spara det bredvid releasen så att framtida kapacitetsändringar jämförs med samma arbetsbelastning.

Inkludera ett kontrollerat fel: neka tillfälligt testsökvägen som används av skrivskyddad konfiguration och autentiseringsuppgifter för valfria service-widgets. Bekräfta att Homepage rapporterar problemet vid rätt gräns, återställ det giltiga tillståndet och kör transaktionen igen. Det här kontrollerar felens synlighet, inte bara framgång, och förhindrar att ett gränssnitt som ser friskt ut döljer en trasig worker, callback eller databasanslutning.

Gör Homepage-starten reproducerbar

Använd containern som en utbytbar runtime, inte som platsen där sanningen finns.

docker run -d \
  --name homepage \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v homepage-data:/app/config \
  -e HOMEPAGE_ALLOWED_HOSTS=home.example.com \
  ghcr.io/gethomepage/homepage:latest

Tillåt och verifiera den utgående eller klientsidiga sökväg som krävs för skrivskyddad konfiguration och autentiseringsuppgifter för valfria service-widgets. Inspektera containeranvändaren, skrivbara sökvägar och den bundna lyssnaren innan du exponerar tjänsten. Kör hela åtgärden — läs in tjänster och bokmärken, anropa flera live-widgets, testa sökning och starta om efter redigering av en YAML-konfigurationsfil — och spara den exakta image-referens som gav resultatet.

Separera utbytbara containers från beständig data

Den beständiga återställningsmängden består av konfigurationsfiler, bokmärken, tjänster och anpassade tillgångar. Montera /app/config före bootstrap, skriv ofarliga exempeldata och byt ut containern för att bevisa att sökvägen faktiskt är beständig. En volym skyddar data från att containern byts ut, men inte från förlust av värden, oavsiktlig radering eller korruption på applikationsnivå.

Ta säkerhetskopior som förstår datakällan: använd logiska dumpar för aktiva databaser när det krävs och kopiera filer endast från ett konsekvent tillstånd. Förvara en krypterad kopia utanför Homepage-värden. Godkännandekriteriet för en återställning är specifikt — tjänster, bokmärken, widgets och anpassade tillgångar ska komma tillbaka och alla kritiska widgets ska hantera fel i nedströms-beroenden på ett synligt sätt. Guiden till återställningstestade säkerhetskopior förklarar varför enbart ett lyckat jobb inte räcker.

Domäner, proxy-headers och port 3000

Webbläsaren, API-klienten och Homepage måste vara överens om en och samma origin. För att uppnå det ska du ange tillåtna värdar för den exakta domänen och proxy-värdnamnet. Bevara den ursprungliga värden och protokollet samtidigt som port 3000 hålls otillgänglig som en konkurrerande publik adress.

Guiden för felsökning när webbplatsen ligger nere hjälper dig att skilja en onåbar route från en applikation som svarar. Den skillnaden är viktig här: värden avvisas eller YAML-indragning hindrar konfigurationen från att läsas in. Bara det första problemet löses genom ändringar i ingressen; det andra kräver inspektion av Homepage-loggar, state eller arbetsbelastning.

Säkerhetsbeslut som är specifika för Homepage

Ärv inte säkerhetsantaganden från en lokal tutorial. Den specifika risken med Homepage är att widget-API-nycklar committas till ett publikt repository. I produktion bör du därför ange tillåtna värdar exakt och lagra widget-API-nycklar i environment eller secret-baserad konfiguration i stället för i ett publikt repository.

HOMEPAGE_ALLOWED_HOSTS styr beteendet, inte konfidentialiteten; validera dess typ och värde och lagra riktiga Homepage-autentiseringsuppgifter separat. Begränsa åtkomsten till filsystem och nätverk, skydda setup-endpoints och definiera gränser för uppladdningar, requests eller exekvering kring widget-fan-out, långsamma nedströms-API:er, DNS-upplösning och uppdateringsfrekvensen för webbläsarens dashboard.

Så minskar Dockup arbetet för Homepage

För Homepage är Dockup mest användbart vid gränsen mellan en image och en beständig tjänst. Det håller routen till 3000, TLS, secret-värden och lagring kopplade över containerbyten, oavsett om beräkningsresurserna tillhör Dockup eller din anslutna server.

Avsluta med applikationskunskap: ange tillåtna värdar för den exakta domänen och proxy-värdnamnet, tillåt och verifiera skrivskyddad konfiguration samt autentiseringsuppgifter för valfria service-widgets och kör denna verifiering: läs in tjänster och bokmärken, anropa flera live-widgets, testa sökning och starta om efter redigering av en YAML-konfigurationsfil. Spara resultatet som en driftsättningskontroll så att nästa image-uppdatering bedöms utifrån beteende i stället för containerstatus.

Vanliga frågor

Vad behöver Homepage för en produktionsdriftsättning?

Routa Homepage-containern via port 3000 genom en HTTPS-origin. Det externa leveranskravet är skrivskyddad konfiguration samt autentiseringsuppgifter för valfria service-widgets. Anse inte Homepage vara redo förrän du kan läsa in tjänster och bokmärken, anropa flera live-widgets, testa sökning och starta om efter redigering av en YAML-konfigurationsfil.

Vilken Homepage-data ska ingå i en säkerhetskopia?

Gör /app/config beständig och inkludera konfigurationsfiler, bokmärken, tjänster och anpassade tillgångar i samma återställningsmanifest. En ren Homepage-återställning är godkänd först när tjänster, bokmärken, widgets och anpassade tillgångar kommer tillbaka och alla kritiska widgets hanterar fel i nedströms-beroenden på ett synligt sätt.

Kräver Homepage HTTPS bakom en reverse proxy?

Använd HTTPS för den publika Homepage-originen och behåll port 3000 på den interna routen. Tillämpa Homepage-inställningen korrekt: ange tillåtna värdar för den exakta domänen och proxy-värdnamnet. För Homepage skyddar HTTPS autentiseringsuppgifter eller användarinnehåll under transport och håller origin-känsligt klientbeteende konsekvent.

Hur bör en Homepage-uppgradering testas?

Återställ det aktuella Homepage-statet till en isolerad driftsättning, tillämpa kandidatversionen och upprepa dess godkännandetransaktion. Var särskilt uppmärksam eftersom konfigurationsnycklar och widget-integrationer kan ändras, så validera YAML och leverantörsbeteende före en image-uppdatering. Behåll den föregående Homepage-imagen tills dess datamigrerings- och rollback-gräns är förstådd.