How to Run a 24/7 YouTube Stream on a $5 VPS (Full Setup Guide)

Running a 24/7 YouTube stream doesn’t require expensive hardware or a powerful home PC running around the clock. With the right VPS configuration, you can maintain a continuous broadcast for as little as $5 per month — less than the cost of your monthly coffee habit.

This guide breaks down exactly what you need:

• Minimum VPS specs for different stream types (audio-only, 720p, 1080p)
• Step-by-step setup using FFmpeg on Ubuntu
• Real cost comparisons between home streaming and VPS solutions
• Provider recommendations based on actual streaming workloads

Whether you’re launching a lo-fi beats channel, ambient music stream, or 24/7 radio station, these specifications will get you streaming without overspending.

Need a broader overview of streaming server software (RTMP, SRS, Icecast)? Start with our complete video streaming server guide.

Why Stream From a VPS Instead of Home

Streaming from your home computer seems like the obvious choice — it’s already there, and there’s no monthly fee. But the hidden costs add up quickly.

The Real Cost of Home Streaming

Running a PC 24/7 consumes significant electricity. A mid-range desktop draws 150–300 watts under streaming load. At the US average of $0.12 per kWh, that’s $13–26 per month in electricity alone — already more than a budget VPS.

Then there’s the wear on your hardware. Fans running constantly, drives spinning non-stop, and thermal cycling all reduce component lifespan. Replacing a $200 GPU or $150 power supply every few years isn’t cheap.

Home internet adds another layer of problems. Most residential ISPs offer asymmetric connections — fast downloads but limited uploads. A 1080p stream at 6 Mbps needs at least 8–10 Mbps of stable upload bandwidth. Many home connections can’t deliver that consistently, especially during peak evening hours when neighbors are streaming Netflix.

What a VPS Solves

A VPS operates from a data center with enterprise-grade infrastructure:

For a 24/7 stream, reliability matters more than raw power. A brief outage at 3 AM might go unnoticed, but a six-hour dropout during peak hours kills your watch time and algorithm ranking.

Minimum VPS Specs by Stream Type

Not all streams need the same resources. A lo-fi audio stream with a static image requires far less power than a 1080p video loop with overlays.

Audio-Only / Static Image Streams

This is the most efficient setup — perfect for internet radio, ambient music channels, or lo-fi beats streams. FFmpeg encodes a single image and audio track with minimal CPU usage.

Estimated cost: $5–9/month

This configuration handles streams like:

• 24/7 lo-fi radio with album art
• Ambient soundscapes with a single background image
• Podcast reruns with a static logo

You can head directly to our Unmanaged level plans to get started with a $5 VPS anywhere in the world.

720p Video Loop Streams

Adding video motion increases CPU requirements. A looping video at 720p30 needs real-time encoding.

Estimated cost: $9–20/month

Good for:

• Music visualizers
• Nature footage loops (rain, fireplace, ocean)
• Relaxation/study streams

1080p Video Streams

Full HD requires more processing power, especially at 60fps.

Estimated cost: $15–30/month

For production quality, consider streaming-optimized VPS plans with guaranteed CPU allocation rather than shared resources.

The $5 Setup: Audio-Only and Simple Video Loops

Let’s build the most cost-effective streaming server possible. This setup handles 24/7 audio streams with a static image — the bread and butter of lo-fi and ambient channels.

What You’ll Get

• Ubuntu 22.04 LTS server
• FFmpeg for encoding
• A single stream to YouTube (expandable later)
• Automatic restart on failure
• ~$7/month total cost

Step-by-Step: Ubuntu + FFmpeg to YouTube

This walkthrough gets you from a fresh VPS to a live YouTube stream in under 30 minutes.

Step 1: Initial Server Setup

Connect to your VPS via SSH and update the system:

# Update package lists and upgrade existing packages
sudo apt update && sudo apt upgrade -y

# Install FFmpeg
sudo apt install ffmpeg -y

# Verify installation
ffmpeg -version

Step 2: Upload Your Media Files

Create a directory for your stream assets:

mkdir -p ~/stream
cd ~/stream

Upload your files using SCP from your local machine:

# From your local terminal (not the VPS) 
scp background.jpg user@your-vps-ip:~/stream/ 
scp playlist.mp3 user@your-vps-ip:~/stream/

For a simple setup, you need:

• One image file (JPG or PNG, 1920×1080 recommended)
• One audio file or playlist (MP3, concatenated into a single long file)

Step 3: Get Your YouTube Stream Key

1. Go to YouTube Studio
2. Click “Create” → “Go Live”
3. Select “Stream” → “Streaming software”
4. Copy your Stream Key (keep this secret!)

Step 4: Create the Streaming Script

Create a script that loops your content and streams to YouTube:

nano ~/stream/start-stream.sh

Paste this configuration:

#!/bin/bash

# YouTube RTMP endpoint
YOUTUBE_URL="rtmp://a.rtmp.youtube.com/live2"
STREAM_KEY="your-stream-key-here"

# File paths
IMAGE="$HOME/stream/background.jpg"
AUDIO="$HOME/stream/playlist.mp3"

# Stream settings
VIDEO_BITRATE="1500k"
AUDIO_BITRATE="128k"
FPS="30"

# Start streaming with infinite audio loop
ffmpeg -loop 1 -i "$IMAGE" \
       -stream_loop -1 -i "$AUDIO" \
       -c:v libx264 -preset ultrafast -tune stillimage \
       -c:a aac -b:a $AUDIO_BITRATE -ar 44100 \
       -b:v $VIDEO_BITRATE -maxrate $VIDEO_BITRATE -bufsize 3000k \
       -pix_fmt yuv420p -g 60 \
       -f flv "$YOUTUBE_URL/$STREAM_KEY"

Make it executable:

chmod +x ~/stream/start-stream.sh

Step 5: Test Your Stream

Run the script manually first:

~/stream/start-stream.sh

Check YouTube Studio — your stream should appear within 30 seconds. Watch for a few minutes to confirm stability, then press CTRL + C  to stop.

Step 6: Run as a Background Service

For 24/7 operation, create a systemd service that auto-restarts on failure:

sudo nano /etc/systemd/system/youtube-stream.service

Paste this configuration:

#!/bin/bash

# YouTube RTMP endpoint
YOUTUBE_URL="rtmp://a.rtmp.youtube.com/live2"
STREAM_KEY="your-stream-key-here"

# File paths
IMAGE="$HOME/stream/background.jpg"
AUDIO="$HOME/stream/playlist.mp3"

# Stream settings
VIDEO_BITRATE="1500k"
AUDIO_BITRATE="128k"
FPS="30"

# Start streaming with infinite audio loop
ffmpeg -loop 1 -i "$IMAGE" \
       -stream_loop -1 -i "$AUDIO" \
       -c:v libx264 -preset ultrafast -tune stillimage \
       -c:a aac -b:a $AUDIO_BITRATE -ar 44100 \
       -b:v $VIDEO_BITRATE -maxrate $VIDEO_BITRATE -bufsize 3000k \
       -pix_fmt yuv420p -g 60 \
       -f flv "$YOUTUBE_URL/$STREAM_KEY"

Replace “your username” with your actual username. Enable and start the service:

sudo systemctl daemon-reload
sudo systemctl enable youtube-stream
sudo systemctl start youtube-stream

Check status:

sudo systemctl status youtube-stream

Your stream now runs continuously and automatically restarts after any interruption.

Automate a 24/7 Twitch Restream or Recording With a Script

The YouTube script above pushes one feed to one platform. But a lot of people running an always-on channel want two more things: mirror the same stream to Twitch, and keep a local recording so nothing is lost. You do not need a second encoder or a paid multistream SaaS for either — the same FFmpeg-plus-systemd pattern handles it. This is the part most “best VPS for streaming” guides skip, so here is the exact setup.

Restream to Twitch (and YouTube) at the Same Time

Twitch ingests RTMP at rtmp://live.twitch.tv/app/YOUR-TWITCH-KEY (swap in a regional ingest like live-fra or live-lax if it is closer to your VPS). To send one encode to two destinations, you encode once and duplicate the packets with FFmpeg’s tee muxer — this is the trick that keeps CPU flat instead of running two encoders:

#!/bin/bash

# Endpoints
YOUTUBE_URL="rtmp://a.rtmp.youtube.com/live2/YOUR-YOUTUBE-KEY"
TWITCH_URL="rtmp://live.twitch.tv/app/YOUR-TWITCH-KEY"

# Source files
IMAGE="$HOME/stream/background.jpg"
AUDIO="$HOME/stream/playlist.mp3"

# Encode ONCE, then fan out to both platforms with tee
ffmpeg -re -loop 1 -i "$IMAGE" \
       -stream_loop -1 -i "$AUDIO" \
       -c:v libx264 -preset veryfast -tune stillimage -pix_fmt yuv420p \
       -b:v 2500k -maxrate 2500k -bufsize 5000k -g 60 -keyint_min 60 -r 30 \
       -c:a aac -b:a 128k -ar 44100 \
       -f tee -map 0:v -map 1:a \
       "[f=flv]$YOUTUBE_URL|[f=flv]$TWITCH_URL"

Two caveats we have hit in practice. First, Twitch caps most non-partner channels around 6,000 kbps and prefers a ~2-second keyframe interval — the -g 60 -keyint_min 60 above gives you that at 30fps, so do not raise the bitrate past what Twitch accepts or it will reject the ingest. Second, Twitch’s terms restrict simulcasting the exact same live content to other “Twitch-like” services for some partners — mirroring to YouTube is fine for the vast majority of creators, but check your own status if you are a Twitch Partner. (RTMP is used here because both platforms accept it; if you are pushing over a lossy uplink from the field first, weigh the streaming protocol you push, RTMP vs SRT, before it reaches the VPS.)

Record the Stream to Disk on a Schedule

If you want an archive on the server instead of (or as well as) a live restream, point FFmpeg at the source and write a segmented MP4. The segment muxer rolls a new file every hour so a weekend of recording does not become one un-openable 40 GB file:

# Record the same loop to hourly MP4 files in ~/recordings
ffmpeg -re -stream_loop -1 -i "$HOME/stream/playlist.mp3" -loop 1 -i "$HOME/stream/background.jpg" \
       -c:v libx264 -preset veryfast -pix_fmt yuv420p -b:v 2500k \
       -c:a aac -b:a 128k \
       -f segment -segment_time 3600 -reset_timestamps 1 -strftime 1 \
       "$HOME/recordings/stream-%Y%m%d-%H%M%S.mp4"

To capture an existing live source (say you already push from home and just want the VPS to keep a copy), replace the two -i inputs with the ingest URL you are pulling from. Wrap either command in its own systemd unit exactly like the youtube-stream.service above, and add a cron job to prune old recordings so the disk never fills:

# Delete recordings older than 7 days, every night at 04:00
0 4 * * * find "$HOME/recordings" -name "stream-*.mp4" -mtime +7 -delete

Recording plus restreaming is real, sustained disk and network load, so this is where a shared-CPU budget box starts to hurt. If FFmpeg reports speed= below 1.0x while doing both, you have run out of headroom — see the throttling signs below.

The 12-Hour Archive Trap (and How to Beat It)

One reader asked exactly the right question: what happens on a truly non-stop stream? YouTube does not limit how long you can broadcast — you can run for weeks — but it only auto-saves a stream as a replayable VOD if that single broadcast is under 12 hours. Cross 12 hours in one continuous session and the archive may not be captured at all, and you can pick up a duplicate/re-broadcast community strike. The clean fix is to script a restart: stop and relaunch the broadcast every ~11 hours so each segment archives as its own VOD (a systemctl restart youtube-stream on an 11-hour timer does it), or keep the server-side recording above as your safety copy. This is a workflow detail, not a hardware one — but it is the difference between a channel that builds a back-catalog and one that streams into the void.

Hidden Costs to Avoid

The $5/month headline only holds if you avoid common pitfalls.

Bandwidth Overages

Some providers advertise “unlimited” bandwidth but throttle after hitting soft caps. Others charge overage fees that can exceed your base plan cost.

A 24/7 stream at 2 Mbps uses about 650 GB per month. At 6 Mbps (1080p), expect 2 TB. Verify your provider’s actual bandwidth allowance before committing.

If you want true VPS bandwidth allocation up to 8 GBPS, you may check our streaming VPS.

CPU Throttling on Shared Plans

Budget VPS plans often use shared CPU resources. During peak hours, your encoding might slow down, causing dropped frames or stream interruptions.

Signs of CPU throttling:

• Sudden frame drops in YouTube Studio
• FFmpeg reporting “speed=0.8x” or lower (should be 1.0x or higher)
• Inconsistent stream quality

If you experience throttling, consider dedicated streaming VPS plans with guaranteed CPU allocation.

Storage Filling Up

FFmpeg can generate temporary files, and system logs grow over time. A full disk crashes your stream.

Set up automatic log rotation and monitor disk usage:

# Check disk usage
df -h

# Clean old logs
sudo journalctl --vacuum-time=7d

When to Upgrade

Your $7 setup handles a single audio/static image stream comfortably. Here’s when you need more:

For complex setups with multiple output destinations or real-time graphics, review our guide on setting up a video streaming server.

OBS on a VPS vs FFmpeg: Which Should You Use?

The upgrade table earlier hints at “OBS on Windows VPS” for overlays — here is the honest tradeoff so you pick right the first time. For a headless 24/7 loop, radio station, or any restream, FFmpeg wins: it is a single process, sips CPU, restarts cleanly under systemd, and never needs a desktop. That is why every script in this guide uses it.

Reach for OBS only when you genuinely need what OBS does and FFmpeg does not — live scene switching, browser-source alerts, chat overlays, or a real-time “Starting soon” screen. The cost is real: OBS wants a graphical session (a virtual display via Xvfb on Linux, or an RDP desktop on a Windows VPS), several times the RAM, and it is heavier to keep alive unattended.

Our rule of thumb: if a human is not touching the stream during the day, use FFmpeg; if the layout changes live, use OBS. If you are still learning the ropes, how to start a Twitch channel the right way walks through the OBS side before you move it to a server.

Conclusion

A reliable 24/7 YouTube stream doesn’t require enterprise hardware or a dedicated PC running in your closet. With the right VPS configuration:

• $5/month covers audio streams with static images
• $9-30/month handles 720p–1080p video loops
• Uptime exceeds 99.9% — far better than home setups
• Setup takes under 30 minutes with the commands provided

The key is matching your specs to your actual needs. Start with the minimum viable configuration, monitor performance for the first week, and scale up only when necessary.

Ready to launch your 24/7 stream? Explore streaming-optimized VPS plans designed for continuous broadcasting workloads

Frequently Asked Questions