Ospitare Owncast su un VPS gestito: le vostre dirette video sul vostro server

Che cosa fa Owncast

Owncast è un server di dirette video e di chat open source, self-hosted e a utente singolo: un'istanza porta il canale di una sola persona o organizzazione. Il suo README lo presenta come un modo di gestire le proprie dirette, sul modello delle grandi piattaforme più diffuse, restando proprietari dei propri contenuti, della propria interfaccia, della propria moderazione e del proprio pubblico.

• L'acquisizione: il vostro software di trasmissione, come OBS, invia il flusso in RTMP, il protocollo usato dalle principali piattaforme di streaming.
• La distribuzione: Owncast suddivide il video in segmenti HLS, in una o più qualità, e lo serve sulla sua pagina web. Il flusso si guarda anche in VLC o mpv, su /hls/stream.m3u8.
• La chat: integrata nella pagina, con moderatori, ban e accesso tramite il Fediverso o IndieAuth.
• Il Fediverso: un account Mastodon può seguire il vostro server ed essere avvisato a ogni vostra diretta. La versione 0.3.0 aggiunge i Featured Streams, che mostrano le dirette di altri server Owncast.
• L'estensione: webhook, API e, dalla 0.3.0, plugin, installati dall'amministrazione con i permessi che concedete loro.

Che cosa consente la licenza MIT

Owncast è pubblicato con la licenza MIT. Concede gratuitamente il diritto di usare, copiare, modificare, unire, pubblicare, distribuire, concedere in sublicenza e vendere copie del software. Potete quindi farlo girare per la vostra azienda, la vostra comunità o i vostri clienti, senza alcuna licenza da acquistare.

L'unica condizione è conservare l'avviso di copyright e il testo della licenza in tutte le copie o le parti sostanziali del software. Il testo fornisce il software «così com'è», senza garanzia.

CPU e banda: dimensionare il server

La documentazione lo dice fin dall'inizio: i requisiti dipendono dalla vostra configurazione. Fissa però una regola chiara per stimarli. La CPU transcodifica il video nelle qualità che proponete; la banda lo consegna a ogni spettatore.

• Il numero di spettatori non cambia il carico della CPU. Il video viene codificato una sola volta, poi servito a tutti: zero spettatori o cento, il lavoro di codifica è lo stesso. La chat aggiunge un po' di carico, modesto rispetto alla codifica.
• La banda cresce con ogni spettatore. Ogni spettatore riceve la propria copia del flusso.
• Ogni qualità transcodificata richiede CPU, tanto più quando il bitrate di destinazione è basso, perché comprimere di più richiede più calcolo.

La banda del server

La documentazione fornisce due formule. Il volume di una diretta, in gigabyte: bitrate in kbps × durata in secondi × spettatori ÷ 8.000.000. La velocità in uscita di picco da sostenere, in Mbps: bitrate in kbps × spettatori ÷ 1.000. Con più qualità, calcolate ciascuna e sommatele. Le sue stime per una diretta di due ore:

Su un VPS Simafri, il traffico non ha un contatore mensile: le vostre dirette si dimensionano sul loro bitrate di picco. Man mano che il pubblico cresce, lo storage a oggetti, trattato più avanti, serve il video al posto del server.

La CPU

La documentazione fornisce punti di riferimento misurati, precisando che variano con il codec, il bitrate, la risoluzione e il preset dell'encoder:

• Un core per qualità: come regola empirica, un solo core di CPU riesce spesso a gestire una qualità transcodificata a 30 fotogrammi al secondo.
• La frequenza dei fotogrammi: 60 fotogrammi al secondo richiedono circa il doppio del calcolo di 30, e 24 fotogrammi al secondo circa 0,8 volte.
• L'impostazione predefinita: Owncast parte con una sola qualità, a 1.200 kbps e 24 fotogrammi al secondo, con l'audio trasmesso senza modifiche. La documentazione consiglia di partire da lì, provare, poi aggiungere una qualità quando la CPU ha margine.

La documentazione non indica alcun valore di memoria, e il disco conta poco: i segmenti video vengono scritti e poi eliminati man mano che la diretta procede. Solo la cartella data cresce nel tempo. Su un VPS, è la CPU a fare la codifica: ogni qualità transcodificata si dimensiona in vCPU. Su un VPS gestito, parlateci delle vostre dirette, del loro bitrate, delle loro qualità e del vostro pubblico, e vi raccomandiamo la taglia adatta.

La vostra connessione di trasmissione

Prima di raggiungere il server, il flusso parte dalla vostra connessione. La documentazione chiede una velocità di upload di almeno 1,5 volte il bitrate del flusso: 7,5 Mbps per un flusso a 5.000 kbps. Raccomanda una connessione via cavo anziché il Wi-Fi.

L'installazione con Docker Compose

La documentazione propone l'immagine owncast/owncast su Docker Hub, che include ffmpeg, lo strumento di codifica di cui Owncast ha bisogno. Su un server in cui Docker è installato, create una cartella e collocatevi questo compose.yaml, tratto dalla documentazione:

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

• La porta 8080 pubblicata su 127.0.0.1: è l'unica modifica rispetto all'esempio della documentazione, che pubblica entrambe le porte. La sua pagina sui reverse proxy chiede di non esporre Owncast su Internet, perché per impostazione predefinita ascolta su tutte le interfacce, e Docker pubblica una porta su tutti gli indirizzi del server quando non gliene viene indicato nessuno. L'interfaccia web si raggiunge allora solo tramite il reverse proxy.
• La porta 1935 riceve il flusso in RTMP. Resta pubblica, perché il vostro software di trasmissione la raggiunge direttamente, senza passare dal proxy.
• La cartella data conserva il database e i suoi backup sul server, fuori dal container: è ciò che salvate e spostate.
• Il tag latest segue la versione più recente; 0.3.0 fissa una versione.

Senza Docker: l'installer ufficiale

L'altra strada della documentazione è uno script che scarica l'ultima versione di Owncast per la vostra piattaforma, e ffmpeg se non è già presente. Installa tutto in una cartella owncast sotto quella corrente. La documentazione sconsiglia di lanciarlo come root e raccomanda di leggere qualsiasi script remoto prima di eseguirlo:

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

Perché Owncast parta con il server e si riavvii da solo dopo un arresto anomalo, la documentazione fornisce un servizio systemd, da adattare alla cartella e all'account che avete scelto:

[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

Password di amministrazione e chiave di trasmissione

L'amministrazione si trova su /admin. Owncast parte con credenziali note a tutti, che la documentazione chiede di cambiare al primo accesso:

Per fare questa modifica prima che l'interfaccia sia aperta al pubblico, passate da un tunnel SSH: la porta 8080 del server compare sul vostro computer, su http://localhost:8080/admin. Aggiungete -p e la porta SSH indicata nella vostra area clienti.

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

• La password di amministrazione si cambia in «Configuration», «Server Setup». Richiede da 8 a 192 caratteri, almeno una lettera minuscola, una maiuscola, una cifra e un carattere speciale tra !@#$%^&*, e nessun trattino.
• Le chiavi di trasmissione si gestiscono nella scheda «Stream Keys» della stessa pagina. Owncast propone una chiave di 30 caratteri generata automaticamente, e potete conservarne diverse, ognuna con un commento: una chiave data a un co-conduttore si può poi revocare senza toccare le altre.
• Una password smarrita si sostituisce all'avvio con l'opzione --adminpassword, che la registra nel database.

La password di amministrazione e la chiave di trasmissione valgono entrambe abc123 all'inizio, ma sono due impostazioni distinte: cambiatele entrambe.

HTTPS: il reverse proxy

Owncast non gestisce HTTPS da solo. La documentazione gli pone davanti un reverse proxy, che ascolta sulle porte 80 e 443, ottiene il certificato, cifra il traffico e lo inoltra in chiaro a Owncast sulla porta 8080. Senza HTTPS, i browser segnalano la pagina come non sicura, e una pagina servita in HTTPS non può incorporare il vostro video né la vostra chat.

• Il proxy inoltra tutti i percorsi, compresa la connessione WebSocket su /ws, che trasporta la chat. Un proxy che la blocca interrompe la chat.
• RTMP non passa dal proxy: il vostro software di trasmissione invia direttamente alla porta 1935 di Owncast.
• L'indirizzo reale dei visitatori: Owncast legge l'intestazione X-Forwarded-For per bloccare l'indirizzo IP di un utente bannato dalla chat. La documentazione chiede che sia il proxy stesso a impostare questa intestazione.

Con Caddy

La documentazione suggerisce Caddy se non avete altre preferenze: ottiene da solo un certificato Let's Encrypt e inoltra WebSocket senza impostazioni aggiuntive. Ecco il suo esempio di Caddyfile, in cui la riga tls indica l'indirizzo e-mail dell'account Let's Encrypt:

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

Con Nginx

Con Nginx, la documentazione insiste su WebSocket: dimenticarlo è ciò che disattiva la chat. Aggiungete questo blocco map alla sezione http di /etc/nginx/nginx.conf:

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

Questo blocco del sito segue quello della documentazione, sulla porta 80 per lasciare a Certbot l'attivazione di 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

Trasmettere in RTMP da OBS

Owncast accetta qualsiasi software che trasmetta in RTMP verso un server remoto. La chiave è accettata solo sul percorso /live. In OBS:

1. Aprite «Impostazioni», poi «Dirette», e scegliete «Personalizzato» come servizio.
2. Inserite l'indirizzo rtmp://live.example.com:1935/live.
3. Inserite la vostra chiave di trasmissione, quella della scheda «Stream Keys» di Owncast.
4. Avviate la diretta.

Un software senza un campo per la chiave accetta l'indirizzo completo, rtmp://live.example.com:1935/live/your-key.

Su un VPS Simafri, l'indirizzo IPv6 del server può aprire qualsiasi porta scegliate: il vostro software di trasmissione raggiunge la porta 1935 tramite quell'indirizzo, con un nome che porta il record AAAA. Su una rete Docker IPv4, come qui, Docker inoltra al container la porta dell'indirizzo IPv6 del server. Aprite quella porta se ufw è attivo, poi provate dal vostro computer:

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

Per qualsiasi altra esigenza, diteci che cosa avete in mente e studiamo con voi l'indirizzamento.

Le impostazioni del vostro software di trasmissione

• I codec: H.264 per il video e AAC per l'audio, gli unici per i quali la transcodifica e la compatibilità di riproduzione sono garantite.
• L'intervallo dei fotogrammi chiave: uno ogni 2 secondi, mai lasciato su «auto». In OBS l'intervallo è in secondi, quindi 2.
• Il bitrate: inviate ciò che intendete proporre, non di più. Se il vostro server gestisce il 720p a 2.500 kbps, non inviategli il 1080p a 6.000 kbps: ogni conversione richiesta aggiunge carico alla CPU.

Qualità video e latenza

Le qualità proposte agli spettatori si impostano in «Configuration», «Video». Più qualità permettono al lettore di scegliere quella che la sua connessione può sostenere: la documentazione raccomanda una seconda qualità, da 1.000 a 2.000 kbps, accanto a una qualità alta da 4.000 a 6.000 kbps, una volta provata la vostra prima configurazione.

• Il bitrate: da 400 a 13.000 kbps, a passi di 100.
• La frequenza dei fotogrammi: da 24 a 120 fotogrammi al secondo, 24 per impostazione predefinita.
• La risoluzione: cambiate la larghezza o l'altezza, non entrambe, e Owncast mantiene le proporzioni.
• L'uso della CPU: cinque livelli. Più alto è il livello, migliore è l'immagine, oppure più leggero è il file a parità di qualità.

Il passthrough trasmette il video in ingresso senza ricodificarlo: risparmia quasi tutta la CPU di quella qualità, e ne ignora le impostazioni di bitrate, risoluzione e frequenza dei fotogrammi. La documentazione lo riserva agli utenti esperti: gli spettatori ricevono esattamente ciò che invia il vostro software, che alcuni lettori non riescono a riprodurre, e la latenza aumenta. Provate la riproduzione sui dispositivi che contano per voi prima di farvi affidamento.

La latenza si regola con il buffer di latenza, nella stessa pagina. Ogni livello scambia un po' di ritardo con la stabilità, e una modifica si applica dalla diretta successiva:

La versione 0.3.0 aggiunge anche, lato spettatore, l'opzione «Minimize latency» del lettore, che accelera leggermente la riproduzione per avvicinarsi alla diretta, e un'impostazione di riproduzione automatica, disattivata per impostazione predefinita.

Lo storage a oggetti per servire più spettatori

Owncast può inviare i suoi segmenti video a uno storage compatibile S3, da cui gli spettatori li scaricano. Il server continua a servire la playlist principale, le API e la chat; il video, che rappresenta quasi tutta la banda, arriva dallo storage. Il vostro server invia allora una sola copia di ogni qualità: nell'esempio della documentazione, 6,5 Mbps per due qualità a 5.000 e 1.500 kbps, che abbiate zero spettatori o mille. Il carico della CPU resta lo stesso.

1. Create un bucket presso il vostro fornitore di storage a oggetti.
2. Rendetelo leggibile pubblicamente, e impostate una politica CORS se il fornitore la richiede: un errore CORS o Access-Control-Allow-Origin nella console del browser deriva quasi sempre da lì.
3. In «Configuration», «Server Setup», scheda «S3 Object Storage», attivate lo storage e inserite il nome del bucket, la chiave di accesso, la chiave segreta, l'endpoint e la regione. Tutti questi campi sono obbligatori.

Questo storage serve la diretta, non un archivio: Owncast elimina man mano i segmenti più vecchi della playlist più un margine di circa 20 segmenti. Il bucket contiene solo gli ultimi minuti della diretta.

Per spettatori sparsi in tutto il mondo, la documentazione descrive anche una rete di distribuzione dei contenuti (CDN) posta davanti a Owncast, con un nome host di origine separato e l'impostazione «Websocket host override», che mantiene la chat collegata al server di origine.

La chat e la moderazione

La chat si imposta in «Configuration», «Chat». Per impostazione predefinita non ci sono moderatori: la documentazione suggerisce almeno di nominare voi stessi, dalla pagina «Users» dell'amministrazione.

• I moderatori nascondono un messaggio o bannano un utente dalla chat stessa. Non hanno accesso all'amministrazione.
• Un ban disconnette l'utente, elimina i suoi messaggi e blocca il suo indirizzo IP noto. Si può revocare in seguito; eliminare un utente, invece, è definitivo.
• Solo utenti consolidati: questa impostazione blocca i messaggi degli account creati da meno di 15 minuti, moderatori esclusi.
• Il filtro del linguaggio respinge i messaggi offensivi, con un elenco di parole interno.
• L'autenticazione obbligatoria lascia inviare messaggi solo agli utenti autenticati, tramite un account del Fediverso o IndieAuth, e ai moderatori.
• Il limitatore di frequenza, attivo per impostazione predefinita, consente circa un messaggio ogni due terzi di secondo e blocca per 10 secondi chi inonda la chat.

La documentazione ricorda che il blocco per IP si può aggirare, con una VPN per esempio: riduce gli abusi, e la moderazione resta il lavoro proprio di ogni canale. Da qui l'utilità di moderatori designati per le vostre dirette più seguite.

I backup

Owncast salva da solo il proprio database una volta all'ora, in data/backup/owncastdb.bak. L'opzione --backupdir cambia questa cartella. Ecco che cosa contiene la cartella dei dati:

Per un ripristino completo, o per spostare l'istanza, la documentazione chiede di salvare l'intera cartella data: copiarla in una nuova installazione porta con sé tutto. Con Docker, a servizio fermo:

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

Pianificate questa copia in base alle vostre dirette, e inviatela fuori dal server. Collocati sul suo disco, questi archivi rientrano anche nei suoi backup notturni.

Ripristinare il database

Un ripristino riporta il database al momento del backup: tutto ciò che è cambiato da allora va perso. Copiate prima il database attuale in un luogo sicuro, poi:

1. Fermate Owncast.
2. Avviate Owncast con --restoreDatabase e il percorso del file di backup: ripristina il database, poi si chiude.
3. Avviate Owncast come di consueto, poi verificate le vostre impostazioni nell'amministrazione.

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

Gli aggiornamenti

Con Docker, la documentazione fornisce due comandi, da lanciare dalla cartella del compose.yaml. La cartella dei dati resta al suo posto:

docker compose pull
docker compose up -d

Con l'installer, le note di rilascio della 0.3.0 descrivono l'aggiornamento: fermate il servizio, mettete da parte i file dell'interfaccia web che avete personalizzato, rilanciate l'installer con l'account che fa girare Owncast, poi riavviate. Lo script stesso conserva un archivio della cartella data in owncast-install-backups prima di sostituire la versione.

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

La versione 0.3.0, uscita il 3 settembre 2026, porta i plugin, i Featured Streams, la riproduzione automatica e la scelta dell'interfaccia su cui ascolta RTMP. Le sue note chiedono di leggere le modifiche prima di aggiornare, perché riguardano la vostra istanza: seguite queste note a ogni versione, e copiate la cartella data subito prima.

Chi fa che cosa su un VPS gestito

Il self-hosting richiede di occuparsi del server oltre che dell'applicazione. Su un VPS gestito, i nostri team prendono in carico il server e seguono la vostra istanza in modo proattivo; Owncast resta il vostro software, con le sue impostazioni e i suoi dati.

Se preferite che i nostri team intervengano nell'applicazione stessa, questa prestazione si fattura a ore o a forfait, con un preventivo comunicato prima dell'intervento.