How to Run a 24/7 Live Stream From a VPS

October 18, 2026Mario Marin

Published: 18 October 2026

A stream that never ends, a music channel, a live camera loop, a looping showcase for a game or a product, should not depend on your own computer staying on. Home connections drop, Windows updates restart the machine, and a PC that runs day and night costs more in electricity than a small server. A VPS in a data centre runs the stream instead, around the clock, while your own computer is off. This guide shows the setup that works, with FFmpeg and systemd, and the size of server each kind of stream needs.

Two kinds of 24/7 stream

Before choosing a server, decide which of these you are running, because they need very different amounts of CPU:

A prepared video on a loop. You encode the video once, in exactly the format the platform wants, and the server sends it again and again without touching the picture. This takes almost no CPU, and the smallest VPS can do it.
A stream encoded live. The server builds the picture as it goes: a still image with a music playlist, a clock or a "now playing" title on screen, or several videos with different formats. Encoding video in real time is the heavy part, and the CPU you need grows with the resolution.

What size of VPS you need

Your stream	Suggested plan	Per month, from
Prepared video on a loop, any resolution	Hourly VPS I KVM, 1 vCPU, 2 GB RAM	€4.00
Still image with music, encoded live at 720p	Hourly VPS II KVM, 2 vCPU, 4 GB RAM	€6.00
Live encode at 1080p30 with overlays	Hourly VPS IV KVM, 4 vCPU, 16 GB RAM	€16.00
One stream sent to several platforms, or to viewers directly	Streaming VPS with a 10 Gbps port	€9.99

Prices shown are our lowest, in Bucharest for the hourly plans. Other locations add a small location fee, and the order page shows the exact total for each one. An hourly VPS is billed for at most 720 hours in a month, so running it all month costs the same as the monthly price. Traffic is unmetered on every plan.

Bandwidth is rarely the limit. A 1080p stream at 6 Mbps uses about 1.94 TB a month, and at 10 Mbps about 3.24 TB. The smallest hourly plan has a 100 Mbps port, which is more than ten times what one stream needs. Disk is worth a look, though: an hour of video at 6 Mbps takes about 2.7 GB, so a long playlist may need a larger plan for the storage alone.

Step 1: prepare the video once

For the loop to need no CPU, the file must already be in a format the platform accepts. YouTube's live encoder guide asks for H.264 video with a keyframe every 2 seconds, and never more than 4, at a constant bitrate, with AAC audio at 128 kbps for stereo. This command converts any video into that shape. Run it on your own computer or on the VPS:

ffmpeg -i input.mp4 \
  -c:v libx264 -preset slow -b:v 6000k -maxrate 6000k -bufsize 12000k \
  -g 60 -keyint_min 60 -sc_threshold 0 -pix_fmt yuv420p \
  -c:a aac -b:a 128k -ar 44100 \
  -movflags +faststart stream-ready.mp4

-g 60 gives a keyframe every 60 frames, which is 2 seconds at 30 frames per second. For a 60 fps video, use -g 120 -keyint_min 120. The -b:v 6000k value sets the quality. Check the platform's own guide for the bitrate it recommends at your resolution.

Copy the file to the server, for example with scp stream-ready.mp4 root@your-vps:/srv/stream/.

Step 2: test the loop by hand

Copy the server URL and stream key from YouTube Studio or your platform's dashboard. Then run:

ffmpeg -re -stream_loop -1 -i /srv/stream/stream-ready.mp4 \
  -c copy -f flv "rtmp://a.rtmp.youtube.com/live2/YOUR-STREAM-KEY"

-re sends the video at its real speed instead of as fast as possible, -stream_loop -1 repeats it forever, and -c copy passes the video through untouched. Within a minute the platform's dashboard should show the stream as live. Stop it with Ctrl+C once you have seen it work.

For several videos in a row, list them in a playlist file and loop the playlist. The files must share the same format, so prepare each one with the command from step 1:

# /srv/stream/playlist.txt
file '/srv/stream/part1.mp4'
file '/srv/stream/part2.mp4'

ffmpeg -re -stream_loop -1 -f concat -safe 0 -i /srv/stream/playlist.txt \
  -c copy -f flv "rtmp://a.rtmp.youtube.com/live2/YOUR-STREAM-KEY"

FFmpeg may print a Non-monotonic DTS warning where one file ends and the next begins. It fixes the timestamps itself. If the platform shows a glitch at the joins, switch to encoding live, as in step 4.

Step 3: make it survive anything with systemd

A stream that runs for months will be interrupted sooner or later: a network blip, a platform restart, a server reboot. systemd restarts FFmpeg every time. Put the stream address in a file only root can read:

# /etc/stream.env   (chmod 600)
STREAM_URL=rtmp://a.rtmp.youtube.com/live2/YOUR-STREAM-KEY

Then create the service:

# /etc/systemd/system/stream.service
[Unit]
Description=24/7 live stream
After=network-online.target
Wants=network-online.target

[Service]
EnvironmentFile=/etc/stream.env
ExecStart=/usr/bin/ffmpeg -nostdin -loglevel warning -re -stream_loop -1 -i /srv/stream/stream-ready.mp4 -c copy -f flv ${STREAM_URL}
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Start it and enable it at boot with systemctl enable --now stream. Follow its log with journalctl -u stream -f. If FFmpeg exits for any reason, systemd starts it again five seconds later, and after a reboot the stream comes back on its own.

On YouTube, also look at the stream's settings for starting and stopping the broadcast automatically with your encoder. With automatic stop turned off, a five second restart of FFmpeg does not end the broadcast.

Step 4: a music stream with a still image

A radio style stream is usually one picture and a lot of music. Here the server encodes video live, but a still image is light work. This command loops an audio file over a cover image at 720p:

ffmpeg -re -stream_loop -1 -i /srv/stream/music.mp3 \
  -loop 1 -framerate 30 -i /srv/stream/cover.png \
  -map 1:v -map 0:a \
  -c:v libx264 -preset veryfast -tune stillimage \
  -b:v 1500k -maxrate 1500k -bufsize 3000k -g 60 -pix_fmt yuv420p \
  -c:a aac -b:a 128k -ar 44100 \
  -f flv "$STREAM_URL"

Watch the speed= figure that FFmpeg prints. It must stay at 1x. If it drops below that, the server cannot encode in real time and the stream will stutter, so move to a plan with more vCPU. To run it around the clock, put this command in the ExecStart line of the service from step 3, with ${STREAM_URL} as the address. For a full 1080p30 picture that changes all the time, budget about 4 to 6 cores at the veryfast preset.

Three things the platform will not tell you twice

Long streams are not archived in full. YouTube's help pages say a stream that runs past 12 hours may not be saved as a video, and viewers' rewind is limited on long streams. If you want replays, keep your own recordings or restart the broadcast on a schedule.
You need the rights to everything you play. A 24/7 stream plays the same content thousands of times. Music and video must be yours or licensed for live streaming, or the channel collects copyright claims around the clock too.
The stream key is a password. Anyone with it can broadcast on your channel. Keep it in the protected environment file, not in scripts or screenshots.

When to move up to a streaming VPS

One stream to one platform fits on the smallest hourly VPS. Move to a streaming VPS with a 10 Gbps port when the server has to send the same stream to several platforms at once, serve viewers directly instead of through YouTube or Twitch, or encode several qualities at once. Our guide to the best VPS for streaming covers bitrate and sizing for those cases, and the post on what 10 Gbps gets you explains the port.

Getting started

Order an hourly VPS in the location closest to the platform's ingest or to your viewers, and pick Ubuntu or Debian.
Install FFmpeg with apt install ffmpeg.
Upload your prepared video, test the loop by hand, then turn it into the systemd service above.
Leave it running. Billed hourly, a VPS I KVM costs about 13 cents a day in Bucharest, and if you stop streaming you delete the server and stop paying.