To keep an FFmpeg YouTube stream running after you disconnect from SSH, run FFmpeg under systemd on your Linux VPS and verify that it can reach YouTube over RTMPS. The service manager can restart a process that exits, but it cannot repair a wrong stream key, a missing video file, limited host capacity or a broadcast problem in YouTube Live Control Room.
The path is: prepare an input, choose encoder settings that fit both YouTube’s current guidance and your measured host capacity, test outbound access to port 443, and then start the encoder as a service. OVHcloud offers different VPS configurations and operating-system images, so check the image and test the actual server rather than assuming a tier guarantees a resolution or bitrate.
Check prerequisites and your Linux distribution
First identify the operating system image and version installed on the VPS. Commands for installing FFmpeg, file locations, account names and systemd conventions vary between distributions and releases. Check the image selected in your OVHcloud control panel and confirm on the machine with the appropriate release-identification command, such as cat /etc/os-release. Do not apply an installation recipe written for another distribution without checking its package names and current documentation.
Confirm that systemd is managing the machine before building the service. On a typical systemd-based Linux VPS, systemctl --version reports the installed version, and systemctl is-system-running can help indicate whether the service manager is operational. If your image uses a different init system, or systemd is unavailable in the environment, this guide’s unit-file steps do not apply as written.
You also need an FFmpeg build that includes the input and output formats, codecs and protocols your command will use. Check the installed build with ffmpeg -version, and inspect its supported encoders and protocols with FFmpeg’s help options. Package builds can differ. A command that works on a workstation may fail on a minimal VPS image if the required codec or RTMPS support is absent.
Decide what you will send before opening the live event: a local video file, a playlist-driven source, or another input. Make sure it is present on the VPS, readable by the account that will run the service, and appropriate for continuous playback. If your channel needs to rotate through several files, see the practical considerations in creating a 24/7 YouTube music stream with a playlist. This guide’s example uses one file so the service mechanics remain clear.
Finally, review the VPS’s current compute, network and acceptable-use details directly with OVHcloud. The available research does not establish a particular OVHcloud plan, image, or performance level for this workload. Encoding in software can consume substantial CPU, especially as resolution or frame rate rises; a stream that is stable on one server may overload another. You will need to benchmark the workload you intend to run.
Get the current YouTube RTMPS URL and stream key
Create or select the intended broadcast in YouTube Live Control Room. YouTube’s streaming setup guidance explains where to find the connection details; use the current RTMPS server URL shown for the event or stream rather than typing an endpoint from an old tutorial. YouTube recommends RTMPS, which encrypts the connection between the encoder and ingestion service.
The Live Control Room may initially hide the URL. Use the lock control in the Stream URL field to reveal the RTMPS URL, then copy both that URL and the stream key into your encoder configuration. Treat the key like a password: do not publish it, paste it into a public repository, include it in a screenshot, or put it in a world-readable file. If a key is exposed, replace or reset it in YouTube rather than assuming it can be kept private after publication.
The URL and key have distinct jobs. The URL identifies the YouTube ingestion endpoint; the key identifies the stream configuration YouTube should receive. Keep the URL exactly as supplied, including its hostname and path. Do not remove a path component or substitute a hostname based on a copied command. RTMPS relies on the hostname for TLS server-name indication (SNI), so a guessed or altered endpoint can fail even when the machine has internet access.
The command examples below use placeholders only. Substitute your current URL and key locally, and take care not to paste a completed command into a shared terminal transcript, support ticket or public log. In particular, avoid making the key part of a unit file readable by every local user. The exact credential-storage method depends on your distribution and systemd version; check the relevant official documentation and permissions before putting a real key into any configuration.
Prepare the input and FFmpeg command
Use a short test file first, then switch to the intended source. Check that the service account can read the file and any directories it needs. If it cannot, FFmpeg may exit immediately with a permission error even though the same command works when you run it as your interactive login. Avoid broad permissions such as making a media directory writable by every user merely to get the test to pass.
YouTube’s current encoder settings list RTMP/RTMPS as supported ingestion protocols, H.264, H.265/HEVC and AV1 as video codecs, and AAC or MP3 audio. They recommend constant bitrate (CBR), a keyframe interval of two seconds, and no interval longer than four seconds. The page gives different bitrate guidance by codec, resolution and frame rate, so select a specific row from the current table rather than treating one bitrate as universal. For example, YouTube’s H.264 recommendation for 1080p30 differs from its recommendation for 1080p60.
Those figures are YouTube guidance, not a promise about an OVHcloud VPS. Higher frame rates and resolutions raise the encoding and outbound network workload. YouTube lists 60 fps as the maximum frame rate in its guidance, but that does not mean your host can encode at that rate. Start with a modest test profile, measure CPU and network behaviour, and increase settings only if the actual machine sustains them without dropped frames or unstable output.
FFmpeg documents a general real-time streaming pattern as ffmpeg -re -i myfile -f flv rtmp://myserver/live/mystream; this is an RTMP illustration, not a complete YouTube command. Adapt the output format and destination to your installed FFmpeg build and the exact RTMPS URL and key supplied by YouTube. A template for a local video input might look like this:
ffmpeg -re -stream_loop -1 -i /srv/media/channel.mp4 \
-c:v libx264 -preset veryfast -r 30 -g 60 -keyint_min 60 \
-b:v 5M -maxrate 5M -bufsize 10M -pix_fmt yuv420p \
-c:a aac -b:a 128k -ar 44100 \
-f flv "<CURRENT_RTMPS_URL>/<STREAM_KEY>"
This is a starting point to adapt and test, not a prescribed profile. It uses H.264 at a fixed frame rate and a GOP length equivalent to two seconds at that frame rate; verify the source’s actual frame rate and the options supported by your FFmpeg build before using it. The example bitrate is deliberately not a claim about any OVHcloud instance and may not be suitable for your chosen output. Use the current YouTube table and your measured capacity to set the video rate, then leave enough outbound headroom for audio and ordinary network variation.
The -stream_loop -1 option asks FFmpeg to repeat the input file, which may suit a single-file ambience or devotional loop. It does not create a programme schedule or prove that repeated material is appropriate for your channel. If you need to manage a sequence of sources, compare that approach with streaming devotional videos continuously to YouTube with FFmpeg. For a different software workflow, the guide to running XSplit Broadcaster on a Windows VPS covers a Windows-based alternative rather than a Linux systemd unit.
Before making a service, run a short foreground test with a temporary key if possible, or take care that the real key is not retained in shell history. Confirm that FFmpeg opens the file, encodes audio and video, and connects to the endpoint. Review the output locally for credential leakage before sharing it. Do not make a real stream key visible in a published command, screenshot or log excerpt.
Check outbound RTMPS access on port 443
YouTube’s developer documentation for RTMPS ingestion describes RTMPS as using port 443 and notes the need for the server hostname for TLS SNI authentication. Your VPS must be able to make an outbound connection to the exact hostname and port used by the current URL. A local firewall, host policy or network restriction can block that connection even when ordinary web browsing from another machine works.
Check outbound rules in the VPS operating system and in any network firewall or security controls configured for the instance. The aim is to permit the encoder to make an outbound TLS connection on port 443 to the supplied YouTube ingestion host. Do not open inbound ports simply because a streaming tutorial mentions them: in this setup FFmpeg initiates the connection to YouTube.
A basic connectivity test can establish whether the hostname resolves and a TCP connection to port 443 can be made, but that is not a full stream test. Use tools available on your distribution, such as getent hosts for name resolution and a suitable TLS or network diagnostic for the endpoint. If a test tool is not installed, follow the distribution’s documentation rather than assuming its absence means the route is blocked. Avoid substituting a generic YouTube website hostname for the ingestion hostname.
A successful TCP connection does not prove that RTMPS negotiation, stream-key authentication, encoding or YouTube’s event configuration is correct. The FFmpeg test remains necessary. If the connection fails, distinguish DNS resolution, firewall or route problems from a TLS hostname mismatch and from a rejected key. Changing the RTMPS hostname to bypass a TLS problem can create a different failure; preserve the exact endpoint YouTube provided.
Create a systemd unit for FFmpeg
Once the command works in a controlled test, create a unit for the target distribution. A system service can run independently of your SSH session, and systemd can track its process and apply configured restart behaviour. It cannot make an invalid command valid or determine whether YouTube considers the incoming picture and sound healthy. Check the systemd service documentation and the target distribution’s conventions for unit locations, syntax and supported directives before using a production unit.
A basic template, with no real key shown, is:
[Unit]
Description=FFmpeg YouTube live encoder
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=streamer
WorkingDirectory=/srv/media
ExecStart=/usr/bin/ffmpeg -re -stream_loop -1 -i /srv/media/channel.mp4 -c:v libx264 -preset veryfast -r 30 -g 60 -keyint_min 60 -b:v 5M -maxrate 5M -bufsize 10M -pix_fmt yuv420p -c:a aac -b:a 128k -ar 44100 -f flv <RTMPS_DESTINATION_FROM_PROTECTED_CONFIG>
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
This is an adaptable example, not a drop-in file: confirm ffmpeg’s path, service account, media path, unit syntax and restart policy on your own image. Do not paste a real destination containing the stream key into a publicly readable unit. One way to separate secrets is a root-owned configuration file with restrictive permissions referenced using a mechanism supported by your systemd version, but the precise syntax and security implications need checking against the local manual. Consider how the chosen method affects process listings, diagnostics and access by administrators; no storage technique makes a key safe to disclose.
Create a dedicated unprivileged account if appropriate for your distribution and workflow, and grant it only the access it needs to read the input and any protected configuration. Check directory traversal permissions as well as the file’s own mode. Avoid running a long-lived encoder as root just to work around a file-permission mistake. If you enable additional systemd sandboxing or hardening, test it carefully: restrictions can prevent access to media, configuration or required device and network resources.
The example uses Restart=on-failure to illustrate process supervision, not to promise recovery from every problem. A restart can help after an unexpected process exit, but repeated failures may continue if the file path is wrong, the key has been revoked or the endpoint is unreachable. Avoid settings that cause an uncontrolled restart loop. The service’s journal may include FFmpeg diagnostics, so inspect what your command writes and ensure it never prints the secret destination.
Enable, start and inspect the service
Save the unit using the filename and location used by your distribution, then ask systemd to reload unit definitions. The commands below are common on systemd distributions, but check local documentation and permissions before applying them:
sudo systemctl daemon-reload
sudo systemctl enable --now ffmpeg-youtube.service
sudo systemctl status ffmpeg-youtube.service
enable arranges for a unit to start during the system’s normal boot target; --now starts it immediately. If you want to test before making it persistent at boot, start it without enabling it. Use a unit name that matches the file you installed. A typo in the name or an invalid unit can look like a broken encoder, so read the error returned by systemd before changing the FFmpeg command.
Inspect recent service messages with journalctl -u ffmpeg-youtube.service and the appropriate time or follow options for your distribution. Look for the earliest meaningful error, not just the final exit status. An input permission failure, missing encoder, malformed option, DNS failure, TLS error and rejected stream key need different fixes. Keep logs private if there is any chance they contain a key or full destination URL.
A unit marked active only tells you that systemd considers its process running. FFmpeg can remain alive while output is stalled or YouTube reports an unhealthy stream. Conversely, a process may exit quickly and be restarted, obscuring the first cause unless you review the journal. Use service status as one diagnostic, not as proof that viewers can see a healthy broadcast.
If you change the unit, reload systemd before restarting the service. Stop it deliberately before replacing media or credentials if the transition needs to avoid competing encoders for the same stream. Do not start multiple copies with the same key unless that is intentional and supported by your setup; overlapping encoders can cause confusing output at the receiving end.
Test the YouTube preview and host capacity
Open the correct event in YouTube Live Control Room and allow time for the preview and stream-health messages to appear. Check the picture, audio, aspect ratio and motion, not only whether the event shows an incoming connection. Test a representative section: a static devotional image may encode differently from a moving video, and music with quiet passages can reveal audio problems that a brief opening check misses.
Monitor both YouTube’s reported stream health and the VPS while the test runs. Watch CPU use, memory pressure, network throughput and FFmpeg’s reported frame progress. Repeat the test long enough to cover ordinary operating conditions and transitions in your source. A brief successful connection does not establish that the chosen profile will be sustainable through an overnight or always-on run.
Use the measured host behaviour to adjust the profile. If CPU use remains high or frames fall behind, reduce encoding load by testing a lower resolution or frame rate, or use a supported hardware encoder only if the host actually provides one and your FFmpeg build can use it. If network throughput approaches the available outbound capacity or YouTube reports connection instability, reduce the bitrate and retest. There is no universal safe figure for an OVHcloud VPS: check the current product details and measure your selected instance and route.
YouTube’s recommended H.264 figures can help choose a test target, but they do not replace that measurement. For example, the current guidance differentiates between 720p30, 720p60, 1080p30 and 1080p60, and other codecs have different recommendations. Recheck the current table before changing settings; do not copy a bitrate from a different codec or frame rate and assume the same result. If dropped frames are the practical problem, the guide to fixing dropped frames in pre-recorded YouTube Live streams can help you separate encoding pressure from source and network issues.
Before leaving the service unattended, verify the intended event, current key, exact RTMPS destination, input permissions, audio, representative movement, systemd restart behaviour and YouTube health messages. If you want to avoid maintaining an SSH-connected encoder process, StreamNeo removes that particular operational burden by turning an uploaded video into a YouTube live stream that can run with your computer switched off; it does not change the need to prepare suitable content or check the YouTube broadcast.
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
How do I keep an FFmpeg YouTube live stream running after I disconnect from SSH?
Run FFmpeg as a systemd service on a systemd-managed Linux VPS rather than leaving it attached to your interactive shell. Configure and test the unit first, then disconnect from SSH and verify in Live Control Room that the broadcast remains healthy. A service manager supervises the process; it does not correct invalid credentials, a missing input or insufficient capacity.
How do I use RTMPS and a YouTube stream key with FFmpeg?
Copy the current RTMPS URL and key from the intended stream in YouTube Live Control Room, and use the exact URL and hostname in FFmpeg’s destination. Keep the key private and out of public examples, repositories and world-readable unit files. Confirm that the installed FFmpeg build supports the output protocol and that the VPS can connect to the supplied endpoint on port 443.
Will a particular OVHcloud VPS run 1080p continuously?
You cannot determine that from the provider name or plan label alone. Check the current OVHcloud specifications and terms for the selected instance, then measure CPU, memory and outbound network behaviour with your actual input and encoder settings. YouTube’s recommendations describe its encoder guidance, not guaranteed performance on a particular VPS.
Does an active systemd service mean the stream is healthy?
No. It means systemd sees the configured process in its expected state, not that YouTube is receiving a usable picture and sound. Check the preview and health messages in Live Control Room alongside FFmpeg’s logs and the host’s resource use.