SSD Nodes Learn Hosting plans →
ガイド Matt Connor著者 Matt Connor

2026年にセルフホストしたいアプリ25選

2026年にVPSで運用する価値がある25個を用途別に紹介します。代替サービス、実運用のRAM・ディスク容量、導入前に知るべき注意点をまとめました。

構築するもの

1つのアプリではなく、候補一覧です。このサイトにある他のすべての記事の中核として、2026年に自分のVPSで実際に運用する価値がある25個のアプリケーションを、用途別にまとめます。それぞれについて、置き換えられるサービス、実際的なRAMとディスク容量の目安、そして対策を省いた場合に問題になる唯一の点を示します。手順を詳しく説明したガイドがある場合は、そのガイドにリンクします。

私は15年間VPSホストを運用しており、これらの大半を自分のサーバーで動かしています。したがって、以下のリソース量は、マーケティング用ページに記載された「最小要件」ではなく、小規模な実運用でアプリが実際に使用する量です。予算として見積もり、そこに余裕を加えてください。

前提条件と現実的な注意点

ここで扱うすべてのアプリは、root または sudo を使える、まっさらな Ubuntu 24.04 KVM VPS 上で動作します。同じ一覧は、自宅のラックに置いたサーバーでも問題なく動作します。月額料金を払い続けるか、RAM を一度購入するかで比較している場合は、自宅の Proxmox とレンタル VPS の比較でハードウェアと電力の費用を検討できます。ほとんどのアプリは Docker コンテナとして提供されるため、Docker を一度インストールすれば、この一覧のほぼすべてをすぐに実行できます(例外は Cloudron と CasaOS です。これらは独自のセットアップスクリプトでホストにインストールします。詳細はコントロールパネルのセクションを参照してください)。

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker "$USER"
newgrp docker
docker run --rm hello-world

docker コマンドが permission denied while trying to connect to the Docker daemon socket で失敗する場合は、グループ設定を省略したか、新しいシェルを開いていません。ログアウトしてから再度ログインしてください。docker compose が docker: 'compose' is not a docker command を返す場合は、古いスタンドアロンバイナリを使用しています。上のスクリプトは最新の Compose プラグインをインストールします。これは docker compose として実行します(ハイフンではなく、スペースを使います)。

以下の内容は、3 つの現実的な条件に左右されます。1 つ目は、制約になるのはディスクや CPU ではなく RAM です。 1 GB の VPS では、小規模なアプリを 1 つ実行するのが限界です。「いくつか自分でホストする」サーバーでは、4 GB が実用上の適量です。2 GB は扱いにくい中間点です。初心者が 3 つ目のサービスを追加し、Out-Of-Memory による強制終了に気付かないまま、コンテナが突然消えた理由を突き止められないことがあります。sudo dmesg には、デーモンが処理した Out of memory: Killed process の行が表示されます。2 つ目は、公開するものには名前と証明書が必要です。 直接 IP アドレスを使う方法はテストには適していますが、スマートフォンアプリやブラウザーで信頼させたい場合は機能しません。3 つ目は、2 つのポートが選択肢の半分を決めます。 標準の HTTP-01 証明書チャレンジでは、受信側の 80 番ポートからサーバーへ到達できる必要があります(DNS-01 チャレンジでは、代わりに DNS レコードで管理権限を証明するため、80 番ポートを閉じている場合に便利です)。また、送信側の 25 番ポートはほとんどのプロバイダーでブロックされます。そのため、末尾の「避けるべきもの」一覧にメールを含めています。

ファイルと写真

  • Nextcloud は、Google Drive、Dropbox、Google Calendar を1つのスイートで置き換えます。RAM は1~2 GBに加えて、ファイルの容量分を確保します。注意点は1つです。SQLite はデモには適していますが、本番環境では問題になります。最初の起動時から PostgreSQL を使用してください。データを格納した後のデータベース移行は、Nextcloud を壊す最も一般的な原因です。Docker、TLS、バックアップを使用した VPS 上の Nextcloud の完全ガイドでは、最初から正しく構築する方法を説明しています。
  • Immich は Google Photos を置き換えます。カメラロールを自動アップロードするスマートフォンアプリや、顔・物体検索にも対応します。RAM は6 GBを確保します。Immich のドキュメントではこれを最小要件としており、8 GBあれば余裕があります。負荷が大きいのは機械学習コンテナです。ディスク容量はライブラリと同じ容量に加えて、サムネイル用におよそ20%を確保します。注意点があります。Immich は2025年10月の最初の安定版リリース v2.0.0 以降、セマンティックバージョニングに従っています。これにより、互換性を壊す変更はメジャーバージョンに限定されます。現在はすでに v3 に移行しているため、latest を無条件に pull しないでください。次のメジャーバージョンまで一気に更新される可能性があります。バージョンを固定し、アップグレードの前に毎回リリースノートを確認してください。セルフホスト型 Immich 写真ライブラリのガイドでは、安全なアップグレード手順を説明しています。使用できるマシンの RAM が6 GB未満の場合は、PhotoPrism と Immich の比較で、実際のメモリ使用量、スマートフォンアプリ、各サービスでライブラリを登録する前に必要なバックアップコマンドを比較できます。
  • Seafile は、3つの中で最も高速な同期エンジンにより Dropbox を置き換えます。RAM は約1 GBを確保します。注意点は、Seafile がファイルをディスク上の通常のファイルではなく、コンテンツアドレス付きのブロックとして保存することです。そのため、ls でデータを参照できません。フォルダーをコピーするのではなく、Seafile 独自のツールでバックアップする必要があります。

パスワード

  • Vaultwarden は Bitwarden プロトコルに対応する小規模な Rust サーバーで、Bitwarden の有料プラン、LastPass、1Password の代わりになります。そのため、公式の Bitwarden アプリとブラウザー拡張機能をそのまま利用できます。必要なメモリは 100–200 MB 程度で、ディスク使用量はほとんどありません。注意点は、このサーバーが所有するすべてのパスワードを保持することです。そのため、TLS とバックアップは必須であり、導入の中心となります。ADMIN_TOKEN は Argon2 ハッシュとして設定してください。compose ファイルに平文のトークンを記述すると、それがサーバーの管理パネルのパスワードになります。この管理パネルでは、すべてのユーザーを一覧表示し、サーバー設定を変更できます。ファイルを読み取れるユーザーには、そのトークンが平文で見えてしまいます。Vaultwarden パスワードマネージャーのガイドは、最初に自分でホストするサービスとして最適です。

メディア

  • Jellyfin は Plex の代替となり、自分のライブラリを対象にすれば Netflix の代替にもなります。完全にオープンで、アカウントも有料のリモートストリーミングも不要です。アイドル時は 1–2 GB の RAM を見込みますが、トランスコード時には CPU 使用率が急上昇します。注意点は、4K ストリームをソフトウェアトランスコードすると小規模な VPS では処理しきれなくなることです。サーバーにハードウェアアクセラレーションを使用させるか、クライアントが直接再生できる形式(Direct Play)でファイルを保持してください。そうすれば、サーバーはデータを転送するだけで済みます。VPS 上の Jellyfin メディアサーバーのガイドで、これらの違いを説明しています。起動後は、Halcyon が同じライブラリをブラウザー上で歩いて回れる 90 年代のレンタル店に変えます。これは、家族に棚を眺めてもらい、すべてをスクロールして通り過ぎないようにするための、私が知る限り最もばかばかしく効果的な方法です。
  • Navidrome は自分の音楽向けの Spotify の代替です。Subsonic 互換アプリからストリーミングできます。RAM は 150–300 MB を見込みます。Go で書かれており、リソース使用量はごくわずかです。注意点は、最初のライブラリスキャンで全ファイルのタグを読み取るため、大規模なコレクションでは 1 時間かかることがある点です。ID3 タグが不適切だと、ブラウジング体験も悪くなります。
  • Audiobookshelf は Audible とポッドキャストアプリの代替となり、デバイス間で再生位置を保持します。RAM は 200–500 MB を見込みます。注意点は、書籍ごとにフォルダーを分ける厳密な構成を前提としていることです。整理されていないインポートフォルダーを使うと、検出が不完全で整理も崩れたライブラリになり、後から修正するのが面倒になります。

自動化と AI

  • n8n は、所有できるビジュアルワークフロービルダーにより、Zapier や Make を置き換えます。タスク単位の課金もありません。必要なメモリは 400 MB~1 GB です。注意点は、n8n が初回起動時に生成した key で保存済みの認証情報を暗号化することです。その key を失うか、N8N_ENCRYPTION_KEY の設定を忘れて再生成させると、保存済みの認証情報はすべて読み取れなくなり、すべて再入力する必要があります。HTTPS 対応のセルフホスト n8n のガイドでは key を固定し、webhook URL の前段に実際の証明書を配置します。
  • Ollama は、ローカルかつプライベートな LLM 推論環境として、ChatGPT のサブスクリプションを置き換えます。必要なリソースは model ごとに異なります。7~8B model では約 8 GB の RAM が必要です。ディスク上のサイズは量子化方式によって異なり、一般的な 4-bit download ではおよそ 4~5 GB、完全精度の fp16 build では 13 GB 以上です。注意点は、CPU のみの VPS では推論自体は正常に動作するものの低速なことです。ホスト型 API のような即時の応答ではなく、1 秒あたりの単語数で考えてください。期待値を調整するか、GPU box を借りてください。Ollama で LLM をセルフホストする ガイドには、現実的な数値を記載しています。

コミュニケーション

  • Rocket.Chat は、スレッド、通話、連携機能を備え、チーム向けに Slack を置き換えます。MongoDB 上で動作し、ここが最も大きな負荷要因になるため、RAM は 2 GB 以上を見積もります。注意点は、Rocket.Chat の各メジャーリリースが対応する MongoDB のバージョン範囲が狭いことです。8.x には MongoDB 8.0 以降が必要で、7.x は 6.0 または 7.0 で動作しました。また、Rocket.Chat のアップグレードガイドラインでは、メジャーバージョンを順番に移行するよう案内しています。1つ飛ばすとデータベースを取り残すため、アップグレードは一段階ずつ行ってください。Docker Compose で Rocket.Chat を構築する ガイドでは、各バージョンへの移行手順を説明しています。
  • Matrix (Synapse) は、ホームサーバーを自分で管理できる、連合型かつエンドツーエンド暗号化されたネットワークで Slack と Discord を置き換えます。大規模な公開ルームに参加すると増加するため、RAM は 1–2 GB を見積もります。注意点は、大規模な連合ルームでは Synapse のメモリ使用量が急増することです。また、Synapse は PostgreSQL 上で動作させる必要があります。デフォルトの SQLite は単一ユーザーでのテストにしか使えず、連合を開始した時点で処理できなくなります。Synapse が重い場合は、同じプロトコルに対応する軽量な Conduit または Dendrite サーバーを使用できます。

ネットワークとアクセス

  • WireGuard は商用 VPN の代替となり、自分の IP と他のサービスへのプライベートトンネルを提供します。必要なリソースはほとんどなく、50 MB 未満で、暗号処理はカーネル内で実行されます。注意点は、コンテナベースの仮想化環境(OpenVZ、一部の LXC)ではモジュールが RTNETLINK answers: Operation not supported で失敗することです。KVM を使用してください。自己ホスト型 WireGuard VPN ガイドを参照してください。トンネルにバインドしたサービスと組み合わせることで、サービスを完全にパブリックインターネットから隔離できます。新しいデバイスを追加するたびにピア設定を手動編集したくない場合は、VPS で Tailscale サブネットルーターを実行する 方法を使うと、ルートを承認し、IP forwarding を再起動後も有効にするだけで、そのプライベート範囲全体を他のマシンへ広告できます。
  • Traefik は手書きの nginx バーチャルホスト設定と証明書更新の手動作業に代わるものです。Docker labels を使ってコンテナを検出し、Let's Encrypt の証明書を自動取得します。必要なメモリは約 100 MB です。注意点は、labels ベースの設定モデルが最初は非常に分かりにくく、1 つの label を間違えるだけで明確なエラーがないままアプリへのルーティングが停止することです。複数の Docker アプリ向け Traefik リバースプロキシ ガイドは、このページにある複数のアプリを 1 つのエントリーポイントの背後で実行するために作成されています。
  • AdGuard Home は Pi-hole のサーバーと有料 DNS フィルタリングの代替となり、DNS 層でネットワーク上のすべてのデバイスに対する広告とトラッカーをブロックします。必要なメモリは 100–150 MB です。注意点は port 53 の使用を要求することです。Ubuntu では systemd-resolved と競合し、port を先に解放するまで listen udp 0.0.0.0:53: bind: address already in use で起動に失敗します。

監視

  • Uptime Kuma は、使いやすいダッシュボードと、ほぼあらゆる通知先へのアラートにより、Pingdom、UptimeRobot、StatusPage の代替になります。必要な RAM は 150–300 MB です。注意点は、常に見落とされるものです。本番サーバーは 別の サーバーから監視してください。監視対象と同じサーバー上で Uptime Kuma を実行していると、そのサーバーが停止したことを検知できません。外部に配置する方法は、Uptime Kuma によるステータス監視のガイドで説明しています。
  • Zabbix は、エージェントベースの詳細なメトリクス、トリガー、履歴機能を備え、Datadog やエンタープライズ向け監視スイートの代替になります。必要な RAM は 2 GB 以上で、専用のデータベースも必要です。注意点は、Zabbix が強力である一方、セットアップの負荷も実際に高いことです。3 つのコンテナを監視するだけなら過剰であり、サーバー群の監視には適しています。まずは Uptime Kuma を使い、実際に監視対象のインフラが必要になった段階で Zabbix 監視サーバーへ移行してください。

Prometheus と Grafana をこの一覧に含めていないのは意図的です。これらは大規模なサーバー群向けの優れたツールですが、個人運用の 2~3 台のサーバーで正当化できる範囲を超えて、実行と調整の負荷が高くなります。この規模では、Uptime Kuma と Zabbix で同じ問題を、より少ない保守負担で解決できます。

ダッシュボードと管理パネル

これらを使うと運用モデル全体が変わります。compose ファイルを手動で実行する代わりに、パネルがアプリを管理します。

  • Cloudron は、「ワンクリックで導入できればよいのに」という要望を、整備されたアプリストア、自動 TLS、組み込みのバックアップで解決します。RAM は最低 2 GB、余裕を持たせるなら 4 GB を見積もります。注意点は、設計方針が明確で、サーバー全体を管理下に置こうとすることです。実際には、コンテナとしてではなく、専用の cloudron-setup script を使って新規の Ubuntu サーバーにインストールします。また、ドキュメントでは ARM、LXC、Docker、OpenVZ のホストをサポート対象外としています。無料で使えるのは 2 アプリまでで、それを超えると有料製品になります。
  • CasaOS は、雑然とした homelab のダッシュボードを、使いやすいアプリグリッドに置き換えます。無料で軽量です。ホストに専用の script(curl -fsSL https://get.casaos.io | sudo bash)でインストールし、コンテナとしては動作させません。その後、アプリは Docker で実行します。CasaOS 自体には、およそ 150 から 300 MB の RAM を見積もります。注意点は、信頼できるホームネットワーク向けに設計されており、パブリックインターネット向けの強化が施されていないことです。直接公開せず、WireGuard 経由でアクセスしてください。
  • Coolify は、Heroku、Vercel、Netlify、git-push によるデプロイ、データベース、プレビュー環境を自分のサーバー上で置き換えます。RAM は最低 2 GB を見積もります。注意点は、比較的新しいプロジェクトで開発が速いため、バージョンを固定し、アップグレード前にリリースノートを読む必要があることです。Cloudron、CasaOS、Coolify の比較では、3 つのうちどれがどのような利用者に適しているかを整理しています。

開発・生産性向上ツール

  • Gitea(または Forgejo) は、プライベートリポジトリ、Issue、CI の用途で GitHub を置き換えます。必要な RAM は 200–500 MB です。注意点は、Forgejo が Gitea から分岐したコミュニティ運営のプロジェクトで、現在はこちらを推奨する人が多いことです。どちらも優れていますが、どちらか一方を選び、リポジトリとデータベースを必ず一緒にバックアップしてください。データベースを含まないリポジトリのバックアップでは、すべての Issue と Pull Request が失われます。
  • Paperless-ngx は、書類を OCR 処理して検索可能にするため、書類棚や有料の文書スキャナーに代わるツールです。必要な RAM は約 1 GB で、OCR 中は CPU 使用率が急上昇します。注意点は、OCR の結果がスキャン品質に左右されることです。大量のアーカイブを再処理すると時間がかかるため、10 年分の紙書類を一括インポートする前に設定を調整してください。
  • Actual Budget は、YNAB とサービス終了した Mint に代わる、高速でローカル動作するプライベートな封筒式予算管理ツールです。必要な RAM は約 150 MB です。注意点は、自動銀行同期が組み込まれているものの任意機能であることです。SimpleFIN Bridge や Enable Banking などの地域プロバイダーに登録し、自分の API 認証情報を追加して初めて利用できます。そのため、初期状態では取引を手動でインポートします。
  • FreshRSS は、Feedly とサービスを終了した Google Reader に代わる、高速でプライベートなフィードリーダーです。モバイルアプリも利用できます。必要な RAM は約 150 MB です。注意点は、cron ベースのフィード更新を設定する必要があることです。設定しない場合、ページを開いたときにしかフィードが更新されません。
  • BookStack は、ドキュメント管理の用途で Notion と Confluence に代わるツールです。コンテンツは棚、書籍、ページとして整理します。PHP と MySQL で動かす場合、必要な RAM は約 500 MB です。注意点は、自由形式のノートではなく、独自の構造でコンテンツを管理することです。この方式を好む人もいれば、制約が多いと感じる人もいます。Wiki 全体を移行する前に試してください。
  • Home Assistant は、SmartThings と多数のベンダー製アプリに代わり、スマートホームをローカル環境で一元管理します。必要な RAM は約 1 GB です。注意点は、多くの機能でデバイスへのローカルネットワークアクセスが必要なことです。そのため、リモート VPS より自宅のハードウェアで実行する方が適しています。必要であれば、ダッシュボードをリモートで実行し、自宅のネットワークへブリッジ接続してください。

代表的なインストール例

具体的に示すため、自己ホスト構成の全体像を示します。compose ファイル、実際の証明書、バックアップを用意します。これは Uptime Kuma の例ですが、一覧にあるすべてのアプリが同じパターンに従います。

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    volumes:
      - ./data:/app/data
    ports:
      - "127.0.0.1:3001:3001"
    restart: unless-stopped
docker compose up -d
docker compose logs -f

127.0.0.1: に注目してください。アプリは localhost でのみ待ち受け、Traefik や nginx などのリバースプロキシが前段で TLS を終端します。0.0.0.0:3001 に直接バインドすると、暗号化されていない管理パネルをインターネット全体に誤って公開することになります。

まだ自分でホストすべきでないもの

  • メール。 これは率直に言います。ほとんどの VPS プロバイダーでは送信ポート 25 がブロックされています。telnet aspmx.l.google.com 25 から Connection timed out が表示されますが、利用者側で修正することはできません。これはプロバイダーのポリシーです。プロバイダーによっては、依頼すれば制限を解除してくれます。AWS などでは、制限の解除を申請できます。ただし、これは設定で切り替えるものではなく、申請が必要です。ポート 25 が開いていても、評判のない新しい IP、PTR レコード、SPF、DKIM、DMARC がなければ、メールは迷惑メールフォルダーに入るか、完全に拒否されます。これは週末だけで対応できる作業ではなく、継続的な運用が必要です。それでも自分で運用する場合は、Mailcow でメールをセルフホストする ガイドを使い、数か月にわたって到達率を管理する覚悟をしてください。
  • 確実にバックアップと復元ができないもの。 テスト復元を一度も実施していないなら、それはバックアップではなく、期待にすぎません。復元できることを確認するまで、失うと取り戻せないデータ、写真の唯一のコピー、アカウントなどをそのサービスに置かないでください。
  • 重要な依存先の唯一のコピー。 障害が発生するとネットワーク全体のインターネット接続まで停止する自前の DNS サーバーは、最初のプロジェクトには不向きです。上流のフォールバックを用意してください。
  • リアルタイムの安全システム。 住宅用警報、医療アラートなど、5 分間の停止が現実に重大な問題になるものは、日曜の夜にアップグレードする趣味用のマシンで運用すべきではありません。

最初の1つを選ぶ方法と、絶対に外せない2つの条件

実際に不満を感じている請求をなくせるアプリか、現実に感じているプライバシー上の懸念を解消できるアプリを選びます。実際には、最初に導入するアプリとして Vaultwarden と Uptime Kuma が最適です。どちらも軽量で、すぐに役立ち、操作を誤っても復旧しやすいためです。2つ目を追加する前に、インストール、証明書の設定、バックアップ、リストアテストまで、1つを最初から最後まで動作させます。身に付けるべきスキルは、インストールボタンを押すことではなく、運用です。

上記のすべてのアプリで、例外なく必須となる条件が2つあります。

  1. 公開するすべてに TLS を適用すること。 ベア IP で平文通信を行うサービスは、デプロイではなくデモです。nginx で Certbot と Let's Encrypt を使う などで、サービスの前段に正式な証明書を配置するか、Traefik に自動処理させます。続いて、Ubuntu 24.04 で SSH に Fail2ban を設定する で入口を強化します。
  2. 実際にリストアしたバックアップを用意すること。 毎晩のダンプを自動化し、データベースとデータボリュームをまとめて取得して、サーバー外 に送信します。さらに月に1回、使い捨ての VPS にリストアし、正常に機能することを確認します。ディスクが故障した日に、バックアップが空だったと知るのでは手遅れです。

この2つを正しく実施すれば、セルフホスティングは快適です。省略すれば、障害発生までのカウントダウンになります。

選択肢は、実用的なものから極端なものまであります。家族向けの VPS 上の Minecraft サーバー から、注意すべき事例としての 世界で最も非効率なデータセンター まで、幅広く選べます。

FAQ

最初に何をセルフホストすべきですか?

Vaultwarden です。パスワードマネージャーは日常的な価値を提供し、サブスクリプションを置き換えられます。また、Docker、リバースプロキシ、TLS、バックアップを含む一連の運用を学べます。壊しても 10 分で再構築できる規模のアプリなので、学習にも適しています。次は Uptime Kuma が適しています。ユーザーより先に障害を把握できるためです。

VPS は実際にどの程度必要ですか?

小規模なアプリを 1 つ動かすだけなら、RAM 1 GB で動作します。複数のサービスを無理なく動かすなら、4 GB を目安にしてください。2 GB は、コンテナが警告なしに Out-Of-Memory で停止し、原因を特定できない状態になりやすい容量です。ほとんどの場合、制約になるのは RAM です。ディスク容量は保存するデータ量に合わせて追加してください。Immich、Ollama、大規模なデータベースを使用するアプリでは、RAM とディスクの両方を多く必要とすることを見込んでください。

セルフホストすべきでないものは何ですか?

最優先で避けるべきなのはメールです。送信元ポート 25 は多くのプロバイダーでブロックされており、メールの到達性を維持するには継続的な対応が必要です。次に、確実にバックアップと復元を行えないものです。停止すると実害が生じる単一障害点も避けてください。例えば、代替手段のない DNS サーバーや、家庭の安全に関わるシステムです。それ以外は、このリストにあるものならセルフホストの候補になります。

これらすべてに Docker が必要ですか?

必須ではありませんが、使用することを推奨します。ここにあるアプリは Cloudron と CasaOS を除き、すべて Docker image を提供しています。この 2 つは独自のセットアップスクリプトでホストに直接インストールし、その後はアプリをコンテナで実行します。それ以外では、Docker によりクリーンなインストールと削除、簡単なバージョン固定、新しいホストへの移行が可能になります。WireGuard や Zabbix など、一部のアプリは必要に応じて apt からネイティブにインストールすることもできます。1 つの compose file の使い方を理解すれば、他のものにも応用できます。そのため、このリスト全体に取り組みやすくなります。

すべてを安全に保つにはどうすればよいですか?

次の 4 つの習慣で、大部分の対策を実施できます。すべての通信の前段に TLS を置くこと、鍵のみのログインで SSH を制限し、ブルートフォース攻撃を Fail2ban で遮断すること、本当に公開が必要なポートだけを公開し、それ以外には WireGuard VPN 経由で接続すること、そしてリリースノートを確認しながら定期的に更新することです。これにより、アップグレードで不意の問題が発生するのを防げます。バックアップが 5 つ目の習慣です。最初の 4 つをすり抜けた操作ミスから復旧する手段になります。