Self-host Matrix su un VPS.
Synapse + Element. Federato. Cifrato end-to-end.
Matrix è ciò che l'email sembrerebbe se fosse stata progettata per la chat nell'era del protocollo aperto. Synapse come homeserver, Element come client, PostgreSQL come store, Caddy come porta d'ingresso — e un grafo di stanze federate che nessuno in particolare possiede.
- 01
Synapse è il default corretto dell'homeserver nel 2026 — l'implementazione di riferimento collaudata in produzione con tutte le funzionalità. Conduit e Dendrite sono validi per casi d'uso più limitati.
- 02
Passare a PostgreSQL fin dal primo giorno; il default SQLite è solo per i test e cede oltre una manciata di utenti. Pianificare il disco per gli upload di media — le stanze federate li accumulano rapidamente.
- 03
La registrazione chiusa è il default sicuro. La registrazione pubblica è un vero lavoro di moderazione; abilitarla solo se si è disposti ad affrontarla.
Matrix in cinque frasi. Cosa si sta effettivamente deployando.
Matrix è un protocollo aperto per la comunicazione in tempo reale. Un homeserver è un server che esegue il protocollo; gli utenti appartengono a un homeserver ciascuno, identificati come @alice:example.com — lo stesso schema dell'email. Le stanze sono le unità di conversazione; una singola stanza può avere membri provenienti da molti homeserver diversi, e lo stato della stanza è replicato in tutti gli homeserver partecipanti. Le stanze private cifrano ogni messaggio con chiavi per dispositivo (Olm/Megolm) in modo che il server veda solo testo cifrato. L'intera rete è un grafo di homeserver che si federano lo stato delle stanze tra loro.
Le proprietà interessanti: nessuna autorità centrale può spegnere Matrix (il protocollo è aperto e gira ovunque), gli utenti su server diversi si parlano trasparentemente (federazione), le stanze private hanno una vera cifratura end-to-end (non la cifratura-in-transito da pubblicità), e un utente può cambiare homeserver e mantenere la propria identità gestendo il proprio. Il compromesso è la complessità operativa — gestire un homeserver è più lavoro che accedere a Discord — e un ecosistema di client raffinati più piccolo rispetto alle piattaforme proprietarie.
Cosa si deploya in questa guida: Synapse (l'homeserver), PostgreSQL (il suo database), Element Web (il client browser, hosted dal proprio dominio), e Caddy (il reverse proxy + TLS automatico). Opzionalmente un backend di storage media e gli endpoint well-known per la scoperta della federazione. L'intero stack è due file Docker Compose e una configurazione Caddy.
Dimensionamento. Synapse è memory-shaped.
Synapse mantiene lo stato per stanza in memoria, e unirsi a una grande stanza federata (diciamo #matrix:matrix.org con 60.000 membri) carica molto di quello stato nell'homeserver. Il risultato è che anche un singolo utente Synapse può usare 2–3 GB di RAM stabilmente se l'utente è in stanze federate affollate. Pianificare di conseguenza.
Singolo utente, federazione moderata. 2 vCPU, 4 GB RAM, 40 GB SSD. Il <a href="/it/vps/" class="text-nord-cyan border-b border-nord-cyan/40 hover:border-nord-cyan transition">piano Ravelin ($5.90/mese)</a> di NordBastion è dimensionato correttamente. Il disco cresce di circa 10 GB/anno per un singolo utente attivo: pianificare lo spazio di conseguenza.
Piccolo team, 5–20 utenti. 4 vCPU, 8 GB RAM, 100 GB SSD. Il tier Iron ($24.90/mese) gestisce questo comodamente. Eseguire PostgreSQL sullo stesso VPS; il database si adatta alla RAM e al disco disponibili.
Homeserver pubblico, 100+ utenti. Oltre i 100 utenti attivi, Synapse beneficia di processi worker (federation sender, federation reader, client reader workers separati) e di un PostgreSQL ottimizzato. I tier Iron o Granite gestiscono questo, ma la complessità operativa cresce in modo non lineare — a quella scala si è un amministratore Matrix oltre che un utente del software.
Realtà del disco. I media upload (immagini, video, file) dalle stanze federate si accumulano nell'homeserver perché la federazione Matrix scarica i media in locale per servirli. Un homeserver pubblico affollato può aggiungere 1 GB di media a settimana. La configurazione media_retention di Synapse permette di eliminare i contenuti più vecchi; revisionarla una volta al trimestre.
L'installazione Docker Compose. Synapse, PostgreSQL, Element.
Avviare un VPS Debian 12 fresco, puntare tre record DNS su di esso: matrix.example.com (il nome host dell'homeserver), element.example.com (il client web), e example.com stesso se si vuole la forma breve dell'identificatore @alice:example.com. Accedere via SSH come utente sudo.
1. Installare Docker e Compose. curl -fsSL https://get.docker.com | sh — Docker Engine include Compose v2 nello stesso pacchetto.
2. Generare la configurazione di Synapse. mkdir -p ~/synapse/data && docker run -it --rm -v ~/synapse/data:/data -e SYNAPSE_SERVER_NAME=example.com -e SYNAPSE_REPORT_STATS=no matrixdotorg/synapse:latest generate — questo scrive homeserver.yaml. Modificarlo: cambiare il database da SQLite a PostgreSQL, impostare l'URL media, impostare enable_registration: false per iniziare (gli utenti si creano tramite la CLI di amministrazione per ora).
3. Scrivere docker-compose.yml. Tre servizi: postgres (postgres:16, volume persistente, locale C), synapse (matrixdotorg/synapse:latest, monta ~/synapse/data, dipende da postgres), element (vectorim/element-web:latest, monta un piccolo config.json che punta a https://matrix.example.com). Mappare solo synapse:8008 e element:80 su localhost; non collegare [redacted-ip].
4. Configurare con Caddy. Due siti Caddyfile: matrix.example.com fa proxy verso [redacted-ip] (Synapse) su entrambe le porte 443 e 8448 (la porta di federazione); element.example.com fa proxy verso [redacted-ip] (Element Web). Caddy recupera automaticamente i certificati Let's Encrypt.
5. Scoperta della federazione (.well-known). Aggiungere due file JSON statici su example.com stesso: /.well-known/matrix/server che restituisce {"m.server": "matrix.example.com:443"} e /.well-known/matrix/client che restituisce {"m.homeserver": {"base_url": "https://matrix.example.com"}}. Questo permette agli identificatori in forma breve @alice:example.com di risolversi correttamente. Verificare con il Federation Tester su federationtester.matrix.org.
6. Creare il primo utente. docker exec -it synapse register_new_matrix_user -u alice -p <password> -a -c /data/homeserver.yaml http://localhost:8008 — crea un account amministratore. Accedere tramite https://element.example.com.
Element, branding, politica di registrazione. Le decisioni che rimangono.
Configurazione di Element. Element Web legge un config.json che punta al suo homeserver, imposta il tema predefinito, il branding e l'elenco delle «stanze suggerite» per i nuovi account. Impostare default_server_config.m.homeserver.base_url su https://matrix.example.com, brand con il nome del suo progetto, e disabilitare il campo brand_url che suggerisce matrix.org. I nuovi utenti atterrano su Element Web puntato al suo server, non a quello di qualcun altro.
Politica di registrazione. Tre modalità: chiusa (solo l'amministratore può registrare utenti tramite CLI; la postura di moderazione più pulita), basata su token (si generano token di registrazione tramite l'API di amministrazione e li si condivide; meglio per un piccolo gruppo), aperta (chiunque può registrarsi; abilitarla solo se si intende gestire un homeserver pubblico con strumenti di moderazione). Iniziare chiusa e allentare solo se si ha un motivo.
Lista di blocco della federazione. Synapse supporta federation_domain_whitelist (solo allow-list) e blocchi per server tramite l'API di amministrazione. Per la maggior parte degli homeserver pubblici, il default è «federare con tutto», con blocchi reattivi dei server abusivi secondo necessità. Il bot Mjolnir automatizza questo se si diventa un bersaglio.
Backup. Dump notturno PostgreSQL + tarball di ~/synapse/data, inviato fuori server tramite rclone su un secondo VPS o bucket B2. Entrambi sono necessari; il database è lo stato delle stanze e gli account, la directory dati contiene le chiavi di firma e i media. Test di ripristino ogni trimestre, come per qualsiasi backup.
La realtà della moderazione. Cosa significa davvero il self-hosting.
Gestire un homeserver Matrix significa accettare che l'host sia responsabile di ciò che il server fa. Su un homeserver privato solo su invito, quella responsabilità è piccola — si conosce ogni utente. Su un homeserver pubblico, la responsabilità scala con la base utenti.
Abusi inbound. Una stanza pubblica federata può essere coinvolta nel coordinamento di abusi, dump di immagini o molestie. Synapse espone endpoint API di amministrazione per bannare un utente (in tutte le stanze), bloccare un homeserver (nessuna ulteriore federazione), e forzare un server ad abbandonare una stanza. Il bot Mjolnir raggruppa queste funzioni in un flusso di moderazione tramite stanza dedicata; il fork Draupnir è la sua continuazione mantenuta attivamente.
Abusi outbound. Un account utente compromesso può pubblicare contenuti abusivi nelle stanze federate, danneggiando la reputazione del server nel resto della rete. Due mitigazioni: limitare la frequenza per utente (i limiti di frequenza predefiniti di Synapse sono ragionevoli), e richiedere la verifica email per i nuovi account (alza la barriera alla registrazione automatizzata).
Postura legale. Nell'UE, un ruolo di fornitore di infrastruttura offre forti protezioni per la responsabilità intermediaria (Direttiva e-Commerce Articolo 14, DSA Articolo 6) — non si è responsabili per i contenuti degli utenti purché si risponda alle notifiche e rimozioni. Le giurisdizioni nordiche estendono questo con esplicite protezioni costituzionali sulla libertà di stampa. Lo stesso homeserver in una giurisdizione senza protezioni per gli intermediari è operativamente più rischioso; scegliere la posizione dell'host di conseguenza.
Il default sicuro. Registrazione solo su invito, federazione abilitata con blocchi reattivi, Mjolnir / Draupnir installati ma inutilizzati finché non servono, termini di servizio pubblicati sul sito web dell'homeserver con una chiara policy di uso accettabile. Questa postura copre il 95% degli operatori senza ulteriore sforzo.
Perché l'host conta. La crittografia protegge il contenuto, l'host protegge i metadati.
Matrix E2EE protegge i corpi dei messaggi — il server detiene solo testo cifrato per le stanze private. Ciò che non protegge sono i metadati: quali homeserver si federano tra loro, quali utenti sono in quali stanze, quando sono online, con che frequenza inviano messaggi, quali sono i loro dispositivi. Quel grafo di metadati vive nell'homeserver e negli homeserver con cui si federa, ed è tecnicamente fuori dalla portata del livello di cifratura.
Un homeserver in esecuzione su un VPS collegato a KYC lega il grafo dei metadati all'identità legale dell'operatore. Una citazione in giudizio all'host produce non solo il database cifrato ma anche il collegamento dall'identificatore @alice:example.com a un nome reale. La crittografia regge ancora; il livello dei metadati è aperto.
L'approccio di NordBastion è l'opposto: <a href="/it/doctrine/" class="text-nord-cyan border-b border-nord-cyan/40 hover:border-nord-cyan transition">registrazione senza KYC</a>, pagamento in criptovaluta, giurisdizioni costituzionali nordiche. L'homeserver è vostro; il collegamento dall'homeserver a un nome non esiste; il regime giuridico che tocca il disco prevede esplicite tutele della libertà di stampa. La combinazione si allinea al modello di sicurezza di Matrix stesso — sia il livello crittografico dei contenuti che il livello operativo dei metadati sono protetti.
Domande, con risposta.
Otto domande che emergono gestendo un homeserver Matrix nel 2026.
Cos'è Matrix e come è diverso da Discord o Slack?
Matrix è un protocollo di comunicazione in tempo reale federato e open-standard — pensare a SMTP per la chat. Chiunque gestisce un homeserver (Synapse, Dendrite, Conduit), gli utenti su homeserver diversi si parlano trasparentemente, ogni messaggio in una stanza privata è cifrato end-to-end per default, nessuna azienda centrale controlla la rete. Discord e Slack sono centralizzati, proprietari, e l'azienda ospita ogni conversazione. Il compromesso: Matrix ha una complessità operativa leggermente superiore e un ecosistema di client raffinati più piccolo, ma si è proprietari di ogni byte.
Synapse, Dendrite o Conduit — quale homeserver?
Synapse è il riferimento, scritto in Python, il più ricco di funzionalità e la scelta collaudata in produzione. Consuma molta memoria. Dendrite è il riscrittura più recente in Go, molto più leggera, mancante di alcune funzionalità avanzate di moderazione ma che chiude rapidamente il divario. Conduit è la terza opzione, un homeserver in Rust focalizzato sul footprint minimo delle risorse, ottimo per un homeserver a singolo utente su un VPS economico. Scegliere Synapse per default a meno che non si abbia un motivo specifico — la documentazione, gli strumenti di moderazione e i bridge di terze parti assumono tutti Synapse.
Quante risorse VPS servono per un homeserver Matrix?
Singolo utente che si federa con la rete Matrix più ampia — 2 vCPU, 4 GB RAM, 40 GB SSD è il floor pratico. Piccolo team (5–20 utenti) — 4 vCPU, 8 GB RAM, 100 GB SSD. I tier Ravelin o Iron coprono entrambi i casi. La risorsa dominante è la RAM (Synapse mantiene molto stato delle stanze in memoria) e il disco (gli upload di media e la cronologia delle stanze federate crescono continuamente).
Devo abilitare la federazione?
Quasi sempre sì — è tutto il punto di Matrix. La federazione permette ai suoi utenti di parlare con chiunque su matrix.org, mozilla.org, kde.org e migliaia di altri homeserver. Le eccezioni: un server privato per team interno dove non si vuole che nessuno scopra le stanze; un modello di minaccia ad alto rischio dove i pattern del traffico di federazione rivelano informazioni; un server che ospita materiale sensibile dove si vuole un controllo rigoroso dei membri. Disabilitare la federazione in seguito va bene; riattivarla la rende scopribile.
Le stanze private sono cifrate end-to-end per default?
Sì — ogni client Element abilita E2EE per default per i nuovi messaggi diretti e le stanze private. La cifratura è per stanza Olm/Megolm con verifica del dispositivo cross-signed. Il server vede solo testo cifrato per il corpo del messaggio. Le stanze pubbliche sono non cifrate by design (poiché chiunque può unirsi, la cifratura non proteggerebbe nulla). Le stanze pubbliche federate sono visibili a chiunque — che è il punto di una stanza pubblica.
Qual è la realtà della moderazione nella gestione di un homeserver pubblico?
È un lavoro vero. Se si consente la registrazione pubblica, il proprio homeserver si federà a stanze spam, verrà coinvolto in stanze di coordinamento abusi, e occasionalmente mostrerà contenuti discutibili da server federati. Gestire un homeserver pubblico richiede la disponibilità ad applicare ban a livello server, bloccare server ostili dalla federazione, e rispondere alle segnalazioni di abuso. Per la maggior parte degli operatori, la postura corretta è la registrazione chiusa (solo su invito) — ogni utente è qualcuno che si conosce, e la superficie di abuso scende praticamente a zero.
Posso usare il mio homeserver Matrix come sostituto di Slack / Discord al lavoro?
Sì — Element Server Suite e la combinazione sottostante Synapse + Element Web coprono il set di funzionalità «chat di team con stanze persistenti, thread, reazioni, huddle voce/video». Il divario principale rispetto a Slack sono le integrazioni di terze parti (meno app precostituite); il divario principale rispetto a Discord sono i canali vocali raffinati. Entrambi sono gestibili ma richiedono un po' di impegno operativo. Per un piccolo team che valuta la sovranità dei dati sopra la raffinatezza, il compromesso vale chiaramente.
Perché l'host da cui si affitta il VPS conta per un server Matrix?
Perché il protocollo di chat federato crea metadati persistenti su chi parla con chi e quando nell'homeserver. Quei metadati sono ricchi (grafo delle stanze federate, eventi di federazione, upload di media). Metterli su un host con KYC lega i metadati all'identità; metterli su un host in una giurisdizione ostile significa che un attore statale può costringerli. Un VPS nordico no-KYC allinea la postura dei metadati dell'host con la postura crittografica del protocollo — entrambe le metà della storia della privacy.
Un VPS nordico per il suo homeserver. KYC-free, pagamento in crypto.
Ravelin (2 vCPU, 4 GB, $5.90/mese) copre un Synapse federato a singolo utente. Iron (4 vCPU, 8 GB, $24.90/mese) è la risposta per il piccolo team.
Ultima revisione · 2026-05-20 · Fonti · Documentazione upstream Synapse, riferimento configurazione Element, specifica Matrix, EU DSA Articolo 6 · Cadenza · annuale
Anonymous VPS hosting in 2026 — the cluster.
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Fediverse instance, Docker Compose, federation-ready in 90 min.
What “no KYC” actually means — and what it does not.
Why Sweden, Finland, Norway and Iceland — the legal floor of each.
XMR end-to-end — wallet, transfer, confirmations, change.