Homer: Ein statisches Server-Dashboard aus einer YAML-Datei
Eine sehr einfache statische Homepage für Ihren Server. Manuell erstellen Dann ist Ihr Dashboard im Verzeichnis /dist einsatzbereit.
Auf einen Blick
- Was ist das?
- Homer erzeugt aus einer einzigen Konfigurationsdatei eine statische Startseite für die eigenen Dienste, mit Suche, PWA und Theme-Anpassung. Wir gehen Docker-Betrieb, Umgebungsvariablen, Release-Installation und Grenzen durch.
- Für wen ist es gedacht?
- Homer passt für Selbsthoster, die eine wartungsarme Übersicht ihrer Dienste wollen und bereit sind, eine YAML-Datei von Hand zu pflegen. Wer dynamische Daten, Nutzerverwaltung oder Schreibzugriffe aus dem Dashboard heraus erwartet, sucht vergebens, denn Homer ist rein statisch.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 12 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Vue, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Homer als statisches Dashboard aus assets/config.yml
Homer beschreibt sich als sehr einfache, statische Startseite für den eigenen Server, gebaut um eine einzelne YAML-Konfigurationsdatei. Das README nennt den Zweck: Dienste griffbereit halten, ohne Portale, Datenbanken oder Anmeldeformulare. Technisch handelt es sich um ein voll statisches HTML- und JavaScript-Dashboard auf Vue-Basis, dessen Inhalt vollständig aus assets/config.yml entsteht.
Das gelöste Problem ist die Übersicht über verteilte Selbsthost-Dienste. Wer einen Homeserver betreibt, hat schnell ein Dutzend Weboberflächen mit eigenen Ports und Pfaden; Homer legt sie als Karten auf einer Seite ab. Die Highlights-Liste nennt Leichtgewichtigkeit, geringe bis keine Wartung, installierbare PWA-Fähigkeit, intelligente Karten, Fuzzy-Suche, mehrere Seiten mit Gruppierung und Theme-Anpassung.
Die Verbreitung ist bemerkenswert für ein statisches Werkzeug: 11.580 Sterne und 923 Forks, bei 167 offenen Issues und einem letzten Push am 27. August 2026. Die Lizenz ist Apache-2.0, die Dokumentation verteilt sich auf eigene Seiten für Konfiguration, Theming, intelligente Karten, Tipps, Entwicklung und Fehlersuche, ergänzt um eine Kubernetes-Anleitung in docs/kubernetes.md.
b4bz/homer mit Bind-Mount auf /www/assets
Der Standardbetrieb läuft über Docker, das Image heißt b4bz/homer. Der entscheidende Trick ist der Bind-Mount: Das Konfigurationsverzeichnis des Hosts wird an /www/assets im Container gebunden, damit das Dashboard ohne Neubau des Images pflegbar bleibt. Der docker run-Befehl aus dem README lautet docker run -d, --name homer, -p 8080:8080, --mount type=bind,source="/path/to/config/dir",target=/www/assets, --restart=unless-stopped, b4bz/homer:latest.
Ein Hinweisblock im README verdient Beachtung: Der Container läuft standardmäßig mit Benutzer- und Gruppen-ID 1000. Bei abweichenden Besitzverhältnissen auf dem Host hilft der Zusatz --user mit eigenen Werten, und die Rechte des Assets-Verzeichnisses müssen zur gewählten ID passen. Wer diesen Punkt übersieht, bekommt lesende Fehler auf die Konfiguration statt einer funktionierenden Seite.
In einer docker-compose-Variante sieht das Setup gleich aus: image b4bz/homer, das Volume auf /www/assets, Port 8080:8080, user 1000:1000 und die Umgebungsvariable INIT_ASSETS auf 1. Nach dem Start liegt das Dashboard damit als reiner Webdienst bereit, und Änderungen an der YAML-Datei wirken ohne Containerneustart, weil die Seite sie beim Laden liest.
INIT_ASSETS, SUBFOLDER und PORT im Compose-Setup
Vier Umgebungsvariablen steuern das Containerverhalten. INIT_ASSETS steht standardmäßig auf 1 und installiert eine Beispielkonfiguration samt Assets wie Favicons, um den Einstieg zu erleichtern; dazu muss das Konfigurationsverzeichnis für den Container-Benutzer beschreibbar sein. Wer eine fertige config.yml mitbringt, setzt den Wert auf 0 und vermeidet so, dass Beispieldateien mitlaufen.
SUBFOLDER ist standardmäßig nicht gesetzt und erlaubt das Betreiben unter einem Pfad wie /homer statt unter der Domain-Wurzel, was hinter einem Reverse-Proxy mit mehreren Anwendungen relevant ist. PORT ändert den internen Port vom Standard 8080 auf einen eigenen Wert, und IPV6_DISABLE auf 1 schaltet das Lauschen auf IPv6 ab.
Diese kleinen Hebel machen den Unterschied zwischen einem Spielzeug und einem pflegbaren Baustein aus. Der Subfolder-Schalter beispielsweise spart eigene Subdomains hinter einem gemeinsamen Proxy, und der Port-Schalter erlaubt es, mehrere Homer-Instanzen parallel zu fahren, etwa eine pro Server oder Nutzergruppe, ohne im Container zu Konflikten zu kommen.
Tastaturkürzel wie Alt plus Enter in der Fuzzy-Suche
Für den Alltag zählt die Bedienung. Die Fuzzy-Suche wird mit dem Schrägstrich gestartet, Escape beendet sie, Enter öffnet das erste passende Ergebnis und respektiert dabei die _target-Eigenschaft des Lesezeichens, also ob der Link im selben oder einem neuen Tab landet. Alt beziehungsweise Option zusammen mit Enter öffnet das erste Ergebnis direkt in einem neuen Tab.
Diese Kombination verwandelt das Dashboard in eine Tastatur-Steuerzentrale: Slash, Anfangsbuchstaben, Enter, fertig. Für Nutzer, die zwischen vielen Diensten wechseln, entfällt damit das Anklicken über mehrere Ebenen. Die Eigenschaft, dass Enter die _target-Einstellung des Lesezeichens übernimmt, zeigt eine sorgfältige Integration statt einer starren Regel.
Die Karten selbst sind als intelligente Karten dokumentiert und lassen sich über die theming- und customservices-Dokumentation anpassen. Mehrere Seiten mit Gruppierung halten auch größere Sammlungen übersichtlich, etwa eine Seite pro Server oder Themenbereich. Ein Default bleibt die PWA-Fähigkeit, mit der sich das Dashboard auf Geräten wie eine App installieren lässt.
homer.zip aus releases und der Start mit pnpx http-server
Ohne Docker führt der Weg über das vorgebaute Release-Paket. Das README nennt die Folge: wget https://github.com/bastienwirtz/homer/releases/latest/download/homer.zip, dann unzip homer.zip -d homer, cd homer, cp assets/config.yml.dist assets/config.yml, und zuletzt ein beliebiger Webserver, im Beispiel pnpx http-server oder python -m http.server 8010.
Wichtig ist der umbenannte Pflichtschritt: Die mitgelieferte Vorlage assets/config.yml.dist wird nach assets/config.yml kopiert, erst danach greift die Konfiguration. Und ein harter Hinweis aus dem README: Homer ist dafür gebaut, von einem HTTP-Server ausgeliefert zu werden; das direkte Öffnen der index.html über das file://-Protokoll funktioniert nicht.
Wer aus dem Quellcode bauen will, nutzt pnpm install und pnpm build, danach liegt das fertige Dashboard im Verzeichnis /dist. Diese drei Routen, Container, Tarball und Eigenbau, decken unterschiedliche Bedürfnisse ab: der Container den bequemen Dauerbetrieb, der Tarball den schnellen Start auf fremden Hostings, der Eigenbau den Weg für eigene Anpassungen am Code.
Versionsschema v26.8.1 gegen v26.08.2 und die file://-Falle
Die Release-Liste enthält eine Stolperfalle für Automatisierungen: v26.8.1 wurde am 27. August 2026 veröffentlicht, v26.08.2 eine Stunde später, beide Zahlen beziehen sich auf dasselbe Jahr und denselben Monat, einmal ohne, einmal mit führender Null im Monatsanteil. Wer Releases nach Tag-Sortierung vergleicht, braucht daher eine Regel, die beide Schreibformen ordnet, und sollte sich auf die Veröffentlichungsdaten stützen statt auf Zeichenkettenvergleich. Davor lag v26.4.2 vom 18. April 2026.
Für den Dauerbetrieb bleibt der praktische Rat, das Image mit einem festen Tag statt mit latest zu fahren und beim Wechsel die Änderungen an der config.yml-Struktur gegen die Konfigurationsdokumentation zu prüfen. Die Fehlersuch-Seite im docs/-Verzeichnis ist der erste Anlauf bei weißen Seiten oder fehlenden Karten, meist ein Rechteproblem auf dem gebundenen Verzeichnis.
Als Alternative zum Containerbetrieb bleibt das Ausliefern von /dist über einen vorhandenen Webserver wie nginx, der auf vielen Homeservern ohnehin läuft. Der Unterschied: Der Container bringt die Bequemlichkeiten INIT_ASSETS und SUBFOLDER mit, während der eigene Webserver nur die fertigen Dateien ausliefert und alle Pfad- und Rechtefragen beim Betreiber liegen. Wer Docker ohnehin einsetzt, fährt mit b4bz/homer schlanker, wer einen nackten Webspace pflegt, nimmt den Tarball. In beiden Fällen entscheidet die Sorgfalt bei der YAML-Datei über die Qualität des Dashboards, nicht die Infrastruktur dahinter.
Redaktionelles Fazit
Homer passt für Selbsthoster, die eine wartungsarme Übersicht ihrer Dienste wollen und bereit sind, eine YAML-Datei von Hand zu pflegen. Wer dynamische Daten, Nutzerverwaltung oder Schreibzugriffe aus dem Dashboard heraus erwartet, sucht vergebens, denn Homer ist rein statisch. Vor dem Ernstbetrieb sollte man den Abruf über einen echten HTTP-Server prüfen, weil der direkte Öffnen-Weg über file:// laut README nicht funktioniert.
Community-Notizen