Hoste Owncast på en Managed VPS: dine livestreams på din egen server

Hvad Owncast gør

Owncast er en selvhostet server med åben kildekode til livestreaming af video og chat for én bruger: én instans bærer kanalen for én person eller én organisation. README'en præsenterer den som en måde at drive dine egne livestreams på, i stil med de store mainstreamplatforme, mens du bevarer ejerskabet over dit indhold, din brugerflade, din moderation og dit publikum.

• Modtagelsen: dit streamingprogram, som OBS, sender streamet over RTMP, den protokol, de store streamingplatforme bruger.
• Leveringen: Owncast deler videoen op i HLS-segmenter i én eller flere kvaliteter og serverer den på sin webside. Streamet kan også afspilles i VLC eller mpv på /hls/stream.m3u8.
• Chatten: indbygget på siden med moderatorer, udelukkelser og login via Fediverse eller IndieAuth.
• Fediverse: en Mastodon-konto kan følge din server og få besked, hver gang du går live. Version 0.3.0 tilføjer Featured Streams, som viser andre Owncast-serveres livestreams.
• Udvidelserne: webhooks, API'er og, siden 0.3.0, plugins, som installeres fra administrationen med de rettigheder, du giver dem.

Hvad MIT-licensen tillader

Owncast udgives under MIT-licensen. Den giver gratis ret til at bruge, kopiere, ændre, sammenflette, udgive, distribuere, underlicensere og sælge kopier af softwaren. Du kan altså køre den for din virksomhed, dit fællesskab eller dine kunder uden at skulle købe en licens.

Den eneste betingelse er at beholde copyrightmeddelelsen og licensteksten i alle kopier eller væsentlige dele af softwaren. Teksten leverer softwaren «som den er», uden garanti.

CPU og båndbredde: dimensionering af serveren

Dokumentationen siger det fra starten: kravene afhænger af din konfiguration. Den opstiller dog en klar regel til at vurdere dem. CPU'en transcoder videoen til de kvaliteter, du tilbyder; båndbredden leverer den til hver seer.

• Antallet af seere ændrer ikke CPU-belastningen. Videoen kodes én gang og serveres derefter til alle: nul seere eller hundrede, kodningsarbejdet er det samme. Chatten tilføjer en smule belastning, som er lille ved siden af kodningen.
• Båndbredden vokser med hver seer. Hver seer modtager sin egen kopi af streamet.
• Hver transcodet kvalitet kræver CPU, så meget desto mere, jo lavere målbitraten er, da en kraftigere komprimering kræver flere beregninger.

Serverens båndbredde

Dokumentationen giver to formler. Mængden for et stream i gigabyte: bitrate i kbps × varighed i sekunder × seere ÷ 8.000.000. Den maksimale udgående hastighed, der skal kunne holdes, i Mbps: bitrate i kbps × seere ÷ 1.000. Med flere kvaliteter beregner du hver af dem og lægger dem sammen. Dens skøn for et stream på to timer:

På en Simafri VPS har trafikken ingen månedlig måler: dine streams dimensioneres efter deres maksimale bitrate. Når dit publikum vokser, serverer objektlageret, som beskrives nedenfor, videoen i stedet for serveren.

CPU'en

Dokumentationen giver målte pejlemærker og bemærker, at de varierer med codec, bitrate, opløsning og encoderens forudindstilling:

• Én kerne pr. kvalitet: som en grov tommelfingerregel kan én CPU-kerne ofte klare én transcodet kvalitet ved 30 billeder i sekundet.
• Billedfrekvensen: 60 billeder i sekundet kræver omkring dobbelt så mange beregninger som 30, og 24 billeder i sekundet omkring 0,8 gange så mange.
• Standardindstillingen: Owncast starter med én enkelt kvalitet på 1.200 kbps og 24 billeder i sekundet, med lyden videresendt uændret. Dokumentationen råder til at starte der, teste og derefter tilføje en kvalitet, når CPU'en har luft.

Dokumentationen opgiver intet tal for hukommelsen, og disken betyder ikke meget: videosegmenterne skrives og fjernes igen, efterhånden som streamet skrider frem. Kun mappen data vokser over tid. På en VPS er det CPU'en, der står for kodningen: hver transcodet kvalitet dimensioneres i vCPU'er. På en Managed VPS fortæller du os om dine streams, deres bitrate, deres kvaliteter og dit publikum, og vi anbefaler den størrelse, der passer.

Din forbindelse til udsendelsen

Før streamet når serveren, forlader det din egen forbindelse. Dokumentationen kræver en uploadhastighed på mindst 1,5 gange streamets bitrate: 7,5 Mbps for et stream på 5.000 kbps. Den anbefaler en kablet forbindelse frem for wi-fi.

Installation med Docker Compose

Dokumentationen tilbyder imaget owncast/owncast på Docker Hub, som indeholder ffmpeg, det kodningsværktøj, Owncast har brug for. På en server, hvor Docker er installeret, opretter du en mappe og lægger denne compose.yaml i den, hentet fra dokumentationen:

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

• Port 8080 publiceret på 127.0.0.1: det er den eneste ændring i forhold til dokumentationens eksempel, som publicerer begge porte. Dens side om reverse proxy beder dig om at holde Owncast væk fra internettet, da den som standard lytter på alle grænseflader, og Docker publicerer en port på alle serverens adresser, når der ikke angives nogen. Webgrænsefladen nås derefter kun via reverse proxyen.
• Port 1935 modtager streamet over RTMP. Den forbliver offentlig, fordi dit streamingprogram når den direkte uden at gå gennem proxyen.
• Mappen data opbevarer databasen og dens backups på serveren, uden for containeren: det er den, du tager backup af og flytter.
• Tagget latest følger den seneste version; 0.3.0 fastlåser en version.

Uden Docker: det officielle installationsprogram

Dokumentationens anden vej er et script, der henter den seneste Owncast-version til din platform og ffmpeg, hvis det ikke allerede findes. Det installerer alt i en mappe owncast under den aktuelle mappe. Dokumentationen fraråder at køre det som root og anbefaler at læse ethvert eksternt script, før man kører det:

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

For at Owncast starter sammen med serveren og genstarter af sig selv efter et nedbrud, leverer dokumentationen en systemd-tjeneste, som du tilpasser til den mappe og den konto, du har valgt:

[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

Administratoradgangskode og streamnøgle

Administrationen ligger på /admin. Owncast starter med adgangsoplysninger, som alle kender, og som dokumentationen beder dig om at ændre ved dit første login:

For at foretage denne ændring, før brugerfladen er åben for offentligheden, går du gennem en SSH-tunnel: serverens port 8080 dukker op på din computer på http://localhost:8080/admin. Tilføj -p og den SSH-port, der vises i dit kundeområde.

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

• Administratoradgangskoden ændres under «Configuration», «Server Setup». Den skal have 8 til 192 tegn, mindst ét lille bogstav, ét stort bogstav, ét ciffer og ét specialtegn blandt !@#$%^&* og ingen bindestreg nogen steder.
• Streamnøglerne administreres under fanen «Stream Keys» på samme side. Owncast foreslår en automatisk genereret nøgle på 30 tegn, og du kan beholde flere, hver med en kommentar: en nøgle, der er givet til en medvært, kan senere tilbagekaldes uden at røre de andre.
• En glemt adgangskode erstattes ved opstart med flaget --adminpassword, som gemmer den i databasen.

Administratoradgangskoden og streamnøglen starter begge som abc123, men de er to separate indstillinger: skift dem begge.

HTTPS: reverse proxyen

Owncast håndterer ikke selv HTTPS. Dokumentationen placerer en reverse proxy foran den, som lytter på port 80 og 443, henter certifikatet, krypterer trafikken og videresender den i klartekst til Owncast på port 8080. Uden HTTPS markerer browserne siden som usikker, og en side, der serveres over HTTPS, kan ikke indlejre din video eller din chat.

• Proxyen videresender alle stier, også WebSocket-forbindelsen på /ws, som bærer chatten. En proxy, der blokerer den, afbryder chatten.
• RTMP går ikke gennem proxyen: dit streamingprogram sender direkte til Owncasts port 1935.
• De besøgendes rigtige adresse: Owncast læser headeren X-Forwarded-For for at blokere IP-adressen på en bruger, der er udelukket fra chatten. Dokumentationen beder om, at proxyen selv sætter denne header.

Med Caddy

Dokumentationen foreslår Caddy, hvis du ikke har nogen anden præference: den henter selv et certifikat fra Let's Encrypt og videresender WebSocket uden ekstra indstillinger. Her er dens eksempel på en Caddyfile, hvor linjen tls angiver e-mailadressen til Let's Encrypt-kontoen:

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

Med Nginx

Med Nginx lægger dokumentationen vægt på WebSocket: at glemme den er det, der slår chatten fra. Tilføj denne blok map til afsnittet http i /etc/nginx/nginx.conf:

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

Denne website-blok følger dokumentationens, på port 80, så Certbot kan sætte HTTPS op:

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

Udsendelse over RTMP fra OBS

Owncast accepterer ethvert program, der sender over RTMP til en ekstern server. Nøglen accepteres kun på stien /live. I OBS:

1. Åbn «Settings» og derefter «Stream», og vælg «Custom» som tjeneste.
2. Indtast adressen rtmp://live.example.com:1935/live.
3. Indtast din streamnøgle, den fra fanen «Stream Keys» i Owncast.
4. Start udsendelsen.

Et program uden et felt til nøglen accepterer den fulde adresse, rtmp://live.example.com:1935/live/your-key.

På en Simafri VPS kan serverens IPv6-adresse åbne den port, du vælger: dit streamingprogram når port 1935 via denne adresse, under et navn, der bærer AAAA-recorden. På et IPv4-Docker-netværk, som her, viderestiller Docker porten på serverens IPv6-adresse til containeren. Åbn porten, hvis ufw er aktiv, og test derefter fra din computer:

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

Har du andre behov, så fortæl os, hvad du har i tankerne, og vi ser på adresseringen sammen med dig.

Indstillingerne i dit streamingprogram

• Codecs: H.264 til video og AAC til lyd, de eneste, hvor transcodning og kompatibel afspilning er sikret.
• Interval mellem keyframes: én hvert 2. sekund, aldrig sat til «auto». I OBS angives intervallet i sekunder, altså 2.
• Bitraten: send det, du har tænkt dig at tilbyde, og ikke mere. Hvis din server klarer 720p ved 2.500 kbps, skal du ikke sende den 1080p ved 6.000 kbps: hver konvertering, du beder om, øger CPU-belastningen.

Videokvaliteter og forsinkelse

De kvaliteter, der tilbydes seerne, indstilles under «Configuration», «Video». Flere kvaliteter lader afspilleren vælge den, dens forbindelse kan holde til: dokumentationen anbefaler en ekstra kvalitet på 1.000 til 2.000 kbps ved siden af en høj kvalitet på 4.000 til 6.000 kbps, når din første konfiguration er testet.

• Bitraten: fra 400 til 13.000 kbps i trin på 100.
• Billedfrekvensen: fra 24 til 120 billeder i sekundet, 24 som standard.
• Opløsningen: ændr bredden eller højden, ikke begge, så bevarer Owncast billedformatet.
• CPU-forbruget: fem niveauer. Jo højere niveau, desto bedre billede, eller desto mindre fil ved samme kvalitet.

Passthrough videresender den indgående video uden at genkode den: det sparer næsten al den CPU, som kvaliteten ellers kræver, og ignorerer dens indstillinger for bitrate, opløsning og billedfrekvens. Dokumentationen forbeholder den øvede brugere: seerne modtager præcis det, dit program sender, hvilket visse afspillere ikke kan afspille, og forsinkelsen stiger. Test afspilningen på de enheder, der betyder noget for dig, før du satser på den.

Forsinkelsen indstilles med forsinkelsesbufferen på samme side. Hvert niveau bytter lidt forsinkelse for stabilitet, og en ændring gælder fra næste stream:

Version 0.3.0 tilføjer også på seersiden afspillerens indstilling «Minimize latency», som afspiller en anelse hurtigere for at komme tættere på live, og en indstilling for automatisk afspilning, der er slået fra som standard.

Objektlager til at betjene flere seere

Owncast kan sende sine videosegmenter til et S3-kompatibelt lager, som seerne henter dem fra. Serveren serverer stadig hovedplaylisten, API'erne og chatten; videoen, som udgør næsten hele båndbredden, kommer fra lageret. Din server sender så kun én kopi af hver kvalitet: i dokumentationens eksempel 6,5 Mbps for to kvaliteter på 5.000 og 1.500 kbps, uanset om du har nul seere eller tusind. CPU-belastningen forbliver den samme.

1. Opret en bucket hos din udbyder af objektlager.
2. Gør den offentligt læsbar, og angiv en CORS-politik, hvis udbyderen kræver det: en fejl CORS eller Access-Control-Allow-Origin i browserens konsol kommer næsten altid derfra.
3. Under «Configuration», «Server Setup», fanen «S3 Object Storage», slår du lageret til og angiver bucketens navn, adgangsnøglen, den hemmelige nøgle, endpointet og regionen. Alle disse felter er obligatoriske.

Dette lager serverer livestreamet, ikke et arkiv: Owncast sletter løbende de segmenter, der er ældre end playlisten plus en buffer på omkring 20 segmenter. Bucketen rummer kun de sidste par minutter af streamet.

Til seere spredt over hele verden beskriver dokumentationen også et netværk til levering af indhold (CDN) placeret foran Owncast med et separat værtsnavn for oprindelsesserveren og indstillingen «Websocket host override», som holder chatten forbundet til oprindelsesserveren.

Chat og moderation

Chatten indstilles under «Configuration», «Chat». Som standard er der ingen moderatorer: dokumentationen foreslår, at du i det mindste gør dig selv til moderator fra administrationens side «Users».

• Moderatorerne skjuler en besked eller udelukker en bruger direkte fra chatten. De har ingen adgang til administrationen.
• En udelukkelse afbryder brugerens forbindelse, fjerner brugerens beskeder og blokerer den kendte IP-adresse. Den kan ophæves senere; at slette en bruger er derimod endeligt.
• Kun etablerede brugere: denne indstilling blokerer beskeder fra konti, der er yngre end 15 minutter, moderatorer undtaget.
• Sprogfilteret afviser stødende beskeder ud fra en intern ordliste.
• Krav om godkendelse lader kun godkendte brugere, via en Fediverse-konto eller IndieAuth, og moderatorer sende beskeder.
• Hastighedsbegrænsningen, som er slået til som standard, tillader omkring én besked hvert to tredjedele sekund og blokerer i 10 sekunder den, der oversvømmer chatten.

Dokumentationen påpeger, at blokering af IP-adresser kan omgås, for eksempel med en VPN: den begrænser misbrug, og moderationen forbliver hver kanals eget arbejde. Derfor er navngivne moderatorer værdifulde ved dine mest sete streams.

Backup

Owncast tager selv backup af sin database én gang i timen til data/backup/owncastdb.bak. Flaget --backupdir ændrer denne mappe. Her er, hvad datamappen indeholder:

For en fuld gendannelse, eller for at flytte instansen, beder dokumentationen dig om at tage backup af hele mappen data: kopieres den til en ny installation, følger alt med. Med Docker og med tjenesten stoppet:

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

Planlæg denne kopi efter dine streams, og send den væk fra serveren. Lagt på dens disk indgår disse arkiver også i dens natlige backup.

Gendan databasen

En gendannelse fører databasen tilbage til tidspunktet for backuppen: alt, hvad der er ændret siden, går tabt. Kopiér først den nuværende database et sikkert sted hen, og derefter:

1. Stop Owncast.
2. Start Owncast med --restoreDatabase og stien til backupfilen: den gendanner databasen og lukker derefter.
3. Start Owncast som normalt, og kontrollér derefter dine indstillinger i administrationen.

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

Opdateringer

Med Docker giver dokumentationen to kommandoer, der køres fra mappen med compose.yaml. Datamappen bliver, hvor den er:

docker compose pull
docker compose up -d

Med installationsprogrammet beskriver noterne til version 0.3.0 opdateringen: stop tjenesten, læg de filer i webgrænsefladen, du har tilpasset, til side, kør installationsprogrammet igen med den konto, der kører Owncast, og genstart derefter. Scriptet gemmer selv et arkiv af mappen data i owncast-install-backups, før det erstatter versionen.

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

Version 0.3.0, udgivet den 3. september 2026, bringer plugins, Featured Streams, automatisk afspilning og valget af den grænseflade, RTMP lytter på. Dens noter beder dig om at læse ændringerne før opdateringen, da de berører din instans: følg disse noter ved hver version, og kopiér mappen data lige før.

Hvem gør hvad på en Managed VPS

Selvhosting kræver, at du holder serveren ud over selve applikationen. På en Managed VPS tager vores teams sig af serveren og følger din instans proaktivt; Owncast forbliver din software, med dens indstillinger og data.

Hvis du foretrækker, at vores teams griber ind i selve applikationen, faktureres den ydelse pr. time eller som fast pris, med et overslag oplyst før indgrebet.