Jitsi Meet Docker: videoconferinte self-hosted pe VPS

Orice echipa ajunge la un moment dat in acelasi punct: apelul video gratuit se taie la minutul 40 exact cand incepe partea importanta a sedintei, sau un client intreaba unde anume sunt stocate datele apelului si mesajele din chat, si nimeni nu are un raspuns clar. Un server propriu de videoconferinte rezolva ambele probleme dintr-o lovitura. Fara limite de timp, fara licente per utilizator, iar traficul trece printr-o masina pe care o controlezi tu. Jitsi Meet face asta realist chiar si pentru o echipa mica, iar cu Docker toata instalarea incape intr-o dupa-amiaza, cu tot cu pauzele de cafea.

Jitsi Meet este un proiect open source (licenta Apache 2.0), cu casa la jitsi.org , iar varianta oficiala pentru Docker se afla la github.com/jitsi/docker-jitsi-meet . In ghidul de fata il instalam pe un VPS proaspat, deschidem exact porturile de care are nevoie, obtinem un certificat Let’s Encrypt gratuit si, cel mai important, punem crearea de camere in spatele unei autentificari, ca strainii sa nu-ti foloseasca serverul pe post de serviciu gratuit de conferinte.

Ce este, de fapt, Jitsi Meet

Jitsi Meet este o aplicatie de videoconferinta care ruleaza complet in browser folosind WebRTC, standardul inclus in Chrome, Firefox, Edge si Safari care permite unei pagini web sa preia camera si microfonul si sa trimita audio si video in timp real. Participantii nu au nevoie de cont si nici de vreo aplicatie instalata: deschid un link, permit accesul la camera si au intrat. Exista si aplicatii native pentru Android si iOS, care se pot conecta la serverul tau.

Sub capota, o instalare Jitsi Meet nu e un singur program, ci patru servicii care lucreaza impreuna:

• web: un server nginx care livreaza interfata Jitsi Meet, se ocupa de HTTPS si, in configuratia noastra, obtine certificatul Let’s Encrypt.
• prosody: un server XMPP care gestioneaza semnalizarea, adica toate mesajele mici de control: cine a intrat, cine are microfonul oprit, cine a ridicat mana, chat-ul.
• jicofo (Jitsi Conference Focus): coordonatorul care administreaza fiecare conferinta, decide ce video bridge o preia si pregateste sesiunile media.
• jvb (Jitsi Videobridge): componenta care muta efectiv sunetul si imaginea. Este un SFU (Selective Forwarding Unit): primeste fluxul fiecarui participant o singura data si il trimite mai departe celorlalti, fara sa-l decodeze si sa-l remixeze, de aceea consumul de CPU e surprinzator de mic.

Proiectul Docker ruleaza fiecare dintre ele intr-un container. Un container este un pachet izolat care contine o aplicatie plus tot ce ii trebuie ca sa ruleze, folosind kernelul Linux al gazdei, dar cu fisierele si procesele lui proprii. Docker este motorul care ruleaza containerele, iar Docker Compose ne lasa sa descriem mai multe containere intr-un singur fisier YAML si sa le pornim pe toate cu o singura comanda. Exact asta ne ofera docker-jitsi-meet.

Porturi, TCP si UDP intr-un minut

Un port este o usa numerotata pe adresa IP a serverului; fiecare serviciu de retea asculta in spatele propriei usi. Exista doua tipuri principale de trafic. TCP este sigur si ordonat, perfect pentru pagini web. UDP trimite si uita: fara retransmisii, fara asteptare. Pentru audio si video live asta e un avantaj, pentru ca un pachet care ajunge tarziu oricum nu mai foloseste la nimic. Jitsi are nevoie de trei usi deschise:

• TCP 80: folosit doar pentru validarea Let’s Encrypt si pentru redirectionarea vizitatorilor catre HTTPS.
• TCP 443: interfata web si semnalizarea (prin websockets securizate).
• UDP 10000: tot traficul media care trece prin video bridge. Acesta e portul pe care toata lumea il uita.

Capcana apelurilor in doi

Cand intr-o camera sunt doar doua persoane, Jitsi incearca o conexiune directa peer-to-peer intre browserele lor si nu foloseste deloc video bridge-ul. Pentru calitate e excelent, dar ascunde greselile de configurare: un server cu UDP 10000 blocat va rula fara probleme apeluri perfecte in doi, apoi se va strica in momentul in care intra al treilea participant. Tine minte asta cand testam la Pasul 8.

De ce ai nevoie

• Un VPS cu adresa IPv4 publica, minim 2 vCPU si 4 GB RAM, cu Debian 13 sau Ubuntu 24.04. Recomandam un VPS KVM (vezi nota despre LXC mai jos).
• Un domeniu sau subdomeniu la care poti crea inregistrari DNS, de exemplu meet.example.ro.
• Un utilizator cu drepturi sudo si acces SSH la server.
• O adresa de email pentru notificarile Let’s Encrypt.
• Cam 30 de minute.

Nota despre containerele LXC: Docker intr-un VPS LXC are nevoie de functia “nesting” activata pe container, asa ca scrie-ne la suport daca esti pe LXC. Chiar si asa, unele setari de kernel pe care le folosim pentru video bridge nu pot fi modificate intr-un container LXC neprivilegiat, iar inregistrarea (Jibri) cere un modul de sunet in kernel pe care LXC nu il poate incarca. Pentru Jitsi, un VPS KVM e alegerea comoda.

Cat de mare trebuie sa fie VPS-ul?

Jitsi in sine e usor cand sta in repaus. Cele doua componente Java (jicofo si jvb) iau cea mai mare parte din RAM, iar bridge-ul creste odata cu numarul de fluxuri active. Graficul de mai jos arata valori aproximative pe care le vedem pe o instanta mica; la tine pot varia in functie de versiune si setari.

In practica: 2 vCPU / 4 GB e confortabil pentru sedinte de pana la aproximativ 10 - 15 oameni, iar 4 vCPU / 8 GB iti lasa loc pentru 20 - 40 de participanti impartiti in cateva camere. De obicei latimea de banda devine limita inaintea procesorului: fiecare participant trimite cam 1 - 2,5 Mbps de video, iar bridge-ul trimite cate o copie a fluxurilor vizibile catre toti ceilalti, asa ca o sedinta aglomerata cu 10 persoane poate scoate din server in jur de 20 - 40 Mbps. Jitsi trimite straturi de rezolutie mai mica pentru miniaturi (simulcast), ceea ce tine consumul sub control.

Instalare Jitsi Meet cu Docker: cei 8 pasi

Iata procedura completa. Fiecare caseta corespunde unui pas numerotat de mai jos.

Pasul 1: Indreapta un domeniu catre VPS

Let’s Encrypt emite certificate doar pentru nume de domeniu, iar browserele permit accesul la camera doar pe pagini HTTPS, asa ca domeniul nu e optional. Mai intai, afla IP-ul public al VPS-ului:

ip -brief address show

Vei vedea cate o linie pentru fiecare interfata de retea, ceva de genul eth0 UP 203.0.113.10/24 .... Prima adresa de pe interfata principala (ignora lo, care e 127.0.0.1) este IPv4-ul tau public.

La furnizorul de DNS, creeaza o inregistrare A pentru subdomeniul dorit, de exemplu meet.example.ro, catre acel IP. Daca adaugi si o inregistrare AAAA (IPv6), asigura-te ca IPv6 chiar functioneaza pe VPS, altfel Let’s Encrypt poate incerca validarea pe IPv6 si va esua. Verifica daca numele se rezolva:

getent hosts meet.example.ro

In output trebuie sa apara IP-ul VPS-ului langa nume. Daca nu apare nimic, mai asteapta cateva minute sa se propage DNS-ul inainte sa continui.

Pasul 2: Instaleaza Docker si pluginul Compose

Incepem cu un sistem la zi:

sudo apt update && sudo apt full-upgrade -y

Pe Ubuntu, verifici daca e nevoie de reboot cu [ -f /var/run/reboot-required ] && echo "reboot necesar". Debian nu creeaza intotdeauna acest fisier, asa ca pe Debian da reboot daca upgrade-ul a instalat un pachet linux-image nou. Apoi instalam Docker din repository-ul oficial Docker, in formatul deb822 actual. Comenzile de mai jos detecteaza singure daca esti pe Debian sau pe Ubuntu:

sudo apt install -y ca-certificates curl
. /etc/os-release
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL "https://download.docker.com/linux/${ID}/gpg" -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/${ID}
Suites: ${VERSION_CODENAME}
Components: stable
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Primul bloc descarca cheia de semnare Docker, al doilea scrie definitia repository-ului in /etc/apt/sources.list.d/docker.sources, iar ultimul instaleaza motorul si pluginul docker compose. Acum permite utilizatorului tau sa ruleze Docker fara sudo:

sudo usermod -aG docker "$USER"

Iesi si intra din nou (sau reconecteaza-te prin SSH) ca sa se aplice noul grup, apoi verifica:

docker run --rm hello-world
docker compose version

Ar trebui sa vezi mesajul “Hello from Docker!” si o versiune de Compose care incepe cu v2 sau mai noua. Detaliul conteaza la Jitsi: calea de configurare foloseste ~, iar daca rulezi Compose cu sudo, ~ devine /root si configuratia ajunge intr-un loc la care nu te astepti.

Pasul 3: Descarca docker-jitsi-meet si genereaza secretele

Echipa Jitsi publica release-uri testate ale setup-ului Docker, fiecare legat de versiuni potrivite ale imaginilor. Folosim mereu ultimul release, nu ramura de dezvoltare. Verifica pe pagina de release-uri care e versiunea curenta; comanda de mai jos il descarca automat:

sudo apt install -y unzip wget
cd ~
wget -O jitsi-release.zip "$(wget -q -O - https://api.github.com/repos/jitsi/docker-jitsi-meet/releases/latest | grep zipball_url | cut -d'"' -f4)"
unzip -q jitsi-release.zip
mv jitsi-docker-jitsi-meet-* docker-jitsi-meet
cd docker-jitsi-meet
ls

Ar trebui sa vezi fisiere ca docker-compose.yml, env.example, gen-passwords.sh si cateva extra optionale (jibri.yml, jigasi.yml si altele de care nu avem nevoie azi). Acum creeaza fisierul de configurare, umple-l cu parole interne aleatoare si creeaza folderele in care containerele isi tin datele:

cp env.example .env
./gen-passwords.sh
chmod 600 .env
mkdir -p ~/.jitsi-meet-cfg/{web,transcripts,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb,jigasi,jibri}

gen-passwords.sh genereaza secretele cu care componentele se autentifica intre ele. Ruleaza-l o singura data, inainte de prima pornire. Daca le regenerezi mai tarziu, datele Prosody existente nu se mai potrivesc si componentele nu se mai conecteaza (vezi sectiunea de depanare). chmod 600 face fisierul .env citibil doar de tine, pentru ca acum contine acele secrete.

Pasul 4: Configureaza URL-ul public, porturile si Let’s Encrypt in .env

Multe setari din .env sunt comentate implicit cu #. Comanda urmatoare iti arata liniile care ne intereseaza si numarul lor:

grep -n -E '^#?(HTTP_PORT|HTTPS_PORT|TZ|PUBLIC_URL|JVB_ADVERTISE_IPS|ENABLE_LETSENCRYPT|LETSENCRYPT_DOMAIN|LETSENCRYPT_EMAIL|ENABLE_HTTP_REDIRECT)=' .env

Deschide fisierul cu nano .env si modifica acele linii ca sa arate asa, stergand #-ul din fata acolo unde exista si folosind domeniul, IP-ul si emailul tau:

HTTP_PORT=80
HTTPS_PORT=443
TZ=Europe/Bucharest
PUBLIC_URL=https://meet.example.ro
JVB_ADVERTISE_IPS=203.0.113.10
ENABLE_LETSENCRYPT=1
LETSENCRYPT_DOMAIN=meet.example.ro
LETSENCRYPT_EMAIL=admin@example.ro
ENABLE_HTTP_REDIRECT=1

Ce face fiecare linie:

• HTTP_PORT si HTTPS_PORT: valorile implicite sunt 8000 si 8443, gandite pentru teste. Validarea Let’s Encrypt cere ca containerul web sa raspunda pe porturile standard 80 si 443.
• PUBLIC_URL: adresa pe care oamenii o scriu in browser. Trebuie sa fie acelasi domeniu de la Pasul 1, fara port.
• JVB_ADVERTISE_IPS: adresa IP pe care video bridge-ul o comunica browserelor pentru trimiterea fluxurilor media. In Docker, bridge-ul vede doar o adresa privata 172.x, asa ca fara aceasta setare ar intreba un server STUN extern care ii este IP-ul public. Setata explicit, e mult mai sigur. Daca VPS-ul are IPv6 functional, poti trece ambele adrese, separate prin virgula.
• ENABLE_LETSENCRYPT, LETSENCRYPT_DOMAIN, LETSENCRYPT_EMAIL: containerul web obtine si reinnoieste automat un certificat gratuit. Cat timp experimentezi, poti adauga si LETSENCRYPT_USE_STAGING=1 ca sa nu atingi limitele Let’s Encrypt, apoi il scoti pentru certificatul real.
• ENABLE_HTTP_REDIRECT: trimite pe oricine scrie http:// catre varianta HTTPS.

Salveaza cu Ctrl+O, Enter, si iesi cu Ctrl+X. Pentru o prima pornire functionala nu mai trebuie schimbat nimic altceva.

Pasul 5: Deschide TCP 80, 443 si UDP 10000

Inainte sa umblam la firewall, un lucru important: Docker isi scrie propriile reguli iptables pentru porturile publicate, iar acestea sunt evaluate inaintea celor din ufw. Asta inseamna ca porturile publicate de containerele Jitsi (80, 443 si UDP 10000) sunt accesibile din internet chiar daca ufw spune “deny”. ufw ramane important pentru serviciile care ruleaza direct pe gazda, in primul rand SSH. Regulile allow din ufw pentru porturile Jitsi nu strica si documenteaza intentia, dar nu te baza niciodata pe ufw ca sa ascunzi un port Docker.

Pe Ubuntu, ufw e preinstalat dar inactiv; pe Debian, instaleaza-l mai intai cu sudo apt install -y ufw. Apoi:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw enable
sudo ufw status verbose

Daca daemonul SSH asculta pe un port nestandard, permite acel port in locul lui 22 inainte de ufw enable, altfel te blochezi singur afara. In output trebuie sa apara cele patru reguli cu ALLOW IN. Daca exista orice alt firewall in fata serverului (un firewall hardware sau un filtru upstream), deschide si acolo aceleasi trei porturi Jitsi.

Optional, doar pe KVM: buffere UDP mai mari. Video bridge-ul proceseaza foarte multe pachete UDP mici, iar proiectul Jitsi recomanda buffere de kernel mai mari pentru el:

sudo tee /etc/sysctl.d/20-jvb-udp-buffers.conf > /dev/null <<'EOF'
net.core.rmem_max = 10485760
net.core.netdev_max_backlog = 100000
EOF
sudo sysctl --system

Output-ul afiseaza setarile aplicate. Intr-un container LXC neprivilegiat aceste chei sunt read-only si vei vedea erori “permission denied”: e normal, sari peste aceasta parte.

Pasul 6: Porneste Jitsi Meet cu Docker si verifica certificatul

Din folderul ~/docker-jitsi-meet, porneste totul:

cd ~/docker-jitsi-meet
docker compose up -d
docker compose ps

La prima rulare se descarca patru imagini, ceea ce dureaza un minut sau doua, apoi apar linii de genul Container docker-jitsi-meet-web-1 Started. docker compose ps trebuie sa afiseze patru servicii, web, prosody, jicofo si jvb, toate cu status Up. Acum urmareste cum containerul web obtine certificatul:

docker compose logs -f web

Cauta mesajul Cert success raportat de clientul Let’s Encrypt, aproape de inceputul logului. Apasa Ctrl+C ca sa nu mai urmaresti logul (containerul continua sa ruleze). Confirma si de pe server:

curl -sI https://meet.example.ro | head -n 1

O linie de status care se termina in 200 inseamna ca nginx serveste site-ul cu un certificat valid. Deschide https://meet.example.ro in browser: ar trebui sa vezi pagina de bun venit Jitsi Meet si lacatul in bara de adrese. Reinnoirea e automata, facuta in containerul web, iar certificatele stau in ~/.jitsi-meet-cfg/web, deci supravietuiesc recrearii containerelor.

Momentan insa oricine gaseste URL-ul poate crea camere. Hai sa reparam asta.

Pasul 7: Cere autentificare pentru crearea camerelor

Modul pe care il vrem se numeste “secure domain” cu invitati: doar utilizatorii inregistrati pot porni o sedinta, iar oricine are link-ul poate intra dupa ce a sosit gazda. Editeaza din nou .env si seteaza (decomenteaza daca e nevoie):

ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal

AUTH_TYPE=internal pastreaza utilizatorii in baza proprie a lui Prosody, ideal pentru echipe mici. Daca vei avea nevoie de mai mult, sunt suportate si LDAP sau token-uri JWT. Aplica schimbarea:

docker compose up -d

Compose observa mediul modificat si afiseaza Recreated pentru containerele afectate. Atentie: docker compose restart nu preia modificarile din .env, doar reporneste containerele cu setarile vechi. Acum creeaza primul utilizator:

docker compose exec prosody prosodyctl --config /config/prosody.cfg.lua adduser alice@meet.jitsi

Ti se va cere parola de doua ori; nu se afiseaza pe ecran si nu ajunge in istoricul shell-ului. meet.jitsi este domeniul XMPP intern folosit de containere, nu domeniul tau public, asa ca lasa-l exact asa. Alte comenzi utile:

# schimba parola
docker compose exec prosody prosodyctl --config /config/prosody.cfg.lua passwd alice@meet.jitsi
# sterge un utilizator
docker compose exec prosody prosodyctl --config /config/prosody.cfg.lua deluser alice@meet.jitsi
# listeaza utilizatorii existenti
sudo ls ~/.jitsi-meet-cfg/prosody/config/data/meet%2ejitsi/accounts/

Testeaza intr-o fereastra privata de browser: deschide https://meet.example.ro/NumeCamera. In loc sa porneasca sedinta, Jitsi arata ca asteapta gazda si iti ofera un buton de autentificare. Logheaza-te ca alice cu parola aleasa, iar sedinta porneste cu tine ca moderator. Invitatii care deschid acelasi link intra acum fara credentiale.

Pasul 8: Testeaza o sedinta reala cu trei persoane

Din cauza capcanei peer-to-peer in doi, un test real are nevoie de minim trei participanti, ideal din retele diferite: laptopul tau, telefonul pe date mobile (nu pe Wi-Fi-ul de la birou) si un coleg de acasa. Porneste sedinta ca utilizator autentificat, trimite link-ul si roaga-i pe toti sa porneasca camera.

Daca toti trei se vad si se aud cateva minute la rand, media trece prin video bridge pe UDP 10000 si configuratia e corecta. Cat timp ruleaza sedinta, verifica resursele pe server:

docker stats --no-stream

Vei vedea CPU si memorie per container; jvb ar trebui sa fie cel mai ocupat, cu valori in zona graficului de mai sus. Daca tii mouse-ul pe barele de semnal din coltul unui participant in browser, vezi si detalii despre conexiune, ca bitrate si pierdere de pachete.

Actualizari si backup

Jitsi publica regulat release-uri stabile noi, cu reparatii de compatibilitate pentru browsere si actualizari de securitate. Fa intotdeauna backup mai intai. Tot ce conteaza, configuratia, certificatele si conturile de utilizator, sta in ~/.jitsi-meet-cfg si in fisierul .env; nu exista o baza de date separata:

cd ~
sudo tar czf jitsi-backup-$(date +%F).tar.gz .jitsi-meet-cfg docker-jitsi-meet/.env
sudo chown "$USER": jitsi-backup-*.tar.gz

Fisierele din folderul de configurare sunt scrise de containere ca root, deci tar are nevoie de sudo, iar chown iti da tie proprietatea arhivei, ca s-o poti copia cu scp de pe calculatorul tau. Pentru restaurare, opresti stack-ul, muti deoparte folderul ~/.jitsi-meet-cfg curent, dezarhivezi backup-ul in home si pornesti din nou.

Pentru upgrade, descarci noul release langa cel curent, refolosesti .env-ul, tragi imaginile si apoi faci schimbul:

cd ~
wget -O jitsi-release.zip "$(wget -q -O - https://api.github.com/repos/jitsi/docker-jitsi-meet/releases/latest | grep zipball_url | cut -d'"' -f4)"
unzip -q jitsi-release.zip
mv jitsi-docker-jitsi-meet-* docker-jitsi-meet.new
cp docker-jitsi-meet/.env docker-jitsi-meet.new/.env
diff docker-jitsi-meet/env.example docker-jitsi-meet.new/env.example
(cd docker-jitsi-meet.new && docker compose pull)
(cd docker-jitsi-meet && docker compose down)
mv docker-jitsi-meet docker-jitsi-meet.old
mv docker-jitsi-meet.new docker-jitsi-meet
cd docker-jitsi-meet && docker compose up -d

diff iti arata setarile noi sau redenumite din sablon; citeste notele de release si copiaza in .env ce e relevant. Pentru ca tragi imaginile inainte de oprire, intreruperea dureaza doar cateva secunde. Oricum, fa-o in afara orelor de sedinte si sterge docker-jitsi-meet.old cand esti multumit.

Depanare si greseli frecvente

Apelurile merg in doi, dar ingheata sau cad cand intra al treilea. Simptomul clasic pentru media care nu ajunge la bridge. Verifica daca UDP 10000 e deschis pe orice firewall upstream, daca JVB_ADVERTISE_IPS contine IP-ul public corect si daca sudo ss -ulpn | grep 10000 arata un proces care asculta. Apoi cauta erori in docker compose logs jvb.

Certificatul nu se emite. De obicei DNS-ul nu indica inca serverul sau altceva ocupa deja portul 80. Ruleaza sudo ss -tlpn | grep -E ':80 |:443 ' ca sa vezi daca un Apache sau un alt nginx de pe gazda tine acele porturi. Confirma si HTTP_PORT=80 si HTTPS_PORT=443 in .env. Dupa mai multe incercari esuate poti atinge limitele Let’s Encrypt; foloseste LETSENCRYPT_USE_STAGING=1 pana cand merge.

Am modificat .env si nu s-a intamplat nimic. Foloseste docker compose up -d, care recreeaza containerele cu noile valori. docker compose restart pastreaza mediul vechi.

Configuratia lipseste sau e in /root. Ai rulat Compose cu sudo. Adauga-ti utilizatorul in grupul docker ca la Pasul 2 si ruleaza Compose ca tine insuti.

Componentele nu se mai conecteaza dupa ce ai rulat din nou gen-passwords.sh. Parolele interne nu se mai potrivesc cu ce a salvat Prosody la prima pornire. Restaureaza .env-ul anterior din backup sau opreste stack-ul si porneste de la zero cu un ~/.jitsi-meet-cfg gol (asta sterge si utilizatorii si certificatul).

Invitatii vad la nesfarsit mesajul ca se asteapta gazda. Cineva trebuie sa se autentifice si sa porneasca sedinta mai intai. Daca nici atunci invitatii nu pot intra, verifica daca ENABLE_GUESTS=1 e setat si daca containerele au fost recreate.

Browserul nu cere acces la camera. Browserele permit camera si microfonul doar pe HTTPS. Asigura-te ca esti pe adresa https:// cu un certificat valid.

Note de securitate

• Autentificarea este protectia principala. Un server Jitsi deschis va fi gasit si folosit de straini, care iti consuma banda. Pastreaza ENABLE_AUTH=1 activ si foloseste parole puternice si unice pentru fiecare cont.
• Publica doar ce e necesar. Fisierul compose implicit publica doar porturile web si UDP 10000; Prosody si Jicofo raman in reteaua interna Docker, iar API-ul de administrare al bridge-ului e legat de 127.0.0.1. Nu adauga intrari ports: in plus si tine minte ca porturile publicate de Docker ocolesc ufw.
• Protejeaza .env si folderul de configurare. Contin secretele interne si baza de utilizatori. Pastreaza chmod 600 .env si tine backup-urile intr-un loc privat.
• Apartenenta la grupul docker echivaleaza cu root. Adauga acolo doar utilizatori carora le-ai da oricum acces root complet.
• Foloseste controalele din sedinta. Nume de camere greu de ghicit, lobby-ul (participantii asteapta pana ii lasa un moderator sa intre) si parolele de camera sunt disponibile direct din interfata. Criptarea end-to-end poate fi activata per sedinta in browserele care o suporta.
• Securizeaza SSH-ul. Foloseste autentificare cu chei, dezactiveaza login-ul cu parola si ia in calcul fail2ban. Serverul video e la fel de sigur ca masina pe care ruleaza.
• Actualizeaza regulat. Urmeaza procedura de upgrade de mai sus macar o data la cateva luni si ruleaza sudo apt update && sudo apt full-upgrade pentru gazda insasi.

Deci, merita Jitsi self-hosted?

Daca echipa ta are apeluri regulate, lucreaza cu clienti carora le pasa unde ajung datele sau pur si simplu s-a saturat de sedinte taiate la 40 de minute, raspunsul e da. Cu Docker, Jitsi Meet inseamna cateva comenzi, un fisier de configurare si trei porturi deschise, iar cu autentificarea activa ramane serviciul tau privat de conferinte, fara limite de timp si fara taxe per utilizator. Lucrurile de retinut sunt putine: UDP 10000 trebuie sa fie accesibil, JVB_ADVERTISE_IPS trebuie sa fie corect si testezi cu trei oameni, nu cu doi.

Poti instala tot ce e mai sus pe un VPS de la noi in cateva minute, pe hardware din propriul nostru data center din Romania, cu banda suficienta pentru video. Daca preferi sa nu te ocupi singur, echipa noastra de administrare servere iti poate instala, securiza si tine la zi serverul Jitsi Meet.

Intrebari frecvente

Cati participanti poate duce un singur VPS?

Un VPS cu 2 vCPU / 4 GB duce confortabil sedinte video de aproximativ 10 - 15 persoane, iar unul cu 4 vCPU / 8 GB ajunge la cateva zeci de participanti impartiti in camere. Latimea de banda e de obicei limita reala, asa ca urmareste graficele de trafic in sedintele aglomerate. Jitsi poate scala si cu mai multe video bridge-uri, dar asta e subiectul altui articol.

Am nevoie de un server TURN?

Pentru majoritatea utilizatorilor, nu: UDP 10000 functioneaza din retele de acasa si mobile. Unele retele corporate stricte blocheaza complet UDP si permit doar HTTPS; pentru acei participanti, un server TURN care asculta pe TCP 443 ajuta la retransmiterea media. docker-jitsi-meet poate fi configurat sa foloseasca unul daca devine o nevoie reala pentru utilizatorii tai.

Pot inregistra sedintele?

Da, cu Jibri, componenta de inregistrare Jitsi, pe care docker-jitsi-meet o include ca fisier optional jibri.yml. Ruleaza cate o instanta completa de Chrome pentru fiecare inregistrare, deci planifica CPU si RAM in plus, si are nevoie de modulul de kernel snd-aloop pe gazda, lucru imposibil intr-un container LXC.

Il pot rula pe un VPS LXC?

Poate functiona daca nesting-ul Docker e activat pe container, dar nu poti aplica optimizarea bufferelor UDP, iar inregistrarea nu va merge. Pentru un server video recomandam un VPS KVM.

Exista limite de timp sau de participanti?

Nu. Serverul tau nu are limite artificiale pentru durata sedintelor sau numarul de camere; singurele limite sunt procesorul, memoria si banda VPS-ului.

Am deja nginx sau alt reverse proxy pe acest VPS. Ce se schimba?

Lasa ENABLE_LETSENCRYPT dezactivat, pastreaza porturile implicite Jitsi HTTP_PORT=8000 si HTTPS_PORT=8443 si lasa proxy-ul existent sa gestioneze certificatul si sa trimita traficul catre Jitsi, inclusiv upgrade-urile de websocket. UDP 10000 merge in continuare direct la video bridge, pentru ca fluxurile media nu pot trece printr-un proxy HTTP.

Functioneaza aplicatiile mobile cu serverul meu?

Da. Instaleaza aplicatia Jitsi Meet pe Android sau iOS, intra in setari, introdu URL-ul serverului (de exemplu https://meet.example.ro) si intra in camere ca de obicei. Aplicatiile cer un certificat valid, pe care ti-l ofera Let’s Encrypt.