SSD Nodes Learn 🎉 VPS vanaf $5.50/mnd
Gidsen Matt ConnorDoor Matt Connor

Matrix Synapse zelf hosten op een VPS: de handleiding

Ontdek hoe u een Matrix Synapse homeserver stabiel houdt op een VPS. Leer alles over Postgres optimalisatie, media opschoning, registratiebeveiliging en betrouwbare back-ups.

Wat er nodig is om een Matrix Synapse homeserver in de lucht te houden

Matrix Synapse is eenvoudig te installeren, maar wordt ook snel verwaarloosd. De installatie bestaat uit één apt repository, één configuratiebestand, één reverse proxy-blok en één DNS-record. Het gedurende een jaar gezond houden van de homeserver vereist ander werk: een volwaardige database, een media store die wordt opgeschoond, registratie die niet toegankelijk is voor vreemden, en een back-up die beide helften van de server veiligstelt.

Deze handleiding richt zich op Ubuntu 24.04 LTS en installeert Synapse vanuit de matrix.org apt repository; dit is de pakketbron die het Synapse-project onderhoudt voor Debian en Ubuntu. Pakketversies wijzigen elke paar weken, daarom wordt hier geen versienummer genoemd. Elk pad en elke optie hieronder is afkomstig uit de actuele Synapse-documentatie.

Dimensionering: wat u daadwerkelijk krijgt met 1 vCPU en 2 GB RAM

Gepubliceerde pagina's over dimensionering, bijgewerkt tot augustus 2026, adviseren doorgaans 1 vCPU en 2 GB RAM voor een Synapse-homeserver. Dit is een eerlijk advies voor één scenario: een privéserver met enkele gebruikers, kleine ruimtes en geen drukke openbare ruimtes. De documentatie van Synapse is duidelijk over het andere scenario. Er wordt gevraagd om "minimaal 1 GB vrij RAM-geheugen als u wilt deelnemen aan grote openbare ruimtes zoals #matrix:matrix.org". Dit is vrij RAM-geheugen, bovenop wat Python, Postgres en de kernel verbruiken.

Eén ruimte kan uw dimensionering veranderen vanwege de manier waarop deelname werkt. Wanneer een lokale gebruiker deelneemt aan een ruimte, wordt uw homeserver een volledige deelnemer in die ruimte. De server ontvangt elk evenement van elke andere server in die ruimte, verifieert de handtekening van elk evenement en slaat de status van de ruimte lokaal op. Een grote openbare ruimte heeft duizenden leden verspreid over honderden servers, dus uw systeem voert dit werk continu uit, ongeacht of uw gebruiker de ruimte ooit nog opent. Het later verlaten van de ruimte verwijdert de geschiedenis die u al heeft opgeslagen niet.

Het meeste RAM-geheugen van Synapse wordt gebruikt voor caches. De caches-sectie bevat een global_factor die alle caches tegelijk schaalt, en de SYNAPSE_CACHE_FACTOR-omgevingsvariabele stelt hetzelfde in. Het verhogen hiervan verbruikt RAM om databasequery's te vermijden. Het verlagen ervan verbruikt CPU en Postgres-tijd om RAM te besparen. Postgres heeft zelf ook geheugen nodig, dus op een systeem met 2 GB concurreren beide om dezelfde megabytes.

Twee praktische regels voor een klein abonnement. Voeg swap toe: swap maakt Synapse niet snel, maar het voorkomt dat de kernel het proces beëindigt tijdens een grote deelname. Houd daarnaast vanaf de eerste week de schijfruimte in de gaten, omdat de twee zaken die onbeperkt groeien de media-opslag en de tabellen met ruimtestatussen zijn, en beide bevinden zich op de schijf.

Waarom Postgres, en waarom SQLite niet langer volstaat

Het Debian-pakket start standaard met SQLite. Dit is prima voor een eerste opstart, maar ongeschikt voor een server die door anderen wordt gebruikt. SQLite staat slechts één schrijfactie tegelijk toe. Federatieverkeer en clientverzoeken schrijven op hetzelfde moment, waardoor een eenvoudig verzoek moet wachten op een trager proces. Het symptoom dat uw gebruikers rapporteren is dat de applicatie willekeurig enkele seconden lijkt te hangen.

De tweede reden is structureel. De worker-processen van Synapse zijn de ondersteunde methode om meer dan één CPU-kern te benutten, en deze workers vereisen Postgres. Bij SQLite blijven betekent dat u zowel het upgradepad als de prestaties opgeeft.

Migreren op een later moment wordt ondersteund, maar dit vereist downtime. Voer de migratie daarom uit voordat u gebruikers heeft. Synapse levert synapse_port_db mee, waarmee een SQLite-database naar een voorbereide Postgres-database wordt gekopieerd:

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

Als u de database liever in een container naast Synapse draait, vindt u de afwegingen in het draaien van uw database in Docker of op de host.

Synapse installeren op 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

Op Ubuntu 24.04 print lsb_release -cs de waarde noble, en de matrix.org-repository publiceert een noble-suite. Gebruik niet het matrix-synapse-pakket uit het eigen archief van Ubuntu. Het Synapse-project verzoekt u dit niet te doen, omdat deze builds achterlopen op de releases en bekende beveiligingslekken bevatten.

Het installatieprogramma vraagt om een servernaam en schrijft het antwoord naar /etc/matrix-synapse/conf.d/server_name.yaml. Beantwoord dit zorgvuldig. server_name is het gedeelte na de dubbele punt in elke gebruikers-ID (@alice:example.com) en het is ingebed in elke kamer die uw server aanmaakt. Het later wijzigen hiervan verplaatst niets: het creëert een andere homeserver. Gebruik uw kale domein, example.com, zelfs wanneer Synapse zelf op matrix.example.com zal draaien. Delegatie verbindt de twee, en dat is het onderwerp van de volgende sectie.

Het pakket voert Synapse uit als de matrix-synapse-gebruiker, bewaart de data onder /var/lib/matrix-synapse, en leest /etc/matrix-synapse/homeserver.yaml gevolgd door elk bestand in /etc/matrix-synapse/conf.d/. Plaats uw eigen instellingen in kleine bestanden in conf.d. Upgrades van het pakket laten deze ongemoeid.

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

Een gezonde start brengt de listeners online en blijft daarna stil. De systemd-unit herstart de service enkele seconden na elke afsluiting, dus een configuratie die Synapse weigert, toont zich als een unit die in een lus opstart en weer stopt. De laatste regels van de journal benoemen de sleutel die werd geweigerd.

Synapse koppelen aan 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

De locale is niet louter cosmetisch. Synapse weigert te starten met een database die is aangemaakt met andere COLLATE- en CTYPE-waarden, tenzij u allow_unsafe_locale instelt in de databaseconfiguratie. De gedocumenteerde reparatiemethode achteraf is een dump en een herstel naar een correct aangemaakte database. Maak deze de eerste keer direct goed aan.

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

Behoud exact één database:-sleutel in al uw configuratiebestanden. Vervang het SQLite-blok binnen homeserver.yaml in plaats van een tweede kopie toe te voegen onder conf.d, zodat er nooit onduidelijkheid bestaat over welke configuratie actief is. Start opnieuw op en controleer vervolgens of Synapse daadwerkelijk op Postgres draait:

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

Een getal betekent dat Synapse het schema in deze database heeft opgebouwd. Een foutmelding over een ontbrekende relatie betekent dat er nog steeds naar het SQLite-bestand wordt geschreven; de configuratie die u heeft bewerkt, is dus niet degene die wordt ingelezen.

Reverse proxy, TLS en de behoeften voor .well-known-bestanden voor federatie

Synapse luistert op onversleuteld HTTP op poort 8008, gebonden aan localhost. TLS en de publieke poort behoren toe aan een reverse proxy die ervoor staat.

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 instrueert Synapse om de X-Forwarded-For-header die de proxy instelt te vertrouwen. Zonder deze instelling lijkt elke client afkomstig van 127.0.0.1, waardoor rate limiting één extreem actieve lokale gebruiker ziet en iedereen tegelijkertijd beperkt.

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

De Synapse-documentatie geeft één waarschuwing over dit blok die gebruikers dagen aan werk kan kosten. Voeg geen pad toe, zelfs geen enkele /, na de poort in proxy_pass. nginx normaliseert in dat geval de URI, wat de bytes verandert die de verzendende server heeft ondertekend. Hierdoor falen federatieverzoeken bij de verificatie van de handtekening, terwijl gewone clientverzoeken blijven werken.

client_max_body_size moet minstens zo groot zijn als de max_upload_size van Synapse. Als nginx het kleinere getal hanteert, worden uploads die daarboven liggen door nginx geweigerd met 413 Request Entity Too Large voordat Synapse ze ooit ziet; er is dan geen Synapse-logregel die de fout verklaart.

Volg voor het certificaat zelf Certbot en Let's Encrypt op Ubuntu 24.04. Als de keuze voor een proxy nog niet is gemaakt, behandelt de vergelijking van reverse proxies welke proxy het TLS-werk voor u uit handen neemt.

Delegatie is wat ervoor zorgt dat server_name gelijk blijft aan example.com terwijl Synapse draait op matrix.example.com. Serveer twee bestanden vanaf het hoofddomein:

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

Het serverbestand vertelt andere homeservers waar ze federatieverkeer naartoe moeten sturen; dit is hoe federatie over poort 443 verloopt in plaats van de standaardpoort 8448. Het clientbestand vertelt Matrix-clients welke URL de backend vormt voor @alice:example.com. De Access-Control-Allow-Origin-header is van belang bij het clientbestand omdat browsergebaseerde clients dit cross-origin ophalen; zonder deze header blokkeert de browser het antwoord en meldt de client dat deze uw homeserver niet kan vinden.

Beide bestanden moeten via geldige TLS worden geserveerd vanaf example.com zelf. Controleer ze en verifieer vervolgens wat de buitenwereld ziet:

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

Het eerste commando retourneert de JSON die u heeft geschreven. Het tweede retourneert een JSON-object met de serverimplementatie en de versie daarvan, wat bewijst dat de proxy Synapse bereikt via het federatiepad. Voer daarna het domein in bij de Matrix federation tester op https://federationtester.matrix.org, die dezelfde route volgt als een echte externe server.

Federeren of niet federeren: maak een bewuste keuze

Federatie is het bestaansrecht van Matrix, maar het is ook de grootste kostenpost. Een federerende homeserver accepteert verbindingen van servers waar u nog nooit van heeft gehoord, ontvangt hun events, slaat hun media op in de cache en bewaart de status voor elke kamer waar uw gebruikers bij betrokken zijn. Dit is een beslissing over het dreigingsmodel, geen standaardinstelling.

Federatie is zinvol wanneer uw gebruikers mensen op andere homeservers moeten kunnen bereiken, of wanneer een draagbare identiteit de reden is dat u voor Matrix heeft gekozen. Federatie is niet nodig wanneer de server voor één team is bedoeld en alle accounts van u zijn. Een gesloten server slaat minder op, ontvangt minder data en is een veel minder interessant doelwit voor misbruik.

Om federatie te beperken in plaats van uit te schakelen, gebruikt Synapse een allow list:

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

De documentatie raadt aan om ook de federatie-listener achter een firewall te plaatsen, zodat ongewenst verkeer bij het netwerk wordt tegengehouden in plaats van in Python. Om federatie volledig uit te schakelen, verwijdert u federation uit de listener resources lijst, publiceert u /.well-known/matrix/server niet en laat u poort 8448 gesloten.

Als de reden voor het draaien van Matrix een besloten teamchat was en federatie nooit onderdeel was van het plan, vergelijk dan de operationele kosten met andere zelfgehoste Slack-alternatieven voordat u zich vastlegt op Synapse. Rocket.Chat on Docker Compose faciliteert teamchat op een kleinere machine, omdat het nooit de kamerstatus van een andere organisatie hoeft op te slaan.

De media-repository is de bron van schijfgebruik

Bestanden die uw gebruikers uploaden, blijven permanent op uw schijf staan. Bestanden die door gebruikers op andere homeservers worden geplaatst, worden opgehaald en in de cache opgeslagen zodra een van uw clients deze weergeeft. Synapse genereert bovendien thumbnails voor afbeeldingen, waardoor één foto meerdere bestanden wordt. Standaard verloopt hiervan niets.

Zoek de opslaglocatie en meet het gebruik:

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

Meet het pad dat uw eigen configuratie aangeeft. Het Debian-pakket bewaart de data van Synapse onder /var/lib/matrix-synapse, dus de opslag bevindt zich doorgaans daar. Stel vervolgens een retentiebeleid in in conf.d:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

Lees deze twee regels zorgvuldig, aangezien het verschillende soorten instellingen zijn. remote_media_lifetime laat een cache verlopen; alles wat hiermee wordt verwijderd, kan opnieuw worden opgehaald van de server die het bestand bezit. local_media_lifetime verwijdert de uploads van uw eigen gebruikers permanent zodra deze de opgegeven leeftijd bereiken. Een team dat documenten deelt in een chat en verwacht deze volgend jaar nog terug te vinden, zal deze verliezen. Veel servers stellen alleen de waarde voor externe media in.

Voor een eenmalige opschoonactie accepteert de admin API een Unix-timestamp in milliseconden:

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 verwijdert gecachte externe media die voor die timestamp voor het laatst zijn benaderd. POST /_synapse/admin/v1/media/delete?before_ts=<ms> verwijdert lokale media volgens dezelfde regel. Voer eerst de opschoning van externe media uit en meet opnieuw, aangezien de externe cache op een federerende server meestal het grootste deel beslaat.

Twee instellingen beïnvloeden dezelfde schijf. max_upload_size begrenst een individuele upload en moet in lijn blijven met client_max_body_size in nginx. url_preview_enabled: true zorgt ervoor dat uw server externe pagina's ophaalt zodat clients link-previews kunnen tonen; dit verbruikt bandbreedte en slaat thumbnails op van content die niemand naar u heeft geüpload.

Sluit registratie voordat iemand uw thuisserver vindt

Scanners vinden een open thuisserver binnen enkele dagen. Zodra accounts vrij aan te maken zijn, wordt uw server een bron van spam in elke ruimte waarmee deze federatie onderhoudt, en blokkeren de beheerders aan de andere kant uw volledige domein. Die reputatieschade duurt langer dan het opschonen, omdat de blokkeerlijsten handmatig worden bijgehouden.

Synapse wordt standaard gesloten geleverd. enable_registration staat standaard op false en registration_requires_token staat standaard op false. Synapse weigert bovendien te starten met registratie ingeschakeld en zonder verificatiestap, tenzij u aanvullend enable_registration_without_verification: true instelt. Die weigering is bewust; schakel het dus niet in om een opstartfout te verhelpen.

Maak de gewenste accounts handmatig aan:

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

Er wordt gevraagd om de gebruikersnaam, het wachtwoord en of het account een serverbeheerder is. Het leest registration_shared_secret uit de configuratie die u meegeeft met -c. Als het meldt dat het een gedeeld geheim (shared secret) niet kan vinden, wijs -c dan naar het bestand waarin dit is opgeslagen.

Wanneer het handmatig aanmaken van accounts niet meer schaalt, zijn registratietokens de tussenoplossing. Een token is een tekenreeks die een nieuwe gebruiker moet opgeven tijdens de aanmelding, en elk token kan een limiet bevatten voor het aantal keer dat het bruikbaar is:

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

Laat token weg uit de body en Synapse genereert er een en geeft deze terug. GET /_synapse/admin/v1/registration_tokens toont de actieve tokens. Beide aanroepen vereisen het toegangstoken van een serverbeheerdersaccount, dat u verkrijgt door in te loggen als de beheerder die u hierboven heeft aangemaakt.

Een organisatie die elders al accounts beheert, kan lokale wachtwoorden volledig overslaan, omdat Synapse het inloggen kan delegeren aan een OIDC-provider (OpenID Connect), bijvoorbeeld Authentik als self-hosted SSO-provider. Nieuwe en vertrekkende gebruikers worden dan op één plek beheerd.

Een back-up waarmee u de server daadwerkelijk kunt herstellen

Een Synapse-back-up bestaat uit drie onderdelen. Als een back-up een van deze onderdelen mist, herstelt u een server die onbruikbaar is.

  • De Postgres-database, die alle events, accounts en rooms bevat.
  • De media store-map, die alle geüploade bestanden bevat.
  • /etc/matrix-synapse, die uw configuratie en de signing key van de server bevat.

De signing key is het onderdeel dat vaak wordt vergeten. Dit is de private key waarmee uw homeserver events ondertekent, en waartegen externe servers de events verifiëren met de bijbehorende public key. Voer grep signing_key_path /etc/matrix-synapse/homeserver.yaml uit om te zien waar deze zich bevindt. Als u deze verliest, herstelt u een server die niet kan bewijzen dat het dezelfde server is die uw rooms al kennen.

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

Maak eerst een dump van de database en kopieer daarna de media store. Mediabestanden worden eenmalig geschreven en via een ID gerefereerd. Een kopie van de media die na de dump wordt gemaakt, kan daarom alleen extra bestanden bevatten, maar nooit ontbrekende. De omgekeerde volgorde kan ertoe leiden dat de herstelde database verwijst naar een bestand dat nooit in uw back-up is opgenomen.

Verplaats alle drie de onderdelen van de VPS. restic met off-site snapshots sluit hier goed bij aan, omdat de media store het grootste deel is en nauwelijks verandert tussen back-ups. Deduplicatie houdt elke snapshot daardoor klein.

Oefen vervolgens het herstel, want een back-up die u nooit heeft teruggezet, is slechts een hypothese. Bouw een tweede VPS, installeer hetzelfde pakket, herstel de configuratie, maak de database aan met dezelfde encoding en locale, pg_restore de dump erin, kopieer de media store terug en log in. Noteer hoe lang dit proces duurde. Dat getal is uw werkelijke hersteltijd.

Wanneer de statustabellen groeien: compactie

Synapse slaat de status van kamers op als statusgroepen, en op een federerende server wordt state_groups_state vaak het grootste object in de database. Meet de situatie voordat u wijzigingen aanbrengt:

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

Als die ene tabel het grootste deel van uw database beslaat, publiceert het project een compressor hiervoor, rust-synapse-compress-state, die de hiërarchie van statusgroepen herschrijft naar minder rijen zonder de betekenis van de status van een kamer te wijzigen. Deze is gebouwd met 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 is het aantal statusgroepen waaraan tegelijkertijd wordt gewerkt en -n is het aantal van die brokken dat deze run verwerkt. De automatische compressor registreert hoe ver deze is gekomen, zodat de volgende run vanaf dat punt verdergaat; dit maakt het veilig om in te plannen. De documentatie vermeldt dat de wijzigingen in transacties worden toegepast op 'append-only' tabellen, waardoor het programma kan draaien terwijl Synapse actief is. Maak hoe dan ook een databaseback-up voordat u de eerste run uitvoert.

Eén detail van Postgres verrast mensen hier vaak. Het verwijderen van rijen geeft ruimte terug aan Postgres voor hergebruik, niet aan het bestandssysteem, dus df zal na een grote compactie mogelijk niet in grootte afnemen. VACUUM FULL geeft deze ruimte wel vrij, en dit vereist een exclusieve lock op de tabel plus vrije schijfruimte die ongeveer gelijk is aan de grootte van de tabel. Plan dit daarom in als onderhoud in plaats van het zomaar uit te voeren.

Controles die de status van de server verifiëren

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

Gezond betekent dat de unit actief is en niet herstart, het delegatiebestand uw m.server-waarde retourneert, het federatie-versie-eindpunt JSON retourneert en de twee groottegetallen vergeleken kunnen worden met die van vorige maand. De groottes zijn de controle die mensen vaak overslaan, en een volle schijf is de fout die een Synapse-server zonder waarschuwing platlegt: een vol volume voorkomt dat Postgres kan schrijven, waarna Synapse elk verzoek dat de database raadpleegt, afwijst.

FAQ

Hoeveel RAM heeft een Matrix Synapse-server nodig?

Voor een privé-homeserver met enkele gebruikers, kleine ruimtes en zonder grote openbare ruimtes is 2 GB werkbaar; dit is wat de meeste gepubliceerde richtlijnen per augustus 2026 aanbevelen. De Synapse-documentatie vereist minimaal 1 GB vrij RAM bovenop het overige gebruik als uw gebruikers lid worden van grote openbare ruimtes zoals #matrix:matrix.org, omdat uw server dan de status van die ruimte opslaat en het verkeer continu verwerkt. Voeg swap toe op een 2 GB-plan zodat één grote join-actie er niet voor zorgt dat het proces door de kernel wordt beëindigd.

Moet ik PostgreSQL gebruiken in plaats van SQLite?

Na een handvol gebruikers wel. SQLite staat slechts één schrijver tegelijk toe, waardoor federatieverkeer en clientverzoeken elkaar onder belasting blokkeren en verzoeken secondenlang blijven hangen. De worker-processen van Synapse, de ondersteunde manier om meer dan één CPU-kern te gebruiken, vereisen Postgres. Migreren op een later moment werkt met synapse_port_db en kost downtime, dus maak de database aan met --encoding=UTF8 --locale=C --template=template0 voordat u gebruikers heeft.

Waarom blijft het schijfgebruik van mijn Synapse-server groeien?

Dit komt door één map en één tabel. De media-opslag bewaart elk bestand dat is geüpload naar ruimtes waar uw server deel van uitmaakt, inclusief gecachte kopieën van media van externe gebruikers en gegenereerde thumbnails; niets verloopt totdat u media_retention instelt. De tabel state_groups_state groeit met de ruimtestatus op een federerende server, en rust-synapse-compress-state verkleint deze. Meet beide, met du -sh op uw media_store_path en met SELECT pg_size_pretty(pg_total_relation_size('state_groups_state'));, voordat u beslist waar u aan gaat werken.

Hoe voorkom ik dat vreemden zich registreren op mijn homeserver?

Laat enable_registration op de standaardwaarde false staan en maak accounts aan met register_new_matrix_user. Wanneer dat niet meer schaalt, stelt u enable_registration: true in samen met registration_requires_token: true, en deelt u tokens uit die zijn aangemaakt via POST /_synapse/admin/v1/registration_tokens/new. Stel enable_registration_without_verification: true niet in enkel om de weigering bij het opstarten van Synapse te omzeilen, want een open homeserver wordt een bron van spam en andere beheerders zullen reageren door uw volledige domein te blokkeren.

Moet mijn homeserver federeren?

Federatie is een beslissing over blootstelling, geen standaardinstelling. Federeer als uw gebruikers mensen op andere homeservers moeten kunnen bereiken. Houd het uitgeschakeld als de server één team bedient, omdat een niet-federerende server minder opslaat, minder ontvangt en aanzienlijk minder misbruik aantrekt. Daartussenin beperkt federation_domain_whitelist federatie tot benoemde partnerdomeinen, en de Synapse-documentatie raadt aan om ook de federatie-listener via een firewall te beveiligen in plaats van alleen op die controle op applicatieniveau te vertrouwen.

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