Oma Matrix-palvelin: Synapse, 12 Vaihetta, 90 Min [2026]

Ranskan hallinnon Tchap-sovelluksesta vuoti kesällä 2026 yli 73 000 virkamiehen tiedot, ja koko episodi nosti esiin saman kysymyksen ympäri Eurooppaa: kuka oikeasti hallinnoi viestintääsi, kun käytät valmista pilvipalvelua? Tchap rakennettiin Matrix-protokollan päälle, mutta murron syynä ei ollut itse protokolla vaan tapa, jolla palvelin oli pystytetty ja ylläpidetty. Se on juuri se ero, joka ratkaisee onnistuuko oma Matrix-asennus vai päädytkö samaan tilanteeseen.

Tässä oppaassa pystytämme toimivan Matrix-kotipalvelimen Synapse-ohjelmistolla omalle palvelimelle, alusta loppuun. Käymme läpi 12 konkreettista vaihetta: palvelimen valinnasta ja PostgreSQL-tietokannasta TLS-varmenteeseen, käänteisproxyyn, ensimmäisen käyttäjän luontiin ja Element Web -asiakkaan käyttöönottoon. Lopussa käsittelemme myös yleisimmät virheet, 8 vianmääritystilannetta ja muutaman edistyneemmän vinkin, joilla palvelin pysyy pystyssä myös silloin kun käyttäjämäärä kasvaa.

Opas sopii sekä yksittäiselle kehittäjälle että pienelle tiimille, joka haluaa oman viestintäkanavan ilman ulkopuolisen palveluntarjoajan lokitusta. Aikaa koko asennukseen kannattaa varata noin 90 minuuttia, jos DNS-tietueet ehtivät levitä matkan varrella ja komennot ajetaan järjestyksessä. Käytämme koko oppaassa esimerkkidomainia omadomain.fi ja alidomainia chat.omadomain.fi, jotka sinun tulee korvata omilla tiedoillasi jokaisessa komennossa ja konfiguraatiotiedostossa.

Emme käsittele tässä artikkelissa itse Element-mobiilisovelluksen kääntämistä lähdekoodista, koska valtaosa käyttäjistä asentaa sen suoraan sovelluskaupasta ja kirjautuu omalla palvelintunnuksellaan. Fokus on nimenomaan palvelinpuolen pystytyksessä, koska se on se osa, jossa suurin osa virheistä ja tietoturva-aukoista syntyy.

Miksi oma Matrix-palvelin kannattaa harkita juuri nyt

Matrix on avoin viestintäprotokolla, jonka päälle rakennettuja kotipalvelimia käyttävät jo useat Euroopan valtiot digitaalisen suvereniteetin nimissä. Elementin Euroopan-laaja katsaus listaa Suomen yhtenä maana, jossa on aktiivinen, luokiteltu Matrix-käyttöönotto julkishallinnossa, samaan tapaan kuin Norjassa ja useissa muissa Euroopan maissa. Yhtiön mukaan Matrix-pohjaisesta viestintäinfrastruktuurista keskustellaan tällä hetkellä noin 35 maan kanssa, ja projekti on laajentunut nichetuotteesta osaksi useiden hallitusten virallista viestintäketjua.

Julkisia yksityiskohtia suomalaisista käyttöönotoista on vielä vähän, joten emme väitä tässä artikkelissa tuntevamme tiettyä ministeriötä tai virastoa. Käytännön syy oman palvelimen pystyttämiseen on silti selvä: kun viestintä kulkee omalla laitteistolla, kukaan kolmas osapuoli ei näe metadataa, eikä palvelun sulkeminen tai hinnoittelumuutos ulkomaisessa pilvessä vaikuta sinuun. Sama logiikka koskee yrityksiä, yhdistyksiä ja yksittäisiä valveutuneita käyttäjiä, jotka haluavat saman salatun viestinnän tason kuin Signalissa, mutta ilman riippuvuutta yhdestä yrityksestä.

Sääntely-ympäristö tukee samaa suuntaa. EU:n keskusteltu viestien valvonta-asetus eli niin kutsuttu Chat Control jatkuu vuoteen 2028 asti, ja Signal vapautettiin lopullisesta versiosta erillisillä poikkeuksilla. Oma Matrix-palvelin ei tarvitse vastaavia poikkeuksia, koska hallinnoit itse sitä, mitä lokeja säilytät ja kuinka pitkään.

Kustannuspuoli on myös houkutteleva. Halvin VPS, jolla Synapse toimii mukavasti pienelle käyttäjäjoukolle, maksaa useimmilla eurooppalaisilla palveluntarjoajilla muutaman kympin kuukaudessa. Verrattuna kaupallisiin ryhmäviestintätuotteisiin, joissa hinta skaalautuu käyttäjämäärän mukaan, oma palvelin maksaa saman verran riippumatta siitä, onko käyttäjiä viisi vai viisikymmentä, kunnes laitteisto alkaa olla pullonkaula. Sama raha kattaa myös täyden hallinnan siihen, minne data fyysisesti tallentuu, mikä on usein ratkaiseva tekijä julkishallinnon ja terveydenhuollon kaltaisilla toimialoilla.

Käytännön esimerkkejä oman palvelimen tarpeesta löytyy useilta aloilta. Journalistiryhmä, joka käsittelee arkaluontoisia lähteitä, hyötyy siitä, ettei viestihistoria säily kolmannen osapuolen palvelimella. Kansalaisjärjestö, joka koordinoi työtä useassa maassa, saa yhden yhtenäisen viestintäkanavan ilman, että eri maiden lainsäädäntö vaikuttaa siihen, missä data sijaitsee. Ohjelmistotiimi taas voi liittää Matrix-huoneisiin botteja ja hälytyksiä suoraan omasta CI/CD-putkestaan Matrixin avoimen client-server-rajapinnan kautta, mikä ei onnistu yhtä joustavasti suljetuissa kaupallisissa palveluissa.

Matrix, Synapse, Conduit ja Dendrite: mitä eroa palvelinohjelmistoilla on

Matrix on itse protokolla, ei ohjelmisto. Kotipalvelimen (homeserver) voi toteuttaa usealla eri ohjelmistolla, ja valinta vaikuttaa suoraan siihen, kuinka paljon ylläpitoa palvelin vaatii. Synapse on projektin alkuperäinen ja yhä kypsin toteutus, ja Element käyttää sitä edelleen omien tuotteidensa perustana. Conduit ja sen haarautuma Conduwuit ovat kevyempiä Rust-pohjaisia vaihtoehtoja pienemmille asennuksille, kun taas Dendrite on toisen sukupolven palvelin, joka ei vielä tue kaikkia uusimpia ominaisuuksia, kuten yksinkertaistettua liukuvaa synkronointia (MSC4186) tai uuden sukupolven OIDC-kirjautumista.

Elokuussa 2026 julkaistu Matrix-ekosysteemin katsaus mittasi federoitavien palvelinten jakaumaa löydettyjen palvelinten joukossa: Synapse 78,1 %, Conduwuit 8,8 %, Conduit 2,7 % ja Dendrite 1,6 %. Luvut eivät kata koko federaatiota, mutta ne kuvaavat hyvin sitä, mihin uudet asennukset päätyvät käytännössä. Tässä oppaassa käytämme Synapsea, koska se on tuotantokäyttöön tarkoitetuille asennuksille yhä suositelluin reitti ja koska Element X -mobiilisovellus vaatii täyden Matrix 2.0 -yhteensopivuuden parhaan suorituskyvyn saamiseksi.

Käytännön eroa kannattaa katsoa myös ylläpitäjän näkökulmasta. Synapse on Python-pohjainen, ja sen konfiguraatio on dokumentoitu poikkeuksellisen kattavasti, koska Element itse ylläpitää sitä tuotteidensa taustalla. Conduwuit taas kirjoitettu Rustilla, joten se pyörii huomattavasti pienemmällä muistijalanjäljellä, mutta yhteisö ja kolmannen osapuolen työkalut ovat vielä ohuempia kuin Synapsen ympärillä. Jos tavoitteena on oppia asennuksesta mahdollisimman paljon ja pitää tulevaisuudessa ovi auki worker-arkkitehtuurille tai isommalle käyttäjämäärälle, Synapse on turvallisempi lähtökohta, vaikka se söisikin enemmän resursseja pienessä asennuksessa.

Palvelinohjelmisto	Kieli	Osuus löydetyistä palvelimista (elokuu 2026)	Sopii parhaiten
Synapse	Python	78,1 %	Tuotantokäyttö, isommat yhteisöt, Element X
Conduwuit	Rust	8,8 %	Kevyt tuotantoasennus, pienempi resurssitarve
Conduit	Rust	2,7 %	Kokeilu- ja harrastuskäyttö
Dendrite	Go	1,6 %	Testiympäristöt, ei vielä täyttä MSC-tukea

Esivaatimukset ennen asennusta

Ennen kuin avaat terminaalin, varmista että seuraavat asiat ovat kunnossa. Puutteellinen valmistelu on yleisin syy siihen, että Synapse-asennus jää kesken puolivälissä, ja moni näistä puutteista huomataan vasta silloin kun ensimmäinen komento epäonnistuu odottamattomalla virheellä.

• Palvelin, jossa on vähintään Ubuntu 24.04 LTS tai Debian 12, 2 vCPU ja 4 Gt RAM-muistia pienelle yhteisölle (alle 50 aktiivista käyttäjää)
• Oma verkkotunnus, jonka DNS-asetuksia voit muokata (esimerkiksi chat.omadomain.fi)
• Root- tai sudo-oikeudet palvelimella
• PostgreSQL 15 tai uudempi (Synapse tukee myös SQLite:tä, mutta se ei sovellu tuotantoon)
• Python 3.11 tai uudempi, jos asennat Synapsen pip-paketinhallinnalla ilman Dockeria
• Nginx tai Caddy käänteisproxyksi TLS-liikenteen purkuun
• Certbot tai vastaava ACME-asiakas Let’s Encrypt -varmenteita varten
• Vähintään 20 Gt levytilaa, enemmän jos suunnittelet paljon mediatiedostojen jakamista

Näistä vaatimuksista PostgreSQL on se, jonka moni yrittää ohittaa käyttämällä oletusarvoista SQLite-tietokantaa, koska se vaatii vähemmän alkuperehtymistä. Vaihto SQLite:stä PostgreSQL:ään jälkikäteen onnistuu Synapsen mukana tulevalla migraatioskriptillä, mutta se on hidas ja riskialtis operaatio, joten kannattaa säästää itsensä siltä ja asentaa PostgreSQL heti alusta alkaen. Sama koskee verkkotunnusta: server_name kirjoitetaan pysyvästi jokaiseen käyttäjätunnukseen ja huonetunnisteeseen, joten sen vaihtaminen jälkikäteen tarkoittaa käytännössä uutta palvelinta tyhjästä.

Synapsen uusin julkaisulinja vuoden 2026 puolivälissä liikkui 1.156–1.159-sarjan tienoilla, ja Element Server Suiten syyskuun 2026 julkaisumuistiinpanoissa mainittiin Synapse 1.156.0 pakattuna versiona. Tarkista aina asennushetken uusin vakaa versio virallisesta julkaisusivusta, sillä projekti julkaisee tietoturvakorjauksia tiuhaan tahtiin.

Kannattaa myös varata etukäteen sähköpostiosoite palvelimen ylläpitäjälle, koska Let’s Encrypt lähettää varmenteen vanhenemisesta muistutuksia sinne, jos automaattinen uusinta jostain syystä epäonnistuu. Jos aiot avata rekisteröitymisen julkisesti, mieti jo tässä vaiheessa, tarvitsetko sähköpostivarmennuksen vai captchan roskaviestien torjuntaan, sillä molemmat vaativat erillisen kolmannen osapuolen palvelun API-avaimen ennen kuin homeserver.yaml-tiedosto on lopullinen.

Vaihe 1–2: palvelimen tilaus ja DNS-tietueiden määritys

Tilaa ensin VPS-palvelin haluamaltasi palveluntarjoajalta. Suomalaisille käyttäjille latenssin kannalta järkevin valinta on Pohjoismaissa sijaitseva konesali. Kun palvelin on käynnissä, kirjaudu siihen SSH:lla ja siirry heti seuraavaan vaiheeseen: DNS-tietueiden asetukseen. Matrix tarvitsee kaksi tietuetta toimiakseen kunnolla.

• A-tietue: chat.omadomain.fi osoittaa palvelimesi IP-osoitteeseen
• SRV-tietue federointia varten, jos et halua avata porttia 8448 suoraan domainin juureen

# Esimerkki SRV-tietueesta DNS-hallintapaneeliin
_matrix._tcp.omadomain.fi. 3600 IN SRV 10 5 8448 chat.omadomain.fi.

DNS-muutosten leviäminen voi kestää muutamasta minuutista muutamaan tuntiin riippuen aiemmasta TTL-arvosta. Tarkista tilanne komennolla dig +short chat.omadomain.fi ennen kuin jatkat. Jos komento ei palauta mitään tai palauttaa vanhan IP-osoitteen, odota vielä hetki ja kokeile eri DNS-palvelimelta, esimerkiksi dig @1.1.1.1 +short chat.omadomain.fi, koska paikallinen resolveri saattaa yhä tarjota vanhaa vastausta välimuististaan.

Kannattaa myös miettää etukäteen, haluatko federoinnin lainkaan päälle. Jos palvelin on tarkoitettu vain sisäiseen käyttöön, voit jättää SRV-tietueen kokonaan tekemättä ja sulkea portin 8448 palomuurista. Federointi kannattaa ottaa käyttöön vasta sitten, kun perusasennus toimii moitteetta asiakkaiden välillä, koska se lisää yhden ylimääräisen muuttujan vianmääritykseen asennuksen alkuvaiheessa.

Vaihe 3–4: järjestelmän päivitys ja PostgreSQL-tietokanta

Päivitä järjestelmä ja asenna PostgreSQL ennen Synapsea. SQLite toimii demoissa, mutta tuotannossa se hidastuu nopeasti huoneiden ja käyttäjien määrän kasvaessa.

sudo apt update && sudo apt upgrade -y
sudo apt install -y postgresql postgresql-contrib python3-pip python3-venv \
  libpq-dev libffi-dev libssl-dev libjpeg-dev libxslt1-dev nginx certbot python3-certbot-nginx

Luo tämän jälkeen Synapselle oma tietokantakäyttäjä ja tietokanta oikealla merkistöllä. Synapse vaatii nimenomaan C-lokaalin ja UTF8-koodauksen, muuten migraatiot voivat epäonnistua myöhemmin.

sudo -u postgres psql -c "CREATE USER synapse_user PASSWORD 'vaihda_tama_salasana';"
sudo -u postgres psql -c "CREATE DATABASE synapse
  ENCODING 'UTF8'
  LC_COLLATE='C'
  LC_CTYPE='C'
  TEMPLATE=template0
  OWNER synapse_user;"

Odotettu tuloste molemmista komennoista on CREATE ROLE ja CREATE DATABASE. Jos näet sen sijaan virheen “role already exists”, olet ajanut komennon jo aiemmin, eikä se haittaa.

Kannattaa myös hienosäätää PostgreSQL:n oletusasetuksia hieman, koska oletusarvot on mitoitettu hyvin pienelle palvelimelle. Muokkaa tiedostoa /etc/postgresql/*/main/postgresql.conf ja nosta shared_buffers-arvo noin 25 prosenttiin palvelimen RAM-muistista sekä max_connections-arvo vähintään sataan, jos suunnittelet worker-prosesseja myöhemmin. Muutosten jälkeen tietokantapalvelu pitää käynnistää uudelleen komennolla sudo systemctl restart postgresql, jotta asetukset astuvat voimaan.

Vaihe 5–7: Synapsen asennus ja peruskonfigurointi

Asenna Synapse virtuaaliympäristöön, jotta se ei sotke järjestelmän Python-paketteja. Tämä on virallisen asennusoppaan suosittelema tapa Debian- ja Ubuntu-pohjaisille järjestelmille silloin, kun et käytä valmiita apt-paketteja tai Dockeria.

sudo mkdir -p /opt/synapse
sudo python3 -m venv /opt/synapse/env
sudo /opt/synapse/env/bin/pip install --upgrade pip
sudo /opt/synapse/env/bin/pip install matrix-synapse psycopg2

Kun asennus on valmis, generoi peruskonfiguraatio yhdellä komennolla. Se luo homeserver.yaml-tiedoston ja allekirjoitusavaimet valmiiksi.

cd /opt/synapse
sudo env/bin/python -m synapse.app.homeserver \
  --server-name chat.omadomain.fi \
  --config-path homeserver.yaml \
  --generate-config \
  --report-stats=no

Avaa sen jälkeen homeserver.yaml ja vaihda tietokanta-asetus SQLite:stä PostgreSQL:ään.

database:
  name: psycopg2
  args:
    user: synapse_user
    password: vaihda_tama_salasana
    database: synapse
    host: localhost
    cp_min: 5
    cp_max: 10

Muista myös asettaa registration_shared_secret, jos aiot luoda käyttäjiä komentoriviltä, sekä rajoittaa julkinen rekisteröityminen pois päältä (enable_registration: false), ellet nimenomaan halua avointa palvelinta koko internetille.

Kannattaa myös tarkistaa homeserver.yaml:sta lokitusasetukset ennen käynnistystä. Oletuskonfiguraatio kirjoittaa lokia sekä konsoliin että tiedostoon, mikä on hyödyllistä ensimmäisten päivien aikana vianmäärityksessä, mutta kannattaa vaihtaa hiljaisemmaksi tuotannossa, jotta levy ei täyty tarpeettomasta debug-tason lokituksesta viikkojen kuluessa. Muokkaa tätä varten erillistä chat.omadomain.fi.log.config-tiedostoa, jonka generointikomento loi samaan hakemistoon homeserver.yaml:n kanssa.

Vaihe 8: TLS-varmenteen hankinta Let’s Encryptilla

Matrix vaatii salatun HTTPS-yhteyden sekä asiakasliikenteelle että federoinnille. Certbot hoitaa varmenteen hankinnan ja uusinnan automaattisesti.

sudo certbot --nginx -d chat.omadomain.fi
sudo certbot renew --dry-run

Onnistunut ajo tulostaa rivin Congratulations! Your certificate and chain have been saved ja kertoo varmenteen sijainnin hakemistossa /etc/letsencrypt/live/chat.omadomain.fi/. Dry run -komento puolestaan varmistaa, että automaattinen uusinta toimii ilman että se kuluttaa Let’s Encryptin varsinaista rate limitiä.

Certbot asentaa oletuksena systemd-ajastimen, joka tarkistaa varmenteen voimassaolon kahdesti päivässä ja uusii sen automaattisesti noin 30 vuorokautta ennen vanhenemista. Voit varmistaa ajastimen tilan komennolla systemctl list-timers | grep certbot. Jos federointiportti 8448 käyttää samaa varmennetta kuin pääportti 443, erillistä konfigurointia ei tarvita, sillä yksi varmenne kattaa molemmat, kunhan Nginxin serverilohko kuuntelee molempia portteja samalla server_name-arvolla.

Vaihe 9: Nginx-käänteisproxyn määritys

Synapse kuuntelee oletuksena porttia 8008 paikallisesti. Nginx ohjaa sekä tavallisen HTTPS-liikenteen (443) että federointiportin (8448) samaan Synapse-prosessiin.

server {
    listen 443 ssl http2;
    listen 8448 ssl http2 default_server;
    server_name chat.omadomain.fi;

    ssl_certificate /etc/letsencrypt/live/chat.omadomain.fi/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/chat.omadomain.fi/privkey.pem;

    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;
        client_max_body_size 50M;
        proxy_http_version 1.1;
    }
}

Testaa konfiguraatio ennen käynnistystä komennolla sudo nginx -t. Jos tuloste on syntax is ok ja test is successful, voit ladata asetukset uudelleen komennolla sudo systemctl reload nginx.

Jos palvelin on julkisesti federoitu, kannattaa lisätä Nginxiin myös yksinkertainen pyyntörajoitus, joka estää yksittäistä IP-osoitetta kuormittamasta rekisteröinti- ja kirjautumisrajapintoja. Lisää lohko limit_req_zone $binary_remote_addr zone=matrixlogin:10m rate=5r/s; Nginxin http-tason konfiguraatioon ja viittaa siihen location-lohkossa avainsanalla limit_req zone=matrixlogin burst=10 nodelay;. Tämä pienentää merkittävästi riskiä, että botit kuluttavat palvelimen resursseja rekisteröitymisyrityksillä.

Vaihe 10–12: käynnistys systemd:llä, ensimmäinen käyttäjä ja Element Web

Aja Synapse systemd-palveluna, jotta se käynnistyy automaattisesti palvelimen uudelleenkäynnistyksen jälkeen ja jotta voit seurata sen tilaa tavallisilla työkaluilla.

sudo tee /etc/systemd/system/matrix-synapse.service > /dev/null <<'EOF'
[Unit]
Description=Synapse Matrix homeserver
After=network.target postgresql.service

[Service]
Type=notify
WorkingDirectory=/opt/synapse
ExecStart=/opt/synapse/env/bin/python -m synapse.app.homeserver -c homeserver.yaml
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now matrix-synapse
sudo systemctl status matrix-synapse

Onnistuneen käynnistyksen tuloste näyttää tältä: Active: active (running) ja lokissa rivi Synapse now listening on TCP port 8008. Luo tämän jälkeen ensimmäinen admin-käyttäjä.

sudo /opt/synapse/env/bin/register_new_matrix_user \
  -c /opt/synapse/homeserver.yaml http://localhost:8008

Komento kysyy käyttäjätunnusta, salasanaa ja haluatko myöntää admin-oikeudet. Kirjautumista varten helpoin ratkaisu on Element Web, jonka voit pystyttää samalle palvelimelle staattisena sivustona tai käyttää julkista app.element.io-osoitetta ja kirjautua sisään omalla palvelintunnuksellasi (chat.omadomain.fi). Mobiilikäyttäjille kannattaa suositella Element X:ää, joka vaatii toimiakseen parhaiten täyden Matrix 2.0 -yhteensopivuuden Synapsen kanssa.

Jos haluat pystyttää Element Webin omalle domainillesi julkisen app.element.io-osoitteen sijaan, lataa uusin julkaistu versio Element-hq:n julkaisusivulta, pura se web-palvelimen juurihakemistoon ja muokkaa mukana tulevaa config.json-tiedostoa niin, että base_url osoittaa kotipalvelimeesi. Tämä on hyödyllistä erityisesti silloin, kun haluat brändätä käyttöliittymän omalla logollasi tai rajoittaa käyttäjien pääsyn vain omaan asennukseesi ilman, että he vahingossa kirjautuvat julkiseen matrix.org-palvelimeen.

Element Web -asiakkaan voi tarjoilla Nginxistä samalta palvelimelta erillisessä alidomainissa, esimerkiksi element.omadomain.fi, jolloin sekä kotipalvelin että käyttöliittymä hallitaan yhdessä paikassa. Muista tässä tapauksessa asettaa käyttöliittymälle oma TLS-varmenne certbotilla samalla tavalla kuin kotipalvelimelle, sillä selaimet estävät sivuston lataamisen kokonaan, jos varmenne puuttuu tai on vanhentunut.

Onnistuneen kirjautumisen jälkeen voit varmistaa palvelimen toimivuuden yksinkertaisella API-kutsulla. Komento curl https://chat.omadomain.fi/_matrix/client/versions palauttaa JSON-vastauksen, jossa listataan palvelimen tukemat Matrix-protokollan versiot, esimerkiksi {"versions":["v1.11","v1.12","v1.13"]}. Jos saat sen sijaan yhteysvirheen, ongelma on todennäköisesti Nginxin tai palomuurin konfiguraatiossa, ei itse Synapsessa.

Federointi ja well-known-tiedostot ulkoista yhteyttä varten

Jos haluat, että käyttäjäsi voivat keskustella myös muiden Matrix-palvelinten käyttäjien kanssa, tarvitset federoinnin. Yksinkertaisin tapa välttää erillinen SRV-tietue on julkaista kaksi well-known-tiedostoa domainisi juuresta.

// https://omadomain.fi/.well-known/matrix/server
{ "m.server": "chat.omadomain.fi:443" }

// https://omadomain.fi/.well-known/matrix/client
{ "m.homeserver": { "base_url": "https://chat.omadomain.fi" } }

Testaa federointi virallisella federaatiotestityökalulla osoitteessa federationtester.matrix.org syöttämällä palvelintunnuksesi. Vihreä tulos jokaisen tarkastuksen kohdalla tarkoittaa, että muut palvelimet pystyvät löytämään ja tavoittamaan sinut. Jos et halua federointia lainkaan, esimerkiksi organisaation sisäiseen käyttöön, aseta federation_domain_whitelist: [] homeserver.yaml-tiedostoon.

Federaatiotestin tulos jaotellaan yleensä kolmeen osaan: DNS-tarkastus, TLS-varmenteen kelpoisuus ja avainten allekirjoituksen validointi. Jos jokin näistä epäonnistuu, työkalu näyttää tarkan virheviestin, jonka perusteella tiedät heti onko kyse DNS-tietueesta, palomuurista vai varmenteesta. Kannattaa ajaa testi uudelleen aina konfiguraatiomuutosten jälkeen, koska federointi on juuri se osa-alue, jossa pienikin virhe näkyy vasta muiden palvelinten käyttäjille, ei omille käyttäjillesi.

Varmuuskopiointi ja päivitysstrategia

Synapse-asennuksen kriittisin osa on PostgreSQL-tietokanta, ei itse sovelluskoodi. Ota säännöllinen dump talteen ja siirrä se erilliseen sijaintiin, mieluiten toiseen konesaliin.

sudo -u postgres pg_dump synapse | gzip > /var/backups/synapse-$(date +%F).sql.gz
# Lisää cron-ajastukseen, esim. joka yö klo 03:00
0 3 * * * postgres pg_dump synapse | gzip > /var/backups/synapse-$(date +\%F).sql.gz

Päivitä Synapse säännöllisesti, koska projekti julkaisee tietoturvakorjauksia usein. Ennen jokaista päivitystä kannattaa lukea julkaisumuistiinpanot, sillä osa versioista sisältää tietokantamigraatioita, jotka vievät aikaa suurilla asennuksilla. Sama kuria kannattaa noudattaa kuin Vaultwarden-asennuksen koventamisessa: päivitä säännöllisesti, mutta testaa ensin.

Pelkkä tietokannan varmuuskopio ei riitä, sillä palvelin tarvitsee palautuakseen myös allekirjoitusavaimet, homeserver.yaml-konfiguraation ja media-repositoryn sisällön. Ota siis varmuuskopio myös hakemistoista /opt/synapse/*.signing.key ja median tallennuspaikasta, joka on oletuksena /opt/synapse/media_store. Testaa palautus kerran etukäteen erillisellä testipalvelimella, jotta tiedät prosessin toimivan silloin kun sitä oikeasti tarvitset, etkä vasta kriisitilanteessa.

Palvelimen koventaminen: yksityisyys- ja tietoturva-asetukset

Perusasennus toimii, mutta oletusasetukset eivät ole vielä optimoituja yksityisyyden kannalta. Synapse lataa oletuksena huoneisiin lähetettyjen linkkien esikatselukuvat palvelimen omalla IP-osoitteella, mikä paljastaa palvelimen olemassaolon ja mahdollisesti käyttäjän lukemat linkit ulkopuolisille sivustoille. Jos et tarvitse tätä ominaisuutta, kytke se pois homeserver.yaml:sta asettamalla url_preview_enabled: false.

Toinen käytännön koventamiskeino on estää toistuvat väärät kirjautumisyritykset fail2ban-työkalulla, joka lukee Synapsen lokia ja estää IP-osoitteen määräajaksi palomuurissa. Alla on yksinkertainen jail-määrittely, jota voi käyttää lähtökohtana.

[matrix-synapse]
enabled = true
port = https,http
filter = matrix-synapse
logpath = /opt/synapse/homeserver.log
maxretry = 5
findtime = 600
bantime = 3600

Muista myös rajoittaa admin-rajapinnan pääsy vain omaan IP-osoitteeseesi Nginxin allow/deny-säännöillä, koska /_synapse/admin-polku antaa oikean access tokenin kanssa laajat oikeudet koko palvelimeen. Viimeisenä, harkitse kaksivaiheisen tunnistautumisen pakottamista käyttäjätileille, jos Element-asiakas ja identiteetintarjoajasi tukevat sitä, koska pelkkä salasana ei enää riitä suojaamaan tiliä, jolla on pääsy vuosien viestihistoriaan.

Kannattaa myös käydä läpi huoneiden oletusasetukset ennen kuin kutsut ensimmäiset käyttäjät sisään. Aseta huonehistorian näkyvyys oletuksena vain jäsenille, ei kaikille joskus liittyneille, ja harkitse huoneavainten (megolm-sessioiden) uusimisväliä tiukemmaksi, jos huoneessa käsitellään erityisen arkaluontoista tietoa. Nämä asetukset löytyvät huonekohtaisesti Element Webin huoneasetuksista, eikä niitä tarvitse säätää palvelintasolla.

Yleisimmät sudenkuopat asennuksessa

Nämä viisi virhettä toistuvat säännöllisesti Synapse-asennuksissa, ja jokainen niistä on helppo välttää etukäteen.

• Väärä tietokantakoodaus. Jos loit PostgreSQL-tietokannan ilman C-lokaalia ja UTF8-koodausta, Synapse kieltäytyy käynnistymästä ja tietokanta pitää luoda uudelleen tyhjästä.
• Server_name vaihdettu jälkikäteen. Palvelimen nimi (server_name) kirjoitetaan käyttäjätunnuksiin ja huonetunnisteisiin pysyvästi. Sitä ei voi vaihtaa asennuksen jälkeen ilman täyttä uudelleenasennusta.
• Portti 8448 unohtuu palomuurista. Ilman avointa federointiporttia palvelin toimii asiakkaille normaalisti, mutta muut palvelimet eivät pysty tavoittamaan sitä.
• Julkinen rekisteröityminen jätetään päälle. Ilman captchaa tai sähköpostivarmennusta avoin palvelin täyttyy roskaviesteistä muutamassa päivässä.
• Levytila loppuu median takia. Media-repository kasvaa nopeasti, jos et aseta max_upload_size-rajaa ja mediatiedostojen vanhentumiskäytäntöä.
• Aikavyöhyke ja kellon synkronointi unohtuu. Federointi ja TLS-varmenteet nojaavat molemmat tarkkaan kellonaikaan. Jos palvelimen kello on pahasti pielessä, varmenteen validointi ja huoneiden tapahtumajärjestys voivat rikkoutua. Asenna chrony tai varmista, että pilvipalveluntarjoaja synkronoi kellon automaattisesti.
• Salasanat kirjoitetaan suoraan komentoriville. Tässä oppaassa käytetyt esimerkkikomennot näyttävät salasanan selkokielisenä havainnollisuuden vuoksi, mutta tuotannossa kannattaa käyttää ympäristömuuttujia tai erillistä secrets-hallintaa, jotta salasana ei jää komentohistoriaan.

Vianmääritys: 8 yleistä ongelmaa ja niiden ratkaisut

Jos jokin ei toimi heti ensimmäisellä yrityksellä, tarkista seuraavat kohdat järjestyksessä ennen kuin aloitat asennuksen alusta. Suurin osa näistä ongelmista ratkeaa muutamassa minuutissa, kunhan tietää mistä lähteä etsimään, ja vain harvoin on tarve purkaa koko asennus ja aloittaa täysin puhtaalta pöydältä.

• "Connection refused" porttiin 8008. Synapse ei ole käynnissä. Tarkista sudo systemctl status matrix-synapse ja lue viimeisimmät rivit lokista.
• Federointitesti epäonnistuu, vaikka palvelin toimii asiakkaille. Portti 8448 ei ole auki palomuurissa tai pilvipalveluntarjoajan verkkoryhmässä. Tarkista sudo ufw status.
• "Invalid signing key" -virhe lokissa. Allekirjoitusavaintiedosto on kopioitu väärästä asennuksesta. Poista se ja anna Synapsen generoida uusi, mutta huomaa että vanhat federointisuhteet katkeavat.
• Element ei löydä palvelinta kirjautumisruudulla. well-known/matrix/client-tiedosto puuttuu tai sen JSON-muoto on virheellinen. Testaa curl https://omadomain.fi/.well-known/matrix/client.
• Tietokantavirhe "too many connections". PostgreSQL:n max_connections-asetus on liian pieni suhteessa Synapsen cp_max-arvoon. Nosta kumpaakin maltillisesti.
• Kuvat ja tiedostot eivät lataudu. Nginxin client_max_body_size on pienempi kuin Synapsen max_upload_size. Yhdenmukaista molemmat arvot.
• Rekisteröinti epäonnistuu "shared secret" -virheeseen. homeserver.yaml:n registration_shared_secret ei täsmää register_new_matrix_user-komennolle annetun konfiguraatiotiedoston kanssa.
• Palvelin kaatuu muistin loppumiseen isoissa huoneissa. Ota käyttöön caches.global_factor-asetuksen pienentäminen tai lisää RAM-muistia, jos palvelin liittyy paljon suuriin julkisiin huoneisiin.
• Certbot ei uusi varmennetta automaattisesti. Yleisin syy on, että Nginx ei ehdi vapauttaa porttia 80 uusintapyynnön ajaksi. Tarkista sudo certbot renew --dry-run tulostus ja varmista, ettei mikään muu prosessi kuuntele samaa porttia.

Edistyneet vinkit: Element Call, sliding sync ja suorituskyky

Kun peruspalvelin toimii, muutama lisäasetus parantaa käyttökokemusta huomattavasti. Element Call on Element Webin uudessa versiossa oletusarvoinen videopuheluratkaisu, ja se korvaa vanhan puhelutoteutuksen asetustasolla. Se vaatii lisäksi MatrixRTC-taustapalvelun (esimerkiksi LiveKit), joka kannattaa asentaa samaan aikaan kotipalvelimen kanssa, ei jälkikäteen.

Sliding sync (MSC4186) nopeuttaa erityisesti mobiiliasiakkaiden alkulatausta suurilla tileillä, joilla on satoja huoneita. Synapse tukee sitä natiivisti uusimmissa versioissa, mutta Dendrite ei vielä tue tätä ominaisuutta täysin, mikä on yksi syy lisää valita Synapse, jos aiot käyttää Element X -mobiilisovellusta laajasti. Suorituskyvyn osalta kannattaa myös erottaa media-repository omaksi työntekijäprosessikseen (worker), jos palvelimella on paljon samanaikaisia latauksia. Tämä pitää pääprosessin vasteajat tasaisina myös silloin, kun joku lataa suuria tiedostoja.

Worker-arkkitehtuuri kannattaa ottaa käyttöön vasta, kun peruspalvelin on vakaa ja käyttäjämäärä alkaa oikeasti kasvaa, ei etukäteen varmuuden vuoksi. Yksinkertaisin ensimmäinen worker on yleensä federation_sender, joka hoitaa lähtevän federointiliikenteen erillään pääprosessista ja estää hitaita etäpalvelimia jumittamasta omien käyttäjiesi viestien lähetystä. Toinen hyödyllinen lisä on media_repository-worker, joka erottaa kuvien ja tiedostojen käsittelyn omaksi prosessikseen. Molemmat vaativat oman Nginx-reitityksensä ja oman systemd-yksikkönsä, mutta tietokanta pysyy yhteisenä kaikille prosesseille.

Kannattaa myös harkita huoneiden ja käyttäjien hallintaan tarkoitettua admin-rajapintaa, jonka Synapse tarjoaa valmiiksi osoitteessa /_synapse/admin. Sen kautta voit muun muassa listata suurimmat huoneet levytilan käytön mukaan, deaktivoida väärinkäyttäjätilejä ja tarkistaa palvelimen kokonaiskäyttäjämäärän ilman erillistä kolmannen osapuolen työkalua. Rajapinta vaatii admin-oikeudella varustetun käyttäjän access tokenin, jonka saat samalla komennolla kuin tavallisen kirjautumisen.

Resurssitarpeen mitoittamiseksi alla on karkea suositus käyttäjämäärän mukaan. Luvut ovat suuntaa-antavia oletuskonfiguraatiolla, ilman worker-prosesseja.

Aktiiviset käyttäjät	vCPU	RAM	Levytila
Alle 50	2	4 Gt	20–40 Gt
50–200	4	8 Gt	80–150 Gt
200–1000	8	16 Gt	250 Gt+, erillinen media-storage suositeltava
Yli 1000	8+ ja worker-prosessit	32 Gt+	Erillinen tietokantapalvelin suositeltava

Element Call ja ryhmäpuhelut: mitä tarvitset lisää

Perus-Synapse-asennus hoitaa tekstiviestit, tiedostojen jaon ja huoneiden hallinnan, mutta ryhmäpuhelut vaativat erillisen taustapalvelun. Element Call nojaa MatrixRTC-arkkitehtuuriin, joka puolestaan tarvitsee SFU-palvelimen (Selective Forwarding Unit) välittämään ääni- ja videovirrat osallistujien välillä. Suosituin avoimen lähdekoodin vaihtoehto tähän on LiveKit, jonka voi pystyttää samalle palvelimelle omana Docker-konttinaan.

docker run -d --name livekit \
  -p 7880:7880 -p 7881:7881 -p 50000-50100:50000-50100/udp \
  -e LIVEKIT_KEYS="omaavain: omasalaisuus" \
  livekit/livekit-server --config /etc/livekit.yaml

Kun LiveKit on käynnissä, lisää homeserver.yaml:iin viittaus MatrixRTC-taustapalveluun ja julkaise sen osoite well-known/matrix/client-tiedostossa org.matrix.msc4143.rtc_foci-kentän alle. Element Web ja Element X löytävät tämän jälkeen palvelun automaattisesti, eikä käyttäjien tarvitse tehdä mitään erillistä asetusta puheluita varten. Huomaa, että UDP-porttialue 50000–50100 pitää avata palomuurissa, sillä ilman sitä puheluiden ääni- ja videovirrat eivät kulje, vaikka itse puhelun aloitus onnistuisikin.

Jos et tarvitse ryhmäpuheluita lainkaan, voit jättää tämän vaiheen kokonaan väliin. Tekstipohjainen viestintä, tiedostojen jako ja huoneiden hallinta toimivat täysin ilman MatrixRTC-taustapalvelua, ja moni pienempi asennus pärjää hyvin ilman sitä. Kannattaa lisätä LiveKit vasta sitten, kun käyttäjät oikeasti pyytävät puheluominaisuutta, koska ylimääräinen palvelu tarkoittaa myös ylimääräistä ylläpidettävää ja ylimääräistä hyökkäyspintaa.

Tietoturva: Synapsen haavoittuvuushistoria ja korjaukset

Aktiivisesti ylläpidetty projekti tarkoittaa myös säännöllisiä tietoturvapäivityksiä. Synapse on julkaissut useita korjauksia vuosina 2025–2026, ja niiden asentaminen ajallaan on omalla palvelimella oma vastuusi, toisin kuin valmiissa pilvipalvelussa.

Tunniste	Tyyppi	Vaikutus	Korjattu versiossa
CVE-2025-30355	Palvelunestohaavoittuvuus	Versiot 1.127.0 asti	1.127.1
CVE-2025-61672	Laitteen avaimen validointivirhe	Versiot ennen 1.138.3 ja 1.139.0	1.138.3 / 1.138.4 / 1.139.1 / 1.139.2
CVE-2026-45076	Tietoturvakorjaus (NVD)	Aiemmat 1.152-sarjaa edeltävät versiot	1.152.1
CVE-2026-45078	Palvelunestoon liittyvä pyyntöjen nälkiintyminen	Aiemmat 1.152-sarjaa edeltävät versiot	1.152.1

Huomionarvoista on, että CVE-2025-61672-korjauksessa yksi välivaiheen versio sisälsi regression, minkä vuoksi suositus oli päivittää suoraan versioon 1.138.4 tai 1.139.2 väliversioiden sijaan. Tämä on hyvä esimerkki siitä, miksi julkaisumuistiinpanojen lukeminen ennen päivitystä kannattaa, ei vain version numeron vertailu. Voit seurata avoimia haavoittuvuuksia NVD:n tietokannasta ja Synapsen omista turvallisuustiedotteista GitHubissa.

Käytännön ylläpitäjälle tästä seuraa yksinkertainen sääntö: tilaa itsellesi ilmoitus uusista GitHub-julkaisuista Synapsen repositoriosta ja varaa jokaista tietoturvakorjausta varten lyhyt ylläpitoikkuna, jonka aikana palvelu voi olla muutaman minuutin poissa käytöstä. Julkisesti federoidulla palvelimella riski on suurempi kuin suljetulla sisäisellä asennuksella, koska hyökkääjä voi löytää haavoittuvan version automaattisella skannauksella ilman, että kukaan huomaa mitään ennen kuin vahinko on jo tapahtunut.

Matrix Suomessa ja Pohjoismaissa: missä tilanne on nyt

Elementin oman Euroopan-kattavan katsauksen mukaan yhtiön Matrix-pohjaisia käyttöönottoja on tunnistettu 43 julkisen sektorin kohteessa eri puolilla Eurooppaa, ja Suomi on listattu yhtenä maana, jossa on aktiivinen, luokiteltu käyttöönotto. Sama viesti toistuu laajemmassa 2026 katsauksessa, jonka mukaan Matrix-pohjaista viestintää käytetään jo yli 25 maassa digitaalisen suvereniteetin perusteilla, ja mukana mainitaan muun muassa Saksa, Sveitsi, Itävalta, Ranska, Alankomaat ja Ukraina julkisen sektorin viestintäinfrastruktuurin osalta.

Suomalaiselle lukijalle käytännön johtopäätös ei ole "asenna Matrix koska valtiokin tekee niin", vaan pikemminkin se, että sama tekninen malli, jota valtiollisissa käyttöönotoissa käytetään, on kenen tahansa saatavilla ilmaiseksi. Yritys, järjestö tai yksittäinen kehittäjätiimi voi rakentaa oman viestintäympäristön, joka noudattaa samaa arkkitehtuuria kuin ministeriötason käyttöönotot, ilman lisenssimaksuja tai riippuvuutta yhdestä pilvitoimittajasta. Lisätietoa EU:n digitaalisen suvereniteetin linjauksista löytyy Euroopan komission digitaalistrategian sivuilta, ja itse protokollan tekniset yksityiskohdat on dokumentoitu Matrixin virallisessa spesifikaatiossa.

Pohjoismainen konteksti tuo mukaan myös käytännön latenssihyödyn. Kun palvelin sijaitsee lähellä käyttäjiä, esimerkiksi suomalaisessa tai ruotsalaisessa konesalissa, viestien ja puheluiden vasteajat pysyvät pieninä verrattuna siihen, että sama liikenne kiertäisi toisen mantereen kautta. Tämä korostuu erityisesti Element Callin kaltaisissa reaaliaikaisissa ominaisuuksissa, joissa muutaman kymmenen millisekunnin ero latenssissa näkyy suoraan puhelun laadussa.

Toinen huomionarvoinen seikka on kielituki. Element Web ja Element X on käännetty myös suomeksi ja ruotsiksi, joten palvelimen käyttöönotto ei tarkoita, että käyttäjien pitäisi opetella uutta järjestelmää vieraalla kielellä. Tämä madaltaa kynnystä ottaa oma palvelin käyttöön esimerkiksi yhdistyksissä ja pienemmissä organisaatioissa, joissa kaikki käyttäjät eivät ole teknisesti orientoituneita.

Mitä asiakassovellusta kannattaa suositella käyttäjille

Palvelin on vasta puolet kokonaisuudesta, koska käyttäjät kohtaavat lopulta asiakassovelluksen, ei homeserver.yaml-tiedostoa. Element Web toimii selaimessa ilman erillistä asennusta ja on useimmiten paras valinta ensimmäiseksi testiympäristöksi, koska sen voi ottaa käyttöön ilman että käyttäjän tarvitsee asentaa mitään laitteelleen. Työpöytäkäyttäjille Element Desktop tarjoaa saman käyttöliittymän natiivisovelluksena, jolloin ilmoitukset ja järjestelmätason integraatiot toimivat luotettavammin kuin selainvälilehdessä.

Mobiilipuolella tilanne on siirtymässä. Element X on merkitty seuraavan sukupolven mobiilisovellukseksi, joka tukee natiivia OIDC-kirjautumista, liukuvaa synkronointia ja Matrix RTC -pohjaisia puheluita, mutta se vaatii toimiakseen parhaiten Matrix 2.0 -yhteensopivan palvelimen. Vanhempi Element Classic -sovellus toimii yhä useimmilla palvelimilla, mutta sitä ei enää kehitetä yhtä aktiivisesti. Jos pystytät palvelimen tässä oppaassa kuvatulla tavalla ajantasaisella Synapse-versiolla, Element X toimii sen kanssa ilman lisäasetuksia.

Element ei ole ainoa Matrix-asiakas, vaikka se on selvästi käytetyin. Vaihtoehtoina ovat esimerkiksi FluffyChat, joka on suunniteltu erityisesti mobiilikäyttöön kevyemmällä käyttöliittymällä, ja Cinny, joka tavoittelee Discordia muistuttavaa käyttökokemusta selaimessa. Kaikki nämä puhuvat samaa Matrix-protokollaa, joten voit tarjota käyttäjillesi valinnanvaraa ilman, että se vaikuttaa mitenkään palvelinpuolen konfiguraatioon. Tämä on yksi konkreettinen etu verrattuna suljettuihin viestisovelluksiin, joissa asiakas ja palvelin tulevat aina samalta valmistajalta.

Vaihtoehto: milloin kannattaa käyttää valmista Matrix-hostausta oman palvelimen sijaan

Oma palvelin ei ole aina oikea valinta. Jos tiimissäsi ei ole ketään, joka ehtii seurata tietoturvapäivityksiä ja tehdä varmuuskopioita säännöllisesti, valmis hostauspalvelu voi olla turvallisempi vaihtoehto kuin laiminlyöty oma-asennus. Sama koskee tilannetta, jossa käyttäjämäärä kasvaa nopeasti eikä kukaan ehdi mitoittaa palvelinta uudelleen ajoissa. Tässä tapauksessa kannattaa punnita samaa riskiä, joka toteutui Protonin käyttökatkossa: yhden toimittajan varassa oleva palvelu voi kaatua kerralla useaksi tunniksi. Oma palvelin siirtää riskin sinulle, mutta antaa myös sinulle täyden hallinnan korjausaikatauluun. Vaihtoehtona kannattaa vertailla myös valmista asennusta, kuten yhteisön ylläpitämää Docker/Ansible-asennuspakettia, joka automatisoi suuren osan tässä oppaassa käsitellyistä vaiheista.

Käytännössä valinta oman ja hostatun palvelimen välillä kannattaa tehdä rehellisen resurssiarvion perusteella. Jos organisaatiolla on jo ylläpitäjä, joka hoitaa muitakin Linux-palvelimia, Matrixin lisääminen listalle ei kasvata työmäärää merkittävästi, koska suurin osa toimenpiteistä, kuten päivitykset ja varmuuskopiot, on samoja kuin muidenkin palveluiden kohdalla. Jos taas kyseessä on pieni tiimi ilman selkeää ylläpitovastuuta, hallitun hostauksen kuukausimaksu on usein halvempi ratkaisu kuin riski siitä, että palvelin jää päivittämättä ja päätyy samaan tilanteeseen kuin huonosti ylläpidetty Tchap-asennus.

Vertailun vuoksi kannattaa myös katsoa, miten muut itse ylläpidetyt palvelut on koventamisen jälkeen saatu turvallisiksi, kuten oman Tor-piilopalvelun pystytyksessä tehtiin: sama perusperiaate, oma palvelin ja oma vastuu, pätee tässäkin.

Koko projekti koottuna: valmis docker-compose-pohja testaukseen

Jos haluat kokeilla koko pinoa nopeasti ennen tuotantoasennusta, alla on kevyt docker-compose-kokonaisuus, joka pystyttää Synapsen ja PostgreSQL:n samalle koneelle yhdellä komennolla. Tämä ei korvaa yllä käytyjä 12 vaihetta tuotantoympäristössä, mutta se on nopea tapa testata konfiguraatiota omalla koneella tai erillisessä testipalvelimessa ennen kuin toistat vaiheet oikealle julkiselle palvelimelle.

version: "3"
services:
  synapse:
    image: matrixdotorg/synapse:latest
    restart: unless-stopped
    environment:
      SYNAPSE_SERVER_NAME: chat.omadomain.fi
      SYNAPSE_REPORT_STATS: "no"
    volumes:
      - ./synapse-data:/data
    depends_on:
      - db
    ports:
      - "8008:8008"
  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: synapse_user
      POSTGRES_PASSWORD: vaihda_tama_salasana
      POSTGRES_DB: synapse
      POSTGRES_INITDB_ARGS: "--encoding=UTF8 --locale=C"
    volumes:
      - ./postgres-data:/var/lib/postgresql/data

Käynnistä kokonaisuus komennolla docker compose up -d, ja generoi konfiguraatio ensimmäisellä ajolla vastaavalla tavalla kuin pip-asennuksessa, mutta konttien sisällä: docker run -it --rm -v $(pwd)/synapse-data:/data -e SYNAPSE_SERVER_NAME=chat.omadomain.fi -e SYNAPSE_REPORT_STATS=no matrixdotorg/synapse:latest generate. Tämän jälkeen muokkaa syntynyttä homeserver.yaml-tiedostoa täsmälleen samalla tavalla kuin tässä oppaassa: vaihda tietokanta PostgreSQL:ään, aseta rekisteröinnin salaisuus ja päivitä lokitusasetukset. Kun testaus on valmis, sama Nginx- ja certbot-vaihe pätee sellaisenaan riippumatta siitä, ajatko Synapsea kontissa vai suoraan virtuaaliympäristössä.

Docker-pohjaisen asennuksen suurin etu on päivitysten yksinkertaisuus: uuden Synapse-version käyttöönotto tarkoittaa käytännössä komentoja docker compose pull ja docker compose up -d, ilman että virtuaaliympäristöä tai pip-paketteja tarvitsee koskea. Haittapuolena on hieman vaikeampi vianmääritys, koska lokit ja tiedostopolut ovat kontin sisällä eivätkä suoraan isäntäjärjestelmän tiedostopolussa. Moni kokenut ylläpitäjä päätyy käytännössä hybridiin: kehitys ja testaus Dockerilla, tuotanto joko Dockerilla tai virtuaaliympäristöllä riippuen siitä, kumpaa työkalua organisaatio muutenkin käyttää muissa palveluissaan.

Usein kysytyt kysymykset

Tarvitseeko Matrix-palvelimen pystyttäminen ohjelmointiosaamista?
Ei välttämättä. Peruskäyttöönotto vaatii lähinnä komentorivin peruskäyttöä ja tekstitiedostojen muokkaamista. Ohjelmointitaitoa tarvitset vasta, jos alat rakentaa botteja tai omia integraatioita Matrix-rajapintaan.

Voiko Synapsen asentaa myös Dockerilla pip-asennuksen sijaan?
Kyllä, ja moni valitsee juuri sen, koska päivitykset hoituvat vetämällä uusi image. Tässä oppaassa käytimme pip-pohjaista asennusta, koska se näyttää selkeämmin, mitä palvelimella oikeasti tapahtuu, mikä auttaa vianmäärityksessä.

Onko Matrix yhtä turvallinen kuin Signal?
Molemmat käyttävät päästä päähän -salausta, mutta niiden luottamusmallit eroavat. Signal on keskitetympi ja yksinkertaisempi auditoida, kun taas Matrixin federoitu malli tuo lisää joustavuutta mutta myös enemmän liikkuvia osia, joiden konfigurointi voi mennä pieleen. Käytännössä turvallisuus riippuu enemmän siitä, kuinka huolellisesti palvelin on pystytetty ja päivitetty kuin siitä, kumpi protokolla on teoriassa vahvempi. Huonosti ylläpidetty Matrix-palvelin voi olla heikompi lenkki kuin oikein konfiguroitu Signal-tili, ja päinvastoin hyvin ylläpidetty Matrix-palvelin tarjoaa saman salaustason mutta ilman riippuvuutta yhdestä yrityksestä.

Voiko oman Matrix-palvelimen yhdistää suuriin julkisiin huoneisiin, kuten matrix.org:iin?
Kyllä, jos federointi on päällä ja well-known-tiedostot on julkaistu oikein. Voit myös rajoittaa federoinnin vain valittuihin domaineihin, jos haluat sisäisen mutta silti federoidun ympäristön esimerkiksi kumppaniorganisaatioiden kanssa.

Kuinka paljon oman Matrix-palvelimen ylläpito vie aikaa kuukaudessa?
Pienellä, alle 50 käyttäjän asennuksella realistinen arvio on 1–3 tuntia kuukaudessa, kun mukaan lasketaan päivitykset ja varmuuskopioiden tarkistus. Isommilla asennuksilla, joissa on worker-prosesseja ja aktiivista federointia, aikaa kuluu enemmän.

Mitä tapahtuu, jos unohdan päivittää Synapsen pitkäksi aikaa?
Vanha, päivittämätön Synapse-versio jää alttiiksi julkaistuille CVE-haavoittuvuuksille, kuten yllä olevassa taulukossa listatuille. Federoitu palvelin on erityisen altis, koska se on oletuksena tavoitettavissa julkisesta internetistä.

Kannattaako Conduit tai Conduwuit valita Synapsen sijaan pieneen asennukseen?
Jos käyttäjiä on vain muutama ja resurssit ovat rajalliset, Conduwuit on validi vaihtoehto pienemmällä muistinkulutuksella. Isommalle tai kasvavalle käyttäjäkunnalle Synapse on silti turvallisempi valinta ekosysteemin tuen ja Element X -yhteensopivuuden takia.

Voiko tämän oppaan vaiheita käyttää myös yrityksen sisäiseen viestintään ilman federointia?
Kyllä. Jätä federointiportti 8448 kiinni palomuurissa ja aseta federation_domain_whitelist: [], jolloin palvelin toimii täysin suljettuna, mutta silti samalla Matrix-protokollalla ja samoilla asiakassovelluksilla.

Voiko yhdellä palvelimella isännöidä useita eri organisaatioiden huoneita erillään toisistaan?
Kyllä, huoneiden pääsynhallinta hoidetaan Matrixissa huonekohtaisilla oikeuksilla, ei erillisillä palvelininstansseilla. Voit siis pitää yhden Synapse-asennuksen, jossa eri tiimeillä tai osastoilla on omat, toisistaan erilliset huoneensa ja tarvittaessa omat huonepohjaiset moderaattorinsa.

Mistä tiedän, milloin palvelin tarvitsee lisää resursseja?
Seuraa PostgreSQL:n kyselyaikoja ja Synapsen omaa /health-päätepistettä säännöllisesti. Jos vasteaika kirjautumiseen tai viestien lähetykseen alkaa venyä useisiin sekunteihin ruuhka-aikoina, se on selkeä merkki siitä, että on aika siirtyä resurssitaulukon seuraavaan tasoon tai ottaa worker-prosessit käyttöön.

Toimiiko tämä opas myös Hetzner-, UpCloud- tai muun eurooppalaisen VPS-tarjoajan palvelimella?
Kyllä, opas ei ole sidottu mihinkään tiettyyn palveluntarjoajaan. Kaikki komennot toimivat sellaisenaan millä tahansa Ubuntu 24.04- tai Debian 12 -pohjaisella VPS-palvelimella, kunhan sinulla on root-oikeudet ja pystyt avaamaan tarvittavat portit palomuurista tai pilvipalvelun verkkoryhmästä.