Jak provozovat Homepage na vlastním serveru v roce 2026: povolené hosty, widgety a konfigurace

Existují dvě verze „spuštěné Homepage“: kontejner existuje, nebo služba skutečně plní svou úlohu. Záleží pouze na druhé variantě. Důkazem je načtení služeb a záložek, zavolání několika živých widgetů, otestování vyhledávání a restart po úpravě konfiguračního souboru YAML.

Homepage slouží jako startovní stránka s živými widgety pro self-hostované služby. Nasazení musí zachovat části, které toto chování zajišťují; port, volume a certifikát jsou vstupy, nikoli výsledek.

Zvolte nejmenší použitelnou topologii Homepage

Užitečný diagram Homepage zobrazuje veřejnou trasu, privátní port 3000, hranici stavu a všechny podpůrné požadavky. Označte, které šipky přenášejí přihlašovací údaje a které představují běžný uživatelský provoz. Vnější požadavek Homepage tvoří konfigurace pouze pro čtení a přihlašovací údaje pro volitelné widgety služeb. Otestujte odchozí DNS, TLS a chování poskytovatele, aniž byste publikovali další příchozí službu.

Diagram ověřte jednou skutečnou akcí: načtěte služby a záložky, zavolejte několik živých widgetů, otestujte vyhledávání a restartujte službu po úpravě konfiguračního souboru YAML. Pravděpodobnou zátěž vytváří fan-out widgetů, pomalá downstream API, DNS resolution a frekvence obnovování dashboardu v prohlížeči; sledujte tuto cestu místo toho, abyste všechny HTTP požadavky považovali za rovnocenné.

Aktualizujte Homepage bez hádání

První užitečná provozní metrika Homepage ukazuje, zda dokáže načíst služby a záložky, zavolat několik živých widgetů, otestovat vyhledávání a restartovat službu po úpravě konfiguračního souboru YAML. Doplňte ji signály saturace pro fan-out widgetů, pomalá downstream API, DNS resolution a frekvenci obnovování dashboardu v prohlížeči. Probe kontrolující pouze proces by neměl volat nákladné závislosti ani restartovat kontejner kvůli krátkodobé nedostupnosti upstreamu.

S aktualizacemi zacházejte jako se změnami dat, protože se mohou měnit konfigurační klíče a integrace widgetů. Před aktualizací image proto ověřte YAML a chování poskytovatele. Pinujte verze, nacvičte postup na obnoveném stavu a ponechte předchozí image k dispozici, dokud zůstane rollback platný. Když je host odmítnut nebo odsazení YAML zabrání načtení konfigurace, uchovejte logy z doby před restartem; obvykle obsahují zprávu s příčinou.

Produkční akceptační test pro Homepage

Než dorazí skuteční uživatelé, vytvořte pro Homepage release checklist. Musí obsahovat pinovanou image, port 3000, canonical origin, persistentní cesty a vlastníka konfigurace pouze pro čtení a přihlašovacích údajů pro volitelné widgety služeb. Připojte očekávaný výsledek této transakce: načtení služeb a záložek, zavolání několika živých widgetů, otestování vyhledávání a restart po úpravě konfiguračního souboru YAML.

Checklist použijte po běžné náhradě i po čistém obnovení. Obnova je akceptována pouze tehdy, pokud se vrátí služby, záložky, widgety a vlastní assety a všechny kritické widgety viditelně zvládnou výpadky downstream služeb. Shromážděte také krátký resource trace pokrývající fan-out widgetů, pomalá downstream API, DNS resolution a frekvenci obnovování dashboardu v prohlížeči; uložte ho vedle release, aby se budoucí změny kapacity porovnávaly se stejnou zátěží.

Zahrňte jedno řízené selhání: dočasně zakažte testovací cestu používanou konfigurací pouze pro čtení a přihlašovacími údaji pro volitelné widgety služeb. Ověřte, že Homepage nahlásí problém na správné hranici, obnovte platný stav a transakci spusťte znovu. Ověříte tím viditelnost chyb, nikoli pouze úspěch, a zabráníte zdravě vypadajícímu rozhraní, aby skrývalo nefunkční worker, callback nebo připojení k databázi.

Zajistěte reprodukovatelný start Homepage

Kontejner používejte jako nahraditelný runtime, nikoli jako místo, kde se nachází 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

Povolte a ověřte odchozí nebo client-side cestu vyžadovanou konfigurací pouze pro čtení a přihlašovacími údaji pro volitelné widgety služeb. Před vystavením služby zkontrolujte uživatele kontejneru, zapisovatelné cesty a bindovaný listener. Proveďte celou akci — načtěte služby a záložky, zavolejte několik živých widgetů, otestujte vyhledávání a restartujte službu po úpravě konfiguračního souboru YAML — a uložte přesnou referenci image, která výsledek vytvořila.

Oddělte nahraditelné kontejnery od trvalých dat

Trvalou sadou pro obnovu jsou konfigurační soubory, záložky, služby a vlastní assety. Před bootstrapem připojte /app/config, zapište neškodná ukázková data a nahraďte kontejner, abyste prokázali, že je tato cesta skutečně persistentní. Volume chrání data před nahrazením kontejneru, nikoli však před ztrátou hostitele, náhodným smazáním nebo poškozením na úrovni aplikace.

Vytvářejte zálohy s ohledem na zdroj dat: v případě potřeby používejte pro živé databáze logické dumpy a soubory kopírujte pouze z konzistentního stavu. Jednu zašifrovanou kopii uchovávejte mimo hostitele Homepage. Akceptační kritérium obnovy musí být konkrétní — vrátí se služby, záložky, widgety a vlastní assety a všechny kritické widgety viditelně zvládnou výpadky downstream služeb. Průvodce zálohami ověřenými obnovou vysvětluje, proč samotný úspěch jobu nestačí.

Domény, proxy hlavičky a port 3000

Prohlížeč, API klient a Homepage se musí shodnout na jednom originu. Aby tomu tak bylo, nastavte povolené hosty pro přesnou doménu a hostname proxy. Zachovejte původní host a protokol a zároveň ponechte port 3000 nedostupný jako konkurenční veřejnou adresu.

Průvodce řešením problémů s nedostupným webem pomáhá rozlišit nedostupnou trasu od aplikace, která odpovídá. Toto rozlišení je zde důležité: host je odmítnut nebo odsazení YAML zabrání načtení konfigurace. Změny ingressu opraví pouze první případ; druhý vyžaduje kontrolu logů Homepage, stavu nebo zátěže.

Bezpečnostní rozhodnutí specifická pro Homepage

Nepřebírejte bezpečnostní předpoklady z lokálního tutorialu. Konkrétním problémem Homepage je uložení API klíčů widgetů do veřejného repository. Produkce proto musí přesně nastavit povolené hosty a API klíče widgetů uchovávat v environmentu nebo konfiguraci napojené na secrets, nikoli ve veřejném repository.

HOMEPAGE_ALLOWED_HOSTS řídí chování, nikoli důvěrnost; ověřte jeho typ a hodnotu a skutečné přihlašovací údaje Homepage ukládejte odděleně. Omezte přístup k filesystemu a síti, chraňte setup endpointy a definujte limity pro upload, requesty nebo spouštění kolem fan-outu widgetů, pomalých downstream API, DNS resolution a frekvence obnovování dashboardu v prohlížeči.

Kde Dockup u Homepage odstraňuje práci

U Homepage je Dockup nejpraktičtější na hranici mezi image a trvalou službou. Zachovává trasu na port 3000, TLS, secret values a storage připojené i po náhradě kontejnerů, bez ohledu na to, zda compute zajišťuje Dockup, nebo váš připojený server.

Dokončete nasazení znalostí aplikace: nastavte povolené hosty pro přesnou doménu a hostname proxy, povolte a ověřte konfiguraci pouze pro čtení a přihlašovací údaje pro volitelné widgety služeb a proveďte toto ověření: načtěte služby a záložky, zavolejte několik živých widgetů, otestujte vyhledávání a restartujte službu po úpravě konfiguračního souboru YAML. Výsledek uchovejte jako deployment check, aby se příští aktualizace image posuzovala podle chování, nikoli podle stavu kontejneru.

Často kladené otázky

Co Homepage potřebuje pro produkční nasazení?

Veďte kontejner Homepage na portu 3000 přes jeden HTTPS origin. Vnější požadavek pro doručování tvoří konfigurace pouze pro čtení a přihlašovací údaje pro volitelné widgety služeb. Homepage nepovažujte za připravenou, dokud nedokážete načíst služby a záložky, zavolat několik živých widgetů, otestovat vyhledávání a restartovat službu po úpravě konfiguračního souboru YAML.

Která data Homepage patří do zálohy?

Zachovejte /app/config a do stejného recovery manifestu zahrňte konfigurační soubory, záložky, služby a vlastní assety. Čistá obnova Homepage je úspěšná pouze tehdy, když se vrátí služby, záložky, widgety a vlastní assety a všechny kritické widgety viditelně zvládnou výpadky downstream služeb.

Vyžaduje Homepage za reverse proxy HTTPS?

Pro veřejný origin Homepage používejte HTTPS a port 3000 ponechte na interní trase. Nastavení Homepage aplikujte správně: nastavte povolené hosty pro přesnou doménu a hostname proxy. U Homepage HTTPS chrání přihlašovací údaje nebo uživatelský obsah při přenosu a zachovává konzistentní chování klienta citlivé na origin.

Jak testovat aktualizaci Homepage?

Obnovte aktuální stav Homepage do izolovaného nasazení, aplikujte kandidátní verzi a zopakujte její akceptační transakci. Věnujte pozornost zejména tomu, že se mohou měnit konfigurační klíče a integrace widgetů, proto před aktualizací image ověřte YAML a chování poskytovatele. Předchozí image Homepage ponechte k dispozici, dokud neporozumíte hranici migrace dat a rollbacku.