Move a YouTube loop stream from Linode to Hetzner by rebuilding the service on a new server, not by assuming a provider snapshot can restore it. Inventory the running stream, recreate its software and settings, verify media and credentials, test the destination, then cut over while Linode remains available for rollback.
A replacement encoder may interrupt the broadcast; no migration plan can promise a seamless hand-off. The aim is to know what must move, catch omissions before you switch, and retain a working route back if the new host misbehaves.
Inventory the Linode stream and its dependencies
Start with the service as it actually runs, rather than the server as it appears in a dashboard. Write down the operating system and architecture, encoder or transcoder and version, launch method, service user, media directories, playlist files, scripts, environment settings, logs and restart behaviour. If it runs in a container, record the image and how its configuration and data are mounted. A loop can look simple while depending on a path, permission or environment variable that nobody has touched for months.
Record where the video, audio, playlists and working files live. Note whether any data is on an attached block volume rather than the Linode's main disk. Make a list of the files and directories that the process needs to read, and note which ones change while the stream runs. If the loop is generated from a playlist or script, include those inputs, not just the final video file.
Also record the service's operating conditions: CPU and memory use while it is encoding, disk use and growth, network throughput, and any recurring warnings in the logs. These observations are more useful than choosing a server based on the word “loop”. A file that is merely relayed may need different resources from one being transcoded, and resolution, codec, bitrate and concurrent processing all affect the load.
Document firewall rules and the network details the process depends on. Record ports, allowed administration sources, DNS names if used, and any private network connections. Keep a note of the YouTube Live server URL and where the stream key is configured, but do not put the key in a general inventory, ticket, screenshot or shell-history command.
Take a copy of the current configuration and note how to start and stop the process. You need to be able to distinguish a service that is running because a supervisor launched it from a process that happens to remain alive in an interactive shell. For a starting point on how a prerecorded channel uses its credentials, see how a YouTube stream key is used for a prerecorded channel.
Prepare the Hetzner server
Create a Hetzner Cloud server with an operating system and architecture compatible with the software you intend to run. Hetzner's server creation documentation describes choices including OS image, SSH access, networking, volumes, firewall and cloud-init. Choose the server type and location by comparing your measured workload and operational needs, not by treating the destination as a copy of the old machine.
The relevant trade-offs include CPU and memory under the real encoding load, the media's storage footprint, architecture compatibility, network path to YouTube ingest and to you as operator, and the need for a public address or private network. Check current provider documentation for the available types, networking and pricing; these can change. Do not infer a destination configuration from an old tutorial or assume that a firewall policy from Linode transfers with the workload.
| Decision | What to compare | Practical check |
|---|---|---|
| Compute and architecture | Actual CPU and memory use; whether the encoder package supports the architecture | Observe the existing loop under its normal workload and verify software support before creating the destination |
| Storage | Media size, working space and whether data belongs on the system disk or a separate volume | Confirm the space required and plan a separate copy and verification for volume data |
| Network | Public access, private connectivity, outbound path and operator access | Identify the ports the service needs and keep administration access restricted |
| Location | Latency to YouTube ingest and convenience for management | Test from the intended destination rather than assuming a region is best |
| Recovery | How you will restore configuration and media if the new host fails | Keep independent copies and document the return-to-Linode steps |
Use SSH keys and a limited administrative approach suitable for your environment. Create the user and directory structure the loop needs, and plan ownership and permissions before copying files. If you use cloud-init or another repeatable method, treat it as a way to reproduce known configuration, not as a substitute for checking the resulting server.
Hetzner says its server backups and snapshots cover the server disk but exclude attached volumes. Its snapshot and backup guidance is worth checking when planning recovery, but this is not a Linode-to-Hetzner snapshot migration procedure. Build the new host and copy the data explicitly; make a separate plan for anything on attached storage.
Reinstall the loop and encoder software
Install the same encoder or a compatible replacement on Hetzner, then reproduce the way it is run. That may mean reinstalling packages, recreating a container deployment, restoring scripts, or configuring a service manager. The details depend on the Linode setup, so use the software's current documentation for the exact commands rather than applying a generic command sequence to an unknown system.
Match the source's functional behaviour: which user runs the process, which paths it reads, where logs go, how it starts after a reboot, and what happens after an encoder exit. Review package versions and configuration differences before treating the new installation as equivalent. A newer package may change defaults; a different operating system can change file locations or service behaviour.
For a continuously running channel, a process that starts once is not enough. Configure the service manager or supervisor to bring it back after a host reboot or a process failure, and make sure its logs are useful without containing secrets. Test a deliberate process restart and a server reboot while you are still on the test stage. That tells you whether recovery is configured or merely assumed.
If the source uses an RTMP relay or a custom media server, reproduce only the components the actual setup needs. Linode's RTMP server tutorial is an example of one possible architecture, not evidence that every loop uses it. Where an RTMP endpoint accepts input, check its authentication and access controls; do not expose a relay publicly just because a tutorial does.
Copy media and configuration
Copy the media, playlists, scripts, configuration and any local state identified in your inventory. Pick a transfer method suited to the size and shape of the data and your security needs. You might copy files over SSH, stage an archive, or use another controlled transfer process; the right choice depends on the source layout and whether the files change during the transfer.
If media is on an attached Linode volume, treat it as a separate data set. Hetzner explicitly excludes attached volumes from its server snapshots and backups, so do not assume a server-disk copy or snapshot contains that material. Copy it deliberately and check the destination path, permissions, and available space. A mismatched mount point can leave the service starting successfully but broadcasting an empty playlist or a fallback file.
For static files, compare the file inventory and sizes; where practical, compare checksums as well. For playlists, inspect referenced paths and confirm they resolve on Hetzner. Check that the service user can read each required file and write wherever the encoder stores temporary state or logs. A successful transfer is not the same as a usable media library.
If the source files change during transfer, plan a final synchronisation after the initial copy. First copy the bulk of the data while Linode continues to serve. At cutover time, pause changes to the media or playlist, perform the final synchronisation, then verify the new copy before starting the destination. For an unchanged prerecorded loop this may be straightforward; a channel that updates playlists or assets needs a clear freeze-and-sync window.
Recreate secrets through a secure method rather than copying them into public notes or command lines. Check configuration files, environment files and service definitions for credentials, then protect their ownership and permissions on the new host. The stream key deserves particular care: use the current value from YouTube Live Control Room, and avoid exposing it in logs, screenshots or transfer scripts.
Configure networking and YouTube credentials
Recreate the required firewall rules on Hetzner and confirm outbound connectivity from the new host. Allow only the administration and service traffic your design requires. If your encoder sends directly to YouTube, focus on the outbound connection; if your setup also accepts an incoming source or serves a management interface, account for those paths separately.
Fetch the current server URL and stream key from YouTube Live Control Room rather than assuming an old URL is still valid. YouTube's encoder instructions describe entering the server URL and key in the encoder settings and checking the resulting preview. For RTMPS, use the endpoint provided there: YouTube describes RTMPS as RTMP over TLS/SSL, and its guidance includes checking the URL and port when troubleshooting.
Enter credentials in the encoder's intended configuration mechanism, restrict access to the file or secret store, and verify that logs do not print them. Confirm the correct YouTube event or stream is selected. Previous stream settings may be available again, but treat that as a convenience rather than confirmation that the destination and key are the ones you meant to use.
Check the output format against the channel's expected resolution, bitrate, frame rate and audio. Do not change several variables at once during migration: preserving the established output makes host-related problems easier to isolate. If you do need a format change, test it separately and confirm the viewer-facing picture and sound.
Test the new host before cutover
Test the service while Linode remains the active publisher. First confirm the new host can read the copied media and that its playlist resolves to the expected files. Start the encoder only in a way that does not create competing publishers to the same live event. If you need to validate the ingest path, schedule a controlled test or use the appropriate YouTube workflow rather than sending two encoders to the same destination and hoping the platform chooses the intended one.
Check YouTube Live Control Room for the incoming feed and inspect the preview for picture, audio, resolution and stability. Then check the stream from a viewer's perspective, including any graphics or rotating visual the channel relies on. A guide to making a 24/7 radio stream with a rotating visual can help you think through elements beyond the audio track itself.
Exercise failure recovery before cutover. Stop and restart the encoder, verify that the supervisor brings it back as expected, and reboot the destination if your test window permits. Confirm that the process starts with the right media and settings without an interactive login. Review logs for permission errors, missing files, network failures and secret leakage. The goal is not merely to see a process running; it is to verify the path from boot to a correctly configured feed.
Write down the cutover and rollback actions in order, including who will check YouTube and who can stop either host. Decide what counts as a pass: for example, the intended content appears in the preview, the stream is viewable, audio is present, the playlist advances as expected, and a restart recovers. Keep the checks concrete and tied to your channel rather than relying on a vague impression that the migration “looks fine”.
Switch publishing and retain Linode for rollback
Choose a time when you can watch the change and respond. Before the switch, confirm the final media synchronisation is complete, the service configuration is reviewed, the key is current, the firewall is in place, and the destination test passed. Keep the Linode intact and do not remove its disk or attached storage as part of the same change.
A conservative sequence is to pause or stop the Linode encoder, verify that it has stopped sending, and then start the Hetzner encoder with the confirmed YouTube settings. Check Live Control Room, then the public stream. Avoid running both publishers against the same event unless your workflow explicitly supports that: simultaneous sends can make it unclear which feed is being received and complicate diagnosis.
There may be an interruption between stopping one encoder and the other being accepted. YouTube's encoder guidance describes starting and stopping the send; it does not guarantee that changing hosts preserves a single uninterrupted event. YouTube also says streams under 12 hours are automatically archived when sending content stops. Take that behaviour into account when deciding when to cut over and whether your channel is operating a continuing broadcast or a sequence of sessions. For more context on this platform behaviour, see why YouTube may end a 24/7 nature stream after 12 hours.
Keep Linode available during a defined observation period. If the new host cannot publish, the feed is wrong, or a restart fails, stop the Hetzner encoder and return to the known Linode configuration using the verified YouTube settings. Do not leave both hosts sending while you troubleshoot. Record what happened, correct the issue, and repeat a test before trying the cutover again.
Once the destination has passed normal operating checks, including a service restart and reboot recovery, you can plan Linode retirement separately. Before deleting anything, confirm all required media and configuration exist on the destination and in an independent backup, check attached media explicitly, and verify that the rollback window has ended by choice rather than by accident. Keep a record of the final service paths, firewall policy, and recovery steps for the next person on call.
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
Can I restore a Linode snapshot directly as a Hetzner server?
Do not plan the move on that assumption. Hetzner documents its own snapshot and backup behaviour, including that attached volumes are excluded; the available documentation does not establish that a Linode snapshot imports as a Hetzner snapshot. Rebuild the service and copy its required data explicitly.
Will viewers see an interruption during the cutover?
They may. Stopping one encoder and starting another does not come with a documented guarantee of a seamless event hand-off, so choose a low-impact time and tell your audience if appropriate. Keep the old host ready until the new feed and recovery behaviour have been checked.
What should I check before deleting Linode?
Confirm the destination can read every required file, including data formerly on attached storage, and that configuration, credentials, firewall rules and restart behaviour are correct. Verify the new stream under normal operation and after restart or reboot, then retain an independent backup before retiring the old host.
Should I use RTMP or RTMPS?
Use the current endpoint shown in YouTube Live Control Room and choose RTMPS when your encoder supports the supplied RTMPS endpoint. YouTube describes RTMPS as RTMP protected with TLS/SSL. Check the current official guidance if the connection fails, rather than reusing an endpoint from an old configuration.