An Owncast server for your own live stream and chat

What your Owncast server does while you are live

OBS, or whatever you broadcast from, pushes one stream to your server over RTMP. Owncast hands it to FFmpeg, which turns it into short HLS video chunks, and then serves those chunks, your channel page, the chat and an admin dashboard, all from the same program. Viewers just open your web address; nothing to install on their side.

The project's requirements guide makes one point worth remembering: processor use stays the same whether nobody is watching or a hundred people are. Encoding happens once. What grows with your audience is outbound traffic, because each viewer downloads their own copy.

Will the processor keep up?

It will if you match the quality options to the cores. Owncast lets you choose how many versions of your stream to offer, and each version is a separate encode:

• Passthrough, sending your stream on unchanged: minimal processor work. Settings like bitrate and resolution are ignored for that output, and viewers on weak connections get the full bitrate or nothing.
• One re-encoded quality: light. As a loose guide from the docs, plan roughly one processor core per re-encoded quality at 30 frames a second.
• A high and a low quality: moderate, and the configuration the project recommends once a single quality works.
• Three qualities, or heavy compression: heavy.

Those multipliers come from the Owncast docs and are labelled as rough measured examples. The project's advice is to start with one output, watch the Stream Health page in the admin, and add a lower quality only while the processor has room.

The docs call passthrough an advanced setting that most people should not use, and the admin makes you confirm the risks before it turns on. If your encoder sends something a phone or browser cannot decode, Owncast cannot fix it, and long keyframe intervals make viewers fall further behind live.

How many people can watch at once?

Multiply the bitrate each viewer receives by the number of viewers. Owncast's own formula gives the answer in Mbit/s: multiply kbit/s by viewers and divide by 1,000. Our dedicated streaming server page plans every port at 80 percent so the stream holds at its peak, which gives these ceilings for a 1 Gbps port (our arithmetic, not the project's):

A 10 Gbps port carries ten times each figure. Because the port is unmetered, a long stream or a busy month does not add anything to the bill: there is no transfer allowance to run past and nothing billed as overage. One more number belongs to your side: the docs ask for an upload at home of at least 1.5 times your streaming bitrate, so a 6,000 kbit/s stream wants about 9 Mbit/s of upload, ideally over a cable rather than Wi-Fi.

The server that fits

A whole machine matters for two reasons. Nobody else's encode is competing for your processor halfway through the show, and hardware encoding becomes possible at all. Owncast's codec guide rules it out on a VPS, since a virtual server shared with other customers cannot reach the graphics hardware directly.

• One stream, one or two qualities, a modest audience: a small machine on its included unmetered port, which is 1 Gbps on ten of our eighteen lines and 500 Mbps on eight.
• Several qualities from one stream: a processor that has Intel graphics built in, which is what gives you Quick Sync hardware encoding. Here that means the Xeon E3-1284L v3 or v4, the E3-1585L v5 or the E-2286M; see our Intel processor guide. Check that your FFmpeg build lists the encoder and actually uses it. In Docker that also means passing the GPU into the container (a devices: - /dev/dri:/dev/dri line) and an FFmpeg with VA-API/Quick Sync support inside it; the plain install is the simpler route for hardware encoding.
• A bigger audience: keep the machine and raise the port; 10 Gbps and above can be picked when you order, and the 10 Gbps page lists the lines that carry it.

A machine already in a rack reaches you about 30 minutes once your order is approved; one built to order, including any port above 1 Gbps, takes 4 to 24 hours.

Up and running in an evening

The project publishes an official container image, which keeps everything in one folder you can copy elsewhere later. Install Docker Engine on Ubuntu from Docker's own instructions, make a folder such as ~/owncast, and save this as docker-compose.yml inside it:

services:
  owncast:
    image: owncast/owncast:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"   # web and admin: only reachable through your proxy
      - "127.0.0.1:1935:1935"   # step 4 opens this to your encoder
    volumes:
      - ./data:/app/data

1. Start it with docker compose up -d. Both ports listen only on the server itself for now. That matters, because ports Docker publishes skip ufw's rules entirely.
2. From your own computer, open a tunnel with ssh -N -L 8080:127.0.0.1:8080 you@server-ip, then load http://127.0.0.1:8080/admin. The user name is admin and the password is abc123.
3. In Configuration > Server Setup, pick a fresh admin password between 8 and 192 characters long, mixing upper and lower case with a digit and one of !@#$%^&*, and leaving out dashes. Then switch to Stream Keys, keep the 30-character key Owncast generates for you, and delete abc123.
4. Change the second port line to "1935:1935", then repeat docker compose up -d. RTMP is now open to your encoder; the web port still is not.
5. Point a domain at the server, allow 80 and 443 through ufw if you use it (sudo ufw allow http and sudo ufw allow https), and add a reverse proxy that holds a free certificate. With Caddy, a site block for your domain containing reverse_proxy 127.0.0.1:8080 is enough. Never send RTMP through the proxy.
6. In OBS, set the server to rtmp://your-domain/live and paste the new stream key. Go live, then open your domain in a browser.

Prefer no containers? Owncast's installer, curl -s https://owncast.online/install.sh | bash, fetches the program and an FFmpeg if you lack one. The project asks you not to run it as root and to read the script first, and its guide shows how to keep Owncast running as a system service.

When the audience outgrows one port

Owncast can send its video chunks to an S3-compatible storage bucket and let viewers download them from there. Your server then uploads just one copy of each quality, so its own traffic stays flat however many people watch, while it keeps serving the page and the chat. Make the bucket publicly readable and set its CORS policy, or players will fail with errors naming Access-Control-Allow-Origin.

Two things the docs are clear about. The bucket holds just a few minutes of recent video, so it is no replacement for recordings. And the project's scaling guide says you cannot simply run more copies of Owncast to grow; the next step past storage is a content delivery network in front of your origin: give the origin its own public hostname and set the Websocket host override in Server Setup to it, or chat stops working behind CDNs that do not pass websockets through.

Keeping it healthy

• Copy the data folder. Owncast saves a database backup every hour inside data/backup, but emoji, uploaded files and plugins sit elsewhere in data/. Back up the whole ./data folder you mounted.
• Update deliberately. Run docker compose pull and then docker compose up -d, after a show rather than before one.
• Choose your delay. With the default buffer, viewers trail you by roughly 10 seconds; the minimum setting brings that closer to 5 but stalls more on shaky connections.
• Know your way back in. A remote iLO or iDRAC console comes with the blade, rack and larger cartridge lines; the smaller cartridges have power control and a reinstall button in the dashboard.

When you would be better off without a server

If you would rather never touch a terminal, a shared live video plan of ours is cheaper below about a thousand viewers at 1080p, RTMP in and HLS out, and leaves nothing to administer; the streaming server page says so in its own words. If you want your show on several platforms simultaneously, read our guide to streaming to several platforms at once first. Owncast is for the moment you want your own page, your own chat and your own rules.

Questions people ask

Is Owncast free to run?

The software is free and open source, with no subscriptions, viewer limits or forced adverts, according to its own site. What you pay for is the machine it runs on and, if you choose to use one, an external storage bucket.

Why do I have to change abc123 straight away?

Both the admin password and the stream key ship as abc123 and are written in the public docs. Anyone who reaches your admin page could take it over, and anyone who reaches port 1935 could broadcast on your channel. Change both through an SSH tunnel before opening either port.

Do I need a graphics card?

Usually not. One or two qualities run fine on ordinary cores. If you want several qualities, a processor with Intel Quick Sync or an NVIDIA card with NVENC can take over the encoding, provided the drivers and a matching FFmpeg build are installed.

What if I forget the admin password?

Start Owncast once with the --adminpassword flag and a new password; the change is saved. Anything typed on a command line can show up in the process list and your shell history, so clear that line afterwards.

Can I embed the stream on my website?

Yes. Owncast publishes standard HLS, so the stream plays in its own page, in an embed on your site, or in players like VLC at your address followed by /hls/stream.m3u8. Embedding into an https site needs your Owncast address on https too, which is what the reverse proxy is for.