To run a 24/7 YouTube playlist stream on a Vultr Cloud Compute server, use an Ubuntu instance, install OBS Studio and FFmpeg, connect OBS to a YouTube live event, and play media stored on the server. Vultr documents uploading source files and enabling OBS’s Loop option; that documented example is a looped source, not a guarantee that every multi-file playlist format will work unchanged.
This walkthrough follows Vultr’s published Ubuntu and Broadcaster guidance, while separating provider instructions from practical checks you should perform on your own instance. A cloud server means the media need not remain on your personal computer, but continuous availability still depends on sizing, network conditions, software behaviour and monitoring.
Choose and prepare a Vultr server
Create a Vultr Cloud Compute instance with an Ubuntu image. Vultr’s OBS and Ubuntu streaming guide lists a tutorial prerequisite of 2 vCPUs, 4 GB of memory, 80 GB of storage and 3 TB of bandwidth. Treat these figures as that guide’s example baseline, not as a tested minimum for every resolution, bitrate, encoding method or workload. The guide is dated 2025; do not assume its figures establish the right plan for your use today.
A server has to do more than hold a video file. It must read the media, encode or pass through the audio and video, and send the resulting stream to YouTube. Estimate storage for the files you plan to keep on the instance, and estimate monthly outgoing traffic using your chosen bitrate and broadcast hours, with room for protocol overhead. The available documentation does not establish a universal bitrate or current Vultr price for this use.
Vultr describes Cloud Compute as shared-CPU virtual machines and notes that configurations can be scaled. Shared CPU does not itself tell you whether your OBS encoding workload will keep up. Watch OBS’s CPU use and dropped-frame indicators after setup; if encoding cannot keep pace, lower output demands or consider a larger or different compute option. That is an adjustment to test, not a promise that a particular plan will solve every problem.
The Vultr tutorial’s prerequisite is useful as a place to begin comparing resources, but your media and intended output matter. A single lower-resolution devotional loop and a set of large, high-resolution clips do not impose the same storage and encoding demands. If you are comparing cloud approaches, the guide to running a 24/7 stream on an Azure virtual machine offers a separate provider-specific setup to consider; its steps should not be substituted blindly for Vultr’s.
Install OBS Studio and FFmpeg on Ubuntu
Follow the installation sequence in Vultr’s OBS/Ubuntu guide for the Ubuntu release and package instructions it covers. It describes installing both OBS Studio and FFmpeg. Keep the distinction clear: this is a documented desktop OBS workflow. The material here does not provide a complete supported command for running arbitrary playlists in a headless FFmpeg-only service, so do not treat the OBS steps as instructions for that different setup.
After installation, confirm that OBS opens and can see the audio and video devices or sources you intend to use. A cloud instance may have no physical capture devices, which is not a problem if your programme is made from media files, but it changes what you need to configure. Use OBS’s preview to check that the selected source actually produces both picture and sound before publishing.
FFmpeg can be useful in media workflows, but having it installed does not automatically create a playlist or a reliable restart service. Vultr’s published instructions are the basis for the OBS route described below. If your requirement is specifically an ordered or shuffled succession of separate files, compare that goal with the single-source loop described here and consult a workflow that explicitly supports playlists, such as this article on shuffling videos in an FFmpeg YouTube live playlist. Do not assume the formats and commands in one workflow apply to the other.
Also avoid treating a successful installation as proof that the stream will stay live unattended. Software versions, Ubuntu packages and desktop session behaviour can differ. The tutorials explain setup, but they do not certify every combination or promise continuous availability.
Create the YouTube live event and protect its key
In YouTube Studio, create or schedule the live event you plan to show. Retrieve the stream URL and stream key from the live setup, then configure the encoder to use that information. Vultr’s tutorial walks through this Studio-to-OBS flow. YouTube’s live streaming documentation explains how to set up and manage a live stream; check the current instructions in Studio because its interface and event options can change.
A stream and a broadcast are related but distinct: the stream is the incoming audio/video feed and its settings, while the broadcast is the event viewers see. YouTube’s Live Streaming API resource documentation describes these objects and their relationship. For a straightforward channel setup, you can create the event in Studio rather than building an API integration.
Treat the stream key as a credential. Anyone who obtains it may be able to publish to the associated channel, so do not paste it into a public note, share it in a screenshot, or leave it exposed in an unsecured script. Limit access to the Vultr account and instance as well. The practical guide to protecting YouTube stream keys on a cloud server covers the risk and handling considerations in more detail.
OBS’s service configuration is the simplest starting route in Vultr’s walkthrough. YouTube supports several third-party ingest protocols, but the correct ingest address and key must come from your channel’s live setup or an official API response. Do not copy a guessed endpoint from an example into your live configuration.
Upload the source media to the server
For a stream that should continue from the cloud, the media source needs to be available to the server. Vultr’s Broadcaster Marketplace guide explicitly advises uploading source files to the server for a 24/7 stream, then configuring OBS to use them. This is the key difference from playing a file that exists only on a home or office computer: the cloud instance can read its own copy after that computer is switched off.
Transfer the files using a method you can operate securely, and keep them in a directory that the account running OBS can read. Check that the upload completed and that the file opens before you build the scene around it. A partial upload, unsupported container, missing audio track or unreadable directory can leave you with a black preview or silent output even though OBS itself is running.
Plan the server’s storage against the source material you expect to retain. If you rotate media, remove files only after confirming they are no longer part of the active scene or schedule. A mounted volume or other storage arrangement may have different persistence and access behaviour; check Vultr’s current documentation for the product you choose rather than assuming every instance storage option behaves alike.
The word “playlist” can refer to several things: one video set to repeat, a sequence of separate OBS media sources, or a playlist file interpreted by a player. The provider-backed instructions in this article support the first meaning most directly: add a source and turn on Loop. If you need a timed sequence of separate clips, establish which OBS source or playback method supports it and test transitions before relying on it overnight. Organising files clearly helps, as explained in how to organise video files for a 24/7 stream on a VPS.
Configure OBS to send the stream
Open OBS and create a scene for the programme you want viewers to see. Add the uploaded media as a source, then verify the picture and sound in the preview. Select YouTube as the service if you are following Vultr’s documented configuration, and enter the stream key in the designated field. Use the stream URL supplied by the channel’s live setup if the configuration asks for it.
Set the output resolution, frame rate and encoding settings with the instance’s capacity and the media in mind. More demanding output can consume more compute and outgoing bandwidth. The Vultr tutorial recommends watching CPU and bandwidth; if CPU load is high or OBS reports dropped frames, reduce output demands or increase compute and check whether the issue improves. Do not regard the example server resources as a performance promise.
For transport, YouTube’s protocol comparison includes RTMP, RTMPS, HLS and DASH. Google’s YouTube Live Streaming API protocol documentation describes RTMPS as RTMP carried through SSL. It requires the valid RTMPS URL and path, port 443, and the server hostname for SNI authentication. The particular endpoint is not interchangeable with an ordinary RTMP address; use the one YouTube provides and ensure your encoder supports the intended protocol.
| Ingest choice | Encryption and practical fit | What to check |
|---|---|---|
| RTMP | Standard option supported by many encoders; the connection is not encrypted in the way RTMPS is. | Use the channel’s provided address and confirm OBS is configured for the matching service. |
| RTMPS | RTMP over SSL, with encryption for the ingest connection; a practical choice when supported by your encoder. | Use the correct RTMPS URL and path, port 443 and hostname/SNI details from the official setup. |
| HLS or DASH | Encrypted options associated with advanced codecs and higher latency in YouTube’s comparison. | Confirm that the encoder supports the required protocol and codec, and that the latency suits the channel. |
For an OBS-based basic stream, follow the service settings Vultr documents rather than changing protocols without a reason. If you need lower latency, a particular codec or another encoding path, check YouTube’s current compatibility requirements and confirm OBS can deliver them. Protocol support does not remove the need to check source quality, encoding load or the event’s settings.
Set firewall rules with the direction of traffic in mind
An OBS push encoder initiates a connection out to YouTube. That does not mean you need to open public inbound RTMP port 1935 so YouTube can reach your Vultr instance. Port 1935 is relevant to arrangements that receive RTMP input or serve an RTMP relay, which is a different network design.
Vultr Firewall Groups filter inbound traffic and can be attached to an instance. Keep administrative access restricted to trusted sources, and check both the Vultr-level rules and Ubuntu’s host firewall if OBS cannot connect or you cannot administer the machine. Do not disable protections as a general fix. For an RTMPS push, check that outbound access can reach the correct YouTube endpoint and port; consult the current Vultr Firewall documentation for the provider-side controls.
A firewall change can solve one connection problem while creating another exposure. Record what you changed and why, and avoid opening services that the chosen push workflow does not use. If you have a separate remote-control or relay requirement, document it independently from the YouTube publishing connection.
Enable Loop, test the hand-off and watch the stream
In OBS, enable Loop for the media source as Vultr’s Broadcaster guide describes. This repeats that source when playback reaches its end. It is not, by itself, a schedule for rotating across every file in a folder. If your intended programme is a series of clips, test the actual sequence using the playback method you selected instead of assuming the Loop checkbox creates a multi-file playlist.
Before going live, use OBS preview to confirm the media starts at the right point, audio is audible and the repeat behaviour is what you expect. Watch at least one transition through the end and back to the start. This is an operational check, not a guarantee against later software, network or server failures. Verify the event’s visibility and title in YouTube Studio, then start the broadcast when you are ready for viewers to see it.
Vultr’s OBS tutorial recommends automatic reconnect settings and monitoring CPU and bandwidth. Those settings can help OBS attempt to resume after a connection interruption, but reconnect behaviour is not the same as uninterrupted availability. Check the stream from YouTube’s viewer side as well as the OBS status, since an encoder can appear active while viewers encounter a stalled or silent feed.
For an unattended channel, decide who will receive an alert or check the stream if it stops. The cited Vultr guides do not provide a tested systemd service definition for restarting every OBS configuration, so do not copy an unverified service recipe into production. A supervised startup or restart method may be useful, but validate it against your Ubuntu and OBS versions and test what happens after a reboot before relying on it.
A 24/7 schedule also deserves a recovery plan: keep a copy of the source media somewhere you can restore from, note the Studio event and stream settings, and know how to rotate the stream key if it is exposed. If the server repeatedly drops frames, inspect CPU load and network use before assuming the YouTube event is at fault. If the preview is smooth but the viewer-side stream freezes, use a separate troubleshooting process, such as this guide to fixing a YouTube live stream that freezes but stays online.
When the maintenance burden is mainly keeping a personal computer running and manually restarting a dropped broadcast, StreamNeo can remove that specific task by running an uploaded video as a YouTube live stream without leaving your computer on. It is YouTube-only, and you still need to prepare appropriate media and channel settings.
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 a Vultr server keep the stream running without my computer?
The media can be uploaded to the Vultr instance, and OBS can read that server-side copy, so your personal computer does not need to hold the source file or stay on for playback. The stream still depends on the instance, OBS, its network connection and YouTube accepting the feed; the setup does not guarantee uninterrupted availability.
Does OBS Loop create a playlist of separate videos?
Loop repeats the media source you have configured. Vultr’s documented example supports looping a source, not a claim that every playlist format or folder of clips will be interpreted as an ordered playlist. Test the exact source and playback method you intend to use.
What Vultr plan should I choose?
Vultr’s OBS/Ubuntu guide gives an example prerequisite of 2 vCPUs, 4 GB RAM, 80 GB storage and 3 TB bandwidth, but that is not a universal performance guarantee. Estimate storage and monthly transfer for your own media and output, then monitor actual CPU use and dropped frames after setup.
Should I open inbound RTMP port 1935?
Not for the basic push workflow described here: OBS connects out to YouTube, so opening inbound RTMP access is not inherently required. Restrict administrative access and check provider and host firewall rules if the connection fails.