Alternative self-hosted a Slack: quale scegliere?

Quale alternativa self-hosted a Slack dovresti usare

Le alternative self-hosted a Slack che vale la pena prendere in considerazione per un piccolo team sono Mattermost, Rocket.Chat, Matrix con Synapse e Zulip. Per uno strumento interno del team su un singolo server, usa Mattermost. Per una community pubblica, usa Zulip. Usa Matrix con Synapse quando devi comunicare con server gestiti da altre persone, e solo in quel caso, perché la federazione è l'unica funzionalità che le altre soluzioni non possono replicare ed è anche quella che modifica il tuo lavoro di amministratore.

Gli elenchi delle funzionalità non permettono di distinguere queste quattro soluzioni. Tutte supportano canali, thread, ricerca, caricamento di file e app mobili. La differenza sta in ciò che richiedono ogni mese: memoria, un database che devi mantenere operativo, un percorso per le notifiche push mobili che potresti non controllare e una licenza che determina se la funzionalità necessaria è disponibile solo a pagamento. Il confronto seguente considera questi aspetti per team di 10 e 100 utenti.

Che cosa sono realmente i quattro

Mattermost è un server Go con un database PostgreSQL. Un binario, un database, un file di configurazione. Funziona come Slack, inclusi thread e comandi slash, ed è il meno impegnativo da gestire dei quattro, il che è un complimento.

Rocket.Chat è un'applicazione Node.js basata su MongoDB. Offre il set di funzionalità più ampio tra queste soluzioni, incluse le chiamate vocali e video e una casella omnicanale che riunisce nella stessa interfaccia le conversazioni dei clienti provenienti da email e canali social. Se quella casella è il motivo per cui stai valutando questa soluzione, confrontala prima con un help desk dedicato basato su Chatwoot, perché un server di chat usato per l'assistenza svolge un lavoro diverso da un server di chat usato dal team.

Matrix è un protocollo, non un prodotto. Synapse è il server di riferimento (Python, PostgreSQL) ed Element è il client usato dalla maggior parte degli utenti. Questa è l'unica opzione tra le quattro con cui il tuo server può comunicare con server che non gestisci.

Zulip è un server Python (Django e Tornado) con PostgreSQL, RabbitMQ, memcached e Redis, installato come un'unità tramite il relativo script. Il suo modello usa argomenti all'interno dei canali, quindi una conversazione di martedì è ancora reperibile il venerdì. La versione 12.0 è stata rilasciata ad aprile 2026.

Quanta RAM e quale database, con 10 e 100 utenti

Tutti i numeri nella tabella seguente provengono dalla documentazione ufficiale dei progetti, consultata ad agosto 2026. Nessun dato è frutto di una mia misurazione o di una stima inventata. La base di confronto è la stessa per ogni riga: la configurazione minima pubblicata dal progetto, includendo il database quando il progetto lo dimensiona separatamente.

[
  {
    "label": "Synapse",
    "published_ram_gb": 1,
    "notes": "Synapse install docs: at least 1 GB free RAM if you want to join large public rooms. PostgreSQL is required for production and is not sized."
  },
  {
    "label": "Mattermost",
    "published_ram_gb": 2,
    "notes": "Mattermost requirements: 1 to 1,000 users on 1 vCPU and 2 GB RAM, single server, database included."
  },
  {
    "label": "Zulip",
    "published_ram_gb": 2,
    "notes": "Zulip requirements: under 100 users on 1 CPU, 2 GB RAM and 2 GB swap. 100 users and above needs 2 CPUs and 4 GB."
  },
  {
    "label": "Rocket.Chat",
    "published_ram_gb": 8,
    "notes": "Rocket.Chat requirements: smallest published tier is 4 GiB for the app plus 4 GiB for MongoDB, rated up to 500 concurrent users."
  }
]

Le righe non sono omogenee, ed è questa la prima informazione utile. I 1 GB di Synapse rappresentano il limite minimo per il processo Synapse, con una condizione: la documentazione richiede almeno questa quantità di RAM libera per partecipare a stanze pubbliche di grandi dimensioni. PostgreSQL non è incluso in quel valore. I 2 GB di Mattermost si riferiscono all'intera macchina, database incluso, e coprono da 1 a 1.000 utenti su una singola vCPU. Zulip documenta 2 GB e una CPU per meno di 100 utenti, oltre a 2 GB di swap; da 100 utenti in su richiede invece 4 GB e 2 CPU. Rocket.Chat pubblica il valore più alto, 8 GB, perché dimensiona l'applicazione a 4 GiB e MongoDB a 4 GiB; questo livello è previsto per un massimo di 500 utenti simultanei.

Con 10 utenti, tutte le 4 soluzioni funzionano su hardware a cui non dedicheresti particolare attenzione. A 100 utenti, le differenze diventano evidenti: Mattermost rientra ancora nel livello da 2 GB, Zulip richiede 4 GB e una seconda CPU, mentre il livello minimo documentato per Rocket.Chat resta invariato a 8 GB, perché il consumo di memoria di MongoDB dipende dalla macchina più che dal numero di utenti.

La scelta del database incide sugli aggiornamenti futuri più che sulle prestazioni quotidiane. Mattermost richiede PostgreSQL 14 o versioni successive e ha deprecato il supporto a MySQL a partire dalla v11; quindi un'installazione MySQL eseguita oggi richiederà una migrazione in futuro. Synapse funziona con SQLite, ma la documentazione del progetto specifica chiaramente che SQLite è adatto solo ai test, perché offre prestazioni scarse nelle stanze di grandi dimensioni. Rocket.Chat 8 richiede MongoDB 8.0; di conseguenza, l'aggiornamento del database e quello della chat costituiscono un unico progetto, non due progetti separati.

Cosa offre davvero un VPS da 2 GB

Il piano da 2 GB è il taglio base presso la maggior parte dei provider ed è una scelta concreta per due di queste quattro applicazioni.

• Mattermost rientra nei requisiti. È l'unica per cui il fornitore documenta esattamente questo taglio, fino a 1.000 utenti, con PostgreSQL sullo stesso server. Dieci persone su 2 GB lavorano senza problemi.
• Zulip rientra nei requisiti, con swap. La documentazione consiglia di usare lo swap su macchine con meno di 5 GB e avverte che i sistemi con poca RAM possono generare errori di memoria esaurita durante gli aggiornamenti, quando tools/webpack è il passaggio che non riesce. È un problema reale che si verifica durante l'aggiornamento, non durante l'installazione.
• Synapse rientra nei requisiti finché il carico resta ridotto. Il consumo a riposo è contenuto. Il problema sono i picchi, descritti nella sezione sulla federazione più avanti.
• Rocket.Chat è l'applicazione da evitare con 2 GB, a causa del motore di archiviazione di MongoDB. WiredTiger dimensiona la cache interna sul valore maggiore tra il 50% di (RAM meno 1 GB) e 256 MB; su una macchina da 2 GB riserva quindi circa 512 MB prima ancora che Node.js venga avviato. Il risultato non è un rifiuto immediato. L'applicazione si installa, funziona, rallenta man mano che cresce la cronologia e, infine, il kernel out of memory killer arresta il processo che in quel momento occupa più memoria.

Prima di decidere, verifica le risorse effettivamente disponibili, perché i provider calcolano la RAM in modo diverso da free:

free -h
swapon --show

Ricorda che il server di chat non è l'unico componente della macchina. La terminazione TLS (transport layer security), i backup e un runtime per container richiedono tutti memoria. Pubblica il server scelto tramite un reverse proxy che conosci, Nginx, Caddy o Traefik e, se usi i container, il tutorial di base su Docker Compose per un VPS è il primo aspetto da configurare correttamente.

Le app mobili richiedono un proprio server push

Questo è l'aspetto che molti scoprono dopo il deployment ed è quello che, più spesso di tutti, determina la risposta.

Il meccanismo è il seguente. Apple Push Notification service (APNs) e Firebase Cloud Messaging (FCM) accettano una notifica soltanto dal soggetto che possiede le credenziali di firma per quella specifica app. Il tuo server non può inviare notifiche a un'app che non hai sviluppato. Di conseguenza, un server di chat self-hosted che usa la build dell'App Store fornita dal vendor deve inoltrare le notifiche al gateway del vendor, che stabilisce le condizioni del servizio.

• Mattermost. L'opzione gratuita è il Test Push Notification Service (TPNS) all'indirizzo https://push-test.mattermost.com, che la documentazione non raccomanda per la produzione e per il quale non è previsto alcun service level agreement (SLA). Funziona soltanto con le build dell'App Store e del Play Store. L'Hosted Push Notification Service (HPNS) è adatto alla produzione e richiede un abbonamento a pagamento. La terza opzione consiste nel compilare autonomamente il push proxy; in questo caso servono build proprie dell'app, con credenziali APNs e FCM proprie.
• Rocket.Chat. Per usare le notifiche push è necessario registrare il workspace con Rocket.Chat Cloud; i workspace della community sono limitati a 10.000 notifiche push al mese. Sono circa 330 al giorno per l'intero workspace. Quando la quota viene esaurita, le notifiche non arrivano più fino al reset del mese; per gli utenti questo appare come un malfunzionamento dell'app.
• Matrix con Element. Synapse invia le notifiche a un gateway push e le app ufficiali Element sono configurate per usare il gateway gestito da matrix.org all'indirizzo https://matrix.org/_matrix/push/v1/notify. Il payload contiene gli identificativi dell'evento e della stanza, non il testo del messaggio, e l'app recupera il contenuto dal tuo server. Il gateway vede quindi i metadati, non le conversazioni. È supportato l'uso di un gateway Sygnal autonomo, ma questo implica la compilazione e la distribuzione di app proprie. Su Android esiste una soluzione intermedia: UnifiedPush con un server ntfy gestito da te.
• Zulip. Il piano gratuito include il servizio di notifiche push mobili per un massimo di 10 utenti. Oltre 10 utenti serve un piano; il piano Community gratuito copre molte organizzazioni non commerciali. Zulip 12.0, ad aprile 2026, ha aggiunto la crittografia end-to-end per i payload push.

Con dieci utenti, tutte queste soluzioni forniscono notifiche funzionanti senza costi. Con cento utenti, il quadro cambia: Zulip richiede un piano, Mattermost continua a funzionare con il servizio di test ma senza SLA né supporto, il limite mensile di Rocket.Chat diventa il vincolo principale e Matrix non è influenzato perché il gateway è gratuito.

Quali offrono il single sign-on senza costi aggiuntivi

Il modello commerciale open core emerge con maggiore chiarezza nel single sign-on (SSO).

• Zulip include SAML (security assertion markup language) e LDAP (lightweight directory access protocol) nel server self-hosted senza costi. Non è necessario acquistare un livello separato.
• Synapse supporta OpenID Connect (OIDC), SAML e CAS nel proprio file di configurazione, gratuitamente. Nelle installazioni più recenti si usa sempre più spesso Matrix Authentication Service, un servizio separato con una migrazione unidirezionale dall'autenticazione classica di Synapse. Pianifica quindi la migrazione in anticipo, invece di accorgertene in seguito.
• Rocket.Chat Community Edition supporta l'accesso di base tramite LDAP e SAML. La sincronizzazione degli attributi utente estesi, la mappatura di gruppi e team e la sincronizzazione in background richiedono una licenza enterprise.
• Mattermost Team Edition gratuita offre GitLab OAuth e nient'altro. SAML, AD/LDAP e OpenID Connect sono funzionalità a pagamento.

Se prevedi di eseguire più servizi con un unico accesso, configura un identity provider Authentik self-hosted davanti a questi servizi e verifica quali dei quattro possono effettivamente integrarsi con esso in base alla licenza disponibile.

Il costo reale della federazione

La federazione è il motivo per cui Matrix esiste. Un utente entra in una stanza ospitata sul server di un altro amministratore e comunica con persone i cui account risiedono su quel server, come i server di posta elettronica che si scambiano messaggi. Nessuna delle altre opzioni disponibili offre questa funzione. Se ti serve, nessuna delle altre soluzioni descritte in questa pagina può sostituirla.

È anche il motivo per cui Synapse utilizza un carico di lavoro diverso. Quando un utente entra in una stanza federata, il server conserva una copia dello stato e degli eventi della stanza e memorizza nella cache i contenuti multimediali pubblicati dagli utenti di altri server: avatar, immagini e file. L'uso del disco dipende quindi da stanze che non hai creato e da persone che non hanno account sul tuo server. Per questo le installazioni di Synapse sviluppano un media store molto più grande del volume dei messaggi inviati dagli utenti locali. Per lo stesso motivo, l'accesso a una stanza pubblica di grandi dimensioni è l'operazione a cui la documentazione associa un requisito di memoria specifico.

Imposta la politica di conservazione il primo giorno, non quando il disco è già pieno:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

Synapse ha introdotto media_retention nella versione 1.61, con durate separate per i contenuti multimediali locali e remoti. I contenuti remoti sono una cache; se un utente richiede nuovamente un file eliminato dalla cache, Synapse lo richiede di nuovo al server di origine. I contenuti locali non sono una cache; di conseguenza, un valore breve per local_media_lifetime elimina definitivamente i caricamenti dei tuoi utenti.

In sintesi: se i tuoi utenti comunicano esclusivamente tra loro, la federazione non offre alcun vantaggio e aumenta l'uso del disco, il traffico di rete e la complessità degli aggiornamenti. Disattivala oppure scegli un server diverso.

Come si eseguono gli aggiornamenti

Zulip è il più semplice. Basta uno script e il downtime documentato è inferiore a 30 secondi, salvo il caso di una migrazione importante del database. L'installazione e l'aggiornamento si eseguono così, direttamente da te sul server:

cd $(mktemp -d)
curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz
tar -xf zulip-server-latest.tar.gz

Esegui l'installer come root. Il flag --push-notifications registra il server presso il servizio di push mobile durante l'installazione e, in quel momento, chiede di accettare i termini di servizio. Leggili prima di iniziare.

sudo ./zulip-server-*/scripts/setup/install --push-notifications --certbot \
    --email=YOUR_EMAIL --hostname=YOUR_HOSTNAME

Gli aggiornamenti successivi usano lo stesso tarball e un solo comando:

curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz
sudo /home/zulip/deployments/current/scripts/upgrade-zulip zulip-server-latest.tar.gz

Mattermost è prevedibile. Sostituisci il binario, riavvia il servizio e le migrazioni vengono eseguite all'avvio. A partire dalle release di agosto 2025, il ramo Extended Support Release (ESR) viene pubblicato ogni 9 mesi e riceve supporto per 12 mesi. Il percorso verificato consiste nell'aggiornare da una ESR alla successiva. È possibile saltare più ESR contemporaneamente, ma questo percorso non è stato verificato; in pratica, dovrai testarlo tu.

Rocket.Chat lega insieme tre aggiornamenti. Ad agosto 2026, il ramo 8.x è quello corrente: la versione 8.7.0 è stata rilasciata il 6 agosto 2026 e richiede MongoDB 8.0 e una versione compatibile di Node.js. Saltare una versione principale può lasciare un database che l'applicazione rifiuta di aprire. La guida all'installazione di Rocket.Chat con Docker Compose blocca per te queste versioni in modo coordinato. Questo è il principale motivo per scegliere qui il percorso basato sui container.

Synapse richiede la lettura delle note. Ogni release include note sull'aggiornamento e devi leggere le note relative a ogni versione intermedia, non soltanto a quella di arrivo. Dopo l'aggiornamento, Synapse esegue aggiornamenti in background sul database. Su un server di piccole dimensioni, queste operazioni possono mantenere la macchina lenta per ore. È un comportamento previsto, non un malfunzionamento.

Condizioni di licenza, in parole semplici

Mattermost distribuisce le build compilate della Team Edition con licenza MIT, mentre il codice sorgente è disponibile con licenza AGPLv3 o con una licenza commerciale. Alcune parti del repository sono distribuite con la Mattermost Source Available License, che richiede una licenza a pagamento per l’esecuzione in produzione. Rocket.Chat usa la licenza MIT, fatta eccezione per le directory ee/, che hanno una propria licenza enterprise. Synapse è passato dalla licenza Apache 2.0 alla AGPLv3 con la versione 1.99.0. I contributori firmano un CLA che consente a Element di vendere eccezioni a tale licenza. Zulip usa la licenza Apache 2.0 e non contiene una directory enterprise. Per questo la sua gestione SSO non presenta eccezioni.

In pratica, la AGPL è rilevante solo se prevedi di modificare il server e offrirlo ad altri come servizio. Per un piccolo team è molto più importante il modello open core, cioè quali funzionalità mancano nella build gratuita. Zulip ne ha il numero minore, Mattermost quello maggiore.

Quale scegliere

Uno strumento per il team interno. Mattermost. Ha l'impronta documentata più contenuta, aggiornamenti prevedibili e un'interfaccia familiare che non richiede spiegazioni. Prevedi un piano a pagamento dal momento in cui SSO diventa un requisito, perché per la maggior parte dei team quel momento arriva.

Un server per una community. Zulip. Gli argomenti mantengono leggibile un canale pubblico molto attivo anche dopo mesi, SAML e LDAP non hanno costi aggiuntivi e l'aggiornamento richiede un solo comando. Se la tua community è più simile a post e risposte che a una chat in tempo reale, confronta prima software per forum self-hosted, perché un forum viene indicizzato meglio dai motori di ricerca e non richiede alcuna infrastruttura push. Scegli invece Rocket.Chat se vuoi funzionalità vocali, video e omnicanale e puoi assegnargli gli 8 GB richiesti dalla relativa documentazione.

Una rete che deve interagire con sistemi esterni. Matrix con Synapse ed Element. Considera l'aumento dello spazio occupato dai media, configura la conservazione dei dati dal primo giorno, usa PostgreSQL e assegna più spazio su disco di quanto prevedi; otterrai un valore concreto dalla comunicazione con server che non controlli. Scegliere Synapse per un team che non usa mai la federazione significa sostenerne i costi senza trarne alcun vantaggio.

FAQ

Qual è la migliore alternativa self-hosted a Slack per un piccolo team?

Mattermost, nella maggior parte dei team interni. La documentazione indica il supporto da 1 a 1,000 utenti su 1 vCPU e 2 GB di RAM, con PostgreSQL sulla stessa macchina. È quindi adatto al piano VPS di fascia base offerto dalla maggior parte dei provider. Il limite principale è il single sign-on: la Team Edition gratuita supporta soltanto GitLab OAuth, mentre SAML, AD/LDAP e OpenID Connect richiedono un piano a pagamento. Se il SSO gratuito è più importante di un'interfaccia simile a Slack, usa Zulip.

Posso eseguire un server di chat self-hosted su una VPS da 2 GB?

Mattermost sì. Anche Zulip, se aggiungi lo swap, come raccomanda la documentazione di Zulip sotto i 5 GB. Rocket.Chat è invece quello che probabilmente ti deluderà, perché il motore WiredTiger di MongoDB riserva per la cache il valore maggiore tra il 50% di (RAM meno 1 GB) e 256 MB. Su una macchina da 2 GB, quindi, circa 512 MB sono già occupati prima dell'avvio dell'applicazione. L'installazione riesce, ma il servizio peggiora man mano che cresce la cronologia e alla fine viene terminato per esaurimento della memoria. Il piano minimo pubblicato da Rocket.Chat prevede 4 GiB per l'applicazione e altri 4 GiB per MongoDB.

I server di chat self-hosted devono avere un proprio server per le notifiche push mobili?

Di solito no, perché APNs di Apple e FCM di Google accettano notifiche soltanto dal soggetto che ha firmato l'applicazione. L'app del fornitore usa quindi il gateway del fornitore. Le condizioni variano. Mattermost offre un servizio di test gratuito senza SLA e un servizio hosted a pagamento. Rocket.Chat limita i workspace community a 10,000 notifiche push al mese; dopo tale soglia, la consegna si interrompe fino al ripristino del conteggio mensile. Zulip include gratuitamente le notifiche push fino a 10 utenti e richiede un piano superiore oltre tale limite. I homeserver Matrix inviano le notifiche tramite il gateway usato dalle app Element, senza costi. Ti serve un gateway proprietario soltanto se distribuisci anche build della tua app.

Conviene eseguire Matrix e Synapse in self-hosting per un team che non comunica mai con altri server?

No. Synapse è progettato per la federation, che è anche ciò che lo rende più pesante da eseguire. La partecipazione a room su altri server scarica il loro stato e memorizza nella cache i relativi media sul disco. Lo spazio di archiviazione cresce quindi per motivi non collegati ai tuoi utenti. Imposta media_retention con un breve remote_media_lifetime prima che questo accada. Un team che comunica soltanto al proprio interno sostiene i costi operativi senza ottenere alcun vantaggio. Mattermost o Zulip svolgono lo stesso lavoro con meno risorse hardware.

Quale alternativa self-hosted a Slack offre il single sign-on gratuito?

Zulip e Synapse. Zulip include SAML e LDAP nel server self-hosted senza costi. Synapse supporta OpenID Connect, SAML e CAS nella propria configurazione; nelle installazioni più recenti, la gestione viene spostata nel servizio separato Matrix Authentication Service. La community edition di Rocket.Chat supporta l'accesso di base tramite LDAP e SAML, ma richiede una licenza enterprise per la sincronizzazione degli attributi, la mappatura dei gruppi e la sincronizzazione in background. La Team Edition gratuita di Mattermost supporta soltanto GitLab OAuth.