Как да хоствате Homepage самостоятелно през 2026 г.: разрешени хостове, widgets и конфигурация
Практическо ръководство за self-hosting на Homepage, обхващащо Docker, портове, persistent data, TLS, сигурност, backups и проблемите, които пречат на използването в production. С проверки.
Има две версии на „стартиране на Homepage“: съществува container или услугата изпълнява реалната си задача. Важна е само втората. Тук доказателството е да заредите services и bookmarks, да извикате няколко live widgets, да тествате търсенето и да рестартирате след редактиране на YAML configuration file.
Homepage изпълнява следната роля: start page с live widgets за self-hosted services. Deployment-ът трябва да запази елементите зад това поведение; port, volume и certificate са входни данни, а не резултат.
Изберете най-малката работеща топология за Homepage
Полезната диаграма на Homepage показва public route, private port 3000, state boundary и всяко supporting requirement. Отбележете кои стрелки пренасят credentials и кои са обикновен user traffic. Външното изискване за Homepage е read-only configuration плюс credentials за optional service widgets. Тествайте outbound DNS, TLS и поведението на provider-а, без да публикувате допълнителна inbound service.
Докажете диаграмата с едно реално действие: заредете services и bookmarks, извикайте няколко live widgets, тествайте търсенето и рестартирайте след редактиране на YAML configuration file. Най-вероятният натиск идва от widget fan-out, бавни downstream APIs, DNS resolution и refresh rate на browser dashboard-а; наблюдавайте този път, вместо да третирате всички HTTP requests като еднакви.
Надграждайте Homepage без догадки
Първата полезна operational metric за Homepage е дали може да зареди services и bookmarks, да извика няколко live widgets, да тества търсенето и да се рестартира след редактиране на YAML configuration file. Съчетайте я със saturation signals за widget fan-out, бавни downstream APIs, DNS resolution и refresh rate на browser dashboard-а. Probe, който проверява само процеса, не трябва да извиква скъпи dependencies или да рестартира container-а, защото upstream временно не е достъпен.
Третирайте upgrades като промени в данните, защото configuration keys и widget integrations могат да се променят, затова валидирайте YAML и поведението на provider-а преди image update. Pin-вайте версиите, репетирайте върху възстановено state и запазете предишния image, докато rollback-ът остава валиден. Когато host-ът е отхвърлен или YAML indentation пречи на зареждането на config, запазете logs от преди рестарта; те обикновено съдържат причинното съобщение.
Production acceptance run за Homepage
Преди да се появят реални потребители, създайте release worksheet за Homepage. Той трябва да посочва pinned image, port 3000, canonical origin, persistent paths и owner-а на read-only configuration плюс credentials за optional service widgets. Приложете очаквания резултат от тази transaction: зареждане на services и bookmarks, извикване на няколко live widgets, тестване на търсенето и рестартиране след редактиране на YAML configuration file.
Използвайте worksheet-а след нормална подмяна и след clean restore. Recovery се приема само ако services, bookmarks, widgets и custom assets се възстановят и всички critical widgets показват видимо downstream failures. Съберете и кратък resource trace, който обхваща widget fan-out, бавни downstream APIs, DNS resolution и refresh rate на browser dashboard-а; съхранявайте го до release-а, за да сравнявате бъдещите промени в capacity със същото workload.
Включете един контролираn failure: временно откажете достъпа до test path, използван от read-only configuration плюс credentials за optional service widgets. Потвърдете, че Homepage отчита проблема на правилната boundary, възстановете валидното условие и изпълнете transaction-а отново. Така проверявате видимостта на грешките, а не само успеха, и предотвратявате интерфейс, който изглежда здрав, но прикрива счупен worker, callback или database connection.
Направете стартирането на Homepage възпроизводимо
Използвайте container-а като replaceable runtime, а не като място, където се съхранява истината.
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
Разрешете и проверете outbound или client-side path, необходим за read-only configuration плюс credentials за optional service widgets. Проверете container user-а, writable paths и bound listener-а, преди да го изложите. Изпълнете цялото действие — заредете services и bookmarks, извикайте няколко live widgets, тествайте търсенето и рестартирайте след редактиране на YAML configuration file — и запазете точната image reference, която е дала резултата.
Разделете replaceable containers от трайните данни
Durable recovery set-ът включва configuration files, bookmarks, services и custom assets. Монтирайте /app/config преди bootstrap, запишете безвредни примерни данни и подменете container-а, за да докажете, че този path действително е persistent. Volume защитава данните от подмяна на container-а, но не и от загуба на host-а, случайно изтриване или application-level corruption.
Правете backups, които разбират data source-а: използвайте logical dumps за live databases, когато е необходимо, и копирайте files само от consistent state. Съхранявайте едно encrypted copy извън Homepage host-а. Acceptance criterion за restore е конкретен — services, bookmarks, widgets и custom assets се възстановяват и всички critical widgets показват видимо downstream failures. Ръководството за backup, тестван чрез restore обяснява защо самият успех на job-а не е достатъчен.
Domains, proxy headers и port 3000
Browser-ът, API client-ът и Homepage трябва да използват един и същ origin. За да постигнете това, задайте allowed hosts за точния domain и proxy hostname. Запазете original host и protocol, като същевременно не допускайте port 3000 да се превърне в конкуриращ public address.
Ръководството за отстраняване на проблеми при недостъпен сайт помага да разграничите недостъпен route от приложение, което отговаря. Това разграничение е важно тук: host-ът е отхвърлен или YAML indentation пречи на зареждането на config. Само първият проблем се отстранява чрез промени в ingress; вторият изисква проверка на Homepage logs, state или workload.
Специфични за Homepage решения за сигурност
Не пренасяйте security assumptions от local tutorial. Специфичният проблем при Homepage е commit-ването на widget API keys в public repository. Затова production средата трябва да задава allowed hosts прецизно и да съхранява widget API keys в environment или secret-backed config, а не в public repository.
HOMEPAGE_ALLOWED_HOSTS контролира поведението, а не confidentiality; валидирайте типа и стойността му и съхранявайте истинските Homepage credentials отделно. Ограничете filesystem и network access-а, защитете setup endpoints и задайте upload, request или execution limits около widget fan-out, бавни downstream APIs, DNS resolution и refresh rate на browser dashboard-а.
Как Dockup премахва работата за Homepage
При Homepage Dockup е най-полезен на границата между image и durable service. Той запазва route-а към 3000, TLS, secret values и storage свързани при подмяна на containers, независимо дали compute-ът принадлежи на Dockup или на свързания ви server.
Завършете с application knowledge: задайте allowed hosts за точния domain и proxy hostname; разрешете и проверете read-only configuration плюс credentials за optional service widgets; и изпълнете тази проверка: заредете services и bookmarks, извикайте няколко live widgets, тествайте търсенето и рестартирайте след редактиране на YAML configuration file. Запазете резултата като deployment check, така че следващият image update да се оценява по поведението, а не по статуса на container-а.
Често задавани въпроси
Какво е необходимо на Homepage за production deployment?
Насочете Homepage container-а през port 3000 към един HTTPS origin. Външното изискване за delivery е read-only configuration плюс credentials за optional service widgets. Не приемайте Homepage за готов, докато не можете да заредите services и bookmarks, да извикате няколко live widgets, да тествате търсенето и да рестартирате след редактиране на YAML configuration file.
Кои данни на Homepage трябва да бъдат включени в backup?
Направете /app/config persistent и включете configuration files, bookmarks, services и custom assets в същия recovery manifest. Clean Homepage restore е успешен само когато services, bookmarks, widgets и custom assets се възстановят и всички critical widgets показват видимо downstream failures.
Изисква ли Homepage HTTPS зад reverse proxy?
Използвайте HTTPS за public Homepage origin и оставете port 3000 във вътрешния route. Приложете правилно Homepage setting-а: задайте allowed hosts за точния domain и proxy hostname. При Homepage HTTPS защитава credentials или user content при пренос и поддържа съгласувано client behavior, зависещо от origin.
Как трябва да бъде тестван Homepage upgrade?
Възстановете текущото Homepage state в isolated deployment, приложете candidate version и повторете acceptance transaction-а. Обърнете особено внимание, защото configuration keys и widget integrations могат да се променят, затова валидирайте YAML и поведението на provider-а преди image update. Запазете предишния Homepage image, докато границите на data migration и rollback не бъдат изяснени.