セルフホストするもの、しないもの、そしてその理由

はじめに

「セルフホスティング」という概念誕生以前より、私はこの世界の一員でした。大学生時代から Linux サーバーを運用し、MythTV から Kodi へと移行してきました。最近インド居住中は安価なサービスを利用していましたが、帰国後には欧米の高額な料金を支払いたくないと考えたためです。特に息子へのコンテンツ消費への回転木馬（treadmill）への疲れや、各アプリの自動推薦による不快感から、ストリーミングサービスからの離脱を決意しました。

その結果、私はJellyfinへ移行し、クラウド依存を断ち、心強い安定感を得ました。今や無意味なリデザインや仲裁条項、データ漏洩などの通知に煩わされることはなくなりました。ソフトウェアのアップグレードも自分の判断で行えるようになりました。

運用ルール

1. ネットワーク公開ポリシー

• 原則: ルーター上で動作する VPN サーバーを除き、いかなるサービスもパブリックインターネットに直接公開していません。
• 理由: 利便性やセキュリティは二の次。AI 支援によるハッキングが容易な現状では、公開しない方が賢明です。
• 技術的制約: ISP が IPv4 で CGNAT を採用しているため、IPv4 での直接アクセスは不可能です。VPN サーバーは IPv6 上のみ公開可能ですが、これは好意的でない接続試行を制限するメリットがあります（ただし公共 Wi-Fi での接続は困難）。

2. コンテナ化 vs ネイティブ実行

• 優先事項: サービスが単一 Go バイナリとして提供されれば、ネイティブ実行を強く推奨します。
  • Docker Compose ファイルのみで MySQL/Redis など複数のコンテナが必要な複雑なサービスは代替案を検討します。
  • 依存関係が少ない場合、ネイティブの方がより速く効率的です。
• メリット:

  curl

  が不足しているか、BusyBox の引数違いによる扱いにくさなど、仮想ネットワーク設定の手間がなくなります。
• Docker の廃止: 現在は Docker を使用しません。完全に独立したサービス制御に疲弊したため、すでに systemd を使用中であり、Podman の systemd への統合は優秀であると考えています。

ハードウェア

昨年購入した Beelink Mini PC（Intel N100 プロセッサ、16 GB RAM、512 GB SSD）が主力サーバーです。

• 価格推移: AI バブル崩壊前は 180 ユーロでしたが、現在は 359 ユーロまで値上がりしています。
• ストレージ: メディア格納用に追加で 6 TB のハードドライブを接続しています。
• パフォーマンス: 16 GB で動作させるための選択をした結果、多くのサービスを動かすのに必要なハードウェアはそれほど多くないことが分かりました（地元の AI 推論は行っておりません）。

サービス一覧

Actual Budget（予算管理）

• 機能: デスクトップクライアントと Web アプリ。カスタムレポートやルールベースのカテゴリ分類に対応。投資口座のトラッキングにはクラウドサービスを使用しつつ、将来的には離脱を目指しています。
• データ入力: 銀行からの自動取込は使用せず、月末に OFX/CSV をダウンロードして手動でインポートします（経費追跡目的のため）。
• 配置: ネイティブ

Podman（コンテナ管理）

• 機能: 前述のルールに基づき、複雑なサービスや依存関係が多い場合はこちらを使用しています。Docker よりも Podman の systemd 統合を推奨します。
• 配置: コンテナ化（Podman）

Audiobookshelf（オーディオブック・ポッドキャスト）

• 機能: オーディオブックとポッドキャストのサーバーへの保存、ダウンロード、スマートフォン再生。チャプター管理が優秀で、子供向け設定に利用しています。
• 配置: Podman

Automatic Ripping Machine (ARM)

• 機能: DVD/ブルーレイの自動ライプニングとトランスコーディング。バイリンガルコンテンツ（英語・フランス語）取得の手段としても利用。
• 配置: Podman

Backrest（バックアップ UI）

• 機能: Restic バックアップソフトウェアのための Web UI。ストレージの保持ポリシー管理や、Immich などの写真データの重複排除/圧縮に使用。失敗通知は Gotify へ送信。
• 配置: ネイティブ

Beszel（監視ダッシュボード）

• 機能: CPU 負荷、メモリ、ディスク使用率、温度などを表示するシンプルなモニタリングツール。Raspberry Pi や Proxmox クラスターの管理にも活用。
• 配置: ネイティブ

Caddy（Web サーバー・リバースプロキシ）

• 機能: HTTPS 証明書の自動取得（Let's Encrypt）や、親しみやすいサブドメイン名の設定を担当。Caddyfile の編集で新しいサービスを追加可能。
• 配置: ネイティブ

Cockpit（サーバー管理コンソール）

• 機能: Web ベースの標準的なシステム認証コンソール。特に通知が設定されていないサービスの失敗を検知する際に役立ちます。
• 配置: ネイティブ

Forgejo（Git 代わり）

• 機能: Gitea のフォーク版で単一バイナリとしてデプロイ。GitHub の不安定さへの代替として利用。将来的に CI/CD も設定予定。
• 配置: ネイティブ

Flussonic（RSS リーダー）

• 機能: Web ベースの RSS リーダー。現在は公式サイトへの定期アクセスや、セルフホストサービスのリリースノート確認に使用しています。
• 配置: ネイティブ

Frigate（NVR・セキュリティカメラ）

• 機能: 8 つの IP カメラを動作させ、人物や車の進入を検知してアラートを発信。Home Assistant と統合し、後庭での人物検知でフラッドライトを点灯など自動化。
• 最適化: Wi-Fi 混雑回避のため解像度を抑え、過剰な CPU/ディスク負荷を防止しつつプライバシー保護（遠くのみ）を確保。
• 配置: Podman

Gonic（音楽サーバー）

• 機能: Subsonic 互換サーバー。子供向けと成人向けの 2 つのインスタンスを動作させており、VPN 経由での外出先ストリーミングも可能です。
• 配置: ネイティブ

Gotify（通知サービス）

• 機能: シンプルな Go ベースの通知サービス。多くのセルフホストサービスとの連携や、Uptime Kuma によるダウン時の通知などを担当。
• 配置: ネイティブ

Home Assistant（スマートホーム中枢）

• 機能: Google Home や Amazon Alexa 等のプロプライエタリエコシステムにない制御と柔軟性を提供。Matter プロトコル導入により状況は改善しましたが、学習曲線が急峻です。
• 配置: Podman

Homepage（ダッシュボード集約）

• 機能: 運用サービスの多さを管理するためのウィジェット集約ツール。現在のステータス把握やサブドメインへのリンクに役立ちます。
• 配置: Podman

Immich（写真共有・代替 Google Photos）

• 機能: Google Photos の有料プランからの脱却。家族でのアルバム共有や、内部ネットワーク利用による高速読み込みを実現。複製が多くストレージ容量を気にする必要のあるため選定されました。
• 配置: Podman

Jellyfin（メディアサーバー）

• 機能: 20 年以上のメディア運用実績を持つ MythTV の後継。自動再生や推薦機能のない「純粋な視聴」を実現。720p メディア中心でリソース負荷を抑制。
• 配置: Podman

Music Player Daemon (MPD)

• 機能: 23 年以上の歴史を持つシンプルかつ安定した音楽プレイヤー。Snapcast 経由で家中のオーディオシステムとの連携や、ポッドキャスト再生も担当。
• 配置: ネイティブ

PocketBase（財務管理 DB UI）

• 機能: SQLite ファイルベースだが、Web ベースの管理フロントエンドを提供。家族共同での入力や複雑なクエリに対応しやすくしました。
• 配置: ネイティブ

Readeck（読書アーカイブ）

• 機能: 読んだもののコピーをタグ付けしてサーバーに保存。Zotero から移行し、スマートフォンの画面スクショもアーカイブ可能に。
• 配置: ネイティブ

Samba（共有ストレージ）

• 機能: Windows 互換のファイル共有プロトコル。LAN 上のクロスプラットフォームファイル共有および妻との重要文書共有を担う。
• 配置: ネイティブ

slskd（ファイル共有）

• 機能: IYKYK（If You Know, You Know）。
• 配置: ネイティブ

Snapcast（同期オーディオ）

• 機能: 自作の Sonos 代替。高価なベンダーロックインなしで家中での同期再生を実現。設定は複雑だが非常に安定。
• 配置: ネイティブ

Syncthing（写真バックアップ）

• 機能: Immich の写真を Macbook の外付けドライブへ片方向同期し、ローカルバックアップ戦略を確立。
• 配置: ネイティブ

Transmission Daemon（トラーサー）

• 機能: 説明要なしの torrent クライアント。
• 配置: ネイティブ

Uptime Kuma（監視）

• 機能: サービスの稼働状況可視化。Podman コンテナ状態や HTTP ステータスコード、JSON ペイロード解析などに対応。ダウン時は Gotify に通知。
• 配置: Podman

Vaultwarden（パスワードマネージャー）

• 機能: Bitwarden のオープンソース再実装。KeePass からの移行先として、スマホでのシームレス同期を確保。Bitwarden クライアントとの互換性を維持。
• 配置: Podman

Vikunja（タスク管理）

• 機能: Trello 代替。PostgreSQL 等の重リソース DB を避け、SQLite で動作する軽量な単一バイナリを選択。
• 配置: Podman

Yubal（YouTube Music ダウンローダー UI）

• 機能: yt-dlp や NewPipe の補完ツール。ダウンロードした音楽の命名やタグ付けを自動化。
• 配置: Podman

ノンサービス（断念したもの）

The *arr スタック (Sonarr, Lidarr, Radarr 等)

• 理由: リソース集約的で頻繁な障害に陥りやすい混沌とした挙動は、求める安定とは反対のため。

Collabora Online

• 理由: Google Docs に劣る利便性。共有ドライブがあれば LibreOffice で十分であり、Web ベースのオフィススイートは不要。

Firefly III

• 理由: Actual Budget に比べて複雑なセットアップ（複数コンテナ）が必要で、外国通貨処理もスクリプトで十分だったため。

Owntracks

• 理由: Android アプリが位置情報の報告に失敗した経験から。リソース対効果のバランスが取れない。

Music Assistant

• 理由: すでに Gonic/Snapcast/MPD で良好な環境を構築しており、「すべてを所有したい」必要は感じられず。

E-mail

• 理由: セルフホストメールの管理コストに見合わないリスクがあるため。将来的には Gmail から有料プロバイダーへの移行を予定。

結論

現在、サーバー上で動作しているのはネイティブサービス 17とPodman コンテナ 11で、すべてが

systemd

によって管理されています。

• メモリ使用量: 約 7.5 GB (htop 表示)
• CPU 負荷: 30% ~ 40%

Intel N100 プロセッサ搭載のこの Mini PC は、多くのサービスを動かすのに十分な性能を持っていました。AI クランチによるハードウェアの高騰を受けつつも、シンプルさと効率を重視するセルフホスティング可能なプロジェクトが続くことを願っています。