セルフホスト型フォーラム4製品をVPSで比較

どのセルフホスト型フォーラムソフトウェアを運用すべきか

現在 VPS (virtual private server) で運用できるセルフホスト型フォーラムソフトウェアは、実質的に Discourse、Flarum、NodeBB、phpBB の4つです。RAM を4 GB割り当てられ、モデレーションを担当できる人が少なくとも2人いるなら、標準の選択肢は Discourse です。RAM が1 GBで、モデレーターが1人なら、Flarum または phpBB を選びます。管理できない高機能なフォーラムより、常に整理された小規模なフォーラムのほうが優れています。

インストールは簡単です。これらはいずれも半日あれば稼働させられます。フォーラムが1年後も存続しているかどうかを左右するのは、通報キューとメール経路です。そのため、機能一覧を読む前にモデレーションとメールのセクションを確認してください。

フォーラムの稼働に実際に必要なもの

フォーラムは1つの要素ではなく、4つの要素で構成されます。アプリケーションプロセス、アプリケーションより長く存続させるデータベース、アップロードしたアバターと添付ファイルを保存するディレクトリ、そしてメールを送信できる経路です。アプリケーションは交換できます。しかし、データベースは交換できません。すべての投稿、アカウント、プライベートメッセージがデータベース内に保存されるためです。そのため、以下の各セクションでプロジェクトが選択しているデータベースが最も重要な項目です。フォーラムを離れる日に、エクスポートがどのような形式になるかを決めるからです。

2つ目のコストは人的コストです。公開登録と公開投稿を有効にすると、通常はドメインがクローラーに検出されてから最初の1週間以内にボット登録が発生します。4つの要素すべてを制限できます。ただし、コア機能だけでこの運用フローを提供しているのは1つだけです。

Discourse: 標準構成と実際のコスト

Discourse は Ruby on Rails で動作し、データに PostgreSQL、キャッシュとジョブキューに Redis、バックグラウンド処理に Sidekiq を使用します。サポート対象のインストールでは、これらすべてを /var/discourse/containers/app.yml の設定ファイルから構築した 1 つの Docker コンテナに収めます。各コンポーネントを自分でインストールする必要はありません。

wget -qO- https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse | sudo bash

このスクリプトは、存在しない場合に git と Docker をインストールし、discourse_docker を /var/discourse に clone してから、対話式の discourse-setup ウィザードを起動します。ウィザードでは、ホスト名、管理者のメールアドレス、SMTP（simple mail transfer protocol）の詳細を入力します。その内容を app.yml に書き込み、コンテナを構築します。コンテナ自身が nginx を実行し、Let's Encrypt の証明書を取得するため、80 番ポートと 443 番ポートは空いていなければなりません。

公開されている最小要件は、swap を含む 1 GB の RAM と、10 GB のディスクです。swap が必要だという点を文字どおりに受け取ってください。ウィザードが swap が必要だと判断すると、セットアップスクリプトは fallocate -l 2G /swapfile で 2 GB の swapfile を作成します。この swap は形式的なものではありません。メモリ使用量のピークはサイトの通常稼働時ではなく、./launcher rebuild app の実行時に発生します。これはアップグレードのたびに、コンテナ内で JavaScript と CSS のアセットを再コンパイルします。swap のない 1 GB のマシンでは、この処理が途中で kill され、再構築が画面上で有用なエラーを表示しないまま終了します。その場合、dmesg | tail に Out of memory: Killed process の行が表示されます。無理なく運用するには 2 GB、フォーラムが活発になったら 4 GB を確保してください。

アップグレードはブラウザーの /admin/upgrade から実行するか、shell から実行します。

cd /var/discourse
./launcher rebuild app

rebuild は実行中のコンテナを破棄し、app.yml から新しいコンテナを bootstrap して起動します。そのため、処理にかかる数分間はサイトが停止します。1 つのコンテナだけを使う構成では、これを回避できません。data.yml と web_only.yml のサンプルを使って 2 つのコンテナに分割すると、Web コンテナの再構築中も PostgreSQL を稼働させられます。停止に気付くユーザーがいる規模になれば、この構成にする価値があります。

Discourse はモデレーション機能に多くの RAM を使います。新規アカウントは trust level 0 から始まり、投稿できるリンク数と投稿速度に厳しい制限があります。読むことや参加することで trust level が上がります。通報はレビューキューに入り、誰がどの案件を処理したかが記録されます。Akismet と StopForumSpam との統合は公式プラグインです。残り 3 つについては、アドオンを組み合わせて実現します。

Discourse の最も強い機能は、Discourse への移行です。ソースツリーの script/import_scripts/ ディレクトリには 60 を超える importer があり、phpbb3.rb、vbulletin.rb、xenforo.rb、vanilla.rb、mybb.rb、flarum_import.rb、nodebb ディレクトリ、メーリングリストのアーカイブ用 mbox importer などが含まれます。これらは、旧データベースのコピーに対してコンテナ内で実行する Ruby スクリプトです。処理は遅いものの、保守されています。

Discourse からの移行は弱点です。./launcher enter app に続けて discourse backup を実行すると、PostgreSQL の dump と uploads ディレクトリを含む .tar.gz が書き出されます。これを復元できるのは別の Discourse だけです。他のソフトウェアはこのファイルを読み取れないため、Discourse を離れる場合は、その dump に対して自分で SQL を記述する必要があります。50,000 件の投稿を import する前に、この制約を受け入れられるか判断してください。

軽量な PHP フォーラム、Flarum

Flarum は一般的な PHP アプリケーションです。nginx または Apache の背後で php-fpm を動かし、MySQL または MariaDB データベースと、ディスク上のファイルを使用します。公式に記載されている要件は、curl、dom、fileinfo、gd、json、mbstring、openssl、pdo_mysql、tokenizer、zip 拡張機能を備えた PHP 7.3 以降と、MySQL 5.6+（または 8.0.23+）または MariaDB 10.0.5+ です。Ubuntu 24.04 には PHP 8.3 が含まれているため、この最低要件を満たしています。

この一覧の pdo_mysql に注意してください。Flarum は PostgreSQL をサポートしておらず、SQLite もサポートしていません。単一ファイルのデータベースが必要なら、下記の phpBB を使用します。

sudo apt update
sudo apt install -y nginx mariadb-server composer php-fpm php-mysql php-curl php-gd php-mbstring php-xml php-zip
sudo install -d -m 755 /srv/flarum
cd /srv/flarum
sudo COMPOSER_ALLOW_SUPERUSER=1 composer create-project flarum/flarum:^1.8.0 .
sudo chown -R www-data:www-data /srv/flarum

Web サーバーは /srv/flarum ではなく /srv/flarum/public を指すように設定します。アプリケーションコード、設定ファイル、データベースパスワードはすべて public の1つ上のディレクトリに置かれています。そのため、ドキュメントルートを1階層上にすると、要求したユーザーに認証情報を提供してしまいます。Apache では mod_rewrite と AllowOverride All も必要です。これにより、同梱されている .htaccess が有効になります。nginx では、同梱されている .nginx.conf を server ブロック内にインクルードします。その後、ドメインにアクセスすると、Flarum 独自のインストーラーがデータベースと管理者アカウントの情報を要求します。

2026年8月時点のバージョンは、1.8.17 が2026年6月に公開された現行の安定版で、2.0 は release candidate 5 の段階です。release candidate で新しいコミュニティを開始しないでください。2.0 がリリースされると、拡張機能を読み込む前に更新する必要があります。このアップグレードで週末を失うことになります。

必要なリソースは少量です。php-fpm のワーカー数個、数百 MB を使用する MariaDB、静的ファイルがあれば動作します。新しいコミュニティなら 1 GB に収まります。

弱点は、モデレーションです。コア機能では、通報とグループごとの権限が提供されます。承認キューとスパムブロック機能は拡張機能で追加します。主に FriendsOfFlarum のコレクションを composer require でインストールし、管理パネルで有効にします。現時点では機能します。ただし、phpBB や Discourse より小規模なボランティア中心のエコシステムに依存します。保守されていない拡張機能があると、composer が新しいバージョンとの依存関係を解決できないため、次のコアアップグレードが止まります。

データの取り出しは簡単です。mysqldump でデータベースをバックアップし、assets ディレクトリをコピーします。データの取り込みは、より難しくなります。Discourse には Flarum から Discourse への移行用に flarum_import.rb が同梱されています。通常、データはこの方向に移行されることが分かります。phpBB から Flarum へのインポートは、公式機能ではなくコミュニティ拡張機能で行います。唯一のコピーを任せる前に、コピーしたデータでテストしてください。

NodeBB: リアルタイム投稿と、それに伴う負担

NodeBB は Node.js で動作します。WebSocket 経由で新しい投稿を開いているブラウザーへプッシュするため、表示中のスレッドは再読み込みなしで更新されます。これが NodeBB を選ぶ理由です。README では Node.js 22 以降と、MongoDB 5 以降または Redis 7.2 以降のいずれかを要求しています。ソースツリーには、3 つ目の選択肢として PostgreSQL ドライバーも含まれています。

この説明で注意が必要なのは、Redis をプライマリデータベースにすることです。Redis はデータセットをメモリ上に保持するため、フォーラムの規模に応じて必要な RAM が増え続けます。MongoDB または PostgreSQL はデータをディスクに保持し、利用頻度の高いデータをキャッシュします。理由を明確に説明できる場合だけ Redis を選択してください。

Ubuntu 24.04 のパッケージは Node.js 18 であり、必要な最低バージョンを下回ります。そのため、まず現在のランタイムをインストールしてください。

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs git build-essential
sudo adduser --system --group --home /srv/nodebb nodebb
sudo -u nodebb git clone -b v4.x https://github.com/NodeBB/NodeBB.git /srv/nodebb
cd /srv/nodebb
sudo -u nodebb ./nodebb setup

./nodebb setup は対話式です。使用するデータベースと接続先を尋ねた後、管理者アカウントを作成し、ポートを設定します。デフォルトのポートは 4567 です。NodeBB は npm start では起動しません。インターフェースは ./nodebb で、出力先は ./nodebb log です。

./nodebb start はデーモン化するため、再起動が発生するマシンには適していません。代わりに、ローダーをフォアグラウンドで systemd から実行してください。

[Unit]
Description=NodeBB
After=network.target

[Service]
Type=simple
User=nodebb
WorkingDirectory=/srv/nodebb
ExecStart=/usr/bin/env node loader.js --no-daemon
Restart=on-failure

[Install]
WantedBy=multi-user.target

--no-daemon が見落とされやすい部分です。これがないとローダーは fork した後に親プロセスを終了します。そのため systemctl status nodebb は unit を停止状態と報告しますが、curl localhost:4567 は引き続き応答し、systemctl stop nodebb は何も停止できません。リバースプロキシの背後で運用する場合は、WebSocket のアップグレードヘッダーを転送する必要があります。nginx のブロックに proxy_set_header Upgrade $http_upgrade; と proxy_set_header Connection "upgrade"; がないと、フォーラム自体は読み込まれますが、ブラウザーのコンソールには失敗した socket.io リクエストが大量に表示されます。その結果、読者が再読み込みするまで新しい投稿が表示されません。

モデレーション機能は Flarum と Discourse の中間です。管理パネルには通報キューがあり、カテゴリーごとの権限と評価システムも利用できます。スパム対策は、nodebb-plugin-spam-be-gone などのコミュニティプラグインで提供されます。これにより Akismet と StopForumSpam を組み込めます。

バックアップは手動で実行します。必要になる日まで、この点に触れる人はほとんどいません。./nodebb CLI にはバックアップコマンドがありません。mongodump または pg_dump を使って自分でデータベースをダンプし、public/uploads ディレクトリと config.json も一緒にコピーします。config.json にはデータベースの認証情報とサイト URL が保存されているため、これがない復元は新規インストールと同じです。公式のインポーターもありません。nodebb-plugin-import はコミュニティプロジェクトですが、現在の仕様への追随が遅れています。一方、Discourse には NodeBB インポーターが付属しているため、確実に機能する移行先は Discourse です。

phpBB: 小規模でも安定して動作する、簡素な掲示板

phpBB は古いソフトウェアです。しかし、それが採用する理由になります。3.3 系列は PHP 7.2.0 から PHP 8.3 まで動作し、MySQL 4.1.3 以降、MariaDB 5.1 以降、PostgreSQL 8.3 以降、SQLite 3.6.15 以降、MS SQL Server、Oracle に対応しています。json、mbstring、XML のサポートと、getimagesize() 関数の有効化が必要です。

この一覧に含める理由は SQLite にあります。SQLite を使う場合、フォーラムは PHP ファイルのディレクトリと、1 つのデータベースファイルで構成されます。データベースサーバーは不要で、調整する項目も、追加でバックアップする対象もありません。すでに別のサービスを動かしている 1 GB VPS では、この違いが実際の負担の差になります。小規模なコミュニティでは SQLite を使い、同時投稿が増えたら MySQL に移行してください。SQLite は書き込みを直列化するため、投稿が互いに待ち合わせるようになるからです。

composer の手順もコンテナもありません。PHP と Web サーバーをインストールし、アーカイブを展開して、ブラウザーのインストーラーを実行します。スタック全体の構築手順は、Ubuntu 24.04 での標準的な LAMP スタックで説明しています。

sudo apt update
sudo apt install -y apache2 php libapache2-mod-php php-mysql php-mbstring php-xml php-gd unzip

phpbb.com から現在の 3.3 リリースをダウンロードし、vhost が配信するディレクトリに展開します。その後、インストーラーが書き込むパスを Web サーバーのユーザーが書き込めるようにします。

sudo chown -R www-data:www-data /srv/phpbb
sudo chmod 660 /srv/phpbb/config.php
sudo chmod -R 770 /srv/phpbb/store /srv/phpbb/cache /srv/phpbb/files /srv/phpbb/images/avatars/upload

公式手順では 666 と 777 が指定されています。これらの数値は、PHP を実行するユーザーを管理できない共有ホスティングを想定したものです。自分の VPS ではそのユーザーを管理できるため、所有者を www-data にして、他のユーザーからはアクセスできないようにします。Apache には注意点があります。Ubuntu の設定では、標準のドキュメントルート配下だけにアクセスを許可しています。そのため、/srv/phpbb を指す vhost には、Require all granted を含む対応する <Directory> ブロックも必要です。これがないと、phpBB に到達する前にすべてのリクエストが 403 Forbidden になります。ブラウザーで /install/index.php を開いてインストールを完了し、その後 config.php を 640 に戻して install/ ディレクトリを削除します。このディレクトリが残っている限り、phpBB は削除するよう警告し続けます。

スパムは phpBB の既知の問題ですが、対処できます。登録フォームは予測しやすい URL（ucp.php?mode=register）にあるため、ボットはドメインがクロールされてから数日以内に見つけます。効果が持続する対策は、管理パネルの Spambot countermeasures にあります。スパム対策方式を Question and Answer に設定し、コミュニティの参加者だけが答えられる質問を作成してください。画像 CAPTCHA（completely automated public Turing tests）は、1000 件単位で課金するサービスによって安価に解答されます。自分のテーマに関する質問なら、その対象にはなりません。

移行元としても、phpBB は最もサポートが充実しています。Discourse の phpbb3.rb は、この記事全体で最も多く利用されているインポーターです。phpBB のサポートフォーラムには、20 年分の回答もあります。移行方法は mysqldump、または SQLite ファイルのコピーです。移行できないのは、使用中のスタイルと拡張機能です。

フォーラムの登録確認メールが届かないのはなぜですか？

これら4つのサービスでは、すべて確認メールによる登録承認が必要です。メールが届かなければアカウントは有効化されず、ログには途中で止まった登録処理だけが残ります。外部へのメール配送はフォーラムが機能するかどうかを左右するため、インストールの一部として扱ってください。

• ほとんどの VPS プロバイダーでは、外向きのポート 25 がデフォルトでブロックされています。そのため、ローカルの Postfix が直接配送しようとしても、メールは宛先に到達しません。メールログには connect to gmail-smtp-in.l.google.com[...]:25: Connection timed out と表示されます。
• 新規に割り当てられた IP アドレスには送信実績がありません。そのため、配送に成功しても迷惑メールフォルダーに入ります。確認リンクの場合、これは届かないのと同じです。
• DNS に SPF（sender policy framework）と DKIM（domainkeys identified mail）のレコードを公開していないと、大手プロバイダーはメッセージを即座に拒否します。Google の拒否メッセージは 550 5.7.26 Unauthenticated email from example.com is not accepted due to domain's DMARC policy です。DMARC（domain-based message authentication, reporting and conformance）も、大量にメールを送信する場合には必須と考えられています。

現実的な解決策はリレーを使うことです。フォーラムの SMTP 設定を、ポート 587 で利用できるトランザクションメールプロバイダーに向けます。そのプロバイダーから提供された SPF、DKIM、DMARC レコードを公開し、mail.example.com のようなサブドメインから送信してください。これにより、フォーラムの送信評価を個人メールと分離できます。メールサーバーを自分で運用することも可能です。VPS で完全なセルフホスト型メールサーバーを構築する方法で詳しく説明しています。ただし、フォーラムを公開する週にメール配送の仕組みを学び始めるのは適切ではありません。

フォーラムを告知する前にテストしてください。Discourse では、コンテナ内から次を実行します。

cd /var/discourse
./launcher enter app
rake emails:test[you@example.com]

このタスクは SMTP 接続を確認し、メッセージを送信します。認証情報が誤っている場合は、通常 Net::SMTPAuthenticationError のように失敗の内容も表示します。phpBB には、管理パネルの Client communication に同等のテスト機能があります。Flarum と NodeBB では、大手プロバイダーの実在するメールボックスに対して使い捨てアカウントを登録し、届いたメールの raw headers を確認してください。Authentication-Results ヘッダー内の spf=pass と dkim=pass が、確認すべき結果です。

Discourse には1つ注意点があります。2026年8月時点では、セットアップウィザードで SMTP を省略し、Discourse ID にフォールバックできます。これにより、メールでリンクを送る代わりに外部アカウントでサインインできます。リレーを用意せずに公開を開始できる点は利点です。ただし、通知メールやパスワードリセットには対応できません。そのため、コミュニティが成長する前に SMTP も設定してください。

フォーラムを TLS の背後に配置するにはどうすればよいですか？

Flarum と phpBB は通常のバーチャルホストなので、すでに運用している Web サーバーで certbot を実行すれば十分です。NodeBB と Discourse は異なります。これらはローカルポートで待ち受けるアプリケーションであり、手前で TLS（トランスポート層セキュリティ）を終端し、ホスト名に応じてルーティングする仕組みが必要です。フォーラムを他のサービスと同じサーバーで運用する場合は、すべてのサービスの前段に 1 つのリバースプロキシを配置します。これは 複数の Docker Compose アプリの前段に Traefik を配置する構成で実現できます。

Discourse はデフォルトで、独自の nginx と独自の Let's Encrypt テンプレートを使用し、ポート 80 と 443 を自分で確保します。既存のプロキシの背後に配置するには、app.yml を編集して templates/web.letsencrypt.ssl.template.yml の行を削除し、公開ポートを変更してコンテナがローカルアドレスだけで待ち受けるようにした後、./launcher rebuild app を実行します。この変更を導入後に行うと、再ビルドと数分間の停止が必要になります。そのため、インストール後ではなく、インストール前に構成を決めてください。

コミュニティの規模に合うフォーラムはどれですか？

判断基準は機能ではなく、利用者数です。

• メンバーが数百人未満で、モデレーターが 1 人、RAM が 1 GB の場合: SQLite を使用する phpBB が適しています。最新のインターフェースを求め、MariaDB を実行できる場合は Flarum も選択肢です。どちらも、パッチを適用する対象を 1 つの PHP アプリケーションにまとめられます。
• コミュニティが成長し、モデレーターが 2 人以上、RAM が 4 GB の場合: Discourse が適しています。モデレーションが 1 人では処理しきれなくなった時点で、Trust levels と review queue は必要なリソースに見合います。
• 長期的に残るスレッドよりもリアルタイムの会話を重視する場合: NodeBB が適しています。あるいは、チャットであることを受け入れ、Docker Compose で Rocket.Chat を実行する方法を選びます。1 週間後に読み返す価値のある投稿が何も残らないフォーラムは、チャットサーバーにすべきです。
• 実際に必要なのが議論ではなくドキュメントの場合: これらのいずれも適していません。BookStack、Wiki.js、または Outline のほうが適切です。同じ質問が繰り返されるフォーラムは、通常、Wiki が不足しています。
• そもそもサーバー上で何を運用するかをまだ決めていない場合: 2026 年版の幅広いセルフホスティング候補から始めるほうが適切です。セルフホスト型 Notion 代替サービスのガイドでは、フォーラムと共有ワークスペースの重複領域を扱っています。

どれを選ぶ場合でも、フォーラムの耐久性は最後に復元したバックアップの状態に左右されます。スケジュールに従ってデータベースをダンプし、同じジョブで uploads ディレクトリもコピーしてください。その後、ダンプが使用可能であることを確認するため、別の場所に 1 回復元します。VPS で restic の定期バックアップを設定するでこの手順を説明しています。この構成で、やり直しがきかないのはこの作業だけです。

FAQ

自己ホスト型フォーラムに必要な最小サーバー要件は何ですか？

phpBB は SQLite を使用すれば、データベースサーバーが不要なため、他のサービスと同居する 1 GB の RAM で動作します。Flarum には 1 GB に加えて MariaDB が必要です。NodeBB は MongoDB と組み合わせれば 2 GB で快適に動作します。Discourse は、swap と 10 GB のディスクを含む 1 GB を最小要件として公開しています。ただし、現実的な下限は 2 GB で、利用者の多いフォーラムには 4 GB が適しています。./launcher rebuild app はアップグレードのたびにメモリ上でアセットを再コンパイルするため、その時点で小規模なサーバーは kernel の out of memory handler によって停止することがあるためです。

phpBB のフォーラムを Discourse に移行できますか？

はい。この中では最もサポートされた移行経路です。Discourse には script/import_scripts/phpbb3.rb が付属しており、phpBB のデータベースのコピーに対してコンテナ内で実行します。稼働中のデータベースに対して実行してはいけません。ユーザー、カテゴリー、トピック、投稿、添付ファイルは移行されます。スタイルと拡張機能は移行されず、古いトピック URL も変わります。そのため、DNS を切り替える前に phpBB のパスからのリダイレクトを計画してください。大規模な掲示板では数時間かかるため、最初にテスト用サーバーでインポートを一度リハーサルし、所要時間を測定してください。

新しいユーザーがアクティベーションメールをまったく受信しないのはなぜですか？

多くの VPS プロバイダーは送信ポート 25 をブロックしています。そのため、ローカルのメールサーバーは配信できず、ログには受信者のメールエクスチェンジャーに対する Connection timed out が記録されます。配信できる場合でも、SPF または DKIM レコードがない新しい IP は拒否またはフィルタリングされ、Google から 550 5.7.26 Unauthenticated email ... is not accepted due to domain's DMARC policy が返されます。ポート 587 のリレー経由で送信し、そのリレーから提供された SPF、DKIM、DMARC レコードを公開してください。その後、テスト登録を行い、受信したメッセージの Authentication-Results ヘッダーを確認してください。

最もモデレーション作業が少ない自己ホスト型フォーラムソフトウェアはどれですか？

Discourse です。ワークフローが後付けではなくコア機能に含まれているためです。新しいアカウントは、十分な量を読むまでレート制限されます。通報はキューに集約され、誰が対応したかも記録されます。Akismet プラグインも公式に提供されています。phpBB も Question and Answer のアンチスパム方式を有効にすれば近い状態になります。この方式だけで、ボットによる登録の大半を阻止できます。Flarum と NodeBB は、同じ機能をコミュニティ拡張機能に依存しています。いずれにしても、実際の主要因は変わりません。モデレーションの負荷は、どのソフトウェアに投稿するかではなく、投稿する人数に応じて増加します。