Slik selvhoster du Homepage i 2026: tillatte verter, widgets og konfigurasjon
En praktisk guide til selvhosting av Homepage, med Docker, porter, persistent data, TLS, sikkerhet, sikkerhetskopier og feil som hindrer produksjonsbruk. Med sjekker.
Det finnes to versjoner av «å kjøre Homepage»: en container finnes, eller tjenesten gjør den faktiske jobben sin. Det er bare den andre som teller. Her er beviset at du laster inn tjenester og bokmerker, kaller flere live-widgets, tester søk og starter på nytt etter at du har redigert en YAML-konfigurasjonsfil.
Homepage har dette formålet: en startside med live-widgets for selvhostede tjenester. Deployeringen må bevare delene som ligger bak denne funksjonaliteten; en port, et volum og et sertifikat er inndata – ikke resultatet.
Velg den minste brukbare Homepage-topologien
Et nyttig Homepage-diagram viser den offentlige ruten, den private porten 3000, tilstandsgrensen og alle støttende krav. Marker hvilke piler som overfører credentials, og hvilke som er vanlig brukertrafikk. Det eksterne kravet for Homepage er skrivebeskyttet konfigurasjon samt credentials for valgfrie service-widgets. Test utgående DNS, TLS og provider-adferd uten å publisere enda en innkommende tjeneste.
Bevis diagrammet med én reell handling: last inn tjenester og bokmerker, kall flere live-widgets, test søk og start på nytt etter at du har redigert en YAML-konfigurasjonsfil. Den sannsynlige belastningen kommer fra widget-fan-out, trege downstream-API-er, DNS-oppløsning og oppdateringsfrekvensen til nettleserdashboardet. Overvåk denne banen i stedet for å behandle alle HTTP-forespørsler likt.
Oppgrader Homepage uten gjetting
Den første nyttige driftsmålingen for Homepage er om den kan laste inn tjenester og bokmerker, kalle flere live-widgets, teste søk og starte på nytt etter at du har redigert en YAML-konfigurasjonsfil. Kombiner dette med metningssignaler for widget-fan-out, trege downstream-API-er, DNS-oppløsning og oppdateringsfrekvensen til nettleserdashboardet. En prosessbasert probe bør ikke kalle kostbare avhengigheter eller starte containeren på nytt fordi en upstream-tjeneste er utilgjengelig en kort stund.
Behandle oppgraderinger som dataendringer fordi konfigurasjonsnøkler og widget-integrasjoner kan endres. Valider derfor YAML og provider-adferd før en image-oppdatering. Lås versjoner, øv på gjenoppretting av state og behold det forrige imaget tilgjengelig til en rollback fortsatt er gyldig. Når verten avvises eller YAML-innrykk hindrer innlasting av konfigurasjonen, må du ta vare på loggene fra før omstarten; de inneholder vanligvis den utløsende feilmeldingen.
En produksjonsgodkjenningstest for Homepage
Før de faktiske brukerne kommer, lager du et release-regneark for Homepage. Det må angi det låste imaget, port 3000, canonical origin, persistente paths og eieren av skrivebeskyttet konfigurasjon samt credentials for valgfrie service-widgets. Legg ved det forventede resultatet av denne transaksjonen: last inn tjenester og bokmerker, kall flere live-widgets, test søk og start på nytt etter at du har redigert en YAML-konfigurasjonsfil.
Bruk regnearket etter en normal utskifting og etter en ren restore. Gjenoppretting godtas bare hvis tjenester, bokmerker, widgets og egendefinerte assets kommer tilbake, og alle kritiske widgets håndterer downstream-feil på en synlig måte. Samle også inn en kort ressursmåling som dekker widget-fan-out, trege downstream-API-er, DNS-oppløsning og oppdateringsfrekvensen til nettleserdashboardet. Oppbevar den sammen med releasen, slik at fremtidige kapasitetsendringer sammenlignes med samme arbeidsbelastning.
Ta med én kontrollert feil: blokker midlertidig testbanen som brukes av skrivebeskyttet konfigurasjon samt credentials for valgfrie service-widgets. Bekreft at Homepage rapporterer problemet ved riktig grense, gjenopprett den gyldige tilstanden og kjør transaksjonen på nytt. Dette tester feilsynlighet, ikke bare suksess, og hindrer at et grensesnitt som ser friskt ut skjuler en ødelagt worker, callback eller databaseforbindelse.
Gjør oppstarten av Homepage reproduserbar
Bruk containeren som et utskiftbart runtime-miljø, ikke som stedet der sannheten ligger.
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
Tillat og verifiser den utgående eller klientsidebaserte banen som kreves for skrivebeskyttet konfigurasjon samt credentials for valgfrie service-widgets. Kontroller container-brukeren, skrivbare paths og bundet listener før du eksponerer den. Kjør hele handlingen – last inn tjenester og bokmerker, kall flere live-widgets, test søk og start på nytt etter at du har redigert en YAML-konfigurasjonsfil – og lagre den nøyaktige image-referansen som produserte resultatet.
Skill utskiftbare containere fra varige data
Det varige gjenopprettingssettet består av konfigurasjonsfiler, bokmerker, tjenester og egendefinerte assets. Monter /app/config før bootstrap, skriv ufarlige eksempeldata og erstatt containeren for å bevise at banen faktisk er persistent. Et volum beskytter data mot utskifting av containeren, men ikke mot tap av verten, utilsiktet sletting eller korrupsjon på applikasjonsnivå.
Ta sikkerhetskopier som forstår datakilden: bruk logiske dumps for aktive databaser når det kreves, og kopier filer bare fra en konsistent tilstand. Oppbevar én kryptert kopi utenfor Homepage-verten. Godkjenningskriteriet for en restore er spesifikt – tjenester, bokmerker, widgets og egendefinerte assets kommer tilbake, og alle kritiske widgets håndterer downstream-feil på en synlig måte. Guiden for sikkerhetskopier som er testet med restore forklarer hvorfor vellykket jobb alene ikke er tilstrekkelig.
Domener, proxy-headere og port 3000
Nettleseren, API-klienten og Homepage må være enige om én origin. For å oppnå dette setter du tillatte verter for det nøyaktige domenet og proxy-verten. Bevar den opprinnelige verten og protokollen, samtidig som port 3000 holdes utilgjengelig som en konkurrerende offentlig adresse.
Feilsøkingsguiden for et nettsted som er nede hjelper deg med å skille en utilgjengelig rute fra en applikasjon som svarer. Dette skillet er viktig her: verten avvises, eller YAML-innrykk hindrer innlasting av konfigurasjonen. Bare det første løses med endringer i ingress; det andre krever inspeksjon av Homepage-logger, state eller arbeidsbelastning.
Sikkerhetsvalg som gjelder spesielt for Homepage
Ikke ta sikkerhetsantakelser fra en lokal tutorial. Den spesifikke utfordringen med Homepage er å legge widget-API-nøkler i et offentlig repository. I produksjon bør du derfor angi tillatte verter nøyaktig og oppbevare widget-API-nøkler i environment eller secret-basert konfigurasjon i stedet for i et offentlig repository.
HOMEPAGE_ALLOWED_HOSTS styrer adferd, ikke konfidensialitet. Valider derfor typen og verdien, og oppbevar ekte Homepage-credentials separat. Begrens filsystem- og nettverkstilgang, beskytt setup-endepunkter og definer grenser for opplasting, requests eller kjøring rundt widget-fan-out, trege downstream-API-er, DNS-oppløsning og oppdateringsfrekvensen til nettleserdashboardet.
Hvor Dockup reduserer arbeidet med Homepage
For Homepage er Dockup mest nyttig i grensen mellom et image og en persistent tjeneste. Det holder ruten til 3000, TLS, secret-verdier og storage knyttet sammen på tvers av container-utskiftinger, uansett om compute tilhører Dockup eller den tilkoblede serveren din.
Avslutt med applikasjonskunnskap: angi tillatte verter for det nøyaktige domenet og proxy-verten; tillat og verifiser skrivebeskyttet konfigurasjon samt credentials for valgfrie service-widgets; og kjør denne verifiseringen: last inn tjenester og bokmerker, kall flere live-widgets, test søk og start på nytt etter at du har redigert en YAML-konfigurasjonsfil. Ta vare på resultatet som en deployment-sjekk, slik at neste image-oppdatering vurderes ut fra adferd og ikke container-status.
Vanlige spørsmål
Hva trenger Homepage for en produksjonsdeployering?
Rout Homepage-containeren på port 3000 gjennom én HTTPS-origin. Det eksterne leveransekravet er skrivebeskyttet konfigurasjon samt credentials for valgfrie service-widgets. Ikke erklær Homepage som klar før du kan laste inn tjenester og bokmerker, kalle flere live-widgets, teste søk og starte på nytt etter at du har redigert en YAML-konfigurasjonsfil.
Hvilke Homepage-data skal inngå i en sikkerhetskopi?
Gjør /app/config persistent, og inkluder konfigurasjonsfiler, bokmerker, tjenester og egendefinerte assets i det samme gjenopprettingsmanifestet. En ren Homepage-restore er bare vellykket når tjenester, bokmerker, widgets og egendefinerte assets kommer tilbake, og alle kritiske widgets håndterer downstream-feil på en synlig måte.
Krever Homepage HTTPS bak en reverse proxy?
Bruk HTTPS for den offentlige Homepage-origin-en, og behold port 3000 på den interne ruten. Bruk Homepage-innstillingen riktig: angi tillatte verter for det nøyaktige domenet og proxy-verten. For Homepage beskytter HTTPS credentials eller brukerinnhold under transport, og sørger for at origin-avhengig klientadferd forblir konsistent.
Hvordan bør en Homepage-oppgradering testes?
Gjenopprett gjeldende Homepage-state i en isolert deployment, bruk kandidatversjonen og gjenta godkjenningstransaksjonen. Vær spesielt oppmerksom fordi konfigurasjonsnøkler og widget-integrasjoner kan endres. Valider derfor YAML og provider-adferd før en image-oppdatering. Behold det forrige Homepage-imaget til migrerings- og rollback-grensen for dataene er forstått.