This is an advanced, optional extra. Most streamers never need it. It is for people whose stream cannot afford to stay down while they fix a broken server: a second, cheap receiver that sits idle and can take over if your main one stops answering.

Your main receiver does the clever things: the backup video when the bond drops, the background audio remover, upscaling. The failover server does none of that. It only runs the bonding receiver and Restreamer, and passes your stream to the platforms exactly as it arrives — same resolution, same frame rate, no re-encoding. That is why the smallest server a provider sells is enough (1 vCPU and 1 GB of memory is plenty for passing a stream through; see Renting a server).

• Your dashboard checks both servers every few seconds. If the main server stops answering for about 20 seconds while you are live, you are asked: Your main server is not answering. Switch to your failover server? The header also shows Failover · main server down.
• Press Switch to failover and the router sends the bond to the failover server, which starts the same channels and platforms your main server was running. Nothing moves on its own: a server that is only slow for a moment should not drag your stream somewhere else.
• While you are on it, a red ON FAILOVER SERVER banner stays across the top of the dashboard, and the header chip says ON FAILOVER.
• When the main server has been answering again for 30 seconds, you are asked whether to go back. You can also press Switch back on the banner at any time.
• If neither server answers, the problem is almost always the router's own internet, and switching would not help — so you are not asked.

The question only appears while a dashboard is open. With no dashboard open, the router still checks both servers every minute and keeps the failover server's copy of your setup up to date, but it waits for you to decide.

Failover reconnects the feed; it is not seamless. Restream.io may briefly show offline during a switch or real failover test. That alone does not prove the destination broadcasts ended, but they can end depending on their settings and the length of the interruption.

Before you go live:

• YouTube: open the actual broadcast in YouTube Studio → Live Control Room → stream settings and turn Auto-stop OFF. This reduces the risk of an encoder disconnect ending that event. It is not a guarantee against every platform timeout. See YouTube's stream settings.
• Twitch: enable Disconnect Protection in Twitch's stream settings. It can give you up to 90 seconds to reconnect. Do not assume it is enabled. See Twitch Disconnect Protection.
• Restream.io: if your plan supports Disconnect Protection, configure it before going live so Restream sends fallback video when the incoming feed disconnects. Availability and limits depend on your plan; see Restream's setup guide.
• Other destinations, including Facebook and Kick: check their current disconnect behavior and test the actual live-event settings you use. Do not assume a fixed grace period.

Detection takes about 20 seconds, plus your reaction time and stream reconnection time. Respond promptly: there is no universal safe interruption window, and neither the receiver nor the dashboard can guarantee that a platform keeps an event open.

Verify a real test at every destination. Switch to the failover server, then switch back. Check that playback resumes on the same live broadcast, with no new event and no ended status. A successful switch or a ready receiver does not prove that the platforms stayed live. Restream's brief offline indicator alone cannot answer that question.

First, set a budget with the provider. A failover server sits idle most of the time, which makes it the easiest server to forget about. Before you create it, add a budget or spending alert in the provider's billing settings (AWS: Billing and Cost Management → Budgets → Create budget, a monthly cost budget a little above the plan's price, with an email alert), and use a hard spending cap or prepaid credit where the provider offers one. A budget is an alarm, not a fuse, but it means a bigger plan picked by mistake, traffic over the plan's allowance or a server you meant to delete cannot run away unnoticed. To stop paying, delete the instance and release its static IP — an unattached static IP is billed too.

About $5 to $7 a month, and nothing to type into a terminal. The dashboard writes a launch script that does the whole install on the new server's first boot, and pairs with it by itself afterwards.

1. In the dashboard, open the Restreamer tab, unfold Failover server (advanced) and then Set up a failover server.
2. Optionally paste a reusable Tailscale auth key (login.tailscale.com → Settings → Keys). Left empty, your main receiver's own key is used, which only works if that key was made reusable.
3. Press Make my launch script, then Copy launch script.
4. Go to lightsail.aws.amazon.com → Create instance. Pick a region away from your main server, then Linux/Unix → OS Only → Ubuntu 24.04 LTS.
5. Click Add launch script and paste the script into the box.
6. Choose a plan with a public IPv4 address (not “IPv6-only”). 1 GB of memory is comfortable; 512 MB works, because the script adds swap. Name it anything and press Create instance.
7. Open the new instance → Networking:
   • Required: Attach static IP. Create a static IP in the same region, select this instance and attach it. Do not rely on the temporary public IP for streaming.
   • Under IPv4 Firewall press Add rule: Application Custom, Protocol UDP, Port 25554 (the card shows your port if you changed it), then Create. SSH (port 22) is already open; your main receiver uses it, with a key only it has, to keep the failover server updated.
8. Wait 10 to 15 minutes. The failover card finds the new server on your tailnet, pairs with it and copies your channels and platforms across. The header gets a Failover chip that says ready. You can leave the page meanwhile.

The static IP and stream firewall rule are required setup steps. In the instance's Networking → IPv4 Firewall → Add rule, choose Application: Custom, Protocol: UDP, and the bonded stream port shown in your dashboard (normally 25554). Allow Any IPv4 address, then click Create and confirm the UDP rule appears in the list. TCP on the same number does not work. Do not expose the receiver's web ports.

If you attach the static IP after pairing, the dashboard discovers the new address through Tailscale every five minutes while the main server is active. Confirm the failover-server address on the dashboard changes to the static IP before relying on it. The incoming stream still uses public UDP, so an address change can leave the failover server unavailable until rediscovery. Address changes are deferred while the failover server carries the stream, until you switch back to the main.

The setup progress panel stays visible above the setup instructions: waiting for Tailscale, contacting the receiver (with its Tailscale IP), pairing, then copying your setup. It shows the last discovery check and survives a page reload. Before the server joins Tailscale, the dashboard cannot distinguish booting from installing or an installation failure; use Lightsail's SSH connection and the cloud-init log for that detail.

Not paired after 20 minutes? In Lightsail click Connect using SSH on the instance and run sudo tail -n 30 /var/log/cloud-init-output.log. It says what went wrong — most often the Tailscale key (single-use, or expired). If it ends with DONE, run sudo cat /root/streamhelpers-pairing-code.txt and paste that code into the box under Already installed one by hand? in the failover card.

The same script works as “user data” at most other providers (DigitalOcean, Vultr, Hetzner …) on Ubuntu 24.04 or Debian 12; open UDP 25554 in their firewall the same way.

You need:

• A second server, anywhere, running Ubuntu or Debian. A different provider, or at least a different region, from your main one is better — the whole point is that it is not affected by whatever took the main one down. Set a budget or spending alert with that provider first (see above).
• Its address, and an SSH login that is root, or a user that can use sudo without a password. A password or an SSH private key both work.
• UDP 25554 open to it, from anywhere, exactly as for your main server (see Open one port).
• A reusable Tailscale auth key, or let it use the same key your main receiver has. Single-use keys work only once.
• Your main receiver already set up, paired and working, on a release from late 2026 or newer.

Then:

1. Open the dashboard's Restreamer tab and unfold Failover server (advanced) near the bottom.
2. Under Set up a failover server, fill in the server's address, SSH port (usually 22), user, and the password or key. Leave the Tailscale key empty to reuse the main receiver's.
3. Press Install failover server. Your main receiver logs in to the new server over SSH and installs a failover receiver on it; the log shows as it goes. It takes 5 to 15 minutes, and you can leave the page.
4. When it finishes, the dashboard pairs with it and copies your Restreamer channels and platforms across. The header gets a Failover chip that says ready.

The SSH password or key is used for that one install and is not kept on the router. The main receiver keeps it so it can update the failover server later; Remove failover server deletes it.

Prefer to install it yourself? On the failover server, run

wget -qO- https://streamhelpers.com/receiver | sh -s -- --failover

add a Tailscale key on its settings page, copy its IRLCFG- code, and paste it into the box under Already installed one by hand? in the failover card, then press Use code. Do not paste that code into the guided setup, which would make it your main server.

Test the actual switch: press Test failover (real switch) and confirm the outage-style prompt. This is not a simulation: the dashboard moves the bond and outputs to the backup and shows the permanent ON FAILOVER SERVER banner. Your main server stays online. A live broadcast can briefly lose its feed. Use Switch back when finished.

Open its Restreamer shows the backup's own generated username and a Copy password button, followed by Open Restreamer login. It does not use your main server's password or place credentials in the URL.

• Your setup. Every few minutes, and whenever you press Send changes now, the dashboard copies your Restreamer channels, platforms and stream keys to the failover server. If it cannot reach it, the chip says changes not sent — bring the server online and press Send changes now.
• The receiver itself. When your main receiver is updated, it updates the failover server too. If the failover server was off, the chip says update needed; start it and press Update failover server.
• Changes you make on the failover server while you are on it are not copied back to the main one. Make lasting changes on the main server after switching back.
• The copy is made with nothing running, so the two servers never push to your platforms at the same time. When you switch, the main server's outputs are stopped as soon as it can be reached.

Remove failover server in the card forgets it. The server itself keeps running until you cancel it with your provider.