セルフホスティングと技術的独立：自分で作る喜び
(ssp.sh)- 技術的独立とセルフホスティングの楽しさと重要性に関する体験を強調
- ドメイン所有とブログの自立運営が、長期的にキャリアと自己成長に大きな利点をもたらすと説明
- オープンなオープンソース生態系で自分の知識やコードを共有することで得られる、コミュニティと学びの大切さに言及
- Homelab構築とさまざまなセルフホスト可能なオープンソースツールを紹介し、サブスクリプション型サービスの限界から離れて実際に使ってみることで感じられる自由を強調
- Markdownベースのコンテンツ共有とオープンソース精神が、ソフトウェア生態系および個人の能力強化に与える前向きな影響を強調
はじめに：技術的独立と自前構築の価値
- PewDiePieがArch Linuxのインストールやオープンソースベースの製品を自分で作る動画を見て、著者は自分自身のものを作るセルフホスティングと技術的独立の重要性をあらためて考えるようになった
- 自分で積み上げたドメインやブログ、直接管理するサービスは、長期的には蓄積される資産となり、これは単なるプラットフォーム移行以上の意味を持つ
ドメイン所有とブログの自前運営の力
- 新しく執筆を始める人や転職・就職を考えている人に、まず自分だけのドメイン購入とブログ運営を勧めている
- プラットフォームを移るたびに大切なコンテンツやドメインを失うことが繰り返されるため、自分でドメインを所有し、同じアドレスで継続してコンテンツを蓄積することが重要
- 時間とともに積み上がった被リンクや過去の記事、投じた努力は、長期的な信頼性へとつながる
著者のセルフホスティング経験と学び
- 著者はブログ、セカンドブレイン、本、購読リストなどさまざまなサービスを自分でホスティングしており、GoHugo、Listmonk、Memberstackなどを活用している
- Homelab環境の構築、SSH、バックアップ、写真管理、Gitea、プロキシ/SSL証明書の自動化などを通じて、段階的に技術力を高めてきた
- 最初は難しく感じられても、その過程で得られる学びと達成感こそが最大の報酬
オープンソースとコミュニティの価値
- オープンソースソフトウェアの活用と貢献が技術的独立を可能にし、自分の知識やツールもGitHubで公開している
- オープンソースでは多様なライセンスを通じて誰もが自由に使え、コミュニティからのフィードバックや協業の機会も増える
- 著者はオープンソースのBIツールを使った経験を通じてオープンソース生態系に魅力を感じ始め、現在ではオンライン活動の大半やデータエンジニアリングに関する文章もこれを基盤としている
LinuxとLinus Torvalds
- Linuxは世界中のデジタル機器の中核であり、Linus Torvaldsがこれを商業化しなかったおかげで世界的に広く普及することができた
- Torvaldsはgitも開発しており、これは世界中のすべてのソフトウェア開発者にとって必須のツールになった
- オープンソースとして自分の仕事を公開すれば、他者の学習やフィードバック、貢献、つながりの機会が生まれ、個人の成長だけでなくコミュニティの発展にも寄与する
感謝しているオープンソースツールたち
- 著者がよく活用し、感謝しているいくつかのオープンソースツールがある
- Quartz: オープンソースのObsidian Publish代替
- GoatCounter: 匿名化されたサイトトラフィック分析ツール
- Listmonk: オープンソースのニュースレターリストシステム
- listmonk-rss: ブログ執筆時に自動でメールを送信
- Homelabで推奨されるオープンソースソフトウェアの例:
- Paperless: 文書のデジタル化と管理
- PhotoPrism: AIベースのセルフホスト写真管理
- Pi-hole: ネットワーク全体の広告ブロック
- Nginx Proxy Manager: ドメインルーティングとSSL自動化
- Audiobookshelf: オーディオブック/ポッドキャストサーバー
- Calibre: 電子書籍管理
- Syncthing: 分散ファイル同期
- Gitea: 軽量セルフホストGitサービス
安価な機材でも十分な実験
- 高価な最新サーバーでなくても、中古のクライアントサーバーと優れたOSがあれば十分にHomelabを構築できる
- 自分で構築・運用する過程で学ぶ楽しさと独立性を重視している
技術的独立性とプラットフォームリスク
- 自分で構築とホスティングを行うことで、GoogleやAppleなど大手サービスの機能変更やサービス終了といったリスクから自由になれる
- 自分だけの環境や特徴を自ら設計・修正できる自由を得ることこそが、Tech Independenceの真の利点
まとめとMarkdownの重要性
-
オープンソース、自作、体験共有の喜びを強調し、あらゆるソリューションとコンテンツ制作の基盤がMarkdownで統一されている点も際立たせている
-
Markdownはさまざまなプラットフォーム間の互換性を保証し、オープンソース/知識共有文化の標準ツールとなっている
-
さらに多くのデータエンジニアリングブログ、セカンドブレインのノート、公開執筆中の本などは、いずれもssp.shおよびGitHubで確認できる
-
読者との体験共有や議論はいつでも歓迎している
1件のコメント
Hacker Newsの意見
自己宣伝で少し申し訳ないけれど、セルフホスティングでは必ずしも新しくハードウェアを買う必要はないという現実を伝えたい。数年たってWindowsでは遅すぎて使えなくなった古いノートPCでも、Linuxサーバーとしてなら十分実用的な性能を発揮する。家や友人の周りで使われずに転がっている古いノートPCが見つかる可能性は高く、私も2011年製のi3ノートPCを2人で問題なく使っていて、2025年になった今でもアップグレードの必要はなさそう。ノートPCは待機時の電力効率も良いので、長期的に見ればデスクトップよりさらに合理的な選択だと思う。セルフホスティング初心者には、ノートPCはすばらしい最初のサーバー候補だと思う。（ちなみにノートPCにはUPSが内蔵されていないので、24時間つなぎっぱなしで使うならバッテリーを外すことを強く勧める）
古いハードウェアの再利用に関する記事
実はこの書き込み自体も、13年物のAcerノートPCでLinux Mint XFCEを使って書いている。古い機器を捨てるのがいつももったいなくて、新しいノートPCを買った後もリビングのTVにHDMIでつなぎ、25ドルのLogitech K400+ワイヤレスキーボード/トラックパッドを組み合わせて使っている。Webブラウジング、YouTube、Netflixはどれも問題なく使え、たまに作業するときはVS CodeやThunderbirdを開くし、Steamのインディーゲームさえゲームパッドで問題なく動く。FrameworkのノートPCがうちの国でも買えるようになれば、こういう再利用環境はもっと広がるはずなのに、残念ながら私の国にはまだ配送されていない
うちの地域（スウェーデンの250世帯のアパート団地）では、人々が電子ゴミ置き場に古いコンピューターを捨てるのが日常茶飯事。私はまるでMad Maxの登場人物みたいに、犬の散歩のたびに毎日何度も物色している。複数台から部品を組み合わせてdebianを入れ、dockerコンテナを動かしていろいろな用途に使っている。こうして作ったFrankensteinサーバーを、親やいとこ、友人にあげたこともある。こんなに使える機器が捨てられているのかと驚かされる。パスワードのかかっていないノートPCも珍しくなく、Windowsにログインすると家族写真が山ほど入っている。たまにはロック解除された5年くらい前のiPhoneまで見つかる。本当に妙な世界だとしか思えない
家には2012年式のMac-Miniも1台ある。もらい物で、Macに乗り換えるつもりはなかったが、強力ではないにせよ性能は悪くない。去年のクリスマスに起動してみたら、標準OSのままでもひどく遅く、macOSを更新したらまともに使えなくなった。YouTubeを見ながらSSDに換装し、Debianを入れてCasaOS（WebベースのホームサーバーOS/UI）を載せてからは、Wireguardで外から接続してNavidromeで音楽をストリーミングする環境を作った。Dockerの概念はまだよく分かっていないが、PATHマッピングなどいろいろ学んでいる最中
中古市場で買い物することに抵抗がないなら、私は今、Threadripper第3世代 32コア/64スレッド、256GB ram、2x10G、2x2.5G、専用IPMI管理用1Gインターフェース、64 PCIe gen 4 laneを備えたProxmoxノードを2,000ユーロ未満で構築中
RAID6/RAIDZ2未満の構成には、かなり大きなデータ損失リスクがある。ほとんどのノートPCはSATA/M.2ポートが足りず、そもそもパリティ構成が組めないので、RAIDレベルの耐障害性が欲しいなら結局は新しいハードウェアが必要になる。バックアップは最低でも2つの物理的な場所に分散するという原則を守るなら、二重に備えるのが理想的
セルフホスティングしたい気持ちも分かるけれど、やりたくない気持ちも十分理解できる。セルフホスティングは面倒で、dockerの更新もしなければならないし、何か壊れたら自分で直すしかなく、たとえ動いていても滑らかというより少しぎこちない感じがすることが多い。今ちゃんと動いていて自分の時間を節約してくれるself hostedツールの一覧はごくわずかで（最初はfirefly）、セットアップ中に壊れて結局あきらめたケースも多かった。最近はプライバシーを尊重して価格も妥当な会社の製品なら、普通にお金を払って使っている
原因はDockerだと思う。Dockerはストレージやネットワークなどに不要な間接層を追加するし、セキュリティなどの更新を入れるにはコンテナを再ビルドする必要があるか、誰かがやってくれるのを待たなければならず面倒。可能なら、upstreamのOSパッケージや単一バイナリ（Goベースのプロジェクトでよくある）として配布できるサービスにこだわったほうが、長期的には運用しやすい
なぜDockerを必ず更新しなければならないのか疑問。私の場合、Docker自体は1年以上更新せずに運用している。Dockerイメージのアップグレードも月に15分ほどで終わる。それに、プライバシーを尊重する企業はごくわずかで、年を重ねても独自の方針を守り続けてくれると信じるのは難しいのが現実
プライバシーを尊重して価格も良い会社を見つけること自体が極めて難しい
どのプロジェクトで問題が起きたのか気になる。Docker Composeまで提供されているレベルなら、たいていは問題なく動くという経験をしてきた。それに、ほぼすべての会社はいずれ信頼を裏切ると思っている。だから、そんな機会すら与えないほうがいい。私はHome Assistantをセルフホスティングしているが、この会社はユーザー不利な運営にならないよう法的な仕組みまで整えている点がユニーク
必要なものの大半をセルフホスティングしているが、最近ほんとうの危機を感じたのは、インターネットが断続的に切れたときだった。自分にこんな問いを投げかけることになった
結論として、もっと多くの文書をアーカイブする必要があること、そしてNixOSはキャッシュサーバーを自前で持たない限りオフラインではほとんど使い物にならないことが分かった。そこは非常に不便。結果として、インターネットがなくても自分に必要なものの大半をセルフホスティングでき、その環境のほうがむしろ生産性がかなり上がることを実感した
devdocsを自分でホストし、Linux用のzeal（オフライン文書ビューア）を使ってみたら、オフライン文書の問題はかなり解決した。devdocs github
zealdocs公式ページ
ダウンタイムがあるたびに、自分のシステムの弱点を新しい機会として捉えている。どうしようもなくupstream側の問題で避けられないなら仕方ないが、対策できる状況ならコストと確率のバランスを取ったシナリオを考え、その作業自体が楽しいと感じるタイプ
私はこのオフライン志向を極限まで突き詰めたことがある。インターネットが完全に断たれていた時期こそ、作業生産性が最も高かった。Webサイト全体をwgetで再帰的に保存するbash aliasを持っていて、yt-dlpで欲しい動画を保存し、KiwixでWikipedia全体のオフラインコピーを持ち、メールもローカル保存でオフライン作成とキューイング送信に対応し、SingleFile拡張で個別ページ保存も効率的、Zealもオープンソースの文書ブラウザとして勧められるツール
「NixOSは自前のキャッシュがないとオフラインで使えない」という問題には共感する。パッケージマネージャを使うソフトウェアなら、キャッシュやリポジトリのバックアップは必須だ。依存関係ツリーの末端にいるすべての個人がそれぞれ役割を果たし続けないとシステム全体が正常に動かないという点は、最近のソフトウェア開発で最も不安な部分のひとつ。エンドユーザー向けソフトウェアでは、すべての依存関係を含んだ個別パッケージのほうがはるかに良いという立場。どうせ実際にディスクへ保存されるのはそういう形なのだから
Kiwix（Wikipediaオフラインソリューション）と、さまざまなjellyfinセットアップは強力なオフライン資源だ。ただし、NixOSやGentooのようなディストリビューションは継続的なインターネット接続を要求しがち。パッケージ全体のミラーリングは現実的にはほぼ不可能
「まずドメインを買え」という助言についてだが、実際にはドメインは借りるものであって、本当に買えるわけではない。一度でも支払いを逃せばすぐ追い出される仕組みで、怖さすら感じる。こうしたオンライン上のアイデンティティのはかなさは悲しいほど
「ドメインは借りるだけだ」という部分については、ICANNが承認するルートゾーン/レジストリだけを使うならその通りだが、私は実験的に自分だけのレジストリを作り、他人と共有しないカスタムルートゾーンを何年も自分で運用している。カスタムTLDは、ドメイン名に世界中のあらゆる製品/サービス分類体系を持ち込む役割も試してみたが、ICANN TLDの曖昧さや不適切さを身をもって実感した
これは一種の技術的限界だ。私のすべての機器（つまりドメイン名の利用者）が、特定の公開鍵で署名されたものを「XorNot.com」と認めるよう設定すれば、システムは置き換えられる。技術的にもう少し支援があれば、「信頼できる鍵と名前の一覧」で今の構造全体を置き換えることもできると思う
セルフホスティング向けツールのエコシステムが大きく進歩している時代だと感じる。最初はホスト型コンポーネントから始めて、各要素をひとつずつセルフホストに置き換えられる。私のブログも家のサーバーでセルフホスティングしている。
手前ではCloudflare Tunnelを使っているが、以前はnginx+letsencrypt+public_ipも試したし、データ保存先もCloudflare R2、S3、あるいはローカルNASに柔軟に置き換えられる（FUSEを挟めばアクセス方法も同じ）。
一方で、どうしても借りなければならない資源はドメイン（買っているように見えても実際は賃借）とインターネット接続くらいで、残りの要素はほとんど任意で選べる時代になった。もちろんサービスを止めれば不便にはなるが、基本動作は維持できる。
昔に比べて本当にものすごく簡単になった。90年代から2000年代初頭には想像もできなかったツール環境。
ただし、メールのスパム対策条件だけは非常に厳しくなったのが難点。8年前まではメールも自分で運用していたが、今はG Suiteを使っている
私は「セルフホストするかどうか」ではなく、「セルフホストできる能力」そのものが重要だと思う。技術が足りなかったり、お金を払いたいときには他人に任せられるという見方のほうが包摂的だ。「金を払えばいい」と考える人たちこそ、長期的には実際に最大のリスクを負う。最近のビジネスは、長期的な技術依存を人質に取る形で計画的に顧客を囲い込む。FOSSに関心がなくても、ベンダー移行の可能性は本当に重要な問題だ。ロックインされれば、いつでも不合理な扱いを受けかねない。そういう構造だけで物事を考えている会社も多い
Zulipは、オープンソース、自前ホスティング、クラウドサービス、相互移行のすべてを支えるサービスとして高く評価している
開発者があふれ、AIによって家庭でも生成できるコードの品質がばらつきながらも増えていく時代なら、セルフホスティングは確実にトレンドになり得る
Linuxの基礎さえ学べば、たとえ必需でなくても、「自分のサービスを自分で動かしている」という快感と達成感があって、セルフホスティングに魅力を感じる人は多い。
さらに大きいのは、完全に依存しているプラットフォームから理由もなく追い出されるという、現実的なリスクを取り除けること。Gmailアカウントまで失えば、「一般人」はアカウント内のオンライン上の身元情報、パスワードリセット、さらにはアプリへのログインまで全部止められて困る可能性がある。Hacker Newsにも、Gmailアカウントを失うと人生が厄介になる人はきっといるはず。だから少なくともメールアイデンティティだけは自分の所有であるべきだという立場。この原則はWebホスティング、AWS、Spotify、Netflixなどあらゆるオンラインサービスにも繰り返し適用すべきで、「別のクラウドホストに置き換える」程度では問題は解決しない。
メールサーバーの設置方法は情報も多く簡単だが、実際の運用プロセス（特に互換性問題や障害対応など）に関する資料が乏しいのが個人的に残念。たとえば、Googleが自分のサーバーをブラックリストに入れたら誰に連絡すべきか、エラーメッセージに対応手順があるのかなど、実運用では助けを得られる場所が少ない。グローバルIPブロックのような外部の不合理な要因にどう対処するかという説明書が必要。DKIMやDNSのようなプロトコルの話ではなく、実際のサービス運用で他事業者にどう対処するかのガイドラインが必要
ドメインは自分で所有して、好きなメールプロバイダーに紐付ければいい。問題が起きてもすぐ別のところへ移せる。ドメイン自体は安いし、メール事業者固有のメールアドレスは絶対に使わないのが正解。
そしてこの原則は、自分でメールサーバーを運用する場合でも、商用サービスを使う場合でも同じ。両者は別の問題
リスクが実際に大きく、危険が明確なのはその通りだが、それが本当に大多数に起こるリスクなのかは疑問。初期のGmail利用者の多くがそれを選んだ理由は、それ以前の代替手段の品質低下が大きかったからだ。ISPメールや大学・職場のメールなどは、必要になればいつでもアカウントが消える構造だった。self-hostingはその問題を「部分的に」解決できるが、セキュリティを維持する能力がなければ、自分で管理するメールサーバーでも完全なコントロールは得られない。ドメイン更新など気を配ることも多く、結局注意を払わなければここでもアカウントは失われる。私はGmailなど少数の大手事業者がなぜこれほど人気なのか理解できるほうで、多くの人にとっては短期でも中期でも、まだこちらのほうが良い選択だという現実がある
自宅でself-hostingするなら、HDDが故障する確率とGmailアカウントを失う確率のどちらが大きなリスクか自問する。自前ホスティングを始めると、機材を置く場所、バックアップ計画、更新管理まで急に考えることが増え、更新やバックアップの最中の停電まで考えると結局UPSも導入しなければならない。しかも私の場合、UPSが不良品でNASのハードドライブまで壊れた経験がある。結局やることが多すぎて、日常に集中する時間が減ってしまう
self-hostingはむしろ重大なリスクを招くこともあるという立場。ローカルのprivate keyやメインのメールドメインを失えば復旧できない。2FAやアカウント復旧は外部サービスのほうがずっと便利だ。self-hosting自体に反対するわけではないが、大半の人にとってはアカウント復旧の可能性を確保するほうがはるかに安全だと思う
Arch Linuxの公式インストーラーが登場して以降、もはや難しいと言うのは無理があると思う。今でもコマンドラインから入るが、昔のように複雑なパーティションブロック計算に頭を悩ませていた時代と比べれば、はるかに簡単になった
自宅ではKubernetes 4ノードのpiクラスタとIntel N150ミニPCをPortainerで一緒に管理している。
オープンソースの運用ツールのうち、以下のツールのおかげで作業生産性が大きく変わったと感じている（すべてコンテナ環境で動作）