SSD Nodes Learn 🎉 VPS từ $5.50/tháng
Hướng dẫn Matt ConnorBởi Matt Connor

Tự host Matrix Synapse trên VPS: cần chuẩn bị gì

Tìm hiểu cách duy trì Matrix Synapse trên VPS: sizing 1 vCPU và 2 GB RAM, Postgres, media retention, chống đăng ký tự do và backup đủ cả hai phần.

Việc cần làm để duy trì một homeserver Matrix Synapse hoạt động ổn định

Matrix Synapse dễ cài đặt và cũng dễ bị bỏ quên. Cài đặt chỉ gồm một apt repository, một file cấu hình, một block reverse proxy và một bản ghi DNS. Duy trì homeserver hoạt động ổn định trong một năm là công việc khác: cần một database thực sự, một media store được dọn dẹp định kỳ, cơ chế đăng ký mà người lạ không thể tự sử dụng, và một bản backup bao gồm cả hai phần của server.

Hướng dẫn này dành cho Ubuntu 24.04 LTS và cài Synapse từ apt repository của matrix.org. Đây là nguồn package do dự án Synapse duy trì cho Debian và Ubuntu. Phiên bản package thay đổi sau mỗi vài tuần, nên hướng dẫn này không ghi số phiên bản cụ thể. Mọi path và option bên dưới đều lấy từ tài liệu Synapse hiện tại.

Sizing: 1 vCPU và 2 GB RAM thực sự đáp ứng được gì

Các trang sizing được công bố, tính đến tháng 8 năm 2026, thường đề xuất chạy Synapse homeserver với 1 vCPU và 2 GB RAM. Mức này phù hợp trong một trường hợp: server riêng tư, vài người dùng, các room nhỏ và không có room công khai đông người. Tài liệu Synapse nói rõ trường hợp còn lại: bạn cần “ít nhất 1GB RAM trống nếu muốn tham gia các room công khai lớn như #matrix:matrix.org”. Đây là RAM trống, chưa tính Python, Postgres và kernel.

Chỉ một room cũng có thể làm thay đổi sizing của bạn, do cách cơ chế tham gia room hoạt động. Khi một người dùng local tham gia room, homeserver của bạn trở thành participant đầy đủ trong room đó. Server nhận mọi event từ tất cả server khác trong room, xác minh chữ ký của từng event và lưu state của room ở local. Một room công khai lớn có hàng nghìn thành viên phân bổ trên hàng trăm server, nên máy chủ của bạn phải liên tục xử lý lượng dữ liệu đó, dù người dùng có mở lại room hay không. Sau khi rời room, lịch sử đã lưu vẫn không bị xóa.

Phần lớn RAM của Synapse được dùng cho cache. Phần caches có một global_factor điều chỉnh đồng thời mọi cache, còn biến môi trường SYNAPSE_CACHE_FACTOR đặt cùng giá trị đó. Tăng giá trị này sẽ dùng thêm RAM để giảm số lần truy vấn database. Giảm giá trị này sẽ dùng thêm CPU và thời gian xử lý của Postgres để tiết kiệm RAM. Postgres cũng cần bộ nhớ riêng, nên trên máy 2 GB, hai thành phần này cạnh tranh cùng một lượng memory.

Có 2 nguyên tắc thực tế cho plan nhỏ. Thêm swap: swap không làm Synapse chạy nhanh hơn, nhưng giúp kernel không kill process trong lúc một client join room lớn. Sau đó hãy monitor disk ngay từ tuần đầu tiên, vì 2 thứ tăng không giới hạn là media store và các bảng room state, và cả hai đều nằm trên disk.

Vì sao dùng Postgres, và vì sao SQLite không còn phù hợp

Gói Debian khởi động với SQLite. Điều này phù hợp cho lần khởi động đầu tiên nhưng không phù hợp với server có người khác sử dụng. SQLite chỉ cho phép một tiến trình ghi tại một thời điểm. Lưu lượng federation và request của client có thể cùng ghi dữ liệu, nên một request nhanh phải chờ sau một request chậm. Người dùng thường thấy ứng dụng bị treo ngẫu nhiên trong vài giây.

Lý do thứ hai liên quan đến cấu trúc. Worker process của Synapse là cách được hỗ trợ để dùng nhiều hơn một CPU core, và worker yêu cầu Postgres. Tiếp tục dùng SQLite đồng nghĩa với việc từ bỏ cả hướng nâng cấp lẫn hiệu năng.

Bạn có thể migration sau này, nhưng việc đó yêu cầu downtime. Vì vậy, hãy thực hiện trước khi có người dùng. Synapse cung cấp synapse_port_db để sao chép database SQLite sang một database Postgres đã chuẩn bị:

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

Nếu muốn chạy database trong một container cùng với Synapse, hãy xem các đánh đổi trong chạy database trong Docker hoặc trên host.

Cài đặt Synapse trên 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

Trên Ubuntu 24.04, lsb_release -cs cho kết quả noble, còn repository matrix.org phát hành một suite noble. Không dùng gói matrix-synapse từ archive riêng của Ubuntu. Dự án Synapse khuyến cáo không làm vậy vì các bản build này thường chậm hơn các bản phát hành của dự án và chứa các lỗi bảo mật đã biết.

Trình cài đặt yêu cầu nhập tên server rồi ghi câu trả lời vào /etc/matrix-synapse/conf.d/server_name.yaml. Hãy nhập cẩn thận. server_name là phần sau dấu hai chấm trong mọi user ID (@alice:example.com), đồng thời được nhúng vào mọi room do server của bạn tạo. Thay đổi giá trị này về sau không di chuyển dữ liệu; nó tạo ra một homeserver khác. Dùng domain gốc của bạn, example.com, ngay cả khi Synapse chạy trên matrix.example.com. Delegation kết nối hai phần này với nhau. Đây là nội dung của section tiếp theo.

Package chạy Synapse với user matrix-synapse, lưu dữ liệu dưới /var/lib/matrix-synapse, và đọc /etc/matrix-synapse/homeserver.yaml rồi đọc mọi file trong /etc/matrix-synapse/conf.d/. Đặt các thiết lập riêng vào những file nhỏ trong conf.d. Các lần nâng cấp package sẽ không thay đổi những file này.

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

Khi khởi động thành công, các listener sẽ hoạt động rồi hệ thống trở nên yên lặng. systemd unit khởi động lại service vài giây sau mỗi lần tiến trình thoát. Vì vậy, nếu Synapse từ chối một cấu hình, unit sẽ khởi động rồi dừng lặp đi lặp lại. Các dòng cuối của journal cho biết key mà Synapse đã từ chối.

Trỏ Synapse vào 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

Locale không chỉ mang tính hình thức. Synapse sẽ từ chối khởi động với database được tạo bằng các giá trị COLLATECTYPE khác, trừ khi bạn đặt allow_unsafe_locale trong cấu hình database. Cách sửa được tài liệu hướng dẫn sau đó là dump rồi nạp lại vào một database được tạo đúng. Hãy tạo đúng ngay từ đầu.

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

Chỉ giữ đúng một khóa database: trong tất cả các file cấu hình. Thay block SQLite bên trong homeserver.yaml thay vì thêm bản sao thứ hai dưới conf.d, để không bao giờ phải đoán cấu hình nào đang được dùng. Khởi động lại, rồi xác nhận Synapse thực sự đang dùng Postgres:

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

Một con số cho biết Synapse đã tạo schema trong database này. Lỗi về relation bị thiếu cho biết nó vẫn đang ghi vào file SQLite, nên file cấu hình bạn đã sửa không phải file đang được đọc.

Reverse proxy, TLS và các file .well-known cần cho federation

Synapse lắng nghe HTTP thuần trên cổng 8008 và bind vào localhost. TLS và cổng public do reverse proxy phía trước Synapse đảm nhiệm.

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 yêu cầu Synapse tin tưởng header X-Forwarded-For do proxy thiết lập. Nếu thiếu cấu hình này, mọi client đều trông như đến từ 127.0.0.1. Khi đó rate limiting chỉ thấy một local user hoạt động quá mức và throttle tất cả client cùng lúc.

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;
}

Tài liệu Synapse đưa ra một cảnh báo về block này mà nhiều người phải mất nhiều ngày mới tìm ra. Không thêm path sau cổng trong proxy_pass, kể cả một / duy nhất. nginx sẽ canonicalise URI. Việc này làm thay đổi các byte mà sending server đã ký, khiến federation request không vượt qua bước xác minh chữ ký, trong khi request thông thường từ client vẫn hoạt động.

client_max_body_size phải lớn hơn hoặc bằng max_upload_size của Synapse. Nếu nginx giữ giá trị nhỏ hơn, các upload vượt quá giới hạn đó sẽ bị nginx từ chối với 413 Request Entity Too Large trước khi Synapse nhận được request. Vì vậy log Synapse sẽ không có dòng nào giải thích lỗi này.

Để cấp certificate, làm theo Certbot và Let's Encrypt trên Ubuntu 24.04. Nếu chưa quyết định dùng proxy nào, xem so sánh reverse proxy để biết proxy nào sẽ xử lý TLS cho bạn.

Delegation cho phép server_name vẫn giữ nguyên là example.com trong khi Synapse chạy trên matrix.example.com. Hãy serve 2 file từ 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"}}';
}

File server cho các homeserver khác biết nơi gửi federation traffic. Nhờ đó federation chạy qua 443 thay vì cổng mặc định 8448. File client cho Matrix client biết URL nào đứng sau @alice:example.com. Header Access-Control-Allow-Origin quan trọng trong file client vì các client chạy trên browser fetch file này cross-origin. Nếu thiếu header, browser sẽ block response và client báo không tìm thấy homeserver của bạn.

Cả 2 file phải được serve qua TLS hợp lệ ngay từ example.com. Hãy kiểm tra chúng, rồi kiểm tra nội dung mà bên ngoài nhìn thấy:

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

Lệnh đầu tiên trả về JSON bạn đã viết. Lệnh thứ hai trả về một JSON object có tên implementation của server và version của nó. Điều này xác nhận proxy reach được Synapse trên federation path. Sau đó kiểm tra domain bằng Matrix federation tester tại https://federationtester.matrix.org, công cụ này đi theo cùng route mà một server từ xa thực sự sử dụng.

Liên kết federation hay không: hãy quyết định có chủ ý

Federation là lý do Matrix tồn tại, đồng thời cũng là phần tốn kém nhất. Homeserver có federation chấp nhận kết nối từ những server bạn chưa từng biết, nhận event của chúng, cache media và lưu state cho mọi room mà người dùng truy cập. Đây là quyết định về threat model, không phải thiết lập mặc định.

Hãy bật federation khi người dùng cần liên lạc với người trên homeserver khác, hoặc khi danh tính có thể di chuyển là lý do bạn chọn Matrix. Không bật federation khi server chỉ dành cho một team và mọi account trên đó đều thuộc quyền quản lý của bạn. Server đóng lưu trữ ít hơn, nhận ít dữ liệu hơn và ít bị lạm dụng hơn nhiều.

Để hạn chế thay vì tắt hoàn toàn, Synapse hỗ trợ allow list:

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

Tài liệu cũng khuyến nghị cấu hình firewall cho federation listener, để traffic không mong muốn bị chặn tại network thay vì đi vào Python. Để tắt hoàn toàn federation, xóa federation khỏi danh sách listener resources, không publish /.well-known/matrix/server và để port 8448 đóng.

Nếu lý do chạy Matrix là chat riêng cho team và federation chưa bao giờ cần thiết, hãy so sánh chi phí vận hành với các giải pháp Slack tự host khác trước khi chọn Synapse. Rocket.Chat trên Docker Compose cung cấp chat cho team trên một máy nhỏ hơn, vì nó không bao giờ phải lưu state của room thuộc tổ chức khác.

Kho lưu trữ media là thành phần âm thầm làm đầy ổ đĩa

Các file do chính user của bạn upload sẽ nằm vĩnh viễn trên ổ đĩa. Các file do user trên homeserver khác đăng được tải về và cache trên ổ đĩa ngay khi một client của bạn hiển thị chúng. Synapse cũng tạo thumbnail cho ảnh, nên một ảnh sẽ thành nhiều file. Theo mặc định, không file nào tự hết hạn.

Tìm thư mục lưu trữ và đo dung lượng:

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

Đo đường dẫn được in trong cấu hình của chính bạn. Gói Debian lưu dữ liệu của Synapse dưới /var/lib/matrix-synapse, nên kho lưu trữ thường nằm ở đó. Sau đó đặt chính sách lưu giữ trong conf.d:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

Đọc kỹ hai dòng này, vì chúng là hai loại cấu hình khác nhau. remote_media_lifetime đặt thời hạn cho cache, và mọi dữ liệu bị xóa có thể được tải lại từ server sở hữu file đó. local_media_lifetime xóa vĩnh viễn các media do user cục bộ upload khi chúng đạt đến thời hạn đó. Một team chia sẻ tài liệu trong chat và muốn tìm lại chúng vào năm sau sẽ mất các file này. Nhiều server chỉ đặt giá trị cho media từ xa.

Để dọn dẹp một lần, admin API nhận Unix timestamp tính bằng mili giây:

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 xóa media từ xa đã được truy cập lần cuối trước timestamp đó khỏi cache. POST /_synapse/admin/v1/media/delete?before_ts=<ms> xóa media cục bộ theo cùng quy tắc. Chạy purge media từ xa trước rồi đo lại, vì trên server federation, cache media từ xa thường chiếm phần lớn hơn.

Hai cấu hình cùng tác động đến ổ đĩa. max_upload_size giới hạn một lần upload và phải đồng bộ với client_max_body_size trong nginx. url_preview_enabled: true khiến server của bạn tải các trang từ xa để client hiển thị link preview. Việc này tiêu tốn bandwidth và lưu thumbnail của những nội dung không do bạn upload.

Đóng đăng ký trước khi có người tìm thấy homeserver của bạn

Các scanner có thể tìm thấy một homeserver đang mở chỉ trong vài ngày. Khi ai cũng có thể tự tạo account, server của bạn sẽ trở thành nguồn phát tán spam trong mọi room mà nó federation cùng, và quản trị viên ở phía bên kia sẽ block toàn bộ domain của bạn. Thiệt hại về reputation vẫn còn sau khi dọn dẹp xong, vì các danh sách block được duy trì thủ công.

Synapse mặc định tắt đăng ký. enable_registration mặc định là falseregistration_requires_token mặc định là false. Synapse cũng từ chối khởi động khi đăng ký được bật nhưng không có bước xác minh, trừ khi bạn đặt thêm enable_registration_without_verification: true. Đây là hành vi từ chối có chủ ý, vì vậy đừng bật tùy chọn này chỉ để bỏ qua lỗi khởi động.

Tạo các account cần dùng thủ công:

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

Lệnh này yêu cầu nhập user name, password và xác định account có phải là server admin hay không. Lệnh đọc registration_shared_secret từ file cấu hình được truyền bằng -c. Vì vậy, nếu lệnh báo không tìm thấy shared secret, hãy trỏ -c đến file chứa secret đó.

Khi tạo account thủ công không còn phù hợp với quy mô cần quản lý, registration token là tùy chọn trung gian. Token là một chuỗi mà user mới phải cung cấp khi đăng ký. Mỗi token có thể giới hạn số lần được sử dụng:

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

Bỏ token khỏi phần body để Synapse tự tạo token và trả về token đó. GET /_synapse/admin/v1/registration_tokens liệt kê các token còn hiệu lực. Cả hai API call đều cần access token của một server admin account. Bạn lấy access token này bằng cách đăng nhập bằng admin user đã tạo ở trên.

Tổ chức đã quản lý account ở nơi khác có thể bỏ qua hoàn toàn password local, vì Synapse có thể ủy quyền đăng nhập cho một OIDC (OpenID Connect) provider, ví dụ Authentik làm SSO provider tự host. Khi đó, việc thêm và xóa user được xử lý tập trung tại một nơi.

Bản backup có thể thực sự dựng lại server

Một bản backup của Synapse có ba phần. Nếu thiếu bất kỳ phần nào, bạn sẽ khôi phục được một server mà không ai sử dụng được.

  • Database Postgres, nơi lưu mọi event, account và room.
  • Thư mục media store, nơi lưu mọi file đã upload.
  • /etc/matrix-synapse, nơi lưu config và signing key của server.

Signing key là phần mọi người thường quên. Đây là private key mà homeserver dùng để ký event. Các server từ xa xác minh event bằng public key tương ứng. Chạy grep signing_key_path /etc/matrix-synapse/homeserver.yaml để xem key của bạn nằm ở đâu. Nếu mất key, bạn sẽ khôi phục được một server không thể chứng minh rằng đó là server mà các room hiện có đã biết.

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

Dump database trước, sau đó copy media store. Các file media chỉ được ghi một lần và được tham chiếu bằng ID. Vì vậy, bản copy media được tạo sau khi dump chỉ có thể chứa thêm file, không thể thiếu file. Nếu làm theo thứ tự ngược lại, database đã khôi phục có thể trỏ đến một file mà backup chưa từng lưu.

Đưa cả ba phần ra ngoài VPS. restic với snapshot lưu ngoài site phù hợp với mô hình này, vì media store chiếm phần lớn dung lượng nhưng hầu như không thay đổi giữa các lần chạy. Deduplication vì thế giúp mỗi snapshot có dung lượng nhỏ.

Sau đó hãy diễn tập restore, vì một bản backup chưa từng được restore mới chỉ là giả định. Tạo một VPS thứ hai, cài cùng package, restore config, tạo database với cùng encoding và locale, pg_restore dump vào database đó, copy media store trở lại, rồi đăng nhập. Ghi lại thời gian thực hiện. Đó là thời gian khôi phục thực tế của bạn.

Nén bảng khi bảng state tăng lớn

Synapse lưu state của room dưới dạng state group. Trên server liên kết federation, state_groups_state thường trở thành object lớn nhất trong database. Hãy đo trước khi thay đổi:

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'));"

Nếu bảng đó chiếm phần lớn database, project có cung cấp một compressor cho bảng này là rust-synapse-compress-state. Công cụ này viết lại hệ thống phân cấp state group thành ít row hơn mà không thay đổi ý nghĩa state của bất kỳ room nào. Công cụ được xây dựng bằng 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 là số state group được xử lý trong một lần. -n là số chunk được xử lý trong lần chạy này. Auto compressor ghi lại tiến độ đã xử lý, nên lần chạy tiếp theo sẽ tiếp tục từ đó. Nhờ vậy, bạn có thể lên lịch chạy an toàn. Tài liệu của công cụ cho biết các thay đổi được áp dụng trong transaction trên các bảng append-only, nên công cụ có thể chạy khi Synapse vẫn đang hoạt động. Dù vậy, hãy backup database trước lần chạy đầu tiên.

Một chi tiết về Postgres thường khiến mọi người bất ngờ. Xóa row chỉ trả lại dung lượng cho Postgres để tái sử dụng, không trả lại dung lượng cho file system. Vì vậy, df có thể không giảm sau một lần compaction lớn. VACUUM FULL mới trả lại dung lượng đó. Lệnh này giữ exclusive lock trên bảng và cần lượng disk trống xấp xỉ kích thước của bảng. Vì vậy, hãy lên lịch chạy trong maintenance window thay vì chạy tùy ý.

Các kiểm tra cho biết server đang hoạt động bình thường

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

Hoạt động bình thường nghĩa là unit đang active và không liên tục restart, file delegation trả về giá trị m.server của bạn, endpoint phiên bản federation trả về JSON, và có thể so sánh hai số liệu dung lượng với tháng trước. Kiểm tra dung lượng là bước mọi người thường bỏ qua. Hết dung lượng đĩa là lỗi khiến Synapse ngừng hoạt động mà không cảnh báo: volume đầy khiến Postgres không thể ghi, sau đó Synapse fail mọi request có thao tác với database.

FAQ

Máy chủ Matrix Synapse cần bao nhiêu RAM?

Với một homeserver riêng có vài người dùng, các room nhỏ và không có room công khai lớn, 2 GB là đủ dùng. Đây cũng là mức mà hầu hết các trang sizing được công bố khuyến nghị tính đến tháng 8 năm 2026. Tài liệu Synapse yêu cầu có thêm ít nhất 1 GB RAM trống ngoài phần RAM cần cho các thành phần khác nếu người dùng sẽ tham gia các room công khai lớn như #matrix:matrix.org, vì khi đó máy chủ của bạn phải lưu state của room đó và liên tục xử lý traffic của room. Hãy thêm swap trên gói 2 GB để một lần tham gia room lớn không khiến kernel kill process.

Tôi có phải dùng PostgreSQL thay vì SQLite không?

Nếu có hơn một vài người dùng thì có. SQLite chỉ cho phép một writer tại một thời điểm, nên federation traffic và request từ client sẽ chặn lẫn nhau khi có tải, khiến request bị treo trong nhiều giây. Các worker process của Synapse, là cách được hỗ trợ để dùng nhiều hơn một CPU core, yêu cầu Postgres. Bạn vẫn có thể migrate sau bằng synapse_port_db, nhưng việc này gây downtime. Vì vậy, hãy tạo database bằng --encoding=UTF8 --locale=C --template=template0 trước khi có người dùng.

Vì sao disk usage của Synapse cứ tăng?

Có một directory và một table cần chú ý. Media store giữ mọi file được upload vào các room mà server của bạn tham gia, bao gồm bản cache của media từ remote user và thumbnail được tạo tự động. Không có dữ liệu nào hết hạn cho đến khi bạn đặt media_retention. Table state_groups_state tăng theo state của room trên server federating, còn rust-synapse-compress-state giúp giảm kích thước table này. Hãy đo cả hai bằng du -sh trên media_store_path của bạn và bằng SELECT pg_size_pretty(pg_total_relation_size('state_groups_state')); trước khi quyết định xử lý phần nào.

Làm cách nào để ngăn người lạ đăng ký trên homeserver của tôi?

Giữ enable_registration ở giá trị mặc định là false và tạo account bằng register_new_matrix_user. Khi cách này không còn phù hợp với quy mô, hãy đặt enable_registration: true cùng với registration_requires_token: true, rồi cấp các token được tạo bằng POST /_synapse/admin/v1/registration_tokens/new. Không đặt enable_registration_without_verification: true chỉ để bỏ qua việc Synapse từ chối khởi động, vì homeserver mở sẽ trở thành nguồn phát tán spam và các administrator khác có thể block toàn bộ domain của bạn.

Homeserver của tôi có nên bật federation không?

Federation là quyết định về mức độ exposure, không phải tính năng mặc định bắt buộc bật. Hãy bật federation nếu người dùng cần liên lạc với người dùng trên các homeserver khác. Hãy tắt federation nếu server chỉ phục vụ một team, vì server không federate sẽ lưu ít dữ liệu hơn, nhận ít traffic hơn và thu hút ít abuse hơn nhiều. Ở mức trung gian, federation_domain_whitelist giới hạn federation vào các partner domain được chỉ định. Tài liệu Synapse cũng khuyến nghị cấu hình firewall cho federation listener thay vì chỉ dựa vào kiểm tra ở application layer.