Hospedar Owncast em um VPS gerenciado: suas transmissões ao vivo em seu servidor

O que o Owncast faz

O Owncast é um servidor de vídeo ao vivo e de chat de código aberto, auto-hospedado e de usuário único: uma instância leva o canal de uma pessoa ou de uma organização. O README dele o apresenta como uma forma de conduzir suas próprias transmissões ao vivo, no estilo das grandes plataformas populares, mantendo a propriedade de seu conteúdo, de sua interface, de sua moderação e de seu público.

• A ingestão: seu software de transmissão, como o OBS, envia o fluxo em RTMP, o protocolo usado pelas grandes plataformas de streaming.
• A distribuição: o Owncast recorta o vídeo em segmentos HLS, em uma ou mais qualidades, e o serve na página web dele. O fluxo também é lido no VLC ou no mpv, em /hls/stream.m3u8.
• O chat: integrado à página, com moderadores, banimentos e login pelo Fediverso ou pelo IndieAuth.
• O Fediverso: uma conta Mastodon pode seguir seu servidor e ser avisada a cada vez que você entra ao vivo. A versão 0.3.0 acrescenta os Featured Streams, que exibem as transmissões ao vivo de outros servidores Owncast.
• A extensão: webhooks, APIs e, desde a 0.3.0, plugins, instalados a partir da administração com as permissões que você concede a eles.

O que a licença MIT permite

O Owncast é publicado sob a licença MIT. Ela concede gratuitamente o direito de usar, copiar, modificar, fundir, publicar, distribuir, sublicenciar e vender cópias do software. Você pode, portanto, rodá-lo para sua empresa, sua comunidade ou seus clientes, sem licença a comprar.

A única condição é manter o aviso de copyright e o texto da licença em todas as cópias ou partes substanciais do software. O texto fornece o software “no estado em que se encontra”, sem garantia.

CPU e banda: dimensionar o servidor

A documentação avisa logo de início: as necessidades dependem de sua configuração. Ela fixa, no entanto, uma regra clara para estimá-las. A CPU transcodifica o vídeo nas qualidades que você oferece; a banda o entrega a cada espectador.

• O número de espectadores não muda a carga da CPU. O vídeo é codificado uma única vez e depois servido a todos: zero espectadores ou cem, o trabalho de codificação é o mesmo. O chat acrescenta um pouco de carga, pequena diante da codificação.
• A banda cresce com cada espectador. Cada espectador recebe a própria cópia do fluxo.
• Cada qualidade transcodificada exige CPU, tanto mais quanto mais baixa for a taxa de bits visada, pois comprimir mais pede mais cálculo.

A banda do servidor

A documentação dá duas fórmulas. O volume de uma transmissão, em gigabytes: taxa de bits em kbps × duração em segundos × espectadores ÷ 8.000.000. A velocidade de saída de pico a sustentar, em Mbps: taxa de bits em kbps × espectadores ÷ 1.000. Com várias qualidades, calcule cada uma e some. As estimativas dela para uma transmissão de duas horas:

Em um VPS Simafri, o tráfego não tem contador mensal: suas transmissões se dimensionam pela taxa de bits de pico. À medida que seu público cresce, o armazenamento de objetos, tratado mais adiante, serve o vídeo no lugar do servidor.

A CPU

A documentação dá referências medidas, lembrando que elas variam com o codec, a taxa de bits, a resolução e a predefinição do codificador:

• Um núcleo por qualidade: como regra aproximada, um único núcleo de CPU costuma dar conta de uma qualidade transcodificada a 30 quadros por segundo.
• A taxa de quadros: 60 quadros por segundo pedem cerca do dobro do cálculo de 30, e 24 quadros por segundo cerca de 0,8 vez.
• A configuração padrão: o Owncast começa com uma única qualidade, a 1.200 kbps e 24 quadros por segundo, com o áudio repassado sem alteração. A documentação aconselha começar por aí, testar e acrescentar uma qualidade quando a CPU tiver folga.

A documentação não informa números de memória, e o disco pesa pouco: os segmentos de vídeo são gravados e depois removidos à medida que a transmissão avança. Só a pasta data cresce com o tempo. Em um VPS, é a CPU que faz a codificação: cada qualidade transcodificada se dimensiona em vCPUs. Em um VPS gerenciado, fale-nos de suas transmissões, da taxa de bits delas, das qualidades e de seu público, e recomendamos o tamanho adequado.

Sua conexão de transmissão

Antes de chegar ao servidor, o fluxo sai de sua própria conexão. A documentação pede uma velocidade de upload de pelo menos 1,5 vez a taxa de bits do fluxo: 7,5 Mbps para um fluxo de 5.000 kbps. Ela recomenda uma conexão por cabo em vez do Wi-Fi.

A instalação com Docker Compose

A documentação propõe a imagem owncast/owncast do Docker Hub, que inclui o ffmpeg, a ferramenta de codificação de que o Owncast precisa. Em um servidor com o Docker instalado, crie uma pasta e coloque nela este compose.yaml, extraído da documentação:

services:
  owncast:
    image: owncast/owncast:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
      - "1935:1935"
    volumes:
      - ./data:/app/data

docker compose up -d

• A porta 8080 publicada em 127.0.0.1: é a única mudança em relação ao exemplo da documentação, que publica as duas portas. A página dela sobre o proxy reverso pede para manter o Owncast fora da internet, pois ele escuta em todas as interfaces por padrão, e o Docker publica uma porta em todos os endereços do servidor quando não recebe nenhum. A interface web passa então a ser acessada apenas pelo proxy reverso.
• A porta 1935 recebe o fluxo em RTMP. Ela continua pública, pois seu software de transmissão a alcança diretamente, sem passar pelo proxy.
• A pasta data guarda o banco e os backups dele no servidor, fora do contêiner: é ela que você salva e transfere.
• A tag latest acompanha a versão mais recente; 0.3.0 fixa uma versão.

Sem Docker: o instalador oficial

O outro caminho da documentação é um script que baixa a última versão do Owncast para sua plataforma, e o ffmpeg se ele ainda não estiver presente. Ele instala tudo em uma pasta owncast dentro da pasta atual. A documentação desaconselha executá-lo como root e recomenda ler qualquer script remoto antes de executá-lo:

curl -s https://owncast.online/install.sh | bash

Para que o Owncast inicie com o servidor e reinicie sozinho após uma falha, a documentação fornece um serviço systemd, a adaptar à pasta e à conta escolhidas:

[Unit]
Description=Owncast
After=network.target

[Service]
Type=simple
WorkingDirectory=/opt/owncast
ExecStart=/opt/owncast/owncast
User=owncast
Group=owncast
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now owncast

Senha de administração e chave de transmissão

A administração fica em /admin. O Owncast inicia com credenciais que todo mundo conhece, e a documentação pede para mudá-las no primeiro login:

Para fazer essa mudança antes de a interface ficar aberta ao público, passe por um túnel SSH: a porta 8080 do servidor aparece em seu computador, em http://localhost:8080/admin. Acrescente -p e a porta SSH indicada em sua área de cliente.

ssh -L 8080:127.0.0.1:8080 user@live.example.com

• A senha de administração é alterada em “Configuration”, “Server Setup”. Ela precisa ter de 8 a 192 caracteres, pelo menos uma letra minúscula, uma maiúscula, um algarismo e um caractere especial entre !@#$%^&*, e nenhum hífen.
• As chaves de transmissão são gerenciadas na aba “Stream Keys” da mesma página. O Owncast propõe uma chave de 30 caracteres gerada automaticamente, e você pode manter várias, cada uma com um comentário: uma chave entregue a um coapresentador pode ser revogada mais tarde sem tocar nas outras.
• Uma senha perdida é substituída na inicialização com a opção --adminpassword, que a grava no banco.

A senha de administração e a chave de transmissão começam ambas como abc123, mas são duas configurações distintas: mude as duas.

HTTPS: o proxy reverso

O Owncast não cuida ele mesmo do HTTPS. A documentação coloca na frente dele um proxy reverso, que escuta nas portas 80 e 443, obtém o certificado, criptografa o tráfego e o repassa sem criptografia ao Owncast na porta 8080. Sem HTTPS, os navegadores marcam a página como não segura, e uma página servida em HTTPS não consegue incorporar seu vídeo nem seu chat.

• O proxy repassa todos os caminhos, inclusive a conexão WebSocket em /ws, que leva o chat. Um proxy que a bloqueia corta o chat.
• O RTMP não passa pelo proxy: seu software de transmissão envia direto para a porta 1935 do Owncast.
• O endereço real dos visitantes: o Owncast lê o cabeçalho X-Forwarded-For para bloquear o endereço IP de um usuário banido do chat. A documentação pede que o próprio proxy defina esse cabeçalho.

Com o Caddy

A documentação sugere o Caddy se você não tem outra preferência: ele obtém sozinho um certificado Let's Encrypt e repassa o WebSocket sem configuração extra. Veja o exemplo de Caddyfile dela, em que a linha tls informa o endereço de e-mail da conta Let's Encrypt:

live.example.com {
  encode gzip
  reverse_proxy 127.0.0.1:8080
  tls contact@example.com
}

Com o Nginx

Com o Nginx, a documentação insiste no WebSocket: é esquecê-lo que desativa o chat. Acrescente este bloco map à seção http de /etc/nginx/nginx.conf:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

Este bloco de site retoma o da documentação, na porta 80 para deixar o Certbot instalar o HTTPS:

server {
    listen 80;
    listen [::]:80;
    server_name live.example.com;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Authorization $http_authorization;
        proxy_pass_header Authorization;
        proxy_pass http://127.0.0.1:8080;
    }
}

sudo nginx -t
sudo certbot --nginx

Transmitir em RTMP a partir do OBS

O Owncast aceita qualquer software que transmita em RTMP para um servidor remoto. A chave só é aceita no caminho /live. No OBS:

1. Abra “Configurações”, depois “Transmissão”, e escolha “Personalizado” como serviço.
2. Informe o endereço rtmp://live.example.com:1935/live.
3. Informe sua chave de transmissão, a da aba “Stream Keys” do Owncast.
4. Inicie a transmissão.

Um software sem campo para a chave aceita o endereço completo, rtmp://live.example.com:1935/live/your-key.

Em um VPS Simafri, o endereço IPv6 do servidor pode abrir a porta que você escolher: seu software de transmissão alcança a porta 1935 por esse endereço, em um nome que leva o registro AAAA. Em uma rede Docker IPv4, como aqui, o Docker encaminha a porta do endereço IPv6 do servidor para o contêiner. Abra essa porta se o ufw estiver ativo e teste a partir de seu computador:

sudo ufw allow 1935/tcp
nc -6 -vz live.example.com 1935

Para qualquer outra necessidade, conte-nos o que você tem em mente e examinamos o endereçamento com você.

As configurações de seu software de transmissão

• Os codecs: H.264 para o vídeo e AAC para o áudio, os únicos para os quais a transcodificação e a compatibilidade de reprodução são garantidas.
• O intervalo de quadros-chave: um a cada 2 segundos, nunca deixado em “automático”. No OBS, o intervalo é em segundos, portanto 2.
• A taxa de bits: envie o que você pretende oferecer, não mais. Se seu servidor dá conta de 720p a 2.500 kbps, não envie a ele 1080p a 6.000 kbps: cada conversão pedida acrescenta carga à CPU.

As qualidades de vídeo e a latência

As qualidades oferecidas aos espectadores são configuradas em “Configuration”, “Video”. Várias qualidades permitem ao player escolher a que a conexão dele consegue sustentar: a documentação recomenda uma segunda qualidade, de 1.000 a 2.000 kbps, ao lado de uma qualidade alta de 4.000 a 6.000 kbps, depois de testada sua primeira configuração.

• A taxa de bits: de 400 a 13.000 kbps, em passos de 100.
• A taxa de quadros: de 24 a 120 quadros por segundo, 24 por padrão.
• A resolução: mude a largura ou a altura, não as duas, e o Owncast mantém a proporção.
• O uso da CPU: cinco níveis. Quanto mais alto o nível, melhor a imagem, ou menor o arquivo com qualidade igual.

O passthrough repassa o vídeo recebido sem recodificá-lo: ele economiza quase toda a CPU dessa qualidade e ignora as configurações de taxa de bits, de resolução e de taxa de quadros dela. A documentação o reserva aos usuários avançados: os espectadores recebem exatamente o que seu software envia, o que alguns players não conseguem reproduzir, e a latência aumenta. Teste a reprodução nos dispositivos que importam para você antes de contar com ele.

A latência se ajusta pelo buffer de latência, na mesma página. Cada nível troca um pouco de atraso por estabilidade, e uma mudança vale a partir da próxima transmissão:

A versão 0.3.0 também acrescenta, do lado do espectador, a opção “Minimize latency” do player, que acelera ligeiramente a reprodução para se aproximar do ao vivo, e uma configuração de reprodução automática, desativada por padrão.

O armazenamento de objetos para servir mais espectadores

O Owncast pode enviar os segmentos de vídeo para um armazenamento compatível com S3, de onde os espectadores os baixam. O servidor continua servindo a playlist principal, as APIs e o chat; o vídeo, que representa quase toda a banda, vem do armazenamento. Seu servidor envia então uma única cópia de cada qualidade: no exemplo da documentação, 6,5 Mbps para duas qualidades a 5.000 e 1.500 kbps, com zero espectadores ou com mil. A carga da CPU continua a mesma.

1. Crie um bucket em seu provedor de armazenamento de objetos.
2. Torne-o legível publicamente e defina uma política CORS se o provedor exigir: um erro CORS ou Access-Control-Allow-Origin no console do navegador quase sempre vem daí.
3. Em “Configuration”, “Server Setup”, aba “S3 Object Storage”, ative o armazenamento e informe o nome do bucket, a chave de acesso, a chave secreta, o endpoint e a região. Todos esses campos são obrigatórios.

Esse armazenamento serve o ao vivo, não um arquivo: o Owncast exclui, à medida que avança, os segmentos mais antigos que a playlist mais uma margem de cerca de 20 segmentos. O bucket guarda apenas os últimos minutos da transmissão.

Para espectadores espalhados pelo mundo, a documentação também descreve uma rede de distribuição de conteúdo (CDN) colocada na frente do Owncast, com um nome de host de origem distinto e a configuração “Websocket host override”, que mantém o chat conectado ao servidor de origem.

O chat e a moderação

O chat é configurado em “Configuration”, “Chat”. Por padrão, não há nenhum moderador: a documentação sugere ao menos nomear você mesmo, a partir da página “Users” da administração.

• Os moderadores ocultam uma mensagem ou banem um usuário a partir do próprio chat. Eles não têm acesso à administração.
• Um banimento desconecta o usuário, remove as mensagens dele e bloqueia o endereço IP conhecido dele. Ele pode ser revogado mais tarde; já a exclusão de um usuário é definitiva.
• Apenas usuários estabelecidos: essa configuração bloqueia as mensagens das contas com menos de 15 minutos, exceto as dos moderadores.
• O filtro de linguagem recusa as mensagens ofensivas, a partir de uma lista interna de palavras.
• A autenticação obrigatória só deixa enviar mensagens os usuários autenticados, por uma conta do Fediverso ou pelo IndieAuth, e os moderadores.
• O limitador de ritmo, ativo por padrão, autoriza cerca de uma mensagem a cada dois terços de segundo e bloqueia por 10 segundos quem inunda o chat.

A documentação lembra que o bloqueio por IP pode ser contornado, com uma VPN, por exemplo: ele reduz os abusos, e a moderação continua sendo o trabalho próprio de cada canal. Daí o valor de moderadores nomeados para suas transmissões mais assistidas.

Os backups

O Owncast faz backup do próprio banco uma vez por hora, em data/backup/owncastdb.bak. A opção --backupdir muda essa pasta. Veja o que a pasta de dados contém:

Para uma recuperação completa, ou para transferir a instância, a documentação pede para salvar a pasta data inteira: copiá-la em uma nova instalação leva tudo junto. Com o Docker, com o serviço parado:

docker compose down
tar -czf owncast-$(date +%F).tar.gz data
docker compose up -d

Agende essa cópia de acordo com suas transmissões e envie-a para fora do servidor. Colocados no disco dele, esses arquivos também entram nos backups noturnos dele.

Restaurar o banco

Uma restauração leva o banco de volta ao momento do backup: tudo o que mudou desde então se perde. Copie primeiro o banco atual em um lugar seguro e depois:

1. Pare o Owncast.
2. Inicie o Owncast com --restoreDatabase e o caminho do arquivo de backup: ele restaura o banco e encerra.
3. Inicie o Owncast normalmente e confira suas configurações na administração.

docker compose stop
docker compose run --rm owncast --restoreDatabase data/backup/owncastdb.bak
docker compose up -d

As atualizações

Com o Docker, a documentação dá dois comandos, executados a partir da pasta do compose.yaml. A pasta de dados continua no lugar:

docker compose pull
docker compose up -d

Com o instalador, as notas da versão 0.3.0 descrevem a atualização: pare o serviço, separe os arquivos da interface web que você tiver personalizado, execute de novo o instalador com a conta que roda o Owncast e reinicie. O próprio script guarda um arquivo da pasta data em owncast-install-backups antes de substituir a versão.

sudo systemctl stop owncast
su -c "curl https://owncast.online/install.sh | bash" owncast
sudo systemctl start owncast

A versão 0.3.0, lançada em 3 de setembro de 2026, traz os plugins, os Featured Streams, a reprodução automática e a escolha da interface em que o RTMP escuta. As notas dela pedem para ler as mudanças antes de atualizar, pois elas afetam sua instância: acompanhe essas notas a cada versão e copie a pasta data logo antes.

Quem faz o quê em um VPS gerenciado

A auto-hospedagem exige cuidar do servidor além da aplicação. Em um VPS gerenciado, nossas equipes assumem o servidor e acompanham sua instância de forma proativa; o Owncast continua sendo seu software, com as configurações e os dados dele.

Se você preferir que nossas equipes intervenham na própria aplicação, esse serviço é cobrado por hora ou por valor fechado, com o orçamento informado antes da intervenção.