Cheapest VPS for YouTube Streaming in 2026: Prices, Setup and Security

Running a VPS without regular care is a security risk from the first minute it’s online. Bots scan the internet for new servers and start guessing their logins within minutes. The VPS that ran our old blog logged 302855 failed logins from 3209 addresses in 31 days, about 7 password guesses a minute. Most guesses fail, but one weak spot, like a weak password or a missed update, is enough. Anyone who gets in also gets your stream key. With it they can broadcast adult content or illegal material on your channel, and YouTube can end a channel over that. Keeping a server safe is ongoing work that needs server know-how. You lock down the logins, install security fixes and watch the logs for as long as the stream runs.

A VPS, or virtual private server, is a bare Linux machine you rent in a data center. Nothing for streaming comes installed, so you set it all up by hand in a terminal. That includes the streaming software, a service that restarts the stream after a crash and the security settings. The cheapest setup is a plain loop with FFmpeg, a free command line program. You convert each video first to the settings YouTube recommends, with FFmpeg or an app like HandBrake. FFmpeg then sends that file to YouTube over and over, without converting it again. The picture is only ever that file, with no song title, overlay or widget. A new song or video means editing that file again and restarting the stream. A stream like the ones Upstream runs, with overlays, widgets and a playlist you can change while it stays live, takes OBS on the server. OBS needs a desktop on the server and encodes the picture live, frame by frame, so it needs a plan with dedicated cores.

The price that compares with Upstream is a VPS that re-encodes live. Upstream encodes its streams live too. Once your videos come from different sources or you add overlays, FFmpeg has to re-encode the video as it plays. In our own test on DigitalOcean (below), the cheapest plan that kept up with a live re-encode at 1080p was $84 a month, even with all 10 clips converted first. The cheapest VPS only works for a plain loop of one prepared file, such as OVHcloud’s VPS-1 at €4.49 a month before VAT, or netcup’s VPS pico at €2.21 a month on a 12-month plan paid upfront. We checked prices on October 23 and 24, 2026. Upstream’s first streams were encoded live on shared servers, and they lagged whenever a neighbour got busy. We moved them to dedicated servers in 2024, even though they cost us more.

Comparison of VPS plans for a 24/7 YouTube stream

These are the cheapest plans. They can copy one prepared file to YouTube, but they can’t re-encode a stream live, which is the work Upstream does on its own servers (see our test below). The table compares one plan from each provider, sorted by what one stream costs for a full month with traffic. We checked the providers’ own pricing pages on October 23, 2026. Prices appear the way the providers show them: netcup’s include 19% German VAT, the other euro prices don’t, and dollar prices are before sales tax. The last column adds traffic charges for one stream at about 6.2 Mbps, our estimate.

Check the traffic charges before you pick a plan. OVHcloud and netcup don’t count traffic in Europe, and Hetzner includes 20 TB, so their price is the whole bill for one stream. DigitalOcean’s $6 plan includes 1000 GiB and charges $0.01 per extra GiB, so one 1080p stream comes to about $14.60. Vultr’s $5 plan covers a stream only because Vultr adds 2 TB a month per account on top of the plan.

A US channel can stream from a server in Europe, because the server only needs a steady connection to YouTube. If you want the server in the US, OVHcloud’s VPS-1 costs $5.35 there with unlimited traffic, and DigitalOcean and Vultr charge the same in their US data centers. Hetzner costs more in the US, where its cheapest plan is €17.99 with 1 TB of traffic.

Oracle’s free tier is a risky home for a stream that has to stay up. Oracle says idle Always Free servers may be reclaimed, and it counts a server as idle when its processor use (at the 95th percentile) and network use stay under 20% for a week. A 6 Mbps stream on the free Micro server uses about 12% of its 50 Mbps.

netcup VPS pico: €2.21 a month on a yearly plan

netcup’s smallest plan has 1 core, 1 GB of memory and traffic that only slows down if your daily average goes above 100 Mbps, far more than one stream sends. You pay 12 months at once, it runs only in Nuremberg, and each customer can order one. Its one core is shared with other customers, so it suits a plain loop and nothing heavier.

OVHcloud VPS-1: €4.49 a month, no contract

OVHcloud’s VPS-1 has 2 cores, 4 GB of memory and unlimited traffic at 500 Mbps in its European and US data centers. It’s the cheapest plan we found that you can cancel any month, and it drops to €3.81 a month on a 12-month commitment.

Hetzner CPX02: €6.49 a month, with 20 TB of traffic

Hetzner’s CPX02 in Germany or Finland includes 20 TB of traffic, about ten times what one 1080p stream uses, and bills by the hour up to the monthly price. Hetzner’s own page says to expect about 300 to 500 Mbit/s with no guarantee. Its cheaper Cost-Optimized plans showed as not available when we checked.

Contabo Cloud VPS 4: €4.40 a month on a 24-month term

Contabo gives the most processor and memory for the money, 4 shared cores and 8 GB, but the €4.40 price needs a 24-month term. Its traffic has no fixed cap and falls under a fair-use policy that lets Contabo slow servers that use a lot.

DigitalOcean: $6 a month, plus traffic

DigitalOcean’s $6 plan looks cheap, but its 1000 GiB of traffic runs out after about 16 days of 1080p streaming. The rest costs $0.01 per GiB, which takes the month to about $14.60. The $12 plan includes 2000 GiB and covers one stream.

Oracle Cloud Always Free: $0, if Oracle keeps it running

Oracle’s free tier includes small servers and 10 TB of outbound traffic a month. A light stream can count as idle under Oracle’s rule, and idle free servers may be reclaimed, so treat it as a test machine.

How much server a 24/7 stream needs

It depends on what the stream does. A plain loop uses FFmpeg’s copy mode, which sends a prepared file without converting it again, so it needs little processor time. OBS does far more work. It draws your whole scene frame by frame, with the video, the song title, the clock and any widgets, and encodes it live. On a VPS with no graphics card, the processor does all of that.

Most channels don’t have one prepared file. Say your stream has 10 videos, each with its own bitrate. A few came from a phone at 60 fps, one from an iPhone in 4K and one from an editing app, and some are older 720p clips. FFmpeg can only copy files back to back when their settings match exactly. So you either convert all 10 to the same settings before they go on the server, and again whenever you add one, or let FFmpeg re-encode the stream live. Separate music needs at least the audio re-encoded, and a song title or a clock on screen needs the video re-encoded. Upstream always runs that live re-encode, so it’s the fair price to compare.

Both need their processor time on schedule, and live encoding needs a lot of it. The cheap plans above share their cores with other customers. DigitalOcean’s own docs say a shared server gets less processor time when its neighbours are busy, and that full access is “not guaranteed.” When that happens, the encoder falls behind and viewers see buffering. A plain loop can stutter the same way, but it needs so little that it usually keeps up.

We learned this running Upstream. Our first streams were encoded live, the same work OBS does, on shared cloud servers. A stream could run fine one day and lag the next, when another customer on the same machine got busy. On November 14, 2023, it hit close to a third of our customers at once. Our monitoring showed lag on stream after stream, and customers started writing in. Our support chat had four times its usual load that day, the busiest of the year.

An infrastructure engineer joined us soon after, and in 2024 we moved our streams to dedicated servers. The lag reports went away. Dedicated servers cost us more than shared ones, and we wouldn’t pay that if shared servers had held up. A test week wouldn’t have caught any of this, because the neighbours on a shared machine can change any day.

For OBS or any live encoding, pick a plan with dedicated cores. DigitalOcean’s CPU-Optimized plans start at $42 a month for 2 dedicated vCPUs and cost $84 for 4, and DigitalOcean recommends them for “media streaming.” Hetzner’s CCX13, with 2 dedicated vCPUs, is €43.49 a month before VAT and was sold out when we checked on October 24, 2026. In our test, a 1080p live re-encode with overlays and separate music kept up only on DigitalOcean’s $84 CPU-Optimized plan with 4 dedicated vCPUs.

To work out traffic, multiply the total bitrate by the seconds in a month and divide by 8. The setup below sends 6 Mbps of video and 160 kbps of audio, so 6160000 × 2592000 ÷ 8 comes to about 2.0 TB a month before network overhead. YouTube’s live encoder settings put the minimum for 1080p at 30 fps at 5 Mbps and recommend 14 Mbps for H.264. 6 Mbps looks fine for calm lofi video. At 14 Mbps a stream sends about 4.6 TB a month, which costs more on plans that charge for traffic.

We tested live re-encoding on four DigitalOcean plans

To see what live re-encoding needs on a VPS, we rented four DigitalOcean servers on October 24, 2026 and ran the same stream on each for 10 minutes. It played 10 clips in a loop, from 480p to 4K and from 24 to 60 fps, including two in the HEVC format iPhones record in. FFmpeg scaled each clip to 1080p at 30 fps, put a logo, a now playing line and a clock on top, mixed separate music with a rain-style ambience, and encoded it all with x264’s veryfast preset at 6 Mbps, the default software encoder setting in OBS. Then we ran it again sending the stream to three platforms at once, plus a second vertical 1080x1920 copy for TikTok or Shorts.

Only DigitalOcean’s $84 CPU-Optimized plan with 4 dedicated vCPUs kept up with one stream, and none of the four kept up with the multistream. The two shared plans fell far behind, and so did the $42 plan with 2 dedicated vCPUs, at 0.75x. A stream that runs slower than real time sends fewer frames than viewers need, so YouTube reports poor stream health and viewers see buffering.

Converting all 10 clips first doesn’t change the answer. We ran the test again on the $42 and $84 plans with all 10 clips converted beforehand to matching 1080p at 30 fps, the prep work a plain loop needs anyway. The $42 plan got closer, at 0.89x, and still fell behind. The $84 plan kept up with one stream with room to spare, but the multistream still fell behind, at 0.93x.

Upstream costs less than the cheapest VPS that kept up: $30 a month against $84, or $288 a year against $1008. That’s $54 a month less, before you count the hours of setup and upkeep on the VPS, and it holds even with the clips converted first. Upstream does the re-encode on its own servers, so you never size or pay for a processor.

Your numbers will vary with the processor and the encoder preset. A faster preset such as ultrafast needs less processor time but makes the picture softer at the same bitrate.

A new VPS gets attacked within minutes

Bots scan the whole internet all day for servers that accept logins, so a new server gets found fast. In a 2019 study, Sophos put 10 test servers online in Amazon data centers. One of them got its first attack 52 seconds after it went live, and they averaged 13 attempts a minute each. In a 2025 interview, Amazon’s security chief put that time at 90 seconds.

Our own logs show the same. The VPS that ran our old blog had SSH, the remote login most servers use, open on its usual port. In the 31 days from September 20 to October 20, 2026, before we changed anything, it logged 302855 failed SSH login connections from 3209 addresses, about 9770 a day. Those connections held 322509 password guesses, about 7 a minute. The busiest day was October 6, with 18175.

The bots guess the obvious names first. They tried the username “root” 191431 times, then “ubuntu”, “admin”, “deploy”, “user” and “test”. Some tried “wallet” and “crypto”, hoping for a server that holds coins. Others used the names of the websites on the server as usernames, which suggests they looked up what the server hosts first.

The same server also got about 500 web requests a day for files that should never be public. Bots asked for .env files, where apps keep passwords and API keys, 9824 times. They looked for backups and config files 3463 times and tried known PHP exploits 1727 times. A streaming VPS that also serves a web page, like the stats page of an RTMP server, gets the same visitors.

On October 21 we turned off password logins on that server and turned on fail2ban, a tool that blocks an address after a few failed logins. The bots kept trying, 2399 times the next day, but none of them got as far as a password check. Guessing alone doesn’t get anyone in. The risk is a door you miss, like a password login left on, an old version of SSH or a control panel open to the internet.

New holes keep coming

The software on the server needs fixes too, because it keeps getting new security holes, and some of them sit in front of the login. In July 2024, Qualys found regreSSHion, a flaw in OpenSSH, the SSH server most Linux servers run. It let an attacker run code as root without logging in, on SSH’s default settings, and Ubuntu 24.04’s SSH had it. Qualys showed it working on 32-bit systems after hours of repeated tries, and OpenSSH’s release notes said 64-bit systems were believed to be at risk too. Turning off passwords didn’t help, because the flaw ran before the login check. The fix was an update.

Anything else on the server needs the same care. On October 21, 2026, PHP shipped fixes for PHP2Shell, two flaws rated 9.2 out of 10 that let attackers run their own code on servers that run PHP. Security researchers had already seen attacks using them. That matters if your VPS also runs a website or a PHP control panel. We finished moving this site off WordPress the same day.

Even software companies struggle to keep up. On October 22, The Browser Company said it will shut down Arc on December 22 and keep only its Dia browser. It said keeping a browser safe takes “constant, dedicated work that is only increasing in the age of AI.”

What a break-in does to your channel

Whoever gets into your VPS gets your stream key, and the key is all anyone needs to go live on your channel. YouTube calls stream keys your stream’s password and address, and Twitch tells streamers to never share theirs. A stranger with the key doesn’t need your YouTube password, and YouTube sees the stream as yours.

From there they can stream adult content or illegal material under your name. YouTube says posting explicit sexual content may result in content removal or channel termination, and a single strike already stops you from uploading or going live for a week. YouTube also reports child sexual abuse imagery to the National Center for Missing and Exploited Children, which works with law enforcement. Anything a stranger streams this way goes out from your account.

YouTube can end a channel after a single case of severe abuse, without a warning first, and deleting the video afterwards doesn’t remove a strike. You can appeal, but the stream already went out under your name, to your subscribers. An attacker with server access can also stop your stream, delete the files on the server, or use the server to attack other machines. That last one can get the server suspended by its provider. A stream key alone can’t delete videos already on your channel.

Lock down the VPS before you add your stream key

These steps close the doors the bots in our logs were trying. On a fresh Ubuntu 24.04 server they take about an hour (our estimate). Do them before the stream key goes on the server.

1. Log in with an SSH key and turn off password logins. Make a key on your computer with ssh-keygen -t ed25519 and copy it over with ssh-copy-id. Keep your current session open and confirm in a second terminal that the key works. Then set PasswordAuthentication no, KbdInteractiveAuthentication no and PermitRootLogin prohibit-password. Check files in /etc/ssh/sshd_config.d/ too, because the first value SSH reads wins. Run sudo sshd -t, reload SSH and test a new login before you close the first one.
2. Turn on a firewall that allows only SSH. The server opens the connection to YouTube itself, so the stream needs no open port. On Ubuntu, run sudo ufw allow OpenSSH, then sudo ufw enable. If you moved SSH to another port, allow that port instead.
3. Install security fixes automatically. Ubuntu Server ships with unattended-upgrades, which installs security updates daily. Check it’s on with sudo dpkg-reconfigure unattended-upgrades. Some fixes, like a new kernel, only work after a reboot, so reboot at a quiet hour when an update asks for one. The service starts the stream again.
4. Block repeat guessers. sudo apt install fail2ban bans an address for a while after a few failed logins. It banned 76 addresses on our server in its first two days, alongside the switch to key-only logins.
5. Run FFmpeg as its own user. The service in the setup below runs FFmpeg as a separate system user. If someone ever found a hole in FFmpeg, they would land in an account that can’t change the system.
6. Treat the stream key like a password. Keep it in a file only root can read, never in a script you copy to other machines or a backup you share. While the stream runs, the key also sits in FFmpeg’s command line. Anyone logged in to the server can read it there, so don’t give anyone else a login. If it leaks, reset it in YouTube Studio right away and update the file, because the old key keeps working until you do.
7. Keep control panels off the open internet. Stats pages, file managers and server panels are what the bots in our web logs went looking for. Reach them through an SSH tunnel instead.

After setup, plan a few minutes a week to install updates and check on the stream. Do this for as long as the stream runs, because the software keeps getting new holes.

Set up a plain loop on the VPS

A plain loop on a VPS is a small Linux project with three parts. Expect an hour or two in a terminal the first time. Live streaming has to be on for your channel first: in YouTube Studio, open Create, then Go live. The first time can take up to 24 hours.

1. Convert your videos first

A 1-core plan can’t reliably convert 1080p video while it streams, so the files should be ready before it goes on the server. YouTube wants a keyframe at least every 4 seconds and recommends a constant bitrate with one every 2 seconds. H.264 video with AAC audio is the safe choice. Files from a phone, a camera or an editing app often have a bitrate that jumps around, and some space their keyframes too far apart. You convert them on your own computer, and again when you add a video. Upstream does this for you when you upload.

The FFmpeg command below scales any video to 1920×1080 at 30 fps at a constant 6 Mbps. We tested it with FFmpeg 7.1. It writes a .ts file, because x264’s strict constant bitrate isn’t meant for .mp4 files. HandBrake, a free app with a window instead of a terminal, can do the same. The keyframe and constant bitrate settings then go in by hand as extra x264 options.

ffmpeg -i input.mp4 \
  -vf "scale=1920:1080:force_original_aspect_ratio=decrease,pad=1920:1080:(ow-iw)/2:(oh-ih)/2,fps=30" \
  -c:v libx264 -preset slow -b:v 6M -minrate 6M -maxrate 6M -bufsize 12M -x264-params nal-hrd=cbr \
  -g 60 -keyint_min 60 -sc_threshold 0 -pix_fmt yuv420p \
  -c:a aac -b:a 160k -ar 44100 stream.ts

2. Install FFmpeg and store the key

Install FFmpeg from Ubuntu’s packages and create a separate system user for the stream, with no password and no login shell, so FFmpeg never runs as root. Keep the stream key in a file only root can read (permissions 600), never in a script, a Git repo or your shell history.

3. Run it as a service that restarts itself

Write a systemd service file that runs FFmpeg as that user. Because systemd runs as root, it can read the key from the root-only file and hand it to FFmpeg. FFmpeg has to read the file at normal speed and loop it without end. It sends the file over RTMPS, the encrypted version of RTMP, to YouTube’s ingest server without converting it again. The service needs Restart=always to start FFmpeg again after a crash, and systemctl enable to start it after a reboot. FFmpeg’s log goes to journalctl, so that’s where you read why a stream stopped.

Run OBS on a VPS for overlays and widgets

A song title, a clock, alerts or a scene you change while the stream stays live all need OBS, or software like it, on the server. OBS is a desktop app made for a PC with a screen and a graphics card. A VPS has neither, so this is a much bigger project than a plain loop.

• A desktop on a server. OBS needs a desktop session and a virtual display to run in, which you install and keep running on a machine that has no screen.
• No graphics card. Cheap VPS plans have none, so the processor draws every frame of the scene in software and then encodes it. That’s why OBS needs dedicated cores.
• Remote desktop. You build and fix scenes over remote desktop, and remote desktop ports are another door the bots scan for. Keep it closed to the internet and reach it through an SSH tunnel.
• Browser sources. Alerts and widgets are web pages that OBS shows with a built-in Chromium browser, the engine behind Chrome. Each one takes memory and processor time, and that browser needs security fixes too.
• Crashes. OBS can reconnect after a dropped connection, but if OBS or the desktop session crashes, nothing starts them again unless you set that up yourself.
• More to patch. The desktop, OBS and its plugins get their own updates, on top of the server’s.

On a VPS, that work needs dedicated cores. In our test, only DigitalOcean’s $84 CPU-Optimized plan with 4 dedicated vCPUs kept up with one 1080p stream, and Hetzner’s similar CCX23 is €86.49 a month before VAT and was sold out when we checked.

There are two steps in between. You can edit the visuals, the music and the song titles into one long video before you upload it. Then a new song, a new order or a different video means editing that video again, uploading it and restarting the stream. FFmpeg can also draw text and images over the video live without a desktop. That’s live encoding too, so it needs the same dedicated cores, and each overlay is written by hand into the command.

What breaks a 24/7 stream on a VPS

• Dropped connections. YouTube or your provider drops the connection now and then, and how you started the stream decides what happens next. A stream started straight from the Go live page in YouTube Studio can end on a brief drop. A broadcast scheduled from the Manage tab rides out a gap of a few seconds, which matches our own tests, but a longer gap can still end it. When a broadcast ends, the next start is a new live video with a new link, and your viewers and chat stay behind on the old one. Our help article on permanent 24/7 YouTube streams walks through the setup.
• Reboots. A reboot for updates takes the stream down for a minute or two.
• Traffic limits. Once the included traffic runs out, some providers charge per gigabyte and others slow the connection, and a slow connection makes YouTube buffer.
• Platform limits. Twitch ends a broadcast at 48 hours, so a Twitch stream restarts after two days. YouTube may not save a replay of a stream longer than 12 hours.
• Changes. On a plain loop, a new song or video means converting it, adding it to the file or playlist and restarting the service, which starts a short break.
• A full disk. A 6.2 Mbps file takes about 2.8 GB per hour of video, so a long playlist fills a 20 to 30 GB disk fast.
• Copyright. YouTube scans every live stream for copyrighted content and can interrupt or end a stream that keeps playing it. Licensed music can trigger it too unless the owner adds your channel to their allowlist, so use music you own or check your license.

On Upstream, the stream restarts on its own after a drop or a server update, and you can change the video or the music while it stays live.

24/7 live streaming

Keep a live channel running 24/7.

Upload your files and build a playlist. Upstream plays it from the cloud while your computer is off.

Sign up for free Explore 24/7 streaming

Manage backgroundLoop duration: 02:26:1403:08:42

1Night owl40:04

2Country train daydream53:32

3Late night sax52:38

4Windmill sunset42:28

SettingsChatDestinationsTriggers

Background Settings

Background playlist order

Ordered loopShuffled loop

Ordered will play the background files in their order.Shuffle will play a random background file from the list.

Video Fit

CropFit

Background will be cropped to fill the entire canvas if the aspect ratio doesn’t match.

VPS or a managed 24/7 service

A VPS costs less only for a plain loop, and you still spend an hour or two setting it up and a few minutes a week keeping it safe. That loop suits someone comfortable in a terminal whose stream never changes. A lofi stream rarely stays that way. You add new songs, switch the video for a new season, or run a short video loop under hours of music. On a VPS, all of that is prep work before anything reaches the server. A new song or video has to be converted to the same settings and added to the file or the playlist, and FFmpeg only reads that list when it starts. So each change means restarting the stream, which drops it for a few seconds. If it takes longer to come back, or the stream was started from the Go live page in YouTube Studio, YouTube can end the broadcast. Keeping a short video in sync with separate music takes scripting and testing first. You do all of this yourself, or pay someone who knows FFmpeg to set it up.

A stream with overlays, widgets and a playlist you change while it’s live needs OBS on dedicated cores instead. At DigitalOcean that costs more a month than Upstream, before you count your time.

On Upstream, none of that needs an editor or OBS. You upload songs and videos separately, and Upstream plays a separate music playlist over your video playlist, with a second audio channel for rain or café sounds if you want one. You add, remove or reorder songs and videos while the stream plays, and it picks up the change without stopping. You add overlays, now playing, clocks and StreamElements widgets in the Stream Designer, and send one stream to up to 10 of 30+ platforms at once. You can also go live with guests in Live Studio over your 24/7 stream. It all runs on dedicated servers whose only neighbours are other Upstream streams, so 1080p doesn’t depend on a stranger’s workload.

Upstream runs your stream on servers we lock down full time. Your stream key lives on those servers, and we keep them patched. We store stream keys encrypted, and our own team tools keep them hidden. YouTube, Twitch, Kick and Mixcloud connect by signing in, so there’s no stream key for you to copy, paste or leak. A leaked key works for anyone until you reset it. A sign-in is tied to Upstream’s app, and you can see and remove it any time in your account settings. On YouTube, it’s the same permission OBS asks for when you connect your account, and we use it only to create and manage your live streams. The parts of Upstream that handle streams only answer the services that need them, and a monitor checks the software we run against newly published security holes. Our security page explains how.

All plans, the free one too, come with live chat and email support, and someone on our team writes the reply. We monitor the streams, and when one stops, our team can check its logs and tell you why. Our helpdesk also has step-by-step guides for permanent 24/7 streams on YouTube, Twitch, Kick and more.

The free plan gives you 24 streaming hours a month, enough to watch a stream run on our servers before you pay for anything. See pricing or read how 24/7 live streaming on Upstream works.

How we counted

On October 23, 2026 we read the SSH log of the Vultr VPS that ran our old blog, from September 20 to October 22 (UTC). The totals in the text cover September 20 to October 20, before we turned off password logins, and the chart adds the two days after. One failed login is one SSH connection, counted once per day, source address and source port, that logged an unknown username, a wrong password or a closed login attempt. One connection can hold several password guesses, which we counted separately. Successful logins aren’t included, and the web requests come from the site’s own access log. The log measures attempts, not break-ins.

The daily counts are in a CSV file. We publish only the totals and keep the addresses private.

For the re-encode test, each droplet ran Ubuntu 24.04 and FFmpeg 6.1.1 from Ubuntu’s packages. Speed is FFmpeg’s own figure, the median over 10 minutes after a 30 second start, and “behind” is how far the stream’s clock fell behind the wall clock by the end. The second run used the same script with the clips converted first to matching 1080p at 30 fps, H.264 at 6 Mbps. The test script and clip list are public, so you can run it on your own server.

Frequently asked questions

Can one VPS stream to YouTube and Twitch at the same time?

Yes. Run a second FFmpeg service with Twitch’s address and your Twitch key. Copying a prepared file uses little processor time, but traffic doubles to about 4 TB a month at 6.2 Mbps. Twitch also ends a broadcast at 48 hours, so that output restarts after two days.

What should I do if my stream key leaks?

Reset it right away: in YouTube Studio, reset the key on the Stream tab, then update the key file on your server and restart the service. The old key keeps working until you reset it. Then find out how it leaked, because a leaked key often means someone got into the server.

Can I run OBS on a VPS instead of FFmpeg?

Yes, and it’s the closest a VPS gets to what Upstream does, with scenes, overlays and widgets. OBS needs a desktop and a virtual display on the server, and with no graphics card the processor draws and encodes every frame. In our test, DigitalOcean’s $84 CPU-Optimized plan with 4 dedicated vCPUs was the cheapest that kept up with one 1080p stream, and you still need remote desktop to edit your scenes. A plain FFmpeg loop runs on the smallest plans but can’t show anything beyond the file.

Can I add new songs to a VPS stream without stopping it?

Not on a plain FFmpeg loop. FFmpeg reads its file or playlist when it starts, so a new song means converting it, adding it and restarting the stream. That drops the stream for a few seconds and can end a broadcast started from the Go live page. OBS can change playlists while it’s live, but it needs a desktop and dedicated cores on the server. On Upstream, you add songs and videos to separate playlists while the stream plays, and it keeps running.

Sources

Prices checked on October 23, 2026 on the providers’ own pages. Server numbers come from our own logs, read the same day.

• VPS prices and limits: Hetzner Regular Performance, Cost-Optimized and General Purpose, netcup VPS pico, OVHcloud VPS for Europe and the US, Contabo’s VPS page as saved on October 17 (its live page sat behind a bot check) and VPS docs, DigitalOcean Droplet pricing, bandwidth billing and shared vs dedicated CPU, Vultr pricing, Hostinger VPS, Oracle’s Always Free resources and Akamai cloud pricing.
• Setup: FFmpeg documentation, YouTube’s live encoder settings and encoder streaming guide, systemd service files, OpenSSH server settings, Ubuntu’s automatic updates and fail2ban.
• Security and channel rules: Sophos on how fast new cloud servers get attacked, Steve Schmidt in The Record, the UK NCSC’s Richard Horne, PHP2Shell coverage from Help Net Security and watchTowr, Arc’s announcement on X, Qualys on regreSSHion, OpenSSH 9.8’s release notes and Ubuntu’s fix, YouTube’s page on copyright in live streams, YouTube’s rules on Community Guidelines strikes, sexual content, child safety and stream keys, and Twitch’s stream key FAQ.
• Our data: daily SSH counts from the VPS that ran our old blog, and the DigitalOcean re-encode test, with music from Big Buck Bunny (CC BY 3.0). Upstream: security, pricing, 24/7 live streaming and the permanent YouTube stream guide. OBS’s YouTube sign-in code.