Analytics cookies only (Google Analytics, PostHog). No ad networks, no cross-site tracking. See our privacy policy.
Self-host Owncast
updated Oct 2026deployed by usprices checked · Jul 2026Install verified on Ubuntu 26.04 · Oct 2026 · how we test
We earn commissions when you shop through the links below. Full disclosure →
A self-hosted live-streaming and chat server for a single streamer: point OBS or any RTMP broadcaster at it and viewers watch on your own web page, with built-in chat, moderation, viewer stats and optional publishing to the Fediverse. It is MIT-licensed Go with an embedded SQLite database and ships as one container, so there is no separate database or cache to run.
Runs on a VPS from $6/mo (Kamatera 2GB, 2 GB RAM) · prices checked Sep 2026
Our recommendation
Pick Owncast when one person or one channel wants to go live on their own domain: point OBS or any RTMP broadcaster at the server, viewers watch on the built-in page with chat and moderation, and you own the viewer stats and the stream. It is an MIT-licensed Go server with an embedded SQLite database, so the install is a single container with two ports, 8080 for the web page and admin and 1935 for RTMP ingest, and one `./data` directory. Upstream says it is impossible to give a single resource figure because transcoding, not viewer count, drives CPU, so our 1 GB floor is an estimate; what scales with viewers is bandwidth, and upstream's rule of thumb is that your own upload speed should be at least one and a half times the stream bitrate. PeerTube is the catalog's other video platform: a federated library of uploaded videos with live streaming on top, and a heavier multi-service install. Owncast does live only, and does it in one container.
What you need
Any VPS with at least 1024 MB of RAM
A domain you control — most self-hosted setups need HTTPS in front of them
Paid link — we earn a commission if you shop through it.
Install
Run these commands on your server:
# Owncast — single container, web on 8080 and RTMP ingest on 1935 — based on the compose example in Owncast's container install docs, pinned to 0.3.0cat > docker-compose.yml <<'EOF'services: owncast: image: owncast/owncast:0.3.0 restart: unless-stopped ports: - 8080:8080 - 1935:1935 volumes: - ./data:/app/dataEOFdocker compose up -d# → http://SERVER_IP:8080 — admin at /admin, user admin / password abc123 and stream key abc123 by default: change both before you stream
Owncast's install and resources docs are clear about the defaults you inherit and the costs that are yours:
non-negotiableThe admin login and the stream key both default to abc123 (admin user admin), and upstream says to change them immediately after first login. Until you do, anyone who finds the server can log in at /admin and anyone who guesses the key can broadcast on your page. They are separate settings; changing one does not change the other.
non-negotiableEverything, the SQLite database, configuration and video segments, lives under the mounted ./data directory, and that directory is the whole backup. Upstream's upgrade path is to pull the newer image and recreate the container; its examples use latest, so pin a tag and move it deliberately.
non-negotiableBudget CPU for transcoding and bandwidth for viewers. Each extra quality variant you offer is another encode running the whole time you are live, whether anyone is watching or not, and every viewer streams the full bitrate from your server for the whole broadcast; upstream's worked example puts one two-hour stream to 25 viewers near 100 GB. Object storage or a CDN is how it offloads that.
non-negotiableBoth ports are plain protocols: HTTP on 8080 and RTMP on 1935. Put a TLS reverse proxy in front of 8080 (upstream documents Caddy, nginx and others) before sharing the page, and leave 1935 reachable only from where you broadcast if your firewall allows it, since the stream key is its only protection.