A second VPS can send a redundant copy of your programme to YouTube’s backup ingestion address while your primary encoder sends to the primary address. That adds another encoder and host to the ingest path, but it does not guarantee that viewers will switch cleanly or at a particular moment if the primary fails.
The practical job is to configure both encoders with the active stream’s correct credentials and compatible output, then rehearse the failure you care about. Treat viewer-side behaviour as something to observe and document, not an outcome promised by the presence of a second VPS.
Understand primary and backup ingestion
In the arrangement described here, one VPS runs the primary encoder and sends the programme to YouTube’s primary ingestion URL. A separate VPS runs a second encoder process and sends a copy of the same programme to the backup ingestion URL. YouTube’s Live Streaming API exposes separate primary and backup ingestion address fields and describes sending the same content to both addresses at the same time. See the LiveStreams resource documentation for the API fields and the relevant stream configuration.
This is redundancy at the input to YouTube. It does not automatically duplicate every part of a live-channel operation. If both encoder processes read from one file on one host, that host or file path may remain a shared point of failure. If both VPS instances depend on the same upstream connection or the same account credentials, some failure modes can affect both. These are consequences of how the components are arranged, not a claim about how YouTube selects a viewer feed.
It is useful to separate three questions. Can the second encoder connect to the backup address? Is it sending content that is compatible with the primary feed? What do viewers and the event status show if the primary encoder stops? The first two are configuration checks; the third requires a controlled rehearsal because the reviewed YouTube material does not specify exactly when or how viewers switch between feeds.
A separate machine is most useful when it reduces a failure you have actually identified, such as a process or host going down. It cannot solve every source, network, configuration or delivery problem. If your channel is a long-running devotional loop, for example, you might also need to check whether the media source is available on both machines and whether the two encoders remain aligned. The planning considerations in this guide to backing up a devotional stream with a second encoder can help you think through the broader operating arrangement.
Find the active stream’s backup address
Start in YouTube Studio by creating or scheduling the live stream you intend to use. YouTube’s encoder setup instructions explain how to obtain the stream URL and key in Live Control Room and enter them in your encoder. Use values shown for the active stream rather than copying an endpoint from an old note, another event or a sample configuration.
For an API-managed setup, the LiveStreams resource has fields for primary and backup ingestion addresses, including separate RTMP and RTMPS fields. The value to use depends on the protocol your encoder will use. If you are configuring RTMPS, obtain the RTMPS backup address for the current stream. Do not assume that an RTMP address can be used unchanged as an RTMPS address, or that a URL copied from a past event is still the right one.
The stream key is a credential, not a public identifier. Enter it only in the encoder’s intended credential field, avoid placing it in a screenshot or shared support message, and do not commit it to a public code repository. If you keep operational notes, record where to retrieve the key rather than copying the key into a general runbook. Limit access to the control panel and VPS accounts to people who need to operate the channel.
Before proceeding, label the values on each machine clearly: primary URL and key for the primary encoder, backup URL and the appropriate stream credentials for the second encoder. Check that you have not pasted the primary address into both outputs by mistake. If your encoder interface combines the URL and key in one field, confirm its expected format in that encoder’s documentation rather than guessing from the YouTube fields.
Configure the second VPS encoder
Install and configure the encoder on the second VPS using the operating system and software you have chosen. YouTube’s documentation supplies the ingest addresses and media settings, not a universal VPS image, command line, CPU size, memory allocation or service file. Those details depend on whether your software decodes and re-encodes the media, relays an existing encoded feed, and what resolution and frame rate you need. Validate those implementation details on the VPS you select.
Set the second output to the active stream’s backup ingestion URL. For an RTMPS workflow, use the RTMPS scheme and port 443. YouTube’s RTMPS ingestion guide describes the endpoint and notes the hostname’s role in TLS SNI authentication. Do not replace the hostname with an IP address just because a network diagnostic displays one; use the supplied endpoint in the form supported by your encoder.
The second VPS needs sustained outbound capacity for its own feed. If both encoders are sending separate copies, account for the outbound load on each host independently, along with ordinary network overhead. A bitrate recommendation is not a guarantee that a particular VPS plan or route can sustain that rate at all times. Check the selected provider’s current offer and test from the actual region and network path you expect to use.
For process supervision, decide what should happen if the encoder exits and how you will notice. A restart policy may bring a failed process back, but it will not correct an invalid key, an unavailable source file or an unreachable endpoint. Keep logs and a simple operator checklist available to the person who will respond. Do not treat a process showing as active as proof that YouTube is receiving healthy media; verify status at the encoder and in YouTube’s stream health information.
If your existing operation is a single Windows computer, moving only the backup encoder to a VPS changes the failure boundaries but also adds another system to maintain. The guide to running a continuous YouTube stream from a Windows 11 PC covers a different operating arrangement. The relevant question is not which arrangement sounds more robust, but which failure you want the second machine to withstand and whether its source and network are independent enough to help.
Match the programme and ingest settings
Aim for both encoders to produce compatible versions of the same programme: same picture, audio mix, resolution, frame rate, codec and broadly consistent keyframe cadence. This is practical guidance for a redundant copy, rather than a guarantee that matching settings dictate viewer switching. If the two feeds differ substantially, a test can reveal an unexpected change in picture, sound or timing when the receiving behaviour changes.
YouTube’s current encoder settings guidance lists RTMP and RTMPS, recommends constant bitrate (CBR), and recommends keyframes every two seconds without exceeding four seconds. It also provides codec-, resolution- and frame-rate-specific bitrate recommendations. For example, its H.264 recommendations are 10 Mbps for 1080p30 and 17 Mbps for 1080p60; its H.265/HEVC and AV1 recommendations are 10 Mbps for 1080p30 and 12 Mbps for 1080p60. These are YouTube recommendations, not measurements of what your VPS can reliably upload. Check the current encoder settings page before settling on settings, as official guidance can change.
| Setting to compare | Practical approach for the two encoders |
|---|---|
| Protocol and endpoint | Use the intended protocol on each output, and the active stream’s primary address on the first VPS and backup address on the second. For RTMPS, keep the RTMPS endpoint and port as supplied. |
| Video format | Match codec, resolution and frame rate where your encoder permits it. Choose from YouTube’s current supported settings for the stream. |
| Bitrate behaviour | Use CBR as YouTube recommends, and select a bitrate appropriate to the chosen codec, resolution and frame rate. Confirm that each VPS can sustain its own outbound feed. |
| Keyframes | Follow YouTube’s recommendation of a two-second interval and do not exceed its four-second maximum. Keep the outputs aligned where possible. |
| Audio and programme | Use the same intended audio mix and programme content, and listen for gaps, clipping or a change in level during a rehearsal. |
If one VPS transcodes while the other relays an already encoded stream, the two outputs may not naturally have identical characteristics. That can be acceptable for a particular workflow, but check the result rather than assuming that matching filenames or source material means matching output. Use a short controlled rehearsal with representative movement and audio before relying on the setup for a long broadcast. A channel built around a prepared file may find the workflow guidance in streaming recorded lectures continuously on YouTube useful when thinking about source continuity, although its subject is not VPS redundancy.
Send both feeds at the same time
Once the second encoder is configured, start the primary and backup processes so both send the same content simultaneously to their respective addresses. The API describes the backup address as an ingest destination for a redundant copy of the content sent to the primary URL. This is not the same as setting up two unrelated broadcasts or scheduling two different events. Confirm the stream and event association in the control panel before starting either process.
Check each encoder’s own output status and the YouTube event’s incoming health indicators. Look for connection failures, warnings, missing audio, an unexpected resolution or frame rate, and a feed that stops advancing. A successful connection message only establishes that a connection was made at that moment; it is not evidence that the full stream is healthy over time. Record what each machine reports and what the event status shows so you can distinguish a source issue from a connection issue later.
There are protocol alternatives, but do not treat them as interchangeable settings. YouTube documents redundant HLS ingestion with a backup URL, a different hostname and a copy= parameter. HLS has its own ingestion requirements and uses segmented uploads; use it only if your encoder and workflow support YouTube’s documented method. For the ordinary RTMPS setup described here, select the event’s RTMPS backup address instead of trying to adapt HLS-specific URL rules. The HLS ingestion guide is the primary reference if HLS is genuinely the protocol you need.
Avoid testing a failure by simply stopping the primary during a public event without an agreed plan. A rehearsal in a private or otherwise controlled setting can establish what your current configuration does, but make sure the event settings and visibility suit your channel. Tell anyone monitoring the channel when the test will happen and what actions they should take. Keep a manual recovery path, including access to the stream controls and a way to check both encoders, rather than relying on a test outcome as a permanent guarantee.
Test viewer and event behaviour
YouTube’s encoder guidance says, “Make sure to test before you start your live stream.” It also advises testing with audio and movement similar to the real event and monitoring stream health and messages. For a 24/7 channel, choose a rehearsal that resembles normal operation: a representative video segment or live programme, the usual audio chain, and the encoder settings you intend to leave running.
Test in stages. First, run both encoders together and confirm that each is sending to its intended address. Check YouTube’s stream health messages, and inspect audio and picture from an appropriate preview or controlled viewing setup. Then, with an operator present, interrupt the primary encoder or its process in a controlled rehearsal. Note what YouTube reports, what the backup encoder continues to send, and what the viewer-facing experience appears to be. Restore the primary according to your planned procedure and note whether the event status returns to the expected state.
Do not infer more than the test shows. A rehearsal is evidence about that event configuration, those encoders, those network paths and the conditions on that day. It does not establish a universal switch time or prove that viewers will have no interruption in a future failure. The reviewed official documentation describes redundant ingestion but does not specify exactly how or when viewers switch feeds after one encoder stops. Keep the distinction clear in any runbook or promise you make to viewers.
Write down the actual observations: time of interruption, messages visible in the control room, whether the programme continued, any audio or picture discontinuity, and what operator action was needed. Avoid converting a single observed interval into a promised recovery-time objective. If a test fails, investigate the relevant layer: source availability, encoder process, credentials, address, outbound network, media compatibility or event setup. Repeat a controlled test after changing a setting rather than assuming a new configuration fixed the issue.
This sort of monitoring is particularly important for an overnight channel, when a process can be running while the programme itself is frozen or silent. Assign a person to respond to alerts or schedule checks, and ensure they know how to inspect the encoder and YouTube status without exposing the stream key. A second VPS reduces dependence on one encoder host only to the extent that the rest of the path needed by the backup remains available.
Decide what redundancy you actually need
A second VPS is a reasonable fit if your main concern is a failure isolated to the first host or encoder process and you can maintain two configurations. It is less useful if both processes depend on one media source that can fail, if both hosts share a weak upstream path, or if nobody can detect and investigate a fault. Mapping the source, encoder, network, credentials and YouTube event before buying a second host helps show which failure modes remain common.
Consider how the backup receives its programme. If it reads the same local file, you need a way to place and verify that file on both hosts. If one VPS relays a feed from the other, the relay path may itself be shared. If you duplicate a source or use a separate origin, assess the extra operational complexity and ensure the output remains the intended programme. There is no universal CPU or memory size in YouTube’s ingest documentation for these arrangements; measure the workload on your chosen encoder and host.
Finally, balance the cost and attention required for a second independently maintained machine against the interruption you are trying to reduce. Keep the configuration readable, credentials protected, and tests repeatable. If your actual need is to turn an uploaded file into an always-on YouTube broadcast without keeping your own computer running, StreamNeo removes the need to keep a local encoding computer on, but it does not replace the specific two-VPS arrangement described here or remove the need to plan for stream behaviour.
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
Where do I find YouTube’s backup ingestion URL?
Open the active stream in YouTube Studio’s Live Control Room and use the stream settings supplied for that event. For API-managed workflows, consult the LiveStreams resource’s backup address fields and choose the one matching your protocol. Do not reuse a sample or old event URL without checking it.
Can two encoders send to YouTube at the same time?
YouTube’s Live Streaming API documents sending the same content to the primary and backup ingestion addresses simultaneously. Configure each output for its corresponding address and verify that both are active. This documents redundant ingest, not a guarantee about the viewer-facing result when one feed fails.
Should the second VPS use the same bitrate and keyframe settings?
Use compatible settings and follow YouTube’s current codec- and resolution-specific recommendations. YouTube recommends CBR, a two-second keyframe interval and no more than four seconds between keyframes. Confirm that each host can sustain its own outbound feed and rehearse the result.
Does a second VPS guarantee seamless failover?
No. A second host can add another encoder and host failure domain, but shared sources, networks or credentials may still affect both feeds. YouTube’s cited documentation does not specify precisely when or how viewers switch, so test in a controlled setting and describe only what you observed.