Alojar Owncast num VPS gerido: as suas transmissões em direto no seu servidor

O que faz o Owncast

O Owncast é um servidor de transmissão de vídeo em direto e de chat, de código aberto, autoalojado e de utilizador único: uma instância suporta o canal de uma pessoa ou de uma organização. O seu README apresenta-o como uma forma de fazer as suas próprias transmissões em direto, ao estilo das grandes plataformas, mantendo a propriedade do seu conteúdo, da sua interface, da sua moderação e do seu público.

• A receção: o seu software de transmissão, como o OBS, envia o sinal em RTMP, o protocolo utilizado pelas grandes plataformas de streaming.
• A difusão: o Owncast corta o vídeo em segmentos HLS, numa ou em várias qualidades, e serve-o na sua página web. O sinal lê-se também no VLC ou no mpv, em /hls/stream.m3u8.
• O chat: integrado na página, com moderadores, banimentos e início de sessão pelo Fediverso ou pelo IndieAuth.
• O Fediverso: uma conta Mastodon pode seguir o seu servidor e ser avisada de cada direto. A versão 0.3.0 acrescenta os Featured Streams, que mostram os diretos de outros servidores Owncast.
• As extensões: webhooks, API e, desde a 0.3.0, plugins, instalados a partir da administração com as permissões que lhes conceder.

O que permite a licença MIT

O Owncast é publicado sob a licença MIT. Esta concede, gratuitamente, o direito de utilizar, copiar, modificar, fundir, publicar, distribuir, sublicenciar e vender cópias do software. Pode, portanto, fazê-lo correr para a sua empresa, a sua comunidade ou os seus clientes, sem licença para comprar.

A única condição é manter o aviso de direitos de autor e o texto da licença em todas as cópias ou partes substanciais do software. O texto fornece o software «tal como está», sem garantia.

Processador e largura de banda: dimensionar o servidor

A documentação começa por dizê-lo: as necessidades dependem da sua configuração. Estabelece, no entanto, uma regra clara para as estimar. O processador transcodifica o vídeo nas qualidades que oferece; a largura de banda entrega-o a cada espectador.

• O número de espectadores não muda a carga do processador. O vídeo é codificado uma 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 ao lado da codificação.
• A largura de banda cresce com cada espectador. Cada espectador recebe a sua própria cópia do sinal.
• Cada qualidade transcodificada exige processador, tanto mais quanto mais baixo for o débito pretendido, porque comprimir mais exige mais cálculo.

A largura de banda do servidor

A documentação dá duas fórmulas. O volume de uma transmissão, em gigabytes: débito em kbps × duração em segundos × espectadores ÷ 8 000 000. O débito de saída de pico a sustentar, em Mbps: débito em kbps × espectadores ÷ 1000. Com várias qualidades, calcule cada uma e some-as. As suas estimativas para uma transmissão de duas horas:

Num VPS Simafri, o tráfego não tem contador mensal: as suas transmissões dimensionam-se pelo seu débito de pico. Quando o público cresce, o armazenamento de objetos, apresentado mais abaixo, serve o vídeo no lugar do servidor.

O processador

A documentação dá pontos de referência medidos, assinalando que variam com o codec, o débito, a resolução e a predefinição do codificador:

• Um núcleo por qualidade: como regra aproximada, um único núcleo de processador consegue muitas vezes tratar uma qualidade transcodificada a 30 imagens por segundo.
• A cadência: 60 imagens por segundo exigem cerca do dobro do cálculo de 30, e 24 imagens por segundo cerca de 0,8 vezes.
• A definição predefinida: o Owncast arranca com uma única qualidade, a 1200 kbps e 24 imagens por segundo, com o áudio transmitido sem alteração. A documentação aconselha a começar por aí, testar e depois acrescentar uma qualidade quando o processador tiver margem.

A documentação não indica nenhum valor de memória, e o disco conta pouco: os segmentos de vídeo são escritos e depois apagados à medida que o direto avança. Só a pasta data cresce com o tempo. Num VPS, é o processador que codifica: cada qualidade transcodificada dimensiona-se em vCPU. Num VPS gerido, descreva-nos as suas transmissões, o seu débito, as suas qualidades e o seu público, e recomendamos-lhe o tamanho adequado.

A sua ligação de transmissão

Antes de chegar ao servidor, o sinal sai da sua própria ligação. A documentação pede um débito ascendente de pelo menos 1,5 vezes o débito do sinal: 7,5 Mbps para um sinal de 5000 kbps. Recomenda uma ligação por cabo em vez do Wi-Fi.

A instalação com o Docker Compose

A documentação propõe a imagem owncast/owncast no Docker Hub, que inclui o ffmpeg, a ferramenta de codificação de que o Owncast precisa. Num servidor com o Docker instalado, crie uma pasta e coloque nela este compose.yaml, tirado 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 alteração em relação ao exemplo da documentação, que publica as duas portas. A sua página sobre os proxies inversos pede que o Owncast não fique exposto à internet, porque escuta em todas as interfaces por predefinição, e o Docker publica uma porta em todos os endereços do servidor quando não lhe é indicado nenhum. A interface web passa então a ser acessível apenas através do proxy inverso.
• A porta 1935 recebe o sinal em RTMP. Continua pública, porque o seu software de transmissão chega a ela diretamente, sem passar pelo proxy.
• A pasta data guarda a base de dados e as suas cópias no servidor, fora do contentor: é ela que copia e que transporta.
• A etiqueta latest acompanha a versão mais recente; 0.3.0 fixa uma versão.

Sem Docker: o instalador oficial

A outra via da documentação é um script que transfere a última versão do Owncast para a sua plataforma, e o ffmpeg se ainda não estiver presente. Instala tudo numa pasta owncast dentro da pasta atual. A documentação desaconselha executá-lo como root e recomenda ler qualquer script remoto antes de o executar:

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

Para que o Owncast arranque com o servidor e reinicie sozinho depois de 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

Palavra-passe de administração e chave de transmissão

A administração encontra-se em /admin. O Owncast arranca com credenciais que todos conhecem, e a documentação pede que as mude no primeiro início de sessão:

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

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

• A palavra-passe de administração muda-se em «Configuration», «Server Setup». Tem de ter de 8 a 192 caracteres, pelo menos uma minúscula, uma maiúscula, um algarismo e um carácter especial entre !@#$%^&*, e nenhum hífen.
• As chaves de transmissão gerem-se no separador «Stream Keys» da mesma página. O Owncast propõe uma chave gerada automaticamente, de 30 caracteres, e pode manter várias, cada uma com um comentário: uma chave dada a um coanfitrião pode ser revogada mais tarde sem tocar nas outras.
• Uma palavra-passe perdida substitui-se no arranque com a opção --adminpassword, que a grava na base de dados.

A palavra-passe de administração e a chave de transmissão começam ambas em abc123, mas são duas definições distintas: mude as duas.

HTTPS: o proxy inverso

O Owncast não trata ele próprio do HTTPS. A documentação coloca à sua frente um proxy inverso, que escuta nas portas 80 e 443, obtém o certificado, cifra o tráfego e transmite-o em claro ao Owncast na porta 8080. Sem HTTPS, os navegadores assinalam a página como não segura, e uma página servida em HTTPS não pode incorporar o seu vídeo nem o seu chat.

• O proxy transmite todos os caminhos, incluindo a ligação WebSocket em /ws, que transporta o chat. Um proxy que a bloqueie corta o chat.
• O RTMP não passa pelo proxy: o seu software de transmissão envia diretamente 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 utilizador banido do chat. A documentação pede que seja o próprio proxy a definir este cabeçalho.

Com o Caddy

A documentação sugere o Caddy se não tiver outra preferência: obtém sozinho um certificado Let's Encrypt e transmite o WebSocket sem nenhuma definição adicional. Eis o seu exemplo de Caddyfile, em que a linha tls indica 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 à secçã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ó é aceite no caminho /live. No OBS:

1. Abra «Definições» e depois «Transmissão», e escolha «Personalizado» como serviço.
2. Introduza o endereço rtmp://live.example.com:1935/live.
3. Introduza a sua chave de transmissão, a do separador «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.

Num VPS Simafri, o endereço IPv6 do servidor pode abrir a porta à sua escolha: o seu software de transmissão chega à porta 1935 por esse endereço, com um nome que tenha o registo AAAA. Numa rede Docker em IPv4, como aqui, o Docker liga a porta do endereço IPv6 do servidor ao contentor. Abra essa porta se o ufw estiver ativo e teste depois a partir do seu computador:

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

Para qualquer outra necessidade, diga-nos o que pretende e analisamos consigo o endereçamento.

As definições do 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 leitura estão garantidas.
• O intervalo entre imagens-chave: uma a cada 2 segundos, nunca deixado em «automático». No OBS, o intervalo é em segundos, portanto 2.
• O débito: envie o que prevê oferecer, não mais. Se o seu servidor trata 720p a 2500 kbps, não lhe envie 1080p a 6000 kbps: cada conversão pedida acrescenta carga ao processador.

As qualidades de vídeo e a latência

As qualidades oferecidas aos espectadores definem-se em «Configuration», «Video». Várias qualidades permitem ao leitor escolher a que a sua ligação consegue sustentar: a documentação recomenda uma segunda qualidade, de 1000 a 2000 kbps, ao lado de uma qualidade alta de 4000 a 6000 kbps, depois de testada a sua primeira configuração.

• O débito: de 400 a 13 000 kbps, em passos de 100.
• A cadência: de 24 a 120 imagens por segundo, 24 por predefinição.
• A resolução: mude a largura ou a altura, não as duas, e o Owncast mantém as proporções.
• A utilização do processador: cinco níveis. Quanto mais alto o nível, melhor a imagem, ou mais pequeno o ficheiro com qualidade igual.

O passthrough transmite o vídeo recebido sem o recodificar: poupa quase todo o processador dessa qualidade e ignora as respetivas definições de débito, de resolução e de cadência. A documentação reserva-o aos utilizadores avançados: os espectadores recebem exatamente o que o seu software envia, que alguns leitores não conseguem reproduzir, e a latência aumenta. Teste a leitura nos dispositivos que lhe interessam antes de contar com ele.

A latência regula-se com a memória intermédia de latência, na mesma página. Cada nível troca um pouco de atraso por estabilidade, e uma alteração aplica-se a partir da transmissão seguinte:

A versão 0.3.0 acrescenta também, do lado do espectador, a opção «Minimize latency» do leitor, que acelera ligeiramente a leitura para se aproximar do direto, e uma definição de reprodução automática, desativada por predefinição.

O armazenamento de objetos para servir mais espectadores

O Owncast pode enviar os seus segmentos de vídeo para um armazenamento compatível com S3, a partir do qual os espectadores os transferem. O servidor continua a servir a lista de reprodução principal, as API e o chat; o vídeo, que representa quase toda a largura de banda, vem do armazenamento. O seu servidor envia então uma única cópia de cada qualidade: no exemplo da documentação, 6,5 Mbps para duas qualidades a 5000 e 1500 kbps, quer tenha zero espectadores ou mil. A carga do processador mantém-se a mesma.

1. Crie um bucket no seu fornecedor de armazenamento de objetos.
2. Torne-o legível publicamente e defina uma política CORS se o fornecedor a exigir: um erro CORS ou Access-Control-Allow-Origin na consola do navegador vem quase sempre daí.
3. Em «Configuration», «Server Setup», separador «S3 Object Storage», ative o armazenamento e introduza o nome do bucket, a chave de acesso, a chave secreta, o endpoint e a região. Todos estes campos são obrigatórios.

Este armazenamento serve o direto, não um arquivo: o Owncast apaga, à medida que avança, os segmentos mais antigos do que a lista de reprodução 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 descreve também uma rede de distribuição de conteúdos (CDN) colocada à frente do Owncast, com um nome de anfitrião de origem distinto e a definição «Websocket host override», que mantém o chat ligado ao servidor de origem.

O chat e a moderação

O chat configura-se em «Configuration», «Chat». Por predefinição, não há nenhum moderador: a documentação sugere que, pelo menos, se nomeie a si próprio, a partir da página «Users» da administração.

• Os moderadores ocultam uma mensagem ou banem um utilizador a partir do próprio chat. Não têm acesso à administração.
• Um banimento desliga o utilizador, retira as suas mensagens e bloqueia o seu endereço IP conhecido. Pode ser levantado mais tarde; eliminar um utilizador, pelo contrário, é definitivo.
• Apenas utilizadores estabelecidos: esta definição bloqueia as mensagens das contas com menos de 15 minutos, exceto as dos moderadores.
• O filtro de linguagem rejeita as mensagens ofensivas, a partir de uma lista de palavras interna.
• A autenticação obrigatória só deixa enviar mensagens os utilizadores autenticados, por uma conta do Fediverso ou pelo IndieAuth, e os moderadores.
• O limitador de débito, ativo por predefinição, permite cerca de uma mensagem a cada dois terços de segundo e bloqueia durante 10 segundos quem inundar o chat.

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

As cópias de segurança

O Owncast faz ele próprio a cópia da sua base de dados uma vez por hora, em data/backup/owncastdb.bak. A opção --backupdir muda essa pasta. Eis o que contém a pasta de dados:

Para um restauro completo, ou para transportar a instância, a documentação pede que copie a pasta data inteira: copiá-la para uma nova instalação leva tudo consigo. Com o Docker, com o serviço parado:

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

Agende esta cópia ao ritmo das suas transmissões e envie-a para fora do servidor. Colocados no seu disco, estes arquivos entram também nas suas cópias de segurança noturnas.

Restaurar a base de dados

Um restauro devolve a base de dados ao momento da cópia: tudo o que mudou desde então perde-se. Copie primeiro a base de dados atual para um lugar seguro e depois:

1. Pare o Owncast.
2. Arranque o Owncast com --restoreDatabase e o caminho do ficheiro de cópia: restaura a base de dados e depois termina.
3. Arranque o Owncast normalmente e verifique depois as suas definiçõ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 mantém-se no lugar:

docker compose pull
docker compose up -d

Com o instalador, a nota da versão 0.3.0 descreve a atualização: pare o serviço, ponha de lado os ficheiros da interface web que tiver personalizado, execute de novo o instalador com a conta que faz correr 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, publicada a 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. A sua nota pede que leia as alterações antes de atualizar, porque afetam a sua instância: acompanhe estas notas a cada versão e copie a pasta data logo antes.

Quem faz o quê num VPS gerido

O autoalojamento exige cuidar do servidor para além da aplicação. Num VPS gerido, as nossas equipas assumem o servidor e acompanham a sua instância de forma proativa; o Owncast continua a ser o seu software, com as suas definições e os seus dados.

Se preferir que as nossas equipas intervenham na própria aplicação, este serviço é faturado à hora ou por pacote, com um orçamento comunicado antes da intervenção.