You stream to YouTube from a VPS by pushing an RTMP or RTMPS feed from your server (via FFmpeg, OBS, or a pre-installed engine like Wowza or NGINX-RTMP) to YouTube’s ingest URL — rtmp://a.rtmp.youtube.com/live2 — appended with your channel’s stream key. A VPS is the right tool when you need a 24/7 channel, a server-side encoder, or a stream that doesn’t depend on your home internet or a laptop staying awake.
Running the encoder on a VPS instead of a local machine removes the single biggest point of failure in unattended or long-running YouTube streams: a home connection dropping, a laptop sleeping, or an ISP throttling upload during peak hours. This guide covers the actual ingest URLs, stream key handling, bitrate tables YouTube publishes, and the systemd/cron setup we use internally to keep 24/7 YouTube channels alive on client VPS instances.
Key Takeaways
- YouTube Live accepts RTMP and RTMPS ingest at
rtmp://a.rtmp.youtube.com/live2(orrtmps://a.rtmps.youtube.com/live2for encrypted ingest), authenticated by a per-stream or persistent stream key from YouTube Studio. - For 24/7 or unattended channels, YouTube’s “persistent” stream key combined with FFmpeg running under systemd with
Restart=alwaysis the most reliable server-side setup. - YouTube recommends 1080p30 at 4,500–9,000 Kbps and 1080p60 at 6,000–9,000 Kbps; going above roughly 51 Mbps total bitrate can get a stream rejected outright.
- A 2 vCPU / 4 GB VPS comfortably handles one 1080p30 restream with FFmpeg in copy mode (no re-encode); transcoding multiple renditions server-side needs 4+ vCPUs or GPU acceleration.
- YouTube enforces a keyframe interval of 2 seconds or less and requires audio in AAC-LC at 128 Kbps or higher — misconfigured keyframes are the most common cause of a stream that connects but never goes live.
What Is YouTube’s RTMP Ingest URL and Stream Key?
YouTube Live ingest happens over RTMP at rtmp://a.rtmp.youtube.com/live2, or RTMPS (TLS-encrypted RTMP) at rtmps://a.rtmps.youtube.com/live2 — both documented in YouTube’s Live Streaming API and Help Center. The stream key is a long alphanumeric string generated per broadcast in YouTube Studio under Go Live → Stream, and it’s the only thing standing between your VPS and your channel — anyone with the key can push video that appears as your live stream.
The full ingest address an encoder needs is the base URL and key concatenated with a slash: rtmp://a.rtmp.youtube.com/live2/xxxx-xxxx-xxxx-xxxx-xxxx. In OBS this is split into “Server” and “Stream Key” fields; in FFmpeg you pass it as one destination URL.
There are two kinds of stream keys worth knowing. A one-time key is tied to a single scheduled broadcast and expires with it — fine for a webinar or a live event. A persistent/reusable key stays valid indefinitely and is what you want for a 24/7 channel, since you can restart the encoder without creating a new broadcast in YouTube Studio each time.
How Do You Push a Stream From a VPS to YouTube With FFmpeg?
The simplest reliable path is FFmpeg in stream-copy mode, which forwards an existing encoded stream without re-encoding it — ideal when your VPS is already receiving RTMP from OBS, Wowza, or NGINX-RTMP and just needs to relay it to YouTube.
ffmpeg -re -i rtmp://127.0.0.1/live/mystream \
-c:v copy -c:a copy \
-f flv rtmp://a.rtmp.youtube.com/live2/xxxx-xxxx-xxxx-xxxx-xxxxIf the incoming stream doesn’t already match YouTube’s requirements (H.264 video, AAC audio, 2-second-or-shorter keyframe interval), you need to transcode instead:
ffmpeg -re -i rtmp://127.0.0.1/live/mystream \
-c:v libx264 -preset veryfast -tune zerolatency \
-b:v 6000k -maxrate 6000k -bufsize 12000k \
-g 60 -keyint_min 60 -sc_threshold 0 \
-c:a aac -b:a 160k -ar 44100 \
-f flv rtmp://a.rtmp.youtube.com/live2/xxxx-xxxx-xxxx-xxxx-xxxxThe -g 60 -keyint_min 60 pair forces a fixed keyframe every 60 frames (2 seconds at 30fps) — this is the single most common reason a YouTube ingest connects but the stream stays stuck on “starting” in YouTube Studio. We’ve seen this exact symptom on client setups more times than any other YouTube-specific issue: encoder shows “connected,” Studio shows a spinner indefinitely, and the fix is almost always a keyframe interval mismatch.
On a StreamingVPS Wowza or Ant Media instance, you don’t hand-roll the FFmpeg command at all — both engines have a built-in “push publish” / “stream target” feature where you paste the YouTube RTMP URL and key into the admin panel and the engine manages the outbound connection, including automatic reconnection if YouTube’s ingest server drops the connection.
Is a VPS Better Than Streaming to YouTube From OBS on Your Laptop?
For anything running unattended or 24/7, yes — a VPS removes dependency on your local network, your computer staying on, and your ISP’s upload bandwidth, all of which are common failure points for laptop-based YouTube streams that run for more than a few hours. For a one-off two-hour livestream where you’re sitting at the keyboard the whole time, OBS on a laptop is simpler and there’s no strong reason to add a server hop.
The tradeoff is upload path: streaming from OBS on your laptop sends one long-haul RTMP connection from your home ISP directly to YouTube’s nearest ingest point, subject to your home upload speed and any ISP-side congestion. Streaming from a VPS means your encoder (OBS, a camera, or a source feed) first needs to reach the VPS — either over the internet or via a local encoder pushing RTMP to the server — and the VPS then relays to YouTube from a datacenter connection that’s typically far more stable and has substantially higher guaranteed upload bandwidth than most residential lines.
For 24/7 channels — a loop of pre-recorded content simulcast as “live,” a security camera feed, a webcam nature stream — a VPS is close to mandatory, since no laptop can reasonably stay online and unattended for weeks at a time without a reboot, an OS update, or a sleep timer interrupting the stream.
What Bitrate and Resolution Settings Does YouTube Recommend?
YouTube publishes specific recommended bitrate ranges by resolution and frame rate in its Live Encoder Settings documentation, and going outside them risks either a rejected stream or wasted bandwidth with no visible quality gain.
| Resolution | Frame rate | Recommended video bitrate | Notes |
|---|---|---|---|
| 480p | 30fps | 1,000–2,000 Kbps | Adequate for low-motion content only |
| 720p | 30fps | 2,500–4,000 Kbps | Common minimum for talking-head streams |
| 720p | 60fps | 3,500–5,000 Kbps | Gaming or sports at 720p |
| 1080p | 30fps | 4,500–9,000 Kbps | Most common target for general live streaming |
| 1080p | 60fps | 6,000–9,000 Kbps | Fast motion (sports, gaming) at full HD |
| 1440p | 60fps | 9,000–18,000 Kbps | Requires solid upstream bandwidth from origin |
| 4K (2160p) | 30/60fps | 13,000–51,000 Kbps | Above ~51 Mbps total, YouTube may reject the stream |
Audio should be AAC-LC, stereo, 44.1 kHz or 48 kHz sample rate, at 128 Kbps minimum — YouTube recommends 128–384 Kbps depending on whether you’re running stereo or 5.1. On a StreamingVPS 4 vCPU / 8 GB streaming plan, we’ve comfortably run a single 1080p60 transcode at 8,000 Kbps alongside a 720p30 lower-bitrate rendition for a multi-quality push, with CPU utilization sitting around 55–65% sustained — headroom for burst traffic without dropping frames.
How Do You Keep a YouTube Live Stream Running 24/7 From a VPS?
The core pattern is: a persistent (reusable) YouTube stream key, an FFmpeg or engine process that reconnects automatically on failure, and a process supervisor that restarts the whole thing if it ever fully dies. We run this as a systemd service rather than a raw cron job or a screen session, since systemd gives you real restart-on-failure semantics and centralized logging via journalctl.
# /etc/systemd/system/youtube-stream.service
[Unit]
Description=24/7 YouTube Live Restream
After=network.target
[Service]
ExecStart=/usr/bin/ffmpeg -re -stream_loop -1 -i /var/streams/loop.mp4 \
-c:v libx264 -preset veryfast -b:v 6000k -maxrate 6000k -bufsize 12000k \
-g 60 -c:a aac -b:a 160k \
-f flv rtmp://a.rtmp.youtube.com/live2/xxxx-xxxx-xxxx-xxxx-xxxx
Restart=always
RestartSec=5
User=streamer
[Install]
WantedBy=multi-user.targetRestart=always with a short RestartSec means that if FFmpeg crashes, or YouTube’s ingest endpoint briefly drops the connection (which happens occasionally on their end, not just yours), the service comes back within 5 seconds instead of leaving the channel dark until someone notices manually. We also recommend a separate uptime check (a cron job hitting the YouTube Live API or a simple ffprobe health check against the local source) that alerts you if the stream has been down for more than a few minutes — systemd will keep retrying, but it won’t tell you it’s retrying.
One limitation worth being upfront about: YouTube’s terms of service require live content to actually be “live” in spirit — looping the exact same static video file with no live element, indefinitely, can trigger a channel-level review. If you’re running a genuine 24/7 feed (a live camera, a rotating multi-hour playlist with live segments mixed in, a FAST channel with scheduled programming), you’re on solid ground; a single 10-minute clip looped forever with no variation is the kind of thing that occasionally gets flagged by YouTube’s automated systems.
Do You Need to Re-Encode, or Can You Just Relay the Stream?
If your source is already H.264/AAC in an RTMP-compatible container and matches YouTube’s keyframe and bitrate requirements, stream-copy (relay-only) is both faster and cheaper — FFmpeg in copy mode uses a fraction of a CPU core since it’s just repackaging packets, not decoding and re-encoding frames. This is the right call when your OBS or camera encoder is already configured correctly and the VPS is purely there for reliability, not transformation.
You need to re-encode when the source doesn’t meet YouTube’s spec — wrong keyframe interval, an unsupported codec, bitrate too high or too low, or when you’re combining multiple inputs (picture-in-picture, overlays, a scoreboard graphic) into one output stream. Re-encoding is also unavoidable if you’re pushing the same source to YouTube and, say, Twitch simultaneously at different bitrates, since each platform has different optimal settings.
FAQ
What is YouTube’s RTMP ingest URL?
YouTube’s primary RTMP ingest URL is rtmp://a.rtmp.youtube.com/live2, or rtmps://a.rtmps.youtube.com/live2 for encrypted RTMPS ingest. You append your stream key from YouTube Studio to this URL to complete the destination address.
Can I stream to YouTube 24/7 from a VPS?
Yes, using a persistent (reusable) stream key from YouTube Studio combined with an auto-restarting encoder process such as FFmpeg under systemd with Restart=always. Be aware that YouTube’s terms require genuinely live or varied content — a single short clip looped forever with no live element can be flagged.
What bitrate should I use for 1080p YouTube Live?
YouTube recommends 4,500–9,000 Kbps for 1080p at 30fps, and 6,000–9,000 Kbps for 1080p at 60fps, with AAC-LC audio at 128 Kbps or higher. Going significantly above these ranges provides no visible quality benefit and increases bandwidth cost.
Why does my YouTube stream connect but never go live?
The most common cause is a keyframe interval longer than 2 seconds — YouTube requires a keyframe (GOP size) of 2 seconds or less, so an FFmpeg command without -g and -keyint_min set correctly will often connect but never transition out of “starting” in YouTube Studio.
Do I need a powerful VPS to stream to YouTube?
Not for stream-copy relay — a 2 vCPU / 4 GB VPS handles a single relayed 1080p stream easily since no transcoding is happening. You need 4+ vCPUs or GPU acceleration only if you’re transcoding, running multiple simultaneous renditions, or pushing to several platforms at once.
Get a VPS Built for This
StreamingVPS instances come with Wowza, Ant Media, NGINX-RTMP, and FFmpeg-ready environments pre-installed — no manually compiling encoders or debugging keyframe settings from scratch. Push publish / stream target features in Wowza and Ant Media handle the YouTube RTMP connection and reconnection logic for you, and our Wowza streaming VPS plans are sized specifically for 24/7 restreaming workloads. Check current specs on the pricing page — go live in 60 seconds.
