A 24/7 YouTube sermon stream on Ubuntu can be run by looping prerecorded media through FFmpeg and letting a systemd service start and restart that process. That supervision does not prove YouTube is receiving healthy video and sound, so you still need to check Studio and plan how sermon archives will be made.
This guide covers a self-hosted setup for a church or volunteer team. It assumes you can use an Ubuntu host that remains powered and connected, and that the sermons and any music or artwork are cleared for the intended broadcast. The FFmpeg command below is an example to adapt, not a tested recipe for every file or installation.
Check YouTube Live eligibility and activation
Before preparing a machine, confirm that the channel can start a live stream. YouTube’s live streaming setup guidance says that first-time activation can take up to 24 hours. Do this ahead of the service or launch date; installing FFmpeg cannot shorten the platform’s activation time.
In YouTube Studio, check the channel’s current live-streaming status and resolve any prompts or restrictions shown there. Eligibility and account status are platform matters and may change, so rely on the current Studio page rather than an old checklist. Do a short private or unlisted test where the channel’s controls allow it, and confirm that the planned operator can see the stream in Studio.
Decide what “24/7” means for your channel. A single continuous event may keep sending a picture, but it is not necessarily the best way to present separate weekly sermons or preserve a complete archive of each one. If you need each service to have its own title, start time and replay, plan separate broadcasts or another recording workflow rather than assuming one endless event will divide itself into useful videos.
Also confirm that the church has permission to rebroadcast the sermon recordings and any included music, slides, photographs or other third-party material. This guide is about technical operation, not ownership or licensing. Keep a record of what the channel is authorised to use and ask the relevant rights holder or adviser when that is unclear.
Prepare sermon media and the Ubuntu host
Choose a host that can remain available when the church office is closed. It might be an existing church-owned Ubuntu machine or an Ubuntu VPS. Compare them on practical factors: who can maintain it, whether upload capacity is predictable, where the media will live, how it behaves during a power or network interruption, and the recurring cost. A VPS may be easier to keep online if local power is unreliable, while an on-site machine can make large media files and local access simpler. Neither choice removes the need to monitor the stream.
The required capacity depends on the actual video, chosen output quality and network. There is no universal CPU or upload-speed figure that fits every sermon loop. Measure outbound capacity at the host, allow room for normal variation and other church traffic, then test the actual encode. A connection that can upload a short sample may still struggle when the host is busy or the service runs overnight.
Keep the sermon file on storage that remains mounted and readable after reboot. Give it a stable path, such as /srv/sermons/sunday-service.mp4, and check its owner and permissions. Avoid a path under a volunteer’s home directory if the service account will not have access. If files are copied in from removable storage, verify the copy and do not depend on a drive that may be unplugged.
You can use ffprobe from the FFmpeg package to inspect streams and duration before writing the service. Check that the file has the expected picture and audio, and listen to its beginning and end. A long silent tail, wrong language track or abrupt ending can be faithfully looped all night by a technically correct command. For help obtaining spoken words from a sermon for review or captions, see how to get a transcript of a YouTube video.
Install FFmpeg from an Ubuntu-supported package source, then check that the installed build recognises the options you plan to use. Package versions and build features differ; use the local ffmpeg -h output and the project’s FFmpeg documentation when an option is unfamiliar. FFmpeg options are position-sensitive: input options belong before the input they affect, while output settings belong before the output destination.
Create the YouTube Live stream and protect its key
In YouTube Studio, create or select the live stream and obtain the ingest URL and stream key for the chosen encoder setup. YouTube’s encoder setup instructions explain how those details are used to connect an encoder. Treat the key like a password: anyone with access to it may be able to send a broadcast to the stream.
Do not paste a real key into a command shown in a guide, a public script repository, a ticket, a screenshot or a chat. A key embedded directly in a service file may be readable by system administrators and can leak through backups or careless sharing. Use a root-owned configuration file with restricted permissions, or another secret-handling method your Ubuntu administrator understands. Do not print the key into logs while troubleshooting.
A simple local arrangement is to keep a private environment file readable only by root and the service account, and refer to it from the systemd unit. For example, /etc/sermon-stream/stream.env might contain a variable holding the key, with ownership and mode restricted using normal Linux permissions. The unit can load it with EnvironmentFile=. Do not include the real value in the unit example, and check that the file is not copied into a public backup or source-control directory.
Keep the ingest URL and key separate in your notes so volunteers can rotate the credential without editing unrelated FFmpeg settings. If a key has been exposed, replace it through YouTube Studio and update the private configuration before restarting the service. A screenshot of an apparently idle service can still reveal credentials if the full command line or environment is visible, so review captures before sharing them.
Configure FFmpeg for the sermon media
For a finite local file that should repeat, FFmpeg provides -stream_loop -1 as an input-loop pattern. It must appear before the corresponding -i. The following is a starting example; adapt the paths, codecs, bitrate, dimensions and frame rate to the media, available CPU and tested upload capacity. It has not been validated against your particular FFmpeg build or YouTube channel.
ffmpeg -re -stream_loop -1 -i /srv/sermons/sunday-service.mp4 \\
-c:v libx264 -preset veryfast -b:v 2500k -maxrate 2500k -bufsize 5000k \\
-r 25 -g 50 -keyint_min 50 -sc_threshold 0 \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv "rtmps://INGEST-URL/APP/STREAM-KEY"
The example’s bitrate and timing values are illustrative starting values, not universal recommendations. Replace the placeholder output with the ingest endpoint and protected key in the way your configuration supports; do not leave a real key in a command history or shareable file. If you use an environment variable, take care that shell expansion and systemd’s environment handling are set up correctly for the chosen method, and do not assume an environment variable is secret from privileged users.
YouTube’s encoder settings guidance recommends constant bitrate, a two-second keyframe interval and says not to exceed four seconds. It also recommends RTMPS for encrypted transport and advises testing and monitoring. Match the keyframe timing to the actual output frame rate rather than copying the example blindly. For a still sermon slide with spoken audio, a modest video setting may be sufficient, but only a listening and viewing test can establish whether text remains readable and sound is clear.
The example re-encodes video and audio. If the source has unusual dimensions, variable frame rate, multiple audio tracks or a codec your build cannot decode, the command may need changes. Do not add -c copy simply to save CPU without confirming that the source format, timestamps and output requirements are compatible. Read the FFmpeg output during a test for decoding errors, dropped frames or repeated warnings, and verify the actual stream in YouTube preview.
If the stream needs a consistent visual when a sermon file ends or fails, solve that deliberately rather than expecting systemd to supply content. A playlist or generated slate can help, but it adds configuration and should be tested at the transition points. A devotional channel using a simple repeated video may also find the planning notes in setting up a 24/7 devotional YouTube live stream with recorded videos in India useful for thinking through content and loop behaviour.
Create and enable the systemd service
Run the stream as a dedicated unprivileged Linux account rather than as root. Give that account read access to the sermon media and any private environment file, and write access only where logs or local recordings require it. Create a system-level unit such as /etc/systemd/system/sermon-stream.service, with a working directory and explicit paths so the service does not depend on an interactive login shell.
A trimmed unit could look like this:
[Unit]
Description=Church sermon YouTube stream
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=sermonstream
Group=sermonstream
WorkingDirectory=/srv/sermons
EnvironmentFile=/etc/sermon-stream/stream.env
ExecStart=/usr/bin/ffmpeg -re -stream_loop -1 -i /srv/sermons/sunday-service.mp4 -c:v libx264 -preset veryfast -b:v 2500k -maxrate 2500k -bufsize 5000k -r 25 -g 50 -keyint_min 50 -sc_threshold 0 -c:a aac -b:a 128k -ar 44100 -f flv ${INGEST_TARGET}
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.target
This illustrates the unit structure, not a drop-in secure command for all systems. In particular, systemd does not interpret shell quoting and variable expansion in the same way as a shell script. Confirm how your chosen configuration passes the complete output URL to FFmpeg; use a carefully permissioned wrapper only if needed, and ensure it does not expose the key. Check the installed systemd manual for exact syntax and consider a local administrator’s review before deploying credentials.
Restart=always and RestartSec= are configurable examples of how systemd can retry a process after it exits. Pick a delay appropriate for your environment rather than assuming immediate repeated retries are always useful. If FFmpeg exits because of a bad path, invalid option or rejected key, restarting the same broken command will not fix the cause. A restart policy is process supervision, not an availability guarantee.
After saving a unit, ask systemd to reload its unit files, then enable it for boot and start it for the current session. These are separate actions: enabling establishes boot behaviour, while starting launches it now. The systemd systemctl documentation describes the commands and unit operations. Keep a note of the unit name and who is responsible for responding to alerts or a failed test.
Check startup, restart behaviour, and logs
Start with a controlled test while someone can inspect both the Ubuntu host and YouTube Studio. Check service status with systemctl status sermon-stream.service, then read recent output with journalctl -u sermon-stream.service. These show local service and process information. They do not show by themselves that YouTube has accepted a usable audio/video signal.
Test boot behaviour during a maintenance window: reboot the host, confirm the service is enabled, and verify that FFmpeg starts and reaches the intended output. Do not use a live Sunday broadcast as the first reboot test. Also test a deliberate process stop or a harmless failure in a separate test environment if you need to understand how the configured restart policy behaves. Avoid experimenting with credentials or unit changes during a live service.
When a process exits, the journal can reveal common local causes: a missing file, permission denial, unsupported encoder, invalid option or a connection error. Correct the underlying issue before judging the restart policy. Repeated retries can fill the journal with the same message and still leave the channel offline. In that case, stop the unit, make the correction, and restart once you have checked the configuration.
A useful handover note should tell another volunteer how to check service status, where to inspect logs, how to verify the preview in Studio and how to contact the person who owns the channel credentials. Do not put the stream key in that note. For a more specific failure mode where FFmpeg appears active despite a disconnect, see why a YouTube encoder can disconnect while FFmpeg keeps running.
The machine’s local checks should be paired with a human check of the broadcast. A service can remain active while its connection is stalled, the wrong input is looping or the platform is not receiving usable media. Similarly, an FFmpeg process can exit briefly, restart successfully and still leave a gap in what viewers saw. Record what was observed in both places when investigating an incident.
Monitor YouTube stream health and archive behaviour
During preflight, open the live control room and confirm that YouTube preview shows the expected picture and sound. Check stream-health indicators and address warnings before relying on the stream. YouTube explicitly advises testing before going live and monitoring stream health; a local active (running) state is not an end-to-end health check. Listen on a separate device if possible, since the encoder’s own output does not reveal what a viewer hears after ingest.
For a first test, use representative sermon material, not just a static colour or a ten-second clip. Listen for the opening, a section with normal speech, any music, and the loop boundary. Look for readable slides, correct orientation, stable audio level and an end-to-start transition that makes sense. Keep a volunteer available to watch Studio during initial operation and again after changes to the file, command or network.
A continuous event also has a separate archive problem. YouTube Help says streams under 12 hours are automatically archived. A single 24/7 event exceeds that stated threshold, so do not assume it will create one complete replay or a tidy archive for each sermon. Plan intentional event boundaries, or maintain a separate local recording and retention process if complete copies matter. YouTube’s Live Streaming API documentation describes archive and DVR-related settings; check current Studio and API behaviour before depending on a particular archive outcome.
If the goal is a distinct replay for every sermon, schedule and end broadcasts at deliberate boundaries, then verify the resulting videos in Studio. If the goal is uninterrupted ambient viewing between services, consider a separate loop or holding visual, while still planning how each sermon is recorded. Guidance on a stream going offline after 12 hours covers the related operational distinction between keeping a channel live and preserving useful events.
A local recording can provide an independent copy, but it brings its own disk-space, rotation, backup and access responsibilities. Decide who checks that recordings exist and when older files are removed or retained. Do a restore or playback check on a sample copy; a recording job that has never been inspected can fail quietly just like an unmonitored stream.
For a church team that does not want an Ubuntu host to run overnight, an uploaded-file cloud stream may remove the need to keep that local FFmpeg process alive. StreamNeo turns an uploaded video into a YouTube-only 24/7 stream, which can remove the specific burden of leaving this Ubuntu machine switched on; YouTube preview and archive planning still remain the channel owner’s responsibility. A self-hosted setup remains appropriate when you want direct control of the host, command and local media workflow.
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 systemd guarantee that viewers will see an uninterrupted sermon stream?
No. systemd can start a process at boot and retry it after it exits, but it cannot establish that YouTube is receiving healthy video and sound or remove every network and platform failure. Check both the service journal and YouTube’s stream-health view.
Will a 24/7 YouTube event archive the whole run?
Do not assume so. YouTube Help says streams under 12 hours are automatically archived, while a continuous 24/7 event is longer than that threshold. Split broadcasts intentionally or keep a separate recording if complete sermon archives are important.
Can I put the stream key in the systemd unit?
Avoid putting a real key in a shareable unit, script, repository or screenshot. Use restricted permissions for credential storage and keep the key out of logs and handover notes. If it is exposed, rotate it in YouTube Studio and update the private configuration.
Should I use a church computer or a VPS?
Choose based on who can maintain it, network and power resilience, media access, storage and cost. An existing church machine may be practical if it stays online and has suitable upload capacity; a VPS may shift some physical upkeep but still requires configuration and monitoring. Test the actual stream from whichever host you choose.