Owncast can run on Ubuntu as a self-hosted RTMP ingest and viewing service, but Owncast by itself does not send a broadcast to YouTube. To make a continuous YouTube stream, you need a separate playout process for your local video files and a separately configured encoder or relay that publishes to YouTube.
This guide uses Owncast’s documented Docker deployment as the ingest side and the official example’s ffplayout and local-file framing for scheduled media. It is not a guide to importing a YouTube playlist: files are played from your own storage, and the path from Owncast to YouTube must be treated as a separate, explicitly verified step.
Understand Owncast and the separate playout process
Think of this setup as distinct jobs rather than one application doing everything. Owncast accepts an RTMP broadcast and provides its own viewing and administration interface. A playout process selects and plays the local media. A further encoder or relay is needed if the intended destination is YouTube.
In the documented Owncast setup, compatible broadcasting software publishes to an RTMP endpoint ending in /live/<stream-key>. That is a feed to Owncast. YouTube’s Live Control Room supplies a different stream URL and key for a feed to YouTube. The Owncast broadcasting guide and YouTube encoder setup documentation describe separate destinations and credentials; neither fact makes an Owncast installation an automatic YouTube relay.
For local-file playout, ffplayout is the relevant separate process in the official example’s approach: it plays files from a local media collection and feeds a broadcast output. Before relying on any particular bridge between a playout output, Owncast, and YouTube, verify its exact input and output path, how it uses or avoids re-encoding, how reconnects work, and what restarts it after a failure. Do not assume that selecting Owncast in one setting will also publish to YouTube.
This separation matters overnight. A working web page only shows that Owncast is answering requests. It does not prove that the file playlist is advancing, that RTMP ingest is healthy, or that YouTube is receiving video. Give each process a clear role and a separate health check, and test the full route before treating it as a 24/7 channel.
Prepare persistent data and credentials
Start with persistent storage for Owncast’s configuration and media, rather than keeping important state in a disposable container layer. Docker deployments commonly mount host directories into the container. Use directories whose purpose is clear, and confirm the container can read the media it needs and write the configuration and state it must retain after a restart.
Before downloading or running an installer, check the official deployment instructions for the current image, Compose example, and volume paths. Owncast’s installation documentation covers its supported deployment approaches. Do not copy a Compose fragment from an unrelated version without checking whether its image name, paths, or configuration options still match the release you are using.
Treat the Owncast administrator password and stream key as separate secrets. The project documentation identifies defaults for a new installation; change them promptly and never publish them in a Compose file, a screenshot, or a public repository. Use unique values, store them somewhere you can retrieve securely, and restrict access to the Ubuntu account and host directories that hold them.
Persisting data also means planning backups. A container restart should not erase your configuration, but a host disk failure can. Keep a separate copy of the files and settings you cannot easily recreate, and confirm that your backup method does not expose credentials. Your source video collection may be large, so decide which material must be backed up and which can be re-copied from an original archive.
For a 24-hour channel, media organisation is part of operations. Use filenames and folders that make it possible to see which files are intended for rotation, and check that the container or playout process sees the same paths you see on the host. If a playlist points at a path that is not mounted into its process, the service can be running while the output is silent.
Map the web and RTMP ports
Owncast’s documented defaults are TCP port 8080 for the web interface and TCP port 1935 for RTMP ingest. In Docker Compose, publishing a host port to the corresponding container port makes that service reachable through the Ubuntu host. Keep the mapping explicit so you can compare it with firewall rules and the URL you plan to use.
| Purpose | Default port | What it is for | Check before opening |
|---|---|---|---|
| Owncast web interface | 8080 | Viewer and administration pages | Decide who should be able to reach the page; use appropriate access controls for administration |
| RTMP ingest | 1935 | A broadcaster or playout output sends video into Owncast | Confirm the publishing process uses the host name and port that are actually reachable |
The Compose port mapping alone does not open a port to the public internet. Check both Ubuntu’s host firewall and the cloud provider’s network firewall, if present. Likewise, a public firewall rule does not help if Compose is bound only to a local interface or if the service is listening on a different port.
Open only the ports the chosen arrangement needs. The web port may be needed for viewers and administration, while RTMP ingest must be reachable from the sending process. If your playout and Owncast run on the same host, you may be able to keep the ingest path private to that host rather than exposing it publicly. Confirm the actual network path before tightening rules, since a blocked port looks much like a failed encoder.
Use the RTMP endpoint documented by Owncast, with your server address, /live path, and your own stream key. Keep the key out of shell history and logs where practical. For YouTube, use the separate stream URL and key shown in Live Control Room; do not substitute Owncast’s port or key for YouTube’s destination details.
Configure the Compose service and restart policy
A Compose service gives you a repeatable way to declare the Owncast container, its published ports, persistent mounts, and restart behaviour. The important operational point is that a container restart policy applies to the container process; it does not automatically supervise a separate playout container, a host-level encoder, or a YouTube session unless those are also configured and monitored.
Use the official Owncast example as the source of truth for the image and service settings. In your Compose file, review the port mappings for 8080 and 1935, mount persistent host directories for the required state and media, and select a restart policy suited to a service that should return after a host reboot or process exit. Avoid adding options you do not understand just to make the file appear more complete.
Keep the Compose file readable. Use named environment variables or a protected environment file only where the official configuration supports them, and set restrictive permissions on files containing secrets. Do not check private credentials into a public code repository. If you change a setting, make a note of why, so that a future restart or update does not depend on remembering an undocumented edit.
A restart policy is useful, but it is not a recovery plan for every failure. It cannot restore a broken network connection, repair a full disk, replace missing media, or guarantee that a cloud provider remains available. It can also repeatedly restart a process that has a persistent configuration error. Read the logs after a restart instead of assuming that an automatic retry means the stream has recovered.
The Compose service should be only one part of your runbook. Write down how to check the Owncast container, how to inspect its logs, where the persistent data lives, how to update the image deliberately, and how to restore a backup. For the playout and YouTube-publishing components, document their own launch and restart methods separately. A system that works only while a terminal window remains open is not yet prepared for unattended operation.
Start Owncast and confirm it is running
From the directory containing the Compose file, start the service using the Compose command supported by your installed Docker version. Then check the service state and recent logs before opening a browser. The exact command can differ with Docker Compose versions, so follow the syntax in the installed tool’s help if a command from an older guide does not work.
Open the web interface using the Ubuntu host address and mapped web port. Confirm that the page loads, then sign in to administration using the credentials you configured. A page that loads is a useful first check, but it only confirms the web-facing service. It does not verify RTMP ingest or outbound YouTube delivery.
Next, test an RTMP publisher using a short, non-critical source. Enter the Owncast endpoint and key in the sending software, publish, and check Owncast’s status or viewer output. If it fails, verify the endpoint path, key, port mapping, host firewall, provider firewall, and whether the sending process can reach the server. Change one variable at a time rather than rotating credentials and network settings simultaneously.
Check logs on both sides of the connection. The Owncast logs can show whether it receives a publishing attempt; the sending process can show whether it can establish a connection and maintain a feed. If the connection starts and then stops, note when it happened and what each process reported. That gives you evidence to distinguish a network interruption from a file-playout or encoding problem.
For a 24/7 service, test the behaviour you actually expect: container restart, host reboot, and a brief interruption of the feed. Confirm which components return on their own and which require intervention. Do this before relying on the stream overnight. A rehearsal also gives you a chance to verify that media resumes sensibly rather than beginning with a blank screen or a file that was only intended for testing.
Feed Owncast from local files with a playout process
Owncast is not a file playlist manager. The official example’s local-file and ffplayout framing is useful because it makes the division clear: ffplayout handles scheduled local media, while Owncast receives the resulting broadcast. The files live in storage accessible to the playout process, and the process must be configured to produce a compatible stream and point it at the intended RTMP destination.
Make the media directory visible to the process that reads the files. If ffplayout runs in its own container, it needs its own mount; a volume mounted into Owncast is not automatically visible to a second container. Check file permissions, available disk space, and the playlist or schedule syntax using a small test collection before loading a full day’s rotation.
Do not confuse local-file playout with importing a YouTube playlist. A YouTube playlist is a list of hosted videos, not a local media directory, and Owncast’s documented Docker service does not fetch or loop that playlist. For local-file playout, use media that you have stored and configured for the playout process. If you want to stream material hosted on YouTube, that is a different workflow and should not be represented as this setup.
The output path requires care. The playout process may publish to Owncast’s RTMP ingest endpoint, while a separate encoder or relay must publish to YouTube if YouTube is the final destination. These are not interchangeable outputs. The reviewed Owncast and YouTube documentation establish how each service accepts a feed, but do not, by themselves, establish a complete bridge between the two. Verify the bridge you choose end to end and account for its credentials, reconnect behaviour, and supervision.
A YouTube encoder should use the destination information from Live Control Room. YouTube’s published encoder guidance recommends constant bitrate, a two-second keyframe interval with a maximum of four seconds, and testing with audio and video similar to the intended broadcast. It also recommends RTMPS for delivery into YouTube. Read the current YouTube live encoder settings and test stream health in Live Control Room rather than assuming that a healthy Owncast preview means YouTube is receiving correctly.
For a local-file channel, the content schedule is as important as the technical loop. Decide how the playlist advances after the final file, how missing or unreadable files are handled, and whether a restart resumes the current item or begins again. Put a short test playlist through a full cycle first. A devotional channel, for example, might use a local sequence of bhajans and announcement clips; it should still have an explicit plan for what happens if one file is missing or the audio track cannot be read.
If your main requirement is to upload a file once and leave your own computer switched off, a hosted upload-to-stream workflow removes the need to maintain a local Ubuntu host and its separate playout process; StreamNeo is built for that specific operational pain, rather than for self-hosted Owncast administration. If you keep the Ubuntu route, choose it because you want control of the host, local media path, and operating details, and are prepared to maintain each component.
Verify the stream and secure administration
Check the complete path, not just one green status indicator. Confirm that the local playout process is advancing through the intended files, that Owncast is receiving the broadcast, and that the separately configured YouTube encoder or relay is publishing to the correct YouTube event. Watch the YouTube preview and stream health, listen for audio, and check that the picture does not freeze when one local file ends and another begins.
YouTube recommends testing before the live event and monitoring stream health. Use the actual intended resolution, frame rate, audio, and encoding settings in the rehearsal, rather than a minimal desktop test that says little about the real load. You can find more on entering destination credentials in this FFmpeg stream-key guide, and a useful continuous playlist workflow from Google Cloud is relevant when comparing a different playout architecture. Those are different approaches, not proof that Owncast imports playlists.
Plan bandwidth for viewers as well as for the publishing feed. Owncast’s bandwidth documentation gives an illustrative calculation: at 4,000 kbps and 25 viewers, its example estimates 100 Mbps of peak outbound throughput and 90 GB transferred over two hours. Those figures are Owncast’s worked example, not a universal hosting requirement or a promise about your own traffic. More viewers and longer viewing time change the total materially; review the Owncast bandwidth notes and compare them with your host’s sustained transfer terms.
A full-day channel also needs an archive plan. YouTube says streams under 12 hours are automatically archived; do not assume from that statement that a longer continuous stream will be preserved as one permanent archive. Check current Live Control Room behaviour for your intended session length. If you need reliable archive segments, plan for session boundaries and verify the resulting recordings rather than discovering the limits after a long broadcast.
For administration, replace defaults, use a unique password and key, and restrict who can reach the admin interface. Keep credentials private and rotate them if they appear in a public log, screenshot, or repository. Do not expose more ports than the stream and viewers need. If Owncast and the playout process share a host, consider whether ingest can remain on a private network path while the public web interface serves viewers.
A restart policy and monitoring reduce some manual work but cannot promise uninterrupted service. Power, internet access, storage, host maintenance, and provider availability remain separate dependencies. If you run the server on physical hardware, a UPS may help with brief power interruptions; it does not address an ISP outage or replace backups. With a hosted server, compare bandwidth allowance, control of ports, region, billing exposure, and who maintains Ubuntu before choosing a provider.
A reliable routine includes checking logs after updates, confirming free disk space, testing recovery from a reboot, and periodically validating that the YouTube destination is still the intended one. For a channel with a published schedule, this 24/7 stream scheduling guide can help make operational checks part of the viewer-facing plan.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does installing Owncast on Ubuntu create a YouTube live stream?
No. Owncast accepts an incoming RTMP broadcast and provides its own viewing service. YouTube requires its own stream URL and key, configured in a separate encoder or verified relay; Owncast alone does not publish to YouTube.
Can Owncast loop a YouTube playlist?
This Docker setup does not import or loop a YouTube playlist. The local-file approach uses files accessible to a separate playout process such as the official example’s ffplayout framing. A playlist of hosted YouTube videos is a different workflow.
Will a Compose restart policy keep every part of the channel running?
It can restart the Owncast container according to its policy, but it does not automatically supervise every separate playout or YouTube-publishing process. Configure and test recovery for each component, and remember that a process restart cannot fix a failed network, full disk, or unavailable host.
What should I verify before leaving the stream unattended?
Rehearse the full route: local files to playout, ingest into Owncast if used, and the separate publishing path to YouTube. Check picture, audio, file transitions, logs, credentials, firewall reachability, and what happens after a restart. Verify YouTube stream health in Live Control Room and review the current archiving behaviour for the session length you intend.