Live streaming today means signing up for Twitch, YouTube Live, or another Big Tech platform. You get an audience, sure, but you also get ads you cannot control, algorithmic recommendations pushing viewers toward competing streams, rules that change overnight, and a chat system that ties your community to someone else’s database. For a hobbyist streamer, a small creator, or an internal company event, handing over complete ownership of a live broadcast to a third party feels like trading your house keys for a guest pass.
Owncast is the direct answer to that trade-off. It is a self-hosted, single-user live video streaming server that you run on your own infrastructure. It handles RTMP ingest from your broadcasting software, packages the stream into HLS segments for playback, and serves a complete web interface with a built-in chat, all from a single Docker container. There is no platform taking a cut, inserting ads, or telling you what you can and cannot stream. It is your server, your audience, and your content.
This article walks through a practical Docker Compose deployment of Owncast: a clean single-container setup you can have running in minutes, a complete breakdown of the twelve command-line flags that control runtime behavior, how the data volume works, how to connect OBS, and what you can configure through the built-in admin panel once the server is up. Because nearly all Owncast settings live in the admin web UI rather than in environment variables, understanding which levers are available at startup versus at runtime is the difference between fighting the tool and using it.
Quick Win: What This Article Delivers
By the end of this article, you will have a working Owncast deployment pattern you can copy onto a server today:
- A self-contained Docker Compose stack with a single container exposing the web interface and RTMP ingest.
- A clear explanation of every command-line flag Owncast exposes:
--webserverport,--rtmpport,--adminpassword,--streamkey,--database,--logdir,--backupdir,--enableDebugFeatures,--enableVerboseLogging,--restoreDatabase,--webserverip, and--followervalidationinterval. - A concrete understanding of the
/app/datavolume: what lives there, why binding it to the host matters for migrations, and what happens if you skip it. - Step-by-step instructions to go from
docker compose upto your first live stream using OBS. - An overview of the admin panel’s configuration categories so you know where to change your stream key, tune video quality, connect S3 storage, turn on Fediverse followers, enable Discord notifications, and moderate chat.
What Does This Thing Actually Do?
Owncast is a complete live streaming platform in a single binary. It is not a plugin for another service and it is not a relay. It is an ingest-and-distribute server that takes an RTMP feed from your broadcasting software and serves the result to viewers as HLS segments with a chat room alongside.
Key capabilities:
- RTMP ingest – Receives a live video feed from OBS, Streamlabs, Restream, or any RTMP-compatible broadcasting software on port
1935. - HLS video distribution – Transcodes the incoming RTMP stream into HLS segments and serves them to viewers through the built-in web player on port
8080. - Built-in web interface and chat – Viewers get a customizable page with the video player and a real-time chat, no external services required.
- Fediverse integration – Owncast is an ActivityPub server. People on Mastodon and other Fediverse platforms can follow your stream handle, see when you go live, and interact with your chat from their Mastodon account.
- Video quality variants – Configure multiple output resolutions and bitrates through the admin. Viewers with slower connections get a lower-bandwidth variant automatically.
- S3-compatible object storage – Offload video distribution to S3, MinIO, Backblaze B2, or any S3-compatible storage provider instead of serving segments from your own server.
- Notifications – Notify your audience when you go live via browser push notifications, Discord webhooks, or Fediverse follower announcements.
- Chat moderation and emoji – Moderate chat with name-based and message-based filters, add custom emoji, and optionally require authenticated chat access.
- Plugin system – Extend Owncast with JavaScript plugins that can modify the page, add overlays, integrate external services, or inject custom UI elements.
- Owncast Directory – Opt into a community-maintained directory of streams, making your server discoverable without handing over your content.
- Embeddable player – The video player can be embedded on other websites as an iframe, so you can run a stream on your own blog or project page.
- Webhooks and APIs – Integrate Owncast with external tooling through first-class webhooks and a documented REST API plus WebSocket interface for real-time events.
- Customization without compiling – The admin panel lets you change the page title, logo, colors, and summary, add custom CSS and JavaScript, and tweak the appearance without touching the container.
A Little Background
Owncast was started in May 2020 by Gabe Kangas. The timing is not a coincidence. When lockdowns pushed everyone indoors, live streaming exploded, and the people who jumped onto Twitch or YouTube Live suddenly realized how little control they had. Owncast was built from the start as a single-user system, meaning it is designed for one streamer with one audience per server. That scope decision keeps the project focused and the deployment footprint small.
The project is written in Go for the backend and React for the frontend, released under the MIT License, and has gathered over 11,500 stars on GitHub. The latest stable release is v0.2.5 from April 2026, with v0.3.0 in development as a nightly build that adds the plugin system among other features. Owncast joins the ActivityPub network, which means your stream handle on the Fediverse works like a Mastodon account. Followers see your stream announcements in their home timeline and can interact with chat through their Mastodon instance while watching on your Owncast page.
The project’s product definition describes a clear vision: Owncast is for the DIY streamer who wants independence and the integrator who wants to add live streaming to an existing product. It is not trying to be a multi-tenant SaaS platform. That tight scope is why the Docker deployment fits in a single container.
Docker Compose Setup
Owncast is one of the simplest Docker deployments in this series. A single container, two ports, and one volume. The image ships with ffmpeg baked in so transcoding works out of the box.
The container exposes two ports:
8080– Web interface, HLS video segments, admin panel, and API. This is where viewers connect with a browser.1935– RTMP ingest. Your broadcasting software pushes video to this port.
The following Compose file is copy-paste runnable. It pins to the official owncast/owncast:latest image on Docker Hub, binds the data directory to a host folder so your database and configuration survive container recreation, and restarts automatically unless you explicitly stop it.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
services: owncast: image: owncast/owncast:latest container_name: owncast restart: unless-stopped ports: - "8080:8080" - "1935:1935" volumes: - ./data:/app/data |
If you prefer to pass command-line flags at startup, add a command: key. For example, to set a custom admin password and stream key at container start so you do not have to visit the admin immediately:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
services: owncast: image: owncast/owncast:latest container_name: owncast restart: unless-stopped ports: - "8080:8080" - "1935:1935" volumes: - ./data:/app/data command: - "--adminpassword=MySecureAdminPass42" - "--streamkey=sk-live-abc123def456" - "--webserverport=8080" - "--rtmpport=1935" |
The owncast/owncast image is the official, maintained image on Docker Hub. An older image under the name gabekangas/owncast also exists and still receives updates, but the owncast/owncast namespace is the current canonical source. For the upcoming v0.3.0 features including the plugin system, there is a nightly image at ghcr.io/owncast/owncast:nightly on GitHub Container Registry.
Installation Steps
- Create a project directory. On your server, make a folder for Owncast and place the
docker-compose.ymlfrom above inside it. - Start the container.
- Verify it is running. Check the logs to confirm Owncast started without errors. You should see log lines indicating the web server is listening on port 8080 and the RTMP server on 1935.
- Open the admin panel. Navigate to
http://your-server-ip:8080/adminin a browser. Log in with the default credentials: Change the admin password immediately. Go to Configuration, then Server Setup, and set a strong password. The admin password and the stream key are separate settings, even though both default toabc123. - Change your stream key. Still under Server Setup in the admin, replace the default stream key
abc123with a long random string. This is the secret that authorizes your broadcasting software to push video to the server. Treat it like a password. - (Optional) Set your server URL. Under Configuration, then General, fill in the Server URL field with the public address where viewers reach your server. This is required to enable notifications and for correct behavior of the Fediverse integration.
- Connect your broadcasting software. In OBS Studio go to Settings, then Stream. Set Service to Custom. Fill in:
If your broadcasting software does not have a separate stream key field, append it to the URL:
rtmp://your-server-ip:1935/live/yourstreamkey. - Start streaming. Click Start Streaming in OBS. Within a few seconds, Owncast detects the incoming RTMP feed and begins transcoding. Open
http://your-server-ip:8080in a browser. The video player and chat should appear. - Upgrading later. To update to a newer Owncast release, pull the latest image and recreate the container:
Your data, configuration, and stream key persist because they live in the bound
./datadirectory on the host.
Command-Line Flags Explained
Owncast exposes twelve command-line flags that control runtime behavior. These are the only startup-time configuration levers. Everything else such as video quality, chat moderation, notifications, and page appearance is configured through the admin web UI at /admin and stored in the SQLite database inside /app/data.
In a Docker Compose setup, pass flags through the command: key. In a docker run command, append them after the image name. Flags are optional. Owncast starts with sensible defaults when none are provided.
–webserverport
Purpose: Overrides the port the web server listens on for HTTP traffic, HLS segments, the admin panel, and the API.
Format: A port number as a string.
Default: 8080. The internal default is set in the Owncast source code and matches the port exposed by the Dockerfile.
|
1 2 3 4 |
command: - "--webserverport=9000" |
Security note: Changing this flag internally also requires adjusting your Compose port mapping so the host-forwarded port matches, otherwise the container port and the Owncast process port will disagree and the service will be unreachable.
–rtmpport
Purpose: Overrides the port the RTMP server listens on for incoming video from broadcasting software.
Format: An integer.
Default: 1935. This is the standard RTMP port used by OBS, Streamlabs, and most broadcasting tools.
|
1 2 3 4 |
command: - "--rtmpport=1936" |
Security note: RTMP is an unencrypted protocol. Only expose port 1935 to networks you trust. If you need to ingest streams over the open internet, consider using a VPN or running OBS through a WireGuard tunnel to the server.
–webserverip
Purpose: Binds the web server to a specific IP address on the container instead of listening on all interfaces.
Format: An IPv4 or IPv6 address as a string.
Default: 0.0.0.0, which means the web server listens on all available network interfaces.
|
1 2 3 4 |
command: - "--webserverip=127.0.0.1" |
Security note: Binding to 127.0.0.1 inside the container makes the web interface unreachable from outside the container unless something else inside the same container network stack proxies to it. This is rarely the right call in Docker. If you want to restrict access, use Docker’s port binding syntax such as "127.0.0.1:8080:8080" instead.
–adminpassword
Purpose: Sets the admin password at startup. If the database already exists the password is updated. If no database exists yet the password is written into the fresh database.
Format: A plaintext string.
Default: abc123, which is the baked-in default when no flag is provided and no database exists yet.
|
1 2 3 4 |
command: - "--adminpassword=CorrectHorseBatteryStaple" |
Security note: Hardcoding a password in a Compose file commits it to version control. For a publicly shared Compose file, set the password through the admin UI after first start and remove the flag. If you use the flag during provisioning, consider pulling the value from a Docker secret or a .env file outside of version control.
–streamkey
Purpose: Sets a temporary stream key valid only for the current process lifetime. It is not persisted to the database, which makes it useful for one-off or automated test streams where you do not want to leave a permanent key behind.
Format: A plaintext string.
Default: No temporary stream key is set unless the flag is provided.
|
1 2 3 4 |
command: - "--streamkey=temp-one-shot-key-2026" |
Security note: This flag creates a session-only key. Your permanent stream key, set through the admin UI, continues to work alongside it. The flag does not override or delete the stored key, it adds a second valid key. Remove the flag when the temporary need passes.
–database
Purpose: Specifies a non-default path to the SQLite database file.
Format: A filesystem path relative to the working directory or absolute.
Default: data/owncast.db inside the container, which resolves to /app/data/owncast.db at runtime.
|
1 2 3 4 |
command: - "--database=/app/data/custom-owncast.db" |
In most deployments you will never need this flag. The default location inside the bound /app/data volume already keeps the database on the host.
–logdir
Purpose: Redirects Owncast logs to a directory of your choice instead of writing to stdout.
Format: A filesystem path.
Default: Empty. When not set, logs are written to stdout, which is the expected behavior in Docker where docker compose logs picks them up.
|
1 2 3 4 |
command: - "--logdir=/app/data/logs" |
Security note: A log directory fills up over time if not rotated. If you redirect to a file inside the data volume, add external log rotation or monitor disk usage so a long-running instance does not exhaust the volume.
–backupdir
Purpose: Sets a custom directory where Owncast writes automatic database backups.
Format: A filesystem path.
Default: data/backup inside the container. Owncast periodically writes a copy of the SQLite database to this directory.
|
1 2 3 4 |
command: - "--backupdir=/app/data/my-backups" |
Because the default backup path sits under the /app/data volume, backups survive container recreation automatically when the volume is bound to the host. No extra configuration is required for a normal deployment.
–enableDebugFeatures
Purpose: Turns on additional debug endpoints and diagnostics in the admin panel.
Format: Boolean flag. Pass true to enable or omit it entirely for the default.
Default: false. Debug features are off.
|
1 2 3 4 |
command: - "--enableDebugFeatures=true" |
Security note: Debug features may expose internal state and performance data. Enable this only on a staging or development instance, never on a production server accessible from the internet.
–enableVerboseLogging
Purpose: Increases log verbosity for troubleshooting startup issues, RTMP connection problems, or Fediverse federation errors.
Format: Boolean flag.
Default: false.
|
1 2 3 4 |
command: - "--enableVerboseLogging=true" |
Turn this on temporarily when troubleshooting, then remove it. Sustained verbose logging generates a large volume of output and can make it harder to spot real problems in the noise.
–restoreDatabase
Purpose: Restores an Owncast database from a backup file at startup. The flag expects the path to a backup file created by Owncast’s built-in backup mechanism or a manual copy of the SQLite database.
Format: A filesystem path to a database backup file.
Default: No restore is attempted.
|
1 2 3 4 |
command: - "--restoreDatabase=/app/data/backup/owncast-backup-2026-08-30.db" |
Security note: A restore overwrites the current database. Make a manual copy of owncast.db before running this flag if there is any chance you need the current state back.
–followervalidationinterval
Purpose: Controls how often, in seconds, Owncast validates Fediverse followers by checking if their remote accounts still exist and still follow the stream. Invalid followers are removed automatically.
Format: An integer representing seconds.
Default: The default interval is baked into the Owncast source. The exact value is not publicly documented, but the flag exists to let operators shorten or lengthen the cycle.
|
1 2 3 4 |
command: - "--followervalidationinterval=86400" |
This is an advanced tuning flag. Shortening the interval too aggressively generates unnecessary outbound traffic to remote Fediverse servers. Lengthening it means dead followers stick around longer and inflate your visible follower count. Most deployments should leave this at the default.
Volume Mounts Explained
/app/data
Purpose: The /app/data directory is Owncast’s sole persistent storage location. Everything that must survive container recreation lives here.
Contents:
owncast.db– The SQLite database containing all configuration set through the admin panel, chat history, Fediverse follower records, and server state.backup/– Automatic database backups written periodically by Owncast.- Log files, if
--logdiris pointed here or defaults place them under the data tree.
Practical usage: Bind this directory to a host folder with the ./data:/app/data volume mapping shown in the Compose file. Without this binding, a docker compose down wipes your entire configuration, stream key, and chat history. With the binding, you can move the data directory to a new server and bring Owncast back up with zero reconfiguration.
Common Use Cases
The Indie Game Streamer
You stream gameplay on Twitch but want a second home where your community is not competing with Twitch ads and algorithm-driven recommendations. Run Owncast on a cheap VPS with 2-4 vCPUs, point OBS at it as a second output using the OBS Multiple RTMP Outputs plugin or a separate portable OBS instance, and give your regulars an ad-free viewing experience with a chat they already know how to use.
Private Company Events
An all-hands meeting, a product demo, or a training session needs to be streamed to employees without ending up on a public platform. Owncast runs inside the company VPN or on an internal network. Set up the stream key once, embed the player on an internal wiki page, and only people with VPN access can reach it. No accounts, no public directory, no leakage.
The Fediverse-Connected Creator
You have an audience on Mastodon and you want to keep it. Turn on the Fediverse features in the admin, set your server URL, and your stream gets its own ActivityPub handle such as @streamer@owncast.example.com. Mastodon users follow that handle, see your go-live announcements in their timeline, and can even participate in your chat from their Mastodon client while watching on your Owncast page. The audience stays on the Fediverse instead of being dragged into a walled garden.
Low-Bandwidth Regional Broadcasting
You stream to viewers in a specific region where international CDN bandwidth is limited or expensive. Use Owncast with S3-compatible object storage pointed at a regional provider or a self-hosted MinIO instance. Video segments are served from storage close to your audience while the single Owncast instance handles ingest and chat from a lightweight server.
Useful Links
- Owncast – Official Website
- Docker Container Installation – Owncast Docs
- Owncast Configuration Reference
- owncast/owncast – GitHub Repository
- owncast/owncast – Docker Hub
- owncast/owncast – GitHub Container Registry (nightly builds)
- Owncast Demo Server
- Owncast Directory
- Live Stream Notifications – Owncast Docs
- OBS Studio – Broadcasting Software
- main.go – Owncast Source (Command-Line Flags)
- defaults.go – Owncast Default Configuration Values
- Owncast FAQ
Conclusion
Owncast does one thing and it does it without asking for your audience data. It is a live streaming server you run yourself, with a web player and chat built in, and it fits in a single Docker container. Two ports, one volume, and a few minutes of OBS configuration is the entire deployment surface.
The real value of Owncast is not technical, it is structural. When you stream to Twitch or YouTube, the platform owns the relationship with your viewers. They get the analytics, they run the ads, they decide what appears in the sidebar, and they control whether your VODs stay up. When you stream to your own Owncast server, you own that relationship. You decide what the page looks like, whether there are ads, how chat moderation works, and who gets access.
The trade-off is bandwidth and server resources. Serving video to dozens or hundreds of simultaneous viewers requires a real internet connection and enough CPU headroom for transcoding. Offloading video segments to S3-compatible storage shifts the bandwidth burden to a CDN-capable provider and is a practical step for scaling beyond what a single VPS can handle. But for many streamers, a mid-range VPS handles a small-to-medium audience without breaking a sweat.
If you have been thinking about stepping away from platform-controlled live streaming, Owncast in Docker is one of the fastest paths from idea to first broadcast.
FAQ
What is Owncast?
Owncast is a free, open-source, self-hosted live video streaming and chat server. It takes an RTMP video feed from broadcasting software like OBS, transcodes it into HLS for playback, and serves a complete web interface with a real-time chat alongside the video player.
Which Docker image should I use for Owncast?
Use owncast/owncast:latest on Docker Hub for the latest stable release. For nightly builds with v0.3.0 features such as plugins, use ghcr.io/owncast/owncast:nightly from GitHub Container Registry. The older gabekangas/owncast image still exists but owncast/owncast is the current canonical source.
What ports does Owncast need?
Port 8080 for the web interface, HLS video segments, admin panel, and API. Port 1935 for the RTMP ingest server where your broadcasting software sends the video feed. Both must be published from the container and reachable by their intended audiences.
What are the default Owncast credentials?
The admin username is admin and the default admin password is abc123. The default stream key is also abc123. The admin password and the stream key are separate settings. Change both immediately after your first login through Configuration, then Server Setup in the admin panel.
How do I connect OBS to Owncast?
In OBS go to Settings, then Stream. Set Service to Custom. Set Server to rtmp://your-server-ip:1935/live and Stream Key to the stream key from your Owncast admin panel under Server Setup. If OBS does not have a separate stream key field, append the key to the URL: rtmp://your-server-ip:1935/live/yourstreamkey.
Does Owncast work with streaming software other than OBS?
Yes. Owncast is compatible with any software that outputs RTMP, including Streamlabs, Restream, FFmpeg directly, and mobile streaming apps that support custom RTMP servers. As long as the software can push an RTMP stream to a custom URL, it works with Owncast.
Where is configuration stored in Owncast?
Nearly all configuration lives in an SQLite database at /app/data/owncast.db inside the container. This includes video quality settings, stream keys, admin credentials, chat moderation rules, notification settings, Fediverse configuration, and page customization. The twelve command-line flags control only runtime behavior such as ports and logging.
What happens if I do not bind the /app/data volume?
Without a volume binding, the SQLite database, automatic backups, and all configuration live inside the container’s ephemeral filesystem. Running docker compose down destroys everything. You lose your stream key, admin password, video settings, chat history, follower records, and page customization. Always bind /app/data to a host directory.
Can I change the web server port from 8080?
Yes. Use the --webserverport flag and update your Docker port mapping to match. For example, --webserverport=9000 combined with "9000:9000" in the ports section. The internal port Owncast listens on and the published host port must agree, otherwise the service is unreachable.
Can I change the RTMP port from 1935?
Yes. Use the --rtmpport flag and update the Docker port mapping. Keep in mind that 1935 is the standard RTMP port expected by broadcasting software, so if you change it you must also update the server address in OBS or your broadcasting tool.
Does Owncast support S3-compatible storage?
Yes. In the admin panel under Server Setup, you can configure an S3-compatible storage backend. Owncast supports Amazon S3, MinIO, Backblaze B2, DigitalOcean Spaces, and any other provider with an S3-compatible API. When S3 storage is active, video segments are uploaded to the bucket instead of being served from the Owncast server directly, offloading bandwidth and storage.
Can Owncast integrate with Mastodon or the Fediverse?
Yes. Owncast is a full ActivityPub server. When you enable the Fediverse features in the admin and set your Server URL, your stream gets an ActivityPub handle like @streamer@owncast.example.com. Mastodon users can follow that handle, see go-live announcements, and participate in your chat through their Mastodon client.
How do I notify viewers when I go live?
Owncast supports browser push notifications for viewers who opt in, Discord webhook notifications that post a message to a channel when you go live, and Fediverse follower announcements that appear in your followers’ Mastodon timelines. You can also set up custom webhooks to notify any external service. All notification channels are configured under Configuration, then Notifications in the admin.
Does Owncast have chat moderation tools?
Yes. The admin panel includes chat moderation with name-based and message-based filtering. You can block specific words, ban users by name or IP, and optionally require that chat participants authenticate. Chat settings are under Configuration, then Chat in the admin.
Can I customize the appearance of my Owncast page?
Yes. Under Configuration, then General, you can set the server name, logo, summary, tags, and page content written in Markdown. The Appearance section lets you change colors, add custom CSS, and inject custom JavaScript. The page is fully customizable without rebuilding the container.
How many video quality variants can I configure?
You can configure multiple stream output variants through the admin under Configuration, then Video. Each variant has its own resolution, video bitrate, framerate, and CPU usage level. The default is a single variant at 1200 kbps and 24 fps. Viewers automatically receive the highest-quality variant their connection supports.
Does Owncast support hardware-accelerated transcoding?
Owncast uses ffmpeg for transcoding, which is included in the Docker image. Hardware acceleration depends on ffmpeg having access to the GPU. You can configure the FFmpeg path and custom encoding flags through the admin panel under Server Setup. For NVIDIA GPUs in Docker, you would need the nvidia-container-toolkit and GPU device mounts in your Compose file.
Can I embed the Owncast player on another website?
Yes. Owncast provides an embeddable iframe player. Use <iframe src="http://your-server:8080/embed/video"></iframe> to embed just the video player, or http://your-server:8080/embed/chat to embed chat. The full page with both is at the root URL.
Does Owncast support plugins?
Kind of. Plugins are a v0.3.0 feature currently available in the ghcr.io/owncast/owncast:nightly image. Plugins can modify the page, add overlays, integrate external services, and inject custom UI. They are written in JavaScript and installed through the admin panel. The stable owncast/owncast:latest image does not include plugin support yet.
Can I run Owncast on a small VPS?
Yes. Owncast can run on a VPS with 1-2 vCPUs and 1-2 GB of RAM for small audiences. Transcoding is the main CPU cost. With a single video quality variant and a handful of viewers, a budget VPS handles it. Larger audiences or multiple quality variants benefit from more CPU cores and higher bandwidth.
How do I list my stream in the Owncast Directory?
Enable the directory option in the admin panel under Configuration, then General. When enabled and your server is reachable at a public URL, your stream appears in the Owncast Directory. This is optional and off by default.
How do I back up my Owncast data?
Owncast writes automatic periodic backups of the SQLite database to /app/data/backup inside the container. With the volume bound to ./data, these backups are on the host filesystem. For an additional manual backup, copy ./data/owncast.db and the ./data/backup folder to another location. You can restore a backup by starting Owncast with the --restoreDatabase flag pointing to a backup file.
What is the difference between the admin password and the stream key?
The admin password logs you into /admin to configure Owncast. The stream key authorizes your broadcasting software to push video to the RTMP server. They are independent settings. Both default to abc123, which is a reason to change both immediately.
Does Owncast support recording streams for later playback?
Owncast does not include a built-in VOD recording feature. It is a live-streaming server, not a video archive. If you need recordings, configure your broadcasting software such as OBS to record locally while streaming, or use a separate tool that captures the RTMP feed and saves it to disk.
Is RTMP traffic encrypted?
No. RTMP is an unencrypted protocol. The video feed between your broadcasting software and Owncast travels in cleartext over the network. If you stream over the open internet, consider running OBS and Owncast on the same machine, using a VPN tunnel, or connecting through WireGuard so the RTMP traffic stays inside an encrypted tunnel.
Can I run multiple Owncast instances on one server?
Yes. Owncast is designed as a single-user system, but you can run multiple instances on the same host. Assign each its own project directory, unique host ports, and distinct data volume. Use different external port numbers such as 8080, 8081, 8082 for the web interfaces and 1935, 1936, 1937 for the RTMP ports. Each instance is fully independent.
How do I upgrade Owncast to a newer version?
Run docker compose pull owncast to fetch the latest image, then docker compose up -d to recreate the container. The database in the bound data volume is preserved and Owncast applies any schema migrations automatically at startup. Check the release notes before upgrading a production instance.
Does Owncast work behind a reverse proxy?
Yes. Owncast works behind Nginx, Caddy, Traefik, and other reverse proxies. The important points are to forward WebSocket connections for chat to work, set the correct Server URL in the admin so Owncast generates correct links and Fediverse handles, and ensure the proxy is not buffering HLS segments in a way that introduces playback latency.
What license is Owncast released under?
Owncast is released under the MIT License, a permissive open-source license that allows commercial use, modification, distribution, and private use with very few restrictions.
Can Owncast handle hundreds of simultaneous viewers?
It depends on your server bandwidth, CPU, and whether you offload video segments to S3-compatible storage. The Owncast server itself is lightweight in Go, but serving HLS segments to hundreds of viewers consumes significant outgoing bandwidth. Using S3-compatible storage or a CDN in front of the HLS output shifts that burden off your server and allows scaling to larger audiences.
Does Owncast support custom emoji in chat?
Yes. You can upload custom emoji through the admin panel under Chat, then Emojis. Custom emoji are available to all chat participants and appear in the emoji picker alongside the built-in set.
How does Owncast handle viewer privacy?
Because Owncast is self-hosted, viewer data stays on your server. There are no third-party analytics services, tracking scripts, or advertising networks injected into the page. The built-in metrics show viewer counts and chat activity without collecting personal data or sharing it with external services. You control the entire data pipeline.
