ガイド

著者 Matt Connor 2026-08-14

Matrix SynapseをVPSで自宅サーバー運用する方法

Q: homeserver への見知らぬユーザーの登録を停止するにはどうすればよいですか？

enable_registration はデフォルトの false のままにし、register_new_matrix_user でアカウントを作成してください。これで対応しきれなくなったら、enable_registration: true と registration_requires_token: true を設定し、POST /_synapse/admin/v1/registration_tokens/new で作成したトークンを配布してください。Synapse の起動時の拒否を抑えるためだけに enable_registration_without_verification: true を設定しないでください。公開された homeserver はスパムの送信元になり、他の管理者からドメイン全体をブロックされる可能性があります。

Matrix SynapseをVPSで1年間安定運用するための実践ガイドです。Ubuntu 24.04 LTSの構成、1 vCPU・2 GB RAMの限界、Postgres、メディア保持、登録対策、バックアップを解説します。

Matrix Synapse のホームサーバーを稼働し続けるために必要なこと

Matrix Synapse は、インストールが簡単である一方、放置もしやすいソフトウェアです。インストールでは、apt リポジトリ、1 つの設定ファイル、1 つのリバースプロキシ設定ブロック、1 つの DNS レコードを用意します。ホームサーバーを 1 年間健全に運用するには、別の作業が必要です。実用的なデータベース、定期的に不要なデータを削除するメディアストア、第三者が利用できない登録設定、そしてサーバーの両方の構成要素を取得するバックアップが必要です。

このガイドでは Ubuntu 24.04 LTS を対象とし、matrix.org apt リポジトリから Synapse をインストールします。このリポジトリは、Synapse プロジェクトが Debian と Ubuntu 向けに管理しているパッケージソースです。パッケージのバージョンは数週間ごとに更新されるため、ここではバージョン番号を記載しません。以下のすべてのパスとオプションは、現在の Synapse ドキュメントに基づいています。

容量: 1 vCPU と 2 GB の RAM で実際にできること

2026年8月時点で公開されている容量計画のページでは、Synapse の homeserver に 1 vCPU と 2 GB の RAM を割り当てる構成が一般的です。これは、プライベートサーバーで、ユーザー数が少なく、小規模なルームだけを使用し、負荷の高い公開ルームに参加しない場合には妥当です。別のケースについて、Synapse のドキュメントは明確に説明しています。「#matrix:matrix.org のような大規模な公開ルームに参加する場合は、少なくとも 1GB の空き RAM」が必要です。これは Python、Postgres、kernel が使用するメモリとは別に必要な空き RAM です。

参加の仕組みにより、1 つのルームだけで必要な容量が変わることがあります。ローカルユーザーがルームに参加すると、homeserver はそのルームの完全な参加者になります。そのルームに参加している他のすべてのサーバーから、すべてのイベントを受信します。各イベントの署名を検証し、ルームの状態をローカルに保存します。大規模な公開ルームには、数百のサーバーに分散した数千人のメンバーがいるため、ユーザーがその後一度もルームを開かなくても、サーバーはこの処理を継続します。後でルームを退出しても、すでに保存した履歴は削除されません。

Synapse の RAM の大部分はキャッシュに使用されます。caches セクションには、すべてのキャッシュを一度に拡大または縮小する global_factor があります。SYNAPSE_CACHE_FACTOR 環境変数でも同じ値を設定できます。値を大きくすると RAM を消費してデータベースへのクエリを減らします。値を小さくすると CPU と Postgres の処理時間を消費して RAM を節約します。Postgres 自体にもメモリが必要なため、2 GB のサーバーでは両者が同じメモリを取り合います。

小規模なプランでは、実用上のルールが 2 つあります。swap を追加してください。swap によって Synapse が高速になるわけではありませんが、大規模な参加処理中に kernel がプロセスを強制終了することを防げます。次に、最初の週からディスクを監視してください。上限なく増加するものは、media store とルーム状態のテーブルであり、どちらもディスク上に保存されるためです。

Postgres を選ぶ理由と、SQLite が選択肢ではなくなる理由

Debian パッケージは SQLite で起動します。初回起動には問題ありませんが、他のユーザーが利用するサーバーには適していません。SQLite では、一度に書き込みできるプロセスは 1 つだけです。Federation のトラフィックとクライアントからのリクエストが同時に書き込みを行うため、軽いリクエストも時間のかかる処理の後ろで待たされます。その結果、ユーザーからはアプリが数秒間、ランダムに停止したように見えます。

2 つ目の理由は構造上の制約です。Synapse の worker プロセスは、複数の CPU コアを使用するためのサポート対象の方法です。worker には Postgres が必要です。SQLite を使い続けると、性能だけでなく、将来の拡張経路も失われます。

後からの移行もサポートされていますが、ダウンタイムが発生します。そのため、ユーザーが増える前に実施してください。Synapse には、SQLite データベースを準備済みの Postgres データベースへコピーする synapse_port_db が含まれています。

synapse_port_db --sqlite-database homeserver.db --postgres-config homeserver-postgres.yaml

Synapse と同じホスト上のコンテナでデータベースを実行する場合のトレードオフについては、データベースを Docker またはホスト上で実行するを参照してください。

Ubuntu 24.04 に Synapse をインストールする

sudo apt install -y lsb-release wget apt-transport-https
sudo wget -O /usr/share/keyrings/matrix-org-archive-keyring.gpg https://packages.matrix.org/debian/matrix-org-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/matrix-org-archive-keyring.gpg] https://packages.matrix.org/debian/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/matrix-org.list
sudo apt update
sudo apt install matrix-synapse-py3

Ubuntu 24.04 では、lsb_release -cs の出力は noble で、matrix.org リポジトリは noble スイートを公開しています。Ubuntu 自身のアーカイブにある matrix-synapse パッケージは使用しないでください。Synapse プロジェクトも使用しないよう求めています。これらのビルドはリリースより遅れており、既知のセキュリティバグを含んでいるためです。

インストーラーはサーバー名を尋ね、その回答を /etc/matrix-synapse/conf.d/server_name.yaml に書き込みます。慎重に回答してください。server_name はすべてのユーザー ID（@alice:example.com）でコロンの後にある部分であり、サーバーが作成するすべてのルームに埋め込まれます。後から変更しても既存のデータは移行されません。別の homeserver になるためです。Synapse 自体を matrix.example.com で実行する場合でも、ベアドメインの example.com を使用してください。Delegation により両者が接続されます。次のセクションで説明します。

パッケージは matrix-synapse ユーザーとして Synapse を実行し、データを /var/lib/matrix-synapse 以下に保持します。また、/etc/matrix-synapse/homeserver.yaml を読み込んだ後、/etc/matrix-synapse/conf.d/ 内のすべてのファイルを読み込みます。独自の設定は conf.d 内の小さなファイルに記述してください。パッケージのアップグレードによる影響を受けません。

sudo systemctl restart matrix-synapse
systemctl status matrix-synapse
sudo journalctl -u matrix-synapse -n 100 --no-pager

正常に起動すると、リスナーが起動した後、ログ出力は落ち着きます。systemd unit は終了後数秒でサービスを再起動するため、Synapse が拒否する設定では、unit が起動と終了を繰り返す状態になります。journal の末尾に、拒否されたキーが記録されます。

Postgres を Synapse の接続先に設定する

sudo apt install -y postgresql
sudo -u postgres createuser --pwprompt synapse_user
sudo -u postgres createdb --encoding=UTF8 --locale=C --template=template0 --owner=synapse_user synapse

ロケールは見た目だけの設定ではありません。異なる COLLATE と CTYPE の値で作成されたデータベースに対して、データベース設定で allow_unsafe_locale を設定しないと Synapse は起動を拒否します。その後に行う公式の修復手順は、正しく作成したデータベースへダンプして再読み込みすることです。最初から正しく作成してください。

database:
  name: psycopg2
  txn_limit: 10000
  args:
    user: synapse_user
    password: secretpassword
    dbname: synapse
    host: localhost
    port: 5432
    cp_min: 5
    cp_max: 10

すべての設定ファイルで database: キーを必ず 1 つだけにします。homeserver.yaml 内の SQLite ブロックを置き換えてください。conf.d の下に 2 つ目のコピーを追加しないでください。どの設定が有効か分からなくなる事態を防げます。再起動した後、Synapse が実際に Postgres を使用していることを確認します。

sudo -u postgres psql synapse -c "SELECT count(*) FROM users;"

数値が表示されれば、Synapse はこのデータベースにスキーマを作成しています。relation が見つからないというエラーが表示された場合、Synapse はまだ SQLite ファイルに書き込んでいます。編集した設定ファイルが読み込まれていません。

リバースプロキシ、TLS、および federation に必要な .well-known ファイル

Synapse は localhost にバインドされ、port 8008 でプレーン HTTP を待ち受けます。TLS と公開 port は、前段の reverse proxy が担います。

listeners:
- port: 8008
  tls: false
  type: http
  x_forwarded: true
  bind_addresses:
  - '::1'
  - '127.0.0.1'
  resources:
  - names:
    - client
    - federation
    compress: false

x_forwarded: true は、proxy が設定する X-Forwarded-For header を Synapse が信頼するようにします。これがないと、すべての client が 127.0.0.1 から接続したように見えます。そのため rate limiting は、1 人の非常に負荷が高い local user として扱い、全員をまとめて throttling します。

location ~ ^(/_matrix|/_synapse/client) {
    proxy_pass http://localhost:8008;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $host:$server_port;
    client_max_body_size 50M;
    proxy_http_version 1.1;
}

Synapse のドキュメントには、この block について、対応を誤ると解決に数日かかる警告があります。proxy_pass の port の後には、単一の / であっても path を追加しないでください。nginx は URI を canonicalise します。これにより送信側サーバーが署名した bytes が変わり、federation requests の signature verification に失敗します。一方、通常の client requests は引き続き動作します。

client_max_body_size は、Synapse の max_upload_size 以上に設定してください。nginx 側の値が小さいと、それを超える uploads は Synapse に届く前に nginx が 413 Request Entity Too Large で拒否します。そのため、失敗の理由を示す Synapse の log line は出力されません。

certificate 自体については、Ubuntu 24.04 での Certbot と Let's Encrypt に従ってください。proxy がまだ決まっていない場合は、reverse proxy の比較で TLS をどれに任せるかを確認できます。

Delegation により、Synapse を matrix.example.com で実行しながら、server_name を example.com のまま維持できます。bare domain から次の 2 つの files を配信します。

location /.well-known/matrix/server {
    default_type application/json;
    return 200 '{"m.server": "matrix.example.com:443"}';
}

location /.well-known/matrix/client {
    default_type application/json;
    add_header Access-Control-Allow-Origin '*';
    return 200 '{"m.homeserver": {"base_url": "https://matrix.example.com"}}';
}

server file は、他の homeserver に federation traffic の送信先を伝えます。これにより、federation は default port 8448 ではなく 443 経由で動作します。client file は、@alice:example.com の backend となる URL を Matrix clients に伝えます。client file では Access-Control-Allow-Origin header が重要です。browser-based clients はこの file を cross-origin で取得するため、この header がないと browser が response をブロックし、client は homeserver を見つけられないと報告します。

両方の files は、example.com 自体から有効な TLS を使用して配信する必要があります。まず files を確認し、次に外部から見える内容を確認します。

curl -s https://example.com/.well-known/matrix/server
curl -s https://matrix.example.com/_matrix/federation/v1/version

1 つ目は、作成した JSON を返します。2 つ目は、server implementation とその version を示す JSON object を返します。これにより、proxy が federation path 経由で Synapse に到達していることを確認できます。続いて、Matrix federation tester（https://federationtester.matrix.org）で domain を検査してください。この tester は、実際の remote server と同じ経路をたどります。

フェデレーションを利用するかどうかは、意図的に決めてください

フェデレーションは Matrix の中核機能であると同時に、コストの大部分を占めます。フェデレーションを行う homeserver は、存在を把握していないサーバーからの接続を受け入れ、相手のイベントを受信し、メディアをキャッシュし、ユーザーが参加するすべてのルームの状態を保存します。これはデフォルト設定ではなく、脅威モデルに関する判断です。

ユーザーが他の homeserver の利用者と連絡を取る必要がある場合や、移植可能な ID が Matrix を選んだ理由である場合は、フェデレーションを有効にします。サーバーが 1 つのチーム専用で、すべてのアカウントを自分で管理している場合は、フェデレーションを有効にしないでください。閉じたサーバーは保存するデータも受信するデータも少なく、悪用の対象になる可能性も大幅に下がります。

無効にするのではなく制限する場合、Synapse では許可リストを使用します。

federation_domain_whitelist:
- lon.example.com
- nyc.example.com

ドキュメントでは、フェデレーション用リスナーもファイアウォールで保護することを推奨しています。これにより、不要なトラフィックを Python 内部ではなくネットワーク上で遮断できます。フェデレーションを完全に無効にするには、リスナー resources のリストから federation を削除し、/.well-known/matrix/server を公開せず、ポート 8448 を閉じたままにします。

Matrix を実行する理由がプライベートなチームチャットであり、フェデレーションを当初から必要としていなかった場合は、Synapse を導入する前に、運用コストを他のセルフホスト型 Slack 代替製品と比較してください。Docker Compose 上の Rocket.Chat は、他の組織のルーム状態を保存する必要がないため、より小さいマシンでチームチャットを運用できます。

メディアリポジトリが静かにディスクを埋めます

自分のユーザーがアップロードしたファイルは、ディスク上に永久に残ります。他のホームサーバーのユーザーが投稿したファイルは、自分のクライアントのいずれかが表示すると、ディスクへ取得されてキャッシュされます。Synapse は画像のサムネイルも生成するため、1 枚の画像が複数のファイルになります。デフォルトでは、これらのファイルは何も期限切れになりません。

保存場所を確認し、使用量を測定します。

grep media_store_path /etc/matrix-synapse/homeserver.yaml
sudo du -sh /var/lib/matrix-synapse/media_store

自分の設定が出力するパスを測定します。Debian パッケージでは Synapse のデータが /var/lib/matrix-synapse 配下に保存されるため、通常はそこに保存場所があります。次に、conf.d で保持ポリシーを設定します。

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

この2行は設定の種類が異なるため、注意して読んでください。remote_media_lifetime はキャッシュを期限切れにします。削除されたファイルは、そのファイルを所有するサーバーから再取得できます。local_media_lifetime は、自分のユーザーがアップロードしたメディアを指定した経過時間に達すると完全に削除します。チャットでドキュメントを共有し、翌年も見つけられることを期待しているチームでは、そのファイルが失われます。多くのサーバーでは、リモート側の値だけを設定します。

一度だけクリーンアップする場合、admin API には Unix タイムスタンプをミリ秒単位で指定します。

BEFORE_TS=$(date -d '30 days ago' +%s%3N)
curl -X POST -H "Authorization: Bearer $ADMIN_TOKEN" \
  "https://matrix.example.com/_synapse/admin/v1/purge_media_cache?before_ts=$BEFORE_TS"

POST /_synapse/admin/v1/purge_media_cache は、そのタイムスタンプより前に最後にアクセスされたリモートメディアのキャッシュを削除します。POST /_synapse/admin/v1/media/delete?before_ts=<ms> は同じ条件でローカルメディアを削除します。まずリモートメディアを削除し、その後にもう一度使用量を測定します。フェデレーションを行うサーバーでは、通常、リモートキャッシュのほうが大きな割合を占めるためです。

2つの設定が同じディスク使用量に影響します。max_upload_size は1回のアップロードの上限を設定するため、nginx の client_max_body_size と一致させる必要があります。url_preview_enabled: true を設定すると、クライアントがリンクプレビューを表示できるように、サーバーがリモートページを取得します。その結果、帯域幅を消費し、自分のサーバーにアップロードされていないコンテンツのサムネイルを保存します。

誰かに homeserver を見つけられる前に登録を閉じる

スキャナーは、公開状態の homeserver を数日で見つけます。アカウントを自由に作成できる状態になると、サーバーが連携するすべてのルームでスパムの発信元になります。相手側の管理者はドメイン全体をブロックします。この評判の損害は、対処後も残ります。ブロックリストは手動で管理されるためです。

Synapse は登録を閉じた状態で出荷されます。enable_registration のデフォルト値は false で、registration_requires_token のデフォルト値は false です。検証手順なしで登録を有効にすると、enable_registration_without_verification: true も設定しない限り Synapse は起動しません。この拒否動作は意図されたものです。起動エラーを解消するために有効化しないでください。

必要なアカウントは手動で作成します。

sudo register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http://localhost:8008

ユーザー名、パスワード、そのアカウントをサーバー管理者にするかどうかを尋ねられます。-c で渡した設定から registration_shared_secret を読み取ります。共有シークレットが見つからないというエラーが表示された場合は、-c に共有シークレットを格納したファイルを指定してください。

アカウントを手動で作成する方法では対応しきれなくなったら、登録トークンを使用します。登録トークンは、新しいユーザーが登録時に提示する文字列です。各トークンには、使用回数の上限を設定できます。

enable_registration: true
registration_requires_token: true

curl -X POST -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"uses_allowed": 1}' \
  https://matrix.example.com/_synapse/admin/v1/registration_tokens/new

token をリクエスト本文から省略すると、Synapse がトークンを生成して返します。GET /_synapse/admin/v1/registration_tokens では、有効なトークンの一覧を取得できます。どちらの呼び出しにも、サーバー管理者アカウントのアクセストークンが必要です。このアクセストークンは、上記で作成した管理者ユーザーでログインして取得します。

別の場所ですでにアカウントを管理している組織では、ローカルパスワードを完全に省略できます。Synapse は、たとえば自己ホスト型 SSO プロバイダーとしての Authentik のような OIDC (OpenID Connect) プロバイダーにログイン処理を委任できるためです。入社者と退職者の管理を1か所に集約できます。

実際にサーバーを再構築できるバックアップ

Synapse のバックアップには 3 つの要素があります。どれか 1 つでも欠けると、誰も利用できないサーバーしか復元できません。

すべてのイベント、アカウント、ルームを保持する Postgres データベース。
アップロードされたすべてのファイルを保持するメディアストアディレクトリ。
/etc/matrix-synapse。設定とサーバーの署名鍵を保持します。

署名鍵は忘れられがちな要素です。これは homeserver がイベントへの署名に使用する秘密鍵であり、リモートサーバーは対応する公開鍵でイベントを検証します。grep signing_key_path /etc/matrix-synapse/homeserver.yaml を実行すると、署名鍵の場所を確認できます。これを失うと、既存のルームが認識しているサーバーと同じサーバーであることを証明できない状態で復元することになります。

sudo -u postgres pg_dump --format=custom --file=/var/backups/synapse-$(date +%F).dump synapse
sudo tar czf /var/backups/synapse-etc-$(date +%F).tgz -C /etc matrix-synapse

最初にデータベースをダンプし、その後でメディアストアをコピーします。メディアファイルは 1 回だけ書き込まれ、ID で参照されるため、ダンプ後に取得したメディアのコピーには追加ファイルしか含まれません。欠落することはありません。逆の順序では、復元したデータベースが、バックアップに含まれていないファイルを参照する可能性があります。

3 つの要素をすべて VPS の外部に送信します。オフサイトスナップショットを使用する restic はこの構成によく適しています。メディアストアが大部分を占め、実行ごとの変化がほとんどないため、重複排除によって各スナップショットのサイズを小さく保てます。

次に、復元を実際に試します。復元したことのないバックアップは、仮説にすぎないためです。2 台目の VPS を構築し、同じパッケージをインストールします。設定を復元し、同じエンコーディングとロケールでデータベースを作成し、pg_restore でダンプを取り込み、メディアストアを元の場所にコピーして、ログインします。完了までの時間を記録してください。その時間が実際の復旧時間です。

状態テーブルが肥大化した場合: コンパクション

Synapse はルームの状態を state group として保存します。フェデレーションサーバーでは、state_groups_state がデータベース内で最大のオブジェクトになることがよくあります。変更する前に測定してください。

sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));"
sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_total_relation_size('state_groups_state'));"

そのテーブルだけでデータベースの大部分を占めている場合、プロジェクトが提供する rust-synapse-compress-state というコンプレッサーを使用できます。これは、各ルームの状態の意味を変えずに、state group の階層をより少ない行に書き換えます。Rust で構築されています。

sudo apt install -y build-essential libssl-dev pkg-config git
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
git clone https://github.com/matrix-org/rust-synapse-compress-state.git
cd rust-synapse-compress-state/synapse_auto_compressor
cargo build --release

./target/release/synapse_auto_compressor -p postgresql://synapse_user:secretpassword@localhost/synapse -c 500 -n 100

-c は一度に処理する state group の数で、-n は今回の実行で処理するチャンク数です。自動コンプレッサーは処理した位置を記録するため、次回の実行はその位置から続行されます。これにより、安全にスケジュール実行できます。ドキュメントによると、変更は append-only テーブルに対するトランザクションで適用されるため、Synapse の稼働中でも実行できます。ただし、初回の実行前には必ずデータベースをバックアップしてください。

ここでは、Postgres の仕様に関して意外に思われやすい点があります。行を削除しても、空き領域はファイルシステムではなく、Postgres が再利用できる領域になります。そのため、大規模なコンパクションの後も df はほとんど変わらないことがあります。VACUUM FULL を実行すると空き領域がファイルシステムに返されます。ただし、テーブルの排他的ロックを取得し、テーブルサイズとおおむね同じ量の空きディスク領域を必要とします。思いつきで実行せず、メンテナンス作業としてスケジュールしてください。

サーバーが正常であることを確認する項目

systemctl status matrix-synapse
curl -s https://example.com/.well-known/matrix/server
curl -s https://matrix.example.com/_matrix/federation/v1/version
sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));"
sudo du -sh /var/lib/matrix-synapse/media_store

正常な状態とは、unit が active で再起動を繰り返していないこと、委任ファイルが m.server の値を返すこと、federation のバージョンエンドポイントが JSON を返すこと、そして2つのサイズの数値を先月の値と比較できることです。サイズの確認は省略されがちですが、ディスク容量の枯渇は Synapse サーバーを警告なしに停止させる原因になります。ボリュームが満杯になると Postgres が書き込みできなくなり、Synapse はデータベースにアクセスするすべてのリクエストで失敗します。

FAQ

Matrix Synapse サーバーにはどのくらいの RAM が必要ですか？

少数のユーザーが小規模なルームを利用し、大規模な公開ルームを利用しないプライベートな homeserver であれば、2 GB で運用できます。2026 年 8 月時点で公開されている多くのサイジング情報も、2 GB を推奨しています。ユーザーが #matrix:matrix.org のような大規模な公開ルームに参加する場合、Synapse のドキュメントでは、他の用途に必要な容量に加えて少なくとも 1 GB の空き RAM を確保するよう求めています。この場合、サーバーはそのルームの状態を保存し、ネットワークトラフィックを継続的に処理するためです。2 GB プランでは swap も追加してください。大規模な参加処理によって、カーネルがプロセスを強制終了する事態を防げます。

SQLite ではなく PostgreSQL を使う必要がありますか？

ユーザーが数人を超える場合は、必要です。SQLite では同時に書き込めるプロセスが 1 つだけなので、高負荷時には federation のトラフィックとクライアント要求が互いにブロックし、要求が数秒間停止することがあります。Synapse の worker プロセスは、複数の CPU コアを使用するためのサポートされた方法ですが、Postgres が必要です。後からの移行は synapse_port_db で実行できますが、ダウンタイムが発生します。そのため、ユーザーを追加する前に --encoding=UTF8 --locale=C --template=template0 でデータベースを作成してください。

Synapse のディスク使用量が増え続けるのはなぜですか？

確認すべき対象は、1 つのディレクトリと 1 つのテーブルです。media store には、サーバーが参加しているルームにアップロードされたすべてのファイルが保存されます。リモートユーザーのメディアのキャッシュコピーや生成されたサムネイルも含まれ、media_retention を設定するまで削除されません。federation を有効にしたサーバーでは、state_groups_state テーブルがルームの状態に応じて増加し、rust-synapse-compress-state によって縮小できます。どちらに対応するかを決める前に、media_store_path 上で du -sh を実行し、SELECT pg_size_pretty(pg_total_relation_size('state_groups_state')); も使用して、両方の使用量を測定してください。

homeserver への見知らぬユーザーの登録を停止するにはどうすればよいですか？

enable_registration はデフォルトの false のままにし、register_new_matrix_user でアカウントを作成してください。これで対応しきれなくなったら、enable_registration: true と registration_requires_token: true を設定し、POST /_synapse/admin/v1/registration_tokens/new で作成したトークンを配布してください。Synapse の起動時の拒否を抑えるためだけに enable_registration_without_verification: true を設定しないでください。公開された homeserver はスパムの送信元になり、他の管理者からドメイン全体をブロックされる可能性があります。

homeserver で federation を有効にすべきですか？

federation はデフォルトで有効にするものではなく、公開範囲に関する判断です。ユーザーが他の homeserver のユーザーと通信する必要がある場合は、federation を有効にしてください。1 つのチームだけが利用するサーバーでは、無効にしておくことを推奨します。保存するデータ、受信するトラフィック、受ける悪用がいずれも少なくなるためです。その中間の構成として、federation_domain_whitelist により federation の接続先を指定したパートナードメインに限定できます。ただし、Synapse のドキュメントでは、このアプリケーション層のチェックだけに頼らず、federation listener に対してもファイアウォールを設定することを推奨しています。

#matrix#synapse#self-hosting #postgresql#federation