Hosta Owncast på en Managed VPS: dina livesändningar på din egen server

Det Owncast gör

Owncast är en självhostad server med öppen källkod för livevideo och chatt, för en enda användare: en instans bär kanalen för en person eller en organisation. README-filen presenterar den som ett sätt att driva dina egna livesändningar, i stil med de stora etablerade plattformarna, samtidigt som du behåller äganderätten till ditt innehåll, ditt gränssnitt, din moderering och din publik.

• Mottagningen: ditt sändningsprogram, som OBS, skickar strömmen över RTMP, det protokoll som de stora strömningsplattformarna använder.
• Distributionen: Owncast delar upp videon i HLS-segment, i en eller flera kvaliteter, och serverar den på sin webbsida. Strömmen går också att spela upp i VLC eller mpv, på /hls/stream.m3u8.
• Chatten: inbyggd i sidan, med moderatorer, avstängningar och inloggning via Fediversum eller IndieAuth.
• Fediversum: ett Mastodon-konto kan följa din server och få besked varje gång du sänder live. Version 0.3.0 lägger till Featured Streams, som visar livesändningar från andra Owncast-servrar.
• Utbyggnaden: webhooks, API:er och, sedan 0.3.0, insticksprogram, som installeras från administrationen med de behörigheter du ger dem.

Det som MIT-licensen tillåter

Owncast publiceras under MIT-licensen. Den ger, kostnadsfritt, rätt att använda, kopiera, ändra, slå samman, publicera, distribuera, underlicensiera och sälja kopior av programvaran. Du kan alltså köra den för ditt företag, din gemenskap eller dina kunder, utan att köpa någon licens.

Det enda villkoret är att behålla upphovsrättsmeddelandet och licenstexten i alla kopior eller väsentliga delar av programvaran. Texten tillhandahåller programvaran ”i befintligt skick”, utan garanti.

Processor och bandbredd: dimensionera servern

Dokumentationen säger det direkt: kraven beror på din konfiguration. Den ger däremot en tydlig regel för att uppskatta dem. Processorn kodar om videon till de kvaliteter du erbjuder; bandbredden levererar den till varje tittare.

• Antalet tittare ändrar inte processorns belastning. Videon kodas en gång och serveras sedan till alla: noll tittare eller hundra, kodningsarbetet är detsamma. Chatten lägger till lite belastning, liten jämfört med kodningen.
• Bandbredden växer med varje tittare. Varje tittare tar emot en egen kopia av strömmen.
• Varje omkodad kvalitet kräver processorkraft, desto mer när målbithastigheten är låg, eftersom hårdare komprimering kräver mer beräkning.

Serverns bandbredd

Dokumentationen ger två formler. Volymen för en sändning, i gigabyte: bithastighet i kbit/s × längd i sekunder × tittare ÷ 8 000 000. Den högsta utgående hastigheten att klara, i Mbit/s: bithastighet i kbit/s × tittare ÷ 1 000. Med flera kvaliteter räknar du ut var och en och lägger ihop dem. Dess uppskattningar för en sändning på två timmar:

På en VPS från Simafri har trafiken ingen månadsmätare: dina sändningar dimensioneras efter sin högsta bithastighet. När din publik växer serverar objektlagringen, som tas upp längre ned, videon i stället för servern.

Processorn

Dokumentationen ger uppmätta riktmärken och påpekar att de varierar med kodek, bithastighet, upplösning och kodarens förinställning:

• En kärna per kvalitet: som en grov tumregel klarar en enda processorkärna ofta en omkodad kvalitet med 30 bilder per sekund.
• Bildfrekvensen: 60 bilder per sekund kräver ungefär dubbelt så mycket beräkning som 30, och 24 bilder per sekund ungefär 0,8 gånger så mycket.
• Standardinställningen: Owncast startar med en enda kvalitet, på 1 200 kbit/s och 24 bilder per sekund, med ljudet vidarebefordrat orört. Dokumentationen råder att börja där, testa och sedan lägga till en kvalitet när processorn har marginal.

Dokumentationen anger ingen siffra för minnet, och disken spelar liten roll: videosegmenten skrivs och tas sedan bort under sändningens gång. Bara mappen data växer med tiden. På en VPS är det processorn som kodar: varje omkodad kvalitet dimensioneras i vCPU. På en Managed VPS berättar du om dina sändningar, deras bithastighet, deras kvaliteter och din publik, så rekommenderar vi lämplig storlek.

Din sändningsanslutning

Innan strömmen når servern lämnar den din egen anslutning. Dokumentationen begär en uppladdningshastighet på minst 1,5 gånger strömmens bithastighet: 7,5 Mbit/s för en ström på 5 000 kbit/s. Den rekommenderar en trådbunden anslutning framför wifi.

Installationen med Docker Compose

Dokumentationen erbjuder avbilden owncast/owncast på Docker Hub, som innehåller ffmpeg, det kodningsverktyg som Owncast behöver. På en server där Docker är installerat skapar du en mapp och lägger denna compose.yaml i den, hämtad från 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 publicerad på 127.0.0.1: det är den enda ändringen jämfört med dokumentationens exempel, som publicerar båda portarna. Dess sida om omvänd proxy ber dig att hålla Owncast borta från internet, eftersom den som standard lyssnar på alla gränssnitt, och Docker publicerar en port på alla serverns adresser när ingen anges. Webbgränssnittet nås då bara via den omvända proxyn.
• Port 1935 tar emot strömmen över RTMP. Den förblir publik, eftersom ditt sändningsprogram når den direkt, utan att gå via proxyn.
• Mappen data håller databasen och dess säkerhetskopior på servern, utanför containern: det är den du säkerhetskopierar och flyttar.
• Taggen latest följer den senaste versionen; 0.3.0 låser en version.

Utan Docker: det officiella installationsprogrammet

Dokumentationens andra väg är ett skript som laddar ned den senaste versionen av Owncast för din plattform, och ffmpeg om det inte redan finns. Det installerar allt i en mapp owncast under den aktuella. Dokumentationen avråder från att köra det som root och rekommenderar att läsa varje fjärrskript innan du kör det:

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

För att Owncast ska starta med servern och starta om av sig själv efter en krasch tillhandahåller dokumentationen en systemd-tjänst, att anpassa efter mappen och kontot du har valt:

[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

Administratörslösenord och strömningsnyckel

Administrationen finns på /admin. Owncast startar med inloggningsuppgifter som alla känner till, och dokumentationen ber dig att byta dem vid din första inloggning:

För att göra ändringen innan gränssnittet är öppet för allmänheten går du via en SSH-tunnel: serverns port 8080 dyker upp på din dator, på http://localhost:8080/admin. Lägg till -p och den SSH-port som visas i din kundzon.

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

• Administratörslösenordet byts under ”Configuration”, ”Server Setup”. Det kräver 8 till 192 tecken, minst en liten bokstav, en stor bokstav, en siffra och ett specialtecken bland !@#$%^&*, och inget bindestreck någonstans.
• Strömningsnycklarna hanteras på fliken ”Stream Keys” på samma sida. Owncast föreslår en automatiskt genererad nyckel på 30 tecken, och du kan ha flera, var och en med en kommentar: en nyckel som ges till en medvärd kan senare återkallas utan att de andra påverkas.
• Ett bortglömt lösenord ersätts vid start med flaggan --adminpassword, som sparar det i databasen.

Administratörslösenordet och strömningsnyckeln är båda abc123 från början, men de är två separata inställningar: byt båda.

HTTPS: den omvända proxyn

Owncast hanterar inte HTTPS själv. Dokumentationen sätter en omvänd proxy framför den, som lyssnar på port 80 och 443, hämtar certifikatet, krypterar trafiken och vidarebefordrar den okrypterad till Owncast på port 8080. Utan HTTPS markerar webbläsarna sidan som osäker, och en sida som serveras med HTTPS kan inte bädda in din video eller din chatt.

• Proxyn vidarebefordrar alla sökvägar, inklusive WebSocket-anslutningen på /ws, som bär chatten. En proxy som blockerar den stänger av chatten.
• RTMP går inte via proxyn: ditt sändningsprogram skickar direkt till Owncasts port 1935.
• Besökarnas verkliga adress: Owncast läser huvudet X-Forwarded-For för att blockera IP-adressen för en användare som stängts av från chatten. Dokumentationen begär att proxyn själv sätter det huvudet.

Med Caddy

Dokumentationen föreslår Caddy om du inte har någon annan preferens: den hämtar ett certifikat från Let’s Encrypt på egen hand och vidarebefordrar WebSocket utan någon extra inställning. Här är dess Caddyfile-exempel, där raden tls anger e-postadressen för Let’s Encrypt-kontot:

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

Med Nginx

Med Nginx betonar dokumentationen WebSocket: att glömma det är det som stänger av chatten. Lägg till det här blocket map i avsnittet http i /etc/nginx/nginx.conf:

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

Det här webbplatsblocket följer dokumentationens, på port 80 så att Certbot kan installera 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

Sända över RTMP från OBS

Owncast tar emot alla program som sänder över RTMP till en fjärrserver. Nyckeln godtas bara på sökvägen /live. I OBS:

1. Öppna ”Settings” och sedan ”Stream”, och välj ”Custom” som tjänst.
2. Ange adressen rtmp://live.example.com:1935/live.
3. Ange din strömningsnyckel, den från fliken ”Stream Keys” i Owncast.
4. Starta sändningen.

Ett program utan fält för nyckeln godtar den fullständiga adressen, rtmp://live.example.com:1935/live/your-key.

På en VPS från Simafri kan serverns IPv6-adress öppna vilken port du vill: ditt sändningsprogram når port 1935 via den adressen, under ett namn som bär posten AAAA. På ett Docker-nätverk i IPv4, som här, kopplar Docker porten på serverns IPv6-adress till containern. Öppna den porten om ufw är aktivt och testa sedan från din dator:

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

För alla andra behov berättar du vad du har i tankarna, så går vi igenom adresseringen tillsammans med dig.

Inställningarna i ditt sändningsprogram

• Kodekarna: H.264 för video och AAC för ljud, de enda för vilka omkodning och kompatibel uppspelning är säkerställda.
• Intervallet för nyckelbildrutor: en varannan sekund, aldrig lämnat på ”auto”. I OBS anges intervallet i sekunder, alltså 2.
• Bithastigheten: skicka det du planerar att erbjuda, inte mer. Om din server klarar 720p på 2 500 kbit/s, skicka den inte 1080p på 6 000 kbit/s: varje konvertering du begär ökar processorns belastning.

Videokvaliteter och fördröjning

De kvaliteter som erbjuds tittarna ställs in under ”Configuration”, ”Video”. Flera kvaliteter låter spelaren välja den som dess anslutning klarar: dokumentationen rekommenderar en andra kvalitet, på 1 000 till 2 000 kbit/s, bredvid en hög kvalitet på 4 000 till 6 000 kbit/s, när din första konfiguration har testats.

• Bithastigheten: från 400 till 13 000 kbit/s, i steg om 100.
• Bildfrekvensen: från 24 till 120 bilder per sekund, 24 som standard.
• Upplösningen: ändra bredden eller höjden, inte båda, så behåller Owncast bildförhållandet.
• Processoranvändningen: fem nivåer. Ju högre nivå, desto bättre bild, eller desto mindre fil vid samma kvalitet.

Passthrough skickar vidare den inkommande videon utan att koda om den: det sparar nästan all processorkraft för den kvaliteten och bortser från dess inställningar för bithastighet, upplösning och bildfrekvens. Dokumentationen reserverar det för vana användare: tittarna får exakt det som ditt program skickar, vilket vissa spelare inte kan spela upp, och fördröjningen ökar. Testa uppspelningen på de enheter som är viktiga för dig innan du förlitar dig på det.

Fördröjningen ställs in med fördröjningsbufferten, på samma sida. Varje nivå byter lite fördröjning mot stabilitet, och en ändring gäller från nästa sändning:

Version 0.3.0 lägger också till, på tittarsidan, spelarens alternativ ”Minimize latency”, som snabbar upp uppspelningen något för att komma närmare direktsändningen, och en inställning för automatisk uppspelning, avstängd som standard.

Objektlagring för att nå fler tittare

Owncast kan skicka sina videosegment till en S3-kompatibel lagring, som tittarna laddar ned dem från. Servern serverar fortfarande huvudspellistan, API:erna och chatten; videon, som står för nästan all bandbredd, kommer från lagringen. Din server skickar då bara en kopia av varje kvalitet: i dokumentationens exempel 6,5 Mbit/s för två kvaliteter på 5 000 och 1 500 kbit/s, oavsett om du har noll tittare eller tusen. Processorns belastning förblir densamma.

1. Skapa en bucket hos din leverantör av objektlagring.
2. Gör den läsbar för alla och ställ in en CORS-policy om leverantören kräver det: ett fel CORS eller Access-Control-Allow-Origin i webbläsarens konsol kommer nästan alltid därifrån.
3. Under ”Configuration”, ”Server Setup”, fliken ”S3 Object Storage”, aktiverar du lagringen och anger bucketens namn, åtkomstnyckeln, den hemliga nyckeln, slutpunkten och regionen. Alla dessa fält är obligatoriska.

Den här lagringen serverar direktsändningen, inte ett arkiv: Owncast tar efter hand bort segment som är äldre än spellistan plus en buffert på ungefär 20 segment. Bucketen innehåller bara de sista minuterna av sändningen.

För tittare spridda över världen beskriver dokumentationen också ett nätverk för innehållsleverans (CDN) framför Owncast, med ett separat värdnamn för ursprunget och inställningen ”Websocket host override”, som håller chatten ansluten till ursprungsservern.

Chatten och modereringen

Chatten ställs in under ”Configuration”, ”Chat”. Som standard finns inga moderatorer: dokumentationen föreslår att du åtminstone gör dig själv till en, från sidan ”Users” i administrationen.

• Moderatorerna döljer ett meddelande eller stänger av en användare direkt från chatten. De har ingen åtkomst till administrationen.
• En avstängning kopplar från användaren, tar bort dennes meddelanden och blockerar dennes kända IP-adress. Den kan hävas senare; att ta bort en användare är däremot slutgiltigt.
• Bara etablerade användare: den här inställningen blockerar meddelanden från konton som är yngre än 15 minuter, moderatorer undantagna.
• Språkfiltret avvisar stötande meddelanden, utifrån en intern ordlista.
• Obligatorisk autentisering låter bara autentiserade användare, via ett konto i Fediversum eller IndieAuth, och moderatorer skicka meddelanden.
• Begränsningen av meddelandetakten, aktiv som standard, tillåter ungefär ett meddelande var två tredjedels sekund och blockerar i 10 sekunder den som översvämmar chatten.

Dokumentationen påpekar att IP-blockering går att kringgå, med en VPN till exempel: den håller nere missbruket, och modereringen förblir varje kanals eget arbete. Därav värdet av utsedda moderatorer för dina mest sedda sändningar.

Säkerhetskopiorna

Owncast säkerhetskopierar själv sin databas en gång i timmen, till data/backup/owncastdb.bak. Flaggan --backupdir ändrar den mappen. Så här ser datamappen ut:

För en fullständig återställning, eller för att flytta instansen, ber dokumentationen dig att säkerhetskopiera hela mappen data: att kopiera den till en ny installation för över allt. Med Docker, med tjänsten stoppad:

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

Schemalägg den här kopian efter dina sändningar, och skicka den utanför servern. Lagda på dess disk ingår de här arkiven också i dess nattliga säkerhetskopior.

Återställa databasen

En återställning för databasen tillbaka till tidpunkten för säkerhetskopian: allt som ändrats sedan dess går förlorat. Kopiera först den nuvarande databasen till en säker plats, och sedan:

1. Stoppa Owncast.
2. Starta Owncast med --restoreDatabase och sökvägen till säkerhetskopian: programmet återställer databasen och avslutas sedan.
3. Starta Owncast som vanligt och kontrollera sedan dina inställningar i administrationen.

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

Uppdateringarna

Med Docker anger dokumentationen två kommandon, som körs från mappen med compose.yaml. Datamappen ligger kvar:

docker compose pull
docker compose up -d

Med installationsprogrammet beskriver versionsanteckningarna för 0.3.0 uppdateringen: stoppa tjänsten, lägg undan de filer i webbgränssnittet som du har anpassat, kör installationsprogrammet igen som det konto som kör Owncast och starta sedan om. Skriptet sparar självt ett arkiv av mappen data i owncast-install-backups innan versionen ersätts.

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

Version 0.3.0, utgiven den 3 september 2026, inför insticksprogram, Featured Streams, automatisk uppspelning och valet av det gränssnitt som RTMP lyssnar på. Dess anteckningar ber dig att läsa ändringarna innan du uppdaterar, eftersom de påverkar din instans: följ anteckningarna vid varje version och kopiera mappen data strax innan.

Vem gör vad på en Managed VPS

Att självhosta innebär att sköta servern utöver applikationen. På en Managed VPS tar våra team hand om servern och följer din instans proaktivt; Owncast förblir din programvara, med sina inställningar och sina data.

Om du föredrar att våra team ingriper i själva applikationen faktureras den tjänsten per timme eller som fast pris, med en offert som lämnas före ingreppet.