A Docker Compose restart policy can bring your playlist-streaming container back after a server reboot. It does not by itself confirm that YouTube is receiving video again or that the same live event is still available, so check those separately.
For a service that should return after Docker or the host restarts, unless-stopped is a practical default when an intentional manual stop should persist. Keep your current image, command and media mounts; change the service policy, apply the Compose file, and then verify the container, encoder output and YouTube status as separate steps.
Confirm the streamer runs as a Compose service
A restart policy belongs to a container, and Compose applies the service definition in compose.yaml (sometimes named docker-compose.yml). First confirm that the process which reads your playlist and sends video to YouTube is actually managed by the Compose project you intend to recover. If you start the encoder by hand in a shell, adding a policy to an unrelated Compose file will not make that hand-started process return after reboot.
From the directory containing the project file, inspect the services and their current state:
docker compose ps
Look for the streaming service name and a container associated with it. In the examples below, that service is called streamer; yours may instead be named youtube, encoder or something else. Use the name from your own Compose file in commands such as docker compose logs streamer.
If docker compose ps reports no relevant service, find out how the stream is launched before editing anything. Check the directory used by whoever deployed it, any deployment notes, and whether the encoder is managed by another mechanism. A container created outside this Compose project may have its own restart configuration, but changes to this project's file will not alter it. Avoid creating a second copy of the encoder simply because the intended service is not immediately visible.
This guide addresses recovery of a Compose-managed encoder after a reboot. It is not a guide to choosing a playlist encoder or setting up YouTube Live from scratch. If you are still deciding how to run the media source, the steps in making a sleep music stream with OBS in India cover a different starting point; check that the commands and paths there match your own setup before adapting them.
Add a restart policy to compose.yaml
Add restart under the long-running streaming service, at the same indentation level as image, command and volumes. For example:
services:
streamer:
image: your-streamer-image
restart: unless-stopped
# Keep your existing command, configuration and media mounts here.
This is only a placement example, not a tested or complete streaming configuration. Keep your actual image and service name. Docker's restart-policy documentation describes policies that determine whether containers start automatically when they exit or when Docker restarts.
For a service that runs continuously, unless-stopped fits many operators' expectations: Docker can start it again after a host or daemon restart, while a deliberate stop stays meaningful across the daemon restart. Choose always instead if your intended behaviour is for the container to return after a daemon restart even when it had been stopped manually beforehand. These are different operating choices, not different promises about YouTube continuity.
on-failure is aimed at restarting after a non-zero process exit. Docker documents that it does not restart a container simply because the daemon restarts, so it does not meet this article's specific reboot requirement. A clean exit also does not trigger that policy. Do not select it just because the word “failure” sounds like a broad recovery setting.
| Policy | After daemon or host restart | After an operator stops the container | Fit for this reboot goal |
|---|---|---|---|
unless-stopped |
Docker can start the container again | The stopped state is retained across daemon restart | A sensible default when a deliberate stop should stick |
always |
Docker can start the container again | It can return after a daemon restart | Choose when the service should return despite a prior manual stop |
on-failure |
Does not restart solely because the daemon restarted | A clean manual stop is not a failure | Not suitable for reboot recovery alone |
Restart behaviour also assumes the container was created with the policy and that Docker Engine itself starts during host boot. Docker's documentation notes a further qualification: restart-policy monitoring begins only after a container has run successfully for at least 10 seconds. If a configuration error makes it exit immediately, do not assume the policy will make an invalid setup healthy.
Keep the existing command and media mounts
The restart line changes container lifecycle handling; it does not define how the encoder plays the playlist. Preserve the current command, environment or configuration, and all media mounts unless you have a separate reason to change them. A policy cannot find a file that has moved, repair an invalid command, refresh expired credentials or translate a host path that no longer exists.
For instance, a service might already mount a host directory containing a playlist file into a path that the encoder expects inside the container. Keep both sides of that mapping intact when adding restart. If the host directory changes during system maintenance, the container may still start but the encoder can fail to find the playlist. That is a file-path problem, not evidence that the restart policy failed.
Before applying the edit, compare the saved file with the previous working configuration. Check indentation, service names, quoting, and whether the command still points to the expected playlist. If you store a YouTube stream key in the Compose file or environment, do not paste it into a public support message or screenshot. This article does not recommend changing or exposing credentials as part of reboot recovery.
A looping file, an ordered playlist and a list that advances between videos can have different restart behaviour depending on the encoder. A container restart usually launches the configured process again, but the process may begin the playlist from its configured starting point rather than resume precisely where it stopped. Check the documentation for the encoder and test with your own files. The discussion of why OBS can replay the same video instead of a playlist is relevant when OBS, rather than another encoder, manages playlist progression.
A reboot can also expose a media issue that was hidden while the server stayed up: a removable drive may mount later, a network share may not yet be available, or a renamed directory may leave the configured path empty. The restart policy has no dependency check for whether your playlist is actually usable. Verify that the host path exists after boot and that the container sees the file at its expected path before concluding that YouTube is at fault.
Apply the Compose configuration
Save the file, then run the Compose command from the project's directory:
docker compose up -d
This asks Compose to reconcile and start the project using the saved service definition. Docker's Compose command reference documents up as the command for creating and starting services from a Compose application. If you edited the restart policy but do not apply the changed configuration, the existing container may still have been created under the old definition.
Do not substitute docker compose restart when your purpose is to apply a changed Compose file. That command restarts existing containers; it does not apply service configuration changes in the file. Likewise, docker compose start starts previously created, stopped containers, but is not the command to reconcile a changed service definition. The distinction is useful when troubleshooting: an encoder process that was restarted is not necessarily a container recreated or updated from the policy you just saved.
After up -d, inspect the service state and, if needed, its logs:
docker compose ps
docker compose logs --tail=100 streamer
Use the actual service name in place of streamer. A container shown as running tells you that Docker considers its main process active; it does not prove that the process opened the playlist successfully or that a valid video feed reached YouTube. Logs may reveal a missing file, invalid option, connection failure or authentication issue. Treat logs as one diagnostic source rather than a guarantee of platform state.
If Compose reports a syntax or configuration error, stop and correct that before reboot testing. Preserve a copy of the last working file so you can restore it if the edit introduced an unrelated problem. Do not repeatedly recreate a service without understanding whether its media and configuration are stored outside the container; a replacement container can lose data that was never mounted or otherwise persisted.
Make sure Docker starts with the host
A container policy cannot help if Docker Engine is not running after the machine starts. Confirm that Docker is enabled to start during host boot using the instructions for your operating system and Docker installation. The steps differ between Linux distributions, desktop installations and managed servers, so use the relevant official documentation rather than copying an unrelated service command.
Also establish how the Compose project is brought back into Docker's view. In a standard Docker Engine setup, containers created with a restart policy can be restarted by the daemon after it starts. The Compose project files still matter for later edits and management; keep the project directory and its configuration available to the person who operates the channel. If the host uses a separate boot script or system service to launch Compose, understand how that mechanism interacts with the container policy instead of adding overlapping automation without a reason.
If the server is in a location with unstable power, a restart policy addresses only part of the recovery path. Power must return, the operating system must boot, Docker must start, the container must run, and the encoder must connect to YouTube. Each can fail independently. The practical checks in troubleshooting reconnects during Indian power fluctuations help separate local network and power symptoms from container configuration issues.
Reboot and verify container recovery
Plan a controlled reboot at a time when a temporary interruption is acceptable. Before it, note the service name and expected playlist path, and confirm the recent logs show the encoder operating as expected. A policy test is useful only if you know what a healthy local process looked like before the restart. Do not treat the test as a guarantee that every future outage will recover in the same way.
After the host returns, connect to it and check Docker and the Compose service:
docker compose ps
docker compose logs --tail=100 streamer
If Compose cannot connect to the daemon, resolve the Docker service or host boot issue first. If the container is absent, confirm you are in the correct project directory and that the expected project was deployed there. If it exists but is stopped or repeatedly exits, inspect the logs and configuration rather than changing policies at random.
Check whether the encoder opened the intended playlist and began producing output. If the logs show a missing file, compare the container path with the host mount. If they show a command or credential error, address that specific error. If the process is running but the output is not progressing, consult the encoder's own status and documentation; a live container is not necessarily a healthy stream.
You can perform a more specific policy test by stopping the service deliberately and observing what happens, but understand the selected policy first. With unless-stopped, an intentional stop should remain in effect across a daemon restart; with always, the container can return after a daemon restart. Docker documents manual-stop behaviour and the conditions around restart monitoring in its automatic container start guidance. Do not use a manual stop as a casual test while viewers expect the channel to continue.
A host reboot test checks a limited claim: whether Docker starts the container configured for automatic recovery. It does not establish that the playlist resumes at the same point, that YouTube has retained the same viewer-facing event, or that the stream will be uninterrupted. Keep those outcomes separate in your notes so an apparently successful container recovery is not mistaken for a complete broadcast recovery.
Check YouTube ingest and event status separately
YouTube distinguishes the incoming encoder feed from the viewer-facing live broadcast. In the Live Streaming API overview, a liveStream represents the input sent by the encoder, while a liveBroadcast represents the event shown to viewers. The API documentation describes stream status separately from broadcast status. In particular, an active stream status indicates YouTube is receiving encoder data; a running Docker container does not establish that status.
After the reboot, inspect YouTube Studio's Live Control Room or the control surface you normally use. Look for whether the expected event is still available and whether the incoming signal is detected. If you use the API, consult the liveStreams resource documentation for the meaning of its status fields, and the broadcast documentation for event state. Do not infer platform state solely from a green-looking local process or from an encoder log that only reports a connection attempt.
There are at least three useful observations to record: whether the container is running, whether the encoder is sending a signal that YouTube receives, and whether the intended broadcast event is live or otherwise in the state you expect. If the first is true but the second is not, investigate the encoder, stream key, outbound connection and YouTube ingest status. If the input is active but the event is not available to viewers as expected, inspect the broadcast state and YouTube's current guidance. These checks point to different parts of the chain.
Do not assume YouTube will resume the same event seamlessly after a server reboot. The documentation establishes that the incoming stream and broadcast are distinct resources; it does not promise that every encoder, channel or event configuration reconnects in a way that preserves the same viewer-facing event. Nor does container recovery prove that a playlist returns at the previous playback position. If continuity matters, test your exact encoder and event workflow in a controlled window, and check current YouTube guidance before relying on it.
A further reboot may be unnecessary if the failure is clearly elsewhere. For example, if the host and container are running but the input is absent, repeatedly restarting the host can obscure rather than clarify the cause. Compare the local logs, media availability and YouTube's status, then change one relevant part at a time. Where the playlist file itself needs replacing without a wider stream interruption, the separate guidance on replacing a source video on a running server addresses that operational problem rather than reboot recovery.
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 unless-stopped restart the stream after every server outage?
It allows Docker to restart a container after a daemon or host restart, provided Docker starts and the container was created with that policy. It cannot repair a missing playlist, invalid encoder command, unavailable network or other underlying fault. Verify the container and the YouTube input separately after a reboot.
Should I use always or unless-stopped?
Both support recovery after a Docker daemon restart. Use unless-stopped when a deliberate operator stop should remain in effect; use always when you want the container to return after a daemon restart even if it was stopped manually beforehand. Choose according to how your team uses the stop command.
Does a running container mean YouTube has resumed the same live event?
No. Container status describes the local process, while YouTube's incoming stream and viewer-facing broadcast are distinct resources. Check YouTube's ingest and event status, and test your encoder and event workflow rather than assuming the same event or playlist position has been restored.
Why did changing restart not affect my existing service?
A saved Compose file does not necessarily update a container until you apply the project configuration. Run docker compose up -d from the correct project directory; docker compose restart restarts existing containers without applying the edited service definition. Then check the service state and logs.