Konfiguracja własnego serwera Matrix do bezpiecznej i prywatnej komunikacji w rodzinie

WhatsApp, Messenger czy Telegram są wygodne, dopóki godzimy się na cudzą infrastrukturę, cudze zasady i konto, które może zostać zablokowane bez wpływu użytkownika. Własny serwer Matrix zmienia ten układ: rodzina nadal korzysta z wygodnej aplikacji na telefonie, ale konta, historia synchronizacji, pliki i konfiguracja serwera znajdują się pod kontrolą administratora.

Nie oznacza to jednak pełnej anonimowości ani systemu „nie do złamania”. Matrix nie ukryje adresu IP serwera przed dostawcą hostingu, nie zastąpi rozsądnego zarządzania telefonami i nie ochroni rozmów, jeśli ktoś pozna kod odblokowania urządzenia. Dobrze skonfigurowany serwer daje coś bardziej konkretnego: kontrolę nad kontami, metadanymi przechowywanymi lokalnie, dostępem do usługi i sposobem wykonywania kopii zapasowych.

Dla rodziny liczącej od kilku do kilkunastu osób rozsądny punkt startowy to:

• VPS z 2 rdzeniami vCPU, 4 GB RAM i 40–80 GB SSD,
• system Debian 13 lub aktualne Ubuntu LTS,
• własna domena,
• Synapse uruchomiony w Dockerze,
• baza PostgreSQL,
• reverse proxy Caddy albo Nginx,
• zamknięta rejestracja użytkowników,
• automatyczne kopie bazy oraz katalogu multimediów,
• osobny serwer TURN do stabilnych połączeń głosowych i wideo.

Sam komunikator można uruchomić w jeden wieczór. Serwer, któremu rzeczywiście można powierzyć rodzinne rozmowy i zdjęcia, wymaga jeszcze testu odzyskiwania danych, aktualizacji oraz przemyślanego sposobu przekazywania kluczy odzyskiwania.

Serwer, domena i architektura: co przygotować przed instalacją

Najważniejszej decyzji nie podejmuje się w Dockerze, lecz przy wyborze nazwy serwera. Identyfikator użytkownika Matrix ma postać:

@anna:rodzina.example

Część po dwukropku wynika z ustawienia server_name. Dokumentacja Synapse ostrzega, że nazwy serwera nie da się później zwyczajnie zmienić. Migracja na inną domenę oznacza w praktyce tworzenie nowych kont i przenoszenie użytkowników między pokojami.

Dlatego nie warto używać przypadkowej darmowej subdomeny ani nazwy dostawcy VPS. Najlepiej kupić domenę, którą rodzina zamierza utrzymywać przez lata, na przykład:

• kowalscy.net,
• naszdom.eu,
• rodzina-nowak.pl.

Domena .pl kosztuje zazwyczaj około 50–150 zł rocznie przy odnowieniu, zależnie od rejestratora. Promocyjna cena pierwszego roku bywa symboliczna, lecz nie powinna decydować o wyborze. Liczy się cena odnowienia, możliwość włączenia DNSSEC, uwierzytelnianie dwuskładnikowe w panelu oraz szybki dostęp do rekordów DNS.

Dobry podział nazw wygląda tak:

• matrix.example.pl — Synapse, czyli serwer Matrix,
• chat.example.pl — opcjonalny Element Web,
• turn.example.pl — serwer TURN do rozmów.

Można użyć krótszego identyfikatora @anna:example.pl, mimo że Synapse działa pod matrix.example.pl. Wymaga to jednak poprawnego wystawienia plików delegacji /.well-known/matrix/server i /.well-known/matrix/client. Dla początkującego administratora prostsze jest przyjęcie server_name: matrix.example.pl. Identyfikatory będą dłuższe, ale liczba punktów awarii spadnie.

VPS: ile zasobów naprawdę potrzeba

Dla 5–15 aktywnych osób nie ma sensu kupować dużego serwera. Synapse uruchomiony jako jeden proces, PostgreSQL, Caddy i coturn powinny działać poprawnie na maszynie z:

• 2 vCPU,
• 4 GB RAM,
• 40 GB SSD jako minimum,
• publicznym IPv4 i IPv6,
• 1–5 TB transferu miesięcznie.

W połowie 2026 roku najtańsze europejskie VPS-y o takich parametrach kosztują zwykle około 6–12 euro miesięcznie plus VAT, czyli mniej więcej 30–65 zł brutto. Dla porównania, Hetzner oferuje w europejskich lokalizacjach instancje CX23 z 2 vCPU, 4 GB RAM i 40 GB dysku od około 6 euro miesięcznie netto. Oferta obejmuje 20 TB transferu, ale dodatkowy publiczny IPv4 może być rozliczany oddzielnie.

Nie schodziłbym do 1 GB RAM. Taki serwer może wystartować, lecz aktualizacja obrazu, generowanie miniaturek zdjęć albo większe zapytanie PostgreSQL szybko doprowadzi do użycia swapu i wyraźnych opóźnień. 4 GB RAM to praktyczne minimum, nie luksus.

Dysk zużywają przede wszystkim:

• zdjęcia i filmy,
• miniatury plików,
• lokalne kopie multimediów pobieranych ze sfederowanych serwerów,
• baza danych,
• logi i kopie zapasowe.

Jeżeli rodzina regularnie przesyła filmy z telefonów, 40 GB skończy się szybciej, niż sugeruje liczba użytkowników. Rozsądniejszy start to 80 GB, szczególnie gdy kopie zapasowe mają przez kilka dni pozostawać na tym samym VPS-ie. Trzeba jednak pamiętać, że kopia przechowywana wyłącznie obok danych źródłowych nie chroni przed awarią konta hostingowego ani usunięciem całej maszyny.

Federacja czy serwer zamknięty

Matrix został zaprojektowany jako protokół federacyjny. Serwer może wymieniać wiadomości z innymi serwerami, podobnie jak serwery pocztowe. Gdy rodzinna osoba dołączy do pokoju działającego na obcej instancji, część danych tego pokoju będzie synchronizowana między uczestniczącymi serwerami.

Dla rodzinnego wdrożenia są dwie sensowne strategie:

Federacja włączona

Pozwala rozmawiać z użytkownikami innych serwerów, korzystać z publicznych pokoi i zapraszać osoby spoza rodziny. Wymaga poprawnej konfiguracji DNS, TLS oraz endpointów federacyjnych. Synapse może obsługiwać federację na porcie 8448, ale dokumentacja rekomenduje wystawienie jej przez reverse proxy.

Federacja ograniczona lub wyłączona

Zmniejsza powierzchnię ataku i ogranicza pobieranie obcych multimediów. To dobry wybór, gdy serwer ma być wyłącznie prywatnym komunikatorem dla domowników. Ceną jest zamknięcie użytkowników w lokalnej wyspie — nie napiszą z konta rodzinnego do osoby na matrix.org.

Najgorsze rozwiązanie to pozostawienie pełnej federacji „bo tak jest domyślnie”, a następnie brak kontroli nad publicznymi pokojami i rosnącym cache’em multimediów. Decyzję trzeba podjąć przed zaproszeniem użytkowników.

Minimalna architektura

Praktyczny układ dla niewielkiej instalacji wygląda tak:

Internet → Caddy/Nginx → Synapse → PostgreSQL

Dodatkowo:

Klient Element → coturn → połączenie głosowe lub wideo

Reverse proxy nie jest dodatkiem kosmetycznym. Przyjmuje ruch HTTPS na porcie 443, zarządza certyfikatem TLS i przekazuje żądania do Synapse działającego na porcie wewnętrznym. Dokumentacja Synapse rekomenduje użycie Nginx, Apache, Caddy, HAProxy lub podobnego mechanizmu zamiast uruchamiania homeservera z uprawnieniami roota.

Caddy jest łatwiejszy do pierwszej instalacji, ponieważ sam uzyskuje i odnawia certyfikaty. Nginx daje większą kontrolę, ale wymaga osobnej konfiguracji Certbota. W obu przypadkach należy przetestować odnowienie certyfikatu, a nie tylko sprawdzić, czy pierwszy certyfikat został wystawiony. Certbot zwykle instaluje automatyczny timer odnowienia, który można zweryfikować przez systemctl list-timers i certbot renew --dry-run.

Instalacja Synapse krok po kroku i bezpieczna konfiguracja kont

Poniższa procedura zakłada świeży VPS z Debianem lub Ubuntu, dostęp przez SSH i domenę wskazującą na publiczny adres serwera.

Najpierw w DNS trzeba utworzyć:

• rekord A dla matrix.example.pl,
• rekord AAAA, jeżeli VPS ma IPv6,
• rekordy dla turn.example.pl, jeśli TURN działa na tej samej maszynie.

Po zmianie DNS należy sprawdzić:

dig +short matrix.example.pl A
dig +short matrix.example.pl AAAA

Instalacji nie rozpoczynamy, dopóki rekordy nie wskazują na właściwy VPS. W przeciwnym razie automatyczne wystawienie certyfikatu TLS zakończy się błędem.

Przygotowanie systemu

Po zalogowaniu przez SSH:

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y docker.io docker-compose-plugin ufw curl
sudo systemctl enable --now docker

Następnie tworzymy katalog projektu:

sudo mkdir -p /opt/matrix/{synapse,postgres,caddy}
sudo chown -R "$USER":"$USER" /opt/matrix
cd /opt/matrix

Przed dalszą pracą dobrze jest utworzyć osobne konto administracyjne bez logowania hasłem przez SSH. Logowanie użytkownika root oraz uwierzytelnianie hasłem należy wyłączyć dopiero po sprawdzeniu, że logowanie kluczem działa w drugim oknie terminala. Zbyt wczesna zmiana sshd_config to jeden z prostszych sposobów na odcięcie się od własnego serwera.

Generowanie konfiguracji Synapse

Oficjalny obraz Synapse jest publikowany jako matrixdotorg/synapse oraz ghcr.io/element-hq/synapse. Obraz uruchamia Synapse jako pojedynczy proces. Domyślnie korzysta z SQLite, ale producent zaleca zewnętrzny PostgreSQL do instalacji produkcyjnych. Obraz nie zawiera serwera TURN.

Konfigurację początkową generujemy poleceniem:

docker run --rm -it \
  -v /opt/matrix/synapse:/data \
  -e SYNAPSE_SERVER_NAME=matrix.example.pl \
  -e SYNAPSE_REPORT_STATS=no \
  matrixdotorg/synapse:latest generate

W pliku /opt/matrix/synapse/homeserver.yaml trzeba następnie ustawić co najmniej:

server_name: "matrix.example.pl"
public_baseurl: "https://matrix.example.pl/"

enable_registration: false

database:
  name: psycopg2
  args:
    user: synapse
    password: "DŁUGIE_LOSOWE_HASŁO"
    database: synapse
    host: postgres
    port: 5432
    cp_min: 5
    cp_max: 10

max_upload_size: 50M

url_preview_enabled: false

Hasło bazy można wygenerować:

openssl rand -base64 36

Nie należy używać w haśle wartości z przykładu ani własnego nazwiska. Plik homeserver.yaml zawiera sekrety i powinien mieć ograniczone prawa:

chmod 600 /opt/matrix/synapse/homeserver.yaml

Aktualne wydania Synapse wymagają PostgreSQL 14 lub nowszego; stare poradniki oparte na PostgreSQL 11–13 są już niewłaściwym punktem startowym.

Plik Docker Compose

Minimalny compose.yaml może wyglądać tak:

services:
  postgres:
    image: postgres:17
    restart: unless-stopped
    environment:
      POSTGRES_USER: synapse
      POSTGRES_PASSWORD: DŁUGIE_LOSOWE_HASŁO
      POSTGRES_DB: synapse
      POSTGRES_INITDB_ARGS: "--encoding=UTF8 --locale=C"
    volumes:
      - ./postgres:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U synapse"]
      interval: 10s
      timeout: 5s
      retries: 5

  synapse:
    image: matrixdotorg/synapse:latest
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    volumes:
      - ./synapse:/data
    expose:
      - "8008"

  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./caddy/Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    depends_on:
      - synapse

volumes:
  caddy_data:
  caddy_config:

Hasło w compose.yaml musi być identyczne z hasłem zapisanym w homeserver.yaml. Lepszą praktyką jest przeniesienie go do pliku .env z prawami 600, ale przy pierwszym wdrożeniu najważniejsze jest uniknięcie rozbieżności i przypadkowego opublikowania katalogu w repozytorium Git.

Plik /opt/matrix/caddy/Caddyfile:

matrix.example.pl {
    reverse_proxy synapse:8008
}

Po uruchomieniu:

cd /opt/matrix
docker compose config
docker compose up -d
docker compose ps
docker compose logs --tail=100 synapse

Polecenie docker compose config powinno zostać wykonane przed startem. Wykrywa błędy składni YAML, które inaczej wyglądają jak awaria kontenera.

Test API:

curl https://matrix.example.pl/_matrix/client/versions

Odpowiedź w formacie JSON oznacza, że klient może dotrzeć do Synapse. Sam zielony status kontenera nie wystarcza — serwer może działać lokalnie, a być niedostępny przez błędny DNS, proxy lub certyfikat.

Zapora sieciowa

Dla podstawowej instalacji:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Portu PostgreSQL 5432 nie należy wystawiać do internetu. W podanym układzie baza jest dostępna tylko w sieci Dockera.

Port 8448 również nie jest konieczny, jeżeli federacja została poprawnie skierowana przez reverse proxy na 443. Otwieranie każdego portu znalezionego w poradniku „na wszelki wypadek” psuje podstawową zaletę zapory.

Tworzenie kont bez publicznej rejestracji

Dla rodzinnego serwera ustawienie:

enable_registration: false

powinno pozostać wyłączone. Konta tworzy administrator:

docker compose exec synapse register_new_matrix_user \
  -c /data/homeserver.yaml \
  http://localhost:8008

Program poprosi o nazwę użytkownika, hasło oraz informację, czy konto ma mieć prawa administratora.

registration_shared_secret należy traktować jak hasło administratora. Osoba, która go pozna, może tworzyć konta — także administracyjne — nawet przy wyłączonej rejestracji publicznej.

Praktyczny model uprawnień jest prosty:

• jedno konto administracyjne używane wyłącznie do zarządzania,
• codzienne konto administratora bez uprawnień specjalnych,
• osobne konto dla każdego członka rodziny,
• brak wspólnego konta „rodzina”.

Wspólne konto wydaje się wygodne do momentu zgubienia telefonu. Nie da się wtedy jednoznacznie unieważnić tylko jednej osoby ani ustalić, które urządzenie wykonało operację.

Limity plików i podgląd linków

Domyślny limit pojedynczego pliku w Synapse wynosi 50 MB. Limit reverse proxy musi być co najmniej tak samo wysoki, inaczej klient otrzyma błąd mimo poprawnej konfiguracji homeservera.

Dla rodzinnego serwera rozsądne wartości to:

• 25–50 MB, gdy komunikator służy głównie do wiadomości i zdjęć,
• 100 MB, gdy często przesyłane są krótkie filmy lub dokumenty,
• więcej niż 100 MB dopiero po wdrożeniu limitów i monitorowania przestrzeni.

Nie ustawiałbym 1 GB tylko dlatego, że dysk ma 80 GB. Jedna osoba może wtedy przypadkowo wypełnić serwer kilkoma nagraniami.

Podgląd linków jest domyślnie wyłączony. Jego włączenie pozwala serwerowi samodzielnie pobierać wskazane strony. Bez prawidłowej listy blokowanych zakresów IP użytkownik mógłby zmusić Synapse do odpytywania usług dostępnych wyłącznie wewnątrz infrastruktury. Dokumentacja wymaga przy włączeniu podglądu jawnego zablokowania między innymi adresów loopback, prywatnych podsieci RFC1918 i adresów link-local.

Dla prywatnej rodziny najbezpieczniejsza decyzja na start brzmi: pozostawić podgląd linków wyłączony. Miniaturka strony nie jest warta dodatkowej powierzchni ataku, dopóki administrator nie rozumie konsekwencji SSRF.

Szyfrowanie, rozmowy głosowe, kopie zapasowe i bieżące utrzymanie

Uruchomienie Synapse kończy instalację techniczną, ale nie kończy wdrożenia. Najwięcej problemów w małych instalacjach pojawia się później: ktoś zmienia telefon, zapomina hasła, traci dostęp do zaszyfrowanej historii albo odkrywa, że połączenia głosowe nie działają poza domowym Wi-Fi.

Szyfrowanie end-to-end nie szyfruje wszystkiego

W pokoju z włączonym E2EE wiadomość jest szyfrowana na urządzeniu nadawcy i odszyfrowywana na urządzeniach odbiorców. Serwer przechowuje zaszyfrowaną treść i nie powinien znać zawartości rozmowy.

Serwer nadal może jednak widzieć lub przetwarzać część metadanych, między innymi:

• adresy IP łączących się urządzeń,
• czas połączeń i wysłania zdarzeń,
• identyfikatory kont i pokojów,
• członkostwo w pokojach,
• wielkość przesyłanych danych,
• informacje konieczne do routingu oraz synchronizacji.

Własny Matrix nie jest więc narzędziem do niewidzialności. Przenosi zaufanie z operatora masowego komunikatora na administratora rodziny i dostawcę hostingu.

Każdy ważny pokój rodzinny należy utworzyć jako szyfrowany od początku. W praktyce nie powinno się najpierw prowadzić rozmowy jawnej, a dopiero po tygodniu włączać szyfrowania. Dawne wiadomości pozostaną nieszyfrowane.

Weryfikacja urządzeń i klucz odzyskiwania

Po zalogowaniu na nowym telefonie Element poprosi o zweryfikowanie urządzenia. Najlepsza procedura to:

1. pozostawić zalogowany stary, zaufany telefon,
2. zalogować się na nowym urządzeniu,
3. uruchomić weryfikację kodem QR lub porównaniem emoji,
4. dopiero po poprawnej weryfikacji wylogować stare urządzenie,
5. sprawdzić dostęp do starszych zaszyfrowanych wiadomości.

Cross-signing pozwala zatwierdzić nowe urządzenie jako zaufane, a mechanizm kopii kluczy umożliwia odzyskanie kluczy wiadomości na kolejnym urządzeniu.

Każdy użytkownik powinien zapisać klucz odzyskiwania poza komunikatorem:

• w menedżerze haseł,
• na zaszyfrowanym pendrivie,
• ewentualnie jako papierowy wydruk w bezpiecznym miejscu.

Nie należy wysyłać klucza samemu sobie w pokoju Matrix. To odpowiednik trzymania zapasowego klucza do mieszkania po wewnętrznej stronie drzwi.

Administrator serwera nie może zagwarantować odzyskania zaszyfrowanej historii, jeśli użytkownik utraci wszystkie zweryfikowane urządzenia i klucz odzyskiwania. Kopia bazy Synapse nie zastępuje kopii kluczy E2EE. Serwer może odtworzyć zaszyfrowane wiadomości, ale bez właściwych kluczy urządzenie nadal ich nie odszyfruje.

TURN: dlaczego wiadomości działają, a rozmowy nie

Połączenie głosowe może działać podczas testu dwóch telefonów w tej samej sieci Wi-Fi, a przestać działać, gdy jedna osoba przełączy się na LTE. Przyczyną są NAT, zapory operatorów i brak bezpośredniej trasy między urządzeniami.

Do niezawodnych rozmów potrzebny jest TURN, na przykład coturn albo eturnal. Dokumentacja Synapse określa skonfigurowanie TURN jako wymagane dla niezawodnego routowania rozmów VoIP.

Minimalna instalacja coturn:

sudo apt install -y coturn

Przykładowe kluczowe ustawienia w /etc/turnserver.conf:

use-auth-secret
static-auth-secret=BARDZO_DLUGI_LOSOWY_SEKRET
realm=turn.example.pl
server-name=turn.example.pl

listening-port=3478
tls-listening-port=5349

fingerprint
no-multicast-peers
no-cli

Ten sam sekret wpisujemy do homeserver.yaml:

turn_uris:
  - "turn:turn.example.pl:3478?transport=udp"
  - "turn:turn.example.pl:3478?transport=tcp"
  - "turns:turn.example.pl:5349?transport=tcp"

turn_shared_secret: "BARDZO_DLUGI_LOSOWY_SEKRET"
turn_user_lifetime: 1h
turn_allow_guests: false

Należy również otworzyć:

• 3478/tcp,
• 3478/udp,
• 5349/tcp,
• zakres portów UDP używany do przekazywania mediów, na przykład 49160:49200/udp.

Wąski zakres kilkudziesięciu portów wystarczy dla niewielkiej rodziny, o ile jest zgodny z konfiguracją min-port i max-port w coturn. Po zmianie:

sudo systemctl restart coturn
sudo systemctl enable coturn
docker compose restart synapse

Test trzeba wykonać między dwoma różnymi sieciami, na przykład telefonem w domowym Wi-Fi i drugim telefonem przez transmisję komórkową. Test dwóch urządzeń podłączonych do tego samego routera daje fałszywe poczucie poprawnej konfiguracji.

Połączenia Matrix 2.0 i nowszych klientów mogą również korzystać z bardziej rozbudowanej infrastruktury MatrixRTC i LiveKit. Oficjalne demonstracyjne środowisko Element zawiera Synapse, Matrix Authentication Service, Element Call, LiveKit oraz dodatkowy serwis JWT, ale autorzy wprost zaznaczają, że projekt demonstracyjny nie jest przeznaczony do poważnej eksploatacji produkcyjnej. Dla rodzinnego serwera tekstowego nie należy wdrażać całego tego stosu pierwszego dnia. Najpierw stabilne wiadomości i klasyczny TURN; później, po realnym teście potrzeb, infrastruktura grupowych rozmów.

Kopie zapasowe: co zapisać

Kopia Synapse powinna obejmować:

• zrzut bazy PostgreSQL,
• katalog synapse, w tym homeserver.yaml i klucze podpisujące,
• katalog media_store,
• konfigurację reverse proxy,
• konfigurację TURN,
• plik Compose i .env,
• kopię informacji o DNS.

Dokumentacja Synapse podkreśla, że kopie mają chronić nie tylko przed awarią sprzętu, ale również przed uszkodzeniem danych, błędem administratora i problematyczną aktualizacją.

Przykładowy zrzut bazy:

mkdir -p /opt/backups/matrix

docker compose exec -T postgres \
  pg_dump -U synapse -Fc synapse \
  > /opt/backups/matrix/synapse-$(date +%F-%H%M).dump

Kopia konfiguracji i multimediów:

tar --exclude='homeserver.db' \
  -czf /opt/backups/matrix/files-$(date +%F-%H%M).tar.gz \
  /opt/matrix/synapse \
  /opt/matrix/caddy \
  /opt/matrix/compose.yaml

Pliki trzeba następnie przesłać poza VPS, na przykład przez restic do zgodnego z S3 storage’u, na domowy NAS albo na drugi serwer. Minimalny rozsądny harmonogram:

• baza danych: codziennie,
• konfiguracja: po każdej zmianie oraz codziennie,
• media: codziennie lub co 2–3 dni,
• przechowywanie: 7 kopii dziennych, 4 tygodniowe i 3 miesięczne.

Dla małego serwera z 20–50 GB danych zewnętrzny backup zwykle kosztuje kilka–kilkanaście złotych miesięcznie. Oszczędzanie tej kwoty przy serwerze przechowującym rodzinne zdjęcia jest źle ustawionym priorytetem.

Najważniejszy jest jednak test odtwarzania. Raz na kwartał należy uruchomić pustą instancję PostgreSQL, zaimportować zrzut i sprawdzić, czy:

• baza się odtwarza,
• Synapse startuje,
• konta istnieją,
• pokoje są widoczne,
• media można pobrać,
• klucz podpisujący serwera został zachowany.

Kopia, której nigdy nie odtworzono, jest tylko założeniem.

Retencja multimediów

Synapse może automatycznie usuwać nieużywane multimedia lokalne i cache plików pobranych z innych serwerów. Przykładowe ustawienie:

media_retention:
  local_media_lifetime: 365d
  remote_media_lifetime: 30d

Dokumentacja wskazuje, że bez ustawienia limitów media lokalne i zdalne nie są domyślnie usuwane na podstawie wieku. Przy czyszczeniu usuwany jest zarówno oryginał, jak i jego miniatury.

Na rodzinnym serwerze nie ustawiałbym krótkiej retencji dla plików lokalnych bez uzgodnienia z użytkownikami. Zdjęcie wysłane do pokoju może zniknąć z serwera, choć ktoś traktował rozmowę jak rodzinne archiwum. Lepsza kolejność działań:

1. najpierw alert na zajętość dysku,
2. potem ograniczenie rozmiaru przesyłanych plików,
3. następnie krótsza retencja cache’u z federacji,
4. dopiero na końcu automatyczne usuwanie lokalnych multimediów.

Aktualizacje bez ruletki

Nie należy automatycznie pobierać obrazu latest i restartować produkcyjnego serwera każdej nocy. Aktualizacja może zawierać migrację bazy, nowe wymagania PostgreSQL albo zmianę konfiguracji.

Bezpieczna procedura:

1. wykonać kopię bazy i konfiguracji,
2. sprawdzić instrukcję aktualizacji Synapse,
3. zanotować aktualną wersję obrazu,
4. pobrać nową wersję,
5. uruchomić aktualizację,
6. sprawdzić logi, logowanie i wysyłanie wiadomości,
7. sprawdzić połączenie głosowe,
8. pozostawić poprzedni tag obrazu zapisany na wypadek wycofania.

Polecenia:

docker compose exec synapse python -m synapse.app.homeserver --version
docker compose pull
docker compose up -d
docker compose logs --tail=200 synapse

W pliku Compose lepiej przypinać konkretny stabilny tag, na przykład matrixdotorg/synapse:v1.x.y, niż stale używać latest. Zmianę wersji wykonuje się wtedy świadomie, a konfiguracja jasno pokazuje, co działa na serwerze.

Nie wolno jednak zakładać, że cofnięcie samego obrazu cofnie migrację bazy. Po aktualizacji zmieniającej schemat jedyną bezpieczną drogą powrotu może być odtworzenie kopii PostgreSQL.

Monitoring, który wystarczy rodzinie

Pełny Prometheus i Grafana są przydatne, ale dla siedmiu użytkowników zwykle stanowią większe obciążenie administracyjne niż sam komunikator. Najpierw warto monitorować cztery rzeczy:

df -h
free -h
docker compose ps
docker compose logs --since=24h synapse

Do tego należy ustawić:

• alert przy zajęciu 80 proc. dysku,
• zewnętrzny test HTTPS co 5 minut,
• powiadomienie o nieudanej kopii,
• miesięczny przegląd aktualizacji systemu i kontenerów.

Najbardziej dokuczliwa cecha własnego Matrixa nie dotyczy interfejsu. To konieczność regularnej administracji. Jeżeli nikt w rodzinie nie zamierza sprawdzać kopii, aktualizować serwera i reagować na pełny dysk, płatna zarządzana usługa Matrix będzie bezpieczniejsza niż zaniedbany VPS.

FAQ: najczęstsze pytania o rodzinny serwer Matrix

Czy administrator własnego serwera może czytać zaszyfrowane wiadomości?
Nie z samej bazy Synapse. Treść pokoju z prawidłowo włączonym E2EE jest szyfrowana na urządzeniach. Administrator nadal ma dostęp do metadanych serwerowych i może przejąć konto lub urządzenie przy błędnym zarządzaniu bezpieczeństwem, dlatego konto administratora oraz SSH wymagają osobnej ochrony.

Czy Matrix jest całkowicie darmowy?
Oprogramowanie jest open source, ale infrastruktura kosztuje. Dla małej rodziny trzeba przyjąć około 35–80 zł miesięcznie za VPS i zewnętrzny backup oraz mniej więcej 50–150 zł rocznie za domenę. Domowy serwer obniża rachunek za VPS, lecz dodaje koszt energii, awarii łącza i publicznego dostępu.

Czy można uruchomić Matrix na Raspberry Pi lub NAS-ie?
Tak, lecz nie jest to najlepszy pierwszy serwer dla rodziny. Problemem zwykle nie jest wydajność, ale brak stałego publicznego adresu, CGNAT, awarie prądu, kopie zapasowe i wystawienie TURN. Raspberry Pi z 4–8 GB RAM oraz dyskiem SSD działa znacznie lepiej niż model uruchomiony z karty microSD.

Czy do działania Matrixa potrzebny jest publiczny adres IPv4?
Nie bezwzględnie, lecz znacznie upraszcza konfigurację klientów, federacji i TURN. Serwer IPv6-only może działać, ale część sieci użytkowników nadal ma słabą obsługę IPv6. VPS z IPv4 i IPv6 jest bezpieczniejszym wyborem operacyjnym.

Czy można pozostawić otwartą rejestrację?
Technicznie tak, lecz na prywatnym serwerze rodzinnym nie ma ku temu dobrego powodu. Otwarta rejestracja przyciąga spam, automatyczne konta i zużycie zasobów. Konta należy tworzyć ręcznie albo wdrożyć rejestrację z zaproszeniami i dodatkowym uwierzytelnianiem.

Czy kopia serwera odzyska zaszyfrowaną historię po utracie telefonu?
Nie zawsze. Backup przywróci zaszyfrowane zdarzenia, ale użytkownik potrzebuje jeszcze kluczy E2EE: zweryfikowanego urządzenia, kopii kluczy oraz klucza odzyskiwania. Bez nich wiadomości mogą pozostać nieczytelne mimo kompletnej bazy.

Czy warto włączać federację?
Tak, jeśli użytkownicy mają rozmawiać z osobami na innych serwerach. Nie, jeśli Matrix ma pełnić rolę zamkniętego rodzinnego komunikatora. Federacja zwiększa funkcjonalność, ale również ruch, ilość przechowywanych danych i liczbę zewnętrznych systemów uczestniczących w pokojach.

Czy potrzebny jest własny Element Web?
Nie. Użytkownicy mogą korzystać z aplikacji Element na Androidzie, iOS, Windowsie, macOS i Linuksie, podając adres własnego homeservera. Własny Element Web jest wygodny, ale tworzy kolejny komponent do aktualizowania i zabezpieczania.

Co trzeba zrobić jako pierwsze po uruchomieniu serwera?
Nie zapraszać jeszcze całej rodziny. Najpierw utworzyć dwa testowe konta, włączyć szyfrowanie pokoju, zweryfikować urządzenia, wysłać plik, wykonać rozmowę między Wi-Fi i LTE, zrobić backup i odtworzyć bazę na próbnej instancji. Dopiero wtedy serwer jest gotowy do normalnego użycia.

Jaki błąd jest najgroźniejszy?
Brak sprawdzonej kopii bazy, konfiguracji i klucza podpisującego serwera. Pełny dysk można powiększyć, certyfikat odnowić, a błędny kontener wymienić. Utraty kluczowych plików i bazy po awarii VPS-a nie da się naprawić dokumentacją.