> Source: https://meetrix.io/blogs/open-source-video-conference-software-it/
> Markdown copy of that page. Cite the URL above, not this file.

Collaboration

# Software per videoconferenza open source: 7 server

[By Shalomi Umeshika](https://meetrix.io/blogs/authors/shalomi-umeshika/) • October 12, 2026 • 13 min read

[English](https://meetrix.io/blogs/open-source-video-conference-software/)[Deutsch](https://meetrix.io/blogs/open-source-video-conference-software-de/)[Español](https://meetrix.io/blogs/open-source-video-conference-software-es/)[Français](https://meetrix.io/blogs/open-source-video-conference-software-fr/)Italiano

Ogni confronto tra software per videoconferenza open source è lo stesso elenco di funzioni. Stanze, condivisione dello schermo, chat, lavagna, registrazione. Le hanno tutti.

Niente di tutto questo decide qualcosa.

Ciò che decide è come il software sposta il video tra le persone, e a questo ti vincoli nel momento in cui scegli una piattaforma. Se sbagli, nessuna configurazione successiva ti salva. Per questo l'articolo è scritto dal lato server: sette piattaforme che puoi ospitare tu stesso, che cosa fa ciascuna alla tua bolletta di banda, quanta parte di una macchina pretende per sé e dove ognuna si ferma.

In breve

Scegli l'architettura media prima del marchio. Il **peer to peer** non richiede un server e crolla verso le quattro persone. Un **SFU** inoltra i flussi senza ricodificarli, ed è ciò su cui gira quasi tutto qui. Stanze generiche: Jitsi Meet. Didattica: BigBlueButton. Già su Nextcloud: Talk, con l'High Performance Backend. Gli altri sono adatti a casi più ristretti.

## Perché l'architettura decide tutto

Ci sono tre modi per portare il video da una persona a diverse. Tutto ciò che segue è una variante di uno di essi.

Il **peer to peer** collega ciascuno direttamente a tutti gli altri. Tre persone, tre connessioni. Otto persone, ventotto connessioni, e ognuno ora carica sette copie della propria videocamera. Ottimo per una chiamata a due. Finito verso i quattro partecipanti su una normale connessione domestica. Jami è l'unico strumento qui che funziona così di proposito.

**Un SFU**, una selective forwarding unit, mette un server in mezzo. Tu carichi un flusso, il server lo copia a tutti gli altri e lungo il percorso nulla viene decodificato né ricodificato.

Quest'ultimo punto è tutto il trucco. Inoltrare costa poco in CPU e molto in banda, quindi un'istanza modesta regge una stanza più grande di quanto penseresti mentre il tuo traffico in uscita cresce senza dare nell'occhio. Jitsi Videobridge, mediasoup, Janus e LiveKit sono tutti SFU, e insieme sono il motore dentro quasi tutto ciò che compare in questo articolo.

**Un MCU** decodifica ogni flusso in ingresso, li mescola in un'unica immagine e rimanda indietro un solo flusso. Gentile con la banda dei client, brutale con la CPU del server. È in gran parte caduto in disuso per la conferenza generica e nulla qui ne usa uno per impostazione predefinita.

Ecco perché «quante persone regge» è una domanda sul media server, non sul logo. La nostra [spiegazione dell'architettura WebRTC](https://meetrix.io/blogs/webrtc-architecture-explained/) approfondisce i compromessi, e [come è costruito Jitsi](https://meetrix.io/blogs/jitsi-architecture/) mostra che aspetto ha una distribuzione SFU quando è reale.

## I sette server

### Jitsi Meet

Apache 2.0, e la cosa più vicina a una risposta predefinita che questo settore abbia.

Sono quattro servizi, non uno: un frontend web, Prosody per il signalling XMPP, Jicofo per gestire le conferenze e il videobridge che sposta davvero il flusso media. Con i pacchetti Debian sei operativo su Ubuntu in circa quindici minuti, e la [guida rapida del manuale di Jitsi](https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-quickstart/) è la versione da seguire. Lo [stack Docker Compose](https://meetrix.io/blogs/jitsi-docker-compose/) è la strada migliore se preferisci non cedere l'intero host.

I punti a favore: non servono account, funziona in qualsiasi browser e si integra in modo pulito in altri prodotti tramite l'[API iframe](https://meetrix.io/blogs/jitsi-api-iframe/). Il punto debole: un singolo videobridge non è un piano di scalabilità. Per impostazione predefinita Jicofo sposta una conferenza su un altro bridge intorno agli ottanta partecipanti, quindi una riunione davvero grande significa più bridge con inoltro tra loro. Abbiamo descritto [come arrivare a mille utenti](https://meetrix.io/blogs/esplorazione-limite-jitsi-meet/) e [lo stesso problema su Kubernetes](https://meetrix.io/blogs/jitsi-kubernetes-scaling-videobridges-octo/).

Una cosa da sapere prima della prima installazione. Il flusso media esce su UDP 10000, e quella porta deve raggiungere direttamente il bridge. Quando il video non compare, controlla prima quello, prima di metterti a leggere i log o a cambiare la configurazione. È il motivo più comune per cui un'installazione nuova ha l'audio per due persone e il silenzio per tre.

### BigBlueButton

LGPL, e costruito per insegnare più che per fare riunioni. Non è posizionamento, si vede nel prodotto: una lavagna condivisa sopra le slide caricate, stanze per sottogruppi, sondaggi, note condivise, una coda per alzare la mano e una registrazione che riproduce la sessione invece di consegnarti un file video. Parla LTI, quindi Moodle e Canvas si collegano direttamente. mediasoup gestisce il flusso media, e la [documentazione di BigBlueButton](https://docs.bigbluebutton.org/) è insolitamente buona per un progetto di queste dimensioni. Se un solo server non basta più, la configurazione con più server è trattata in [scalare BigBlueButton su AWS](https://meetrix.io/blogs/scaling-bigbluebutton-aws/).

L'installazione è un solo script, ed è davvero il primo avvio più semplice di tutto ciò che c'è qui.

Con una condizione. Si aspetta un server Ubuntu pulito e dedicato, e il progetto lo indica come requisito, non come suggerimento. Metti in conto di dargli l'intera macchina.

Vuoi metterlo direttamente a confronto con Jitsi? L'abbiamo fatto [in un confronto a parte](https://meetrix.io/blogs/bigbluebutton-vs-jitsi-meet/).

### Nextcloud Talk

AGPL, parte di Nextcloud, ed è tutto il suo argomento. Le chiamate stanno accanto ai tuoi file, quindi puoi avviarne una da un documento e condividere quel documento al suo interno senza lasciare la pagina. Se la tua organizzazione usa già Nextcloud, aggiungere Talk costa quasi nulla.

È sulla scala che molti inciampano. Di serie Talk usa il signalling di Nextcloud, che va bene per poche persone e solo per poche. Oltre serve l'[High Performance Backend](https://github.com/strukturag/nextcloud-spreed-signaling), un server di signalling autonomo con Janus dietro. È open source e la [documentazione di amministrazione di Talk](https://nextcloud-talk.readthedocs.io/en/latest/) lo copre. È anche una seconda distribuzione con requisiti propri, e quasi ogni lamentela sulla qualità delle chiamate di Talk risale a qualcuno che non l'ha mai installato.

Devi prima montare Nextcloud stesso? La nostra [guida alla distribuzione di Nextcloud](https://meetrix.io/blogs/nextcloud-developer-guide/) copre quella metà.

### plugNmeet

Open source, costruito su LiveKit e pensato per un lavoro diverso da tutto il resto dell'elenco. Parte dal presupposto che tu abbia già un'applicazione e voglia la conferenza al suo interno. Prima viene l'API, e l'interfaccia è solo uno dei consumatori di quell'API, l'opposto di come sono progettati gli altri. Esistono integrazioni con Moodle e WordPress, e la [documentazione di plugNmeet](https://mynaparrot.github.io/plugNmeet-docs/) parte dall'API anziché dall'interfaccia, il che ti dice che tipo di progetto è.

La scelta giusta quando metti le chiamate dentro un prodotto tuo e vuoi che stanze, permessi e ciclo di vita siano guidati dal tuo backend. Quella sbagliata se ciò che vuoi davvero è un URL da mandare alle persone.

### Jami

GPL, mantenuto da Savoir-faire Linux, e l'unica vera voce peer to peer qui.

Non c'è nessun server. Gli account sono identità crittografiche che vivono sul dispositivo, i peer si trovano tramite una tabella hash distribuita e il flusso media passa direttamente tra i partecipanti. Nulla di ciò che dice qualcuno passa da un'infrastruttura gestita da qualcun altro, che è un'affermazione diversa da «lo ospitiamo noi» e va trattata come tale.

Il prezzo è la scala e la prevedibilità. Il video di gruppo funziona, ma la velocità di upload di ogni partecipante è un tetto, e la connettività dipende dalla riuscita del NAT traversal, senza alcun tuo server su cui ripiegare. Linux, Windows, macOS, Android, iOS, tutto è coperto nella [documentazione di Jami](https://docs.jami.net/). Usalo per piccoli gruppi in cui l'assenza di un server è il requisito vero e non una bella frase da brochure.

### Apache OpenMeetings

Apache 2.0, Java, e il veterano del gruppo. Offre più superficie della maggior parte: lavagna, gestione dei file, registrazione, sondaggi, un calendario di pianificazione, LDAP. Kurento gestisce il flusso media, e tutto parte dal [sito di Apache OpenMeetings](https://openmeetings.apache.org/).

A dire il vero, lo sviluppo procede lentamente rispetto a Jitsi o a BigBlueButton, e lo stack è più pesante da montare perché ti occupi di Java, Kurento e di un database invece di lanciare un solo installer. Si guadagna il suo posto se vuoi specificamente la pianificazione e la gestione dei documenti integrate, o se il tuo team gestisce già servizi Java e questo è terreno familiare e non una novità da imparare.

### Element e Matrix

Element è un client per Matrix, un protocollo aperto e federato per la comunicazione in tempo reale, quindi ospitare in proprio qui significa gestire un homeserver e non un prodotto di conferenza. Ottieni più del video: messaggistica cifrata, spazi, federazione con altri server Matrix e chiamate costruite su un SFU LiveKit. Parti dalla [documentazione di Matrix](https://matrix.org/docs/) e non da Element, perché il protocollo è ciò a cui ti vincoli.

È la distribuzione più pesante dell'articolo. Strumento sbagliato se ti serve solo la videoconferenza. Strumento giusto se stai sostituendo Slack e Zoom nello stesso progetto e la messaggistica è la cosa principale.

Da dire anche: Element ha smesso di chiamarsi Riot nel 2020. Qualunque documentazione che usi ancora il vecchio nome ha sei anni di ritardo, quindi verificala sulla documentazione attuale prima di seguirla.

## Confronto affiancato

| Piattaforma | Licenza | Architettura media | Modalità di installazione | Dimensione di stanza comoda | Uso più adatto |
| --- | --- | --- | --- | --- | --- |
| **Jitsi Meet** | Apache 2.0 | SFU (Jitsi Videobridge) | Pacchetti Debian o Docker Compose | Decine per bridge, centinaia con più bridge | Stanze generiche, integrazione |
| **BigBlueButton** | LGPL | SFU (mediasoup) | Script di installazione, server dedicato | Dimensione di una classe, decine di videocamere attive | Didattica e formazione |
| **Nextcloud Talk** | AGPL | SFU (Janus, tramite l'HPB) | App Nextcloud, più HPB per la scala | Piccola senza HPB, decine con l'HPB | Team già su Nextcloud |
| **plugNmeet** | Open source | SFU (LiveKit) | Docker, pilotato dalle tue chiamate API | Decine, LiveKit scala di più | Conferenza dentro il tuo prodotto |
| **Jami** | GPL | Peer to peer, nessun server | Solo app desktop e mobile | Una manciata | Piccoli gruppi, massima privacy |
| **Apache OpenMeetings** | Apache 2.0 | Media server Kurento | Java, Kurento e un database | Da piccola a media | Pianificazione e documenti integrati |
| **Element / Matrix** | Apache 2.0 | SFU (LiveKit) su Matrix | Homeserver, client e SFU | Decine | Prima la messaggistica, chiamate incluse |

## Quanto costa davvero gestire un software per videoconferenza open source

La licenza è gratuita. Il server no, e il conto non ha la forma che la maggior parte delle persone si aspetta.

La banda finisce prima della CPU. Un SFU inoltra invece di transcodificare, quindi ogni partecipante in più ti costa traffico in uscita molto più in fretta di quanto ti costi in processore. Dieci persone con la videocamera accesa significano che il server riceve dieci flussi e ne manda fuori novanta. Quella curva è quadratica, ed è per questo che una stanza da cinquanta non vale cinque volte una da dieci. Simulcast e inoltro solo delle persone che si stanno guardando in quel momento attenuano l'effetto. Nessuno dei due ne cambia la forma. Per mettere dei numeri sulle tue stanze, prova il [calcolatore di banda per videochiamate](https://meetrix.io/features/video-call-bandwidth-calculator/).

Ti serve anche TURN. Una parte dei tuoi utenti si trova dietro un NAT simmetrico o un firewall aziendale che blocca le porte UDP di cui WebRTC ha bisogno, e per loro la chiamata non peggiora, fallisce del tutto. Coturn è la risposta standard. È un servizio separato, e il flusso media inoltrato lo attraversa in entrambe le direzioni, quindi ha un costo di banda reale tutto suo. I concetti sono in [STUN, TURN e ICE](https://meetrix.io/blogs/stun-vs-turn-vs-ice-webrtc-nat-traversal/), la configurazione in [configurare un server TURN per Jitsi Meet](https://meetrix.io/blogs/setting-up-a-turn-server-for-jitsi-meet/), e una volta che è in funzione il [tester ICE di WebRTC](https://meetrix.io/features/webrtc-ice-tester/) mostra se fornisce davvero candidati di relay.

Poi le porte, dove le distribuzioni muoiono davvero. Il signalling è normale HTTPS sulla 443 e non dà problemi a nessuno. Il flusso media vuole UDP e non passerà attraverso un normale reverse proxy. Questo disallineamento sta dietro la maggior parte delle segnalazioni del tipo «funziona con due persone, si rompe con tre» che troverai nei forum, e [quali porte deve avere aperte Jitsi Meet](https://meetrix.io/blogs/jitsi-meet-ports/) è da leggere prima dell'installazione e non dopo.

Per le dimensioni delle istanze e le cifre mensili rispetto a una data dimensione di stanza, le abbiamo scorporate a parte in [quanto costa davvero ospitare in proprio Jitsi Meet](https://meetrix.io/blogs/jitsi-meet-self-hosting-cost/).

## Se stai costruendo, non distribuendo

Molte persone che cercano un software per server di videoconferenza non vogliono affatto una piattaforma già pronta. Vogliono il livello media e hanno intenzione di costruirsi l'interfaccia da sole. Nessuna delle sette sopra è la risposta giusta per questo, e va guardato un livello più in basso:

-   **[LiveKit](https://docs.livekit.io/).** SFU con licenza Apache 2.0 con SDK client per web, mobile e linguaggi server. È il backend media dentro plugNmeet ed Element Call, e questo dice più sulla sua maturità di qualsiasi pagina delle funzioni.
-   **[mediasoup](https://mediasoup.org/documentation/).** Una libreria SFU per Node.js anziché un'applicazione. Di basso livello, ben documentata, e ciò su cui gira BigBlueButton.
-   **[Janus](https://janus.conf.meetecho.com/docs/).** Costruito attorno ai plugin, quindi gestisce gateway SIP e streaming oltre alla conferenza. È l'SFU dietro l'High Performance Backend di Nextcloud Talk.
-   **Jitsi Videobridge da solo**, senza il resto dello stack, se vuoi tenere il bridge e scrivere attorno ad esso il tuo signalling.

Li abbiamo confrontati a fondo in [i media server WebRTC open source](https://meetrix.io/blogs/best-open-source-webrtc-media-servers-2026/), che è il miglior punto di partenza se stai costruendo e non distribuendo.

## Come scegliere

Quattro domande ti portano lì più in fretta di qualsiasi matrice di funzioni.

Quanto è grande la stanza più grande che userai davvero? Non la più grande che riesci a immaginare. Sotto le cinque persone il peer to peer è praticabile e Jami diventa interessante. Fino a qualche decina, qualsiasi SFU qui fa il suo lavoro. Oltre le cento stai progettando una distribuzione con più bridge, e questo punta a Jitsi, che ha il percorso più battuto per farlo.

È una riunione o una lezione? Se la tua risposta comprende slide, mani alzate, gruppi di lavoro e presenze, BigBlueButton è stato costruito esattamente per questo e tutto il resto ne è un'imitazione.

Deve vivere dentro qualcos'altro? Integrarlo nel tuo prodotto punta a plugNmeet o all'API iframe di Jitsi. Aggiungere chiamate a un Nextcloud esistente punta a Talk. Sostituire nello stesso momento la tua piattaforma di chat punta a Matrix.

E poi quella che tutti saltano. Chi lo gestisce il giorno in cui va male? Il self-hosting non è un'installazione, sono i rinnovi TLS, gli aggiornamenti di versione, la capacità quando l'assemblea generale dell'intera azienda cade su un solo bridge e qualcuno reperibile quando una chiamata cade nel mezzo di qualcosa di importante. Se nessuno se ne occupa, paga un piano ospitato. È una decisione ingegneristica legittima, non una resa.

Per la maggior parte dei team che fanno la domanda generale, la risposta è Jitsi Meet. Licenza permissiva, un percorso di distribuzione ben collaudato, una via d'uscita quando un solo bridge non basta più e molto più sapere operativo scritto di qualsiasi altra cosa qui per il momento in cui qualcosa si rompe a un'ora scomoda. Gli altri vincono sui casi specifici. Quei casi specifici sono reali. Restano comunque casi specifici.

## Domande frequenti

Che cos'è un server di videoconferenza open source?

È la parte server di un sistema di videochiamate che gestisci tu stesso invece di noleggiarlo da Zoom o da Google. In pratica è un media server che riceve audio e video di ogni partecipante e li inoltra a tutti gli altri, più un livello di signalling che stabilisce chi si trova in quale stanza. Poiché il codice sorgente è aperto, puoi leggerlo, modificarlo ed eseguirlo sul tuo hardware, senza licenza per utente.

Quanti partecipanti regge un server di videoconferenza self-hosted?

Dipende molto più dall'architettura media che dal marchio del software. Uno strumento peer to peer come Jami se la cava bene con poche persone. Un SFU come Jitsi Videobridge o mediasoup gestisce decine di persone per stanza su una sola macchina, e per impostazione predefinita Jicofo sposta una conferenza Jitsi su un altro bridge intorno agli 80 partecipanti. Oltre alcune centinaia gestisci più bridge con inoltro tra l'uno e l'altro, e questa è una questione di progettazione della distribuzione, non un'impostazione.

Mi serve anche un server TURN?

Quasi sempre, sì. Una minoranza dei tuoi utenti si trova dietro un NAT simmetrico o un firewall aziendale che blocca le porte UDP di cui WebRTC ha bisogno, e per loro il flusso media deve essere inoltrato tramite TURN, altrimenti la chiamata semplicemente non si connette. Coturn è la scelta standard ed è un servizio separato che ospiti accanto al server di videoconferenza.

La videoconferenza self-hosted costa davvero meno di Zoom?

Elimina le licenze per utente, ed è da lì che viene il risparmio, ma le sostituisce con il costo del server, il costo della banda e il tuo tempo di gestione. Per un piccolo team i conti spesso favoriscono un piano ospitato. Per qualche centinaio di utenti abituali, o per chi deve tenere il flusso media sulla propria infrastruttura per ragioni di conformità, di solito vince il self-hosting.

Quale server di videoconferenza open source è il più facile da installare?

BigBlueButton, se accetti il suo vincolo. Lo script di installazione monta l'intero stack in un unico passaggio, ma si aspetta un server dedicato e pulito e non ama condividere. Jitsi Meet è il più facile da inserire in un ambiente esistente, perché con Docker Compose avvii i quattro servizi senza prendere possesso dell'host.

Posso integrarne uno nella mia applicazione?

Sì. Jitsi Meet ha un'API iframe che inserisce una conferenza completa in una pagina con poche righe di JavaScript, e plugNmeet è progettato fin dall'inizio per essere pilotato da un'applicazione esterna tramite la sua API. Se vuoi costruire tu l'interfaccia invece di incorporare quella di qualcun altro, ti serve una libreria SFU come LiveKit o mediasoup, non una piattaforma già pronta.

La videoconferenza open source supporta la crittografia end to end?

In parte, con delle riserve. Jitsi Meet offre E2EE tramite gli insertable streams del browser, il che richiede browser compatibili e disattiva tutto ciò che richiede al server di vedere il flusso media, compresa la registrazione. Jami è crittografato end to end per progettazione, perché non c'è alcun server nel mezzo. Matrix ed Element trattano la crittografia come una funzione di primo piano. Tutto il resto cifra in transito ma decifra sul server.

## Jitsi Meet su AWS, già configurato

Un'immagine di Jitsi Meet pronta per la produzione, con la rete del videobridge, TLS e TURN già sistemati, se vuoi il risultato self-hosted senza passare una settimana sulle porte.

[Ottieni Jitsi Meet su AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-45cn3ib2xi7fw)

Meetrix Store

Jitsi Meet

Self-hosted video calls for 50 to 500 users

[Deploy it](https://meetrix.io/store/jitsi-meet/)

Meetrix Store New

Deploy what this guide covers, pre-configured.

-    [Jitsi Meet Self-hosted video calls for 50 to 500 users](https://meetrix.io/store/jitsi-meet/)
-    [Coturn TURN/STUN for WebRTC, no per-minute relay fees](https://meetrix.io/store/coturn/)
-    [Mattermost Team chat, a self-hosted Slack alternative](https://meetrix.io/store/mattermost/)
-    [RustDesk Remote desktop AMI, a TeamViewer alternative](https://meetrix.io/store/rustdesk/)
-    [Plane Issues, cycles and roadmaps, a Jira alternative](https://meetrix.io/store/plane/)
-    [Mailcow Business email on your own domain](https://meetrix.io/store/mailcow/)

[Browse all products](https://meetrix.io/store/)