Własny serwer Matrix Synapse na VPS: konfiguracja

Wymagania dotyczące utrzymania serwera domowego Matrix Synapse

Instalacja Matrix Synapse jest prosta, lecz łatwo o niej zapomnieć. Proces obejmuje dodanie jednego repozytorium apt, edycję jednego pliku konfiguracyjnego, konfigurację jednego bloku reverse proxy oraz jeden rekord DNS. Utrzymanie stabilności serwera domowego przez rok wymaga innych działań: wdrożenia wydajnej bazy danych, regularnego czyszczenia pamięci podręcznej mediów, ograniczenia rejestracji dla niepowołanych użytkowników oraz wykonywania kopii zapasowych obejmujących obie części serwera.

Niniejszy przewodnik dotyczy systemu Ubuntu 24.04 LTS i zakłada instalację Synapse z repozytorium apt matrix.org, które jest oficjalnym źródłem pakietów utrzymywanym przez projekt Synapse dla systemów Debian i Ubuntu. Wersje pakietów zmieniają się co kilka tygodni, dlatego w tekście nie podano konkretnych numerów wersji. Wszystkie ścieżki oraz opcje przedstawione poniżej są zgodne z aktualną dokumentacją Synapse.

Dobór zasobów: co faktycznie oferuje 1 vCPU i 2 GB RAM

Opublikowane strony z wymaganiami sprzętowymi, aktualne na sierpień 2026, zazwyczaj wskazują dla serwera domowego Synapse konfigurację 1 vCPU i 2 GB RAM. Jest to uczciwe założenie dla jednego przypadku: prywatnego serwera, kilku użytkowników, małych pokoi i braku aktywnych pokoi publicznych. Dokumentacja Synapse jasno określa drugi przypadek. Wymaga ona „co najmniej 1 GB wolnej pamięci RAM, jeśli chcesz dołączyć do dużych pokoi publicznych, takich jak #matrix:matrix.org”. Wolnej pamięci RAM, ponad to, co zużywa Python, Postgres i jądro systemu.

Jeden pokój może zmienić zapotrzebowanie na zasoby ze względu na sposób działania procesu dołączania. Gdy lokalny użytkownik dołącza do pokoju, serwer domowy staje się pełnoprawnym uczestnikiem tego pokoju. Odbiera każde zdarzenie od każdego innego serwera w pokoju, weryfikuje podpis każdego z nich i przechowuje stan pokoju lokalnie. Duży pokój publiczny ma tysiące członków rozproszonych na setkach serwerów, więc serwer wykonuje tę pracę w sposób ciągły, niezależnie od tego, czy użytkownik kiedykolwiek ponownie otworzy ten pokój. Opuszczenie pokoju w późniejszym czasie nie usuwa już zapisanej historii.

Większość pamięci RAM w Synapse jest przeznaczana na pamięci podręczne. Sekcja caches zawiera global_factor, która skaluje wszystkie pamięci podręczne jednocześnie, a zmienna środowiskowa SYNAPSE_CACHE_FACTOR ustawia ten sam parametr. Zwiększenie tej wartości zużywa pamięć RAM, aby uniknąć zapytań do bazy danych. Zmniejszenie jej zużywa czas procesora i Postgres, aby zaoszczędzić pamięć RAM. Postgres wymaga własnej pamięci, więc na maszynie z 2 GB RAM oba procesy rywalizują o te same megabajty.

Dwie praktyczne zasady dla małego planu. Dodaj swap: swap nie sprawi, że Synapse będzie działać szybko, ale zapobiegnie zabiciu procesu przez jądro systemu podczas dołączania do dużego pokoju. Następnie monitoruj dysk od pierwszego tygodnia, ponieważ dwie rzeczy, które rosną bez limitu, to magazyn mediów i tabele stanu pokoi, a obie znajdują się na dysku.

Dlaczego Postgres i dlaczego SQLite przestaje być opcją

Pakiet Debian domyślnie korzysta z SQLite. Jest to akceptowalne przy pierwszym uruchomieniu, ale nieodpowiednie dla serwera używanego przez inne osoby. SQLite pozwala na zapis tylko jednego procesu w danym momencie. Ruch federacyjny oraz żądania klientów zapisują dane jednocześnie, przez co szybkie żądanie czeka w kolejce za wolniejszym, a użytkownicy zgłaszają, że aplikacja losowo zawiesza się na kilka sekund.

Drugi powód ma charakter strukturalny. Procesy robocze (worker processes) Synapse są wspieranym sposobem wykorzystania więcej niż jednego rdzenia procesora, a wymagają one Postgres. Pozostanie przy SQLite zamyka drogę do aktualizacji oraz ogranicza wydajność.

Późniejsza migracja jest wspierana, ale wiąże się z przestojem, dlatego należy ją przeprowadzić przed udostępnieniem usługi użytkownikom. Synapse dostarcza synapse_port_db, narzędzie kopiujące bazę danych SQLite do przygotowanej bazy Postgres:

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

Jeśli wolisz uruchomić bazę danych w kontenerze obok Synapse, wady i zalety tego rozwiązania opisano w uruchamianiu bazy danych w Dockerze lub na hoście.

Instalacja Synapse na 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

W systemie Ubuntu 24.04 polecenie lsb_release -cs zwraca noble, a repozytorium matrix.org udostępnia pakiet noble. Nie należy korzystać z pakietu matrix-synapse pochodzącego z oficjalnego archiwum Ubuntu. Projekt Synapse odradza to rozwiązanie, ponieważ te wersje są opóźnione względem oficjalnych wydań i zawierają znane luki bezpieczeństwa.

Instalator wymaga podania nazwy serwera, która zostaje zapisana w pliku /etc/matrix-synapse/conf.d/server_name.yaml. Należy odpowiedzieć na to pytanie rozważnie. server_name to część identyfikatora użytkownika znajdująca się po dwukropku (@alice:example.com); jest ona również zawarta w każdym pokoju utworzonym przez serwer. Późniejsza zmiana tej wartości nie przenosi danych: tworzy ona nowy homeserver. Należy użyć samej domeny, example.com, nawet jeśli Synapse będzie działać pod adresem matrix.example.com. Delegacja łączy te dwa elementy, co zostało opisane w kolejnej sekcji.

Pakiet uruchamia Synapse jako użytkownik matrix-synapse, przechowuje dane w /var/lib/matrix-synapse i odczytuje plik /etc/matrix-synapse/homeserver.yaml oraz wszystkie pliki w /etc/matrix-synapse/conf.d/. Własne ustawienia należy umieszczać w małych plikach wewnątrz conf.d. Aktualizacje pakietu nie modyfikują tych plików.

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

Poprawny start usługi inicjuje procesy nasłuchujące, po czym usługa przechodzi w stan oczekiwania. Jednostka systemd restartuje usługę kilka sekund po każdym jej wyjściu, więc konfiguracja odrzucona przez Synapse objawia się jako jednostka, która uruchamia się i wyłącza w pętli. Ostatnie linie dziennika wskazują klucz, który został odrzucony.

Konfiguracja Synapse z 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

Ustawienia regionalne (locale) nie są kwestią kosmetyczną. Synapse odmawia uruchomienia z bazą danych utworzoną przy użyciu innych wartości COLLATE oraz CTYPE, chyba że w konfiguracji bazy danych zostanie ustawione allow_unsafe_locale. Udokumentowana procedura naprawcza w takim przypadku wymaga wykonania zrzutu danych i ponownego zaimportowania ich do poprawnie utworzonej bazy. Należy utworzyć ją poprawnie za pierwszym razem.

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

Należy zachować dokładnie jeden klucz database: we wszystkich plikach konfiguracyjnych. Należy zastąpić blok SQLite wewnątrz homeserver.yaml zamiast dodawać drugą kopię w conf.d, aby uniknąć niejasności co do tego, która konfiguracja jest aktywna. Po restarcie należy zweryfikować, czy Synapse faktycznie korzysta z Postgres:

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

Liczba oznacza, że Synapse utworzyło swój schemat w tej bazie danych. Błąd dotyczący brakującej relacji oznacza, że usługa nadal zapisuje dane do pliku SQLite, co świadczy o tym, że edytowany plik konfiguracyjny nie jest tym, który jest odczytywany przez aplikację.

Reverse proxy, TLS oraz wymagania federacyjne dla plików .well-known

Synapse nasłuchuje na zwykłym HTTP na porcie 8008, powiązanym z localhost. Obsługa TLS oraz publiczny port należą do reverse proxy działającego przed nim.

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 instruuje Synapse, aby ufało nagłówkowi X-Forwarded-For ustawianemu przez proxy. Bez tego każdy klient jest widziany jako połączenie z 127.0.0.1, przez co mechanizm rate limiting traktuje wszystkich użytkowników jako jednego intensywnie działającego klienta lokalnego i blokuje ruch dla wszystkich.

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

Dokumentacja Synapse zawiera ostrzeżenie dotyczące tego bloku, którego zignorowanie kosztuje użytkowników wiele dni pracy. Nie należy dodawać ścieżki, nawet pojedynczego /, po numerze portu w proxy_pass. W przeciwnym razie nginx kanonizuje URI, co zmienia bajty podpisane przez serwer wysyłający, a żądania federacyjne kończą się niepowodzeniem weryfikacji podpisu, podczas gdy zwykłe żądania klientów działają poprawnie.

Wartość client_max_body_size musi być co najmniej tak duża jak max_upload_size w Synapse. Jeśli nginx posiada mniejszą wartość, przesyłane pliki przekraczające ten limit są odrzucane przez nginx z błędem 413 Request Entity Too Large, zanim dotrą do Synapse, przez co w dzienniku Synapse nie pojawia się żaden wpis wyjaśniający przyczynę niepowodzenia.

W kwestii samego certyfikatu należy postępować zgodnie z instrukcją Certbot i Let's Encrypt na Ubuntu 24.04. Jeśli wybór proxy pozostaje niejasny, porównanie reverse proxy wskazuje, które z nich automatyzuje obsługę TLS.

Delegacja pozwala na zachowanie domeny server_name jako example.com, podczas gdy Synapse działa na matrix.example.com. Należy udostępnić dwa pliki z poziomu domeny głównej:

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

Plik server informuje inne serwery domowe, gdzie kierować ruch federacyjny, co umożliwia działanie federacji przez port 443 zamiast domyślnego portu 8448. Plik client informuje klientów Matrix, który adres URL obsługuje @alice:example.com. Nagłówek Access-Control-Allow-Origin jest kluczowy w pliku client, ponieważ klienci przeglądarkowi pobierają go w ramach żądań cross-origin; bez tego nagłówka przeglądarka blokuje odpowiedź, a klient zgłasza błąd braku serwera domowego.

Oba pliki muszą być serwowane przez poprawne TLS z samej domeny example.com. Należy je zweryfikować, a następnie sprawdzić, co widzi świat zewnętrzny:

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

Pierwsze polecenie zwraca utworzony plik JSON. Drugie zwraca obiekt JSON z nazwą implementacji serwera i jej wersją, co potwierdza, że proxy poprawnie komunikuje się z Synapse na ścieżce federacyjnej. Następnie należy przetestować domenę za pomocą narzędzia Matrix federation tester pod adresem https://federationtester.matrix.org, które podąża tą samą ścieżką, co rzeczywisty serwer zdalny.

Federacja czy brak federacji: podejmij świadomą decyzję

Federacja stanowi istotę protokołu Matrix, ale generuje również większość kosztów utrzymania. Serwer domowy (homeserver) z włączoną federacją akceptuje połączenia z serwerów, o których administrator nigdy nie słyszał, odbiera ich zdarzenia, buforuje media oraz przechowuje stan każdego pokoju, do którego dołączyli użytkownicy. Jest to decyzja dotycząca modelu zagrożeń, a nie ustawienie domyślne.

Federację należy włączyć, gdy użytkownicy muszą komunikować się z osobami na innych serwerach lub gdy powodem wyboru Matrix jest przenośna tożsamość. Nie należy federować, jeśli serwer istnieje na potrzeby jednego zespołu, a wszystkie konta należą do administratora. Zamknięty serwer przechowuje mniej danych, odbiera mniej ruchu i jest znacznie mniej atrakcyjnym celem dla nadużyć.

Aby ograniczyć federację zamiast całkowicie ją wyłączać, Synapse obsługuje listę dozwolonych serwerów (allow list):

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

Dokumentacja zaleca również odizolowanie portu nasłuchującego federacji za pomocą firewalla, aby niechciany ruch był blokowany na poziomie sieci, a nie wewnątrz środowiska Python. Aby całkowicie wyłączyć federację, należy usunąć federation z listy resources nasłuchujących portów, nie publikować /.well-known/matrix/server i pozostawić port 8448 zamknięty.

Jeśli powodem uruchomienia Matrix był prywatny czat zespołowy, a federacja nigdy nie była częścią planu, warto porównać koszty utrzymania z innymi alternatywami dla Slacka z własnym hostingiem przed podjęciem decyzji o wyborze Synapse. Rocket.Chat na Docker Compose obsługuje czaty zespołowe na słabszych maszynach, ponieważ nie musi przechowywać stanu pokoi należących do innych organizacji.

Repozytorium mediów to element, który stopniowo zapełnia dysk

Pliki przesyłane przez użytkowników pozostają na dysku na stałe. Pliki publikowane przez użytkowników na innych serwerach domowych są pobierane i buforowane na dysku w momencie, gdy klient wyświetli je po raz pierwszy. Synapse generuje również miniatury obrazów, więc jedno zdjęcie zajmuje miejsce kilku plików. Domyślnie żadne z nich nie wygasa.

Zlokalizuj magazyn i sprawdź jego rozmiar:

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

Sprawdź ścieżkę wskazaną w konfiguracji. Pakiet Debian przechowuje dane Synapse w /var/lib/matrix-synapse, więc magazyn zazwyczaj znajduje się w tym miejscu. Następnie skonfiguruj politykę retencji w conf.d:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

Przeanalizuj uważnie te dwie linie, ponieważ dotyczą różnych ustawień. remote_media_lifetime usuwa elementy z pamięci podręcznej, a usunięte dane można ponownie pobrać z serwera źródłowego. local_media_lifetime trwale usuwa pliki przesłane przez własnych użytkowników po osiągnięciu określonego wieku. Zespół udostępniający dokumenty na czacie, który oczekuje dostępu do nich w kolejnym roku, utraci te dane. Wiele serwerów konfiguruje wyłącznie wartość dla mediów zdalnych.

W przypadku jednorazowego czyszczenia, API administratora przyjmuje znacznik czasu Unix w milisekundach:

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 usuwa buforowane media zdalne, do których ostatni dostęp miał miejsce przed podanym znacznikiem czasu. POST /_synapse/admin/v1/media/delete?before_ts=<ms> usuwa media lokalne zgodnie z tą samą zasadą. Najpierw wykonaj czyszczenie mediów zdalnych i ponownie sprawdź rozmiar, ponieważ na serwerze federacyjnym pamięć podręczna mediów zdalnych zazwyczaj zajmuje większą część przestrzeni.

Dwa ustawienia wpływają na ten sam dysk. max_upload_size ogranicza rozmiar pojedynczego przesyłanego pliku i musi być zgodne z client_max_body_size w nginx. url_preview_enabled: true sprawia, że serwer pobiera strony zdalne, aby klienci mogli wyświetlać podglądy linków, co zużywa pasmo i przechowuje miniatury treści, których nikt nie przesłał bezpośrednio na Twój serwer.

Zamknij rejestrację, zanim ktoś znajdzie Twój serwer domowy

Skanery znajdują otwarty serwer domowy w ciągu kilku dni. Gdy tworzenie kont jest ogólnodostępne, serwer staje się źródłem spamu w każdym pokoju, z którym się federuje, a administratorzy po drugiej stronie blokują całą domenę. Szkody w reputacji trwają dłużej niż samo sprzątanie, ponieważ listy blokad są utrzymywane ręcznie.

Synapse jest domyślnie zamknięty. enable_registration ma wartość domyślną false, a registration_requires_token ma wartość domyślną false. Synapse odmawia również uruchomienia z włączoną rejestracją bez kroku weryfikacji, chyba że dodatkowo ustawisz enable_registration_without_verification: true. Ta odmowa jest celowa, więc nie włączaj tej opcji tylko po to, aby pozbyć się błędu przy starcie.

Twórz konta ręcznie:

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

Narzędzie pyta o nazwę użytkownika, hasło oraz o to, czy konto ma posiadać uprawnienia administratora serwera. Odczytuje ono registration_shared_secret z konfiguracji przekazanej za pomocą -c, więc jeśli zgłasza brak wspólnego sekretu (shared secret), wskaż -c plik, w którym jest on przechowywany.

Gdy ręczne tworzenie kont przestaje być skalowalne, rozwiązaniem pośrednim są tokeny rejestracyjne. Token to ciąg znaków, który nowy użytkownik musi podać podczas rejestracji, a każdy token może posiadać limit użyć:

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

Pomiń token w treści żądania, a Synapse wygeneruje token i zwróci go. GET /_synapse/admin/v1/registration_tokens wyświetla listę aktywnych tokenów. Oba wywołania wymagają tokena dostępu (access token) konta administratora serwera, który uzyskasz logując się jako administrator utworzony wcześniej.

Organizacja, która zarządza kontami w innym miejscu, może całkowicie pominąć lokalne hasła, ponieważ Synapse potrafi delegować logowanie do dostawcy OIDC (OpenID Connect), na przykład Authentik jako samodzielnie hostowany dostawca SSO. Dodawanie i usuwanie użytkowników odbywa się wtedy w jednym miejscu.

Kopia zapasowa umożliwiająca pełne odtworzenie serwera

Kopia zapasowa Synapse składa się z trzech elementów. Brak któregokolwiek z nich uniemożliwia przywrócenie użytecznego serwera.

• Baza danych Postgres, przechowująca wszystkie zdarzenia, konta oraz pokoje.
• Katalog media store, zawierający wszystkie przesłane pliki.
• /etc/matrix-synapse, gdzie znajduje się konfiguracja oraz klucz podpisywania serwera.

Klucz podpisywania jest elementem najczęściej pomijanym. Jest to klucz prywatny, którym homeserver podpisuje zdarzenia, a serwery zdalne weryfikują je za pomocą odpowiadającego mu klucza publicznego. Uruchom grep signing_key_path /etc/matrix-synapse/homeserver.yaml, aby sprawdzić lokalizację tego pliku. Utrata klucza oznacza przywrócenie serwera, który nie jest w stanie udowodnić, że jest tą samą jednostką, którą znają już inne pokoje.

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

Najpierw wykonaj zrzut bazy danych, a następnie skopiuj media store. Pliki multimedialne są zapisywane jednokrotnie i odwoływane przez ID, więc kopia media store wykonana po zrzucie bazy może zawierać jedynie dodatkowe pliki, nigdy brakujące. Odwrotna kolejność może doprowadzić do sytuacji, w której przywrócona baza danych wskazuje na plik, którego kopia zapasowa nie zarejestrowała.

Prześlij wszystkie trzy elementy poza VPS. restic z migawkami zewnętrznymi dobrze sprawdza się w tym modelu, ponieważ media store stanowi większą część danych i zmienia się nieznacznie między uruchomieniami, a deduplikacja pozwala zachować niewielki rozmiar każdej migawki.

Następnie przeprowadź próbne przywracanie, ponieważ kopia zapasowa, której nigdy nie przywrócono, jest jedynie hipotezą. Skonfiguruj drugi VPS, zainstaluj ten sam pakiet, przywróć konfigurację, utwórz bazę danych z tym samym kodowaniem i ustawieniami regionalnymi (locale), wczytaj zrzut za pomocą pg_restore, skopiuj z powrotem media store i zaloguj się. Zapisz czas trwania tej operacji. Ta wartość to rzeczywisty czas odzyskiwania danych.

Gdy tabele stanu rosną: kompaktowanie

Synapse przechowuje stan pokoi w grupach stanu, a na serwerze federacyjnym state_groups_state często staje się największym obiektem w bazie danych. Przed wprowadzeniem jakichkolwiek zmian należy wykonać pomiary:

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

Jeśli ta tabela stanowi większość bazy danych, projekt udostępnia narzędzie do jej kompresji, rust-synapse-compress-state, które przepisuje hierarchię grup stanu na mniejszą liczbę wierszy bez zmiany znaczenia stanu jakiegokolwiek pokoju. Narzędzie zostało napisane w języku 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 określa, na ilu grupach stanu narzędzie pracuje jednocześnie, a -n to liczba takich porcji przetwarzanych w jednym przebiegu. Automatyczny kompresor zapisuje postęp, dzięki czemu kolejne uruchomienie kontynuuje pracę od tego samego miejsca, co pozwala na bezpieczne planowanie zadań. Dokumentacja wskazuje, że zmiany są stosowane w transakcjach na tabelach typu append-only, więc proces może działać podczas pracy Synapse. Mimo to, przed pierwszym uruchomieniem należy wykonać kopię zapasową bazy danych.

Jeden szczegół dotyczący Postgres zaskakuje użytkowników. Usuwanie wierszy zwraca miejsce do ponownego wykorzystania przez Postgres, a nie do systemu plików, więc df może w ogóle nie zmienić rozmiaru po dużej kompaktacji. VACUUM FULL zwraca miejsce do systemu, jednak wymaga wyłącznej blokady tabeli oraz wolnego miejsca na dysku w przybliżeniu równego rozmiarowi tabeli, dlatego należy zaplanować to jako czynność serwisową, zamiast uruchamiać ją doraźnie.

Kontrole stanu serwera

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

Stan zdrowy oznacza, że jednostka jest aktywna i nie restartuje się, plik delegacji zwraca wartość m.server, punkt końcowy wersji federacji zwraca format JSON, a dwie wartości rozmiaru można porównać z danymi z poprzedniego miesiąca. Rozmiary to kontrola, którą użytkownicy często pomijają, a zapełnienie dysku to awaria, która wyłącza serwer Synapse bez ostrzeżenia: pełny wolumen uniemożliwia zapis w Postgres, co powoduje, że Synapse odrzuca każde żądanie wymagające dostępu do bazy danych.

FAQ

Ile pamięci RAM wymaga serwer Matrix Synapse?

W przypadku prywatnego serwera domowego z kilkoma użytkownikami, małymi pokojami i brakiem dużych pokoi publicznych, 2 GB pamięci jest wartością wystarczającą; jest to również zalecenie większości publikowanych poradników dotyczących doboru zasobów na sierpień 2026. Dokumentacja Synapse wymaga co najmniej 1 GB wolnej pamięci RAM ponad standardowe zapotrzebowanie, jeśli użytkownicy dołączają do dużych pokoi publicznych, takich jak #matrix:matrix.org, ponieważ serwer przechowuje wtedy stan pokoju i stale przetwarza jego ruch. W planach z 2 GB pamięci należy dodać swap, aby nagłe dołączenie do dużego pokoju nie spowodowało zabicia procesu przez jądro systemu.

Czy muszę używać PostgreSQL zamiast SQLite?

Przy większej liczbie użytkowników – tak. SQLite pozwala tylko na jednego piszącego jednocześnie, więc ruch federacyjny i żądania klientów blokują się nawzajem pod obciążeniem, co powoduje zawieszanie się żądań na kilka sekund. Procesy robocze Synapse, czyli wspierany sposób wykorzystania więcej niż jednego rdzenia procesora, wymagają Postgres. Migracja w późniejszym terminie jest możliwa przy użyciu synapse_port_db i wiąże się z przestojem, dlatego bazę danych należy utworzyć za pomocą --encoding=UTF8 --locale=C --template=template0, zanim pojawią się użytkownicy.

Dlaczego zużycie dysku przez Synapse stale rośnie?

Przyczyną jest jeden katalog i jedna tabela. Magazyn mediów przechowuje każdy plik przesłany do pokoi, w których znajduje się serwer, w tym kopie podręczne mediów użytkowników zewnętrznych oraz wygenerowane miniatury; pliki te nie wygasają, dopóki nie zostanie skonfigurowane media_retention. Tabela state_groups_state rośnie wraz ze stanem pokoi na serwerze federacyjnym, a rust-synapse-compress-state pozwala na jej zmniejszenie. Przed podjęciem działań należy zmierzyć oba parametry za pomocą du -sh na media_store_path oraz przy użyciu SELECT pg_size_pretty(pg_total_relation_size('state_groups_state'));.

Jak zablokować rejestrację nieznajomych na moim serwerze domowym?

Pozostaw enable_registration z domyślną wartością false i twórz konta za pomocą register_new_matrix_user. Gdy to rozwiązanie przestanie wystarczać, ustaw enable_registration: true wraz z registration_requires_token: true i udostępniaj tokeny wygenerowane przez POST /_synapse/admin/v1/registration_tokens/new. Nie ustawiaj enable_registration_without_verification: true tylko po to, aby wyciszyć ostrzeżenie Synapse przy starcie, ponieważ otwarty serwer domowy staje się źródłem spamu, a inni administratorzy zareagują zablokowaniem całej domeny.

Czy mój serwer domowy powinien federować?

Federacja to decyzja dotycząca ekspozycji, a nie ustawienie domyślne. Federuj, jeśli użytkownicy muszą kontaktować się z osobami na innych serwerach domowych. Wyłącz tę funkcję, jeśli serwer obsługuje jeden zespół, ponieważ serwer niebędący w federacji przechowuje mniej danych, odbiera mniej ruchu i przyciąga znacznie mniej nadużyć. W sytuacjach pośrednich federation_domain_whitelist ogranicza federację do wskazanych domen partnerskich, a dokumentacja Synapse zaleca również zabezpieczenie firewallem portu nasłuchującego federacji, zamiast polegania wyłącznie na weryfikacji na poziomie aplikacji.