Composizione: la mascotte orso polare di NordBastion in armatura tattica nordica davanti a una volta traslucida di celle di cifrario illuminate di ciano, fili di federazione che si intrecciano tra silhouette di fortezze lontane attraverso un fiordo notturno, il logo Matrix inciso debolmente sulla porta della volta, aurora sopra
Caso d'uso · Homeserver Matrix · Aggiornato 2026

Il suo homeserver Matrix.
End-to-end. Federato. Nordico. Inchiedibile.

Synapse + Postgres + Element su un Ravelin a $23,90/mese. Il suo homeserver instrada e federa; non può leggere il proprio traffico E2E; la giurisdizione nordica significa che nessuno può chiedergli educatamente di iniziare a provarci.

In sintesi
  • 01

    Ravelin a $23,90/mese regge comodamente un Synapse ben federato con ~100 stanze — Postgres, Redis, i worker Synapse, la cache dello stato delle stanze, tutto sulla stessa macchina.

  • 02

    La cifratura end-to-end è strutturale — l'homeserver instrada ciphertext che non può decifrare. Il signup admin senza KYC significa che nemmeno l'operatore porta una traccia documentale.

  • 03

    Giurisdizione nordica + nessun log per design + uplink non misurato. Le chiacchiere di federazione per un insieme di stanze attive sono volume reale; qui non fatturano extra.

Perché vale la pena

Perché auto-ospitare l'homeserver in primo luogo.

Iscriversi a matrix.org è la risposta giusta per la maggior parte delle persone. Gestire il proprio homeserver è la risposta giusta quando il suo handle, l'appartenenza alle stanze e i metadati dei messaggi non dovrebbero vivere sul pannello amministrativo di qualcun altro. Il protocollo è federato, la cifratura è end-to-end; il tassello mancante è «chi controlla la macchina a cui è ancorato il mio account», e la risposta cambia materialmente il threat model.

Il modello di federazione di Matrix è generoso: qualsiasi homeserver può parlare con qualsiasi altro homeserver, le stanze attraversano server, la cifratura segue l'utente e non è richiesta una directory centrale per partecipare. Una volta che il suo homeserver è in esecuzione e validato contro il federation tester, il suo account è un cittadino di prima classe della rete — uguale a @user:matrix.org o @user:mozilla.org, solo sul suo dominio.

La storia operativa per Synapse è ben battuta: template Docker Compose upstream, Postgres per lo stato, Redis per il worker pool, worker shardati opzionali per federazione ad alto volume. Niente è nuovo; tutto è documentato; le modalità di fallimento sono note.

La domanda giusta non è «auto-ospitare o matrix.org» in astratto — è «voglio la mia identità di federazione ancorata a una macchina che amministro». Se la risposta è sì, il resto di questa pagina è la ricetta.

Dimensionamento

La fascia NordBastion giusta per il compito.

Per un homeserver di comunità con ~100 stanze (mix di piccoli DM e una manciata di stanze pubbliche ben popolate federate verso l'esterno), la fascia giusta è il Ravelin ($23,90/mese, 8 vCPU, 16 GB, 480 GB NVMe). Il data path Python di Synapse è affamato di RAM sotto raffiche di federazione — una stanza popolare a cui si unisce un server con 50k utenti produce un picco transitorio di state-resolution che vuole margine. 16 GB lo assorbono comodamente.

Oltre ~1000 stanze attive o quando il traffico di federazione spinge Synapse a richiedere la modalità sharded worker, la fascia Bulwark le dà i core per far girare worker dedicati federation_sender, synchrotron ed event_persister — la storia di scaling orizzontale di Synapse all'interno di una sola macchina. A quel punto le converrà anche pensare se Postgres debba stare sul suo proprio VPS; possiamo parlare di un layout a due macchine.

Per un homeserver personale — il suo account, qualche DM, un paio di piccole stanze private — un Garrison ($11,90/mese, 4 vCPU, 8 GB, 240 GB NVMe) è ampiamente sufficiente. Conduit su un Sentinel è tecnicamente possibile per una configurazione a singolo utente, ma Synapse su un Garrison le dà spazio per crescere senza una migrazione.

Ciò che nessuna di queste è: un'offerta managed-Matrix multi-tenant per mille tenant. NordBastion è costruito per l'operatore che gestisce il proprio homeserver per persone che conosce — non per vendere account Matrix a sconosciuti.

Configurazione

Dal VPS nuovo alla prima stanza federata. Sei passi, circa novanta minuti.

Uno schema scheletro — la documentazione upstream Synapse di element-hq resta il riferimento autorevole per il tuning di homeserver.yaml e per la worker mode.

  1. 01

    Docker + Compose

    Il Docker engine ufficiale + il plugin Compose v2. Element-HQ pubblica un'immagine Synapse mantenuta che può ancorare per tag.

    curl -fsSL get.docker.com \
      | sh
    apt install \
      docker-compose-plugin
  2. 02

    Generi homeserver.yaml

    La modalità «generate» one-shot dell'immagine Synapse scrive una config iniziale legata al suo server_name. Disabiliti la registrazione aperta nello stesso passaggio.

    docker run --rm \
      -v ./data:/data \
      -e SYNAPSE_SERVER_NAME=example.org \
      matrixdotorg/synapse:latest \
      generate
  3. 03

    Colleghi Postgres + Redis

    Postgres è lo store di produzione; SQLite è solo per i test. Redis è richiesto per il worker pool anche se inizia a singolo processo.

    # aggiunga a docker-compose.ymlpostgres: postgres:15
    redis:    redis:7-alpine
    # poi in homeserver.yaml: database driver psycopg2
  4. 04

    Pubblichi well-known

    Due piccoli file JSON su /.well-known/matrix/{client,server} sul suo dominio apex. Serviti come application/json con CORS Access-Control-Allow-Origin: *.

    # /.well-known/matrix/server
    {"m.server": "matrix.example.org:443"}
    # /.well-known/matrix/client
    {"m.homeserver":{"base_url":"https://matrix.example.org"}}
  5. 05

    Validi la federazione

    federationtester.matrix.org controlla well-known, catena dei certificati, handshake TLS, handshake di versione e scambio chiavi. Non inviti utenti finché non è verde.

    # incolli server_name in:# federationtester.matrix.org
    # tutti i controlli devono essere verdi
  6. 06

    Crei l'admin tramite shared secret

    registration_shared_secret in homeserver.yaml + CLI register_new_matrix_user = un account admin senza mai aprire il signup pubblico.

    docker compose exec synapse \
      register_new_matrix_user \
      -a -c /data/homeserver.yaml \
      http://localhost:8008
Perché questo host per questo compito

Perché NordBastion specificamente per un homeserver Matrix.

Senza KYC

Gli admin di infrastruttura E2E non dovrebbero portare una traccia documentale.

La cifratura end-to-end è un'affermazione forte. Viene minata nel momento in cui l'hoster del relay sa, dal KYC lato billing, esattamente quale persona giuridica ha tirato su questo homeserver. Signup senza KYC con fatturazione solo cripto mantiene i metadati amministrativi del relay tanto opachi quanto i metadati del payload del relay: «il saldo prepagato dietro questa email», fine della storia.

Giurisdizione nordica

Cintura e bretelle.

La cifratura end-to-end di Matrix impedisce già aritmeticamente al relay di leggere i payload. La giurisdizione nordica aggiunge un secondo strato: nessun mandato di conservazione dei dati che costringa l'hoster a registrare i metadati di connessione, nessuna legislazione di client-side scanning in atto e un warrant canary pubblicato che descrive cosa accadrebbe se qualcuno provasse a cambiare la matematica (non possiamo). Due strati di «no» battono uno.

1 Gbps non misurato

La federazione è volume.

Un homeserver federato in qualche stanza pubblica ben popolata spinge molti piccoli eventi di federazione — ogni join, ogni cambio di stato, ogni ricevuta di messaggio è un fan-out di consegna verso N server. L'aggregato non è enorme ma è sostenuto, e qualunque hoster che fatturi per GB-out rende nervoso l'operatore. L'uplink non misurato rimuove il sovraccarico cognitivo: federi quanto il protocollo richiede; la fattura è la stessa.

Verdetto

Lo faccia girare su un Ravelin. Disabiliti il signup aperto. Lasci che la federazione faccia il resto.

Auto-ospitare un homeserver Matrix è una delle mosse sovrane più pulite che un piccolo gruppo possa fare per la propria messaggistica. Al prezzo di un singolo seat SaaS di strumento di chat ottiene un homeserver federato e cifrato end-to-end i cui handle sopravvivono a qualsiasi piattaforma, la cui moderazione è la sua, e il cui hosting è in una giurisdizione senza mandati di conservazione dei dati né legislazione di client-side scanning in atto.

NordBastion ha opinioni sulle parti che contano per questo compito specifico — signup admin senza KYC, giurisdizione nordica, uplink non misurato — ed è deliberatamente ordinario sul resto. Docker è Docker. Synapse è Synapse. Element-HQ fornisce l'immagine; noi forniamo la macchina.

Si prenda una serata, esegua i sei passi, validi contro il federation tester, crei l'admin. L'homeserver sopravvive alla serata per anni.

FAQ · Matrix su un VPS

Le domande che emergono per prime.

Le otto domande con cui gli admin Matrix si confrontano realmente prima di `docker compose up`. La well-known delegation è la seconda domanda per una ragione.

Perché E2E se il server è già mio?

Perché il server è una macchina e i messaggi vivono per sempre. Chiunque con accesso al disco — un incidente di snapshot, un'immagine forense, un co-admin uscito di testa, un successore quando alla fine consegnerà la macchina — vede testo in chiaro se la stanza non è cifrata. La cifratura end-to-end mantiene utile l'homeserver (instrada, federa, presenta la UI) rendendo il payload del messaggio aritmeticamente illeggibile per qualsiasi cosa al di fuori delle chiavi del dispositivo del partecipante. Auto-hosting ed E2E sono cintura + bretelle: lei controlla il relay E il relay non può leggere il proprio traffico.

Cos'è la well-known delegation e perché tutti ci inciampano?

Matrix permette al suo dominio user-facing (example.org) di differire dal dominio server-facing (matrix.example.org) servendo due piccoli file JSON su https://example.org/.well-known/matrix/client e /.well-known/matrix/server. Quello client dice a Element quale URL di homeserver usare; quello server dice ai peer federati dove raggiungere Synapse per l'API s2s. Le persone inciampano su tre cose: servire i file con il Content-Type sbagliato, CORS che non permette ad altre istanze di prelevarli, o il file server che punta a una porta che il firewall in realtà non espone. Validi con federationtester.matrix.org prima di pubblicare la stanza.

Synapse vs Dendrite vs Conduit — conta per l'hosting?

Synapse (Python, l'implementazione di riferimento) è ciò che fa girare il 95% degli homeserver pubblici; è il peer di federazione più testato e l'unico che supporta ogni funzionalità definita dalla specifica. Conduit (Rust, singolo binario, RocksDB) e Dendrite (Go, microservizi) sono più leggeri — Conduit notoriamente gira su un Raspberry Pi. Per un homeserver federato rivolto al pubblico con utenti sopra, Synapse è la risposta; per un homeserver hobbistico a singolo utente può sperimentare con Conduit su un Sentinel. Questo editoriale presuppone Synapse.

Come evito lo spam di iscrizioni pubbliche?

Imposti `enable_registration: false` in homeserver.yaml e si affidi a `registration_shared_secret` per creare account tramite l'API admin per le persone che davvero vuole. In alternativa, `enable_registration_without_verification: false` combinato con un flusso di invito a shared-secret codificato. La federazione Matrix è abbastanza grande da far sì che qualunque homeserver a registrazione aperta diventi una fattoria di account spambot in pochi giorni; la risposta canonica è «la registrazione è curata dall'admin, la federazione è aperta».

Element vs Cinny vs SchildiChat vs altri — all'homeserver interessa?

No — l'API C-S di Matrix è il contratto del protocollo, e ogni client conforme parla con ogni server conforme. Element è il default e il più testato; Cinny è un client web più leggero che alcuni self-hoster preferiscono includere; SchildiChat è un fork di Element con UI in stile Telegram; FluffyChat punta al mobile-first. L'homeserver non vede né si cura di quale client usa un utente. Scelga ciò che la sua comunità preferisce, lo cambi più tardi, senza migrazione.

Come funziona il backup delle chiavi end-to-end?

Ogni utente Matrix ha un insieme di chiavi del dispositivo (per dispositivo, effimere) e una chiave di cross-signing (per account, a lunga durata). La chiave master di cross-signing è ciò che permette a un utente di aggiungere un nuovo dispositivo senza ri-verificare tutto; se la perde, l'utente resta fuori dai messaggi E2E storici finché non rinnova le chiavi. La funzionalità «Secure Backup» di Element cifra la chiave di cross-signing con una passphrase o recovery key e la conserva lato server come ciphertext opaco — l'homeserver tiene il blob ma non può leggerlo. Documenti il passaggio della recovery key per i suoi utenti al signup; è il singolo pezzo di UX che previene blocchi evitabili.

Posso migrare una stanza da un altro homeserver al mio?

Non direttamente — le stanze sono oggetti federati, non record per-server, quindi «spostare» una stanza significa farne l'upgrade (un primitivo nativo Matrix che crea una stanza successore e segna quella vecchia con un redirect) e invitare lo stesso set di partecipanti. L'ID della stanza cambia, l'alias può seguire. La migrazione diretta degli account utente tra homeserver è da tempo in wishlist Matrix (la portabilità dell'account è nella roadmap della specifica); oggi crea un nuovo account sul suo server e chiede alle persone di ri-aggiungerla.

Qual è la storia di gestione abusi per un homeserver federato?

Matrix ha primitivi di moderazione per-stanza (kick, ban, redact, admin di stanza) e primitivi di moderazione per-server (denylist via l'API modulo di Synapse, bot MJOLNIR per denylist gestite, modalità allowlist a livello server per federazione su invito). Per un homeserver di comunità, la sottoscrizione in stile MJOLNIR a denylist è la risposta standard — delega l'identificazione di spam/abusi a comunità di denylist mantenute e applica la policy localmente. La sua sovranità: sceglie quali denylist seguire.