Come installare un server SimpleX su un VPS

Cosa fa un server SimpleX per chat self-hosted

Per eseguire autonomamente un server SimpleX basta avviare un daemon su un VPS: smp-server, il relay per SMP (simplex messaging protocol). Gestisce le code di messaggi in cui i contatti scrivono e da cui leggono. Un secondo daemon opzionale, denominato xftp-server, inoltra i trasferimenti di file. Entrambi provengono dallo stesso progetto, simplexmq, e ciascuno è costituito da un singolo binario, un file di configurazione e un log in modalità append-only.

Questa guida è rivolta all'operatore, non all'utente dell'applicazione. Il relay non gestisce account, elenchi di contatti né cronologia delle chat. Gestisce le code, alcuni messaggi cifrati non consegnati e un certificato che lo identifica. Ti assumi la responsabilità della disponibilità del servizio, di un modesto spazio su disco e dei metadati che transitano dal tuo server.

Ogni comando, percorso, porta e flag riportato di seguito proviene 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 è rilevante, la pagina di provenienza viene indicata accanto al numero.

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

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

Queste code devono comunque risiedere in un luogo, per un motivo semplice. Due telefoni sono raramente online nello stesso momento. Un componente deve accettare subito un messaggio e conservarlo finché 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 compare in ogni link di invito che distribuisci tramite quel relay. Tienilo presente quando leggi il modello delle minacce verso la fine.

Cosa può e non può vedere un relay

Il progetto definisce questo aspetto come modello di minaccia in protocol/security.md. È consigliabile 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, né aggiungere, duplicare o alterare singoli messaggi senza essere rilevato. Inoltre, non può violare la cifratura end-to-end mediante un attacco attivo.

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

La separazione delle responsabilità è quindi netta. 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.

Cosa serve prima di iniziare

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

Su un'istanza ARM usare l'asset aarch64 invece di x86-64. Il resto della procedura non cambia. La scelta tra i piani VPS ARM e x86 dipende dal prezzo e dalle prestazioni per core, non dal supporto di questo software.

Installa una release fissata, non quella “latest”

Il progetto fornisce uno script di installazione che scarica la release corrente e registra un comando simplex-servers-update. Funziona. Fissa comunque la versione: se il binario di un relay cambia senza preavviso, diventa difficile capire il problema quando qualcosa si rompe.

Ad agosto 2026 la release corrente di simplexmq è v6.5.0, pubblicata il 29 aprile 2026. Controlla la pagina delle release per individuare il tag desiderato, quindi usa 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. Crea manualmente le due directory prima di eseguire qualsiasi altra operazione, perché /etc/opt appartiene a root e ha modalità 755; l'utente smp non avrebbe quindi alcuna directory di configurazione in cui 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

Confronta questo hash con i checksum SHA2-256 pubblicati nelle note della release per lo stesso tag. Il progetto firma inoltre i checksum delle release con la chiave SimpleX Chat FB44AF81A45BDE327319797C85107E357D4A17FC, documentata nella pagina del server, quindi puoi verificare la firma invece di fidarti della pagina da cui hai letto l'hash.

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

Installalo deliberatamente con root come proprietario. Il servizio viene eseguito come smp, quindi, se il servizio viene compromesso, non può modificare il binario da cui viene avviato.

Inizializza il server e conserva i due secret stampati

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 sopravvive a un riavvio. Senza questo parametro, un riavvio elimina tutte le code e interrompe il funzionamento di ogni contatto instradato attraverso il relay.
• --daily-stats (-s) scrive i contatori in formato CSV in /var/opt/simplex/smp-server-stats.daily.log.
• --fqdn inserisce il tuo dominio nel certificato generato. Se non hai un dominio, usa --ip.
• --no-password consente a chiunque di creare una coda sul relay. Per mantenerlo privato, imposta create_password sotto [AUTH] in /etc/opt/simplex/smp-server.ini dopo l'inizializzazione, invece di passare --password qui, perché una riga di comando resta visibile nella cronologia della shell e nell'elenco dei processi mentre è in esecuzione.

Init genera un certificato e stampa i due valori che devi 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, cioè l'impronta digitale seguita dal nome host. Copia subito entrambi i valori.

Init crea anche /etc/opt/simplex/ca.key e la documentazione indica di spostare questo file in una destinazione offline. Il motivo è importante: i client fissano l'impronta digitale di questa autorità di certificazione. Chiunque disponga di ca.key può quindi emettere un nuovo certificato del server che i client accetteranno come autentico. Ti serve nuovamente solo per rinnovare in seguito il certificato del server con smp-server cert.

Considera init un'operazione da eseguire una sola volta. L'impronta digitale contenuta nel tuo indirizzo deriva dall'autorità generata durante l'inizializzazione. Se rigeneri tale autorità, ottieni un indirizzo diverso e quello già distribuito non sarà più utilizzabile.

Eseguilo con systemd come utente senza privilegi

Scrivi /etc/systemd/system/smp-server.service esattamente come indicato 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 sono accessibili a un processo non-root; senza questa impostazione, il daemon non può associarsi alle porte 80 o 443. Aggiungila se devi servire queste porte. LimitNOFILE=65535 è importante perché ogni client sottoscritto mantiene aperta una connessione TCP e il limite predefinito è molto inferiore a quello necessario per un relay con traffico elevato. ExecStopPost copia il log dello store in un file .bak a ogni arresto, fornendo un punto di rollback automatico.

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 daemon con un account dedicato, privo di diritti sudo, segue la stessa pratica descritta in account dedicati per servizio su un VPS e impedisce che un bug in un daemon di rete si trasformi in una shell root.

Quali porte aprire e quale lasciare chiusa

La documentazione ne indica tre: 5223/tcp, 443/tcp e 80/tcp. La porta 5223 è utilizzata dal 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 con criteri restrittivi consentono il traffico in uscita sulla porta 443 e bloccano tutto il resto. La porta 80 serve solo 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 vi accede dal server stesso tramite nc 127.0.0.1 5224. Restituisce lo stato del server ed elimina le code, quindi deve rimanere 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 bloccare l'accesso al server.

C'è un ulteriore 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 scartata prima di raggiungere il server.

L'indirizzo del server richiesto dai client

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

Quella stringa costituisce l'intera configurazione lato client. Incollala nelle impostazioni del server dell'applicazione oppure consenti a qualcuno di scansionare il codice QR che l'applicazione la visualizza. La documentazione specifica che il codice QR include la password, quindi chi lo scansiona può ricevere messaggi anche tramite il tuo server.

Un comportamento documentato sorprende tutti. L'aggiunta del server nell'applicazione influisce solo sui contatti creati da quel momento in poi. I contatti esistenti restano sui relay sui quali sono state create le relative code e non vengono migrati. Per lo stesso motivo 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 ricevono alcun metadato dei file: vedono singoli blocchi 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 parti di file, 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 ha la stessa struttura, con User=xftp e ExecStart=/usr/local/bin/xftp-server start +RTS -N -RTS. Durante l'inizializzazione viene stampato un indirizzo xftp:// nello stesso formato di quello SMP, con la relativa impronta digitale in /etc/opt/simplex-xftp/fingerprint.

È necessario pianificare un conflitto di porte. La porta documentata del server XFTP è 443 e anche la configurazione SMP elenca 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 che operano 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.

Imposta 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 larghezza di banda. Il relay per messaggi incide poco su entrambe.

Cosa risiede sul disco e cosa ripristina un backup

Contano 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 conserva le code e, quando restore_messages: on, i messaggi non recapitati, insieme 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 di messaggi: gli elementi accodati sono testi cifrati con chiavi che il relay non ha mai posseduto e la configurazione [STORE_LOG] distribuita elimina comunque i messaggi dopo 21 giorni. È una copia dell'identità del server, incluso ca.key, quindi chiunque ottenga il file può presentarsi ai tuoi contatti come il tuo relay. Cifralo e conservalo fuori dal server.

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

TLS: due certificati con funzioni diverse

Il trasporto SMP non utilizza un'autorità di certificazione pubblica. Init genera un'autorità privata e un certificato server; l'impronta digitale di tale autorità viene inclusa nell'indirizzo del server. Il client verifica ciò che il server presenta confrontandolo con l'impronta associata. È questo il meccanismo che, secondo il progetto, protegge la connessione tra client e server dagli attacchi man-in-the-middle. Su quella porta non è necessario eseguire alcun client ACME (automatic certificate management environment), e la rotazione viene eseguita manualmente con smp-server cert e con SMP_SERVER_CFG_PATH impostato.

La pagina informativa facoltativa utilizza 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 l'autorità privata, quindi questo è l'unico punto in cui è appropriato utilizzare un certificato riconosciuto pubblicamente. La guida introduttiva Docker della documentazione configura Caddy davanti al server proprio per questo scopo e rilascia automaticamente il certificato.

Accesso al 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 con attenzione le due righe relative alla modalità. Single hop e non-anonymous indicano che la posizione del relay non è nascosta. L'indirizzo onion è veloce e offre ai client un percorso di accesso che non rivela mai il loro indirizzo IP, ma il server resta individuabile tramite il proprio 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 descrive i compromessi. 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, ad esempio quali code esistono, quando vengono lette e quali indirizzi si connettono, risiedono su una macchina che controlli tu. 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 termini chiari:

• La cifratura non cambia. I messaggi erano cifrati end-to-end prima della configurazione e restano cifrati end-to-end 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 trasferito la fiducia da un operatore di messaggistica a un operatore di hosting. Non l'hai eliminata.
• Il tuo relay costituisce un insieme ristretto di utenti. Se serve un solo nucleo familiare, la connessione al relay identifica quel nucleo e il suo hostname compare in ogni link di invito che invii tramite il relay. Un relay pubblico molto utilizzato ti protegge meglio solo sotto questo aspetto, e questo è il vero compromesso. Un server di ricerca privato presenta la stessa caratteristica. Per questo cosa nasconde davvero SearXNG sul tuo VPS dipende da quante persone condividono l'istanza con te.
• La disponibilità ora dipende da te. Se il disco è pieno o il server non è operativo, i messaggi non vengono più consegnati e i tuoi contatti non hanno modo di aggirare il problema.

Lo stesso ragionamento si applica a qualsiasi servizio privato che esegui su una macchina di tua proprietà, che si tratti di questo relay o di una VPN WireGuard sul tuo VPS. Stai scegliendo quale soggetto può vedere i metadati. Non li stai facendo scomparire.

Quando non funziona

Il servizio si avvia e si arresta immediatamente. Leggere sudo journalctl -u smp-server -n 50. Un errore di bind indica la porta che il servizio non è riuscito a occupare. Eseguire quindi sudo ss -tlnp | grep :443 per verificare quale processo la sta già utilizzando. Su un server appena installato, di solito si tratta di nginx, Caddy o del server XFTP installato un'ora 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. Creare prima la directory con il proprietario corretto, quindi eseguire nuovamente init.

I client non riescono a raggiungere il relay. Verificare che il nome venga risolto nell'indirizzo corretto con dig +short smp1.example.com. Testare quindi la porta dal laptop, non dal server: nc -vz smp1.example.com 5223. Se la connessione dall'esterno fallisce 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 nell'indirizzo condiviso deve corrispondere al contenuto attuale di /etc/opt/simplex/fingerprint. Se è stato configurato 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 già assegnate.

FAQ

Un server self-hosted 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 modifica 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 usi il self-hosting è ottenere una crittografia più forte, la crittografia era già presente.

Che cosa può vedere effettivamente 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ò compromettere la crittografia end-to-end con un attacco attivo. Può vedere quando il destinatario di una coda è online, contare i messaggi che transitano in una coda, conoscere l'indirizzo IP di un destinatario, eliminare i messaggi futuri in una coda o falsificare lo stato della coda. Questi sono i poteri che si acquisiscono quando il relay è di propria gestione.

Mi servono un nome di dominio e un certificato TLS?

Per una configurazione utilizzabile serve un dominio, mentre smp-server init accetta --ip se non ne hai realmente uno. Per la porta di messaggistica non serve un certificato rilasciato da un'autorità pubblica: init genera una propria autorità e il client verifica il fingerprint indicato nel tuo indirizzo smp://. Un certificato riconosciuto pubblicamente serve solo 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 il cui fingerprint è incorporato nell'indirizzo del server, quindi una ricostruzione genera un fingerprint diverso 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 crittografata e al di fuori del server, quindi conserva ca.key offline come indicato nella documentazione, perché chiunque ne disponga può impersonare il tuo relay.

Posso eseguire il relay SMP e il relay di file XFTP sullo stesso VPS?

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