HomerはYAMLで自宅サービスの入口を整えられるか

Homerの仕事はサービスへの静的な入口

Homerは、サーバー上のサービスを手元に置くためのシンプルな静的ホームページです。READMEはYAML設定ファイルを使う静的HTMLとJavaScriptのダッシュボードとして説明しています。サービス本体を管理したり、状態を収集したりするサーバーオーケストレーターではなく、利用者が登録したリンクや表示情報をまとめる画面です。

そのため、Homerの導入判断は自分のサービス一覧を安全に整理できるかで決まります。リンク先の認証、監視、バックアップ、ネットワーク到達性は各サービスとWebサーバーの責任です。READMEのHighlightsにあるYAML設定、PWA、テーマなどを、自分のランディング画面に必要な機能と照合してください。

assets/config.ymlが表示内容を決める

設定の中心はassets/config.ymlです。READMEはdocs/configuration.mdを参照し、設定オプションを確認するよう案内しています。サービス名、リンク、アイコンなどを編集する場合は、配布物のassets/config.yml.distをコピーまたは改名して開始します。YAMLのインデントとURLの記述が画面へ直接影響します。

最初はサービスを一つだけ登録し、HTTPサーバーから表示してリンクが正しく遷移することを確認します。複数のURL、ブックマークのtarget、サブフォルダーの設定を一度に変えると原因が分かりにくくなります。設定変更後はブラウザーのキャッシュ、コンソールエラー、生成物のassetsパスを確認してから本番の一覧を置き換えます。

Dockerは設定ディレクトリを外へ出す

Dockerの例では、ローカル設定ディレクトリを用意し、/www/assetsへbind mountしてb4bz/homer:latestを起動します。設定をコンテナの外に置くことで、ダッシュボードのYAMLとアイコンを維持しやすくなります。READMEの例は8080番ポートを公開し、restart=unless-stoppedを指定しています。

コンテナは既定でUIDとGID 1000のユーザーで動作します。assetsディレクトリの所有権が一致しない場合は--user <your-UID>:<your-GID>を付ける案内があります。実際に設定を読み込めるか、アイコンを表示できるか、コンテナ再作成後も内容が残るかを試してからUIDを固定してください。

release zipと手動ビルドの違い

事前ビルドを使う場合はGitHub Releasesからhomer.zipを取得して展開し、assets/config.yml.distをassets/config.ymlへ改名してWebサーバーの配下へ置きます。READMEはwgetの取得例と、pnpx http-serverまたはpython -m http.server 8010での簡易配信例を示しています。これは本番のTLSやアクセス制御を設定する手順ではありません。

手動ビルドではpnpm installの後にpnpm buildを実行します。生成物を/distに置く構成なので、ビルド前後でconfigの位置と参照パスを確認します。Node.jsとpnpmの版、ビルドログ、dist内のファイルを記録し、release zipと手動ビルドで表示結果が一致するかを同じ設定で比較してください。

file://ではなくHTTPで表示する

READMEはindex.htmlをfile://プロトコルで直接開いても動かないと明記しています。ローカル確認でもHTTPサーバーを使う必要があります。画面が白い場合は、ファイルを開く方法、assets/config.ymlの場所、JavaScriptの読み込み、ブラウザーコンソールのエラーを順に確認します。

Homerをサブフォルダーでホストする場合は、サブフォルダーのパスを設定する案内があります。内部ポートを8080から変更する場合も設定項目を確認します。リバースプロキシ配下でリンクや静的アセットが正しく読めるかを確認し、Homerがリンク先のサービスを代理認証するとは考えないでください。

Apache-2.0で設定を長く維持する

HomerのライセンスはApache-2.0です。改変や再配布の条件はリポジトリのLICENSEとライセンス本文で確認します。設定ファイルへサービスURLや説明を記載すること自体は簡単ですが、内部ホスト名や管理画面へのリンクを外部へ公開しないよう、Webサーバーの公開範囲を別に管理します。

Homerは、リンク集を静的に保ちたい人には導入が軽い選択肢です。サービスの稼働監視、ユーザー認証、シークレット管理を一つの画面へ求める人には、追加の仕組みが必要です。まず一つの設定ファイルと一つのDockerコンテナで、更新、再起動、バックアップ、外部公開時の表示を確認してから項目を増やすのがよいでしょう。config.ymlを変更した後に意図しない管理URLが公開されていないか、アイコンの参照切れがないか、コンテナ再作成後も同じ設定が読み込まれるかを確認します。

Homerの静的アセットを確認する

bastienwirtz/homerではassets/config.ymlにサービスを一つだけ登録し、Dockerの/www/assetsマウント後に8080番のHTTP画面でリンク、アイコン、targetの挙動を確認します。次にconfig.ymlを変更してコンテナを再作成し、設定が残ることを確かめます。サブフォルダー配信では静的アセットのパスを確認し、file://で開いた結果を動作確認に使いません。実施記録には対象版と入力条件を残し、成功した結果だけでなく失敗した場合の出力も保存します。設定を変更した前後で同じ確認を繰り返せるようにし、READMEに書かれた機能と自分の環境で確認できた事実を分けます。採用判断では、導入できたかだけでなく、更新、障害、切り戻し、権限、ライセンスを同じ担当者が追跡できるかを確かめます。

v26.8.1とINIT_ASSETSの扱い

README取得時点のGitHub Releasesには v26.8.1、v26.08.2、v26.4.2 が並びます。タグ表記が v26.8.1 と v26.08.2 でゼロ埋めが揃っていないため、docker run の b4bz/homer:latest と zip 配布の版を同じ番号だと決めつけない方が安全です。デモは homer-demo.netlify.app、コンテナは hub.docker.com/r/b4bz/homer です。環境変数 INIT_ASSETS の既定は 1 で、設定ディレクトリへ見本の config と favicon を入れる案内があります。書き込み権限がないと初期配置に失敗します。SUBFOLDER は /homer のような配下パス、PORT は内部 8080 の変更、IPV6_DISABLE=1 は IPv6 待受停止です。

Kubernetes は docs/kubernetes.md、設定詳細は docs/configuration.md、テーマは docs/theming.md、Smart cards は docs/customservices.md です。キーボードショートカットは / で検索開始、Escape で終了、Enter で先頭一致を開き、Alt または Option と Enter で新しいタブです。ブックマークの _target を尊重すると README は書いています。ライセンスは Apache-2.0 で、本文はリポジトリの LICENSE が一次資料です。file:// で index.html を開いた結果を、これらの版や環境変数の確認に使わないでください。

編集部の結論

既に複数の自宅サービスを運用し、リンクと表示情報を軽い静的ページに集約したい人に適しています。まずassets/config.ymlを用意してHTTPサーバー経由で開き、Dockerなら設定ディレクトリのマウントとUID、GIDを確認してください。file://では動かないため、リンクの遷移、アイコン、サブフォルダー設定を実際のWebサーバーで試し、認証やサービス監視がHomer自身の機能だと誤解しないことが重要です。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes