To run a 24/7 YouTube playlist stream from a Linux VPS without OBS, use FFmpeg as the encoder: it reads your media, loops it, and sends the video and audio to YouTube Live Control Room using your stream URL and key. A Linux service manager such as systemd can relaunch FFmpeg after a process failure, but it cannot guarantee that YouTube is receiving a healthy broadcast.
This approach suits you if you are comfortable administering a Linux machine, protecting a stream key and checking logs. First confirm that YouTube Live is enabled for your channel, then test the complete media sequence and outgoing feed before relying on an unattended process overnight.
Check channel access and understand the feed
Your browser and your encoder have different jobs. The browser gives you access to YouTube Studio and Live Control Room, where you create or select a broadcast, copy its ingest URL and stream key, see the incoming preview, inspect stream health and, where required, launch the broadcast. FFmpeg on the VPS is the encoder: it reads your files and sends the outgoing feed to YouTube.
That distinction matters when you troubleshoot. Closing a browser does not itself stop a separate FFmpeg process, but the process must still be running on a reachable VPS with its media available and its internet connection working. YouTube may also require a launch action in Live Control Room, depending on how you set up the stream. Do not treat closing the control room as proof that a public broadcast has started or will continue.
Before you provision the machine, check your channel’s live-stream access. YouTube’s current encoder setup guidance says the channel must be verified, must not have a live-streaming restriction in the previous 90 days, and the user must meet its minimum age requirement of 16. Enabling a channel to stream for the first time may take up to 24 hours, so do not leave that step until the evening you plan to go live. Check the current YouTube encoder setup guidance for the requirements that apply when you configure the channel.
If you are new to the YouTube side of the process, the stream setup and streaming basics guide explains the control-room steps before you move to a command-line encoder. The VPS workflow starts after YouTube has made a broadcast available and you can access its stream settings.
Prepare the playlist before encoding
Keep the source files on the VPS or on storage that the FFmpeg process can read continuously. A simple setup might use a directory of prepared video files and a playlist file that states their order. Decide whether each item should play once in sequence, repeat as a group, or have a particular transition. A loop of one file is easier to test than a mixed playlist with clips of different lengths, audio formats and frame rates.
FFmpeg’s -stream_loop -1 option repeats an input indefinitely. For example, a basic command can loop one local file and send it to YouTube:
ffmpeg -re -stream_loop -1 -i /srv/live/loop.mp4 \
-c:v libx264 -preset veryfast -b:v 8M -maxrate 8M -bufsize 16M \
-r 30 -g 60 -c:a aac -b:a 128k \
-f flv "$YOUTUBE_RTMPS_URL/$YOUTUBE_STREAM_KEY"
This is an example to adapt and test, not a universal command. The video settings in it describe one H.264 720p30 target; if your file has a different resolution, frame rate, codec or audio track, inspect and test it rather than assuming the output will be correct. The command also uses shell variables for credentials. Set those securely in the service environment or a protected configuration file instead of putting a real key in a shell history, public repository or article comment.
For a set of clips, test the exact playlist you intend to broadcast. Unequal durations, mismatched audio and changes in frame rate can cause problems at file boundaries even when each item plays correctly on its own. A clean repeat should not leave a silent gap, a frozen frame or an unexpected jump in the broadcast. Watch the full cycle on a private or otherwise appropriate test setup before making it unattended.
FFmpeg can also pass through compatible compressed streams without re-encoding by using -c copy. That reduces the work the VPS has to do, but it leaves the source streams as they are. If they do not fit the output and ingest settings you need, stream copy may fail or produce an unsuitable feed. Re-encoding gives you more control over output but uses more CPU, so test on the actual VPS with representative motion and sound.
For playlist construction and process details, see the guide to an always-on FFmpeg systemd service. Use it as a companion for the Linux process-management side, while checking the current YouTube documentation for ingest requirements.
Choose output settings and test capacity
Set output resolution, frame rate, codecs and bitrate deliberately. YouTube’s current encoder guidance lists H.264, H.265 or AV1 for video, frame rates up to 60 fps, constant bitrate, and AAC or MP3 for audio. It recommends a two-second keyframe interval, which must not exceed four seconds. Let Live Control Room detect resolution and frame rate by default unless you have a reason to set them manually. Review YouTube’s encoder settings and bitrate guidance before fixing the output command.
For an H.264 output, YouTube lists these bitrate recommendations:
| Output target | YouTube’s listed recommended bitrate | What to consider |
|---|---|---|
| 720p at 30 fps | 8 Mbps | A lower output target can be easier to sustain, but test it with the detail and motion in your source. |
| 1080p at 30 fps | 14 Mbps | Check that your VPS can sustain this outgoing rate continuously, not only in a brief speed test. |
| 1080p at 60 fps | 17 Mbps | Higher frame rate and resolution call for more sustained network capacity and may also increase encoding work. |
These figures are YouTube’s encoder recommendations, not a guarantee that a particular VPS, provider connection or route can carry the feed reliably. YouTube also lists 128 Kbps as its recommended stereo audio bitrate. Choose a target that matches the files and the connection you can monitor, then test with audio and movement similar to the final stream. YouTube recommends running an upload speed test and checking stream health messages during the broadcast.
A speed test is only a snapshot. Sustained upload capacity may vary, and a VPS can also run short of CPU when it re-encodes video. A stream-copy command may ease CPU demand, but only if the source is compatible. If FFmpeg reports encoding overload, test a less demanding output or a suitable preset, then watch the incoming feed; do not assume that a process which remains alive is encoding in real time.
Connect FFmpeg to YouTube securely
In Live Control Room, create or select the stream and copy the server URL and stream key from its settings. Prefer the RTMPS address shown there. YouTube describes RTMPS as RTMP protected with TLS/SSL, and its RTMPS guidance explains how to use the secure ingest address. Do not assume a remembered endpoint is current: copy the URL supplied for the stream you are configuring.
Treat the stream key as a password. Anyone who obtains it may be able to send a feed to the associated broadcast. Keep it out of public files and restrict access to the account that runs FFmpeg. If you need to rotate the key, update the protected configuration and restart the service using the new value.
Run FFmpeg manually first, from the same account and with the same media paths that the eventual service will use. Read its output for connection errors, missing files, unsupported codecs and permission failures. Then check Live Control Room for an incoming preview and stream-health messages. A command that appears to have started is not enough: the control room should show that YouTube is receiving the feed you expect.
If the connection fails, verify that the URL and key belong to the selected stream, that the VPS can reach the ingest endpoint, and that the URL begins with rtmps when using the secure connection. YouTube notes that specifying port 443 can help in some SSL connection configurations. Correct the cause and verify the incoming preview again rather than masking a failed connection with repeated restarts.
Complete the broadcast launch step
Sending an encoder feed and making a broadcast live are related but distinct actions. FFmpeg can connect and YouTube can show an incoming preview while the broadcast has not yet been made public. Depending on how you created or scheduled the stream, YouTube may start it automatically or wait for you to select Go live in Live Control Room.
Check the stream’s status and the launch controls in the browser before you close the control room. If YouTube presents a manual launch step, complete it and confirm that the broadcast is live. If you are using a scheduled stream, review the scheduled-stream settings and current interface rather than assuming that the arrival of video starts it. The distinction is easy to miss when the encoder runs remotely, because a working FFmpeg process can give the impression that the entire broadcast workflow is complete.
For a first run, keep the control room open until you have confirmed both the incoming feed and the live state you intended. Confirm that the title, visibility and selected broadcast are correct as well. An accidental test feed sent to the wrong stream is harder to diagnose after you have disconnected from the browser.
Close the browser only after launch is confirmed
Once the stream is confirmed live, you can close the browser if you do not need it for monitoring or further controls. The browser is not carrying FFmpeg’s video feed; FFmpeg sends that feed from the VPS. But closing the browser does not guarantee that the stream stays live. The VPS process, its access to the media, its network connection and YouTube’s acceptance of the incoming feed all need to continue operating.
Keep another way to check the broadcast available, such as returning to Live Control Room from a separate device or session. A useful first-night routine is to verify the public playback, check the encoder process on the VPS and revisit stream health after the stream has run for a while. If you need a live chat or other browser-based control, closing the control room may also remove access to that particular action even though the encoder feed continues.
A separate prerecorded video streaming guide covers the broader difference between prepared media and live camera input. Here, the key operational point is that the browser controls the YouTube broadcast while FFmpeg supplies the outgoing media.
Keep the VPS, network and service observable
A Linux service manager can start FFmpeg on boot and restart it after a process exit. With systemd, use a dedicated unprivileged account, point the service at stable media paths, and configure restart behaviour deliberately. Keep the stream key in a protected environment file or equivalent secret mechanism readable only by the service account. Store logs somewhere you can inspect, and know how to check both the service status and FFmpeg’s recent output.
A restart policy handles only one class of failure: a process that exits. It does not fix an expired or wrong key, missing media, an unsupported file, full storage, exhausted CPU, a VPS outage, network trouble or a broadcast that YouTube has ended. Nor does it prove that YouTube is receiving usable audio and video. Check the system service and Live Control Room together; a green process status is not a substitute for stream health.
Consider what should happen if the VPS reboots or the connection drops. The service may attempt to reconnect, but check how YouTube reports the event and whether the scheduled broadcast still needs an action. Keep a practical alert or a regular check for process exits and stream-health issues. If the feed matters to a shop, study room or devotional audience, test the recovery procedure before depending on it for an overnight broadcast.
A VPS gives you control over Linux packages, file handling and process policy. In return, you are responsible for updates, credentials, storage, logs, capacity and network behaviour. A hosted workflow may suit you better if maintaining a Linux process is the part you wish to avoid: StreamNeo removes that specific VPS administration work by letting you upload a video and send it to YouTube without keeping your computer running. It is YouTube-only, so it will not fit a workflow that needs another destination.
YouTube says that streams under 12 hours are automatically archived; do not assume a single 24/7 broadcast will become one indefinitely archived video. Check the current controls and how the broadcast is segmented if you need a replay. Also confirm that you have the rights to every video, image, music track and other element in your playlist, and follow YouTube’s Community Guidelines and Terms of Service. No encoder setup decides whether particular content is permitted.
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 close the browser after starting FFmpeg?
You can close the browser after you have confirmed the broadcast is live and completed any required Go live step. FFmpeg sends the feed from the VPS, independently of the browser session. The VPS, its media access and its internet connection still need to keep working, and the control room remains useful for checking stream health.
Does -stream_loop -1 loop a whole playlist?
It repeats the FFmpeg input to which the option applies; it does not automatically define how a collection of files should be sequenced. Build the playlist behaviour deliberately and test a full cycle, including file boundaries and audio. The playlist method depends on your files and the transitions you want.
Will systemd keep the YouTube stream live if FFmpeg crashes?
Systemd can restart a failed process if the service is configured to do so, but the restart alone does not prove that YouTube is receiving a healthy feed. Check the service logs and Live Control Room after a failure. A bad key, unavailable file, resource limit or network problem may persist across restarts.
Is a Linux VPS necessary for a 24/7 playlist?
No. A VPS is one way to keep a command-line encoder and its files available without leaving a personal computer on. It gives you Linux-level control but also makes you responsible for maintenance and monitoring; choose it when that trade-off suits your experience and workflow.