A headless Ubuntu VPS can send an ordered folder of videos to YouTube Live without a desktop streaming application. The practical pattern is to prepare a deliberate playlist, have FFmpeg encode or pass through its contents, send them to YouTube’s RTMPS ingest address, and verify the incoming stream in Live Control Room.
Treat the playlist and service setup below as an implementation approach, not an official YouTube recipe. Files, Ubuntu packages, network routes and VPS capacity differ, so test your exact material and configuration before relying on a long broadcast.
How the headless VPS workflow fits together
The VPS reads local video files and feeds them to FFmpeg. FFmpeg produces one continuous outgoing stream and sends it to the ingest URL and stream key shown in YouTube Live Control Room. YouTube receives that feed; its preview and health messages tell you whether the broadcast is arriving in a usable form.
There is no monitor or desktop application in this path. You administer Ubuntu remotely, usually through a terminal, and the machine must remain powered on and connected for as long as it is doing the encoding. A process supervisor can restart a process that exits, but it cannot fix a poor network route, an invalid key or a source file that breaks the playlist.
It helps to separate the work into three concerns: preparing media, publishing the feed, and checking what YouTube receives. A folder is not automatically a reliable playlist: filesystem order may not match the sequence you intend, and different files may use different codecs, dimensions, frame rates or audio layouts. Similarly, a running FFmpeg process is not proof that viewers can see or hear a healthy stream.
If you are choosing a small always-on host, include CPU capacity, disk space, upload capacity and your ability to maintain the machine in the decision. A low-CPU VPS may handle compatible files when they are copied without re-encoding, but mixed sources that need normalising can demand more processing. For other ways to run a recurring playlist, the Raspberry Pi loop guide describes a different hardware approach; the steps here focus on a remote Ubuntu machine.
Prepare YouTube Live before connecting
Open YouTube Live Control Room and create or select the stream you intend to use. In its stream settings, retrieve the current ingest URL and stream key. YouTube’s live streaming encoder setup guidance explains how to find these values and select RTMPS. Use the exact address displayed for your stream rather than copying an example URL from a tutorial.
The URL and key work together as the destination credentials for the encoder. Depending on how the client accepts them, the address and stream name may be separate fields or combined. The YouTube Live Streaming API describes the ingest address and stream name as the details needed to transmit; its Live Streams reference also documents stream health and configuration issues. Follow the format required by your FFmpeg invocation and the values shown in Control Room.
Use RTMPS when it is available for your stream. It carries RTMP over TLS, protecting the connection in transit. If a connection fails, check that you copied the RTMPS address and that the VPS can reach the indicated endpoint and port; YouTube’s RTMPS instructions mention trying port 443 where needed. A local firewall or provider network policy may also affect outbound traffic.
Treat the stream key like a password. Avoid putting it in a public repository, a support screenshot or a command that may be saved in shell history. A private configuration file with restrictive permissions is a more prudent place for it than a checked-in script, though the exact secret-handling method is your operational choice rather than a YouTube VPS-specific recipe. If you expose a key, replace it in Live Control Room and update the encoder configuration. For a fuller discussion of command-line exposure, see using a stream key with FFmpeg without leaving it in shell history.
Before moving on, note what stream you selected and keep Control Room open in a separate session. You will return there to confirm that YouTube is receiving data, inspect the preview and read any health messages. Do not treat a successful connection message from FFmpeg as the final test.
Install and validate FFmpeg
Install FFmpeg using a trusted package source appropriate for your Ubuntu release, then check that the executable runs and that its build supports the protocols and codecs you plan to use. Ubuntu package versions and build options can vary. In particular, verify RTMPS support rather than assuming every package build has identical TLS capabilities.
Before transmitting, inspect representative files with FFmpeg’s probing tools or another media inspector. Record their video codec, resolution, frame rate, audio codec, sample rate and channel layout. The useful question is not only whether a file plays on your laptop, but whether its streams can be combined into the output profile you have chosen without an unexpected change at a playlist boundary.
For a conventional SDR profile, H.264 video with AAC audio is a practical starting point supported by YouTube’s encoder guidance. YouTube also supports H.265/HEVC and AV1 video, and AAC or MP3 audio for RTMP/RTMPS. Its recommended encoder settings specify CBR bitrate encoding, a two-second keyframe interval recommendation that should not exceed four seconds, and a maximum frame rate of 60 fps. For SDR, the guidance recommends Rec. 709 and 8-bit depth.
Pick resolution and frame rate based on the source material and a measured, sustainable upload rate from the VPS. YouTube’s table gives 1080p30 H.264 a 5 Mbps minimum and 14 Mbps recommendation; for AV1 or H.265 at that resolution and frame rate it gives a 4 Mbps minimum and 10 Mbps recommendation. These are YouTube ingest recommendations, not proof that your VPS or route can sustain the rate. The table can change, so consult the current encoder settings page when configuring a real stream.
Choose between stream copy and re-encoding deliberately. Copying compatible encoded streams avoids doing a full video encode on the VPS, which can reduce CPU demand, but it leaves the source properties in place and is not a universal solution for files with different parameters. Re-encoding lets you create a consistent output profile, but uses CPU and can fail to keep pace if the VPS is undersized. Test a representative sequence and watch CPU, upload use and YouTube health before extending it to the full folder.
Turn the video folder into an ordered playlist
Create a text playlist that names each file in the sequence you want, rather than relying on a shell wildcard. Wildcards are convenient for selecting files but do not express editorial intent, and lexicographic sorting can put names such as clip-10 before clip-2. Rename files consistently or maintain a separate ordered list, and check it line by line before launching a broadcast.
FFmpeg can consume a concat-style list for suitable inputs, but the syntax and flags depend on how the inputs are encoded and whether you plan to copy or re-encode them. This is an implementation choice, not something specified by YouTube. Use paths that resolve from the working directory of the eventual process; a service launched in the background may not start in the directory you expect.
Compare the files before assuming they form one seamless sequence. Inputs with the same codec, dimensions, frame rate and audio properties are generally easier to join in a copy workflow. Mixed material may need normalisation or a transcode to a common profile. Check that each file has the audio you expect, that the ending and beginning do not create long gaps, and that rotation or unusual aspect ratios will not produce an unintended picture.
A short test playlist is more useful than a full overnight experiment. Include at least one file that represents the ordinary material and, if the folder contains varied sources, one of each materially different type. Run that sequence through the same FFmpeg path you expect to use unattended. Watch the transition between files locally if possible, then inspect YouTube’s preview for pauses, black frames, missing sound or changes in framing.
If the final item should lead back to the beginning, confirm how your playlist mechanism handles the end of the list. Repeating a folder and maintaining a live broadcast are separate behaviours: one controls media order, while the other controls the encoder process and YouTube session. The guide to keeping OBS streaming after a playlist ends covers a different application, but the distinction between playlist completion and broadcast continuity is useful here too.
Send the playlist to YouTube Live
Once the playlist, output profile and Control Room destination are ready, run FFmpeg in a foreground test first. This makes its initial diagnostics visible and gives you a chance to catch a bad path, missing input, unsupported option or connection failure before you hide the process in a service. Insert the actual URL and key through a method that does not disclose the key in shared logs or source control.
There is no single command that safely covers every folder. The correct input options differ between concat demuxing, separate inputs and other playlist methods; output options differ between stream copy and re-encoding. Build the command around your inspected files and validate the exact installed FFmpeg build. Do not assume a copy-oriented example works with arbitrary mixed files, or that changing an extension makes codecs compatible.
For the output, set a supported video and audio codec, a bitrate appropriate to the resolution and frame rate, CBR behaviour, and a keyframe interval consistent with YouTube’s guidance. Map an audio stream explicitly if there is one you intend to send. A silent source or incorrect mapping can produce a picture with no sound; YouTube’s health diagnostics include missing audio and unsupported audio conditions. If the content is meant to be silent, decide how that should be represented and verify the resulting stream rather than inferring success from the video alone.
While FFmpeg runs, look for evidence that it is reading successive inputs and transmitting output. A stalled timestamp, repeated input error or immediate exit points to a local problem. On the YouTube side, wait for the stream to appear in Live Control Room. If no incoming data appears, re-check the exact URL, key, protocol, outbound network access and firewall path. The API’s stream health documentation lists configuration and health information that can help distinguish an encoder issue from a connection problem.
Use the title, visibility and broadcast controls in Control Room intentionally. The VPS sends an encoder feed; it does not decide whether you should make the broadcast public, schedule it or end it. Check the current YouTube interface and settings before you begin, especially if the stream is intended for a particular audience or schedule.
Check preview and health status
Do not start an unattended run until the incoming preview is visible and representative. Confirm that motion is present, the picture is framed correctly, the expected resolution and frame rate are being received, and audio is audible at a suitable level. A single still image can conceal a frozen encode; listen as well as watch, and inspect a transition between playlist items.
Read stream health messages rather than treating the preview as the only signal. YouTube’s guidance recommends testing a representative stream and monitoring health and messages. Its API lists possible issues including low or high video bitrate, frame-rate mismatch, missing audio, unsupported audio codec, sample-rate problems and unsuitable keyframe spacing. Compare each warning with the actual output profile and the source files you inspected.
A table helps make the bitrate examples concrete without turning them into a universal prescription:
| YouTube example for SDR | Minimum bitrate | Recommended bitrate | What to check |
|---|---|---|---|
| 720p30 H.264 | 3 Mbps | 8 Mbps | VPS upload capacity and whether the picture needs this detail |
| 1080p30 H.264 | 5 Mbps | 14 Mbps | Sustained upload headroom, not just a brief speed-test result |
| 1080p30 AV1 or H.265 | 4 Mbps | 10 Mbps | Encoder support and CPU capacity for the selected codec |
Values in the table are from YouTube’s published encoder guidance as reviewed in 2026; check its current settings page because recommendations can be revised. They describe platform recommendations, not a promise about the performance of your provider, route or encoder. If your VPS has variable upload capacity, choose a less demanding profile and test it under realistic conditions rather than selecting the highest figure in the table.
Keep a record of the output settings that passed your test and the messages Control Room showed. If the feed is healthy on a short representative run, that evidence is more useful than a guess based on the process staying alive. It still does not guarantee that every file, later network condition or future YouTube setting will behave identically.
Keep the job running and troubleshoot failures
For an unattended broadcast, one common implementation is to run the FFmpeg command under systemd. A service unit can start the process after a reboot, use an explicit working directory, and apply restart behaviour if FFmpeg exits. This is a Linux process-management approach, not a YouTube-prescribed workflow. Test the service as your normal operating user and confirm it can read the media and secret configuration with the permissions you intended.
Set logs so you can inspect why the process stopped, and rotate or limit them to avoid consuming disk space over time. Check disk use, CPU load, memory pressure and network transfer after a trial run. A restart policy only restarts the local process; it does not prove that YouTube has resumed a healthy feed, nor does it manage every broadcast lifecycle decision for you. After a restart, check Live Control Room again.
Use a simple failure sequence. If there is no incoming signal, verify the key and RTMPS URL, then check DNS, outbound connectivity, firewall rules and the FFmpeg error output. If YouTube sees video but no audio, inspect the source and output mapping, then check codec and sample-rate messages. If the picture buffers or health warnings mention bitrate, compare configured output with the VPS’s sustained upload capacity. If warnings mention frame rate or keyframes, inspect the encoder output settings rather than changing unrelated parts of the command.
When a failure happens at a file boundary, test the two neighbouring files together. Compare their codecs, timestamps, dimensions and audio layouts; a problem that appears only at the transition often points to incompatible media or playlist handling. If the source set varies substantially, normalise a copy of the files into a consistent profile and test that set before replacing the live playlist. Keep originals so you can revise the conversion without losing source material.
A cloud-run broadcast can also remove the need to leave a personal computer encoding all night. If that is the specific pain you are trying to remove, StreamNeo turns an uploaded video into a YouTube-only 24/7 stream, so you do not need to keep this Ubuntu process and its host running on your own computer. A VPS remains useful when you need direct control over a custom playlist pipeline or want to manage the encoder yourself; compare the operational work as well as the convenience.
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
Can I stream a folder directly without making a playlist?
You can select files with shell patterns, but the result may not follow the intended order. An explicit playlist makes sequence review easier and helps you test transitions before a long run. The exact playlist format and FFmpeg options depend on your files and workflow.
Does systemd guarantee that YouTube stays live?
No. Systemd can start or restart the local FFmpeg process according to its configuration, but it cannot guarantee network continuity or a healthy YouTube feed. After a restart, verify the preview and health status in Live Control Room.
Should I copy the video streams or re-encode them?
Copying can use less CPU when the files are compatible and already match the output needs. Re-encoding can make varied files more consistent but requires processing capacity and careful testing. Try representative files from your folder and check the result on YouTube before choosing.
Can every Ubuntu VPS sustain a 24/7 stream?
No single configuration works for every VPS, file set or network route. Check the host’s sustained upload capacity and ability to encode the chosen profile, then run a representative test and monitor YouTube’s health messages. Re-test when you change files, settings or the host.