Cum să găzduiești Homepage pe cont propriu în 2026: hosts permise, widgeturi și configurare

Există două versiuni ale „rulării Homepage”: există un container sau serviciul își îndeplinește efectiv rolul. Doar a doua contează. Aici, dovada constă în încărcarea serviciilor și bookmarkurilor, apelarea mai multor widgeturi live, testarea căutării și repornirea după editarea unui fișier de configurare YAML.

Homepage are următorul scop: să ofere o pagină de pornire cu widgeturi live pentru serviciile self-hosted. Implementarea trebuie să păstreze componentele din spatele acestui comportament; un port, un volum și un certificat sunt intrări, nu rezultatul final.

Alege cea mai mică topologie viabilă pentru Homepage

O diagramă utilă pentru Homepage afișează ruta publică, portul privat 3000, limita datelor persistente și fiecare cerință auxiliară. Marchează săgețile care transportă credențiale și separă-le de traficul obișnuit al utilizatorilor. Cerința externă pentru Homepage constă în configurație read-only și credențiale pentru widgeturile opționale ale serviciilor. Testează DNS-ul outbound, TLS și comportamentul providerului fără să publici un alt serviciu inbound.

Dovedește diagrama printr-o acțiune reală: încarcă serviciile și bookmarkurile, apelează mai multe widgeturi live, testează căutarea și repornește după editarea unui fișier de configurare YAML. Presiunea probabilă vine din fan-out-ul widgeturilor, API-urile downstream lente, rezoluția DNS și frecvența de refresh a dashboardului din browser; monitorizează această rută în loc să tratezi toate requesturile HTTP ca fiind echivalente.

Actualizează Homepage fără presupuneri

Prima metrică operațională utilă pentru Homepage este dacă poate încărca serviciile și bookmarkurile, apela mai multe widgeturi live, testa căutarea și reporni după editarea unui fișier de configurare YAML. Asociaz-o cu semnale de saturație pentru fan-out-ul widgeturilor, API-urile downstream lente, rezoluția DNS și frecvența de refresh a dashboardului din browser. Un probe care verifică doar procesul nu ar trebui să apeleze dependențe costisitoare sau să repornească containerul doar pentru că un serviciu upstream este temporar indisponibil.

Tratează actualizările ca modificări de date, deoarece cheile de configurare și integrările widgeturilor se pot schimba, așa că validează YAML-ul și comportamentul providerului înainte de actualizarea imaginii. Fixează versiunile, repetă procedura pe o stare restaurată și păstrează imaginea anterioară disponibilă până când rollback-ul rămâne valid. Când hostul este respins sau indentarea YAML împiedică încărcarea configurației, păstrează logurile de dinaintea repornirii; de obicei, acestea conțin mesajul cauzal.

O procedură de acceptare pentru Homepage în producție

Înainte să apară utilizatorii reali, creează o fișă de release pentru Homepage. Aceasta trebuie să precizeze imaginea fixată, portul 3000, originea canonică, căile persistente și responsabilul pentru configurația read-only și credențialele widgeturilor opționale ale serviciilor. Atașează rezultatul așteptat al acestei tranzacții: încărcarea serviciilor și bookmarkurilor, apelarea mai multor widgeturi live, testarea căutării și repornirea după editarea unui fișier de configurare YAML.

Folosește fișa după o înlocuire normală și după o restaurare completă. Recuperarea este acceptată doar dacă serviciile, bookmarkurile, widgeturile și asseturile personalizate revin, iar toate widgeturile critice gestionează vizibil erorile serviciilor downstream. Colectează și o scurtă trasare a resurselor, care să acopere fan-out-ul widgeturilor, API-urile downstream lente, rezoluția DNS și frecvența de refresh a dashboardului din browser; păstreaz-o lângă release, pentru ca viitoarele schimbări de capacitate să fie comparate folosind același workload.

Include o eroare controlată: blochează temporar ruta de test utilizată pentru configurația read-only și credențialele widgeturilor opționale ale serviciilor. Confirmă că Homepage raportează problema la limita corectă, restabilește condiția validă și rulează din nou tranzacția. Astfel verifici vizibilitatea erorilor, nu doar succesul, și previi ca o interfață care pare sănătoasă să ascundă un worker, un callback sau o conexiune la baza de date defectă.

Fă pornirea Homepage reproductibilă

Folosește containerul ca runtime înlocuibil, nu ca loc în care se află sursa adevărului.

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

Permite și verifică ruta outbound sau client-side necesară pentru configurația read-only și credențialele widgeturilor opționale ale serviciilor. Inspectează utilizatorul containerului, căile writable și listenerul asociat înainte de a-l expune. Rulează acțiunea completă — încarcă serviciile și bookmarkurile, apelează mai multe widgeturi live, testează căutarea și repornește după editarea unui fișier de configurare YAML — și salvează referința exactă a imaginii care a produs rezultatul.

Separă containerele înlocuibile de datele persistente

Setul durabil pentru recuperare constă în fișierele de configurare, bookmarkuri, servicii și asseturi personalizate. Montează /app/config înainte de bootstrap, scrie date de exemplu inofensive și înlocuiește containerul pentru a demonstra că ruta este într-adevăr persistentă. Un volum protejează datele împotriva înlocuirii containerului, dar nu și împotriva pierderii hostului, ștergerii accidentale sau coruperii la nivelul aplicației.

Creează backupuri care înțeleg sursa datelor: folosește logical dumps pentru bazele de date live, atunci când este necesar, și copiază fișierele doar dintr-o stare consistentă. Păstrează o copie criptată în afara hostului Homepage. Criteriul de acceptare pentru o restaurare este specific — serviciile, bookmarkurile, widgeturile și asseturile personalizate revin, iar toate widgeturile critice gestionează vizibil erorile serviciilor downstream. Ghidul pentru backupuri testate prin restaurare explică de ce succesul jobului nu este suficient.

Domenii, headere proxy și portul 3000

Browserul, clientul API și Homepage trebuie să fie de acord asupra unei singure origini. Pentru a obține acest lucru, setează hosts permise pentru domeniul exact și hostname-ul proxy-ului. Păstrează hostul și protocolul originale, menținând în același timp portul 3000 indisponibil ca adresă publică alternativă.

Ghidul de depanare pentru site-uri indisponibile te ajută să diferențiezi o rută inaccesibilă de o aplicație care răspunde. Distincția este importantă aici: hostul este respins sau indentarea YAML împiedică încărcarea configurației. Doar prima problemă se rezolvă prin modificări în ingress; a doua necesită inspectarea logurilor, stării sau workloadului Homepage.

Decizii de securitate specifice pentru Homepage

Nu prelua presupunerile de securitate dintr-un tutorial local. Problema specifică Homepage este includerea cheilor API ale widgeturilor într-un repository public. În producție, setează, prin urmare, hosts permise cu precizie și păstrează cheile API ale widgeturilor în configurația bazată pe environment sau pe secrets, nu într-un repository public.

HOMEPAGE_ALLOWED_HOSTS controlează comportamentul, nu confidențialitatea; validează-i tipul și valoarea și stochează separat credențialele reale Homepage. Limitează accesul la filesystem și la rețea, protejează endpointurile de setup și definește limite pentru uploaduri, requesturi sau execuție în jurul fan-out-ului widgeturilor, API-urilor downstream lente, rezoluției DNS și frecvenței de refresh a dashboardului din browser.

Cum elimină Dockup munca pentru Homepage

Pentru Homepage, Dockup este cel mai util la limita dintre o imagine și un serviciu durabil. Păstrează ruta către 3000, TLS-ul, valorile secretelor și storage-ul atașate între înlocuirile containerului, indiferent dacă procesarea aparține Dockup sau serverului tău atașat.

Încheie cu cunoștințe specifice aplicației: setează hosts permise pentru domeniul exact și hostname-ul proxy-ului; permite și verifică configurația read-only și credențialele widgeturilor opționale ale serviciilor; apoi rulează această verificare: încarcă serviciile și bookmarkurile, apelează mai multe widgeturi live, testează căutarea și repornește după editarea unui fișier de configurare YAML. Păstrează rezultatul ca verificare de deployment, astfel încât următoarea actualizare a imaginii să fie evaluată după comportament, nu după starea containerului.

Întrebări frecvente

De ce are nevoie Homepage pentru un deployment în producție?

Rutează containerul Homepage pe portul 3000 printr-o singură origine HTTPS. Cerința externă de livrare constă în configurație read-only și credențiale pentru widgeturile opționale ale serviciilor. Nu considera Homepage pregătit până când nu poți încărca serviciile și bookmarkurile, apela mai multe widgeturi live, testa căutarea și reporni după editarea unui fișier de configurare YAML.

Ce date Homepage trebuie incluse într-un backup?

Persistă /app/config și include fișierele de configurare, bookmarkurile, serviciile și asseturile personalizate în același manifest de recuperare. O restaurare Homepage completă este reușită doar când serviciile, bookmarkurile, widgeturile și asseturile personalizate revin, iar toate widgeturile critice gestionează vizibil erorile serviciilor downstream.

Are Homepage nevoie de HTTPS în spatele unui reverse proxy?

Folosește HTTPS pentru originea publică Homepage și păstrează portul 3000 pe ruta internă. Aplică corect setarea Homepage: setează hosts permise pentru domeniul exact și hostname-ul proxy-ului. Pentru Homepage, HTTPS protejează credențialele sau conținutul utilizatorilor în tranzit și păstrează consecvent comportamentul clientului dependent de origine.

Cum trebuie testat un upgrade Homepage?

Restaurează starea curentă Homepage într-un deployment izolat, aplică versiunea candidat și repetă tranzacția de acceptare. Acordă o atenție deosebită acestui pas, deoarece cheile de configurare și integrările widgeturilor se pot schimba, așa că validează YAML-ul și comportamentul providerului înainte de actualizarea imaginii. Păstrează imaginea Homepage anterioară până când limitele migrației datelor și ale rollback-ului sunt înțelese.