Instalar o Jitsi Meet em um VPS (2026): Docker, HTTPS, 10000 UDP, autenticação, TURN e gravação

Os fluxos de vídeo do Jitsi são encaminhados principalmente pelo Jitsi Videobridge. Não é um aplicativo web comum: CPU e memória importam, mas largura de banda pública, perda de pacotes, jitter, acessibilidade UDP e as regiões onde os participantes estão costumam afetar mais diretamente a experiência.

As configurações a seguir são pontos de partida conservadores, não garantias fixas de simultaneidade. Ativar HD, compartilhamento de tela, gravação ou muitas câmeras aumentará significativamente os requisitos de recursos.

Priorize:

• VPS com velocidade de porta de 1Gbps ou superior e tráfego mensal suficiente;
• Data centers próximos dos principais participantes;
• IPv4 público, capacidade de abrir UDP, regras de security group claras;
• Desempenho de CPU estável, sem overselling grave;
• Suporte a snapshots e resgate por console.

Se você ainda está em dúvida entre 2 núcleos/2GB e 4 núcleos/8GB, consulte Como escolher a configuração de um VPS. Para videoconferência, priorize a qualidade da rede e a margem de memória, e não apenas o tamanho do disco.

Prepare o seguinte:

• Um VPS Ubuntu 24.04 LTS novo;
• Acesso SSH como root ou com sudo;
• Um domínio, por exemplo meet.example.com;
• Um e-mail que possa receber notificações de certificado;
• As principais regiões dos usuários das reuniões e uma estimativa básica de simultaneidade.

Adicione um registro DNS A:

meet.example.com    A    203.0.113.10

Confirme o domínio e o IP público:

dig +short meet.example.com A
curl -4 ifconfig.me

Os dois resultados devem coincidir. Se o VPS ainda não tiver IPv6 configurado, não adicione um registro AAAA apontando para um endereço incorreto.

A documentação oficial do Jitsi Docker exige a abertura de:

Ao usar o UFW, libere primeiro o SSH e depois ative o firewall:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw enable
sudo ufw status numbered

Também é preciso configurar as mesmas regras no security group do provedor de nuvem. Alterar apenas o UFW ou apenas o security group não é suficiente. Antes de fazer isso, leia Como recuperar o acesso SSH perdido por causa do UFW para não ficar bloqueado fora da sessão SSH atual.

10000/UDP é a porta mais fácil de esquecer. Se a página web abrir, mas as reuniões com várias pessoas não tiverem som, travarem ou desconectarem após alguns segundos, verifique-a primeiro.

Atualize o sistema e instale Docker, Compose e ferramentas de descompactação:

sudo apt update
sudo apt upgrade -y
sudo apt install -y docker.io docker-compose-v2 unzip curl ca-certificates
sudo systemctl enable --now docker
sudo docker version
sudo docker compose version

Se o repositório do sistema não tiver docker-compose-v2, instale o Compose Plugin pelo repositório oficial do Docker em vez de recorrer ao Python docker-compose v1, sem manutenção há anos.

Não clone master diretamente para produção. A documentação oficial informa que master com imagens unstable diárias é para desenvolvimento, e que implantações em produção devem baixar um Release.

Este artigo fixa stable-11146-2:

cd /opt
sudo curl -fL https://github.com/jitsi/docker-jitsi-meet/archive/refs/tags/stable-11146-2.zip -o jitsi.zip
sudo unzip jitsi.zip
sudo mv docker-jitsi-meet-stable-11146-2 jitsi-meet
sudo chown -R "$USER":"$USER" /opt/jitsi-meet
cd /opt/jitsi-meet
cp env.example .env

A partir desta versão, os contêineres passam a rodar como não root com sistema de arquivos somente leitura. A estrutura de configuração, dados persistentes e diretórios de execução difere das versões antigas, portanto atualizar uma instância antiga não pode ser feito apenas trocando a tag da imagem.

Gere as senhas XMPP internas para Jicofo, JVB, Jigasi e Jibri:

cd /opt/jitsi-meet
./gen-passwords.sh

O script modifica .env e preserva .env.bak. Essas senhas são usadas na comunicação entre componentes; não devem ficar vazias nem reutilizar manualmente a mesma senha.

Crie os diretórios exigidos por stable-11146 e versões posteriores:

sudo mkdir -p /opt/jitsi-meet-cfg/{web,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb,jigasi,jibri,transcriber}
sudo mkdir -p /opt/jitsi-meet-cfg/storage/{jibri,prosody,transcripts,web}
sudo mkdir -p /opt/jitsi-meet-cfg/tmp/{web-crontabs,web-load-test}
sudo chmod 777 /opt/jitsi-meet-cfg/storage/{jibri,prosody,transcripts,web}
sudo chmod 777 /opt/jitsi-meet-cfg/tmp/{web-crontabs,web-load-test}

Os contêineres oficiais atuais rodam como usuário sem privilégios com UID/GID 1000, e os diretórios storage e tmp que precisam ser gravados devem ser graváveis. Se faltarem diretórios ou as permissões estiverem erradas, o contêiner se recusará a iniciar.

Edite .env:

nano /opt/jitsi-meet/.env

No mínimo, modifique ou adicione:

CONFIG=/opt/jitsi-meet-cfg
HTTP_PORT=80
HTTPS_PORT=443
TZ=Asia/Shanghai

PUBLIC_URL=https://meet.example.com
JVB_ADVERTISE_IPS=203.0.113.10

ENABLE_LETSENCRYPT=1
LETSENCRYPT_DOMAIN=meet.example.com
[email protected]
LETSENCRYPT_ACME_SERVER=letsencrypt
ENABLE_HTTP_REDIRECT=1

ENABLE_PREJOIN_PAGE=1
ENABLE_LOBBY=1
ENABLE_REQUIRE_DISPLAY_NAME=1
RESTART_POLICY=unless-stopped

JVB_ADVERTISE_IPS deve conter o IP público que os clientes realmente conseguem acessar. Se o VPS estiver atrás de NAT, tiver várias interfaces de rede ou tiver migrado de IP, um valor incorreto aqui fará a sinalização funcionar, mas a mídia falhar.

Não exclua as linhas de senha geradas por gen-passwords.sh. Após salvar, verifique primeiro as variáveis principais:

cd /opt/jitsi-meet
grep -E '^(CONFIG|PUBLIC_URL|JVB_ADVERTISE_IPS|HTTP_PORT|HTTPS_PORT|ENABLE_LETSENCRYPT|LETSENCRYPT_DOMAIN)=' .env

Não publique a saída completa de .env em tickets, capturas de tela ou repositórios públicos, pois ela contém senhas internas.

Baixe as imagens e inicie:

cd /opt/jitsi-meet
sudo docker compose pull
sudo docker compose up -d
sudo docker compose ps

Observe os logs da primeira inicialização:

sudo docker compose logs -f --tail=100 web prosody jicofo jvb

Após confirmar que não há reinicializações contínuas, pressione Ctrl+C para sair dos logs e então teste:

curl -I http://meet.example.com
curl -I https://meet.example.com
sudo ss -lntup | grep -E ':(80|443|10000)\b'

Abra https://meet.example.com no navegador e crie uma sala aleatória. Teste com pelo menos dois dispositivos em redes diferentes, por exemplo um computador em banda larga e um celular com o Wi-Fi desativado usando dados móveis.

A conexão do Jitsi se divide aproximadamente em duas partes:

1. O navegador acessa a página web, BOSH ou sinalização WebSocket pela 443/TCP;
2. O áudio e o vídeo se comunicam preferencialmente com o Jitsi Videobridge pela 10000/UDP.

Portanto, a página inicial e a sala abrirem só prova que o HTTPS está basicamente funcionando, não que o caminho de mídia está funcionando. Ao solucionar problemas, execute:

sudo ufw status verbose
sudo ss -lunp | grep ':10000'
sudo docker compose logs --tail=200 jvb

Também confirme o security group da nuvem, o firewall do host, as políticas UDP da operadora e JVB_ADVERTISE_IPS. O proxy normal da Cloudflare não encaminha o tráfego de mídia 10000/UDP do Jitsi.

A opção mais simples e estável é manter meet.example.com como DNS Only, de modo que tanto o HTTPS quanto o UDP vão diretamente para o VPS. Também é recomendável usar DNS Only ao emitir certificados pela primeira vez, para reduzir variáveis na validação ACME.

A nuvem laranja da Cloudflare pode fazer proxy de páginas web e WebSocket, mas não substitui o encaminhamento de mídia UDP do JVB nem consegue ocultar o IP de origem do servidor de mídia. Assumir erroneamente que "com a nuvem laranja ativada não é preciso abrir a 10000/UDP" fará com que seja possível entrar na sala, mas não conversar normalmente.

Se você realmente quiser fazer proxy da camada web, verifique separadamente:

• Se o WebSocket de /xmpp-websocket funciona;
• Se o JVB Candidate que o navegador recebe é o IP público correto;
• Se a 10000/UDP é diretamente acessível;
• Se o modo HTTPS é Full (strict) e não Flexible.

Por padrão, uma implantação anônima permite que qualquer visitante crie uma sala, o que pode ser abusado ao ser exposto à internet. Equipes pequenas podem habilitar a autenticação interna já presente na configuração do Docker:

ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal

Aplique a configuração:

cd /opt/jitsi-meet
sudo docker compose up -d

Crie uma conta de moderador:

sudo docker compose exec prosody \
  prosodyctl --config /config/prosody.cfg.lua \
  register host meet.jitsi 'replace-with-a-strong-password'

Depois de habilitada, os usuários autenticados ficam responsáveis por criar salas, e os convidados podem entrar após a aprovação do moderador. Teste separadamente o fluxo de moderador e o de convidado com um navegador anônimo e um navegador normal.

A autenticação interna é adequada para um pequeno número de moderadores fixos. Quando precisar de SSO corporativo, permissões detalhadas ou identidades de reunião emitidas por um sistema de negócio, use uma solução JWT/OIDC. O projeto oficial marcou o antigo processo manual de Secure Domain como obsoleto; não copie tutoriais desatualizados de configuração do Prosody para sistemas novos.

Algumas redes corporativas, o Wi-Fi de hotéis e firewalls rígidos bloqueiam UDP ou conexões ponto a ponto. Nesse caso, você pode implantar o Coturn para que as conexões um a um sejam retransmitidas pelo TURN quando a conexão direta não for possível.

A documentação oficial de TURN do Jitsi usa:

• 3478/UDP: TURN normal;
• 5349/TCP: TURN com TLS;
• Para redes especialmente rígidas, pode-se planejar TLS 443, mas isso exige multiplexação SNI com o HTTPS web ou um servidor separado.

Não coloque nomes de usuário e senhas TURN estáticos diretamente na configuração do frontend. Os navegadores conseguem ver essas credenciais, e outras pessoas podem roubar seu tráfego de retransmissão. Uma opção mais robusta é usar credenciais de curta duração emitidas pelo módulo de serviço externo do Prosody.

O TURN não substitui a 10000/UDP nem transforma um VPS de baixa largura de banda em uma plataforma de reuniões de alta simultaneidade. Ele serve principalmente como alternativa para conexões em redes restritas e aumentará o tráfego de saída do servidor.

A gravação e a transmissão ao vivo no lado do servidor usam o Jibri. O Jibri inicia um navegador, renderiza a reunião, captura áudio e vídeo e codifica, consumindo bem mais recursos que os componentes básicos do Jitsi.

Não habilite o Jibri diretamente em um host de reuniões de 2 núcleos e 2GB. Em produção, prepare um host separado para gravação ou pelo menos reserve CPU, memória e disco dedicados, e planeje:

• O diretório e a capacidade de armazenamento dos arquivos de gravação;
• Se os usuários são claramente informados de que a gravação está em andamento;
• As permissões de acesso aos arquivos e os períodos de retenção;
• O acúmulo local quando o upload para o armazenamento de objetos falha;
• Os limites de simultaneidade para gravar várias reuniões ao mesmo tempo.

Se você só precisa de um salvamento pessoal temporário, avalie primeiro a gravação local no navegador em vez de implantar imediatamente um Jibri completo.

O Jitsi básico não salva o conteúdo de cada reunião como um aplicativo de banco de dados, mas os arquivos a seguir determinam se você consegue reconstruir rapidamente:

/opt/jitsi-meet/.env
/opt/jitsi-meet/docker-compose.yml
/opt/jitsi-meet-cfg/

Registre a versão atual e o estado dos contêineres antes do backup:

cd /opt/jitsi-meet
grep -m1 -o 'stable-[0-9-]*' docker-compose.yml
sudo docker compose ps
cd /
sudo tar \
  --exclude='opt/jitsi-meet-cfg/tmp' \
  -czf /root/jitsi-backup-$(date +%F).tar.gz \
  opt/jitsi-meet/.env \
  opt/jitsi-meet/docker-compose.yml \
  opt/jitsi-meet-cfg

Copie os backups para armazenamento de objetos ou outro servidor; não os deixe apenas no mesmo disco do sistema. .env contém senhas, então os arquivos de backup precisam ser criptografados e ter permissões restritas. Você pode combinar com o tutorial de simulação de backup e restauração de VPS para validar o processo de recuperação.

A recomendação oficial é baixar novamente o Release mais recente em vez de mudar o diretório de produção para master. Antes de atualizar, crie um snapshot do VPS e um backup da configuração, e depois leia as Release Notes.

A partir de stable-11146, os contêineres passam a rodar como não root e com sistema de arquivos somente leitura, e foram adicionados os diretórios storage e tmp. Ao atualizar de versões antigas, primeiro crie e autorize esses diretórios conforme a documentação oficial.

Processo comum de atualização:

1. Baixe e descompacte o novo Release em um novo diretório;
2. Compare os arquivos env.example e Compose antigos e novos;
3. Copie o .env existente e adicione as variáveis exigidas pela nova versão;
4. Preserve os diretórios persistentes /opt/jitsi-meet-cfg;
5. Baixe as novas imagens e execute docker compose up -d;
6. Teste novamente áudio e vídeo com duas redes externas.

Não considere uma atualização entre versões concluída apenas por executar docker compose pull, porque a estrutura do Compose, os diretórios e as variáveis de ambiente também podem mudar.

• Usar o Release estável oficial, não master nem unstable
• PUBLIC_URL corresponde ao domínio HTTPS real
• JVB_ADVERTISE_IPS é o IP público correto
• 80/TCP, 443/TCP e 10000/UDP estão abertas tanto no security group quanto no UFW
• O certificado Let's Encrypt é válido e o HTTP redireciona automaticamente para HTTPS
• Dois dispositivos em redes diferentes concluíram os testes de áudio, vídeo e compartilhamento de tela
• Estranhos não conseguem criar nem abusar livremente das salas de reunião
• .env e o diretório de configuração estão criptografados e com backup fora do local
• Há um snapshot antes da atualização e a versão estável atual está registrada
• O TURN foi testado para compatibilidade com redes restritas, e não apenas a abertura de portas

O critério de uma implantação bem-sucedida do Jitsi Meet não é "a página inicial abre", mas sim que redes externas consigam realizar reuniões com várias pessoas pelos caminhos de mídia HTTPS, WebSocket e UDP corretos. Primeiro acerte PUBLIC_URL, JVB_ADVERTISE_IPS, 10000/UDP e as permissões de criação de salas, e depois considere gravação, transmissão ao vivo, SSO e expansão com vários Videobridge.

• Documentação de implantação do Jitsi Docker
• Releases do docker-jitsi-meet
• Documentação de configuração de TURN do Jitsi