Como Configurar LiveKit e InstanBlog em um VPS com Produção Ativa sem Conflitos

Adicionar novas aplicações a um servidor virtual privado (VPS) que já mantém sites em produção exige precisão cirúrgica. Quando o stack envolve soluções de tempo real como o LiveKit (um servidor de mídia WebRTC/SFU) ao lado de plataformas web convencionais como o InstanBlog, o desafio dobra: conflitos de portas, saturação de recursos e riscos de indisponibilidade da aplicação preexistente tornam-se riscos reais.

Neste guia, exploramos os padrões arquiteturais recomendados para provisionar novos serviços sem interromper o ecossistema já consolidado no servidor.

O Desafio: WebRTC e Aplicações Web em Ambientes Compartilhados

Um site em produção geralmente consome as portas padrão 80 (HTTP) e 443 (HTTPS) por meio de um servidor web como Nginx ou Apache. A introdução de uma nova aplicação web (InstanBlog) e de uma plataforma de streaming/vídeo (LiveKit) traz dois obstáculos principais:

1. Roteamento de Domínios: Múltiplas aplicações HTTP/HTTPS disputando as mesmas portas de entrada.
2. Tráfego WebRTC de Baixa Latência: O LiveKit não opera exclusivamente via TCP/HTTP; ele requer faixas amplas de portas UDP para transporte de mídia RTP, além de portas de sinalização via WebSocket.

Uma configuração mal planejada pode derrubar o serviço principal por consumo excessivo de descritores de arquivo ou disputa de portas.

Arquitetura de Isolamento com Reverse Proxy e Docker

Para blindar a aplicação em produção, a melhor abordagem é encapsular tanto o InstanBlog quanto o LiveKit em containers Docker, orquestrados por uma rede interna que conversa com um Reverse Proxy unificado na máquina host.

1. Reverse Proxy Centralizado (Nginx)

Se o servidor já roda Nginx para o site atual, mantenha-o como o ponto único de terminação SSL e roteador de tráfego HTTP/WebSocket. O tráfego para o InstanBlog e a sinalização do LiveKit passam por ele via diretivas proxy_pass baseadas no Server Name (SNI):

• site-atual.com -> localhost:3000 (Aplicação existente)
• blog.meudominio.com -> localhost:8080 (InstanBlog)
• livekit.meudominio.com -> localhost:7880 (LiveKit Signaling/API)

2. Configuração de Rede do LiveKit

O LiveKit demanda comunicação direta para as faixas UDP do WebRTC (tipicamente entre as portas 50000-60000). Como o Nginx não gerencia nativamente essa distribuição de mídia de forma otimizada sem overhead, expomos essas portas UDP diretamente na interface de rede pública do host, garantindo que não colidam com nenhum processo já em execução.

No arquivo livekit.yaml:
yaml
port: 7880
bind_addresses:

• “0.0.0.0”
  rtc:
  udpport: 7882
  tcpport: 7881
  portrangestart: 50000
  portrangeend: 60000
  useexternalip: true

Controle de Recursos: Protegendo o Site em Produção

Em sistemas que desenvolvo para produção compartilhada, o provisionamento de serviços de áudio/vídeo sempre inclui limites estritos de CPU e memória (cgroups). O processamento de WebRTC pode escalar rapidamente o consumo de CPU em picos de conexões concorrentes.

Defina cotas explícitas no docker-compose.yml:

yaml
services:
livekit:
image: livekit/livekit-server:latest
restart: unless-stopped
deploy:
resources:
limits:
cpus: ‘1.50’
memory: 2G
reservations:
memory: 512M

Essa restrição impede que eventuais gargalos na transmissão de vídeo causem Out-Of-Memory (OOM) no processo do banco de dados ou no servidor web da sua aplicação principal.

Fluxo de Implantação Recomendado

Para garantir transição sem falhas, adote o seguinte roteiro de implantação:

1. Auditoria de Portas e Serviços: Mapeie todas as portas TCP e UDP em uso ativo via ss -tulpn.
2. Configuração de DNS e Certificados: Aponte os novos subdomínios e configure os certificados Let’s Encrypt usando Certbot sem alterar os blocos de servidor existentes.
3. Instalação do InstanBlog: Suba o stack (PHP/Node e banco de dados) isolado em um subdiretório ou container dedicado, mapeando para uma porta local interna.
4. Configuração do LiveKit Server: Inicialize o binário ou container definindo o IP público estático e configurando as chaves de API (API_KEY e API_SECRET).
5. Validação de Firewall (UFW): Libere explicitamente as portas de sinalização (7880-7882) e a faixa de portas de mídia UDP (50000-60000).
6. Testes de Conectividade Sintéticos: Execute testes de WebRTC antes de conectar a interface web definitiva, monitorando os logs do site principal para verificar estabilidade.

Conclusão e Próximos Passos

Subir múltiplos ecossistemas em um mesmo VPS é viável e econômico, desde que a arquitetura respeite o isolamento de rede e limites de consumo de hardware. Uma abordagem modular protege o faturamento gerado pelo site existente enquanto abre caminho para novas funcionalidades interativas.

Se você precisa estruturar ou auditar a infraestrutura do seu servidor, migrar sistemas legados ou implementar soluções de streaming em tempo real com estabilidade garantida, conheça meus serviços de consultoria em arquitetura de software e DevOps.