A 24/7 YouTube stream from Oracle Cloud Infrastructure (OCI) needs more than an encoder command: you provision a VM and network, prepare a looping media source, send it to YouTube Live, and supervise the process. The commands and service unit below are illustrative patterns, not an officially tested end-to-end OCI recipe; validate them on your chosen Ubuntu release and test a representative stream before relying on them.
Treat “24/7” as the goal of continuous live output, not a promise of one complete YouTube recording. YouTube says a stream longer than 12 hours may not be captured at all, and DVR rewind may also be limited or unavailable beyond that point. If you need an archive, plan a separate local recording and enough storage for it.
What the setup includes
The path is: an OCI Ubuntu VM with suitable compute, storage and network access; an encoder such as FFmpeg reading your media; YouTube Studio’s current ingest URL and stream key; and a supervisor that restarts a failed encoder process and keeps logs. You still need to check YouTube’s live health and the VM itself. Restarting a process is not the same as guaranteeing an uninterrupted broadcast.
There are two practical approaches. Running FFmpeg on your own VM gives you control over the media path and process configuration, but leaves you responsible for operating-system updates, storage, network capacity, permissions, and recovery checks. A managed workflow may suit you better if maintaining a VM is the part you want to avoid: StreamNeo accepts an uploaded video and YouTube stream key, then runs the broadcast with your computer switched off. It is YouTube-only; it does not remove the need to prepare suitable content or verify the channel’s live status.
Before provisioning, decide what “always on” means for your channel. A devotional station might loop a long programme, while a local news channel may need scheduled source changes and a person who can review updates. A single file repeated forever is operationally simpler, but can become stale or produce an obvious loop. For recorded services, see how to stream church sermons around the clock in India; the content and rights questions matter as much as the encoder.
Also decide whether you need a YouTube archive, a private copy, or both. YouTube’s automatic archive behaviour is not a substitute for your own retention plan. If local recordings are required, test that recording does not exhaust the VM’s boot volume, and choose where completed files will be kept and rotated.
Provision an Ubuntu VM on OCI
OCI offers Ubuntu platform images, but an image is only one part of a working instance. Compute shape, boot storage, VCN and subnet configuration, routing, public access or a bastion, and SSH access all need deliberate setup. Start with OCI’s Ubuntu platform image guidance, then check compute shape capacity in the intended region and availability domain before planning around a particular shape. Availability can vary; do not assume a free-tier size will be available or sustain your chosen encoder and network load.
Select compute based on what you will actually encode. Sending a pre-encoded file without changing its video stream can require less CPU than resizing or re-encoding it, but that is not a guarantee for every file or VM. Audio processing, resolution changes and simultaneous local recording add work. Test with the actual media and observe CPU and memory rather than inferring capacity from a shape name.
Plan storage separately for the operating system, media files, logs and any local recordings. A short test clip and a large archive have very different storage needs. Check free space before enabling a recording job, and decide how old recordings will be removed or moved. Avoid placing the only copy of important source media on the same disk you expect to fill with output recordings.
For networking, allow only the access you need. SSH should be restricted to your administration path where possible; avoid opening incoming services simply because the stream is public. The encoder normally sends outbound traffic to YouTube. OCI notes that a public IP is needed for direct Internet communication from outside the VCN, while SSH can instead be reached through a bastion. Review the OCI networking and instance access documentation for the design you choose, and test actual outbound connectivity from the VM.
Connect to the instance, then update package metadata and install FFmpeg using the package sources appropriate to that Ubuntu image. This is a generic illustrative pattern, not an OCI-certified package version:
sudo apt update
sudo apt install ffmpeg
ffmpeg -version
Confirm that the package exists for your release and inspect its available codecs and protocols. If you need a newer build or special codec support, make that a documented deployment choice rather than copying an unverified repository command. A headless FFmpeg workflow does not require a desktop environment; OBS’s graphical interface is a different operating choice, not a prerequisite for command-line encoding.
Prepare media and an encoder
Place media in a stable directory and make its ownership and read permissions explicit. For example, /srv/live/source.mp4 is easier to reason about than a file in an interactive user’s Downloads folder. The service should read the file as its own unprivileged account, not depend on a shell session or a mounted path that disappears after reboot.
Before streaming, inspect the file and play it locally or in a test broadcast. Confirm that its picture, soundtrack, duration, orientation, and frame rate are suitable. A file can decode successfully while still having silent audio, black frames, or an unintended ending. If you are looping a playlist or combining several clips, check transition behaviour and confirm the encoder reaches the next item after the current one finishes.
A simple FFmpeg loop can be written as an input option, but test the exact file and FFmpeg build first. A representative command shape is:
ffmpeg -re -stream_loop -1 -i /srv/live/source.mp4 \
-c:v copy -c:a aac -b:a 128k \
-f flv "rtmps://CURRENT_INGEST_URL/YOUR_STREAM_KEY"
This is illustrative only. -stream_loop -1 asks FFmpeg to repeat an input, while -re reads at its media rate rather than sending the file as fast as possible. Copying the video stream avoids video re-encoding only when the source codec, timestamps and stream properties are acceptable for the intended output. Audio conversion here is an example, not a universal fix. Review FFmpeg’s output for decoding, timestamp or muxing errors, and test for a full loop boundary. For OBS users, checking why a media source does not loop is a separate troubleshooting path.
Do not put an actual key in a command saved to shell history, a script committed to source control, a screenshot, or a log. The command above uses conspicuous placeholders and must not be pasted unchanged as a working command. The next section covers keeping the key out of the command line; the precise secret injection method depends on your implementation.
Configure YouTube Live ingest securely
Open YouTube Studio and the Live Control Room, enable live streaming in advance, and create or select the stream you intend to use. YouTube’s live streaming activation guidance says first-time activation can take up to 24 hours, so do not leave setup until the intended broadcast start. Copy the server URL and stream key shown for that stream. They are separate values: the URL identifies the ingest endpoint, while the key associates the incoming feed with your YouTube stream.
Prefer RTMPS when the current YouTube settings offer it. YouTube Help recommends RTMPS, a secure extension to RTMP. Use the exact URL displayed in Studio rather than relying on a hard-coded endpoint in an old tutorial; the endpoint shown there is the relevant one for your current configuration. Confirm the stream is receiving data in Live Control Room before treating the setup as ready.
YouTube describes stream keys as credentials, comparable to a password and address. Store the key in a file readable only by the service account, or use another secret mechanism appropriate to your operating setup. Do not embed it in a broadly readable unit file, share it in support requests, or print it as part of diagnostic output. A file-based approach still requires careful permissions and backups: root-only access may be too restrictive if the service runs under a dedicated account, while world-readable permissions expose the credential to every local user.
If a key has been exposed, reset it in YouTube Studio and update the service’s protected configuration. Also consider process inspection: command-line arguments may be visible to other local users or administrators. A credential stored securely can still leak if expanded into a command argument or written to logs. The example later uses a protected environment file as an illustration, but validate how your FFmpeg invocation and systemd version handle the secret. YouTube’s stream settings help explains managing stream settings and keys.
Choose conservative encoder settings
Begin with the simplest output that your media and VM can sustain. YouTube’s current encoder settings guidance recommends CBR, a two-second keyframe interval (not more than four seconds), and gives H.264 bitrate recommendations for particular resolutions and frame rates. These are ingest recommendations, not evidence that a chosen OCI shape can encode them continuously.
| Output example | YouTube-recommended H.264 video bitrate | Practical consideration |
|---|---|---|
| 1080p at 30 fps | 5 Mbps | More pixels to encode or send than a lower-resolution output |
| 720p at 30 fps | 6 Mbps | Follow YouTube’s stated recommendation even though the resolution is lower |
| Stereo audio | 128 Kbps | YouTube recommends AAC or MP3 audio; check source audio and output compatibility |
The figures come from YouTube’s encoder guidance and are not a quality guarantee. The 720p recommendation is not lower than the 1080p recommendation in this table; do not assume a bitrate solely from resolution. If you do not need to re-encode, the source’s existing video bitrate and codec affect both network use and compatibility. If you do re-encode, test the resulting picture, sound, CPU use and stream health before leaving the process unattended.
For a basic H.264 encode, an illustrative FFmpeg option pattern may include -c:v libx264 -preset veryfast -tune zerolatency -b:v 5M -maxrate 5M -bufsize 10M -r 30 -g 60. These values are a starting example for a 30 fps output, not a tested OCI recipe or a universal recommendation. A two-second GOP at 30 fps corresponds to 60 frames; if you change frame rate, the keyframe interval needs to be adjusted accordingly. Check encoder options and output behaviour in the installed FFmpeg build. -preset affects the CPU/quality trade-off, and a preset that is too demanding may overload a small VM.
Network capacity should be considered in the outbound direction. YouTube recommends 20% headroom above the total stream bitrate, counting primary and backup feeds. For a single 5 Mbps feed, applying that margin means at least 6 Mbps usable upload capacity for the stream; shared traffic or bitrate variation calls for additional room. A speed test at one moment does not prove sustained capacity throughout the day. Watch for dropped frames and YouTube health messages while testing, and reconsider resolution or bitrate if the uplink is inconsistent.
Avoid adding a backup feed unless you have a reason and account for its bandwidth in the total. A secondary feed consumes outbound capacity as well as resources, and two feeds do not eliminate failures in source media, VM access or platform state. For a one-file station, stable playback at a modest setting is often easier to maintain than a complicated setup whose resource use has never been measured on the selected instance.
Create an illustrative supervised service
A service manager can start the encoder at boot and attempt a restart after an unexpected exit. The unit below is an illustrative systemd pattern only, not an officially supplied or tested OCI/FFmpeg service. Validate unit syntax, account names, paths, permissions and environment-file behaviour on the target Ubuntu release before enabling it. Use a dedicated unprivileged account such as stream, created and configured according to your administration policy.
Keep the secret in a protected file rather than in the unit. For example, /etc/stream/encoder.env could contain a STREAM_KEY variable and be readable only by root and the service account. The directory and file modes must permit the service to read the value without making it broadly accessible. Do not put the key itself in the following sample. Environment variables can be exposed through diagnostics in some circumstances, so assess whether this mechanism meets your threat model; a more controlled secret mechanism may be preferable.
# Illustrative only: validate on the target Ubuntu release.
[Unit]
Description=YouTube live encoder
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=stream
Group=stream
WorkingDirectory=/srv/live
EnvironmentFile=/etc/stream/encoder.env
ExecStart=/usr/bin/ffmpeg -re -stream_loop -1 -i /srv/live/source.mp4 -c:v copy -c:a aac -b:a 128k -f flv rtmps://CURRENT_INGEST_URL/${STREAM_KEY}
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
This sample makes assumptions that need checking: FFmpeg’s executable path, support for the chosen protocol and codecs, environment substitution in the unit’s command, the ingest URL, and suitability of the source file. systemd does not make a bad stream correct merely by restarting it. A malformed URL, unreadable file or unsupported codec may fail repeatedly; use a test service or foreground command first and inspect the logs before enabling startup.
When the file is validated, the general control pattern is to reload unit definitions, enable the service for boot and start it, then inspect its status. These are ordinary systemd operations, but check their behaviour on the installed release and substitute your actual unit name:
sudo systemctl daemon-reload
sudo systemctl enable --now youtube-encoder.service
sudo systemctl status youtube-encoder.service
Before reboot testing, ensure you can recover access if the unit loops or consumes resources. Test a controlled stop and start, confirm the service user can read the media, and check whether an operator can change the source without exposing credentials. If you need playlists, file changes or scheduled content, implement and test that workflow separately instead of assuming one source-file command covers it.
Monitor failures and recovery
Set up checks at three levels: systemd process state, the VM’s resource and network condition, and YouTube’s Live Control Room health. A service can be active while YouTube is not receiving a healthy picture or sound. Conversely, YouTube may show ingest while the process is about to fail at the end of a file. Confirm the content itself and the platform’s status rather than relying on one green indicator.
Use systemctl status for a current summary and journalctl -u youtube-encoder.service to review recent service output. Limit log access and retention appropriately; a diagnostic record should not contain the stream key. Look for repeated restarts, permission errors, decode failures, timestamp warnings, CPU saturation, and storage pressure. Restart loops may make the service appear to be trying, but they can hide a persistent configuration fault unless someone reviews the logs.
Recovery depends on what failed. If FFmpeg exited because the file was missing, restore the file and verify its permissions before restarting. If it failed during a network interruption, systemd may relaunch the process, but YouTube’s stream state and viewer experience can still be affected. If the VM reboots or is subject to maintenance, confirm the service starts and reconnects as expected. No gathered OCI or YouTube documentation quantifies continuity for a particular shape, so do not present this setup as guaranteed uptime.
Make a written runbook with the ingest stream name, where the protected key is managed (not the key itself), service name, media path, log command, and steps to stop or replace the source. Keep a separate, controlled route for rotating the key. Have someone test that runbook while the channel is not relying on the broadcast, then carry out a representative live test long enough to observe media looping, resource use and YouTube health. The content-specific guide to streaming a Tamil devotional radio station can help frame the programming side, but it does not replace validating this VM’s behaviour.
For long-term operation, decide how you will notice a failure when nobody is watching. Check notifications and monitoring arrangements periodically, and assign an owner who can act on an alert. Test recovery after a deliberate service stop and a VM reboot; those tests establish what your configuration does, not a guarantee about future network or platform events. Keep source media and any local archive backed up independently of the instance.
Archive planning and practical trade-offs
A 24-hour output target should not be confused with a 24-hour archive. YouTube’s archive guidance says streams exceeding 12 hours may not be captured at all; DVR rewind can also be limited or unavailable beyond 12 hours. A single continuously running session therefore cannot be relied on to create one complete replay covering every hour. Check YouTube’s current archive live streams guidance before you design a workflow around replays.
If you need an archive, record locally or create a separate recording workflow, then confirm that the resulting files are usable and have been copied somewhere safe. Recording on the same VM can consume substantial storage over time and may compete for disk I/O. Estimate from your actual encoded bitrate and test duration rather than relying on a generic storage claim. Set a retention or rotation policy, and alert before the volume fills. A local recording is only useful if the disk survives the failure you are trying to protect against, so consider a separate backup location.
You may also split programming into planned sessions if the channel needs distinct replays or more manageable content windows. That changes how the live session starts and ends, and may affect viewers, notifications and scheduled streams; test the approach in YouTube Studio. It does not turn platform archive behaviour into a guarantee. Keep the distinction clear for viewers: live continuity and replay availability are different outcomes.
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 OCI provide an official command sequence for this whole setup?
The OCI and YouTube documentation cited here covers platform images, capacity, ingest and encoder guidance, but it does not certify this combined Ubuntu, FFmpeg and systemd recipe. Treat commands and unit configuration as examples, validate them on the selected Ubuntu release, and test the actual media and stream before depending on them.
How do I keep an FFmpeg stream running after an exit?
A systemd service with restart-on-failure can relaunch a process after some failures. It cannot correct a bad file, broken credentials or a YouTube-side issue, so inspect logs and confirm healthy ingest in Live Control Room after recovery.
Will YouTube archive a 24/7 stream as one complete replay?
Do not rely on that. YouTube says streams over 12 hours may not be captured at all, and DVR may be limited or unavailable beyond that duration. Keep a separate local recording if a complete archive matters, and check current YouTube guidance.