ホームラボ 2026 の現状: セルフホスティング趣味の進化

 (mrlokans.work)
59 ポイント 投稿者 GN⁺ 16 일 전 | 19件のコメント | WhatsAppで共有
  • 小規模ハードウェアと無料のクラウドトンネリングを組み合わせ、メディア・AI・写真・モニタリングなど多様なサービスを自前で運用するホームラボ構築事例の整理
  • OrangePI 5から始め、GMKTec NUC（32GB RAM、1TB NVMe）へアップグレードし、Hetzner仮想マシンを並行運用するハイブリッド構成
  • すべてのサービスはDockerコンテナで稼働し、Ansible role ベースの IaC と SOPS 暗号化で再現性とセキュリティを確保
  • Cloudflare Tunnel を通じてインバウンドポートを開放せずに外部アクセスを提供し、Traefik + Authentik でリバースプロキシと SSO 認証を処理
  • 月額約 7ユーロの運用コストでベンダーロックインなしにデータ所有権を維持し、完璧さより学習と楽しさを重視

ハードウェア構成

  • 初期は OrangePI 5 を使っていたが、電源管理と USB 接続ストレージの問題により GMKTec NUC に移行
    • AMD Ryzen 7 5700U CPU、32GB RAM、1TB NVMe M2 ストレージを搭載
    • M2 スロットが2基あり、RAM とディスクの両方を拡張可能
    • 年間運用ベースでははるかに安定して動作
  • 24/7 稼働が必要なサービスは Hetzner 仮想マシンで別途運用
  • NAS はまだ構築しておらず、Syncthing で重要データを同期
    • Ugreen NAS や Ubiquiti などにも関心はあるが、現時点では自分で触って作る過程そのものをより楽しんでいる段階

運用原則

  • Infrastructure-as-Code: 可能な限りすべての設定をスクリプトまたは管理プラットフォーム（Ansible など）で自動化し、コードとして保存する
  • 再現性（Reproducibility）: 障害発生やマシン交換時にインフラを素早く再デプロイ・再構成でき、実験サービスを削除した際にも残骸が残らないこと
  • 使いやすさ: 趣味プロジェクトである以上、標準的で馴染みのあるアプローチを好む

オペレーティングシステム

  • Debian ディストリビューションをベアメタルに直接インストールして使用
  • NixOS（再現可能ビルド）や Talos（k8s クラスタ）なども検討したが、単一マシンでの k8s ワークロード管理の負担と時間不足により保留
  • ProxMox のような ハイパーバイザーも不要 と判断し、使用していない

ネットワークアーキテクチャ

  • 外部公開方式として Cloudflare Tunnel を採用
    • サーバーから Cloudflare ネットワークへ アウトバウンド専用接続 を作るため、ファイアウォールでインバウンドポートを開ける必要がない
    • トンネル設定後は双方向トラフィックがトンネルを通って流れる
    • ドメインを Cloudflare DNS に接続すると、サブドメインごとにマシン上の特定ポート・プロトコル（HTTP/HTTPS/TCP など）へマッピング可能
    • 完全 無料 で提供され、ngrok より優れた代替と評価
  • 固定 IP（グローバル IP）方式はコストとセキュリティリスクがあり、Tailscale Funnel などの代替もあるが、最も手軽なソリューションとして Cloudflare Tunnel を選択

  • Traefik

    • オープンソースのリバースプロキシで、Docker をネイティブに認識するためサーバー自動化に有利
    • コンテナに適切なラベルを付けると 自動でルーティングを検出 し、別途設定ファイルを編集する必要がない

  • Authentik

    • IdP（Identity Provider）および SSO プラットフォーム
    • 設定を ブループリント（YAML ファイル） 形式で保存できるため、IaC 原則に従える
    • ForwardAuth ミドルウェアを通じて、機密性の高いサービスへアクセスする際にログインページへリダイレクト

運用ツール

  • Ansible

    • エージェントレス（SSH のみ必要） なインフラ自動化ツールで、YAML ベース設定と豊富なサンプルが強み
    • 各サービスを role 単位で定義: tasks、defaults、handlers、templates、files で構成
      • tasks: 実行する作業を定義
      • defaults: イメージタグ、ポート、コンテナ名などの既定値
      • handlers: 設定変更時にコンテナを再起動
      • templates: Jinja2 ベースの .env ファイルや config.yaml をレンダリング
      • files: 静的設定、スクリプト
    • サービスデプロイの一般的な手順:
      • 共有リソース（ネットワーク、ボリューム）作成 → PostgreSQL にスキーマ・ユーザー作成 → 設定テンプレートをレンダリング → Docker イメージを pull → コンテナ起動（環境変数、ロギング設定を含む） → Authentik ブループリントへ認証設定をプロビジョニング → 必要に応じて Cloudflare Tunnel を設定
    • 欠点として 膨大なドキュメント、反復的な DSL 構造とボイラープレートがあるが、慣れているため使い続けている
    • GitOps 統合なしで 手動で playbook を実行、現時点ではそれで十分

  • SOPS (Secrets OPerationS)

    • YAML/JSON の値だけを暗号化し、キー構造はそのまま維持するため Git diff が有用に機能する
    • age 暗号化バックエンドを使用 — 「PGP なしで暗号化をシンプルにした」ツール
    • ホストごとに通常設定ファイル（homelab.yaml）と暗号化ファイル（homelab.sops.yaml）を分けて管理
    • ワークフロー:
      • age-keygen で鍵を生成 → sops コマンドで暗号化ファイルを編集（エディタで復号し、保存時に自動で再暗号化） → Ansible 実行時に 自動復号
      • Ansible は SOPS をネイティブサポートしているため、追加モジュールやフラグは不要
    • Ansible Vault と比べた利点: ファイル全体ではなく 値単位の暗号化 により diff を活用できる
    • 制約: age の秘密鍵をチームメンバーと安全に共有する必要があり、鍵を失うとシークレットを復旧できない
      • 1人で運用するホームラボでは適切な程度の複雑さ

稼働中のサービス

  • メディア管理: *arr スタック

    • Prowlarr: インデクサ管理者として検索結果を他の *arr サービスへ渡す
    • Radarr: 映画コレクション管理 — 欲しい映画を指定すると検索・ダウンロード・整理を自動実行
    • Lidarr: 音楽向けの同様の機能で、Navidrome と連携
    • Bazarr: 字幕を自動ダウンロード
    • Tidarr: Tidal 音源をローカル保存できるサービス
    • Transmission: BitTorrent クライアント（ポート 9091）で、すべての *arr サービスのダウンロード要求を処理
    • すべてのサービスは Authentik 認証 の背後に配置
    • 共有ダウンロードディレクトリ（/mnt/data/docker/transmission/downloads）と PUID/PGID 1000 を使用し、ハードリンク でディスク容量を節約
    • ワークフロー例: 映画を Radarr に追加 → Prowlarr で検索 → Transmission がダウンロード → Radarr がメディアライブラリへ移動 → Jellyfin で視聴可能

  • メディア消費

    • Jellyfin: オープンソースのメディアサーバーで、Plex と違ってクラウドログイン不要。独自認証を使い、Android TV アプリを含む多様なデバイスに対応
    • Navidrome: Subsonic API をサポートする 音楽ストリーミングサーバー。モバイルアプリ（DSub2000 など）と連携。Lidarr がライブラリフォルダへ音楽を供給
    • Calibre Web: 電子書籍ライブラリ管理およびリーダー
      • ノートPC上の Calibre デスクトップアプリで管理しているメタデータ DB を Syncthing でサーバーに同期
      • OPDS API を通じて複数のリーダーから書籍にアクセス可能

  • AI とチャット

    • LibreChat: セルフホスティング型 AI チャットインターフェースで、複数の LLM プロバイダー（OpenAI、Anthropic、ローカル Ollama）に接続可能
      • RAG（Retrieval Augmented Generation） をサポート
      • MongoDB（チャット履歴）、PostgreSQL + pgvector（埋め込み）、MeiliSearch（全文検索）が必要で、比較的重い構成
      • Claude Code の方が使いやすく利用頻度は低いため、削除を検討中

  • 写真とファイル

    • Immich: セルフホスティングの Google Photos 代替 サービス
      • スマホからの自動写真バックアップ、顔認識、アルバム整理、EXIF メタデータ抽出
      • 独自の PostgreSQL（pgvector 含む）と機械学習コンテナ（画像分類）を使用し、現在数千枚の写真を保存中
    • Syncthing: ノートPC・スマホ・サーバー間でフォルダを同期。クラウド仲介なしの P2P 直接同期
      • Obsidian Vault、ドキュメントなどを複数デバイスと Android 間で同期
    • MinIO: S3 互換オブジェクトストレージで、S3 API が必要なテストやアプリケーションに活用

  • 読書と情報

    • Miniflux: ミニマルな RSS フィードリーダーで、約50件のブログ・ニュースソースを購読
      • キーボードショートカットをサポートし、アルゴリズムによる並べ替えなしの 時系列フィード を提供

  • インフラと認証

    • Traefik: ホスト名ベースで Docker コンテナへトラフィックをルーティングするリバースプロキシ。コンテナ起動時に適切なラベルさえあれば自動検出
    • Authentik: SSO および ID プロバイダー。ForwardAuth ミドルウェアでサービスを保護し、ブループリントを Git に保存して認証設定全体を管理
    • PostgreSQL: 共通データベースサーバーとして、Authentik・Miniflux・Immich・LibreChat などが個別 DB の代わりに 1つのインスタンスを共有 し、リソース節約とバックアップ容易化を実現
    • Redis: 共通キャッシュおよびセッションストア。主に Authentik などのセッション管理やジョブキューに使用

  • カスタムソフトウェア

    • Highlight Exporter: KOReader、Readwise、Apple Books から書籍ハイライトを抽出し、Obsidian 互換 Markdown に変換する Go サービス
    • Telegram Assistant: さまざまな自動化作業とグループチャット内での AI アクセスを提供する Telegram ボット。新技術の試験用として 最も頻繁に書き直している プロジェクト
    • Chess-blunder trainer: chess.com や lichess.com の対局を読み込み、Stockfish で分析後に 悪手だけを選別して訓練 する Web アプリで、近日オープンソース公開予定

モニタリング

  • Beszel

    • 設定と運用が簡単で、優れたデフォルトを備えた 軽量モニタリングソリューション
    • Grafana スタックは2台のマシンで基本的な OS 統計を見るには過剰で複雑だと判断
    • Glances などの類似プロジェクトも調整が多すぎると感じた
    • Beszel は必要機能の 120%をカバー しつつ導入が簡単

  • Statsping

    • 特定リソースの細かな監視のための ミニマルなサービス ping ツール
    • 定義したエンドポイントへ ping を送り、遅延と可用性を報告し、サービス障害時には複数の方法で通知
    • ホームラボ障害時にも生き残るよう クラウドマシンでホスティング し、別途メンテナンスのオーバーヘッドはない

現在足りていない部分

  • バックアップ

    • バックアップの重要性は認識していながら、現状 まったく実装していない
    • 映画・音楽・写真データの損失よりも各サービスの データベースバックアップ が必要だが、適切なソリューション（restic など）とハードウェア構成をまだ決められていない

  • RAID 設定

    • メディアデータとシステムが 単一の M2 NVMe ドライブ に同居している状態
    • NAS サーバーや別バックアップマシンを置くための物理的スペースが不足

  • クラウド独立性

    • リソース可用性を Cloudflare Tunnel のインフラに大きく依存
    • Cloudflare 障害時にはインフラへのアクセスも同時に止まり、今後は代替手段への投資を計画

  • 完全な IaC と自動化

    • CI パイプラインや自動プロビジョニングなしで Ansible playbook を手動実行
    • 現時点では GitOps への移行が大きな利点をもたらすとは感じていない

コスト効率と結論

  • Hetzner 仮想マシンに月額約 7ユーロ を支出、ホームサーバーの電力消費はごく小さいと推定
  • 新サービス追加や設定変更には約 20〜30分 を要し、かなりの部分を Claude Code に委ね、デプロイ前に簡単なレビューだけ行う
  • プロジェクト全体に費やした時間は数年にわたり約 100〜150時間 と推定
  • 最小限の ベンダーロックインなしで データを所有でき、突然の利用規約変更やアルゴリズムフィード、買収・合併によるデータ消失リスクがない
  • 完璧なシステムではなく インフラ理解と楽しさ が目標であり、デプロイするサービス、書く Ansible role、暗号化するシークレットの一つひとつに学習価値がある
  • ホームラボを始めるなら、小さく始めて、考えすぎないことが重要

関連記事

19件のコメント

 
dongho42 15 일 전

Tailscaleを使っていましたが、今はCloudflare Tunnelを使っていて本当に気に入っています。用途は互いに少し違いますが、私の場合はTailscaleがAdGuardと競合してしまって使いにくかったです。
 
minhoryang 14 일 전

Tailscaleの親DNSをAdGuardに指定すればいいのではないですか？
 
click 14 일 전

AdGuard Desktopではありませんが、AdGuard MobileはローカルVPNとして動作するため、併用できません
 
dongho42 14 일 전

DNSではなく、VPNの部分で競合が起きていたようです。
 
kw9101 16 일 전

最近、Google NestでMBCラジオを流せるようにしようといろいろ試していたところ、
Cloudflare Tunnel を使いました。なぜ無料なのかと不思議に思うほど良いサービスです。
 
hulryung 15 일 전

面白そうですね。ぜひ詳しく聞かせてください。
 
toida 14 일 전

私は Oracle Cloud の free tier を使っています。4 vCPU、24GB RAM、200GB で、Arm ベースなのでたまに互換性のないものがあるのを除けば、おもちゃとして最高です。
 
click 15 일 전

新しく契約した通信会社で 80、443 ポートが塞がれていたので、cloudflare tunnel で迂回して使っています
これがなかったら違約金を払って通信会社を変えるところでした
 
recast7838 15 일 전

どこの通信事業者を使っているのですが、ポートが塞がれているのでしょうか？
 
click 14 일 전

正確には自分で塞いでいたわけではなく、通信事業者のルーターが 80、443 のポートフォワーディングをできないようにしていたのが正しかったです。
ポートフォワーディングのために市販ルーターを使ったら、1G オプションで契約したプランの速度をこっそり 100Mbps にナーフされてしまって、
代案を探していたところ、CF Tunnel につないでしまうのがいちばんすっきりしていると感じました。
 
keepworking 14 일 전

市販のルーターにMACアドレスを変換してくれる機能があるか確認して、通信会社のルーターのものに変換してみれば、それも回避できそうです。
 
click 13 일 전

CF Tunnelを設定してから、80番と443番ポートに溜まっていたfail2banのログがまったく出なくなったので、完全に外してそれ以降は気にしなくなりました。
ドメイン自体をCloudflareで購入し、SSOもCloudflareで設定して、SSOを通過できなければサービスを使えないようにして、すべての攻撃をCloudflareが代わりに受け止める構成にしています。
自分一人だけが使うサービスしか入っていないので、この構成でも十分実用的でした。
Cloudflareが障害になったら、その程度は受け入れることにしました。
 
antegral 14 일 전

通常、通信事業者のルーターではポートフォワーディングが塞がれていることがあると聞いています。

市販のルーターを1台付ければ開けることはできるでしょうが……おっしゃる通り、cf tunnel には基本的な WAF も付いていますし、しかも ICN リージョンに振ってくれるので、使わない大きな理由はありませんね
 
bus710 15 일 전

ホームラボにn8nを載せて、Anthropic、Telegram、ストレージなどをつないで細々した作業を回しているんですが、コネクタがよく整備されていて便利でした。
 
ndrgrd 15 일 전

Ryzen 8000シリーズの低消費電力機を24時間365日稼働のホームサーバーとして使っています。
普段はNASとして使い、コンテナや各種サービスを合わせて70個ほど動かしていますが、電力使用量は月10kWhも出ませんでした。費用は2,000ウォン程度です。
 
kimjoin2 16 일 전

Cloudflare Tunnel
とても気に入っています。
 
kimjoin2 16 일 전

応答完了まで時間がかかるやつらがたまに 502 を吐くことはありますが、
無料ですからね〜
 
j2sus91 16 일 전

私もクラウドトンネルを使っていますが、とても良いです。
通常、共有ルーターを挟むと外部IPをルーターが持つことが多いのですが、

Cloudflare Tunnelを使えば、内部IPでも
ドメイン登録を通じて外部接続できるようになります〜

しかも無料です。
 
GN⁺ 16 일 전
Hacker Newsのコメント

  • これは本当にすごいけど、Cloudflare Tunnelをメディアストリーミング用途に使うべきではない
    利用規約で禁止されているか、少なくとも想定された使い方ではない。サービスが停止される可能性もある
    代わりにWireguardやTailscaleを使うのがよい
    関連記事

    • だから自分も同じ理由で月5ドルのVPSを借りて、Tailscaleで接続している
      CGNAT回避にも便利で、GUIベースならNginx Proxy Managerを勧める
    • Tailscale Funnelがカスタムドメインをサポートするようになったのか気になる
      自分は今、rathole + traefik構成へ移行中。明け方までいじっていたら徹夜してしまった
    • Cloudflare Tunnelはサービスを公開インターネットに露出させるが、Wireguard/TailscaleはVPNだ
      Tailscale（Headscaleではない）はFunnelというリバースプロキシ機能を提供しているが、個人ドメインは使えない
      CF Tunnelの代替として最も近いのはPangolinで、NetBirdをリバースプロキシ機能付きでセルフホストする方法もある
    • 記憶している限りでは、CFの規約が禁止していたのはメディアのキャッシュであって、ストリーミング自体ではなかったはず

  • これは「独立」に対するファンタジーというより、システム管理者になることへのファンタジーに見える

    • 自分はライセンスの問題で好きな音楽へのアクセスが塞がれるかもしれないと心配しなくていいのが本当にうれしい
    • 独立には責任が伴う。両者は切り離せない
    • たとえばr/homelabには、NASを自作して妻の写真をGoogle Photosの代わりに保存させている人たちの話がある
      でも正直、GoogleやAppleに月5ドル払うほうがずっと良い選択に思える。3-2-1バックアップすらしているのか疑わしい

  • 地元の図書館でこういうサービスを運営するボランティアグループがあればいいのにと思う
    子どもたちがサービス運用を学び、技術に不慣れな人たちもオープンソースを活用できる良い機会になるはず

    • ただ問題は常にサポートだ
      誰もカスタマーサポートを担当したがらない。だからたいていのサービスは「サポートはあちらへ問い合わせてください」と言えるように金を払う構造になっている

  • 自分はシークレット管理に fnox を使っている
    sopsよりはるかに多くのバックエンドをサポートしていて、**DX（開発者体験）**もより良いと感じる

    • 自分はInfisicalをセルフホストして使っている
    • 面白そうだ。今はSOPSを使っているが、代替として検討する価値はありそう

  • 「独立して備えた男性のファンタジー」という言い方もあるが、結局Cloudflareが間に入っているので完全な独立ではない

  • Cloudflare Tunnelは本当に優れたツールだ
    以前は自宅IPで直接ホスティングしていたが、今はcloudflaredでずっと楽に管理している
    ファイアウォールやネットワーク侵入の心配も減った
    自分のhomelabは今ではClaudeが書いたidempotentなbashスクリプトで管理している
    依存関係は、属性を変更したいという人の欲求のせいで複雑になり、その相互作用がバグを生むと感じる
    だから単純なbashスクリプトで全部を表現するほうが安定している
    現在はsystemd + podmanコンテナを使っており、自分用の記録としてメモページを残してある

    • Cloudflareがすべてのデータを見られるというプライバシー上の懸念はないのか？
      現実的な利便性がその欠点を上回ると考えているのか気になる
    • 単にWireguardを使うのと比べて、Cloudflare Tunnelの利点は何なのか知りたい

  • どうしてみんなこういうものを公開インターネットに載せるのか理解できない。Tailscaleを使えばいいのでは

    • アプリをインストールして公開URLだけ指定すればいいのは便利ではある。同じtailnetに属している必要がないから
    • Tailscaleはやりすぎな解決策だ。ポート80と443だけ開けて、リバースプロキシで認証をきちんとすれば十分安全だ。自分は何年もそうして運用している
    • でもスマートTVのようにTailscaleをインストールできない外部ユーザーがJellyfinにアクセスする必要がある場合もある

  • 筆者はhomelabとself-hostingを混同しているように思う
    self-hostingは実際に使うサービスを運用することで、homelabは実験と学習のための環境だ
    自分は個人データやサービスをhomelabには置かない。壊れてもおかしくない場所だからだ

  • ウクライナでは実際に地下バンカーの中で本番トラフィックを処理しているSaaS企業を見たことがある

  • ストリーミングのサブスク料金だけで年間1,300ドルになっていて衝撃を受けた
    それでNASと36TBのHDDを買い、arrスタックを構築してすべてのサブスクを解約した
    家族全員がそれに倣い、年間5,000〜6,000ドル節約している
    NASは数か月で元が取れる見込みで、今ではもう全部が純粋な得だ
    Claude Codeのおかげで設定も数時間で終わった
    しかもNetflixやHuluの雑音なしのコンテンツキュレーションができるようになって、ずっと快適になった

    • もうひとつの大きな利点は、高ビットレートのストリーミングが可能なことだ
      4K Blu-rayをリッピングして自宅でストリーミングすれば、商用サービスよりずっと高画質になる
    • 自分はハイブリッド方式を使っている。低価格のサブスクは維持しつつ、広告なしの最高画質は自前のメディアサーバーで見る
      最近のストリーミングサービスはコストパフォーマンスが最悪だと感じる。高額プランでも1080p止まりのことが多い
    • それは合法なのか気になる。アップロードは避ける方式なのだろうか
    • あるいは、そもそも金も時間も注ぎ込まず、コンテンツ消費依存から抜け出して別の趣味を見つけるのも一つの手だ