Self-host Owncast on a managed VPS: your live streams on your own server

What Owncast does

Owncast is an open source, self-hosted, single-user live video streaming and chat server: one instance carries the channel of one person or organization. Its README presents it as a way to run your own live streams, in the style of the large mainstream platforms, while keeping ownership of your content, interface, moderation and audience.

• Ingest: your broadcasting software, such as OBS, sends the stream over RTMP, the protocol the major streaming platforms use.
• Delivery: Owncast cuts the video into HLS segments, in one or more qualities, and serves it on its web page. The stream also plays in VLC or mpv, at /hls/stream.m3u8.
• Chat: built into the page, with moderators, bans and sign-in through the Fediverse or IndieAuth.
• The Fediverse: a Mastodon account can follow your server and be told each time you go live. Version 0.3.0 adds Featured Streams, which show the live streams of other Owncast servers.
• Extending it: webhooks, APIs and, since 0.3.0, plugins, installed from the admin with the permissions you grant them.

What the MIT license allows

Owncast is published under the MIT license. It grants, free of charge, the right to use, copy, modify, merge, publish, distribute, sublicense and sell copies of the software. You can therefore run it for your business, your community or your clients, with no license to buy.

The only condition is to keep the copyright notice and the license text in all copies or substantial portions of the software. The text provides the software “as is”, without warranty.

CPU and bandwidth: sizing the server

The documentation says it up front: requirements depend on your configuration. It does set out a clear rule to estimate them. The CPU transcodes the video into the qualities you offer; bandwidth delivers it to each viewer.

• Viewer count does not change CPU load. The video is encoded once, then served to everyone: zero viewers or a hundred, the encoding work is the same. Chat adds a little load, small next to encoding.
• Bandwidth grows with each viewer. Every viewer receives their own copy of the stream.
• Each transcoded quality needs CPU, all the more when the target bitrate is low, since compressing further takes more computation.

Server bandwidth

The documentation gives two formulas. The volume of a stream, in gigabytes: bitrate in kbps × duration in seconds × viewers ÷ 8,000,000. The peak outbound speed to sustain, in Mbps: bitrate in kbps × viewers ÷ 1,000. With several qualities, work out each one and add them up. Its estimates for a two-hour stream:

On a Simafri VPS, traffic has no monthly meter: your streams are sized on their peak bitrate. As your audience grows, object storage, covered below, serves the video in place of the server.

The CPU

The documentation gives measured reference points, noting that they vary with codec, bitrate, resolution and encoder preset:

• One core per quality: as a rough rule of thumb, a single CPU core can often handle one transcoded quality at 30 frames per second.
• Frame rate: 60 frames per second takes about twice the computation of 30, and 24 frames per second about 0.8 times.
• The default setting: Owncast starts with a single quality, at 1,200 kbps and 24 frames per second, with its audio passed through untouched. The documentation advises starting there, testing, then adding a quality once the CPU has headroom.

The documentation gives no memory figure, and disk matters little: video segments are written and then removed as the stream goes on. Only the data folder grows over time. On a VPS, the CPU does the encoding: each transcoded quality is sized in vCPUs. On a managed VPS, tell us about your streams, their bitrate, their qualities and your audience, and we will recommend the right size.

Your broadcasting connection

Before it reaches the server, the stream leaves your own connection. The documentation asks for an upload speed of at least 1.5 times the stream bitrate: 7.5 Mbps for a 5,000 kbps stream. It recommends a wired connection over Wi-Fi.

Installing with Docker Compose

The documentation offers the owncast/owncast image on Docker Hub, which includes ffmpeg, the encoding tool Owncast needs. On a server with Docker installed, create a folder and put this compose.yaml in it, taken from the documentation:

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 published on 127.0.0.1: this is the one change from the documentation’s example, which publishes both ports. Its reverse proxy page asks you to keep Owncast off the internet, since it listens on every interface by default, and Docker publishes a port on all of the server’s addresses when given none. The web interface is then reached through the reverse proxy alone.
• Port 1935 receives the stream over RTMP. It stays public, because your broadcasting software reaches it directly, without going through the proxy.
• The data folder keeps the database and its backups on the server, outside the container: this is what you back up and move.
• The latest tag follows the most recent release; 0.3.0 pins a version.

Without Docker: the official installer

The documentation’s other route is a script that downloads the latest Owncast release for your platform, and ffmpeg if it is not already there. It installs everything in an owncast folder under the current one. The documentation advises against running it as root and recommends reading any remote script before running it:

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

To have Owncast start with the server and restart on its own after a crash, the documentation provides a systemd service, to adapt to the folder and account you chose:

[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

Admin password and stream key

The admin lives at /admin. Owncast starts with credentials everyone knows, which the documentation asks you to change at your first login:

To make this change before the interface is open to the public, go through an SSH tunnel: the server’s port 8080 shows up on your computer, at http://localhost:8080/admin. Add -p and the SSH port shown in your customer area.

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

• The admin password is changed under “Configuration”, “Server Setup”. It needs 8 to 192 characters, at least one lowercase letter, one uppercase letter, one digit and one special character from !@#$%^&*, and no dash anywhere.
• Stream keys are managed in the “Stream Keys” tab of the same page. Owncast offers an auto-generated 30-character key, and you can keep several, each with a comment: a key given to a co-host can later be revoked without touching the others.
• A lost password is replaced at startup with the --adminpassword flag, which saves it to the database.

The admin password and the stream key both start as abc123, but they are two separate settings: change both.

HTTPS: the reverse proxy

Owncast does not handle HTTPS itself. The documentation puts a reverse proxy in front of it, which listens on ports 80 and 443, gets the certificate, encrypts the traffic and forwards it in plain form to Owncast on port 8080. Without HTTPS, browsers flag the page as not secure, and a page served over HTTPS cannot embed your video or your chat.

• The proxy forwards every path, including the WebSocket connection at /ws, which carries the chat. A proxy that blocks it cuts off the chat.
• RTMP does not go through the proxy: your broadcasting software sends straight to Owncast’s port 1935.
• Visitors’ real address: Owncast reads the X-Forwarded-For header to block the IP address of a user banned from chat. The documentation asks for the proxy to set this header itself.

With Caddy

The documentation suggests Caddy if you have no other preference: it gets a Let’s Encrypt certificate on its own and forwards WebSocket with no extra setting. Here is its Caddyfile example, where the tls line gives the email address of the Let’s Encrypt account:

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

With Nginx

With Nginx, the documentation stresses WebSocket: forgetting it is what disables chat. Add this map block to the http section of /etc/nginx/nginx.conf:

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

This site block follows the documentation’s, on port 80 so that Certbot can set up 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

Streaming over RTMP from OBS

Owncast accepts any software that broadcasts over RTMP to a remote server. The key is only accepted on the /live path. In OBS:

1. Open “Settings”, then “Stream”, and pick “Custom” as the service.
2. Enter the address rtmp://live.example.com:1935/live.
3. Enter your stream key, the one from Owncast’s “Stream Keys” tab.
4. Start streaming.

Software with no field for the key accepts the full address, rtmp://live.example.com:1935/live/your-key.

On a Simafri VPS, the server’s IPv6 address can open any port you choose: your broadcasting software reaches port 1935 through that address, under a name that carries the AAAA record. On an IPv4 Docker network, as here, Docker maps the port on the server’s IPv6 address to the container. Open that port if ufw is active, then test from your computer:

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

For any other need, tell us what you have in mind and we will look at the addressing with you.

Your broadcasting software settings

• Codecs: H.264 for video and AAC for audio, the only ones for which transcoding and playback compatibility are assured.
• Keyframe interval: one every 2 seconds, never left on “auto”. In OBS the interval is in seconds, so 2.
• Bitrate: send what you plan to offer, no more. If your server handles 720p at 2,500 kbps, do not send it 1080p at 6,000 kbps: every conversion you ask for adds CPU load.

Video qualities and latency

The qualities offered to viewers are set under “Configuration”, “Video”. Several qualities let the player pick the one its connection can sustain: the documentation recommends a second quality, from 1,000 to 2,000 kbps, next to a high quality of 4,000 to 6,000 kbps, once your first configuration has been tested.

• Bitrate: from 400 to 13,000 kbps, in steps of 100.
• Frame rate: from 24 to 120 frames per second, 24 by default.
• Resolution: change the width or the height, not both, and Owncast keeps the aspect ratio.
• CPU usage: five levels. The higher the level, the better the picture, or the smaller the file at equal quality.

Passthrough passes the incoming video along without re-encoding it: it saves nearly all of that quality’s CPU, and ignores its bitrate, resolution and frame rate settings. The documentation reserves it for advanced users: viewers receive exactly what your software sends, which some players cannot play, and latency goes up. Test playback on the devices that matter to you before relying on it.

Latency is set with the latency buffer, on the same page. Each level trades a little delay for stability, and a change applies from the next stream:

Version 0.3.0 also adds, on the viewer side, the player’s “Minimize latency” option, which slightly speeds up playback to get closer to live, and an autoplay setting, off by default.

Object storage to serve more viewers

Owncast can send its video segments to S3-compatible storage, from which viewers download them. The server still serves the master playlist, the APIs and the chat; the video, which makes up almost all of the bandwidth, comes from the storage. Your server then sends only one copy of each quality: in the documentation’s example, 6.5 Mbps for two qualities at 5,000 and 1,500 kbps, whether you have zero viewers or a thousand. CPU load stays the same.

1. Create a bucket with your object storage provider.
2. Make it publicly readable, and set a CORS policy if the provider requires one: a CORS or Access-Control-Allow-Origin error in the browser console almost always comes from there.
3. Under “Configuration”, “Server Setup”, “S3 Object Storage” tab, enable storage and enter the bucket name, access key, secret key, endpoint and region. All of these fields are required.

This storage serves the live stream, not an archive: Owncast deletes, as it goes, segments older than the playlist plus a buffer of about 20 segments. The bucket only holds the last few minutes of the stream.

For viewers spread around the world, the documentation also describes a content delivery network (CDN) placed in front of Owncast, with a separate origin hostname and the “Websocket host override” setting, which keeps the chat connected to the origin server.

Chat and moderation

Chat is set up under “Configuration”, “Chat”. By default there are no moderators: the documentation suggests at least making yourself one, from the “Users” page of the admin.

• Moderators hide a message or ban a user from the chat itself. They have no access to the admin.
• A ban disconnects the user, removes their messages and blocks their known IP address. It can be lifted later; deleting a user, on the other hand, is permanent.
• Established users only: this setting blocks messages from accounts younger than 15 minutes, moderators excepted.
• The language filter rejects offensive messages, using an internal word list.
• Required authentication lets only authenticated users, through a Fediverse account or IndieAuth, and moderators send messages.
• The rate limiter, on by default, allows roughly one message every two thirds of a second and blocks anyone flooding the chat for 10 seconds.

The documentation points out that IP blocking can be evaded, with a VPN for example: it keeps abuse down, and moderation remains each channel’s own work. Hence the value of named moderators for your most watched streams.

Backups

Owncast backs up its own database once an hour, to data/backup/owncastdb.bak. The --backupdir flag changes that folder. Here is what the data folder holds:

For a full recovery, or to move the instance, the documentation asks you to back up the whole data folder: copying it to a new install carries everything over. With Docker, with the service stopped:

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

Schedule this copy to match your streams, and send it off the server. Placed on its disk, these archives are also part of its nightly backups.

Restoring the database

A restore brings the database back to the time of the backup: anything changed since is lost. First copy the current database somewhere safe, then:

1. Stop Owncast.
2. Start Owncast with --restoreDatabase and the path of the backup file: it restores the database, then exits.
3. Start Owncast as usual, then check your settings in the admin.

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

Updates

With Docker, the documentation gives two commands, run from the compose.yaml folder. The data folder stays in place:

docker compose pull
docker compose up -d

With the installer, the 0.3.0 release notes describe the update: stop the service, set aside any web interface files you have customized, run the installer again as the account that runs Owncast, then restart. The script itself stores an archive of the data folder in owncast-install-backups before replacing the release.

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

Version 0.3.0, released on 3 September 2026, brings plugins, Featured Streams, autoplay and the choice of the interface RTMP listens on. Its notes ask you to read the changes before updating, as they affect your instance: follow these notes with each release, and copy the data folder right before.

Who does what on a managed VPS

Self-hosting means running the server on top of the application. On a managed VPS, our teams take charge of the server and proactively monitor your instance; Owncast remains your software, with its settings and its data.

If you would rather have our teams work inside the application itself, that service is billed by the hour or at a fixed rate, with an estimate shared before the work starts.