Homepage 2026 selbst hosten: Allowed Hosts, Widgets und Konfiguration

Es gibt zwei Varianten, was „Homepage ausführen“ bedeutet: Ein Container existiert, oder der Dienst erledigt seine eigentliche Aufgabe. Nur die zweite Variante ist relevant. Der Nachweis besteht hier darin, Services und Bookmarks zu laden, mehrere Live-Widgets aufzurufen, die Suche zu testen und nach der Bearbeitung einer YAML-Konfigurationsdatei einen Neustart durchzuführen.

Homepage erfüllt folgenden Zweck: eine Startseite mit Live-Widgets für selbst gehostete Services. Das Deployment muss die Komponenten hinter diesem Verhalten erhalten; ein Port, ein Volume und ein Zertifikat sind Voraussetzungen, nicht das Ergebnis.

Die kleinste sinnvolle Homepage-Topologie auswählen

Ein nützliches Homepage-Diagramm zeigt die öffentliche Route, den privaten Port 3000, die Zuständigkeitsgrenze für den Status und alle unterstützenden Anforderungen. Kennzeichne, welche Pfeile Credentials übertragen und welche normalen Benutzer-Traffic transportieren. Die externe Anforderung von Homepage besteht aus einer schreibgeschützten Konfiguration sowie Credentials für optionale Service-Widgets. Teste ausgehendes DNS, TLS und das Verhalten der Provider, ohne einen weiteren eingehenden Service zu veröffentlichen.

Belege das Diagramm mit einer echten Aktion: Lade Services und Bookmarks, rufe mehrere Live-Widgets auf, teste die Suche und starte den Dienst nach der Bearbeitung einer YAML-Konfigurationsdatei neu. Die wahrscheinliche Belastung entsteht durch Widget-Fan-out, langsame nachgelagerte APIs, DNS-Auflösung und die Aktualisierungsrate des Browser-Dashboards. Überwache diesen Pfad, statt alle HTTP-Anfragen gleich zu behandeln.

Homepage aktualisieren, ohne zu raten

Die erste nützliche Betriebsmetrik für Homepage ist, ob Services und Bookmarks geladen, mehrere Live-Widgets aufgerufen, die Suche getestet und nach der Bearbeitung einer YAML-Konfigurationsdatei ein Neustart durchgeführt werden kann. Ergänze diese Metrik um Sättigungssignale für Widget-Fan-out, langsame nachgelagerte APIs, DNS-Auflösung und die Aktualisierungsrate des Browser-Dashboards. Ein Process-only-Probe sollte keine teuren Abhängigkeiten aufrufen oder den Container neu starten, nur weil ein Upstream kurzzeitig nicht verfügbar ist.

Behandle Updates als Datenänderungen, da sich Konfigurationsschlüssel und Widget-Integrationen ändern können. Validiere daher YAML und das Verhalten der Provider vor einem Image-Update. Pinne Versionen, übe den Ablauf mit einem wiederhergestellten Status und halte das vorherige Image verfügbar, bis ein Rollback weiterhin möglich ist. Wenn der Host abgelehnt wird oder die YAML-Einrückung das Laden der Konfiguration verhindert, sichere die Logs vor dem Neustart. Sie enthalten normalerweise die ursächliche Meldung.

Ein produktionsreifer Abnahmelauf für Homepage

Erstelle vor dem Eintreffen echter Benutzer ein Release-Arbeitsblatt für Homepage. Es muss das gepinnte Image, Port 3000, die kanonische Origin, persistente Pfade sowie den Verantwortlichen für die schreibgeschützte Konfiguration und die Credentials der optionalen Service-Widgets benennen. Füge das erwartete Ergebnis dieser Transaktion hinzu: Services und Bookmarks laden, mehrere Live-Widgets aufrufen, die Suche testen und nach der Bearbeitung einer YAML-Konfigurationsdatei neu starten.

Verwende das Arbeitsblatt nach einem normalen Austausch und nach einer sauberen Wiederherstellung. Die Wiederherstellung gilt nur dann als erfolgreich, wenn Services, Bookmarks, Widgets und benutzerdefinierte Assets zurückkehren und alle kritischen Widgets Ausfälle nachgelagerter Systeme sichtbar behandeln. Erfasse außerdem einen kurzen Ressourcen-Trace zu Widget-Fan-out, langsamen nachgelagerten APIs, DNS-Auflösung und der Aktualisierungsrate des Browser-Dashboards. Bewahre ihn zusammen mit dem Release auf, damit künftige Kapazitätsänderungen anhand derselben Auslastung verglichen werden können.

Füge einen kontrollierten Fehler ein: Verweigere vorübergehend den Testpfad, der für die schreibgeschützte Konfiguration und die Credentials der optionalen Service-Widgets verwendet wird. Bestätige, dass Homepage das Problem an der richtigen Grenze meldet, stelle den gültigen Zustand wieder her und führe die Transaktion erneut aus. Damit wird die Sichtbarkeit von Fehlern geprüft, nicht nur der Erfolg. So wird verhindert, dass eine scheinbar gesunde Oberfläche einen defekten Worker, Callback oder eine unterbrochene Datenbankverbindung verbirgt.

Den Homepage-Start reproduzierbar machen

Verwende den Container als austauschbare Runtime, nicht als Quelle der Wahrheit.

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

Erlaube und verifiziere den ausgehenden oder clientseitigen Pfad, der für die schreibgeschützte Konfiguration und die Credentials der optionalen Service-Widgets erforderlich ist. Prüfe den Container-Benutzer, beschreibbare Pfade und den gebundenen Listener, bevor du den Dienst veröffentlichst. Führe die vollständige Aktion aus – Services und Bookmarks laden, mehrere Live-Widgets aufrufen, die Suche testen und nach der Bearbeitung einer YAML-Konfigurationsdatei neu starten – und speichere die exakte Image-Referenz, mit der das Ergebnis erzielt wurde.

Austauschbare Container von dauerhaften Daten trennen

Der dauerhafte Wiederherstellungssatz besteht aus Konfigurationsdateien, Bookmarks, Services und benutzerdefinierten Assets. Binde /app/config vor dem Bootstrap ein, schreibe harmlose Beispieldaten und ersetze den Container, um zu beweisen, dass dieser Pfad tatsächlich persistent ist. Ein Volume schützt Daten vor dem Austausch des Containers, nicht jedoch vor dem Verlust des Hosts, versehentlichem Löschen oder einer Beschädigung auf Anwendungsebene.

Erstelle Backups, die die Datenquelle verstehen: Verwende bei Bedarf logische Dumps für laufende Datenbanken und kopiere Dateien nur aus einem konsistenten Zustand. Bewahre eine verschlüsselte Kopie außerhalb des Homepage-Hosts auf. Das Abnahmekriterium für eine Wiederherstellung ist konkret: Services, Bookmarks, Widgets und benutzerdefinierte Assets kehren zurück, und alle kritischen Widgets behandeln Ausfälle nachgelagerter Systeme sichtbar. Der Leitfaden für Backups mit getesteter Wiederherstellung erklärt, warum ein erfolgreicher Job allein nicht ausreicht.

Domains, Proxy-Header und Port 3000

Browser, API-Client und Homepage müssen sich auf eine gemeinsame Origin einigen. Setze dafür Allowed Hosts für die exakte Domain und den Proxy-Host. Bewahre den ursprünglichen Host und das Protokoll, während Port 3000 als konkurrierende öffentliche Adresse nicht verfügbar sein darf.

Der Leitfaden zur Fehlersuche bei nicht erreichbaren Websites hilft dabei, eine nicht erreichbare Route von einer antwortenden Anwendung zu unterscheiden. Diese Unterscheidung ist hier wichtig: Der Host wird abgelehnt oder die YAML-Einrückung verhindert das Laden der Konfiguration. Nur das erste Problem wird durch Änderungen am Ingress behoben; das zweite erfordert eine Prüfung der Homepage-Logs, des Status oder der Auslastung.

Sicherheitsentscheidungen speziell für Homepage

Übernimm keine Sicherheitsannahmen aus einem lokalen Tutorial. Das spezifische Risiko bei Homepage besteht darin, Widget-API-Keys in einem öffentlichen Repository zu committen. In der Produktion sollten Allowed Hosts daher präzise gesetzt und Widget-API-Keys in einer umgebungs- oder secret-basierten Konfiguration statt in einem öffentlichen Repository abgelegt werden.

HOMEPAGE_ALLOWED_HOSTS steuert das Verhalten, nicht die Vertraulichkeit. Validiere Typ und Wert und speichere echte Homepage-Credentials separat. Begrenze den Zugriff auf Dateisystem und Netzwerk, schütze Setup-Endpunkte und definiere Limits für Uploads, Requests oder Ausführung rund um Widget-Fan-out, langsame nachgelagerte APIs, DNS-Auflösung und die Aktualisierungsrate des Browser-Dashboards.

Wie Dockup bei Homepage Arbeit abnimmt

Bei Homepage ist Dockup vor allem an der Grenze zwischen einem Image und einem dauerhaften Service nützlich. Es hält die Route zu 3000, TLS, Secret-Werte und Storage über den Austausch von Containern hinweg verbunden – unabhängig davon, ob die Compute-Ressourcen zu Dockup oder zu deinem angebundenen Server gehören.

Schließe mit anwendungsspezifischem Wissen ab: Setze Allowed Hosts für die exakte Domain und den Proxy-Host; erlaube und verifiziere die schreibgeschützte Konfiguration sowie die Credentials der optionalen Service-Widgets; und führe diese Prüfung aus: Services und Bookmarks laden, mehrere Live-Widgets aufrufen, die Suche testen und nach der Bearbeitung einer YAML-Konfigurationsdatei neu starten. Halte das Ergebnis als Deployment-Check fest, damit das nächste Image-Update anhand des Verhaltens und nicht anhand des Container-Status bewertet wird.

Häufig gestellte Fragen

Was benötigt Homepage für ein produktives Deployment?

Leite den Homepage-Container über eine einzige HTTPS-Origin auf Port 3000. Die externe Bereitstellungsanforderung besteht aus einer schreibgeschützten Konfiguration sowie Credentials für optionale Service-Widgets. Betrachte Homepage erst dann als bereit, wenn du Services und Bookmarks laden, mehrere Live-Widgets aufrufen, die Suche testen und nach der Bearbeitung einer YAML-Konfigurationsdatei neu starten kannst.

Welche Homepage-Daten gehören in ein Backup?

Mache /app/config persistent und nimm Konfigurationsdateien, Bookmarks, Services und benutzerdefinierte Assets in dasselbe Wiederherstellungsmanifest auf. Eine saubere Homepage-Wiederherstellung ist erst dann erfolgreich, wenn Services, Bookmarks, Widgets und benutzerdefinierte Assets zurückkehren und alle kritischen Widgets Ausfälle nachgelagerter Systeme sichtbar behandeln.

Benötigt Homepage HTTPS hinter einem Reverse Proxy?

Verwende HTTPS für die öffentliche Homepage-Origin und halte Port 3000 auf der internen Route. Wende die Homepage-Einstellung korrekt an: Setze Allowed Hosts für die exakte Domain und den Proxy-Host. Bei Homepage schützt HTTPS Credentials oder Benutzerinhalte während der Übertragung und sorgt für ein konsistentes, von der Origin abhängiges Client-Verhalten.

Wie sollte ein Homepage-Upgrade getestet werden?

Stelle den aktuellen Homepage-Status in einem isolierten Deployment wieder her, wende die Kandidatenversion an und wiederhole die Abnahmetransaktion. Achte besonders darauf, dass sich Konfigurationsschlüssel und Widget-Integrationen ändern können. Validiere daher YAML und das Verhalten der Provider vor einem Image-Update. Behalte das vorherige Homepage-Image, bis die Grenzen der Datenmigration und des Rollbacks verstanden sind.