Docker can restart an FFmpeg container after certain failures, but that does not show whether viewers are receiving a healthy YouTube stream. For a church’s always-on channel, you need to configure the YouTube ingest, protect its stream key, choose a tested encoding rate, and check the feed in Live Control Room.
The outline below covers the container and the operating routine around it. A continuous service may still need planned YouTube session boundaries and a person who can investigate a rejected or frozen feed.
Prepare the YouTube stream first
In YouTube Live Control Room, create or schedule the stream and locate its server URL and stream key. YouTube’s guide to creating a live stream with an encoder describes entering those details into the encoder, then starting the feed and checking its preview. Use the URL shown for the specific stream; do not assume a saved URL or key is interchangeable with a new stream configuration.
Where Live Control Room offers the choice, use the RTMPS URL. YouTube describes RTMPS as an encrypted extension to RTMP; FFmpeg’s protocol documentation likewise describes RTMPS as RTMP over a secure connection. Encryption protects the transport between encoder and ingest, but it does not make a leaked key harmless. It also does not correct an incorrect destination or an unstable upload connection.
Treat YouTube’s current encoder settings as a starting point, not a target you must reach regardless of your connection. Its encoder recommendations list H.264 among supported video codecs, AAC or MP3 audio, constant bitrate (CBR), and a recommended two-second keyframe interval that should not exceed four seconds. For H.264, the listed recommended ingest rates include 8 Mbps for 720p30, 14 Mbps for 1080p30, and 17 Mbps for 1080p60. These are YouTube recommendations for those formats, not proof that your church’s connection can sustain them.
Test the available upload connection at the place and time the stream will run. Leave headroom rather than setting the video rate equal to the best result from a brief test: other devices, network congestion, and ordinary variation can affect sustained delivery. YouTube itself recommends a speed test and ongoing stream-health checks. For a more focused discussion of estimating a sustained rate, see upload bandwidth for a YouTube radio livestream.
Treat the stream key like a password
A stream key gives an encoder permission to send video to the associated live stream. Keep it out of public repositories, shared documents, screenshots, terminal recordings, and support messages. Avoid putting it directly into a command that will be saved in shell history or copied into a ticket. The same care applies to configuration files: restrict who can read them, and do not commit them alongside the Dockerfile or other project files.
For a simple Docker deployment, supply the key at run time through an environment variable or a restricted environment file rather than embedding it in the image. An environment file is still a file containing a credential, so store it outside source control and limit access to the church staff who operate the stream. Be aware that privileged users on the Docker host may be able to inspect container configuration; this is access control, not a secure vault. Choose a method your team can maintain and understand.
Do not print the complete destination URL if it includes the key. FFmpeg diagnostics are useful, but logs should not become another place where the credential is routinely exposed. If the key is accidentally shared, use Live Control Room to rotate or replace it, then update the running container’s configuration and test the new feed. Establish who is authorised to make that change, since a volunteer discovering an exposed credential at night needs a known route to the person with channel access.
Keep a written record of the stream’s non-secret settings: the intended resolution and frame rate, audio source, stream schedule, and where the credential is stored. That helps a second operator diagnose a blank preview without passing the key around. It also separates the YouTube destination from the media and encoding choices that may need to change independently.
Build and run the FFmpeg container
Start with a Docker image that contains an FFmpeg build with the protocols and options you plan to use. Check that the build supports RTMPS and any recovery options in your command; FFmpeg options can differ by build. Pinning a known image version makes a later rebuild easier to reason about than silently pulling a changing image, but have an owner responsible for updating and testing it. Do not assume that a container running means the command inside it is encoding correctly.
The following is a shape of a command, not a complete production recipe. Replace the image, file path, input handling, and options with values tested for your installation. Keep the key out of the example and provide it as a variable at runtime:
docker run -d \\
--name church-live \\
--restart unless-stopped \\
--env-file /path/only-operators-can-read/live.env \\
-v /srv/church-media:/media:ro \\
ffmpeg-image:tested-version \\
-re -stream_loop -1 -i /media/service-loop.mp4 \\
-c:v libx264 -preset veryfast -b:v 8M -maxrate 8M -bufsize 16M \\
-r 30 -g 60 -c:a aac -b:a 128k \\
-f flv "$YOUTUBE_RTMPS_URL/$YOUTUBE_STREAM_KEY"
The example uses a looped file and one plausible format as an illustration, not a universal church setting. Confirm that the installed FFmpeg accepts the options and that the selected media has the expected audio and motion. The URL construction depends on the exact server URL and key format supplied by Live Control Room; if those are provided as separate values, assemble them carefully without printing the result. A file-based service, a live camera, and a playlist have different input concerns. For a playlist workflow, continuous FFmpeg playback for a YouTube product demo offers a related example to adapt rather than copy blindly.
The -re option reads a file at its natural rate rather than pushing it as fast as possible. The loop option can repeat an input file, but it cannot create a sensible programme schedule, confirm rights, or guarantee a clean transition. For audio, verify levels and continuity before unattended operation. If there is a camera or mixer, document which input device, audio channel, and fallback source are expected.
The sample bitrate follows YouTube’s listed H.264 recommendation for 720p30; it is not a claim that 720p30 suits every congregation or connection. Choose resolution and frame rate based on what is visible and what the tested upload can sustain. If the rate must be reduced, change the encode settings deliberately and check the resulting preview. A number copied from a guide is not a substitute for observing stream health under representative conditions.
Choose restart behaviour deliberately
Docker has restart policies that govern what happens after a container exits or the Docker daemon restarts. For an unattended service, unless-stopped is often a reasonable starting point: Docker can bring the container back after an exit or daemon restart, while a deliberate manual stop remains stopped across a later daemon restart. The always policy differs in how a manually stopped container is treated when Docker restarts. Check the current Docker documentation for automatic container starts and select the behaviour that matches your maintenance procedure.
A restart policy is not a high-availability system or a feed monitor. It cannot detect every case where FFmpeg remains alive but output is frozen, where YouTube rejects the incoming feed, or where the network path fails without the process exiting. Nor does restarting prove the audience-facing stream resumed. A container can be shown as running while Live Control Room reports a problem.
Use a deliberate manual stop for planned maintenance, and record why it was stopped and who is responsible for starting it again. With unless-stopped, that intentional choice persists across a Docker daemon restart, which is useful when a technician is changing media or configuration. Before relying on automatic starts, test a controlled container exit and a host restart during a non-public rehearsal. Confirm what actually happens in Docker and in YouTube, not just what the policy is intended to do.
Verify the actual feed in Live Control Room
Once FFmpeg starts sending, open the corresponding stream in Live Control Room. Inspect the preview for the expected picture and sound, then review YouTube’s stream-health indicators and messages. Check that the stream is associated with the intended event and visibility setting. A successful FFmpeg process launch only establishes that the process started; YouTube’s preview is a separate check that the feed arrived and can be inspected.
Test with representative content before the service is unattended. Include the actual audio source, scene changes or motion, and any long static sections that are normal for the church. Listen for silence, clipping, wrong-channel audio, or a loop point that cuts a prayer or song in the middle. Watch for buffering or dropped-feed messages and adjust the encoder or network plan before the public stream depends on it.
YouTube scans live streams for third-party material. If its systems identify protected content, a placeholder can replace the feed, and continued third-party content can lead to interruption or termination. A licence alone may not prevent an automated interruption; YouTube says the rights owner may need to add the channel to its Content ID allowlist. Confirm the church’s rights and any required channel allowlisting for music, recordings, or other third-party content before leaving a stream unattended. This is a check with the rights owner and YouTube, not a promise that a technical setup resolves rights issues.
Monitor beyond Docker status
Give someone a simple check routine that looks at more than docker ps. Docker status and container logs can show whether the process is up and whether FFmpeg is reporting errors; Live Control Room shows YouTube’s side of ingest and the stream preview. A viewer check from a separate device or network can add another perspective, particularly if the operator’s own connection sees a cached or local view. None replaces the others.
For a small church team, define who checks the feed during the first part of a service, who is contacted if the preview disappears, and who can access the channel and host. Decide how long a volunteer should investigate before handing over. Keep instructions accessible without storing the stream key in the same open document. Include the host’s power and network checks, where the relevant logs are, and how to stop a loop safely.
An FFmpeg process can also exit after a temporary connection failure. FFmpeg documents an output FIFO recovery approach with options such as -attempt_recovery 1 and -recovery_wait_time 1; evaluate it against the installed build and your output setup. It can attempt to recover from some temporary failures, but it is not a guarantee of uninterrupted delivery and does not replace YouTube preview checks. If you use it, rehearse a disconnect and learn whether YouTube accepts the resumed feed or requires a new action from the operator.
Keep a short incident log with the time, what YouTube showed, what Docker reported, and the action taken. Avoid recording the key or full destination URL. This record helps distinguish recurring network trouble from an encoder configuration error, and lets the next volunteer avoid repeating an unsuccessful fix. If the host is remote or the stream is operated from a cloud machine, logs and limits for an FFmpeg stream on an AWS Mumbai instance provides a relevant troubleshooting angle.
Plan for session boundaries and recovery
“24/7” describes the channel’s intended availability; it does not necessarily mean a single YouTube stream can remain one uninterrupted session forever. YouTube’s current help says streams under 12 hours are automatically archived. Do not plan an indefinite single archive on the assumption that one long-running process will make it so. Decide whether the church needs scheduled sessions, separate archives, or a planned operator hand-off, and check current YouTube guidance for the stream format and archive behaviour that applies.
Write down the recovery sequence before the first unattended run. For example: check Live Control Room for an ingest or policy message; check whether the container is running and inspect recent FFmpeg errors; confirm the host has working network access; then decide whether to restart the process, correct configuration, or create/restart a YouTube session. If a new session is needed, use the correct current stream details rather than assuming a container restart reconnects to the same audience-facing event. YouTube session behaviour is a separate operational concern from Docker process recovery.
Choose where the host should run based on who can maintain it and the network path to YouTube. An existing church computer may avoid new hardware but depends on its power, updates, and local internet connection. A dedicated small computer can reduce competing use of the machine, but still needs someone to maintain it and a tested connection. A hosted machine can avoid some local power and access issues, while introducing its own administration, network path, and recurring cost. Compare those responsibilities rather than assuming a particular deployment is inherently more reliable.
A service that removes the need to leave a church computer running can address one specific burden: StreamNeo turns an uploaded file into a YouTube live stream, so the programme does not depend on a local FFmpeg host staying powered on. You would still need to prepare the content and channel, check the resulting YouTube feed, and plan for stream/session boundaries; it is YouTube-only.
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
Will Docker automatically reconnect my church stream if YouTube drops it?
Docker can restart a container when a configured condition occurs, such as its process exiting. It does not establish that the resumed feed is reaching YouTube or that YouTube continued the same session. Check Live Control Room and follow a rehearsed recovery procedure.
Should I use RTMP or RTMPS?
Use the RTMPS URL provided in Live Control Room when available, since it encrypts the transport. Confirm that your FFmpeg build supports the protocol and use the exact URL supplied for the stream. A transport choice does not replace protecting the key itself.
Can one FFmpeg container provide an endless YouTube archive?
Do not assume so. YouTube documents automatic archiving for streams under 12 hours, so plan sessions and archives separately from keeping a process running. Check current YouTube guidance before settling on the church’s schedule.
What should I check before leaving the stream unattended?
Confirm the preview and health status in Live Control Room, test representative audio and motion, and verify the upload connection under realistic conditions. Make sure the stream key is restricted, content rights are checked, and someone knows how to investigate a failure and start the appropriate recovery step.