Index denníkaDockup / poznámka z terénu
Note / self-host-homepage

Ako self-hostovať Homepage v roku 2026: povolené hosty, widgety a konfigurácia

Praktický návod na self-hosting Homepage, ktorý pokrýva Docker, porty, trvalé dáta, TLS, bezpečnosť, zálohy a zlyhania blokujúce produkčné použitie. Vrátane kontrol.

Existujú dve verzie „spustenia Homepage“: kontajner existuje alebo služba plní svoju skutočnú úlohu. Dôležitá je iba druhá možnosť. Dôkazom je načítanie služieb a záložiek, volanie niekoľkých živých widgetov, otestovanie vyhľadávania a reštart po úprave konfiguračného súboru YAML.

Homepage slúži ako úvodná stránka so živými widgetmi pre self-hostované služby. Nasadenie musí zachovať súčasti, ktoré toto správanie zabezpečujú; port, volume a certifikát sú vstupy, nie výsledok.

Vyberte najmenšiu použiteľnú topológiu Homepage

Užitočný diagram Homepage zobrazuje verejnú route, privátny port 3000, hranicu stavu a všetky podporné požiadavky. Označte, ktoré šípky prenášajú credentials a ktoré predstavujú bežnú používateľskú prevádzku. Externou požiadavkou pre Homepage je konfigurácia iba na čítanie spolu s credentials pre voliteľné service widgets. Otestujte odchádzajúce DNS, TLS a správanie providerov bez publikovania ďalšej prichádzajúcej služby.

Diagram overte jednou reálnou akciou: načítajte služby a záložky, zavolajte niekoľko živých widgetov, otestujte vyhľadávanie a reštart po úprave konfiguračného súboru YAML. Najväčší tlak pravdepodobne spôsobí fan-out widgetov, pomalé downstream API, DNS resolution a frekvencia obnovovania dashboardu v prehliadači; monitorujte túto cestu namiesto toho, aby ste všetky HTTP requesty považovali za rovnocenné.

Aktualizujte Homepage bez hádania

Prvou užitočnou prevádzkovou metrikou pre Homepage je, či dokáže načítať služby a záložky, zavolať niekoľko živých widgetov, otestovať vyhľadávanie a reštartovať sa po úprave konfiguračného súboru YAML. Skombinujte ju so signálmi saturácie pre fan-out widgetov, pomalé downstream API, DNS resolution a frekvenciu obnovovania dashboardu v prehliadači. Probe kontrolujúci iba proces by nemal volať nákladné dependencies ani reštartovať kontajner len preto, že upstream je krátkodobo nedostupný.

K aktualizáciám pristupujte ako k zmenám dát, pretože konfiguračné kľúče a integrácie widgetov sa môžu meniť. Pred aktualizáciou image preto overte YAML a správanie providerov. Verzie pinujte, postup si nacvičte na obnovenej state a predchádzajúci image ponechajte k dispozícii, kým rollback zostáva platný. Keď je host odmietnutý alebo odsadenie YAML bráni načítaniu konfigurácie, uchovajte logy z obdobia pred reštartom; zvyčajne obsahujú príčinnú správu.

Produkčný akceptačný test pre Homepage

Pred príchodom skutočných používateľov vytvorte pre Homepage release worksheet. Musí obsahovať pinned image, port 3000, canonical origin, persistent paths a vlastníka konfigurácie iba na čítanie spolu s credentials pre voliteľné service widgets. Pripojte očakávaný výsledok tejto transakcie: načítanie služieb a záložiek, volanie niekoľkých živých widgetov, otestovanie vyhľadávania a reštart po úprave konfiguračného súboru YAML.

Worksheet použite po bežnej náhrade aj po čistej obnove. Recovery je akceptované iba vtedy, ak sa vrátia služby, záložky, widgety a custom assets a všetky kritické widgety viditeľne zvládnu zlyhania downstream služieb. Zhromaždite aj krátky resource trace zahŕňajúci fan-out widgetov, pomalé downstream API, DNS resolution a frekvenciu obnovovania dashboardu v prehliadači; uchovajte ho pri release, aby sa budúce zmeny kapacity porovnávali s rovnakým workloadom.

Zahrňte jedno riadené zlyhanie: dočasne zablokujte testovaciu cestu používanú konfiguráciou iba na čítanie spolu s credentials pre voliteľné service widgets. Overte, či Homepage ohlási problém na správnej hranici, obnovte platný stav a transakciu zopakujte. Tým overíte viditeľnosť chýb, nielen úspech, a zabránite tomu, aby zdravo vyzerajúce rozhranie zakrývalo nefunkčný worker, callback alebo databázové pripojenie.

Zaistite reprodukovateľný štart Homepage

Kontajner používajte ako nahraditeľný runtime, nie ako miesto, kde sa nachádza zdroj pravdy.

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

Povoľte a overte odchádzajúcu alebo client-side cestu potrebnú pre konfiguráciu iba na čítanie spolu s credentials pre voliteľné service widgets. Pred vystavením služby skontrolujte používateľa kontajnera, zapisovateľné cesty a bindnutý listener. Spustite kompletnú akciu — načítajte služby a záložky, zavolajte niekoľko živých widgetov, otestujte vyhľadávanie a reštart po úprave konfiguračného súboru YAML — a uložte presnú referenciu image, ktorá vytvorila daný výsledok.

Oddeľte nahraditeľné kontajnery od trvalých dát

Trvalý recovery set tvoria konfiguračné súbory, záložky, služby a custom assets. Pred bootstrapom pripojte /app/config, zapíšte neškodné vzorové dáta a nahraďte kontajner, aby ste overili, že táto cesta je skutočne persistentná. Volume chráni dáta pred nahradením kontajnera, nie však pred stratou hosta, náhodným vymazaním alebo poškodením na aplikačnej úrovni.

Vytvárajte zálohy so znalosťou zdroja dát: v prípade potreby používajte pre live databázy logical dumps a súbory kopírujte iba z konzistentného stavu. Jednu šifrovanú kópiu uchovávajte mimo hosta Homepage. Akceptačné kritérium obnovy je konkrétne — vrátia sa služby, záložky, widgety a custom assets a všetky kritické widgety viditeľne zvládnu zlyhania downstream služieb. Návod na zálohy overené obnovou vysvetľuje, prečo samotný úspech jobu nestačí.

Domény, proxy headers a port 3000

Prehliadač, API klient a Homepage sa musia zhodovať na jednom origine. Aby to platilo, nastavte allowed hosts pre presnú doménu a hostname proxy. Zachovajte pôvodný host a protokol a zároveň ponechajte port 3000 nedostupný ako konkurenčnú verejnú adresu.

Návod na riešenie problémov s nedostupným webom pomáha rozlíšiť nedostupnú route od aplikácie, ktorá odpovedá. Toto rozlíšenie je dôležité aj tu: host je odmietnutý alebo odsadenie YAML bráni načítaniu konfigurácie. Zmeny na ingress vyriešia iba prvý prípad; druhý vyžaduje kontrolu logov Homepage, state alebo workloadu.

Bezpečnostné rozhodnutia špecifické pre Homepage

Nepreberajte bezpečnostné predpoklady z lokálneho tutorialu. Špecifickým problémom Homepage je commitovanie API keys widgetov do verejného repository. Produkcia by preto mala presne nastaviť allowed hosts a API keys widgetov uchovávať v environment alebo v konfigurácii napojenej na secrets, nie vo verejnom repository.

HOMEPAGE_ALLOWED_HOSTS riadi správanie, nie dôvernosť; overte jeho typ a hodnotu a skutočné credentials Homepage uchovávajte oddelene. Obmedzte filesystem a network access, chráňte setup endpoints a definujte limity uploadu, requestov alebo execution okolo fan-outu widgetov, pomalých downstream API, DNS resolution a frekvencie obnovovania dashboardu v prehliadači.

Kde Dockup odbremeňuje pri Homepage

Pri Homepage je Dockup najužitočnejší na hranici medzi image a trvalou službou. Zachováva route na port 3000, TLS, hodnoty secrets a storage pripojené aj po nahradení kontajnerov, bez ohľadu na to, či compute patrí Dockup alebo vášmu pripojenému serveru.

Na záver využite znalosti aplikácie: nastavte allowed hosts pre presnú doménu a hostname proxy, povoľte a overte konfiguráciu iba na čítanie spolu s credentials pre voliteľné service widgets a spustite toto overenie: načítajte služby a záložky, zavolajte niekoľko živých widgetov, otestujte vyhľadávanie a reštart po úprave konfiguračného súboru YAML. Výsledok si uložte ako deployment check, aby sa ďalšia aktualizácia image posudzovala podľa správania, nie podľa stavu kontajnera.

Často kladené otázky

Čo Homepage potrebuje na produkčné nasadenie?

Route kontajnera Homepage veďte cez port 3000 na jeden HTTPS origin. Externou delivery požiadavkou je konfigurácia iba na čítanie spolu s credentials pre voliteľné service widgets. Homepage nepovažujte za pripravený, kým nedokážete načítať služby a záložky, zavolať niekoľko živých widgetov, otestovať vyhľadávanie a reštart po úprave konfiguračného súboru YAML.

Ktoré dáta Homepage patria do zálohy?

Persistujte /app/config a do rovnakého recovery manifestu zahrňte konfiguračné súbory, záložky, služby a custom assets. Čistá obnova Homepage je úspešná iba vtedy, ak sa vrátia služby, záložky, widgety a custom assets a všetky kritické widgety viditeľne zvládnu zlyhania downstream služieb.

Vyžaduje Homepage HTTPS za reverse proxy?

Pre verejný origin Homepage používajte HTTPS a port 3000 ponechajte na internej route. Nastavenie Homepage aplikujte správne: nastavte allowed hosts pre presnú doménu a hostname proxy. HTTPS pri Homepage chráni credentials alebo používateľský obsah počas prenosu a zachováva konzistentné správanie klienta citlivé na origin.

Ako testovať aktualizáciu Homepage?

Obnovte aktuálny stav Homepage do izolovaného nasadenia, aplikujte kandidátnu verziu a zopakujte jej akceptačnú transakciu. Venujte tomu mimoriadnu pozornosť, pretože konfiguračné kľúče a integrácie widgetov sa môžu meniť; pred aktualizáciou image preto overte YAML a správanie providerov. Predchádzajúci image Homepage ponechajte k dispozícii, kým nebudete rozumieť hranici migrácie dát a rollbacku.