Come ospitare un server SimpleX su un VPS

Cosa fa un server SimpleX chat self-hosted

Per eseguire un server SimpleX chat self-hosted, si avvia un demone su un VPS: smp-server, il relay per SMP (simplex messaging protocol). Il demone gestisce le code di messaggi in cui i contatti scrivono e da cui leggono. Un secondo demone opzionale, denominato xftp-server, gestisce il relay dei trasferimenti di file. Entrambi fanno parte dello stesso progetto, simplexmq, e ciascuno consiste in un singolo binario, un file di configurazione e un log in modalità append-only.

Il testo è rivolto all'operatore, non all'utente dell'app. Il relay non gestisce account, elenchi di contatti o cronologia delle chat. Gestisce le code, una parte dei messaggi cifrati non consegnati e un certificato che lo identifica. Le responsabilità dell'operatore sono la disponibilità del servizio, una quantità ridotta di spazio su disco e i metadati che transitano sul server.

Tutti i comandi, percorsi, porte e flag riportati di seguito provengono dalla documentazione del progetto: la pagina sull'hosting del server SMP, la pagina del server XFTP e il documento sulla sicurezza del protocollo. Quando un numero è importante, la pagina di provenienza viene indicata accanto.

Perché una rete senza identificativi degli utenti ha comunque bisogno di relay

SimpleX non usa nomi utente, numeri di telefono o ID degli account. Un contatto è una coda unidirezionale: un indirizzo su un relay, su cui un dispositivo scrive e l'altro legge. Due contatti non condividono alcun identificativo che un server possa usare per collegarli.

Le code devono comunque risiedere da qualche parte, per un motivo semplice. Due telefoni sono raramente online nello stesso momento. Un componente deve accettare subito un messaggio e conservarlo fino a quando l'altro dispositivo non lo richiede. Questo è l'unico compito di un relay SMP. Di conseguenza, i due dispositivi non si connettono mai direttamente e nessuno dei due apprende l'indirizzo IP (Internet Protocol) dell'altro. Il relay assorbe questa esposizione.

Il nome host del relay fa parte dell'indirizzo della coda, quindi è incluso in ogni link di invito che distribuisci tramite quel relay. Ricordatelo quando leggi il modello delle minacce verso la fine.

Cosa può e non può vedere un relay

Il progetto presenta questo aspetto come modello di minaccia in protocol/security.md. Vale la pena leggerlo prima di installare qualsiasi componente, perché al termine di questa guida il relay sarà sotto il tuo controllo. Un relay, anche se completamente controllato da un attaccante, non può conoscere il contenuto o il tipo dei messaggi, non può aggiungere, duplicare o alterare singoli messaggi senza essere rilevato e non può compromettere la crittografia end-to-end con un attacco attivo.

La stessa pagina elenca ciò che un relay può fare. Può sapere quando un destinatario della coda è online. Può contare quanti messaggi transitano attraverso una coda. Può conoscere l'indirizzo IP di un destinatario. Può eliminare tutti i messaggi futuri di una coda oppure fornire informazioni false sullo stato della coda.

La distinzione è quindi chiara. La riservatezza è responsabilità del client e l'hosting autonomo non la modifica. I metadati e la disponibilità sono responsabilità dell'operatore del relay; con l'hosting autonomo, entrambi passano sotto il tuo controllo.

Prerequisiti

• Una VPS con Ubuntu 22.04 o 24.04. Il progetto pubblica binari di release compilati esattamente per queste due versioni, in x86-64 e aarch64.
• Un nome di dominio con un record A che punti alla VPS, oltre a un record AAAA se usi IPv6. La documentazione usa smp1.example.com come esempio.
• Accesso root o sudo e una seconda sessione SSH aperta mentre modifichi il firewall.
• Una posizione esterna al server in cui archiviare un backup, perché la directory di configurazione identifica il server.

Su un'istanza ARM usa l'asset aarch64 invece di x86-64. Il resto della guida non cambia. La scelta tra i piani VPS ARM e x86 dipende dal prezzo e dalle prestazioni per core, non dalla compatibilità del software.

Installare una release fissata, non la versione "latest"

Il progetto fornisce uno script di installazione che scarica la release corrente e registra un comando simplex-servers-update. Funziona. Fissare comunque la versione è una scelta corretta: se il binario di un relay cambia senza preavviso, diventa difficile analizzarne il comportamento quando si verifica un problema.

Ad agosto 2026 la release corrente di simplexmq è v6.5.0, pubblicata il 29 aprile 2026. Consultare la pagina delle release per individuare il tag desiderato, quindi usare quel tag in tutti i comandi riportati di seguito.

sudo useradd -m smp
sudo install -d -o smp -g smp -m 755 /etc/opt/simplex /var/opt/simplex

useradd -m smp non imposta alcuna password, quindi nessuno accede direttamente come smp. Creare manualmente le due directory prima di eseguire qualsiasi altra operazione, perché /etc/opt appartiene a root ed è in modalità 755. Di conseguenza, l'utente smp non ha una directory di configurazione in cui poter scrivere.

VER=v6.5.0
curl -fL "https://github.com/simplex-chat/simplexmq/releases/download/$VER/smp-server-ubuntu-24_04-x86-64" -o /tmp/smp-server
sha256sum /tmp/smp-server

Confrontare questo hash con i checksum SHA2-256 pubblicati nelle note della release dello stesso tag. Il progetto firma inoltre i checksum delle release con la chiave SimpleX Chat FB44AF81A45BDE327319797C85107E357D4A17FC, documentata nella pagina del server. In questo modo è possibile verificare la firma invece di fidarsi della pagina da cui è stato copiato l'hash.

sudo install -m 755 -o root -g root /tmp/smp-server /usr/local/bin/smp-server

Installare il binario con root come proprietario intenzionalmente. Il servizio viene eseguito come smp, quindi un'eventuale compromissione del servizio non può modificare il binario da cui viene avviato.

Inizializzare il server e salvare i due secret visualizzati

sudo su smp -c "smp-server init --yes --store-log --daily-stats --no-password --fqdn=smp1.example.com"

• --store-log (-l) scrive un log delle code in modalità append-only in /var/opt/simplex/smp-server-store.log, così il relay mantiene le code dopo un riavvio. Senza questa opzione, un riavvio elimina tutte le code e interrompe il funzionamento di ogni contatto instradato tramite il relay.
• --daily-stats (-s) scrive i contatori in formato CSV in /var/opt/simplex/smp-server-stats.daily.log.
• --fqdn inserisce il dominio nel certificato generato. Usare --ip se non si dispone di un dominio.
• --no-password consente a chiunque di creare una coda sul relay. Per mantenerlo privato, impostare create_password sotto [AUTH] in /etc/opt/simplex/smp-server.ini dopo l’inizializzazione, invece di passare --password qui. La riga di comando è infatti visibile nella cronologia della shell e nell’elenco dei processi durante l’esecuzione.

Init genera un certificato e visualizza i due valori da conservare. Il primo è l’impronta digitale, una stringa base64 che viene scritta anche in /etc/opt/simplex/fingerprint. Il secondo è l’indirizzo completo del server, formato dall’impronta digitale e dal nome host. Copiare subito entrambi i valori.

Init crea anche /etc/opt/simplex/ca.key. La documentazione indica di spostare questo file in uno storage offline. Il motivo è importante: i client memorizzano l’impronta digitale di questa autorità di certificazione. Chiunque disponga di ca.key può quindi emettere un nuovo certificato server che i client accettano come appartenente al server originale. È necessario ripristinare il file solo per ruotare in seguito il certificato server con smp-server cert.

Considerare init un’operazione da eseguire una sola volta. L’impronta digitale contenuta nell’indirizzo deriva dall’autorità generata durante l’inizializzazione. Se si rigenera tale autorità, si ottiene un indirizzo diverso e quello già distribuito non sarà più utilizzabile.

Eseguirlo con systemd come utente senza privilegi

Scrivi /etc/systemd/system/smp-server.service esattamente come riportato nella documentazione:

[Unit]
Description=SMP server systemd service

[Service]
User=smp
Group=smp
Type=simple
ExecStart=/usr/local/bin/smp-server start +RTS -N -RTS
ExecStopPost=/usr/bin/env sh -c '[ -e "/var/opt/simplex/smp-server-store.log" ] && cp "/var/opt/simplex/smp-server-store.log" "/var/opt/simplex/smp-server-store.log.bak"'
LimitNOFILE=65535
KillSignal=SIGINT
TimeoutStopSec=infinity

[Install]
WantedBy=multi-user.target

L'unità upstream include anche AmbientCapabilities=CAP_NET_BIND_SERVICE. Questa riga è necessaria perché il processo viene eseguito come smp e le porte inferiori a 1024 non possono essere aperte da un processo non-root; senza questa impostazione, il demone non può effettuare il bind sulle porte 80 o 443. Aggiungila se pubblichi questi servizi su tali porte. LimitNOFILE=65535 è importante perché ogni client sottoscritto mantiene aperta una connessione TCP e il limite predefinito è molto inferiore a quello richiesto da un relay sotto carico. ExecStopPost copia il log dello store in un file .bak a ogni arresto, fornendo un punto di ripristino gratuito.

sudo systemctl daemon-reload
sudo systemctl enable --now smp-server
sudo systemctl status smp-server
sudo journalctl -fu smp-server

Un avvio corretto registra l'indirizzo del server. Verifica quindi che i socket siano effettivamente aperti:

sudo ss -tlnp | grep -E ':(443|5223)'

Entrambe le righe devono indicare smp-server. Eseguire il demone con un account dedicato, privo di autorizzazioni sudo, segue la stessa pratica descritta in account dedicati per servizio su un VPS e impedisce che un bug in un demone di rete si trasformi in una shell root.

Quali porte aprire e quale lasciare chiusa

La documentazione ne elenca tre: 5223/tcp, 443/tcp e 80/tcp. La porta 5223 è il trasporto SMP. La configurazione fornita imposta port: 5223,443 in [TRANSPORT], quindi lo stesso protocollo risponde anche sulla porta 443. Questo è importante perché molte reti restrittive consentono il traffico in uscita sulla porta 443 e su nessun'altra porta. La porta 80 serve soltanto per la pagina informativa opzionale e per il relativo redirect a HTTPS.

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 5223/tcp
sudo ufw enable

Non aprire la porta 5224. È la porta di controllo e la documentazione mostra come raggiungerla dal server stesso tramite nc 127.0.0.1 5224. Visualizza lo stato del server ed elimina le code, quindi deve restare accessibile solo tramite loopback, con le password dell'amministratore e degli utenti impostate in [AUTH]. Se non hai mai usato questo strumento, le basi di ufw su un VPS spiegano l'ordine delle regole e come evitare di bloccarti fuori dal server.

C'è un altro controllo che spesso causa problemi. La maggior parte dei provider gestisce un firewall di rete nel pannello, separato da ufw sul server. Una porta può essere aperta in ufw e venire comunque bloccata prima di raggiungere il server.

L'indirizzo del server necessario ai client

smp://<fingerprint>[:<password>]@<public_hostname>[,<onion_hostname>]

Questa stringa costituisce l'intera configurazione lato client. Incollala nelle impostazioni del server dell'applicazione oppure chiedi a qualcuno di scansionare il codice QR che l'applicazione mostra per questa configurazione. La documentazione segnala che il codice QR include la password. Chi lo scansiona può quindi ricevere messaggi anche tramite il tuo server.

Un comportamento documentato sorprende tutti. Aggiungere il server nell'applicazione influisce solo sui contatti creati da quel momento in poi. I contatti esistenti restano sui relay su cui sono state create le relative code e non vengono migrati. Per questo non puoi disattivare un relay il giorno dopo averlo sostituito.

Aggiunta di un relay per file XFTP

XFTP (protocollo di trasferimento file SimpleX) gestisce la parte file della rete. È un daemon separato con un proprio indirizzo. Come indicato nell'annuncio di XFTP del progetto, i relay non dispongono di metadati sui file: vedono soltanto singoli blocchi, ciascuno da 256kb, 1mb o 4mb, il cui accesso è autorizzato tramite credenziali anonime. Un mittente può distribuire i blocchi di un file tra più relay. Il server conserva quindi dei frammenti, non file completi.

sudo useradd -m xftp
sudo install -d -o xftp -g xftp -m 755 /etc/opt/simplex-xftp /var/opt/simplex-xftp /srv/xftp
curl -fL "https://github.com/simplex-chat/simplexmq/releases/download/$VER/xftp-server-ubuntu-24_04-x86-64" -o /tmp/xftp-server
sudo install -m 755 -o root -g root /tmp/xftp-server /usr/local/bin/xftp-server
sudo su xftp -c "xftp-server init -l --fqdn=xftp1.example.com -q '20gb' -p /srv/xftp/"

La configurazione si trova in /etc/opt/simplex-xftp/, lo stato in /var/opt/simplex-xftp/ e i blocchi dei file nella directory indicata da -p. L'unità systemd segue la stessa struttura, con User=xftp e ExecStart=/usr/local/bin/xftp-server start +RTS -N -RTS. L'inizializzazione stampa un indirizzo xftp:// nello stesso formato di quello SMP, con la relativa fingerprint in /etc/opt/simplex-xftp/fingerprint.

È necessario pianificare una possibile collisione. La porta documentata del server XFTP è 443 e anche la configurazione SMP indica la porta 443. Due processi non possono associare la stessa porta sullo stesso indirizzo. Su un singolo VPS, quindi, è necessario modificare una delle due configurazioni. La soluzione più semplice consiste nell'impostare port: 5223 nella sezione [TRANSPORT] di SMP e lasciare la porta 443 al relay per file. In questo modo, però, i client su reti restrittive non potranno usare il fallback sulla porta 443. Le alternative sono aggiungere un secondo indirizzo IP allo stesso VPS oppure usare un secondo VPS.

Impostare la quota in modo realistico. -q '20gb' rappresenta lo spazio su disco effettivamente disponibile. Il relay per file è il componente che consuma spazio su disco e banda. Il relay dei messaggi incide appena su entrambe le risorse.

Cosa risiede sul disco e cosa ripristina un backup

Sono importanti due directory. /etc/opt/simplex/ contiene l'identità: smp-server.ini, il certificato e la chiave del server, ca.key e fingerprint. /var/opt/simplex/ contiene lo stato: smp-server-store.log contiene le code e, quando restore_messages: on, i messaggi non consegnati, oltre al file delle statistiche giornaliere.

sudo systemctl stop smp-server
sudo tar czf /root/simplex-backup.tgz -C / etc/opt/simplex var/opt/simplex
sudo chmod 600 /root/simplex-backup.tgz
sudo systemctl start smp-server

È importante capire cosa contiene quell'archivio. Non è un archivio dei messaggi: gli elementi in coda sono testi cifrati con chiavi che il relay non ha mai posseduto e la configurazione [STORE_LOG] inclusa elimina comunque i messaggi dopo 21 giorni. È una copia dell'identità del server, incluso ca.key, quindi chiunque entri in possesso del file può presentarsi ai tuoi contatti come il tuo relay. Cifrala e conservala fuori dal server.

Il vantaggio si vede nel ripristino. Ripristina /etc/opt/simplex su un nuovo VPS, associa allo stesso nome DNS il nuovo server e l'impronta digitale resterà invariata, quindi tutti gli indirizzi che hai distribuito continueranno a funzionare. Se perdi quella directory, non è possibile recuperarla: una nuova installazione genera una nuova impronta digitale, quindi un nuovo indirizzo e tutti i contatti instradati attraverso il tuo relay vanno persi.

TLS: due certificati con funzioni diverse

Il trasporto SMP non usa un'autorità di certificazione pubblica. Init genera un'autorità privata e un certificato del server; l'impronta digitale di questa autorità è inclusa nell'indirizzo del server. Il client confronta ciò che presenta il server con l'impronta digitale fissata nell'indirizzo. È questo il meccanismo che il progetto descrive come protezione della connessione client-server dagli attacchi machine-in-the-middle. Su quella porta non è necessario eseguire un client ACME (automatic certificate management environment), e il rinnovo viene eseguito manualmente con smp-server cert impostato su SMP_SERVER_CFG_PATH.

La pagina informativa opzionale usa l'altro certificato. La relativa sezione [WEB] indica static_path, https: 443, cert: /etc/opt/simplex/web.crt e key: /etc/opt/simplex/web.key. Un browser non riconosce la tua autorità privata, quindi questo è l'unico punto in cui è appropriato usare un certificato considerato attendibile pubblicamente. La guida rapida Docker della documentazione configura Caddy davanti al server proprio per questo scopo e rilascia automaticamente il certificato.

Raggiungere il relay tramite Tor

La documentazione include una sezione su Tor che installa Tor dal repository del Tor Project e aggiunge un hidden service in /etc/tor/torrc:

SOCKSPort 0
HiddenServiceNonAnonymousMode 1
HiddenServiceSingleHopMode 1
HiddenServiceDir /var/lib/tor/simplex-smp/
HiddenServicePort 5223 localhost:5223
HiddenServicePort 443 localhost:443

Leggere attentamente le due righe relative alle modalità. Single hop e non anonimo significano che la posizione del relay non è nascosta. L'indirizzo onion è veloce e offre ai client un modo per connettersi senza rivelare il proprio indirizzo IP, ma il server resta individuabile tramite il suo IP pubblico. Il nome host onion ottenuto da /var/lib/tor/simplex-smp/hostname va aggiunto alla fine dell'indirizzo del server, dopo una virgola. Se si vuole nascondere anche la posizione del server, è necessaria una configurazione diversa; eseguire un vero onion service su un VPS illustra il compromesso. La differenza tra ciò che nasconde ciascuno strumento è l'argomento di Tor a confronto con una VPN e si applica direttamente anche in questo caso.

Modello delle minacce: cosa cambia con il self-hosting

Cosa offre. I metadati (quali code esistono, quando vengono lette e quali indirizzi si connettono) risiedono su una macchina che controlli tu, e sei tu a stabilire per quanto tempo conservarli. Inoltre, non fai parte di un grande insieme di utenti i cui dati possono essere richiesti in un'unica operazione.

Cosa non offre, in modo esplicito:

• La cifratura non cambia. I messaggi erano cifrati end-to-end prima della configurazione e restano cifrati end-to-end anche dopo. Il self-hosting è una scelta relativa ai metadati, non alla crittografia.
• Il provider del tuo VPS vede il traffico diretto al tuo indirizzo IP e conserva i tuoi dati di fatturazione. Hai spostato la fiducia da un operatore di messaggistica a un provider di hosting. Non l'hai eliminata.
• Il tuo relay è un insieme ristretto di utenti. Se serve una sola abitazione, la connessione al relay identifica quell'abitazione e il suo hostname compare in ogni link di invito che invii da quel relay. Un relay pubblico molto utilizzato ti offre una maggiore protezione sotto questo aspetto, e questo è il vero compromesso.
• La disponibilità ora dipende da te. Un disco pieno o un server non funzionante impediscono la consegna dei messaggi e i tuoi contatti non hanno modo di instradarli aggirando il tuo relay.

Lo stesso ragionamento vale per qualsiasi servizio privato che esegui su un server di tua proprietà, sia esso questo relay o una VPN WireGuard sul tuo VPS. Stai scegliendo quale soggetto vede i metadati. Non li stai facendo scomparire.

Quando non funziona

Il servizio si avvia e si arresta immediatamente. Leggi sudo journalctl -u smp-server -n 50. Un errore di bind indica la porta che il servizio non è riuscito ad acquisire. Esegui quindi sudo ss -tlnp | grep :443 per vedere quale processo la sta già utilizzando. Su un server appena configurato, di solito si tratta di nginx, Caddy o del server XFTP installato poco prima.

Init non riesce a scrivere la configurazione. Eseguire smp-server init come utente smp prima che esista /etc/opt/simplex genera un errore di autorizzazione, perché /etc/opt appartiene a root. Crea prima la directory con il proprietario corretto, quindi esegui nuovamente init.

I client non riescono a raggiungere il relay. Verifica che il nome venga risolto nell'indirizzo corretto con dig +short smp1.example.com. Testa quindi la porta dal laptop, non dal server: nc -vz smp1.example.com 5223. Se la connessione dall'esterno non riesce mentre ss mostra che il socket è aperto sul server, il problema riguarda il firewall di rete del provider, che è un controllo distinto da ufw.

Un contatto non riesce a connettersi tramite il relay. L'impronta digitale presente nell'indirizzo condiviso deve corrispondere al contenuto attuale di /etc/opt/simplex/fingerprint. Se hai impostato create_password in [AUTH], l'indirizzo deve includere anche quella password. In caso contrario, il client non può creare una coda.

Dopo avere aggiunto il server nell'app non è cambiato nulla. È il comportamento previsto. Solo i nuovi contatti utilizzano il relay appena aggiunto. I contatti esistenti continuano a usare le code che avevano già.

FAQ

Self-hosting di un server SimpleX rende i miei messaggi più sicuri?

No, ed è una scelta progettuale. SimpleX cifra i messaggi end-to-end tra i dispositivi, quindi il relay non dispone delle chiavi, indipendentemente da chi lo gestisce. Il self-hosting cambia chi può osservare i metadati associati a quei messaggi: quali code esistono, quando vengono lette e quali indirizzi IP si connettono. È una scelta relativa ai metadati. Se il motivo per cui scegli il self-hosting è ottenere una cifratura più robusta, la cifratura era già presente.

Che cosa può vedere realmente l'operatore di un relay SimpleX?

Il protocol/security.md del progetto descrive questi aspetti. Un relay non può leggere il contenuto o il tipo dei messaggi, non può modificarli singolarmente senza essere rilevato e non può violare la cifratura end-to-end con un attacco attivo. Può vedere quando il destinatario di una coda è online, contare i messaggi che passano attraverso una coda, conoscere l'indirizzo IP del destinatario, eliminare i messaggi futuri di una coda oppure fornire informazioni false sullo stato della coda. Questi sono i poteri che si acquisiscono quando il relay è sotto il proprio controllo.

Mi servono un nome di dominio e un certificato TLS?

Per una configurazione utilizzabile serve un dominio e smp-server init accetta --ip se non ne disponi realmente. Per la porta di messaggistica non serve un certificato rilasciato da un'autorità pubblica: init genera una propria autorità e il client verifica tramite pinning l'impronta digitale presente nell'indirizzo smp:// del server. Un certificato riconosciuto pubblicamente serve soltanto per la pagina web informativa opzionale, configurata come cert e key nella sezione [WEB] di smp-server.ini.

Che cosa succede se perdo /etc/opt/simplex?

Tutti gli indirizzi che hai distribuito smettono di funzionare. Quella directory contiene l'autorità di certificazione la cui impronta digitale è incorporata nell'indirizzo del server; una ricostruzione genera quindi un'impronta diversa e, di conseguenza, un server diverso. I contatti le cui code risiedono su quel relay non possono essere ripristinati dal lato client. Esegui il backup della directory in forma cifrata e al di fuori del server. Conserva inoltre ca.key offline, come indicato nella documentazione, perché chiunque ne disponga può impersonare il relay.

Posso eseguire il relay SMP e il relay di file XFTP sulla stessa VPS?

Sì, ma occorre risolvere un conflitto. La porta documentata del server XFTP è 443 e la configurazione SMP predefinita elenca port: 5223,443, quindi entrambi richiedono lo stesso socket. Assegna la porta 443 a uno solo dei due: imposta port: 5223 per il server SMP oppure sposta il relay di file su un secondo indirizzo IP o su una seconda VPS. Dimensiona inoltre la quota di archiviazione in base allo spazio realmente disponibile sul disco, perché il relay di file è il componente che consuma spazio su disco e banda.