Jitsi Meet no Brasil: VPS para chamadas estáveis

Resposta direta

Para rodar Jitsi Meet em produção no Brasil, comece com uma VPS de 2 vCPUs, 4 GB de RAM, 40 GB de SSD e pelo menos 1 TB de transferência mensal para salas pequenas com até 10 ou 15 participantes simultâneos. Para 25 a 50 participantes, considere 4 vCPUs, 8 GB de RAM, rede de 1 Gbps e monitoramento de CPU, banda e perda de pacotes. A latência pesa muito na experiência: quando o público está no Brasil, um servidor em datacenter nacional ou em região próxima costuma reduzir atraso, jitter e falhas de áudio. Além disso, libere corretamente as portas do Jitsi, proteja SSH, use HTTPS, configure firewall e avalie TURN se houver usuários atrás de redes corporativas restritivas.

Resumo rápido

• Jitsi Meet usa o servidor como ponto central de sinalização e encaminhamento de mídia, principalmente pelo Jitsi Videobridge.
• Para poucas salas, 2 vCPUs e 4 GB de RAM já permitem testes sérios e reuniões pequenas.
• A banda de saída cresce rápido, especialmente com vídeo ligado e muitos participantes simultâneos.
• Latência abaixo de 50 ms para usuários no Brasil melhora áudio, vídeo e compartilhamento de tela.
• Firewall mal configurado costuma causar sala que abre, mas sem áudio ou vídeo entre participantes.
• Gravação com Jibri e TURN com coturn podem exigir VPS separada ou mais CPU e RAM.
• Não trate preço, storage NVMe, backup ou localidade como fixos sem conferir a página oficial do provedor.

Por que o Jitsi Meet exige planejamento de VPS

Jitsi Meet parece simples para o usuário final: a pessoa abre um link no navegador, autoriza câmera e microfone, e entra na reunião. No servidor, a história é mais trabalhosa. Uma instalação típica reúne Nginx, Prosody, Jicofo e Jitsi Videobridge. O Nginx entrega a interface web e termina HTTPS. O Prosody cuida da sinalização XMPP. O Jicofo coordena as conferências. O Jitsi Videobridge, também chamado de JVB, encaminha os fluxos de áudio e vídeo entre os participantes.

Essa arquitetura explica por que a VPS não pode ser escolhida apenas pelo número de sites que ela roda ou pela quantidade de armazenamento. Em videoconferência, o gargalo aparece em CPU, rede, latência e estabilidade. O disco é relevante para logs, sistema, pacotes e gravações, mas uma reunião ao vivo depende muito mais de processamento e tráfego constante. Uma instância com 80 GB de disco e pouca banda pode falhar antes de encher o armazenamento.

O que roda no servidor

O servidor do Jitsi não transcodifica todos os vídeos como uma plataforma de streaming tradicional. Em geral, ele encaminha pacotes WebRTC entre os navegadores. Isso reduz a necessidade de CPU quando comparado a transcodificação pesada, mas não elimina consumo. Criptografia, controle de sessões, encaminhamento de múltiplos fluxos, estatísticas e renegociação de mídia ainda pesam. Em uma reunião com 20 pessoas, o JVB precisa lidar com muitos fluxos simultâneos, mesmo que cada participante veja apenas alguns vídeos em destaque.

O que roda no navegador dos participantes

Parte do trabalho fica no cliente. Notebook fraco, câmera em 1080p, Wi-Fi congestionado e navegador desatualizado podem derrubar a experiência mesmo com servidor bom. Por isso, a infraestrutura deve ser dimensionada com margem. Se você está montando uma solução para aulas, reuniões internas ou atendimento remoto, trate a VPS como uma peça do conjunto. Para entender o impacto de localidade e rota de rede, o guia sobre VPS para baixa latência no Brasil ajuda a separar problema de servidor, rota e conexão do usuário.

CPU, RAM e disco por número de participantes

O dimensionamento do Jitsi Meet deve partir de participantes simultâneos, não de usuários cadastrados. Uma escola pode ter 300 alunos, mas se apenas duas turmas entram ao mesmo tempo, o servidor não precisa suportar 300 câmeras simultâneas. Da mesma forma, uma empresa com 40 funcionários pode exigir bastante se todos participam de reuniões longas com câmera, compartilhamento de tela e gravação.

Para um laboratório, 1 vCPU e 2 GB de RAM podem instalar o Jitsi e permitir testes com poucas pessoas. Não é a configuração que eu usaria para produção. Em uso real, uma base mais confortável começa em 2 vCPUs e 4 GB de RAM. Isso dá folga para sistema operacional, Nginx, Prosody, Jicofo, JVB, logs e picos de CPU durante entrada de participantes. O disco pode começar em 40 GB SSD, desde que gravações não fiquem no mesmo servidor por muito tempo.

Estimativa prática de recursos

Uma sala com até 10 participantes, vídeo em 720p moderado e sem gravação costuma se encaixar em 2 vCPUs e 4 GB de RAM, desde que a rede seja estável. Para 25 participantes simultâneos, 4 vCPUs e 8 GB de RAM são uma referência mais segura. Para 50 participantes, pense em 8 vCPUs, 16 GB de RAM, rede de 1 Gbps e monitoramento ativo. Acima disso, vale avaliar múltiplos JVBs, balanceamento e testes com carga real.

O uso de swap deve ser mínimo. Swap em servidor de videoconferência pode transformar um pico administrável em congelamento perceptível. Se a RAM passa de 80% durante reuniões normais, aumente o plano ou separe serviços. Monitorar com htop, vnstat, journalctl e métricas do JVB ajuda a detectar padrões antes que usuários reclamem.

Quando separar componentes

Separar componentes começa a fazer sentido quando você adiciona gravação, TURN para muitos usuários, múltiplas salas simultâneas ou autenticação integrada. Um desenho comum é manter o Jitsi Meet principal em uma VPS, rodar coturn em outra instância pequena com IP público próprio, e deixar Jibri em uma máquina separada com mais CPU. Essa separação reduz disputa por recursos e facilita manutenção. Em produção, pense em snapshots e backup de configuração, mas confirme no provedor se esses recursos existem no plano e na localidade escolhida.

Banda, latência e localização no Brasil

Banda é o ponto que mais pega quem dimensiona Jitsi pela primeira vez. Em sites comuns, você calcula páginas, imagens, cache e picos de acesso. Em videoconferência, cada participante envia e recebe mídia em tempo real. Uma câmera em 720p pode variar de algumas centenas de Kbps a mais de 2 Mbps, dependendo de movimento, codec, qualidade selecionada e condições de rede. O servidor precisa encaminhar esses fluxos com baixa perda e sem saturar a interface.

Uma forma simples de estimar é trabalhar com cenários. Se uma reunião tem 10 participantes e cada um consome, em média, 1 Mbps de tráfego de vídeo recebido, o volume agregado no servidor cresce conforme os fluxos encaminhados. Na prática, o total não é apenas 10 Mbps, porque há envio, recebimento, áudio, tela compartilhada, camadas de qualidade e overhead. Para salas pequenas, uma conexão de 100 Mbps pode bastar. Para uso com 30 ou 50 pessoas simultâneas, prefira porta de 1 Gbps e franquia mensal compatível.

Como estimar tráfego

Pense em três números: taxa média por participante, duração das reuniões e simultaneidade. Um time com 20 pessoas em reuniões de 2 horas por dia pode gerar tráfego bem diferente de uma escola com 6 salas ao mesmo tempo durante 4 horas. Se você assumir 1,5 Mbps médios por participante em sessões com vídeo, 30 participantes simultâneos podem exigir dezenas de Mbps sustentados, com picos maiores quando alguém compartilha tela em alta resolução.

O cálculo mensal também importa. Uma reunião com 20 participantes durante 1 hora, usando tráfego agregado elevado, pode consumir vários gigabytes. Multiplique isso por dias úteis e salas paralelas. Se o provedor cobra excedente de transferência ou reduz velocidade após certo limite, esse detalhe precisa ser revisado antes da publicação de qualquer comparação de preço.

Por que latência muda a experiência

Latência não é só número bonito em teste de ping. Em chamada de vídeo, atraso alto cria sobreposição de fala, pausas estranhas e sensação de conversa truncada. Jitter e perda de pacotes são ainda piores, porque causam cortes de áudio e vídeo congelando. Para público brasileiro, hospedar em São Paulo, Fortaleza ou outra região nacional disponível pode reduzir bastante a rota, mas a disponibilidade real depende do provedor e do plano. Se a VPS ficar nos Estados Unidos, alguns usuários podem ver 120 ms a 180 ms de latência, o que ainda funciona, mas deixa menos margem para redes domésticas ruins.

IPv6 também pode ajudar em ambientes específicos, principalmente quando usuários e redes corporativas já têm boa conectividade nesse protocolo. Não é cura automática para latência, mas faz parte de uma configuração moderna. Se esse ponto está no seu radar, veja o conteúdo sobre VPS com IPv6 no Brasil antes de fechar a arquitetura.

Firewall, portas e hardening para Jitsi Meet

Jitsi Meet depende de portas específicas para funcionar bem. O caso clássico de erro é a página abrir normalmente em HTTPS, os usuários entrarem na sala, mas áudio e vídeo não conectarem. Isso acontece quando a sinalização funciona, mas o tráfego WebRTC fica bloqueado por firewall, NAT, regra de segurança do provedor ou configuração incorreta do JVB. Em VPS, você precisa alinhar firewall do sistema, security group do painel cloud e regras de rede do provedor.

Em instalações padrão, as portas TCP 80 e 443 são usadas para HTTP e HTTPS. A porta UDP 10000 costuma ser usada pelo Jitsi Videobridge para mídia. A porta TCP 22 fica para SSH, mas não deve permanecer exposta sem cuidado. Dependendo da configuração, podem aparecer portas adicionais para Prosody, TURN, métricas ou administração. Não abra tudo. Abra apenas o necessário, registre a decisão e teste com usuários fora da sua rede local.

Portas mais comuns

Uma política inicial com UFW em Ubuntu poderia permitir 80/tcp, 443/tcp, 10000/udp e SSH em uma porta controlada. Exemplo: permitir SSH apenas para o IP do escritório ou para uma VPN administrativa. Em vez de depender de senha, use chave pública. Desative login root direto quando possível. Ative atualizações de segurança e acompanhe logs com journalctl, auth.log e métricas de tentativas de acesso.

Um exemplo prático de checagem é testar a sala em três redes: banda larga residencial, 4G ou 5G e rede corporativa. Se funciona em casa, mas falha na empresa, pode ser bloqueio de UDP. Nesse caso, TURN sobre TCP 443 pode ser necessário. Só que TURN aumenta tráfego no servidor e muda o dimensionamento, então não deve ser tratado como detalhe secundário.

Acesso administrativo e atualizações

Hardening não é luxo em servidor de videoconferência. A URL de reunião pode circular fora da empresa, bots varrem IPs públicos e servidores mal atualizados viram alvo. Use certificados válidos, senhas fortes para salas sensíveis, autenticação quando fizer sentido e atualizações frequentes do sistema. O guia de VPS com firewall e hardening de segurança aprofunda medidas como UFW, Fail2ban, SSH com chave e redução de superfície de ataque.

Também vale separar contas administrativas de usuários comuns. Em uma instalação corporativa, habilitar autenticação para criação de salas e permitir convidados apenas após a entrada do organizador reduz abuso. Para eventos públicos, configure lobby, senha e moderação. O servidor pode estar tecnicamente saudável, mas uma reunião aberta sem controle vira problema operacional em minutos.

TURN, gravação e recursos que mudam o dimensionamento

A instalação básica do Jitsi Meet atende muitos cenários, mas alguns recursos mudam completamente o perfil da VPS. O primeiro é TURN, normalmente implementado com coturn. Ele ajuda usuários atrás de NAT restritivo, firewall corporativo ou redes que bloqueiam UDP direto. Quando o caminho ponto a ponto ou o transporte normal falha, o tráfego pode ser retransmitido pelo TURN. Isso resolve conectividade, mas aumenta consumo de banda e CPU no servidor que faz o relay.

Se o seu público acessa de escolas, hospitais, órgãos públicos ou empresas com firewall rígido, planeje TURN desde o início. Uma instância pequena dedicada, por exemplo 1 ou 2 vCPUs e 1 a 2 GB de RAM, pode ser suficiente para poucos usuários, mas o gargalo real será rede. Para muitos participantes usando relay ao mesmo tempo, a transferência cresce rápido. Teste com redes reais, não apenas com desenvolvedores em fibra residencial.

Quando usar coturn

Use coturn quando houver relatos de tela preta, áudio que não conecta, participantes que entram e caem, ou falha apenas em redes específicas. Configure TLS, restrinja acesso quando aplicável e monitore tráfego. Em ambientes mais controlados, uma VPN corporativa pode reduzir a necessidade de TURN, mas nem sempre é viável para convidados externos. O ponto central é não colocar coturn na mesma VPS do Jitsi principal sem avaliar margem de banda.

O segundo recurso pesado é gravação. No ecossistema Jitsi, gravação e transmissão costumam envolver Jibri, que abre uma sessão headless do Chrome, captura a conferência e grava ou transmite o conteúdo. Isso consome CPU, RAM e disco de forma bem diferente do JVB. Uma gravação em 720p pode usar vários gigabytes por hora, dependendo de qualidade e codec.

Jibri e gravação

Para Jibri, prefira uma VPS separada com 4 vCPUs, 4 a 8 GB de RAM e disco suficiente para armazenamento temporário. Se você grava aulas diariamente, 80 GB desaparecem rápido. Uma rotina de upload para object storage, limpeza automática e retenção por período definido evita pane por disco cheio. Também é melhor não gravar no mesmo servidor que sustenta a reunião ao vivo, porque picos de CPU do Chrome headless podem causar engasgos perceptíveis.

Streaming para YouTube ou outra plataforma adiciona outra camada de risco. A reunião depende do Jitsi, o Jibri depende da reunião, e a transmissão depende da plataforma externa. Para eventos importantes, faça ensaio com o mesmo número aproximado de participantes, mesma resolução, mesma rede e mesma conta de transmissão. Sem esse teste, qualquer estimativa vira aposta.

Tabela prática de dimensionamento

A tabela abaixo usa perfis conservadores para orientar uma primeira escolha de VPS para Jitsi Meet no Brasil. Ela não substitui teste de carga, porque codec, resolução, redes dos usuários, número de salas e uso de TURN podem alterar bastante o consumo. Ainda assim, ajuda a evitar dois extremos comuns: contratar uma VPS mínima para reunião crítica ou superdimensionar antes de medir qualquer coisa.

Cenário de uso	Participantes simultâneos	VPS sugerida	Rede e transferência	Observações técnicas
Laboratório e validação	3 a 8	2 vCPUs, 2 a 4 GB RAM, 30 a 40 GB SSD	100 Mbps, franquia baixa a média	Bom para testes, não ideal para reuniões críticas com gravação
Time pequeno	10 a 20	2 a 4 vCPUs, 4 a 8 GB RAM, 40 a 80 GB SSD	100 Mbps a 1 Gbps, pelo menos 1 TB mensal	Monitorar CPU, UDP 10000, perda de pacotes e uso de RAM
Escola, consultório ou operação interna	25 a 50	4 a 8 vCPUs, 8 a 16 GB RAM, 80 GB SSD ou NVMe	1 Gbps, franquia mensal generosa	Pode exigir TURN separado e política de salas com senha
Evento ou produção crítica	50 ou mais	Múltiplos JVBs ou arquitetura separada	1 Gbps ou mais, teste prévio obrigatório	Precisa ensaio, monitoramento, plano de contingência e revisão humana

Em provedores como DigitalOcean, Vultr, Linode/Akamai, AWS Lightsail, Google Cloud, Azure, Oracle Cloud, Hetzner, Contabo, Hostinger, HostGator, Locaweb e LetsCloud, os pontos que precisam de verificação são parecidos: localidade disponível, tipo de disco, limite de transferência, política de uso justo, snapshots, backup, IPv4, IPv6 e custo de tráfego excedente. Não publique comparação de preço sem revisão humana, porque valores, promoções e regiões mudam com frequência.

LetsCloud pode entrar na análise quando o objetivo é hospedar mais perto do público brasileiro ou pagar em reais, desde que a localidade, o tipo de storage e recursos como snapshot ou backup sejam confirmados no site oficial antes da publicação. DigitalOcean, Vultr e Linode/Akamai costumam ser lembrados pela documentação e ecossistema de cloud. AWS, Google Cloud e Azure dão mais opções corporativas, mas podem exigir mais cuidado com custos de rede. Essa leitura é editorial, não um ranking definitivo.

O melhor uso da tabela é definir um ponto de partida e validar. Suba a VPS, instale Jitsi, chame usuários reais, monitore por 60 a 90 minutos e registre CPU, RAM, tráfego de saída, perda de pacotes e relatos de áudio. Se a sala fica bem com 15 pessoas, não assuma automaticamente que ficará bem com 45. A curva de tráfego e de problemas de rede não cresce de forma perfeitamente linear.

Recomendações por perfil

Dev solo e laboratório

Para aprender Jitsi Meet, criar uma prova de conceito ou validar integração com autenticação, uma VPS de 2 vCPUs, 2 a 4 GB de RAM e 30 a 40 GB de SSD resolve bem. Use Ubuntu LTS, domínio próprio, HTTPS válido e firewall com apenas as portas necessárias. Faça testes com 3 a 8 participantes em redes diferentes. Não misture esse ambiente com produção de cliente. Laboratório bom é descartável: documente instalação, variáveis, regras de firewall e comandos usados, para conseguir recriar tudo em outra VPS em menos de uma hora.

Time pequeno ou escola

Para reuniões internas, aulas pequenas, atendimento remoto ou grupos de 10 a 25 pessoas, comece em 2 a 4 vCPUs, 4 a 8 GB de RAM e 40 a 80 GB de SSD. Dê preferência a datacenter no Brasil ou região com baixa latência para a maioria dos usuários. Configure autenticação para criação de salas, senha para reuniões sensíveis e monitoramento simples com alertas de CPU, disco e tráfego. Se muitos usuários acessam de redes corporativas, teste coturn cedo. É melhor descobrir bloqueio de UDP em uma simulação do que durante uma aula cheia.

Produção com reuniões críticas

Para operação crítica, como teleatendimento, reuniões executivas, treinamento recorrente ou eventos pagos, trate Jitsi como serviço de produção. Use pelo menos 4 a 8 vCPUs, 8 a 16 GB de RAM e rede de 1 Gbps para o nó principal, com TURN e gravação separados quando necessários. Tenha plano de contingência, backup de configuração, snapshots testados, atualização programada e monitoramento de disponibilidade. Antes de eventos grandes, faça ensaio com carga parecida, incluindo câmera, microfone, compartilhamento de tela e gravação. Se a reunião não pode falhar, a arquitetura precisa prever falha parcial sem improviso.