- 長年にわたりさまざまなセルフホスティングのアプローチを試した末に、自分向けのカスタム環境をうまく構築できた経験を共有
- 主な目標は個人データの統制と信頼できるインフラの維持であり、そのために NixOS、ZFS、Tailscale、Authelia など複数の中核技術を組み合わせた
- 家族や身近な人の使いやすさまで考慮し、SSO や専用スタートページの導入などでアクセシビリティも強化
- 実運用で直面した課題と具体的な解決策（例: プライベートサービスの公開プロキシ、混在 VPN 環境、認証連携）を詳しく整理
- 今後はバックアップ基盤やセキュリティ強化などの追加改善を予定しており、ノウハウと参考資料も残している
紹介と動機
- 数年にわたって複数のセルフホスティング方式を試した末に、自分に合った「十分に良い」環境を構築
- さまざまなオープンソース資料や他者の経験を参考にしており、その過程を共有することで他の開発者の役に立てたいとしている
目標
- 個人データとそのサービスを自ら統制することで、プライバシーを強化し、依存サービスの変更や終了リスクの最小化を追求
- この統制を家族や身近な人にも提供し、信頼できるサービス環境を整えることに注力
要件
-
必須要件
- 可能な限りサービスの公開インターネット露出を制限し、セキュリティ事故のリスクを低減
- ミスによる中核インフラのダウンタイム最小化（循環依存の回避と設定ロールバックの容易さを確保）
- 認証・ネットワーク・ドメインなど中核コンポーネントを自ら所有し、オープンソースを優先して適用
- 家族や身近な人の観点での使いやすさに配慮（統一されたSSO ログイン、最小限の保守で済むこと）
- 設定ファイルの宣言的構成を積極導入（バージョン管理やバックアップ・復旧の容易さ、他人の設定を参考・再利用しやすいこと）
- アップデートが簡単かつ安全で、定期的に管理できること
-
非優先要件
- 極端なモジュール化や美しさは不要（実用性優先）
- すべてがオープンソースである必要はないが、可能なら活用
- **高可用性（HA）**は追求せず、ダウンタイムを受け入れる代わりにシンプルな構成を採用
技術選定
-
NixOS
- OS のあらゆる設定を Nix 言語とパッケージマネージャで宣言的に管理するLinux ディストリビューション
- 構成がコード化されるため、バージョン管理と体系的なロールバックが可能
- 豊富なパッケージと Docker/PODMAN などの連携もサポート
- 他の開発者の Nix 設定を参考にしてノウハウを蓄積
-
ZFS
- 高性能ファイルシステムで、スナップショットやロールバックなどデータ保護機能に優れる
- 10TB HDD 4 台を RAIDZ2 で構成（2 台同時故障まで許容）、256GB SDD でキャッシュを適用
- ファイル・メディアのデータセット分離、用途別の NFS マウントで管理
- シンプルで信頼性の高いメインストレージアーキテクチャを構成
-
Tailscale & headscale
- Tailscale: 使いやすいメッシュ VPNで、クライアントをインストールするだけで公開インターネットに露出せず内部ネットワークへアクセス可能
- Headscale: セルフホスト可能なオープンソースの Tailscale バックエンド（企業ポリシー変更リスクを排除）
- ネットワーク安全性の強化に効果がある一方、ユーザーデバイスへのクライアント導入が必要
- Usability の観点では、デバイスごとのクライアント導入がやや導入障壁になる
-
Authelia & LLDAP
- Authelia: OpenID Connect ベースの SSO・認証・認可ソリューションで、nginx プロキシと連携可能
- LLDAP: Lightweight LDAP。Authelia のユーザー・グループ管理とバックアップ認証に活用
- 最小限のリソースでうまく動作するが、構成難易度は高く、どのサービスとどう連携するかの学習コストがある
構造設計
-
アーキテクチャ
- 各サーバーには Star Wars の惑星名を付けている
- エントリーポイント（public server）は「taris」で、Authelia、headscale、ブログなど必須サービスを提供
- headscale、Authelia、LLDAP は外部アクセス可能である必要があるため、限定的にパブリック運用
- プライベートサービス（Foundry VTT、監視など）は NGINX でプロキシし、選択的に公開
-
プライベートサーバー
- メインサーバー「kuat」では TrueNAS で NixOS VM と ZFS ストレージプールを管理
- 「files」（復旧不能データ）と「media」（望めば復旧可能なデータ）でスナップショット／バックアップのスコープを分離
- 主要サービスは「bespin」VM で NixOS により運用し、テスト用 VM（「alderaan」）も別途構築
-
その他のサービス
- ミッションクリティカルなデバイスは単一目的のアプライアンスとして構成（例: スマートホームには Home Assistant OS を別途使用）
- Matrix サーバーと Element クライアントは公式 Ansible Playbook を活用
- メールとパスワード管理は ProtonMail と Bitwarden の外部サービスにアウトソースし、循環依存を遮断
個別の課題と解決
-
サービスのスタートページ
- Flame ベースのシンプルなダッシュボードで、ユーザーごとのサービスアクセス性を向上
- 使用量が少なく視覚的な完成度も高いため、代替サービス導入前まで実用的に運用
-
Tailscale と他 VPN の併用
- 一部の OS（特に Android、Windows）は複数 VPN の同時実行が不可
- Tailscale の exit node 機能と Gluetun（コンテナベースの VPN クライアント）の組み合わせにより、ProtonVPN など外部 VPN の迂回利用に対応
- ただし、バッテリー消費の増加や断続的な速度低下といった副作用がある
-
認証（Authentification）の注意点
- セルフホスティングサービスごとの主要認証プロトコル: OIDC（優先）、OAuth、LDAP
- 各サービスと Authelia にそれぞれ個別設定が必要
- 管理者アカウントは必ず Authelia/LLDAP 連携とは別に維持し、認証問題発生時の復旧手段を確保
- OIDC 非対応サービスは NGINX と Authelia のプロキシ連携でアクセス制御を実装
- Authelia の OIDC と NGINX Proxy のアクセス制御は別構成が必要
-
DNS と SSL 発行
- 公開サービスは一般的な方法（ドメイン→パブリック IP）で運用
- 内部サービスは「internal」サブドメインと Tailscale IP を活用し、外部露出を遮断
- SSL 証明書は NixOS 組み込みの Let's Encrypt サポートを利用（公開サービスは HTTP-01、内部サービスは DNS-01 方式）
-
NixOS VPS インストール時の注意
- 多くの VPS では NixOS のインストールオプションが提供されていない
- インストールが必要な場合はコミュニティ Wiki などを参照し、対応するインストール経路を確認する必要がある
-
TrueNAS データセットの VM マウント
- TrueNAS のデフォルトファイアウォールは、VM からホストへのアクセスを遮断する
- 公式ガイド（Bridge ネットワーク作成）に従って NFS データセットのマウントを実装
-
個人サービスの公開プロキシ
- headscale ベースの場合、NGINX
proxyPass でプライベートサービスを外部公開できる
- Tailscale 公式 Funnel 以外にも、設定例や構成の参考資料を提供
次のステップと課題
- 専用バックアップサーバーと復旧検証体制の追加が必要
- Tailscale/headscale のアクセス制御を積極活用する計画
- SSH アクセスなど追加のセキュリティ強化を進める予定
- Pi-hole、AdGuard Home などローカル DNS の暗号化・キャッシュソリューション導入を検討
- Forgejo、Manyfold、RomM など新規サービス拡張を検討
参考資料
2件のコメント
すてきですね！
Hacker Newsのコメント
家族や友人が簡単に使えるようにするには、1人につき1つのログインアカウントでSSO（シングルサインオン）ベースで複数のサービスにアクセスできるようにするのが目標で、ここが本当に難しい一方で同時に格好いい部分でもある。オープンソースとLinuxは実に逆説的で、本当にどこでも使われあらゆるプロトコルも扱えるのに、実際のクライアント環境、つまり人々をひとつに結びつけたりグループウェア的な要素を自分で構築したりするのは、むしろより複雑になる。複数のシステムを有機的に連携させ、ディレクトリインフラまで構築する過程そのものが驚きだ。いつかFreeIPAやWindows互換のディレクトリサービスを自分で運用することになるとは思っていたが、最近はOpenIDベースの世界が実際に根付きつつあるようにも感じる
共感に感謝する。シンプルなログインとアクセシビリティはこのプロジェクトで最も難しい要件で、実際に人が使うかどうかを左右するポイントだと思う。オープンソースは本当にどこにでもあるが、一般ユーザーが自分で何かを使おうとした瞬間から問題が起きる。この逆説は、各プロジェクトがそれぞれ独自に革新しようとする意志があるから生まれるのだと思う。ひとつの方向に引っ張る主体がいないのは長所でもあり短所でもある。それでも最近5年間のセルフホスティング環境だけ見ても、インストールや利用の面ではずっと簡単になってきていると感じる
この逆説には本当に同意する。昨日も、FOSSが非技術者にとってどれほどアクセスしづらいかについて、自分の検証プラットフォームに投稿した。技術的なユーザーと非技術ユーザー個人をつなぐ、システムインテグレーターのようなプラットフォームが解決策になるのかもしれないと考えている
実際のところ、そこまで難しくはない。特定のサービスにこだわるのではなく、SSO対応かどうかを最優先の選定基準にすれば、意外と簡単にセットアップできる。自分も最初はほとんど経験がなかったが、caddyとauthentikを使ってすぐにセルフホスト環境を完成させた。代替として、yunohostはSSOまで含めて全部自動で構成してくれる非常に簡単なディストリビューションだ
自分はauthentikでGoogle、Discord、GitHubのSSO認証を使っている。みんなにとって十分うまく動いている
誰にとっても自分だけの「ぴったり合う」システムを見つけるには時間がかかることは分かっている。目標も好みも環境も人それぞれなので、自分の最終的なセットアップ過程をブログ記事として整理して共有したい。目標と要件、使用技術、設計、問題解決の過程を扱う。自分のやり方が誰にでも合うわけではないが、ほかの人の参考にもなればうれしい。自分も多くのコンテンツとフリーソフトウェアのおかげで成長してきたので、これからも助けを分かち合いたい
Nixをホームラボで使ってみた感想が気になる。自分はかなりハードコアに25Uラックで小規模なkubernetes、ceph、Talos Linuxまで7年以上回しているが、だんだん単純化したくなって考えていると、不思議とNixとZFSに行き着く。関連する難しさにはとても見覚えがある。そちらも気になることがあれば聞いてほしい
coolifyの利用は検討したことがあるだろうか。自分は1年以上coolifyを使っていて、HerokuのようにGitHubから自動デプロイされる点がかなり気に入っている https://coolify.io/
ZFSの暗号化機能も使っているのか気になる。自分は以前、FreeIPAなど複数のVMをDebian+ZFSで動かしていたが、単純化のためにVPSではSeafileの暗号化ライブラリだけを動かし、ZFS send/receiveで自宅サーバーにバックアップする構成へ変えた。そのサーバーは毎晩起動し、アップデートと同期の後に再びスリープする。さらに安全にするため、Linuxデスクトップ（Fedora）のZFSも全面暗号化で運用しようか考えている。メインのデータセットがすでに暗号化されているので、外付けドライブやクラウド同期もずいぶん簡単になる。写真ライブラリ全体をVPSのSeafileに載せるのはコスト負担が大きく、方法を探している
セットアップの感想と詳細な説明が役に立った。あなたのようにすぐ導入するのは難しいが、ダッシュボードとしてflameを入れて家族と試してみることにした
はじめまして。あなたの作業は本当に興味深い。自分もNixOSベースで似たプロジェクトに取り組んでいる。目標は、誰でもモデムにつないでWebインストールウィザードを通せば終わる、ほぼゼロ設定のApple的な雰囲気を持つ小さな箱を作ることだ。まだ初期段階だが、すでに自宅で運用している。ハイブリッドルーター（OPNSense/PFSense）とアプリサーバー（Nextcloud、Synology、Yunohostなど）の役割を一度に担う。すべての設定も1枚のNixモジュールで管理し、ダイナミックDNS、Let's Encrypt証明書、各アプリごとのサブドメイン自動割り当て、広告ブロック、headscaleを内蔵している。今はSSOまで作っているところで、あなたの記事からも少しアイデアをもらおうと思っている。詳しくは https://homefree.host を参照
ときどき自宅ネットワークを見て、自分が死んだら家族にどれほどの迷惑をかけるだろうとか、部外者がこのセットアップを理解するのがどれほど大変だろうかと想像する。「ホームラボ遊び」は実のところ、地下鉄模型のレールを作る昔ながらの「おじさん」たちの趣味に似た何かを満たしてくれる。これを悪く言っているのではなく、人によっては、自分だけが完全にコントロールできるミニチュア世界を持ちたいという本能があるのだと思う
自分もまったく同じことを考えて、もしものときに備えた文書を書いてある。第1部はお金と重要書類の場所、第2部は家をどう「もっとバカに」戻すかの手順だ。たとえばスマートスイッチを撤去して従来型のスイッチに戻す方法、Bitwardenのようなキープラットフォームをクラウドへ移す方法、ドメインやメールの維持費、ルーターをISPの標準機器に戻す方法などだ。妻はスマートホームに前向きではなかったが、いつでもまた「普通の家」に戻せると伝えたら安心していた。正直、これが全部なくなったらどれほど不便なのか分からないが、それは自分の仕事ではなくなるという慰めもある
うちでは家族写真をhome labのRAID1に保存し、毎晩、義理の両親の家にあるコンピューターの外付けドライブへrsyncでバックアップしている。バックアップであると同時に、何かあっても家族が簡単にアクセスできるようにするためだ。妻はITに関心がないので、「USBをつなげば全部入っている」とだけ伝えてある
物理ディスクの盗難のような、あまり意味のない脅威シナリオは無視してよいと思う。すべての写真と主要文書は暗号化せずに保存し、分かりやすい説明も一緒に残しておくのが現実的だ。むしろホームオートメーションのほうが心配事は多い
ホームラボ運営者が長く不在になる場合や、もしもの事態にどう備えるかを事前に考えておくのは実務的に重要だ。自分はこれを簡単にするために特別な配慮をしてきたわけではないが、もっと考えるべきだとは感じている。重要なのは、大事なデータとそこへアクセスするための認証情報を残すことだ。Nextcloudのようなサービスを活用して、データが自動的に家族のデバイスに同期されるようにし、実際に家族や友人が自分で使ってみるようにするのがよい。うちでもHome Assistantは、配偶者と一緒に使う程度にはある種の必需家電のようにしたいと努力している。これが別のVMではなく実物として存在するほうが、管理しやすくなる。もちろん、これらは希望的観測が大きいので、少なくとも近しい家族同士では詳細な計画を一緒に立てておくことが重要だ
自分もこの点はかなり考えた。NASやDockerサービスが自分抜きでうまく起動するはずがない、という前提でいる。オフサイトのパスワードバックアップも、実際には専門家の助けなしでは復旧できない気がする。だからNTFSの外付けHDDにcronで毎日増分スナップショットを新しいフォルダとして保存している。容量は50GB未満で安価に二重化できる。もしものときは、そのドライブをつないでフォルダをコピーするだけでよい。各ノートPCにもSeafileのライブラリ全体のコピーがある。メールドメインは10年分前払いしてiCloudでホストしており、家族写真の添付で容量がいっぱいになってメールが弾かれる問題についてはmigaduを検討している
自分もこの分野に強い関心がある。自営業やIT起業を直接始めると、ホームラボ欲がさらに強くなると警告しておきたい。単にコンテナを回すだけでは次第に物足りなくなり、各種書類を提出して合法的なDBAとASNを取得し、本当に自分のIPブロックやIPv6まで持つ、自前のISPのようなものへ進化していく。ingress（外部アクセス）の問題はtailscaleで解決している人が多いが、ここが本当に難しい。STUN/TURNベースの構成でサーバー全体の静的ファイルだけをキャッシュし、動的アクセスはログインウォールでメールのマジックリンク認証にする方式も、理論上はそこまで危険でも高コストでもないと思う。リモート開発環境を構築しながら、こうした部分までさらに掘り下げる口実もできる。参考リンク https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT, https://en.wikipedia.org/wiki/STUN
最近Immichを触っているが、自宅の外ではtailscaleだけで使うか、それともVPSにリバースプロキシまで載せるかで毎回悩む。一番気になるのは、VPS上で誰が攻撃を試みているのかを検知してくれる、ユーザーフレンドリーな監視・セキュリティソリューションを見つけることだ
自分のセットアップはずっと単純だ
HTTPはパスワードを平文で送るので、少なくとも自己署名証明書は使ったほうが安全だ
インフラやサービスまでコードで自作するのは、学ぶには本当に最高だ。自分のニーズにぴったり合わせられる点も素晴らしい
こういうホームラボ運用をしてみたいが時間がない。週末にインストールはできても、保守やアップデートを継続する余裕がない。だから結局クラウド事業者に任せて気にしないようにしている。自分のようにクラウドだけ使っている人は、どういうやり方でアプローチしているのか気になる
自分も以前のセットアップでは保守がちゃんとできずストレスを感じていた。だからNixOSとZFSが好きになった。どちらもロールバックが本当に簡単だ。アップデートして問題があれば前のバージョンへすぐ戻せるし、デバッグは余裕のあるときだけやればいい。それにクラウドの選択肢も、その体験に満足しているならそれでよいと思う。自分でセットアップするのは確かに時間を食うので、各自でコストと価値を比較するのが大事だ
自分は12個ほどセルフホスティングサービスを動かしているが、たいていアップグレードは月に1分もかからない。サービスごとにフォルダがあり、その中にdocker-composeスタックとデータフォルダがある。アップデートは
docker compose pullしてup -dすれば終わりだ。まれに設定変更が必要なアップグレードもあるが、たいていは数分以内で済む。VMも使わず、Docker Composeだけによる完全自動化セルフホストが一番シンプルな方法だと思うこれは単に週末1日だけの話では終わらない。自分の場合、Plexを一度入れてみるところから始まって、1年後にはProxmoxと各種ホームオートメーションが組み合わさった複雑な構造物になっていた。半分冗談で半分本気だが、最小セットアップならdocker composeから始めると管理もしやすくアップグレードも簡単だ
わざわざSSOまで導入する必要があるのか疑問だ。家族や友人がwireguardクライアント（iOSでも非常に簡単）を使えば、トグル一つで自宅ネットワークにつながり、別途SSOがなくても内部サービスをすべて使える。小規模な家庭ネットワークでは、欠点より利点のほうがずっと大きい
うちで使っているNextcloudやMealieのようなサービスは、それぞれユーザー別アカウントが前提だ。SSOのおかげで、すべてのサービスに同じアカウントでアクセスできるうえ、自分がパスワードまで管理する必要もなくなったと思っている。セットアップは少し複雑になるが、運用はむしろ簡単になるので、家族も実際に使ってくれる可能性が高くなる
自分は20個のアプリをセルフホストしていて、それぞれの認証を別々に管理するのにうんざりしてSSOを導入中だ。家族に一部のアプリを公開したいときも、認証の問題を一か所で処理できることが最優先だ。上で言われているやり方には同意しにくい
flameをわざわざ使う理由が気になる。node、react、reduxなど数十から数百のサードパーティ依存関係を「セキュリティ王国」に持ち込むことになるが、スタートページの役割なら実際にはシンプルなHTML1枚にリンクを並べるだけでもよいのではないかと思う
NixOSでセルフホスティングをしてみたいとは思っているが、まだ実行には移していない。自分の環境は、いくつかのVMと、各VMごとにdocker composeファイル1枚で管理しており、ansible playbookでcomposeファイルだけコピーし、Fedora ServerのOSを1リリース遅れで維持して期限が来たらアップグレードして終わりだ。Macではnix-darwinを動かしているので、Nix設定の利点は理解しているが、実際に自分の環境をNixへ移植するほどの効率や時間対効果はまだ感じられない。LLM（大規模AI）が設定ファイルの書き起こしでもしてくれるなら別だが、今のところ挑戦する動機が足りない
自分もNixOSを試して、1週間でホームネットワークと実サーバー2台まで全部移行した。3〜4か月ほど経ったが、期待以上に満足している。サーバーの移行はワークステーションを移すより簡単だった。最近ではJetson Orin NanoというおもちゃもNixOSでセットアップして遊んでいる。昔のGentooだったら考えられないことだ。Gentooで一番嫌だったのは、古いマシンでの信じられないほど長いコンパイル時間だった。たとえば2019年製XPSでGHCをビルドすると6時間かかるほどだった
自分にとってNixOSの最大の違いは、何か壊れたときのロールバックがあまりにも簡単なことだった。ansibleやcomposeベースでもバックアップや復旧はできるが、その仕組み自体を自分で書かなければならない負担がある。それでも今のシステムに満足しているなら、それはそれでよいことだと思う
すでにIaCをある程度使っているなら、NixOSがもたらす追加の効率はそこまで大きいとは感じなかった