A VPS reboot does not automatically bring a YouTube stream back unless the encoder is registered as a system service and enabled to start during boot. You also need a separate restart policy for cases where the encoder process exits after the machine is already running.
For a dependable setup, make systemd start the encoder, wait for the network and required media to be ready, restart eligible failures, and then check the recovered feed in YouTube Live Control Room. A green service status alone is not proof that YouTube is receiving usable video.
Why a stream may not return after a reboot
An encoder started from an SSH terminal belongs to that login session unless you deliberately run it under a supervisor. When the VPS reboots, the shell disappears, the command stops, and nothing tells the operating system to run it again. The same problem can occur when the encoder exits overnight because of a damaged input, a network interruption, an invalid option, or an ordinary end-of-file condition.
These are two different recovery jobs:
| Situation | What needs to happen | systemd setting or action |
|---|---|---|
| The VPS boots | Start the encoder as part of the normal boot process | Enable the service |
| The encoder exits with an error | Start it again after a qualifying failure | Configure Restart=on-failure or another suitable policy |
| The encoder exits cleanly | Decide whether a clean exit means completion or an unexpected stop | Choose Restart=always only when that behaviour is wanted |
| The encoder starts before its input is available | Delay or order the service until its dependencies are ready | Use appropriate dependencies and readiness checks |
Enabling a service does not make an invalid command work. A restart policy does not repair a wrong stream key, a missing file, a broken input mount, insufficient upload capacity, or a problem on YouTube's side. It only controls what the service manager does after the process meets the policy's restart conditions.
If your encoder is FFmpeg, first make sure the command works in a planned manual test. For a looping file workflow, the media and looping logic matter as much as the supervisor. The guide on making FFmpeg rotate through videos for a 24/7 YouTube stream is useful when the source is a playlist rather than one continuous file.
Check the VPS operating system and systemd
This approach assumes that the VPS uses systemd. Many current Linux distributions do, but you should check rather than copy a unit designed for a different operating system. Distribution, systemd version, installed encoder, user account, file paths, input type, and network configuration all affect the final service.
Run these checks as an administrator or with sudo:
cat /etc/os-release
systemctl --version
command -v ffmpeg
The first command identifies the operating system. The second confirms that systemd is present and shows its version. The third confirms where the encoder executable is installed. If systemctl is unavailable, or the VPS uses another init system, stop here and follow documentation for that environment instead of using this unit unchanged.
You should also identify the account that will run the encoder. A dedicated unprivileged account is generally easier to reason about than running a media process as root. That account needs read access to the media directory and configuration files, and it must be able to open any mounted or network-backed input it uses.
Before creating the unit, test the complete encoder command as that same account. Use the real input and the stream address from YouTube Live Control Room. YouTube describes the stream key as similar to a password and an address, so do not paste it into a public article, a shared terminal recording, or a log that other users can read. The current YouTube Help guidance on managing live stream settings explains where the stream URL and key are obtained.
For a new channel, also separate the streaming mechanism from content questions. A devotional playlist, local news loop, or study channel may need different media checks. For example, streaming a church service playlist on YouTube Live from a computer involves source preparation that a systemd unit cannot validate for you.
Create a service with safe configuration handling
A systemd unit describes how to launch the encoder and what should happen around it. The exact command is specific to your encoder and media, so the example below is a structure rather than a universal FFmpeg recipe.
Create a directory for protected configuration and give it ownership and permissions appropriate to the service account. One possible arrangement is:
sudo install -d -m 750 -o stream -g stream /etc/stream
sudo install -m 640 -o root -g stream /dev/null /etc/stream/youtube.env
The environment file can hold values that should not be placed directly in the unit. Use placeholders while adapting the example, and do not publish the completed file:
YOUTUBE_URL=rtmps://actual-address-from-live-control-room
YOUTUBE_KEY=replace-with-the-key-from-live-control-room
Whether an encoder accepts these variables depends on the command you use. Some commands need the values expanded into an output URL, while others use a separate configuration option. Confirm the syntax for your encoder and check that the resulting process list and journal do not expose the key. If the key is reset in Live Control Room, update this file and restart the service. A supervisor cannot know that an old key has been revoked.
Create a unit such as /etc/systemd/system/youtube-stream.service:
[Unit]
Description=YouTube live encoder
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=stream
Group=stream
EnvironmentFile=/etc/stream/youtube.env
WorkingDirectory=/srv/stream
ExecStart=/usr/bin/ffmpeg -re -stream_loop -1 -i /srv/stream/input.mp4 -c:v libx264 -c:a aac -f flv "${YOUTUBE_URL}/${YOUTUBE_KEY}"
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
Do not copy the command without checking it. The executable may be in another location, the input may be a playlist or capture device, and the output syntax may differ. YouTube supports RTMP and RTMPS encoder workflows, and its official RTMPS explanation describes RTMPS as RTMP over a TLS or SSL connection. Use the address shown for your own stream rather than inventing one.
The EnvironmentFile keeps the credential separate from the unit, but it is not a complete security design. Restrict access, avoid placing the file in a public media directory, and check journal output before sharing diagnostics. If the key has been exposed, reset it in Live Control Room and replace the stored value.
After saving the unit, ask systemd to read it:
sudo systemctl daemon-reload
At this stage, do not enable it and walk away. Start it manually, inspect the result, and correct the command while you are present:
sudo systemctl start youtube-stream.service
sudo systemctl status youtube-stream.service --no-pager
sudo journalctl -u youtube-stream.service -n 100 --no-pager
Enable startup and configure restart behaviour
Once the command works in a supervised test, enable it for the normal boot target:
sudo systemctl enable youtube-stream.service
This creates the relationship that causes systemd to start the unit when the relevant boot target is reached. It is different from start, which launches the service now. You can use both explicitly when preparing the machine:
sudo systemctl enable --now youtube-stream.service
The second recovery layer is the Restart= setting. The systemd documentation for service restart behaviour distinguishes policies that react to failure from policies that also react to clean exits. Restart=on-failure is often a sensible starting point for a long-running encoder that should remain stopped when it deliberately completes. Restart=always also responds to clean exits, which may be appropriate when a clean encoder exit is still an unexpected interruption.
| Setting | What it generally covers | When to consider it |
|---|---|---|
Restart=no |
No automatic restart | A deliberately one-shot or manually managed service |
Restart=on-failure |
Eligible unsuccessful exits, signals, timeouts, and related failures | A long-running encoder that should restart after faults but not after a normal completion |
Restart=always |
Failure exits and clean exits, subject to systemd's documented exceptions | An encoder where any exit, including a clean one, should lead to another attempt |
The exact meaning depends on the systemd version and how the encoder exits. A service that reaches end-of-file may exit cleanly even though you expected an endless loop. With on-failure, that clean exit may leave the stream stopped. With always, it may be started again, but repeated clean exits can create a restart cycle rather than solve the underlying media problem.
RestartSec=10 adds a delay between attempts in this example. Choose a delay that gives the input or network time to recover without creating a rapid loop. systemd also has start-rate controls that can stop repeated attempts from continuing indefinitely; review those if you are troubleshooting a unit that repeatedly fails at launch.
A systemd operation that intentionally stops a service should not be confused with an encoder crash. Restart rules have exceptions for systemd-managed stops, and you should consult the installed documentation when testing commands such as stop, restart, and reload. The important distinction is that boot enablement and process restart are separate controls.
If you change Restart=, ExecStart=, dependencies, or the environment file arrangement, reload the unit and restart it deliberately:
sudo systemctl daemon-reload
sudo systemctl restart youtube-stream.service
sudo systemctl status youtube-stream.service --no-pager
Account for network and input dependencies
A unit can be active while its input is absent or its output cannot reach YouTube. After=network-online.target expresses ordering, but it does not guarantee that every route, DNS service, mounted directory, or remote input is usable. The target's behaviour also depends on the distribution and the network management software installed on the VPS.
For a local media file, confirm that the path exists after boot and that the service account can read it:
sudo -u stream test -r /srv/stream/input.mp4
sudo -u stream ls -l /srv/stream/input.mp4
For a playlist, a mounted disk, or a network filesystem, add the relevant mount or service dependency only after identifying how that input is made available. Do not add arbitrary unit names to Requires= because a guessed dependency can prevent the encoder from starting at all. A source that is ready only after a separate download or mount process may need that process to have its own startup and failure handling.
The output also needs enough upload capacity. YouTube's streaming tips recommend keeping 20% upload headroom above the total stream bitrate and warn that a connectivity disruption can break a stream. This is a planning recommendation, not a promise that a particular VPS connection will remain stable during every reboot or route change.
Check the encoder's selected codec, resolution, frame rate, keyframe interval, and bitrate against YouTube's current live encoder settings. The appropriate bitrate varies with codec, resolution, and frame rate, so do not copy a number from another channel merely because the file appears similar. A restart loop cannot correct an output that the network cannot carry or an encoder configuration YouTube cannot accept.
It is also worth deciding what a reboot means for your YouTube workflow. A service may reconnect to the endpoint, but that does not by itself establish how a particular scheduled stream, watch page, archive, or viewer session will appear. Test the complete arrangement in a maintenance window rather than assuming that process recovery and viewer-facing continuity are identical.
Inspect status and logs after reboot
When you are ready to test, record the current state first. This makes it easier to distinguish a service that never started from one that started and then failed:
systemctl is-enabled youtube-stream.service
systemctl is-active youtube-stream.service
systemctl show youtube-stream.service -p Result -p ExecMainStatus -p NRestarts
is-enabled checks the boot relationship, while is-active reports the current service state. NRestarts can show that the process has been cycling, but a value alone does not explain why. Use the journal for the surrounding evidence:
journalctl -u youtube-stream.service --since "10 minutes ago" --no-pager
Look for the encoder's first error, not only the final systemd message. Common examples include a missing input, permission denial, an invalid option, failure to resolve the destination, refusal from the endpoint, or an authentication error. If systemd says the process exited and restarted, that confirms supervision. It does not confirm that the output reached YouTube.
A useful troubleshooting order is:
- Check that the unit is enabled and points to the intended executable.
- Check that the service account can read the input and configuration.
- Run the exact command manually as that account, without exposing the key in shared output.
- Confirm the current stream URL and key in Live Control Room.
- Check DNS, routes, firewall rules, and available upload capacity.
- Inspect the new journal entries after one controlled restart.
If the key was reset or replaced, update the protected configuration and restart the service. If the media file has moved, correct the path rather than increasing the restart frequency. Repeated attempts can make a log noisy while leaving the actual fault unchanged.
For operators who would rather not leave a computer running to host the encoder, StreamNeo removes the VPS reboot and local supervision work by taking an uploaded video, YouTube stream key, and channel configuration and running the broadcast in the cloud with monitoring and automatic restart handling.
Verify recovery in Live Control Room
A controlled reboot is the test that matters. Choose a maintenance window, tell anyone who may be watching, and make sure you can access the VPS console if SSH is unavailable during startup. Do not use an unplanned production reboot as your first test.
Before rebooting, confirm that the service is enabled and currently running:
sudo systemctl is-enabled youtube-stream.service
sudo systemctl status youtube-stream.service --no-pager
Then reboot:
sudo systemctl reboot
After the VPS returns, reconnect and check the boot sequence and unit state:
systemctl status youtube-stream.service --no-pager
journalctl -b -u youtube-stream.service --no-pager
The -b filter shows entries from the current boot. Check whether the service was launched at boot, whether it reached the encoder command, whether it restarted, and whether any dependency delayed or blocked it. If the service is inactive, the journal should tell you where the startup path stopped.
Next, verify the stream in YouTube Live Control Room rather than stopping at active (running). Look for an incoming preview, connection status, video and audio health, and any warnings. If the stream is scheduled, confirm the state of that particular scheduled event. Then open the viewer-facing page from a separate device or browser session and check that the picture, sound, and loop behaviour are what viewers receive.
YouTube's own status is important because the encoder may remain connected while sending no frames, sending unusable audio, or repeatedly reconnecting. A service status reports the process manager's view. Live Control Room reports whether YouTube can use what the process is sending.
If recovery fails, compare the time of the reboot with the first journal error and the first Live Control Room message. A failure before the encoder launches points towards boot ordering, permissions, paths, or dependencies. A running encoder with no incoming feed points towards the command, credentials, network, or output settings. A visible feed with poor health points towards input quality or capacity rather than boot startup.
After the test, decide whether the observed behaviour meets your channel's needs. A VPS service can restart a process, but it cannot guarantee a continuous viewer session or repair every interruption. If the channel is built around recorded content, review the guidance on YouTube rules for running a 24/7 live stream of pre-recorded content as a separate content and policy task.
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 enabling a systemd service restart the stream after every VPS reboot?
It tells systemd to start the service when the enabled boot target is reached. It does not prove that the encoder command, input, credentials, network, or YouTube workflow will work after boot, so verify the feed in Live Control Room.
Should I use Restart=on-failure or Restart=always?
Use on-failure when a clean encoder exit should remain stopped and failures should be retried. Consider always when any exit is unexpected, but check the encoder's exit behaviour so a completed input does not create an endless restart loop.
Why is the service active but YouTube shows no stream?
The process may be running without sending valid video or audio. Check the journal, stream URL, key, input permissions, output settings, network route, and upload headroom, then confirm the result in Live Control Room rather than relying on service status.
Will this unit work on every VPS?
No. The operating system, systemd version, encoder path, media input, user permissions, network manager, and dependency layout vary between VPS machines. Treat the unit as a starting structure and adapt it after testing the actual command manually.