なぜセルフホスティングをするべきなのか？
(romanzipp.com)- 個人向けサービスのセルフホスティングにより、ビッグテックや政府の監視から距離を置き、プライバシーとデータ主権を確保できる
- カレンダー、連絡先、位置情報などの機微な個人データは、想像以上に多くの情報を露出させるため、GoogleやAppleのような企業に依存せず自分で管理する必要がある
- 技術企業が理由もなくアカウントを凍結したり、プロトコルではなく独自APIを強いる状況では、標準プロトコルベースの自前サーバー運用がデジタル主権を保証する
- CalDAV/CardDAVサーバー、メールサーバー、Home Assistant、RSSリーダー、位置トラッカーなどの実用的なセルフホスティングサービスと具体的なソフトウェアの選択肢を紹介する
- 初期設定は複雑でも、長期的な観点でのデータ統制権とサービスの安定性を確保することが、プライバシー保護と技術的自立にとって重要である
なぜセルフホスティングを選ぶべきなのか
- 最近、自分のHomelab環境を同僚に共有したところ、「そもそもなぜ自分でサーバーを立て、コンテナを構成し、ハードウェアに多額の費用をかけてまで面倒に運用するのか？」と聞かれた
- この質問をきっかけに、セルフホスティングの主な動機と、実際にどのようなサービスをセルフホスティングできるのかを具体的に説明する
プライバシー
- プライバシーは自動的に与えられる権利ではなく、闘って勝ち取るべき権利である
- ビッグテック企業や一部の政府（例: EUのchat control）は、個人生活全体をのぞき見しようとする試みを続けている
- 自分でサービスをホストすれば監視リスクを減らす、あるいはなくすことができるが、そのためには技術的知識が必要になる
- 家族や知人にサービスを提供することで、彼らもデータの独立性を持てるよう支援できる
-
カレンダー & 連絡先
- カレンダーは思っている以上に多くの情報を露出する
- 身元情報だけでなく、定期的な会合、家族、同僚、機密性の高いビジネスミーティングの情報
- 医療予約を通じた健康情報、睡眠や運動のルーティン
- 法的義務、ローンの予定やサブスクリプションのような金融情報
- デモ参加予定から読み取れる政治的信条
- いつ連絡が取れるかを把握され、なりすましに悪用される可能性
- 連絡先データも同様に機微性が高い
- ソーシャルグラフやメタデータ（検索履歴、作成日）から個人情報を推測できる
- 例: 同じ性別で名前しかない連絡先が急に増えたら交際中だと推測される、セラピストの連絡先作成はメンタルヘルス受診を意味する
- ほとんどの人はソーシャルグラフのデータがどこに保存されているかを認識しておらず、実際にはGoogle、Apple、Samsungなどが処理している
- AppleのAdvanced Data Protectionですら、カレンダーと連絡先はエンドツーエンド暗号化されていない
- カレンダーは思っている以上に多くの情報を露出する
-
位置情報
- 数年前、AndroidとGoogle Mapsを使っていたとき、Googleアカウント内に何年分もの詳細な位置履歴があるのを発見した
- 自分で有効化した覚えのない機能が、自動的にすべての移動や訪問先をジオコーディネート付きで記録していた
- 魅力的である一方で恐ろしい体験でもあり、データを自分で管理し、自分だけがアクセスできるようにしたいと思った
- 数年前、AndroidとGoogle Mapsを使っていたとき、Googleアカウント内に何年分もの詳細な位置履歴があるのを発見した
-
その他
- データが追跡されるあらゆる方法と、それに警戒すべき理由を列挙すると、この文章の範囲を超えてしまう
- 目的は、新しい一歩を踏み出す動機づけをすることにある
主権
- デジタル主権とは、データを管理し、そのデータをどう使うかを選び、誰と共有するかを制御することを意味する
-
アカウント凍結の問題
- 技術企業が明確な理由もなくアカウントを凍結する事例は引き続き報告されており、過去にはGoogleで自分も経験した
- 連絡すらできなかったり、AIチャットボットにたらい回しにされたりする巨大テック企業の慈悲に依存したくはない
- 規制当局が技術企業に対し、実際の人間に連絡できる手段を提供するよう要求しないのはなぜなのか疑問に思う
-
プロトコルと標準
- プロトコルとファイル標準を好む
- 「Gmail」APIではなくSMTPとIMAPを使う（古いが現時点では最善であり、新しいJMAPイニシアチブは歓迎している）
- Microsoftのようなビッグテックは、AI-Copilot統合Office 365ソフトウェアの利用を強要し、最近ではOffice 365アカウントのSMTPアクセスを無効化した
- プロトコルとファイル標準を好む
何をセルフホスティングするのか
-
ハードウェア
- enum.coという会社で働いており、デジタル主権を重視する環境にいる
- 3台のミニサーバーで構成された高可用性Kubernetesクラスターを運用中（上司の助けを借りて構築した）
-
カレンダー & 連絡先
- 機微なデータなので、自前のCalDAV/CardDAVサーバーをホスティングしている
- サーバーの選択肢:
- Radicale: Pythonベース、基本的なWeb UI、単一ユーザーのみ対応、Appleデバイスとは互換性がない
- ⭐ おすすめ Baïkal: PHPベース、活発に開発されており、高機能なWeb UI、マルチユーザー対応
- DAViCal: PHPベース、試していない
- Xandikos: Pythonベース、認証を内蔵していない、Web UIなし
- Nextcloud: PHPベース、すでに使っているなら問題ないが重すぎる
- カレンダーや連絡先データを意識するということは、どのアプリがアクセス権を持っているかを見直すことでもある
-
メール
- セルフホストのメールサーバーは長らくタブー視されてきたが、実際にはそこまで難しくない
- StalwartやMailcowのような最近のソリューションにより、個人メールボックスのホスティングが容易になっている（マーケティングメールではなく）
- 自宅でのホスティングは推奨しない（固定IPが必要で、インターネット全体からアクセス可能である必要がある）
- 設定手順:
- 信頼できるホスティング事業者を選ぶ
- クリーンなIPアドレスを確保する（メールブラックリストを確認して繰り返す）
- サーバー設定後、受信できるか、すべてのプロトコルが正しく構成されているか確認する
- internet.nl のオンラインテストツールで検証する
- Google、Microsoft、Yahoo宛てにメールを送ってスパム扱いされないか確認する
- DNS、DMARC、SPF、TLSなどを繰り返し点検する
- 今後、詳細なブログ記事を書く予定
-
スマートホーム
- 数年前からHome Assistantインスタンスのホスティングを始めた。当時はApple Homekitで十分だったが、実験的に始めた
- その後、多くのスマートホーム企業が倒産したり、クラウドサービスを終了したり、価格を引き上げたり、無料サービスを有料化したりした
- 数週間前、Philips Hueがユーザーにアカウント作成を強制するという話を聞いて、Home Assistantの価値が際立った
- すでにお金を払った照明の全機能を使うにはアカウントが必要になる
- スマートホーム機器の外向きネットワーク通信を遮断するファイアウォールルールを、以前から常に設定してきた
- ローカルネットワーク内でも、Philips Hueアプリ専用機能（キャンドル風アニメーションなど）は使えないようだ
- この機能をエミュレートするコミュニティプラグインがあることを願っている
- ローカルでしか使わない機器のためにオンラインアカウントを作ることは絶対にしない
- 現在はエネルギー使用量の追跡に夢中で、マシンビジョンでガスメーターの使用量を追跡する Raspberry Pi + カメラ装置を開発する予定だ
-
RSSアグリゲーター
- RSS経由で多くのニュースサイトやブログを購読しており、RSS自体がすでに分散的で主権的である
- したがってRSSアグリゲーターのセルフホスティングは任意であり、最後の段階だ
- iPhoneとMacではNetNewsWireを使っている
- 最高のRSSリーダーであり、オープンソースで、素晴らしい人たちに支えられている
- FreshRSSとのネイティブ統合を提供する
- FreshRSSはフィードアグリゲーターとして、フィルタリングなどより多くの機能を提供する
- RSSフィードを標準提供していないソースも購読できる
-
位置トラッカー
- dawarichインスタンスをデプロイした（ドイツ語で「自分はそこにいた」という意味）
- 地理位置データを収集して閲覧するサーバー
- 現在位置をサーバーへ送信できる、さまざまなモバイルアプリを選べる
- 利用可能なアプリ:
- 公式 dawarich アプリ: iOSのノッチに常時ナビゲーションアイコンが表示される
- Overland: バッテリー消費が激しい
- ⭐ Owntracks: iOSで最もよく動作するが、アプリ設定が非常にわかりにくい
- PhoneTrack
- dawarichインスタンスをデプロイした（ドイツ語で「自分はそこにいた」という意味）
アイデア & 展望
- 最近ホームラボを再構成し、単一の大型サーバーから3ノードKubernetesクラスターへ移行した
- ホスティングできるアプリケーションの種類において、はるかに高い柔軟性を得られた
- 試してみたいアプリやツールの一覧:
- EteSync: エンドツーエンド暗号化された CalDAV & CardDAV
- AnyType: 自前のAnyTypeサーバーインスタンスをホスティング
- Immich または ente: iCloud写真からセルフホスティングへ移行
- Passbolt: パスワードマネージャー（Bitwardenは好まない）
- BirdNET: マイクによる屋外の鳥類種モニタリング
- penpot: Figmaに似ているが、無料かつオープンソース
- Habitica: 習慣トラッカー
- vert: ファイル変換ツール
- InvoiceShelf: 請求書マネージャー
- selfh.stは、セルフホスト可能なアプリケーションを探せる優れたリソース
1件のコメント
Hacker Newsの意見
個人向けサービスを自分でセルフホスティングするだけでなく、ソフトウェア企業やSaaSの中小企業も、より直接的にホスティングする方法を検討してみる価値があると言いたい
クラウドベンダーは複雑性やスケールを理由に自分たちが不可欠だと語るが、実際には大半のソフトウェアプロジェクトや事業にはそこまでの必要性はない
たとえば NextJS のデプロイのためにわざわざ Vercel や Netlify に依存する必要はなく、Ubuntu が入った VPS で Nginx や Caddy（私はこれが好き）を動かせばよい
ほぼ 90% 以上のプロジェクトは、次のような方法で十分に自前ホスティングできる
セキュアな VPS と必須のセキュリティ制御の適用（root ログイン無効化、SSH キーによるログインなど）
Caddy/Nginx のようなリバースプロキシを設定すれば静的ファイルや Web サイトを配信でき、1 日に数百万リクエストでもない限り CDN も不要
Supervisor や systemd でバックエンド/API を実行
同じリバースプロキシでバックエンドや他サービスもプロキシ可能
自分で mysql/postgres データベースを動かし、セキュリティ設定を適用
バックアップスクリプト/cron ですべてバックアップでき、定期的なテストも必要
DOS/DDOS 対策をしたいなら Cloudflare レイヤーを追加できる
最終的には Cloudflare/DNS→Reverse Proxy(Caddy/Nginx)→アプリ という構成になる
デプロイはたいてい git pull で十分で、必要なら追加ビルドも可能
Docker やコンテナも必須ではなく、小規模〜中規模プロジェクトならなくても構わない
難しそうに思えるかもしれないが、実際には思うほど難しくなく、大半のプロジェクトは大規模 Web スケールを必要としない
私にとって最も不安なのは、OS 全体（カーネルやユーザーランドを含む）を管理することで生じるセキュリティリスク
ファイアウォールを適切に設定できているか、最新の CVE に迅速に対応できているかなどが心配
だからむしろ GitHub Actions でワークフローを構築し、コンテナイメージをビルドしてプライベートレジストリに push し、k8s の設定でそのイメージをサービスへデプロイするほうが安定的だと感じる
VM に直接載せるのと同じくらい簡単で、こうすれば自分のアプリとそのインターフェースだけに責任を持てばよい
私が canine.sh を作った理由は、まさに上で述べられた設定作業をすべてワンクリックにしたかったから
以前に小さな SaaS を共同創業したとき、クラウド利用料が年間 50 万ドルを超えていた
本番運用では sentry が必須だとすぐに気づき、サーバーログを逐一あさるよりクラウド版 sentry に月 40 ドルほど
データ監視のために datadog も必要で月 300 ドル
顧客プレゼン用ダッシュボードのための Looker/Tableau/Omni のような BI ツールは年間 2 万ドル
データウェアハウスとレプリケーションは年間 15 万ドル
こうした外部サービスの費用が積み上がり、最終的には外部サービスをすべて自分のインフラで維持・運用するのが最善だという結論に至った
例として Cloud Sentry→Self Hosted Sentry、Datadog→Prometheus/Grafana、Looker→Metabase、Snowflake→Clickhouse、ETL→Airbyte など
多くの企業が最終的に Kubernetes を選ぶ理由はここにある
インディーハッカーにはなぜ Kubernetes の複雑さが必要なのか理解しにくいかもしれないが、すべてを単一の VPS に載せられない理由がここにある
「大半のプロジェクトは Web スケールを必要としない」という点に同意する
いまの主要クラウドプラットフォームのマーケティングは、実質的に YAGNI（You Ain't Gonna Need It）がインフラにも当てはまるようなものだと感じる
2000 年代初頭からシステム管理者として働いてきたが、みんなが自分のサービスを直接ホストする流れを、まるで何かの革新のように扱うのを見ると面白い
昔は Docker が出る前からすでに LXC や BSD Jails などでコードを隔離して動かしていたし、これは DevOps 以前からある長い伝統でもある
今の開発者たちがこうしたものを新しく発見しているのを見るのも興味深い
最後に、グレイビアード（ベテラン）システム管理者と協業したり、コーヒーでも飲みながら助けを借りるとよい
昔ながらの方法でインフラを直接管理することを喜んでやる人は多く、実践的なノウハウもたくさん持っている
セルフホスティングのもう一つの利点は、クラウドサービスと違って、システム技術や知識の移植性が高いこと
systemd、ufw、ssh の使い方を身につけておけば、他のシステムにもすぐ適用できる
むしろ Docker やコンテナのレイヤーごとのビルド、さまざまなテクニックを覚えるためにかかる時間とコストのほうが、一般的な Debian Web サーバー管理より大きいと思う
全体として同意するし、意見を共有してくれてありがとう
1 点だけ異なるのは「CDN は規模が大きくなって初めて必要になる」という部分
CDN は単にオリジンへのリクエストを分散するためだけでなく、ユーザー体験のレイテンシを下げることが主目的だと思う
体感速度は実際きわめて重要な機能であり、先回りの最適化には注意すべきだが、少なくとも静的アセットをユーザーに近いエッジから配信するのは、もう 10 年前から基本仕様レベルだ
素晴らしい話題だ。自分の経験をもとに視点を共有できる
ホームラボを自分で運用していて最大の利点は、コスト削減やデータプライバシーそのものではなく、実際に深い実務知識を得られること
Docker、ネットワーキング、Linux 管理について文章で学ぶのと、家族が使うサービスを自分で運用し、DNS が止まったり Docker コンテナの再起動に失敗したりして自分で解決しなければならない状況で学ぶのとでは、得られる学びの深さがまったく違う
ただし別の現実もある
最初は面白いプロジェクトでも、パスワードマネージャーやファイル同期のような重要サービスまで自分でホストし始めると、24/7 のオンコール担当者になるということ
バックアップ、セキュリティパッチ、稼働率のすべてが自分の責任になり、その時点で単なる趣味ではなく「仕事」になる
結局のところセルフホスティングは、データのコントロール権と大きな達成感を得られる一方で、SaaS の費用を自分の時間と精神的負担、つまり IT 担当者としての役割に置き換えるトレードオフだ
ただ HN ユーザーなら十分やってみる価値があると思う
会社（enum.co）ではデジタル主権を重視して働けて幸運だと書いていたが、実際に info.addr.tools でメールサーバーを確認すると、MX は smtp.google.com で、TXT レコードにも Google 関連の属性が多かった
これは単なる「スローガン」ではなく、DNS 上の現実だ
デジタル主権を重視しながら Google のメールサービスに依存しているのは矛盾している
https://info.addr.tools/enum.co
enum を擁護するなら、彼らが提供しているのは k8、S3 互換ストレージ、DevOps の領域だ
もしセルフホスティングやメール主権を売りにしていて gmail を使っていたら話はまったく別だが
完全に 100% 独立というわけではなく、実際 OP も「セルフホストのメールサーバーは大きな禁句のように扱われるが、思うほど恐れる必要はない」と述べている
みんなこの問題を認識していて、改善の余地も残っている
こんにちは、enum の創業者です
その指摘はもっともで、良いポイントです
正直に言うと、社内用メールに Google Workspace を使っていたのは、初期段階でコア製品開発に集中するための実務的な選択でした
スタートアップでは非常によくある選択で、今後数週間のうちに移行する予定です
ただし、顧客向けプラットフォームとすべてのデータは常に 100% 主権を守っています
インフラは完全にビッグテックから独立しています
問題を指摘してくれてありがとう
メールだけはセルフホスティングの例外だと考えている
私はあらゆるサービスをセルフホストしているが、メールだけは 3rd party に任せている
DNS に Google 関連レコードがあることを強く指摘した点に感心した
すごいと思う
TXT の
google-site-verification=...の部分は、別に「悪」ではなく、Google がメール送信時にスパム扱いしないようにするための妥協策だメールをセルフホスティングする場合、デジタル主権がプライバシーより重要なら
私は gmail にカスタムドメインを使い、自分のメールサーバーをセルフホストして mbsync で gmail からメールを継続的にダウンロードしている
保存と閲覧は自分のサーバーで行うが、送信は引き続き gmail を利用する
Google が私のアカウントアクセスを遮断してもメール自体は手元にあり、プロバイダーを変えるときは DNS を変更すればよい
送信メールの到達性の問題もない
SPF、DMARC などの DNS 設定を行って 6 年前にメールのセルフホスティングを始めた
問題は 1、2 回しかなく、たいていはサービス側やランダムな障害、IP 変更、バックアップ自動化など、メールサーバー以外のことのほうが厄介だった
むしろメールサーバーは勝手にうまく動いてくれる
なぜメール送信までセルフホスティングしないのかといえば
おそらくメール配信の到達性（Deliverability）の問題では？
メールの完全な主権はカスタムドメインにかかっている
これを安全に持っていれば、いつでも複数のプロバイダーから選べて、移行も自由になる
セルフホスティングは本当に素晴らしい
1 年前にソフトウェアエンジニアから SaaS 創業を始めて以来、Coolify と Hetzner の 20 ドルサーバーで Postgres、旧バージョンの Minio、Nuxt、NextJs、Umami analytics、Open WebUI、静的サイトなどを自分でホストしている
最初は学習が必要だったが、セットアップが終わってからは新しいサービスを立ち上げるのがプラグアンドプレイのように簡単になった
サーバーリソースも 1/4 も使っていない（ユーザーが少ないので笑）
https://coolify.io/docs/
IT 専門職として働いているが、自宅でのセルフホスティングや NAS 構築だけはずっと先延ばしにしていて、結局 Ugreen NAS の 4 ベイモデルを買ってすぐに TrueNAS CE を入れた
ChatGPT に自分専用の docker-compose ファイルなどのコンテキストまで渡しながらセットアップを進めた
Docker やネットワークについては学生時代に少し触れた程度で、ほとんど知識がなかったが
現在は
という構成で運用している
セルフホスティングは良いが、問題はバックアップとアップグレードだ
いろいろなリソースを自分でホストしているが、重要データや他人が依存するものは自分ではホストしていない
アプリの復旧やアップグレードが簡単でなければ依存しないようにしている
実際、セルフホストアプリでバックアップ/復元が 1〜2 行で済むものはあまりない
参考までに、Tailscale と Pangolin は自宅で安全にセルフホストするうえで神の贈り物のような存在だ
期待しているバックアップソリューションが何なのか気になる
すべてのセルフホストアプリは Docker で動かしているので、コンテナのボリュームフォルダと docker-compose.yml だけバックアップすればよい
復元はフォルダを戻して
docker compose upすれば終わりアプリごとに別個のバックアップ実装は不要だと思うし、それは開発者の時間の無駄だ
Tailscale の代わりに netbird のセルフホスティングを強く勧める
非常に活発に開発されていて、UI も素晴らしい
https://github.com/netbirdio/netbird
Pangolin が何なのか気になる
検索すると動物しか出てこない
私のセルフホスティングスタック
最新版への更新やセキュリティパッチの案内が不十分だったり、すべてのバージョンを順番に経由しないといけない場合もある
「セルフホスティング」を家庭内サーバーだけに限定しすぎると、いつまでもニッチなままになってしまう
オープンソースの買い切りアプリ、昔ながらの Windows PC アプリケーション、簡単に移行できるクラウドアプリなど、SaaS ではないあらゆる形を奨励すべきだ
どんな形であれロックインを避け、ユーザーがコントロール権を得ることこそ、本当のセルフホスティングの目標だと思う
それでも、言葉の意味がぼやけてはいけない
標準プロトコルで移行可能なクラウドアプリであっても、結局自分の所有・管理するサーバーでなければ、運営者の都合でデータポリシーや収集方針が変わる可能性がある
予期せずデータが収集されたり、サービス終了前にデータ移行できるかどうか確信できなかったりする
Windows のインストール型ソフトウェアもセルフホスティングの範疇に入ることはある
実際、最初は Windows 実行ファイルや Docker から始めて、徐々に発展していくこともある
少なくとも、自分が root 権限を持ったまま他人のデータセンター（コロケーションなど）でサーバーを動かすのもセルフホスティングに含まれると思う
20 年前なら、おじいさんたちですら limewire.com から setup.exe をダウンロードして next->next->next と押すだけで、完璧なファイルサーバーとクライアントをインストールできた
2007 年には世界のコンピュータの 1/3 が limewire を使っていた
なのに今では、ごく基本的なセルフホスティングソフトウェアでさえ、実質的にプロ級エンジニアでないと導入できない
SSH、Docker、Tailscale、TLS 証明書など複雑な管理が必要で、バックアップや数多くのその他自動化まで求められる……
なぜ
apt-get installで終わる「セルフホスティング」ソフトウェアが少ないのかと思うだから誰も自分でホストしないのだ
https://en.wikipedia.org/wiki/LimeWire
一部のソフトウェアは
apt-get installで導入が終わることもあるが、インターネットにサービスを公開するにはドメイン名や HTTPS の設定から必要になるLimewire や BitTorrent のようなクライアントは、中央サーバー（トラッカーなど）があるおかげでドメインなしでも使えたのだ
多くの人は limewire のようなインストーラーをセルフホスティングだとは考えないだろう
単なるローカルプログラムのインストールだ
Ubuntu では snap でサーバーサイドアプリを簡単にインストールできるようにしようとしていたが、コミュニティの強い反発で失敗した
snap にも欠点はあるが、サーバーアプリの配布を簡単にするためのフォーマットだ
例として今でも nextcloud は snap でインストールできる
完璧ではないという理由で、現実的に「十分良い」ものまで退けてしまったわけだ
Limewire はクライアントにすぎず、サーバーではない
きちんとアップロードさせるにはファイアウォールやポートフォワーディングが必要で、UPnP の許可（推奨しない）も必要になる
セルフホスティングのサーバーはまったく別の領域だ
初心者でも自動でできたはずの世界から、悪意あるハッカーのせいで設定と運用の難度が上がってしまった
専門家であっても、プロの侵入テスターや国家級ハッカーに対しては無防備だ
最近のソフトウェア開発そのものが複雑になりすぎたと思う
まるで不要な問題をわざわざ作って職を維持する官僚主義のようだ
大半の人はセルフホスティングすら必要なく、ただ自分のコンピュータで動かして、ときどきローカルネットワークからアクセスできれば十分だ
だが収益モデルがなく、開発者は特殊なレイヤーや不必要に複雑なアーキテクチャに執着する
結果としてサーバーソフトウェアや WebView ベースのもの、データとローカル環境の乖離、管理すべき機器ばかりが増える
大半のコンピュータは遊んでいるのに、管理レイヤーだけが積み重なっていく
ノート PC の流れもこの混乱の一部だと思う
良い Mac 向けローカルアプリも消え、クラウドのサブスクリプション型ばかりになった
オープンソースでさえ結局は Docker イメージ、複雑な設定、山ほどの gotcha だらけだ
もしシンプルにインストール・管理できたなら、有料でも使う価値はあるだろうが
今はどれだけ時間がかかるか分からないので、みんな結局ビッグテックに任せてしまう
Web 技術はインタラクティブな文書には向いているが、それ以外の用途では依然として使い勝手に大きな難しさがある