LiveKit: self-host

Faz sentido quando o uso é grande o suficiente pra um custo fixo de VPS sair mais barato que pagar por minuto no LiveKit Cloud, ou quando você já mantém infra própria e prefere concentrar tudo.

Qualquer VPS com IP público serve. Os exemplos aqui usam a Vultr porque tem planos baratos com banda generosa incluída — não é a única opção, é só a mais testada por quem mantém esta documentação.

1. Provisionar a VPS

Crie conta na Vultr.

Deploy New Server → Cloud Compute → plano High Frequency (a partir de ~US$6/mês: NVMe, CPU dedicada, 2TB de banda incluída — o suficiente pra uma comunidade pequena/média).

Escolha a região mais próxima da sua comunidade.

Sistema operacional: Ubuntu 24.04.

2. Apontar um domínio

LiveKit precisa de HTTPS/WSS — sem domínio não tem certificado TLS válido, e sem TLS o navegador bloqueia a conexão WebRTC.

Crie um registro DNS tipo A apontando um subdomínio (ex: livekit.suacomunidade.com) pro IP da VPS. Confirme que propagou antes de seguir:

dig +short livekit.suacomunidade.com

3. Instalar o LiveKit

A própria LiveKit mantém um instalador oficial que configura Docker Compose

Caddy (TLS automático) + geração de API key/secret numa tacada só. Rode via SSH, dentro da VPS:

curl -sSL https://get.livekit.io | bash

O instalador pergunta o domínio (o que você apontou no passo 2) e cuida do resto. Ao final, ele mostra LIVEKIT_API_KEY, LIVEKIT_API_SECRET e a URL (wss://SEU-DOMINIO). Guarde os três.

Referência oficial: docs.livekit.io/home/self-hosting/vm.

4. Portas

O instalador já abre o necessário:

443/TCP — sinalização e TLS
UDP 50000-60000 — mídia (áudio/vídeo de verdade trafega aqui)

Se a Vultr tiver um firewall de borda ativado no dashboard (separado do firewall da própria VPS), libere essa mesma faixa lá também — é a causa mais comum de "conecta mas ninguém ouve ninguém" em self-host.

Variáveis desta etapa

Variável	Valor
`LIVEKIT_URL`	`wss://SEU-DOMINIO`
`LIVEKIT_API_KEY`	Gerada pelo instalador
`LIVEKIT_API_SECRET`	Gerada pelo instalador

Rodar o Next.js na mesma VPS?

Dá pra fazer — o Caddy que o instalador já configurou consegue servir um segundo domínio/subdomínio pro Next.js na mesma máquina, sem custo extra de hospedagem. Mas isso acopla o app ao servidor de voz: um deploy ruim ou um pnpm build pesado competindo por CPU pode afetar chamadas em andamento, e você fica responsável por process manager (pm2/systemd) e deploy manual (sem o git-push-automático que Railway dá de graça).

Recomendação: comece com o Next.js num serviço separado (ver Deploy do Next.js) e só considere juntar na mesma VPS se o custo extra de um segundo serviço realmente importar pro seu orçamento.

Dashboard de métricas de infra (opcional)

Com uma VPS própria, o painel de admin do OpenCall pode mostrar CPU/RAM/disco/banda em tempo real. Isso é um passo separado, documentado no próprio repo do app em infra/vps-metrics/README.md — envolve instalar dois scripts via cron na VPS e configurar SERVER_METRICS_INGEST_SECRET + VPS_SSH_HOST/VPS_SSH_USER/VPS_SSH_PRIVATE_KEY no serviço do Next.js. Sem isso configurado, a aba "Infra" do admin simplesmente não aparece — não precisa fazer se não quiser.