Owncast hosten op een Managed VPS: uw livestreams op uw eigen server

Wat Owncast doet

Owncast is een opensource, zelf gehoste server voor live video en chat voor één gebruiker: één instantie draagt het kanaal van één persoon of organisatie. De README stelt het voor als een manier om uw eigen livestreams te verzorgen, in de stijl van de grote bekende platformen, terwijl u eigenaar blijft van uw inhoud, interface, moderatie en publiek.

• De ontvangst: uw uitzendsoftware, zoals OBS, stuurt de stream via RTMP, het protocol van de grote streamingplatformen.
• De levering: Owncast knipt de video in HLS-segmenten, in een of meer kwaliteiten, en biedt hem aan op zijn webpagina. De stream speelt ook af in VLC of mpv, op /hls/stream.m3u8.
• De chat: ingebouwd in de pagina, met moderators, bans en aanmelden via de Fediverse of IndieAuth.
• De Fediverse: een Mastodon-account kan uw server volgen en een melding krijgen telkens als u live gaat. Versie 0.3.0 voegt Featured Streams toe, die de livestreams van andere Owncast-servers tonen.
• De uitbreiding: webhooks, API's en, sinds 0.3.0, plug-ins, geïnstalleerd vanuit het beheer met de rechten die u ze toekent.

Wat de MIT-licentie toestaat

Owncast wordt gepubliceerd onder de MIT-licentie. Die kent kosteloos het recht toe om kopieën van de software te gebruiken, te kopiëren, te wijzigen, samen te voegen, te publiceren, te verspreiden, in sublicentie te geven en te verkopen. U kunt het dus draaien voor uw bedrijf, uw community of uw klanten, zonder een licentie te kopen.

De enige voorwaarde is dat u de copyrightvermelding en de tekst van de licentie behoudt in alle kopieën of wezenlijke delen van de software. De tekst levert de software “zoals hij is”, zonder garantie.

CPU en bandbreedte: de server dimensioneren

De documentatie zegt het meteen: de behoeften hangen af van uw configuratie. Ze geeft wel een duidelijke regel om ze te schatten. De CPU transcodeert de video naar de kwaliteiten die u aanbiedt; de bandbreedte levert hem aan elke kijker.

• Het aantal kijkers verandert de CPU-belasting niet. De video wordt één keer gecodeerd en daarna aan iedereen geleverd: nul kijkers of honderd, het coderingswerk blijft hetzelfde. De chat voegt een beetje belasting toe, klein naast de codering.
• De bandbreedte groeit met elke kijker. Elke kijker ontvangt zijn eigen kopie van de stream.
• Elke getranscodeerde kwaliteit vraagt CPU, des te meer wanneer de beoogde bitrate laag is, omdat sterker comprimeren meer rekenwerk vraagt.

De bandbreedte van de server

De documentatie geeft twee formules. Het volume van een stream, in gigabytes: bitrate in kbps × duur in seconden × kijkers ÷ 8.000.000. De piekdoorvoer naar buiten die u moet aanhouden, in Mbps: bitrate in kbps × kijkers ÷ 1.000. Met meerdere kwaliteiten berekent u elke kwaliteit apart en telt u ze op. Haar schattingen voor een stream van twee uur:

Op een Simafri-VPS heeft het verkeer geen maandelijkse teller: uw streams worden gedimensioneerd op hun piekbitrate. Groeit uw publiek, dan levert objectopslag, verderop behandeld, de video in plaats van de server.

De CPU

De documentatie geeft gemeten referentiepunten, en merkt op dat ze variëren met de codec, de bitrate, de resolutie en de preset van de encoder:

• Eén kern per kwaliteit: als ruwe vuistregel kan één CPU-kern vaak één getranscodeerde kwaliteit aan, bij 30 beelden per seconde.
• De framerate: 60 beelden per seconde vraagt ongeveer twee keer het rekenwerk van 30, en 24 beelden per seconde ongeveer 0,8 keer.
• De standaardinstelling: Owncast start met één kwaliteit, op 1.200 kbps en 24 beelden per seconde, met de audio ongewijzigd doorgegeven. De documentatie raadt aan daar te beginnen, te testen en pas een kwaliteit toe te voegen als de CPU ruimte over heeft.

De documentatie noemt geen cijfer voor het geheugen, en de schijf telt weinig: de videosegmenten worden geschreven en daarna verwijderd naarmate de stream vordert. Alleen de map data groeit met de tijd. Op een VPS doet de CPU de codering: elke getranscodeerde kwaliteit wordt in vCPU's gedimensioneerd. Vertel ons op een managed VPS over uw streams, hun bitrate, hun kwaliteiten en uw publiek, dan raden wij u de passende grootte aan.

Uw verbinding om uit te zenden

Voordat de stream de server bereikt, vertrekt hij vanaf uw eigen verbinding. De documentatie vraagt een uploadsnelheid van minstens 1,5 keer de bitrate van de stream: 7,5 Mbps voor een stream van 5.000 kbps. Ze raadt een bekabelde verbinding aan boven wifi.

De installatie met Docker Compose

De documentatie biedt de image owncast/owncast op Docker Hub aan, die ffmpeg bevat, het coderingsprogramma dat Owncast nodig heeft. Maak op een server waar Docker is geïnstalleerd een map aan en plaats daarin dit compose.yaml, overgenomen uit de documentatie:

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

• Poort 8080 gepubliceerd op 127.0.0.1: dit is de enige wijziging ten opzichte van het voorbeeld uit de documentatie, dat beide poorten publiceert. De pagina over reverse proxy's vraagt Owncast niet rechtstreeks aan het internet bloot te stellen, omdat het standaard op elke interface luistert, en Docker publiceert een poort op alle adressen van de server wanneer u er geen opgeeft. De webinterface is dan alleen via de reverse proxy bereikbaar.
• Poort 1935 ontvangt de stream via RTMP. Ze blijft openbaar, omdat uw uitzendsoftware haar rechtstreeks bereikt, zonder langs de proxy te gaan.
• De map data bewaart de database en haar back-ups op de server, buiten de container: dit is wat u back-upt en verhuist.
• De tag latest volgt de recentste versie; 0.3.0 legt een versie vast.

Zonder Docker: het officiële installatieprogramma

De andere weg uit de documentatie is een script dat de laatste versie van Owncast voor uw platform downloadt, en ffmpeg als dat er nog niet is. Het installeert alles in een map owncast onder de huidige map. De documentatie raadt af het als root uit te voeren en beveelt aan elk script op afstand te lezen voordat u het uitvoert:

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

Wilt u dat Owncast met de server opstart en na een crash vanzelf herstart, dan levert de documentatie een systemd-dienst, aan te passen aan de map en het account die u koos:

[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

Beheerderswachtwoord en streamsleutel

Het beheer staat op /admin. Owncast start met toegangsgegevens die iedereen kent, en de documentatie vraagt ze bij uw eerste aanmelding te wijzigen:

Om deze wijziging te doen voordat de interface voor het publiek openstaat, gaat u via een SSH-tunnel: poort 8080 van de server verschijnt dan op uw computer, op http://localhost:8080/admin. Voeg -p en de SSH-poort toe die in uw klantenzone staat.

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

• Het beheerderswachtwoord wijzigt u in “Configuration”, “Server Setup”. Het telt 8 tot 192 tekens, minstens één kleine letter, één hoofdletter, één cijfer en één speciaal teken uit !@#$%^&*, en nergens een koppelteken.
• De streamsleutels beheert u in het tabblad “Stream Keys” van dezelfde pagina. Owncast stelt een automatisch gegenereerde sleutel van 30 tekens voor, en u kunt er meerdere bewaren, elk met een opmerking: een sleutel die u aan een co-host geeft, trekt u later in zonder de andere aan te raken.
• Een vergeten wachtwoord vervangt u bij het opstarten met de vlag --adminpassword, die het in de database opslaat.

Het beheerderswachtwoord en de streamsleutel starten allebei als abc123, maar het zijn twee aparte instellingen: wijzig ze allebei.

HTTPS: de reverse proxy

Owncast regelt HTTPS niet zelf. De documentatie zet er een reverse proxy voor, die op de poorten 80 en 443 luistert, het certificaat verkrijgt, het verkeer versleutelt en het onversleuteld doorgeeft aan Owncast op poort 8080. Zonder HTTPS markeren browsers de pagina als niet beveiligd, en een pagina die via HTTPS wordt aangeboden, kan uw video of uw chat niet insluiten.

• De proxy geeft elk pad door, ook de WebSocket-verbinding op /ws, die de chat draagt. Een proxy die haar blokkeert, schakelt de chat uit.
• RTMP gaat niet via de proxy: uw uitzendsoftware stuurt rechtstreeks naar poort 1935 van Owncast.
• Het echte adres van de bezoekers: Owncast leest de header X-Forwarded-For om het IP-adres te blokkeren van een gebruiker die uit de chat is verbannen. De documentatie vraagt dat de proxy deze header zelf zet.

Met Caddy

De documentatie stelt Caddy voor als u geen andere voorkeur hebt: het verkrijgt zelf een Let's Encrypt-certificaat en geeft WebSocket door zonder extra instelling. Hier is haar Caddyfile-voorbeeld, waarin de regel tls het e-mailadres van het Let's Encrypt-account opgeeft:

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

Met Nginx

Bij Nginx legt de documentatie de nadruk op WebSocket: wie het vergeet, schakelt de chat uit. Voeg dit blok map toe aan de sectie http van /etc/nginx/nginx.conf:

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

Dit siteblok volgt dat uit de documentatie, op poort 80 zodat Certbot HTTPS kan plaatsen:

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

Uitzenden via RTMP vanuit OBS

Owncast aanvaardt elke software die via RTMP naar een externe server uitzendt. De sleutel wordt alleen aanvaard op het pad /live. In OBS:

1. Open “Instellingen”, daarna “Stream”, en kies “Aangepast” als dienst.
2. Voer het adres rtmp://live.example.com:1935/live in.
3. Voer uw streamsleutel in, die uit het tabblad “Stream Keys” van Owncast.
4. Start de uitzending.

Software zonder veld voor de sleutel aanvaardt het volledige adres, rtmp://live.example.com:1935/live/your-key.

Op een Simafri-VPS kan het IPv6-adres van de server elke poort openen die u kiest: uw uitzendsoftware bereikt poort 1935 via dat adres, onder een naam die het record AAAA draagt. Op een IPv4-netwerk van Docker, zoals hier, koppelt Docker de poort op het IPv6-adres van de server aan de container. Open die poort als ufw actief is, en test daarna vanaf uw computer:

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

Voor elke andere behoefte vertelt u ons wat u voor ogen hebt, en bekijken wij de adressering samen met u.

De instellingen van uw uitzendsoftware

• De codecs: H.264 voor de video en AAC voor de audio, de enige waarvoor transcodering en compatibiliteit bij het afspelen gegarandeerd zijn.
• Het interval van de keyframes: één om de 2 seconden, nooit op “auto”. In OBS telt het interval in seconden, dus 2.
• De bitrate: stuur wat u wilt aanbieden, niet meer. Kan uw server 720p op 2.500 kbps aan, stuur hem dan geen 1080p op 6.000 kbps: elke conversie die u vraagt, voegt CPU-belasting toe.

Videokwaliteiten en latentie

De kwaliteiten die kijkers krijgen, stelt u in bij “Configuration”, “Video”. Met meerdere kwaliteiten kiest de speler de kwaliteit die zijn verbinding aankan: de documentatie raadt een tweede kwaliteit aan, van 1.000 tot 2.000 kbps, naast een hoge kwaliteit van 4.000 tot 6.000 kbps, zodra uw eerste configuratie getest is.

• De bitrate: van 400 tot 13.000 kbps, in stappen van 100.
• De framerate: van 24 tot 120 beelden per seconde, standaard 24.
• De resolutie: wijzig de breedte of de hoogte, niet allebei, en Owncast behoudt de beeldverhouding.
• Het CPU-gebruik: vijf niveaus. Hoe hoger het niveau, hoe beter het beeld, of hoe kleiner het bestand bij gelijke kwaliteit.

Passthrough geeft de binnenkomende video door zonder hem opnieuw te coderen: het bespaart vrijwel alle CPU van die kwaliteit, en negeert haar instellingen voor bitrate, resolutie en framerate. De documentatie behoudt het voor gevorderde gebruikers: kijkers ontvangen precies wat uw software stuurt, wat sommige spelers niet kunnen afspelen, en de latentie neemt toe. Test het afspelen op de toestellen die voor u tellen voordat u erop rekent.

De latentie stelt u in met de latentiebuffer, op dezelfde pagina. Elk niveau ruilt een beetje vertraging in voor stabiliteit, en een wijziging geldt vanaf de volgende stream:

Versie 0.3.0 voegt aan de kant van de kijker ook de optie “Minimize latency” van de speler toe, die het afspelen iets versnelt om dichter bij live te komen, en een instelling voor automatisch afspelen, standaard uitgeschakeld.

Objectopslag om meer kijkers te bedienen

Owncast kan zijn videosegmenten naar S3-compatibele opslag sturen, waar de kijkers ze downloaden. De server levert nog altijd de hoofdplaylist, de API's en de chat; de video, die vrijwel alle bandbreedte uitmaakt, komt uit de opslag. Uw server stuurt dan nog maar één kopie van elke kwaliteit: in het voorbeeld uit de documentatie 6,5 Mbps voor twee kwaliteiten van 5.000 en 1.500 kbps, of u nu nul kijkers hebt of duizend. De CPU-belasting blijft dezelfde.

1. Maak een bucket aan bij uw aanbieder van objectopslag.
2. Maak hem openbaar leesbaar, en stel een CORS-beleid in als de aanbieder dat vraagt: een fout CORS of Access-Control-Allow-Origin in de console van de browser komt bijna altijd daarvandaan.
3. Schakel in “Configuration”, “Server Setup”, tabblad “S3 Object Storage”, de opslag in en voer de naam van de bucket, de toegangssleutel, de geheime sleutel, het endpoint en de regio in. Al deze velden zijn verplicht.

Deze opslag levert de livestream, geen archief: Owncast verwijdert gaandeweg de segmenten die ouder zijn dan de playlist plus een buffer van ongeveer 20 segmenten. De bucket bevat alleen de laatste minuten van de stream.

Voor kijkers verspreid over de wereld beschrijft de documentatie ook een content delivery network (CDN) dat voor Owncast wordt geplaatst, met een aparte hostnaam voor de oorsprong en de instelling “Websocket host override”, die de chat verbonden houdt met de oorspronkelijke server.

De chat en de moderatie

De chat stelt u in bij “Configuration”, “Chat”. Standaard zijn er geen moderators: de documentatie stelt voor uzelf er op zijn minst een te maken, vanaf de pagina “Users” van het beheer.

• De moderators verbergen een bericht of verbannen een gebruiker vanuit de chat zelf. Ze hebben geen toegang tot het beheer.
• Een ban verbreekt de verbinding van de gebruiker, verwijdert zijn berichten en blokkeert zijn bekende IP-adres. Hij kan later worden opgeheven; een gebruiker verwijderen is daarentegen definitief.
• Alleen gevestigde gebruikers: deze instelling blokkeert de berichten van accounts die jonger zijn dan 15 minuten, moderators uitgezonderd.
• Het taalfilter weigert beledigende berichten, op basis van een interne woordenlijst.
• Verplichte authenticatie laat alleen geauthenticeerde gebruikers, via een Fediverse-account of IndieAuth, en moderators berichten sturen.
• De snelheidsbegrenzer, standaard actief, staat ongeveer één bericht per twee derde seconde toe en blokkeert wie de chat overspoelt gedurende 10 seconden.

De documentatie wijst erop dat de blokkering op IP-adres te omzeilen is, met een VPN bijvoorbeeld: ze beperkt misbruik, en de moderatie blijft het eigen werk van elk kanaal. Vandaar het nut van aangewezen moderators voor uw meest bekeken streams.

De back-ups

Owncast maakt zelf elk uur een back-up van zijn database, naar data/backup/owncastdb.bak. De vlag --backupdir wijzigt die map. Dit bevat de gegevensmap:

Voor een volledig herstel, of om de instantie te verhuizen, vraagt de documentatie de hele map data te back-uppen: wie haar naar een nieuwe installatie kopieert, neemt alles mee. Met Docker, met de dienst gestopt:

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

Plan deze kopie in op het ritme van uw streams, en stuur haar buiten de server. Staan deze archieven op de schijf van de server, dan vallen ze ook onder de nachtelijke back-ups.

De database terugzetten

Terugzetten brengt de database terug naar het moment van de back-up: alles wat sindsdien is gewijzigd, gaat verloren. Kopieer eerst de huidige database naar een veilige plek, en daarna:

1. Stop Owncast.
2. Start Owncast met --restoreDatabase en het pad van het back-upbestand: het zet de database terug en stopt daarna.
3. Start Owncast zoals gewoonlijk, en controleer daarna uw instellingen in het beheer.

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

De updates

Met Docker geeft de documentatie twee opdrachten, uit te voeren vanuit de map van compose.yaml. De gegevensmap blijft ongemoeid:

docker compose pull
docker compose up -d

Met het installatieprogramma beschrijven de release-opmerkingen van 0.3.0 de update: stop de dienst, zet de bestanden van de webinterface die u hebt aangepast opzij, voer het installatieprogramma opnieuw uit met het account dat Owncast draait, en start daarna opnieuw. Het script zelf bewaart een archief van de map data in owncast-install-backups voordat het de versie vervangt.

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

Versie 0.3.0, uitgebracht op 3 september 2026, brengt de plug-ins, Featured Streams, het automatisch afspelen en de keuze van de interface waarop RTMP luistert. De opmerkingen ervan vragen de wijzigingen te lezen vóór de update, omdat ze uw instantie raken: volg deze opmerkingen bij elke versie, en kopieer de map data vlak ervoor.

Wie doet wat op een managed VPS

Self-hosting vraagt dat u naast de applicatie ook de server beheert. Op een managed VPS neemt ons team de server voor zijn rekening en houdt het uw instantie proactief in de gaten; Owncast blijft uw software, met zijn instellingen en gegevens.

Wilt u liever dat ons team in de applicatie zelf ingrijpt, dan wordt die dienstverlening per uur of tegen een vast bedrag gefactureerd, met een offerte voordat het werk begint.