Як розгорнути Matrix Synapse на VPS

Що потрібно для стабільної роботи Matrix Synapse homeserver

Matrix Synapse легко встановити й так само легко залишити без належного обслуговування. Для встановлення потрібні один apt-репозиторій, один конфігураційний файл, один блок reverse proxy та один DNS-запис. Підтримувати homeserver у робочому стані протягом року — інше завдання: потрібні повноцінна база даних, media store, який регулярно очищується, реєстрація, недоступна для сторонніх осіб, і резервна копія, що охоплює обидві частини сервера.

Цей посібник призначений для Ubuntu 24.04 LTS і встановлює Synapse з apt-репозиторію matrix.org — джерела пакетів, яке проєкт Synapse підтримує для Debian і Ubuntu. Версії пакетів змінюються кожні кілька тижнів, тому номер версії тут не зазначено. Усі наведені нижче шляхи й параметри взято з актуальної документації Synapse.

Розрахунок ресурсів: що насправді дають 1 vCPU і 2 GB RAM

Опубліковані сторінки з рекомендаціями щодо ресурсів станом на August 2026 зазвичай вказують 1 vCPU і 2 GB RAM для homeserver Synapse. Це коректно лише для одного сценарію: приватний сервер, кілька користувачів, невеликі кімнати та відсутність активних публічних кімнат. Документація Synapse прямо описує інший сценарій. У ній зазначено: «At least 1GB of free RAM if you want to join large public rooms like #matrix:matrix.org». Йдеться про вільну RAM додатково до ресурсів, потрібних Python, Postgres і kernel.

Одна кімната може змінити вимоги до ресурсів через особливості приєднання. Коли локальний користувач приєднується до кімнати, ваш homeserver стає її повноцінним учасником. Він отримує кожну подію від усіх інших серверів у цій кімнаті, перевіряє підпис кожної події та локально зберігає стан кімнати. У великій публічній кімнаті тисячі учасників розподілені між сотнями серверів, тому ваш сервер постійно виконує цю роботу, навіть якщо користувач більше ніколи не відкриє кімнату. Подальший вихід із кімнати не видаляє вже збережену історію.

Більшість RAM Synapse використовує для кешів. У розділі caches є global_factor, який одночасно масштабує всі кеші, а змінна середовища SYNAPSE_CACHE_FACTOR задає те саме значення. Збільшення цього параметра витрачає RAM, щоб зменшити кількість запитів до бази даних. Зменшення параметра економить RAM, але збільшує використання CPU і час роботи Postgres. Postgres також потребує власної пам’яті, тому на сервері з 2 GB ці два компоненти конкурують за ті самі мегабайти.

Для невеликого тарифу варто дотримуватися двох практичних правил. Додайте swap: він не зробить Synapse швидшим, але не дасть kernel завершити процес під час великого приєднання. Також відстежуйте використання диска з першого тижня, оскільки без обмеження зростають два компоненти: media store і таблиці стану кімнат. Обидва зберігаються на диску.

Чому Postgres і чому SQLite перестає бути варіантом

Пакет Debian використовує SQLite після встановлення. Це нормально для першого запуску, але не підходить для сервера, яким користуються інші люди. SQLite дозволяє лише одному процесу записувати дані одночасно. Федеративний трафік і запити клієнтів записують дані в той самий момент, тому простий запит очікує завершення повільного. Користувачі бачать це як випадкове зависання застосунку на кілька секунд.

Друга причина має структурний характер. Worker-процеси Synapse — рекомендований спосіб використовувати більше одного ядра CPU, а для них потрібен Postgres. Якщо залишитися на SQLite, ви втрачаєте не лише продуктивність, а й можливість подальшого масштабування.

Міграція пізніше підтримується, але потребує простою, тому виконайте її до появи користувачів. Synapse постачається з synapse_port_db, який копіює базу даних SQLite у підготовлену базу Postgres:

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

Якщо ви хочете запускати базу даних у контейнері поруч із Synapse, ознайомтеся з компромісами в розділі запуск бази даних у Docker або на хості.

Встановлення Synapse на Ubuntu 24.04

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 публікує suite noble. Не використовуйте пакет matrix-synapse` із власного архіву Ubuntu. Проєкт Synapse не рекомендує цього, оскільки ці збірки відстають від його релізів і містять відомі вразливості безпеки.

Інсталятор запитує ім’я сервера та записує відповідь у `/etc/matrix-synapse/conf.d/server_name.yaml. Введіть його уважно. server_name — це частина після двокрапки в кожному ідентифікаторі користувача (@alice:example.com), і вона вбудовується в кожну кімнату, яку створює ваш сервер. Зміна цього значення пізніше нічого не переміщує: вона створює інший homeserver. Використовуйте домен без піддомену — example.com, навіть якщо сам Synapse працюватиме на matrix.example.com`. Делегування забезпечує зв’язок між ними. Це описано в наступному розділі.

Пакет запускає Synapse від імені користувача `matrix-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

Після успішного запуску служба відкриває порти, а потім переходить у режим очікування. Unit systemd перезапускає службу через кілька секунд після будь-якого завершення, тому конфігурація, яку Synapse відхиляє, проявляється як unit, що запускається та постійно завершує роботу в циклі. Останні рядки журналу містять назву ключа, який він відхилив.

Налаштуйте Synapse для роботи з Postgres

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

Локаль — це не формальність. Synapse не запускається з базою даних, створеною з іншими значеннями COLLATE і CTYPE, якщо в конфігурації бази даних не встановити allow_unsafe_locale. Задокументований спосіб виправлення — створити дамп, а потім завантажити його в правильно створену базу даних. Налаштуйте все правильно з першого разу.

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:. Замініть блок SQLite всередині homeserver.yaml, а не додавайте другу копію під conf.d. Тоді не виникне сумнівів, яку конфігурацію фактично використовує Synapse. Перезапустіть Synapse, а потім перевірте, що він справді працює з Postgres:

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

Число означає, що Synapse створив схему в цій базі даних. Помилка про відсутню relation означає, що Synapse досі записує дані у файл SQLite, тому редагований вами файл конфігурації не читається.

Reverse proxy, TLS і файли .well-known, потрібні для federation

Synapse прослуховує звичайний HTTP на порту 8008 і прив’язаний до localhost. TLS і публічний порт належать 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 повідомляє Synapse, що потрібно довіряти заголовку X-Forwarded-For, який встановлює proxy. Без цього кожен клієнт виглядає так, ніби запит надійшов із 127.0.0.1. Тому rate limiting бачить одного надзвичайно активного локального користувача й обмежує всіх разом.

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 є одне попередження щодо цього блока, через яке можна втратити кілька днів. Не додавайте шлях після порту в proxy_pass, навіть один /. Тоді nginx канонізує URI. Це змінює байти, які підписав сервер-відправник. Federation-запити не проходять перевірку підпису, а звичайні запити клієнтів продовжують працювати.

client_max_body_size має бути не меншим за max_upload_size у Synapse. Якщо nginx використовує менше значення, завантаження, більші за нього, nginx відхиляє з помилкою 413 Request Entity Too Large ще до того, як їх побачить Synapse. Тому в журналі Synapse не буде повідомлення, яке пояснює помилку.

Для самого сертифіката скористайтеся матеріалом Certbot і Let's Encrypt в Ubuntu 24.04. Якщо ви ще не визначилися з proxy, у матеріалі порівняння reverse proxy описано, який із них виконуватиме TLS-термінацію.

Delegation дає змогу залишити server_name як example.com, тоді як Synapse працює на matrix.example.com. Віддавайте з bare domain два файли:

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 повідомляє іншим homeserver, куди надсилати federation-трафік. Завдяки цьому federation працює через 443, а не через порт за замовчуванням 8448. Файл client повідомляє Matrix-клієнтам, який URL обслуговує @alice:example.com. Заголовок Access-Control-Allow-Origin важливий у файлі client, оскільки клієнти в браузері отримують його cross-origin. Без цього заголовка браузер блокує відповідь, і клієнт повідомляє, що не може знайти ваш homeserver.

Обидва файли потрібно віддавати через чинний TLS безпосередньо з example.com. Перевірте їх, а потім перевірте, що бачить зовнішній світ:

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

Перша команда повертає написаний вами JSON. Друга повертає JSON-об’єкт із назвою реалізації сервера та її версією. Це підтверджує, що proxy досягає Synapse через federation-маршрут. Потім перевірте домен за допомогою Matrix federation tester на https://federationtester.matrix.org. Він використовує той самий маршрут, що й віддалений сервер у реальному запиті.

Федерацію використовувати чи ні: ухваліть це свідомо

Федерація є основним призначенням Matrix, але водночас створює більшість витрат. Homeserver із федерацією приймає з’єднання від серверів, про які ви ніколи не чули, отримує їхні події, кешує медіафайли та зберігає стан кожної кімнати, до якої звертаються ваші користувачі. Це рішення щодо моделі загроз, а не налаштування за замовчуванням.

Увімкніть федерацію, якщо користувачам потрібно спілкуватися з людьми на інших homeserver або якщо переносна ідентичність є причиною вибору Matrix. Не використовуйте федерацію, якщо сервер призначений для однієї команди, а всі облікові записи на ньому належать вам. Закритий сервер зберігає менше даних, отримує менше запитів і значно менше цікавить зловмисників.

Щоб не вимикати федерацію повністю, а лише обмежити її, Synapse використовує список дозволених:

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

Документація також рекомендує фільтрувати listener федерації на рівні firewall, щоб небажаний трафік блокувався в мережі, а не всередині Python. Щоб повністю вимкнути федерацію, вилучіть federation зі списку listener resources, не публікуйте /.well-known/matrix/server і залиште порт 8448 закритим.

Якщо причиною запуску Matrix був приватний командний чат, а федерація ніколи не була потрібна, порівняйте витрати на роботу з іншими self-hosted альтернативами Slack, перш ніж зупинити вибір на Synapse. Rocket.Chat у Docker Compose забезпечує командний чат на менш потужній машині, оскільки йому не потрібно зберігати стан кімнат іншої організації.

Медіасховище непомітно заповнює диск

Файли, які завантажують ваші користувачі, назавжди залишаються на диску. Файли, опубліковані користувачами на інших homeserver, завантажуються й кешуються на вашому диску, щойно їх відображає один із ваших клієнтів. Synapse також створює мініатюри зображень, тому одна фотографія перетворюється на кілька файлів. За замовчуванням нічого з цього не видаляється автоматично.

Знайдіть сховище та виміряйте його розмір:

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

Уважно прочитайте ці два рядки, оскільки це різні типи налаштувань. 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> видаляє локальні медіафайли за тим самим правилом. Спочатку запустіть очищення віддалених файлів, а потім знову виміряйте розмір, оскільки на сервері, що бере участь у federation, віддалений кеш зазвичай займає більшу частину дискового простору.

Два налаштування впливають на один і той самий диск. max_upload_size обмежує розмір одного завантаження й має відповідати client_max_body_size у nginx. url_preview_enabled: true змушує ваш сервер завантажувати віддалені сторінки, щоб клієнти могли показувати попередній перегляд посилань. Це витрачає пропускну здатність і зберігає мініатюри вмісту, який ніхто не завантажував на ваш сервер.

Закрийте реєстрацію, перш ніж хтось знайде ваш homeserver

Сканери знаходять відкритий homeserver за кілька днів. Якщо створювати облікові записи може будь-хто, ваш сервер стає джерелом спаму в кожній кімнаті, з якою він федератується, а адміністратори з іншого боку блокують увесь ваш домен. Така шкода репутації зберігається довше за результати очищення, оскільки списки блокування ведуть вручну.

Synapse постачається із закритою реєстрацією. enable_registration має значення false, а registration_requires_token має значення false. Synapse також відмовляється запускатися, якщо реєстрацію увімкнено без етапу перевірки, якщо додатково не встановити enable_registration_without_verification: true. Така відмова є навмисною, тому не вмикайте цей параметр, щоб усунути помилку запуску.

Створюйте потрібні облікові записи вручну:

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

Команда запитує ім’я користувача, пароль і те, чи є обліковий запис адміністратором сервера. Вона читає registration_shared_secret з конфігурації, яку ви передаєте через -c. Якщо команда повідомляє, що не може знайти спільний секрет, передайте через -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 виводить список активних токенів. Обидва виклики потребують access token облікового запису адміністратора сервера. Отримайте його, увійшовши як обліковий запис адміністратора, створений вище.

Організація, яка вже керує обліковими записами в іншій системі, може повністю відмовитися від локальних паролів, оскільки Synapse може делегувати вхід провайдеру OIDC (OpenID Connect), наприклад Authentik як self-hosted SSO-провайдеру. Додавання та видалення користувачів тоді виконуються в одному місці.

Резервна копія, з якої справді можна відновити сервер

Резервна копія Synapse складається з трьох частин. Якщо бракує будь-якої з них, після відновлення сервером ніхто не зможе користуватися.

• База даних Postgres, у якій зберігаються всі події, облікові записи та кімнати.
• Каталог media store, у якому зберігаються всі завантажені файли.
• /etc/matrix-synapse, у якому зберігаються конфігурація та signing key сервера.

Signing key — це частина, про яку часто забувають. Це приватний ключ, яким ваш 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

Спочатку створіть дамп бази даних, а потім скопіюйте media store. Медіафайли записуються один раз і доступ до них здійснюється за ID, тому копія media store, створена після дампу, може містити лише додаткові файли, але не пропущені. Якщо змінити порядок, відновлена база даних може посилатися на файл, якого немає в резервній копії.

Передайте всі три частини за межі VPS. restic із віддаленими snapshot добре підходить для цієї схеми, оскільки media store займає більшу частину обсягу й майже не змінюється між запусками. Тому дедуплікація зберігає кожен snapshot невеликим.

Потім відпрацюйте відновлення, оскільки резервна копія, з якої ви ще жодного разу не відновлювали сервер, є лише припущенням. Створіть другий VPS, встановіть той самий пакет, відновіть конфігурацію, створіть базу даних із тією самою encoding і locale, pg_restore дамп у неї, скопіюйте media store назад і увійдіть до системи. Запишіть, скільки часу це зайняло. Це і є ваш фактичний час відновлення.

Коли таблиці станів розростаються: ущільнення

Synapse зберігає стан кімнат у групах стану, і на федеративному сервері 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. Він перебудовує ієрархію груп стану в меншу кількість рядків, не змінюючи семантику стану жодної кімнати. Компіляція виконується за допомогою 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 визначає, зі скількома групами стану компресор працює одночасно, а -n — скільки таких блоків обробляє цей запуск. Автоматичний компресор зберігає інформацію про виконаний обсяг, тому наступний запуск продовжує роботу з цього місця. Саме це дає змогу безпечно запускати його за розкладом. У документації зазначено, що зміни застосовуються в транзакціях до таблиць, доступних лише для додавання, тому компресор може працювати, поки 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 активний і не перезапускається, файл делегування повертає значення m.server, endpoint версії федерації повертає JSON, а два показники розміру можна порівняти з показниками за минулий місяць. Перевірку розмірів часто пропускають. Саме заповнений диск може без попередження вивести сервер Synapse з ладу: повний том не дає Postgres записувати дані, після чого Synapse завершує помилкою кожен запит, що звертається до бази даних.

FAQ

Скільки оперативної пам’яті потрібно серверу Matrix Synapse?

Для приватного homeserver із кількома користувачами, невеликими кімнатами та без великих публічних кімнат достатньо 2 GB. Саме такий обсяг рекомендує більшість опублікованих сторінок із вимогами до ресурсів станом на August 2026. Документація Synapse рекомендує мати щонайменше 1 GB вільної RAM додатково до решти потреб, якщо користувачі приєднуватимуться до великих публічних кімнат, наприклад #matrix:matrix.org. У такому разі ваш сервер зберігає стан цієї кімнати та безперервно обробляє її трафік. Додайте swap на тарифі з 2 GB, щоб одне велике приєднання не призвело до завершення процесу ядром.

Чи обов’язково використовувати PostgreSQL замість SQLite?

Після кількох користувачів — так. SQLite допускає лише одного writer одночасно, тому під навантаженням federation traffic і запити клієнтів блокують один одного, а запити зависають на кілька секунд. Worker processes Synapse, які є підтримуваним способом використання більш ніж одного CPU core, потребують Postgres. Подальша міграція за допомогою synapse_port_db можлива, але потребує простою, тому створіть базу даних за допомогою --encoding=UTF8 --locale=C --template=template0 до появи користувачів.

Чому використання диска Synapse постійно зростає?

Причини — один каталог і одна таблиця. Media store зберігає кожен файл, завантажений до кімнат, у яких бере участь ваш сервер. Це також стосується кешованих копій media віддалених користувачів і згенерованих мініатюр. Ніщо не видаляється автоматично, доки ви не налаштуєте media_retention. Таблиця state_groups_state зростає разом зі станом кімнат на federating server, а rust-synapse-compress-state зменшує її розмір. Перед вибором способу очищення виміряйте обидва показники: за допомогою du -sh для вашого media_store_path і за допомогою 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. Не встановлюйте enable_registration_without_verification: true лише для того, щоб приховати відмову Synapse запускатися. Відкритий homeserver стає джерелом спаму, тому інші адміністратори можуть заблокувати весь ваш домен.

Чи має мій homeserver підтримувати federation?

Federation — це рішення щодо зовнішньої доступності, а не налаштування за замовчуванням. Увімкніть federation, якщо користувачам потрібно спілкуватися з людьми на інших homeserver. Вимкніть її, якщо сервер обслуговує одну команду. Non-federating server зберігає менше даних, отримує менше трафіку та приваблює значно менше зловживань. Проміжний варіант — federation_domain_whitelist обмежує federation указаними доменами партнерів. Документація Synapse також рекомендує фільтрувати federation listener на рівні firewall, а не покладатися лише на цю перевірку на рівні застосунку.