Homepageを家のサービス入口にする：Docker連携と公開範囲の設計
Docker とサービス API を統合した、高度にカスタマイズ可能なホームページ (またはスタートページ/アプリケーション ダッシュボード)。
ひと目でわかる
- これは何？
- gethomepage/homepageのREADMEをもとに、静的ダッシュボードの構成、YAML設定、Docker検出、API連携、外部ネットワークでの防御条件を整理します。
- 誰に向いている？
- gethomepage/homepageは、セルフホストした複数のサービスを一つの入口へまとめ、Dockerの状態や各サービスの情報を見やすく整理したい利用者に向きます。多数の連携とカスタマイズがある一方、ウィジェットはホームオートメーションなどの個人情報へ触れ得ます。
- 商用利用できる？
- 条件付きでできます。GPL-3.0 はコピーレフトのライセンスで、これを含むソフトウェアを配布する場合、そのソフトウェアのソースコードを同じライセンスで公開する必要があります。配布せず社内で使うだけなら、この義務は生じません。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に JavaScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Homepageは何を一つにまとめるのか
gethomepage/homepageは、DockerやサービスAPIと連携する、カスタマイズ可能なホームページまたはアプリケーションダッシュボードです。READMEは、ビルド時に静的生成される高速なサイトで、100以上のサービス連携と多言語対応を備えると説明しています。検索、ブックマーク、天気、情報ウィジェットを同じ画面へ置けるため、日々使うセルフホストサービスの入口として考えやすい構成です。
ここでの価値は、サービスそのものを置き換えることではなく、入口と状態表示を整理する点にあります。READMEの「安全」や「高速」はプロジェクトが掲げる特徴の説明であり、利用環境での性能や保護を自動的に保証するものではありません。どのサービスを載せるか、誰が見られるか、APIから何を取得するかを自分の構成に合わせて決める必要があります。
Docker連携はラベルとソケットが鍵になる
Docker連携では、コンテナの状態や統計を表示し、ラベルをもとにサービスを自動検出してHomepageへ追加できます。READMEのDocker Compose例では、ghcr.io/gethomepage/homepage:latestを使い、3000番ポートを公開し、ローカルの設定ディレクトリを/app/configへマウントしています。Docker連携用に/var/run/docker.sockを読み取り専用でマウントする例もあります。
この例から、設定ディレクトリの存在、ポートの公開先、Dockerソケットの権限が導入前の確認点だと分かります。latestタグをそのまま本番の更新単位にすると、いつ変更が入ったかを追いにくくなります。試す版をリリース履歴で選び、設定ファイルを保存し、ラベル検出が意図しないコンテナを表示しないかを確認してください。Dockerソケットに触れる構成の意味も、便利さだけでなく権限境界として評価すべきです。
サービスウィジェットが取得する情報
Homepageは、Radarr、Sonarr、Lidarr、Bazarr、Ombi、Tautulli、Plex、Jellyfin、Emby、Transmission、qBittorrentなど、多数のセルフホスト系サービスを例に挙げています。サービス連携のほか、天気、時刻、日付、検索、Glancesなどの情報提供者もあり、ページ上部にシステムと状態の情報を表示できます。
ウィジェットは、単なるリンクより便利な反面、接続先APIの認証情報と返される情報を扱います。READMEは、APIリクエストをバックエンドへプロキシし、APIキーを隠す特徴を説明していますが、利用側の設定ミスや公開範囲を解消するものではありません。各ウィジェットがどのホストへ接続し、どの値を画面へ出し、失敗時に何を表示するかを確認します。個人情報が含まれるサービスは、表示対象と利用者を分けて設計してください。
YAMLとカスタマイズで画面を組む
HomepageはYAMLファイル、またはDockerラベルの検出を通じて設定できるとREADMEにあります。カスタムテーマ、CSSとJavaScript、レイアウト、書式、ローカライズにも対応します。AMD64とARM64向けのイメージがあり、40以上の言語をサポートするという説明もあります。
設定を増やす前に、サービス、ブックマーク、ウィジェット、全体設定を役割ごとに分けて管理すると、変更の影響を追いやすくなります。独自CSSやJavaScriptは、見た目を整える一方で、アップグレード後の表示崩れや運用担当の属人化を生みます。最初は公式ドキュメントの設定例を使い、必要になった変更だけを追加し、元に戻せる差分として保存してください。多言語対応も、翻訳済みかどうかと、自分の表示要件が合うかを実際に確認する項目です。
外部ネットワークへ出す前の条件
READMEのSecurity Noticeは、ウィジェットがホームオートメーションシステムなどから個人情報へアクセスし得ると注意しています。Homepageを信頼できないネットワークから到達可能にする場合、認証、TLS、Hostヘッダーの厳格な検証を行うリバースプロキシまたはVPNの背後へ置くことが必須だと明記されています。オプションとして、組み込みのOIDCログインまたは簡易パスワードログインも案内されています。
この注意は、公開前の最優先チェックです。HOMEPAGE_ALLOWED_HOSTSは必須環境変数としてDocker例に記載され、必要ならポートも含めます。設定したHost以外からのアクセス、TLS終端の位置、認証前後で取得されるウィジェット情報を確認してください。パスワードやOIDCを有効にしたから十分とは限らず、ネットワーク制御、最小権限、ログの保護を合わせて確認する必要があります。
Docker以外の起動と開発経路
ソースから試す場合は、GitHubリポジトリをcloneし、pnpm installで依存関係を入れ、pnpm buildで本番バンドルを作ります。初回起動ではsrc/skeletonをconfigへコピーして、例の設定ファイルを用意できます。本番モードはHOMEPAGE_ALLOWED_HOSTS=gethomepage.dev:1234 pnpm startで起動する手順がREADMEにあります。開発サーバーはpnpm devで起動し、localhostの3000番ポートを開きます。
このプロジェクトはNext.jsアプリケーションとして説明されています。開発時のlocalhostと、本番モードでリバースプロキシの背後に置く状態を同じものと見なさないでください。設定ディレクトリ、環境変数、ポート、Dockerソケットの有無を起動方式ごとに記録します。ドキュメントをローカルで作る場合は、uv sync後にuv run zensical serveを使う経路もありますが、アプリ本体の運用と文書サイトの生成を分けて管理すべきです。
ライセンスと更新の判断
素材取得時点のメタデータでは、ライセンス識別子はGPL-3.0、既定ブランチはdev、アーカイブ状態はfalseです。32,279 stars、2,087 forks、3 open issuesという記録と、v2.1.2などのリリース履歴は、活動状況を考えるための参照情報です。人気やIssue数だけで、個別の構成が安全、安定、互換だと判断することはできません。
更新時は、イメージの版、設定ファイル、追加CSSやJavaScript、連携するサービスのAPI仕様を保存し、代表的な画面と認証経路を確認します。GPL-3.0の条件は、利用、改変、再配布の形態に応じて法務担当やライセンス文書で確認してください。まずは家庭内または隔離されたネットワークで、表示するサービスと情報を限定して試します。信頼できる公開境界、APIキーの保管、設定の復元手順を説明できる状態になってから、利用範囲を広げるのが妥当です。
編集部の結論
gethomepage/homepageは、セルフホストした複数のサービスを一つの入口へまとめ、Dockerの状態や各サービスの情報を見やすく整理したい利用者に向きます。多数の連携とカスタマイズがある一方、ウィジェットはホームオートメーションなどの個人情報へ触れ得ます。READMEが指定するように、信頼できないネットワークへ出す場合は認証、TLS、Hostヘッダー検証を行うリバースプロキシまたはVPNを先に用意し、許可するAPIと公開範囲を確認してから運用してください。
コミュニティノート