If Restreamer runs in a Docker container on your VPS, configure a Docker restart policy and make sure the Docker service starts when the host boots. These are separate settings: the policy tells Docker what to do with a container, while the host’s service configuration determines whether Docker itself runs after a reboot.
Before changing anything, record how the existing container was created. Its mounts, ports, environment variables and any hardware-specific options may be needed for the stream to work; a restart policy does not repair a faulty configuration or guarantee that an upstream stream is available.
Check what should happen after reboot
First confirm that this is a Docker-based Restreamer installation. The Restreamer Linux installation guide describes its Docker deployment for supported Linux systems. If you installed Restreamer by another method, Docker commands will not apply; identify the service manager or deployment tool you actually used before proceeding.
Think through the desired behaviour after two events: a VPS reboot and an operator deliberately stopping Restreamer. On reboot, you generally want Docker to start and then start the container. After a deliberate stop, you may want Restreamer to remain stopped until someone starts it again. That second preference determines which restart policy is a better fit.
A successful container start also does not necessarily mean that the stream is ready. Restreamer may need valid configuration, reachable inputs and working network access. If you are operating a continuous YouTube channel, keep the stream-side checks separate from the VPS restart checks; for instance, latency settings to check when YouTube delay is too high address a different class of problem than whether Docker starts at boot.
Inspect the current container settings
Use the VPS shell to list running containers:
docker ps
This shows running containers, but a stopped Restreamer container will not appear. Include stopped containers with:
docker ps -a
Identify the Restreamer container by its name or image, rather than assuming that a particular name is used. Then inspect its configuration, replacing restreamer below with the actual container name or ID:
docker inspect restreamer
The output is detailed JSON. Look for the image, entrypoint and command, environment, port bindings, mount sources and destinations, and the current restart policy. You can narrow the output with a formatted inspect command, but the exact fields may vary by Docker version. If you are unsure how the container was originally started, save the full output before making changes.
Also check whether the container is configured for automatic removal. A container created with --rm is removed when it exits, so it cannot be treated like an ordinary stopped container and updated in the same way. Docker documents that --restart and --rm cannot be combined; using both produces an error. See the Docker container run reference before recreating anything.
Do not paste secrets from inspect output into a public forum or ticket. Environment variables can contain credentials or stream keys. Keep a private copy for recovery, and redact sensitive values before sharing diagnostic information.
Ensure Docker starts at host boot
The container policy only matters if the Docker daemon is running. A VPS reboot starts the operating system afresh; Docker must be enabled to start with it, or no container restart policy can take effect at that point.
Docker notes that Debian and Ubuntu installations start Docker at boot by default. On other systemd-based Linux distributions, Docker’s post-install instructions show how to enable the Docker and containerd services. Check your operating system and installation method rather than blindly changing service settings. The Docker Linux post-installation steps provide the relevant guidance.
On a system that uses systemd, you can check Docker’s current state with:
systemctl is-enabled docker.service
systemctl status docker.service
If the service is not enabled and you have confirmed that systemd is the appropriate service manager for this installation, Docker documents these commands:
sudo systemctl enable docker.service
sudo systemctl enable containerd.service
Enabling a service makes it start at boot; it does not necessarily start it immediately. To start Docker now, use sudo systemctl start docker.service, then check its status. If your provider uses a different distribution, a managed container setup or a non-systemd service manager, follow the instructions for that environment instead. Do not treat a successful enable command as proof that a reboot will work; test it during a suitable maintenance window.
Choose a restart policy
Docker’s restart policy governs how Docker responds when a container exits and when the Docker daemon restarts. The two relevant choices here, unless-stopped and always, differ mainly in how they treat an intentional manual stop.
| Policy | After an unexpected container exit or Docker restart | If an operator manually stopped the container before a daemon restart |
|---|---|---|
unless-stopped |
Docker restarts it under the policy’s conditions | It remains stopped |
always |
Docker restarts it under the policy’s conditions | Docker can start it again when the daemon restarts |
Choose unless-stopped if a deliberate stop should survive a VPS reboot. Choose always if you want the container to return after Docker restarts even when it had previously been stopped manually. Neither choice fixes the reason a process exited. If, for example, a configuration file is invalid or an input source is unavailable, Docker may start the container again without resolving that underlying issue.
For an existing container that is not configured with --rm, Docker lets you update its restart policy without rebuilding it. For example:
docker update --restart unless-stopped restreamer
Replace the policy or container name to match your decision. Confirm the updated value with docker inspect; do not infer success just because the command returned without an obvious error. Docker documents that the policy only takes effect after the container has started successfully and has been monitored for at least ten seconds. If it fails immediately on its first start, investigate that startup failure rather than expecting the policy to resolve it.
Preserve Restreamer mounts and options
If you need to recreate the container, preserve the details that connect Restreamer to its data and to the network. Restreamer’s installation guide describes host-mounted configuration and data directories mapped into /core/config and /core/data. Those mounts let the container use host-side state; omitting or changing their host paths can make a replacement appear to have lost its configuration or data.
Ports matter too. The Restreamer guide includes examples for web access on ports 8080 and 8181, RTMP on 1935, RTMPS on 1936, and SRT on UDP 6000. These are examples from the documented setup, not a prescription for every VPS. Your actual host ports may differ because of a reverse proxy, firewall rules, another application or an earlier configuration choice. Keep the mappings your current deployment requires.
Environment variables, command arguments, device access and other runtime options may also be significant. A container that starts with the right image but without the original variables or mounts may not behave like the one you had. Capture the current settings first, and compare them with the Restreamer Quick Start only as a reference, not as a replacement for your own working configuration.
For a 24/7 channel, the media and stream configuration are another part of the recovery picture. A VPS restart test can confirm that a process returns, but not that the content is correct or that YouTube is receiving it. Before any planned change, check the source media, stream destination and any audio or video settings; a guide to encoding settings for live streaming can help when the output itself needs review.
Recreate safely without --rm
If the container was created with --rm, or you have another reason to rebuild it, make a recoverable record of its configuration before removing or replacing anything. Keep the image reference and all required options. Add the chosen --restart policy to the new docker run command, and omit --rm. Docker expressly says those two flags are incompatible, so do not combine them.
A command structure might look like this, but it is deliberately incomplete:
docker run -d \
--name restreamer \
--restart unless-stopped \
-p HOST_PORT:CONTAINER_PORT \
-v /host/config:/core/config \
-v /host/data:/core/data \
IMAGE
The capitalised placeholders are not literal settings. Replace them with the mappings, paths and image used by your installation, and include the environment variables, additional ports, or device options it needs. Do not run this template unchanged: a guessed port or path could break access or make persistent state unavailable.
A safer sequence is to prepare the replacement command, check every option against the existing inspect output, and only then stop and replace the old container. Do not delete host data directories as part of routine container replacement. If you are uncertain about a mount’s role, pause and establish which host directory contains the data before changing it. Where a deployment is managed by Compose or another tool, change its source configuration and redeploy through that tool so that the next update does not undo a one-off command-line change.
The comparison of a VPS with a managed 24/7 streaming option can help frame the operational trade-off: a VPS gives you control over its configuration, but you are also responsible for preserving and checking that configuration after maintenance. For a server you already run, careful recording of its current settings is usually the practical first step.
Reboot and verify recovery
Do not make the first reboot test during a critical broadcast if you can avoid it. Tell anyone who depends on the stream, choose a maintenance window, and make sure you can access the VPS console or provider recovery tools if remote access does not return. Record the current container state and policy, then confirm that Docker is enabled at boot and the container has the intended restart policy.
Reboot the host using your usual method. After it comes back, connect to the VPS and check the container:
docker ps -a
If Restreamer is running, inspect its policy and restart count if needed:
docker inspect restreamer
Review the logs as well:
docker logs --tail 100 restreamer
The commands provide different evidence. docker ps -a shows whether the container is running or stopped; inspect can show the policy and restart information; logs may reveal an application startup error. Then test the web interface and the actual stream path from an appropriate viewer or YouTube Studio. Confirming only that the container is up does not prove that a stream is live, that the expected media is playing, or that the audio and video are right.
If the container is stopped, check Docker’s service status and container logs before changing policy again. If Docker did not start, address host service startup. If Docker started but the container did not, re-check the container’s policy and whether it had been manually stopped. If it is running but Restreamer is not serving correctly, investigate application configuration, mounts, ports, credentials and source availability. A restart policy requests restarts under defined conditions; it is not a diagnosis or repair tool.
For broader continuity planning, think about what viewers see when an always-on channel is interrupted and how quickly you can confirm it has returned. A reboot test is useful because it exercises the host and container startup path, but it does not test every failure mode, such as an expired credential, a full disk or a broken media file. Keep a short record of the test outcome and the exact configuration that passed it.
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 --restart unless-stopped make Docker start after a VPS reboot?
No. It controls what Docker does with the container once the Docker daemon is running. You also need Docker configured to start at host boot, then you should verify both behaviours with a planned reboot.
Should I use always or unless-stopped?
Use unless-stopped when a deliberate manual stop should persist across a Docker or VPS restart. Use always when you want Docker to bring the container back after a daemon restart even if it had been stopped manually; choose based on how you operate Restreamer.
Can I add a restart policy to a container created with --rm?
Docker documents that --restart and --rm cannot be used together. If you need to recreate the container, omit --rm, preserve its existing mounts and runtime options, and include the desired restart policy.
What if Restreamer starts but the stream does not return?
A running container only confirms that Docker started it, not that the application is correctly configured or its source and destination are reachable. Check the logs, mounts, ports, credentials, media and stream status separately; the restart policy does not fix those underlying problems.