[Home](https://servhidden.com/it) /
[Guide di Hosting Privato](https://servhidden.com/it/guides) /
Self-Hosting Matrix: federazione, metadati e cosa non copre la E2EE






Operaciones


# Self-Hosting di un Server Matrix



Un homeserver non è una scatola privata che parla di chat: è un nodo di replica in una rete pubblica. Cosa risolve davvero il self-hosting di Matrix, cosa lascia in chiaro la crittografia end-to-end, quale implementazione scegliere e quali decisioni operative sono irreversibili.


[Leer la guida](#guide-body)
[FAQ](#guide-faq)






## En questa pagina




- [Guida](#guide-body)

- [FAQ](#guide-faq)

- [Guide relacionullas](#guide-related)

- [Paginas consigliate](#guide-cta)






Senza KYC
Solo crypto
Nessun log
DMCA ignorato
Root completo
NVMe SSD





18 min di lettura
Aggiornato Aug 2026

En questa pagina

[01Cosa cambia davvero gestire il proprio homeserver](#cosa-cambia-davvero-gestire-il-proprio-homeserver)
[02La federazione è un protocollo di replica travestito da protocollo di chat](#la-federazione-è-un-protocollo-di-replica-travestito-da-prot)
[03Cosa copre la crittografia, e cosa resta in chiaro](#cosa-copre-la-crittografia-e-cosa-resta-in-chiaro)
[04Synapse, Dendrite o Conduit: cosa usare davvero](#synapse-dendrite-o-conduit-cosa-usare-davvero)
[05La configurazione della delega che tutti sbagliano](#la-configurazione-della-delega-che-tutti-sbagliano)
[06Dimensionarlo onestamente](#dimensionarlo-onestamente)
[07L'archivio media è una bomba a orologeria per il disco](#larchivio-media-è-una-bomba-a-orologeria-per-il-disco)
[08Registrazione, spam e la reputazione che erediti](#registrazione-spam-e-la-reputazione-che-erediti)
[09I bridge, e il conto di metadati che portano](#i-bridge-e-il-conto-di-metadati-che-portano)
[10Tenerlo in vita: chiavi, backup e aggiornamenti](#tenerlo-in-vita-chiavi-backup-e-aggiornamenti)
[11Dove si trova il server decide ancora il risultato](#dove-si-trova-il-server-decide-ancora-il-risultato)
[12La versione breve](#la-versione-breve)
[FAQDomande frequenti](#guide-faq)
[→Paginas consigliate](#guide-cta)







Ti metti a fare self-hosting di Matrix per impedire a un'azienda di conservare le tue conversazioni, e su questo punto funziona esattamente come promesso. Quello che sorprende dopo è la forma di ciò che hai installato: un homeserver non è una scatola privata che per caso parla di chat. È un nodo di replica in una rete pubblica, e la federazione si comporta molto più come un protocollo di pubblicazione di quanto la maggior parte dei nuovi amministratori si aspetti.

Niente di tutto ciò è un argomento contro il gestirne uno — è l'argomento per gestirne uno *deliberatamente*. La privacy che guadagni è reale ma specifica: la custodia passa a te, l'account non può essere chiuso da qualcun altro, e le questioni legali finiscono in una giurisdizione che hai scelto tu, non una scelta fatta da un'azienda. La privacy che non guadagni è altrettanto specifica, e vive quasi tutta nel divario tra "i messaggi sono cifrati" e "nessuno può dire chi sta parlando con chi". Questa guida copre entrambe le metà, poi i dettagli operativi che decidono se il server sarà ancora sano tra un anno.

## Cosa cambia davvero gestire il proprio homeserver

Comincia separando le minacce, perché un homeserver ne risolve alcune completamente, altre in parte, altre per niente. La tabella qui sotto è la versione onesta del discorso, e vale la pena leggerla prima di scegliere l'hardware, non dopo.

| Cosa ti preoccupa | Il tuo homeserver lo risolve? |
| --- | --- |
| Un'azienda che legge il contenuto dei tuoi messaggi | La crittografia end-to-end lo copre già nelle stanze private — e sì, il self-hosting elimina anche l'azienda |
| Un'azienda che profila con chi parli e quando | **In parte.** Smetti di alimentare un unico operatore centrale, e ora è il tuo server a conservare quel registro |
| Un account chiuso o sospeso da qualcun altro | **Sì.** Il vantaggio più netto di tutto l'esercizio, e il meno discusso |
| Una richiesta legale sui tuoi dati | **Si sposta, non sparisce.** La richiesta ora arriva a te, secondo la legge del paese che hai scelto |
| Altre parti che scoprono il tuo grafo sociale | **No.** Ogni server con un membro nella stanza riceve gli stessi dati di appartenenza che ricevi tu |
| Nascondere che il server esiste | **No.** La federazione richiede un nome pubblico e una porta raggiungibile; è l'opposto del nascosto |

Leggi con attenzione le ultime due righe, perché è lì che le aspettative si rompono. Se il tuo obiettivo è che nessuno possa stabilire che un servizio esiste, Matrix è lo strumento sbagliato e un [servizio onion](https://servhidden.com/it/guides/how-to-host-a-tor-hidden-service) è più vicino a quello giusto. Se il tuo obiettivo è custodia, controllo e giurisdizione, un homeserver è uno strumento eccellente e il resto di questa guida parla di come gestirlo bene.

Un homeserver è un partecipante in una rete pubblica, non una scatola privata: ogni server con un membro nella tua stanza conserva una propria copia di chi si è unito, quando e con quale frequenza scrive.

## La federazione è un protocollo di replica travestito da protocollo di chat

Ecco il meccanismo che spiega la maggior parte delle sorprese. Quando uno dei tuoi utenti entra in una stanza ospitata altrove, il tuo server non recupera i messaggi su richiesta come un client di posta. Entra nella stanza come partecipante in un grafo di eventi distribuito, poi **scarica e conserva una copia** degli eventi della stanza, della sua composizione e di abbastanza cronologia di stato da convalidare ciò che segue. Da quel momento la tua macchina detiene una replica, e ogni altro server partecipante ne detiene una a sua volta.

Le conseguenze vanno in entrambe le direzioni e nessuna delle due è intuitiva. I dati generati dai tuoi utenti — nome visualizzato, avatar, ingressi e uscite, timestamp, reazioni — vengono copiati su ogni server che ha un membro in quella stanza, e restano nei loro database indipendentemente da cosa elimini in seguito sul tuo. La redazione è una richiesta ai peer, non un comando. Non esiste un "annulla invio" attraverso una federazione di server gestiti indipendentemente, e aspettarselo è il fraintendimento più comune sul protocollo.

Nell'altra direzione, unirsi a grandi stanze pubbliche significa importare sul tuo disco la cronologia di altre persone. Ecco perché un homeserver nuovo di zecca con tre utenti può portarsi dietro decine di gigabyte di database: non perché i tuoi tre utenti abbiano scritto molto, ma perché si sono uniti a stanze con cinquantamila membri e anni di stato. Scegliere le stanze con attenzione è una decisione di capacità tanto quanto di privacy.

## Cosa copre la crittografia, e cosa resta in chiaro

Matrix cifra il contenuto dei messaggi con Megolm, e nelle stanze private è attiva per impostazione predefinita. Questo protegge la parte a cui le persone tengono di più e funziona davvero — il tuo server conserva testo cifrato che non può leggere, il che è una proprietà reale e utile quando il server è hardware noleggiato. La busta attorno al messaggio è tutta un'altra storia, e il divario è più ampio di quanto ammettano la maggior parte dei riassunti.

| Segnale | Cifrato? | Visibile a |
| --- | --- | --- |
| Testo del messaggio e contenuto dei file | **Sì** | Solo i dispositivi verificati dei membri della stanza |
| Chi è nella stanza, e ogni ingresso o uscita | No | Ogni homeserver con un membro in quella stanza |
| Timestamp, frequenza dei messaggi, orari di attività | No | Ogni homeserver partecipante |
| Nomi visualizzati, avatar, presenza e digitazione | No | Ogni homeserver partecipante |
| Nome, argomento e avatar della stanza | No | Ogni homeserver partecipante |
| Dimensione dell'allegato e tempistica del trasferimento | No | Ogni homeserver partecipante |
| Il dominio del tuo server e il suo indirizzo IP | No | L'intera federazione — è voluto così |

La lettura pratica: la crittografia protegge il *cosa*, la federazione pubblica il *chi, quando e con quale frequenza*. Per la maggior parte delle comunità questo compromesso è del tutto accettabile e l'onestà è il punto. Per un modello di minaccia in cui il grafo sociale stesso è la parte sensibile, un protocollo federato è strutturalmente la forma sbagliata, e nessuna opzione di configurazione lo cambia.

## Synapse, Dendrite o Conduit: cosa usare davvero

In pratica contano tre implementazioni, e la scelta è soprattutto una decisione di risorse più che filosofica.

- **Synapse** è il server di riferimento, scritto in Python, e l'unico dove ogni funzione funziona fin dal primo giorno. È anche il più esigente: la memoria cresce con il numero e la dimensione delle stanze a cui si uniscono i tuoi utenti, e un server trafficato prima o poi va diviso in processi worker. Scegli questo quando ti serve che spazi, strumenti di moderazione, bridge e API di amministrazione si comportino esattamente come documentato.

- **Dendrite** è la riscrittura in Go. Sensibilmente più leggero di Synapse e perfettamente usabile per un piccolo server, al costo di qualche ritardo nelle funzionalità. Un'opzione intermedia ragionevole quando Synapse ti sembra pesante per il numero di persone che hai davvero.

- **Conduit** e il suo fork attivamente sviluppato conduwuit sono scritti in Rust e distribuiti come un singolo binario con database integrato. Fanno girare un server per una famiglia o una piccola community sul piano più economico che vendiamo senza battere ciglio. Il compromesso è un ecosistema più piccolo: alcuni strumenti di amministrazione e qualche bridge danno per scontato Synapse.

Per un primo server con una manciata di utenti, il software della famiglia Conduit su un piccolo [VPS](https://servhidden.com/it/vps) è la strada meno dolorosa verso qualcosa che funziona e resta economico. Per tutto ciò che prevedi possa crescere — una community pubblica, un'azienda, un progetto con bridge — parti direttamente con Synapse e salta la migrazione, perché passare da un'implementazione all'altra in seguito è un esercizio di esportazione e ricostruzione, non una modifica di configurazione.

## La configurazione della delega che tutti sbagliano

Matrix separa il nome nei tuoi ID utente dalla macchina che serve il traffico, e invertire questo è l'errore permanente più comune nel self-hosting. Il tuo server_name è il dominio che compare dopo i due punti in ogni ID utente sul tuo server. Diventa parte della tua identità nella federazione nel momento in cui viene firmato il primo evento, e **non può essere cambiato in seguito** senza abbandonare ogni account e stanza sulla macchina.

La configurazione che quasi sempre vuoi: server_name è il tuo dominio nudo, mentre il software gira su un sottodominio. Colleghi i due con la delega, in uno di due modi. Il più semplice è un file JSON statico servito su /.well-known/matrix/server sul dominio nudo, che indica l'host e la porta reali. L'alternativa è un record DNS, _matrix._tcp, che punta allo stesso posto. Servi anche il file lato client su /.well-known/matrix/client, così le app trovano l'homeserver a partire dal solo indirizzo.

**Decidi il nome prima di installare qualsiasi cosa.** Impostare server_name sul sottodominio solo perché è lì che il software si trova a girare è l'errore classico, ed è irreversibile: ogni ID utente, ID stanza ed evento firmato lo porta per sempre. Scegli il dominio che vorresti stampato su un biglietto da visita, delega verso qualunque host il processo ascolti davvero, e mantieni un TLS valido su entrambi i nomi — un certificato scaduto sull'host delegato blocca la federazione anche se l'app sembra funzionare bene in locale.

## Dimensionarlo onestamente

Matrix in condizioni normali non è vincolato dalla CPU; è vincolato dalla memoria e dal comportamento del database. I dati pubblicati per Synapse sono una base utile: circa 2 GB di RAM per iniziare, circa 4 GB una volta che hai dieci-cinquanta utenti attivi, e 8 GB o più oltre un centinaio. I server della famiglia Conduit restano ben al di sotto. Quello che quei numeri omettono è che il consumo segue le *stanze a cui ci si unisce*, non le persone registrate — cinque utenti in cento grandi stanze pubbliche costano molto di più di cinquanta utenti in una manciata di stanze private.

Ne seguono due regole pratiche. Metti il database su storage veloce e dagli spazio per crescere, perché il pattern di scrittura è piccolo e costante piuttosto che a raffiche. E non dimensionare in base al numero di utenti di oggi: dimensiona in base alle stanze a cui quegli utenti si uniranno nel primo mese, che di solito è dove si nasconde la sorpresa. Il nostro piano base regge comodamente un piccolo server Conduit o Dendrite, mentre un'istanza Synapse per una community vera appartiene a un piano di fascia media o superiore — la [pagina dedicata all'hosting per chat](https://servhidden.com/it/use-cases/matrix-xmpp-hosting) elenca i piani che consigliamo per ciascuno di questi scenari.

Qui l'uptime conta più che per la maggior parte dei carichi di lavoro, perché un server di chat fermo non è solo non disponibile — sta silenziosamente perdendo eventi che i peer ritenteranno per un po' e poi smetteranno di offrire. La federazione perdona i minuti ed è spietata sui giorni.

## L'archivio media è una bomba a orologeria per il disco

Ogni immagine, video e file che attraversa una stanza in cui si trovano i tuoi utenti può finire in cache sul tuo disco, compresi i media remoti che i tuoi utenti non hanno mai aperto. La conservazione predefinita in Synapse li mantiene a tempo indeterminato. Il risultato è prevedibile e continua a sorprendere: un server con un database stabile e una cartella media che cresce silenziosamente finché il volume si riempie, e a quel punto il sintomo non è "disco pieno" ma "il server si comporta in modo strano".

Imposta una policy di conservazione per i media remoti fin dal primo giorno, non dopo il primo disservizio. Synapse espone le impostazioni di conservazione in homeserver.yaml, oltre a endpoint di amministrazione per eliminare cronologia vecchia e file in cache; synapse-compress-state recupera una quantità sorprendente di spazio dalle tabelle di stato su un server datato. Tieni d'occhio sia il database sia il percorso dei media, e imposta un avviso sullo spazio libero invece che sul servizio caduto — il secondo sintomo arriva giorni dopo il primo.

Un'impostazione merita una decisione, non un valore predefinito. Le anteprime degli URL fanno sì che il tuo server recuperi qualsiasi link pubblicato in una stanza, il che significa che **l'indirizzo IP del tuo server fa una richiesta in uscita verso terzi nell'istante in cui qualcuno incolla un link** — incluso un link scelto apposta per vedere chi abbocca. Se il tuo homeserver è dietro un front e il suo indirizzo reale conta, valutalo con attenzione; la nostra guida su come [nascondere un indirizzo di origine](https://servhidden.com/it/guides/hiding-your-origin-server-ip) copre la stessa categoria di fuga di dati in maggior dettaglio.

## Registrazione, spam e la reputazione che erediti

La registrazione aperta su un homeserver pubblico è un invito, e non del tipo che vuoi. Le iscrizioni automatiche trasformano un piccolo server in una fonte di spam nel giro di pochi giorni, e la conseguenza non resta locale: altri homeserver aggiungono il tuo dominio a liste di controllo degli accessi, e una volta che il tuo nome compare su abbastanza di esse, i tuoi utenti legittimi smettono di poter partecipare alle stanze altrove. Recuperare una reputazione di dominio bruciata è molto più difficile che evitarlo, esattamente come per la [deliverability della posta](https://servhidden.com/it/guides/offshore-mail-server-setup).

Le impostazioni predefinite difendibili sono semplici. Tieni enable_registration disattivato per un server privato e distribuisci gli account tu stesso. Se vuoi tenere la porta aperta, vincolala: registration_requires_token trasforma la registrazione in un sistema a inviti senza alcun servizio di terze parti, e un captcha aiuta contro la parte più grossolana del problema. Per le stanze che amministri, i bot di moderazione della famiglia Mjolnir e Draupnir ti permettono di applicare liste di ban e ACL delle stanze su un'intera community invece che una stanza alla volta.

Vale la pena saperlo anche al contrario: i nostri intervalli di indirizzi non compaiono nelle blocklist ACL di Matrix che circolano tra gli homeserver, quindi un nuovo server parte da una reputazione pulita. Cosa succede a quella reputazione in seguito dipende da come gestisci la registrazione, non da dove si trova la macchina.

## I bridge, e il conto di metadati che portano

I bridge sono il motivo onesto per cui molte persone restano su Matrix: un unico client per stanze che vivono su altre reti. Cambiano anche la posizione di sicurezza del tuo server in un modo facile da trascurare. Un bridge detiene le credenziali dell'account remoto e, al confine dove i protocolli si incontrano, gestisce necessariamente i messaggi in una forma che può convertire — il che significa che il processo del bridge vede in chiaro un traffico che è cifrato end-to-end su entrambi i suoi lati.

Questo non è un motivo per evitare i bridge. È un motivo per trattare l'host del bridge come infrastruttura sensibile: è la macchina che, se compromessa, espone gli account per cui fa da tramite. Ogni bridge raddoppia più o meno l'impronta di memoria di un piccolo server, quindi pianifica la capacità di conseguenza, e dedica alla sua collocazione la stessa attenzione che hai dedicato all'homeserver stesso — il ragionamento della nostra [guida alla giurisdizione](https://servhidden.com/it/guides/choosing-an-offshore-jurisdiction) vale con ancora più forza per una macchina che detiene contemporaneamente le credenziali di più reti.

## Tenerlo in vita: chiavi, backup e aggiornamenti

Un server Matrix ha un file la cui perdita è irrecuperabile in un modo che non ha nulla a che vedere con il volume di dati. La chiave di firma — signing.key in Synapse — è ciò che dimostra che gli eventi che dichiarano di provenire dal tuo dominio provengono davvero da lì. Se la perdi non puoi più essere credibilmente il tuo server; i peer rifiuteranno eventi firmati da uno sconosciuto che detiene il tuo nome. Fanne un backup separato da tutto il resto, e tieni quella copia fuori dalla macchina.

**Fai il backup della chiave e del database, e capisci perché ripristinarne uno senza l'altro è pericoloso.** Riportare indietro un database Matrix a uno snapshot più vecchio mette il tuo server in uno stato che i suoi peer hanno già superato, e la divergenza che ne risulta è molto più difficile da riparare rispetto a una ricostruzione pulita. Fai dump coerenti con pg_dump, tienili fuori dalla macchina, e ricorda che su questa piattaforma non esiste una copia del provider su cui contare — non viene conservato nulla dopo la cessazione, che è proprio il punto dell'accordo ed è trattato nella nostra [guida al backup](https://servhidden.com/it/guides/vps-backup-strategy).

Gli aggiornamenti sono ordinaria amministrazione, ma non facoltativi. Le versioni dell'homeserver portano migrazioni dello schema, e saltarne molte trasforma un aggiornamento di cinque minuti in un pomeriggio intero. Leggi le note di rilascio prima di aggiornare, aggiorna con una regolarità tale che ogni passo resti piccolo, e applica l'igiene di base dell'host dalla [checklist di hardening della prima ora](https://servhidden.com/it/guides/first-hour-vps-hardening-checklist) — un server di chat è un servizio esposto a internet e di lunga durata con un database annesso, e merita lo stesso trattamento.

## Dove si trova il server decide ancora il risultato

Tutto quanto sopra è configurazione. La parte che la configurazione non può toccare è quale sistema legale riceve una richiesta sui tuoi utenti, e per un server di comunicazioni questa domanda pesa più che per un sito web. Un homeserver conserva in chiaro registri di appartenenza, timestamp e dati del grafo sociale anche quando i corpi dei messaggi sono cifrati — quindi la giurisdizione che lo ospita è la giurisdizione che governa l'accesso a quel registro.

Questo è l'argomento pratico per scegliere una posizione di proposito e non solo in base alla latenza. Ne gestiamo sette, e i compromessi tra loro sono spiegati nella [guida alla giurisdizione](https://servhidden.com/it/guides/choosing-an-offshore-jurisdiction) e nella [pagina delle sedi](https://servhidden.com/it/locations). L'altra metà della stessa domanda è chi il provider sa che tu sia: un account senza alcuna identità collegata non può produrre documenti d'identità che non ha mai raccolto, ed è proprio per questo che l'[hosting no-KYC](https://servhidden.com/it/no-kyc-hosting) e le comunicazioni self-hosted continuano a comparire nella stessa conversazione. Nessuna delle due è una difesa contro un tribunale che ha già il tuo nome, e la nostra [guida OpSec](https://servhidden.com/it/guides/server-opsec-staying-anonymous) è schietta su dove si trovi quel limite.

## La versione breve

Se porti via sei cose da questa pagina, porta via queste:

- Scegli il server_name prima di installare qualsiasi cosa — è l'unica decisione che non potrai mai rivedere.

- Delega con /.well-known/matrix/server o un record SRV, e mantieni un TLS valido su entrambi i nomi.

- Dimensiona in base alle stanze a cui i tuoi utenti si uniranno, non a quanti utenti hai.

- Imposta la conservazione dei media fin dal primo giorno, e decidi tu sulle anteprime degli URL invece di ereditare il valore predefinito.

- Tieni la registrazione chiusa o vincolata a token; una reputazione di dominio bruciata è costosa da rimediare.

- Fai il backup di signing.key separatamente, e non riportare mai indietro il database lasciando indietro i tuoi peer.

Fai queste cose e il server risulterà poco appariscente, esattamente ciò che un server di chat dovrebbe essere. Quello che ottieni in cambio merita di essere guardato con chiarezza: non l'invisibilità, e non un protocollo che nasconde chi parla con chi, ma conversazioni il cui contenuto è tuo, un account che nessun altro può chiudere, e una macchina sotto un sistema legale che hai scelto deliberatamente. [Metti un homeserver dove l'hai scelto tu](https://servhidden.com/it/use-cases/matrix-xmpp-hosting), e lascia che la federazione arrivi a lui.





FAQ

## Matrix self-hosted — domande frequenti





### 01
Il self-hosting di Matrix rende i miei messaggi più privati?



Cambia la custodia, non la crittografia. I contenuti dei messaggi nelle stanze private sono già cifrati end-to-end prima di raggiungere qualsiasi server, compreso uno commerciale, quindi il self-hosting non cifra nulla che non fosse già cifrato. Cambia invece chi detiene i metadati, chi può chiudere il tuo account e quale sistema legale riceve una richiesta al riguardo. Sono vantaggi reali, ma diversi da quelli che di solito dai per scontati.





### 02
Gli admin degli altri homeserver possono leggere le mie stanze?



Non possono leggere il contenuto dei messaggi cifrati, ma possono vedere molto altro. Ogni homeserver con un utente nella tua stanza riceve e conserva lo stato della stanza: chi ne fa parte, quando le persone sono entrate o uscite, i nomi visualizzati, i timestamp, le reazioni e la dimensione e i tempi dei trasferimenti di file. Quei dati restano nel loro database, alle loro condizioni, e cancellarli dalla tua parte non li rimuove dalla loro.





### 03
Synapse o Conduit: quale devo usare?



Conduit o conduwuit per un piccolo server privato, perché un singolo binario Rust con database integrato gira bene anche su un piano entry-level e richiede pochissima manutenzione. Synapse per tutto ciò che prevedi possa crescere, ospitare bridge o richiedere moderazione pubblica, perché è l'implementazione di riferimento e ogni funzione e strumento di amministrazione la considera prioritaria. Passare da un'implementazione all'altra in seguito significa esportare e ricostruire tutto, quindi scegli pensando al secondo anno.





### 04
Quanta RAM serve a un server Matrix?



Per Synapse, circa 2 GB per iniziare, circa 4 GB per dieci-cinquanta utenti attivi, e 8 GB o più oltre un centinaio. I server della famiglia Conduit restano ben al di sotto di queste cifre. La correzione importante è che la memoria segue il numero e la dimensione delle stanze a cui si uniscono i tuoi utenti, non il numero di account che ospiti: pochi utenti in molte grandi stanze pubbliche costano più di tanti utenti in piccole stanze private.





### 05
Perché il mio homeserver usa così tanto disco?



Due cause, di solito insieme. Unirsi a grandi stanze federate porta sul tuo disco la cronologia e lo stato di altri server, quindi anche un server piccolo può avere onestamente un database enorme. E i media remoti vengono messi in cache a tempo indeterminato per impostazione predefinita, quindi immagini e file provenienti da stanze in cui i tuoi utenti sono semplicemente presenti si accumulano per sempre. Imposta presto una policy di conservazione per i media remoti, elimina periodicamente la cronologia vecchia e monitora lo spazio libero invece di aspettare i sintomi.





### 06
Devo lasciare aperta la registrazione?



Non su un server a cui tieni. La registrazione aperta attira iscrizioni automatiche che trasformano il tuo dominio in una fonte di spam, e gli altri homeserver rispondono aggiungendolo a liste di controllo degli accessi condivise: a quel punto i tuoi utenti legittimi vengono bloccati dalle stanze altrove. Tieni la registrazione disabilitata e crea tu stesso gli account, oppure vincolala con dei token di registrazione così la porta si apre solo per chi hai invitato.





### 07
Eseguire un bridge rompe la crittografia end-to-end?



Sposta il confine. Un bridge deve convertire tra due protocolli, quindi in quel punto gestisce necessariamente i messaggi in forma leggibile e detiene le credenziali dell'account remoto. Il traffico resta cifrato sul lato Matrix e sull'altra rete, ma il bridge stesso è un punto in cui entrambi sono leggibili. Tratta la macchina che lo esegue come infrastruttura sensibile, e tieni presente che ogni bridge raddoppia più o meno l'impronta di memoria di un piccolo server.





### 08
Posso cambiare il mio server_name in seguito?



No, e vale la pena leggerlo due volte prima di installare qualsiasi cosa. Il server_name è incorporato in ogni ID utente, ID stanza ed evento firmato che il tuo server produce, quindi cambiarlo significa abbandonare gli account e le stanze invece di rinominarli. Scegli il dominio nudo che vuoi davvero usare, poi usa la delega .well-known o un record SRV per puntarlo verso qualunque host esegua il software.




Guide relacionullas

## Seguir leyendo


[### Come Scegliere una Giurisdizione di Hosting Offshore in 2026

Compra


Un quadro decisionale pratico per scegliere una giurisdizione offshore: leggi sulla conservazione dei dati, esposizione ai trattati MLAT, posizione sul DMCA, velocità dei tribunali e applicazione reale della legge — paese per paese.


FAQ di 6 domande](https://servhidden.com/it/guides/choosing-an-offshore-jurisdiction)
[### VPS vs Server Dedicato per Workload Critici per la Privacy

Compra


Quando un VPS va bene, quando la tenancy condivisa è un rischio e quando il bare metal è l'unica risposta onesta. Isolamento hardware, rischio hypervisor e costo rispetto al modello di minaccia.


FAQ di 6 domande](https://servhidden.com/it/guides/vps-vs-dedicated-for-privacy)
[### VPN Autogestionulla in un VPS Senza KYC: WireGuard vs OpenVPN

Operaciones


Perché una VPN self-hosted batte i provider commerciali, e come si confrontano davvero WireGuard e OpenVPN su privacy, prestazioni e rischio operativo nel 2026.


FAQ di 6 domande](https://servhidden.com/it/guides/self-hosted-vpn-wireguard-vs-openvpn)
[### RTX 4090 vs H100 SXM5 per inferenza IA (e dove rientra la RTX 5090)

Compra


Guida all'acquisto: quale GPU NVIDIA scegliere per carichi di lavoro LLM, immagine, video, voce e fine-tuning self-hosted nel 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs doppio H100 — VRAM, throughput, $/token, quando vince ciascuna.


FAQ di 6 domande](https://servhidden.com/it/guides/rtx-4090-vs-h100-for-ai-inference)
[### RDP Windows Offshore per Trading Forex con MT4 / MT5 / cTrader

Operaciones


Guida completa: perché scegliere un RDP Windows per il trading forex, come scegliere una giurisdizione offshore a bassa latenza, la configurazione di MT4 / MT5 / cTrader / Expert Advisor, la latenza verso i server dei broker e il percorso di checkout senza KYC.


FAQ di 6 domande](https://servhidden.com/it/guides/offshore-windows-rdp-for-forex-trading)
[### Hosting con DMCA Ignorato: Cosa Significa Davvero nel 2026

Compra


Cosa acquista davvero un hosting "DMCA ignored", quali giurisdizioni lo supportano concretamente, i carichi di lavoro che ne hanno bisogno e le insidie sul copyright che il termine non copre.


FAQ di 6 domande](https://servhidden.com/it/guides/dmca-ignored-hosting-explained)
[### Registrazione Anonima di Domini con Crypto: Privacy WHOIS nel 2026

Privacy


Una guida pratica 2026 per registrare domini senza rivelare la propria identità: regimi WHOIS per TLD, scelta del registrar, opzioni di pagamento crypto e gli errori operativi che vi espongono comunque.


FAQ di 6 domande](https://servhidden.com/it/guides/anonymous-domain-registration-with-crypto)
[### Pagamenti Crypto per Hosting: Monero vs Bitcoin vs USDT

Privacy


Come la scelta della moneta di pagamento influisce su ciò che il tuo host scopre di te. Privacy, commissioni, finalità ed esposizione all'analisi della catena per XMR, BTC e USDT — con una raccomandazione chiara.


FAQ di 6 domande](https://servhidden.com/it/guides/crypto-payments-monero-vs-bitcoin-vs-usdt)
[### L'hosting offshore è davvero anonimo? Una risposta onesta

Privacy


L'hosting offshore no-KYC elimina l'identità che un host normale raccoglie — ma "anonimo" dipende dal pagamento, dai log del provider e dalla tua opsec. Ecco cosa è davvero tracciabile.


FAQ di 6 domande](https://servhidden.com/it/guides/is-offshore-hosting-truly-anonymous)
[### La prima ora di hardening di un VPS: una checklist

Operaciones


Una checklist concreta e ordinata per mettere in sicurezza un nuovo VPS in meno di un'ora: chiavi SSH, un firewall, fail2ban, aggiornamenti automatici e la riduzione della superficie d'attacco che blocca la maggior parte degli attacchi opportunistici.


FAQ di 6 domande](https://servhidden.com/it/guides/first-hour-vps-hardening-checklist)
[### Cos'è l'Hosting No-KYC? Definizione, Legalità e Come Funziona

Privacy


L'hosting No-KYC ti permette di noleggiare un server senza alcuna verifica d'identità — nessun nome, nessuna email, nessun documento. Ecco cosa significa esattamente, come funziona tecnicamente, se è legale e come scegliere un provider affidabile.


FAQ di 6 domande](https://servhidden.com/it/guides/what-is-no-kyc-hosting)
[### L'Hosting Offshore è Legale? La Risposta Onesta per il 2026

Compra


L'hosting offshore è legale — per te e per il provider. Ecco cosa significa davvero il termine, dove si trova il confine giuridico, i miti da sfatare e come usarlo in modo responsabile.


FAQ di 6 domande](https://servhidden.com/it/guides/is-offshore-hosting-legal)
[### Come pagare l'hosting con Monero (XMR) — Guida passo dopo passo

Privacy


Una guida passo dopo passo per pagare un VPS o un server dedicato con Monero (XMR): perché XMR è l'opzione più privata, come ottenerlo e come funziona il checkout — dalla fattura al server operativo in pochi minuti.


FAQ di 6 domande](https://servhidden.com/it/guides/how-to-pay-for-hosting-with-monero)
[### Come ospitare un sito web in modo anonimo — Guida pratica 2026

Privacy


Una guida pratica e stratificata per ospitare un sito web senza alcuna identità associata: l'account, il pagamento, il dominio, la giurisdizione, la connessione e il contenuto — ogni livello spiegato nel dettaglio.


FAQ di 6 domande](https://servhidden.com/it/guides/how-to-host-a-website-anonymously)
[### Come Configurare una VPN WireGuard su un VPS — Guida Passo dopo Passo

Operaciones


Costruisci la tua VPN privata su un VPS con WireGuard: perché una VPN self-hosted supera quella commerciale, la configurazione completa dall'installazione a un client connesso, e come rafforzarne la sicurezza.


FAQ di 6 domande](https://servhidden.com/it/guides/how-to-set-up-wireguard-vpn-on-a-vps)
[### Come fare self-hosting di un LLM su un server GPU — Guida 2026

Operaciones


Esegui il tuo modello linguistico su un server GPU in affitto: perché il self-hosting supera un'API, quale GPU e modello scegliere, la configurazione con Ollama o vLLM, e i costi reali.


FAQ di 6 domande](https://servhidden.com/it/guides/self-host-an-llm-on-a-gpu-server)
[### Hosting Bulletproof vs Hosting Offshore — Qual è la Differenza?

Compra


Hosting bulletproof e hosting offshore vengono continuamente confusi — ma non sono la stessa cosa. Ecco la vera differenza, perché conta e quale dei due fa davvero al caso tuo.


FAQ di 6 domande](https://servhidden.com/it/guides/bulletproof-vs-offshore-hosting)
[### Come acquistare un VPS con Bitcoin — Guida passo dopo passo (2026)

Compra


Una guida accessibile anche ai principianti per acquistare un VPS con Bitcoin: come ottenere BTC, scegliere un piano, pagare la fattura e cosa si ottiene — un server attivo senza carta e senza nome associato.


FAQ di 6 domande](https://servhidden.com/it/guides/how-to-buy-a-vps-with-bitcoin)
[### I migliori paesi per l'hosting ignorato dal DMCA nel 2026

Compra


Dove ospitare i tuoi server quando vuoi essere al riparo dai takedown in stile statunitense: le giurisdizioni che funzionano davvero, cosa significa concretamente "ignorato dal DMCA" e come scegliere.


FAQ di 6 domande](https://servhidden.com/it/guides/best-countries-for-dmca-ignored-hosting)
[### Come ospitare un servizio nascosto Tor (sito .onion) — Guida 2026

Operaciones


Configura un servizio onion Tor su un VPS: cos'è un servizio nascosto, perché rappresenta la forma più solida di hosting anonimo, la procedura completa e come mantenerlo davvero anonimo.


FAQ di 6 domande](https://servhidden.com/it/guides/how-to-host-a-tor-hidden-service)
[### Configurazione di un Server Mail Offshore — Self-Hosting di Email Private nel 2026

Operaciones


Gestisci il tuo server email privato su un VPS offshore: perché ospitare la posta in autonomia, cosa ti serve, come configurare uno stack mail all-in-one e come garantire la consegna dei messaggi.


FAQ di 6 domande](https://servhidden.com/it/guides/offshore-mail-server-setup)
[### Guida all'Hosting di Nodi Crypto — Esegui un Nodo Blockchain su un VPS

Operaciones


Come ospitare un nodo blockchain su un server: perché gestire il proprio nodo, come dimensionare il server per Bitcoin, Ethereum, Monero e non solo, la configurazione e come mantenerlo privato.


FAQ di 6 domande](https://servhidden.com/it/guides/crypto-node-hosting-guide)
[### GPU Hosting per Stable Diffusion — Esegui il Tuo Server di Immagini

Operaciones


Esegui Stable Diffusion sul tuo server GPU dedicato: perché fare self-hosting della generazione di immagini, quale GPU scegliere, la configurazione con una web UI e il confronto dei costi rispetto a un servizio in hosting.


FAQ di 6 domande](https://servhidden.com/it/guides/gpu-hosting-for-stable-diffusion)
[### Server OpSec — Restare Anonimi Quando Gestisci un Server

Privacy


Sicurezza operativa per chi gestisce un server anonimo: gli errori che espongono l'identità, le abitudini che li prevengono e come tenere davvero separate le identità.


FAQ di 6 domande](https://servhidden.com/it/guides/server-opsec-staying-anonymous)
[### Guida alla configurazione di una seedbox — Costruisci la tua seedbox privata nel 2026

Operaciones


Come costruire la propria seedbox su un server: cos'è una seedbox, come dimensionarla, come installare un client torrent con interfaccia web e come mantenerla privata e sicura.


FAQ di 6 domande](https://servhidden.com/it/guides/seedbox-setup-guide)
[### Come aggirare la censura DPI con il tuo VPS (guida 2026)

Privacy


La tua VPN ha smesso di funzionare? Come aggirare la censura DPI con il tuo VPS: cosa rileva davvero la deep packet inspection, quale dei cinque protocolli del 2026 batte quale tipo di blocco, e una guida completa a VLESS+REALITY.


FAQ di 6 domande](https://servhidden.com/it/guides/bypass-dpi-censorship-with-your-own-vps)
[### Crittografia full-disk su un VPS: setup LUKS e cosa protegge davvero

Operaciones


Come cifrare un VPS con LUKS: volumi dati cifrati, cifratura full-root con sblocco remoto via SSH, le impostazioni che contano su un server piccolo, e cosa blocca davvero la crittografia del disco.


FAQ di 8 domande](https://servhidden.com/it/guides/full-disk-encryption-on-a-vps)
[### Nascondere l'IP del server di origine: CDN, reverse proxy e cosa trapela

Privacy


Se mettere una CDN davanti a un server offshore: cosa nasconde, lo sportello reclami che erediti, i sei modi in cui un IP di origine trapela comunque, e come verificare il tuo.


FAQ di 8 domande](https://servhidden.com/it/guides/hiding-your-origin-server-ip)
[### Backup VPS: Strategia Cifrata, Offsite e Che Funziona Davvero

Operaciones


Il tuo host non conserva backup. Cosa distrugge davvero i server, perché il backup push muore con loro, restic contro BorgBackup, e come testare un vero ripristino.


FAQ di 8 domande](https://servhidden.com/it/guides/vps-backup-strategy)
[### Migrare un Sito su Hosting Offshore Senza Downtime

Operaciones


L'ordine che rende noiosa una migrazione di host: abbassa il TTL del DNS con giorni di anticipo, fai girare entrambi i server in parallelo, blocca le scritture per minuti anziché ore — e ripulisci la traccia di DNS passivo, Certificate Transparency e WHOIS che il trasloco lascia dietro di sé.


FAQ di 8 domande](https://servhidden.com/it/guides/migrate-website-to-offshore-hosting)
[### How to Self-Host a Crypto Payment Gateway with BTCPay Server

Operaciones


Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out.


FAQ di 8 domande](https://servhidden.com/it/guides/self-host-a-crypto-payment-gateway)




## Gestisci l'homeserver dove hai scelto tu



Sette giurisdizioni, root completo, ISO personalizzata e banda illimitata su ogni piano — da 7,50 $/mese per un piccolo server Conduit o Dendrite. Niente KYC, niente email, solo crypto.


[Vedi i Piani VPS](https://servhidden.com/it/vps)
[Todas le località](https://servhidden.com/it/locations)
[Hosting offshore](https://servhidden.com/it/anonymous-hosting)


## Structured data (JSON-LD)

```json
{
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://servhidden.com/#organization",
    "name": "ServHidden",
    "url": "https://servhidden.com",
    "description": "VPS e server dedicati offshore in 7 giurisdizioni. Nessun KYC, nessun log, solo crypto. Privacy per architettura.",
    "logo": {
        "@type": "ImageObject",
        "url": "https://servhidden.com/ServHidden.webp",
        "width": 512,
        "height": 512
    },
    "foundingDate": "2025",
    "areaServed": [
        {
            "@type": "Country",
            "name": "Iceland"
        },
        {
            "@type": "Country",
            "name": "Panama"
        },
        {
            "@type": "Country",
            "name": "Moldova"
        },
        {
            "@type": "Country",
            "name": "Romania"
        },
        {
            "@type": "Country",
            "name": "Switzerland"
        },
        {
            "@type": "Country",
            "name": "Netherlands"
        },
        {
            "@type": "Country",
            "name": "Russia"
        }
    ],
    "knowsAbout": [
        "Offshore hosting",
        "Offshore VPS",
        "Bare-metal dedicated servers",
        "DMCA-ignored hosting",
        "No KYC hosting",
        "Cryptocurrency payments",
        "Privacy engineering",
        "Token-based authentication",
        "Anonymous domain name registration",
        "No-KYC domain registrar",
        "WHOIS privacy",
        "Cheap .com domains",
        "Crypto-paid domain names",
        "NVIDIA GPU compute",
        "Windows RDP hosting",
        "Agentic commerce"
    ],
    "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "url": "https://servhidden.com/contact",
        "availableLanguage": [
            "en",
            "ru",
            "zh",
            "es",
            "fr",
            "de",
            "pt",
            "ar",
            "ja",
            "ko",
            "hi",
            "id",
            "it",
            "tr",
            "fa",
            "vi"
        ]
    },
    "sameAs": [
        "https://servhidden.com/canary",
        "https://servhidden.com/press"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "WebSite",
    "@id": "https://servhidden.com/#website",
    "url": "https://servhidden.com",
    "name": "ServHidden",
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "inLanguage": [
        "en",
        "ru",
        "zh",
        "es",
        "fr",
        "de",
        "pt",
        "ar",
        "ja",
        "ko",
        "hi",
        "id",
        "it",
        "tr",
        "fa",
        "vi"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "Self-Hosting Matrix: federazione, metadati e cosa non copre la E2EE",
    "description": "Cosa ti dà davvero un homeserver Matrix: Synapse contro Conduit, il server_name che non puoi mai cambiare, i media che riempiono il disco e cosa rivela la federazione.",
    "image": "https://servhidden.com/assets/img/guides/self-host-a-matrix-server.webp?v=1787253905",
    "author": {
        "@type": "Organization",
        "@id": "https://servhidden.com/#editorial",
        "name": "ServHidden Editorial",
        "url": "https://servhidden.com/about",
        "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.",
        "knowsAbout": [
            "Offshore hosting jurisdictions",
            "Data retention law",
            "MLAT and judicial cooperation",
            "WireGuard and OpenVPN deployment",
            "Tor relay operation",
            "Monero and Bitcoin payment privacy",
            "KVM virtualization and bare-metal hosting",
            "DMCA-ignored hosting"
        ],
        "parentOrganization": {
            "@id": "https://servhidden.com/#organization"
        }
    },
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "datePublished": "2026-08-20T00:00:00+00:00",
    "dateModified": "2026-08-21T00:00:00+00:00",
    "mainEntityOfPage": "https://servhidden.com/guides/self-host-a-matrix-server",
    "inLanguage": "it",
    "keywords": "server Matrix self-hosted, self-hosting Matrix, installare Synapse, homeserver Matrix, server di chat privato, VPS per Matrix, Synapse vs Conduit, federazione Matrix privacy",
    "articleSection": "Operaciones",
    "wordCount": 3473
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "Il self-hosting di Matrix rende i miei messaggi più privati?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Cambia la custodia, non la crittografia. I contenuti dei messaggi nelle stanze private sono già cifrati end-to-end prima di raggiungere qualsiasi server, compreso uno commerciale, quindi il self-hosting non cifra nulla che non fosse già cifrato. Cambia invece chi detiene i metadati, chi può chiudere il tuo account e quale sistema legale riceve una richiesta al riguardo. Sono vantaggi reali, ma diversi da quelli che di solito dai per scontati."
            }
        },
        {
            "@type": "Question",
            "name": "Gli admin degli altri homeserver possono leggere le mie stanze?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Non possono leggere il contenuto dei messaggi cifrati, ma possono vedere molto altro. Ogni homeserver con un utente nella tua stanza riceve e conserva lo stato della stanza: chi ne fa parte, quando le persone sono entrate o uscite, i nomi visualizzati, i timestamp, le reazioni e la dimensione e i tempi dei trasferimenti di file. Quei dati restano nel loro database, alle loro condizioni, e cancellarli dalla tua parte non li rimuove dalla loro."
            }
        },
        {
            "@type": "Question",
            "name": "Synapse o Conduit: quale devo usare?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Conduit o conduwuit per un piccolo server privato, perché un singolo binario Rust con database integrato gira bene anche su un piano entry-level e richiede pochissima manutenzione. Synapse per tutto ciò che prevedi possa crescere, ospitare bridge o richiedere moderazione pubblica, perché è l'implementazione di riferimento e ogni funzione e strumento di amministrazione la considera prioritaria. Passare da un'implementazione all'altra in seguito significa esportare e ricostruire tutto, quindi scegli pensando al secondo anno."
            }
        },
        {
            "@type": "Question",
            "name": "Quanta RAM serve a un server Matrix?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Per Synapse, circa 2 GB per iniziare, circa 4 GB per dieci-cinquanta utenti attivi, e 8 GB o più oltre un centinaio. I server della famiglia Conduit restano ben al di sotto di queste cifre. La correzione importante è che la memoria segue il numero e la dimensione delle stanze a cui si uniscono i tuoi utenti, non il numero di account che ospiti: pochi utenti in molte grandi stanze pubbliche costano più di tanti utenti in piccole stanze private."
            }
        },
        {
            "@type": "Question",
            "name": "Perché il mio homeserver usa così tanto disco?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Due cause, di solito insieme. Unirsi a grandi stanze federate porta sul tuo disco la cronologia e lo stato di altri server, quindi anche un server piccolo può avere onestamente un database enorme. E i media remoti vengono messi in cache a tempo indeterminato per impostazione predefinita, quindi immagini e file provenienti da stanze in cui i tuoi utenti sono semplicemente presenti si accumulano per sempre. Imposta presto una policy di conservazione per i media remoti, elimina periodicamente la cronologia vecchia e monitora lo spazio libero invece di aspettare i sintomi."
            }
        },
        {
            "@type": "Question",
            "name": "Devo lasciare aperta la registrazione?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Non su un server a cui tieni. La registrazione aperta attira iscrizioni automatiche che trasformano il tuo dominio in una fonte di spam, e gli altri homeserver rispondono aggiungendolo a liste di controllo degli accessi condivise: a quel punto i tuoi utenti legittimi vengono bloccati dalle stanze altrove. Tieni la registrazione disabilitata e crea tu stesso gli account, oppure vincolala con dei token di registrazione così la porta si apre solo per chi hai invitato."
            }
        },
        {
            "@type": "Question",
            "name": "Eseguire un bridge rompe la crittografia end-to-end?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Sposta il confine. Un bridge deve convertire tra due protocolli, quindi in quel punto gestisce necessariamente i messaggi in forma leggibile e detiene le credenziali dell'account remoto. Il traffico resta cifrato sul lato Matrix e sull'altra rete, ma il bridge stesso è un punto in cui entrambi sono leggibili. Tratta la macchina che lo esegue come infrastruttura sensibile, e tieni presente che ogni bridge raddoppia più o meno l'impronta di memoria di un piccolo server."
            }
        },
        {
            "@type": "Question",
            "name": "Posso cambiare il mio server_name in seguito?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "No, e vale la pena leggerlo due volte prima di installare qualsiasi cosa. Il server_name è incorporato in ogni ID utente, ID stanza ed evento firmato che il tuo server produce, quindi cambiarlo significa abbandonare gli account e le stanze invece di rinominarli. Scegli il dominio nudo che vuoi davvero usare, poi usa la delega .well-known o un record SRV per puntarlo verso qualunque host esegua il software."
            }
        }
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "Home",
            "item": "https://servhidden.com/it/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "Guide di Hosting Privato",
            "item": "https://servhidden.com/it/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "Self-Hosting Matrix: federazione, metadati e cosa non copre la E2EE",
            "item": "https://servhidden.com/it/guides/self-host-a-matrix-server"
        }
    ]
}
```

