If your YouTube encoder is running directly in an SSH terminal, a broken SSH connection can also end the process. Run the encoder inside a tmux session on the remote host, detach from that session, and reconnect later when you need to inspect it.
That solves the terminal-lifetime problem, not every streaming problem. tmux does not keep a crashed encoder, rebooted host, failed network connection or rejected YouTube feed healthy, so you need to identify which failure you are trying to recover from.
Why an SSH disconnect can stop the encoder
An SSH connection gives you a remote shell, but the shell is still part of a session owned by that connection. Programs started from it can inherit the terminal and receive a hangup signal when the connection ends. Whether a particular process exits depends on how it was launched and how the host handles the disconnect, but relying on a plain SSH window is a poor basis for an unattended broadcast.
This is easy to miss during testing. You start an encoder, see video in YouTube Live Control Room, close the laptop lid or lose mobile data, and assume the remote machine will continue. Later, the stream has stopped because the encoder was tied to the shell that disappeared.
The useful distinction is between the SSH client and the remote process. Your laptop is the client. The Linux machine you connect to is the remote host. tmux must run on the remote host, and the encoder must be launched inside tmux there. Starting tmux on your laptop and then opening SSH inside it only protects the local SSH client session. It does not separate the remote encoder from the remote SSH session.
This approach suits a command-line encoder such as FFmpeg, provided FFmpeg and its input files are already available on the remote machine. If you are building a playlist-based broadcast, the automatic video playlist guide covers the media side separately from keeping the terminal session alive.
Before changing anything, decide what you expect the setup to do. If you only need to close SSH without stopping a healthy encoder, tmux is a sensible tool. If you need an encoder to restart after a crash or a machine to recover after a reboot, you need a different layer as well.
Create or attach to a named tmux session
After connecting to the remote host, check that tmux is installed:
tmux -V
If the command is unavailable, install tmux using the package manager for the distribution and account you administer. The installation command varies between Linux distributions, so do not paste a command intended for a different host without checking first.
Create a named session, or attach to it if it already exists:
tmux new-session -A -s youtube-live
The -s youtube-live part gives the session a name you can recognise later. The -A option means that tmux creates the session when it does not exist and attaches to the existing session when it does. This is convenient for a one-channel setup, but it also means you should look carefully at what is already running before entering commands.
A named session is safer than relying on a number such as 0. If you later host a devotional stream, a local news loop and a study channel on the same machine, separate names make it less likely that you will inspect or stop the wrong process. For example, you might use devotional-live, news-loop and study-live, provided each session is used consistently.
If you want to see sessions without attaching to one, use:
tmux list-sessions
You may see a result showing the session name, number of windows and when it was created. That tells you a tmux session exists; it does not prove that the encoder is still running or that YouTube is receiving a usable feed.
The command from the opening example is deliberately safe for a named workflow, but it is not a health check. An existing session may contain an old shell, an error message or an encoder that stopped hours ago. Read the pane before starting another copy.
Start the encoder inside tmux
Once you are looking at the shell inside the remote tmux session, start your encoder there. Use the command that matches your media files, audio settings and YouTube configuration. The exact encoder command cannot be universal because the input, output, resolution, frame rate and operating system are not specified here.
YouTube’s encoder workflow uses a stream URL and stream key from Live Control Room. Its official encoder instructions explain where those values come from and how an encoder connects to the broadcast. Keep the stream key private, just as you would keep a password private.
A typical workflow is therefore:
tmux new-session -A -s youtube-live
# Run your encoder command here
Do not type the comment as an encoder command. Replace it with the command you have tested for your own media. If your command reads a local file, verify that the file path exists on the remote host. A path that works on your desktop will not automatically exist on a VPS or another remote Linux machine.
Watch the initial output rather than detaching immediately. Look for evidence that the input opened, audio and video are being processed, and the connection to YouTube was accepted. Then check Live Control Room from a separate browser session. This catches an incorrect path, expired stream configuration, missing codec support or a connection error before you leave the process unattended.
For a transport connection, YouTube documents RTMPS as RTMP over TLS/SSL and provides the relevant URL through Live Control Room. You can read the YouTube RTMPS guidance when choosing the connection details supported by your encoder. Transport security does not make the SSH process persistent; these are separate connections with separate failure modes.
If the encoder prints regular progress information, leave it visible while testing. That output will be useful when you reconnect. If it produces too much output, redirecting logs may make later inspection easier, but do not hide errors until you have confirmed the command works.
Detach without stopping the session
When the encoder is running inside tmux, detach with this key sequence:
- Press
Ctrl+b. - Release both keys.
- Press
d.
The d is a tmux command, not input sent to the encoder. You should return to the ordinary SSH shell and see a message indicating that the session was detached. You can then close SSH. The tmux session and the encoder remain on the remote host while that host, process and network connection continue to function.
Do not type exit in the tmux pane when your intention is to detach. Exiting the shell can close the pane, and if the encoder is running as that pane’s foreground process, it can end the encoder as well. Detaching leaves the pane and its foreground process in place; exiting leaves it no longer running in that pane.
You can test the procedure deliberately rather than waiting for a night-time failure. Start the encoder, confirm the feed, detach, close the SSH client, wait a while, then reconnect from another network if practical. The purpose of the test is to confirm that tmux is installed on the host you actually use and that you are reconnecting to the same user account and machine.
A remote host may have more than one account, address or machine label. If you reconnect as a different user, that user may not see the original tmux session. If you connect to a replacement machine with the same project name, there will be no session there. Record the SSH host, user account, media paths and session name somewhere you can use during an incident.
For people who prefer an automation workflow rather than an interactive terminal, the distinction is covered in the guide to using a radio automation system with YouTube Live. Automation and process persistence overlap, but they solve different parts of the broadcast.
Reconnect and inspect or reattach
When you return, connect to the same remote host and account, then list the sessions:
tmux list-sessions
If the named session is present, reattach using an exact target:
tmux attach-session -t '=youtube-live'
The equals sign tells tmux to use the exact session name. That avoids accidentally matching a similarly named session, which matters when one host carries several channels.
Read the pane before pressing keys or launching another command. You may find the encoder still printing normal progress, an error followed by a returned shell prompt, or a connection message that needs investigation. If the pane is showing the encoder, you can watch it interactively as if the SSH connection had never been closed.
When you finish inspecting it, detach again with Ctrl+b, then d. Reattaching does not restart the encoder. It only connects your terminal to the existing tmux session. If the process has ended, first establish why it ended before launching a replacement. Starting a second encoder with the same stream key can create confusion and may not produce the result you expect.
If you need to enter a command after the encoder has stopped, make sure you are at a shell prompt inside the intended session. If the old process is still attached to the pane, use the encoder’s normal stop procedure or terminate it only after checking the effect on the live broadcast. A stream that has already stopped is different from one that is merely hidden because you detached.
What tmux does and does not keep healthy
tmux preserves a terminal session across an SSH disconnect. It does not supervise the encoder in the broader sense. A process can crash while the tmux session remains open, and a process can stay alive while its outbound connection to YouTube is broken.
The following comparison helps choose the right tool:
| Approach | Reconnect to the same interactive terminal | Keeps ordinary output | Restarts after a process crash | Starts again after a host reboot |
|---|---|---|---|---|
| tmux | Yes | In the session, while retained by the session | No | No |
| screen | Yes | In the session, while retained by the session | No | No |
nohup with redirected output |
No interactive reattachment | Yes, in the chosen log file | No | No |
| Service manager or supervisor | Usually no terminal reattachment | Through configured logs | Can be configured to restart | Can be configured to start at boot |
screen offers a similar reattachable-session pattern. nohup command > output.log 2>&1 & is useful for a simple background command whose output you want to capture, but it is not the same as returning to the live terminal. A service manager or process supervisor is the relevant layer when automatic restart and boot recovery matter.
A service-based setup needs the actual encoder command, file locations, environment variables, permissions, user account, restart policy and operating system. Do not apply a generic service unit without checking those details. A unit that launches successfully in one deployment may fail because the media path, stream key environment or working directory is different in another.
The host itself can become unavailable through a reboot, termination, disk problem, resource exhaustion or a provider-side event. tmux cannot run without the host. Likewise, it cannot repair an encoder that has exhausted memory, lost access to its input file or been killed by the operating system.
The network path is another boundary. The SSH connection from you to the host can fail while the host-to-YouTube connection remains healthy, which is the case tmux addresses. The host-to-YouTube connection can also fail while SSH remains available. In that situation, you can reconnect and inspect the encoder, but tmux does not restore the feed by itself.
YouTube can also stop receiving or accept no usable content because of encoder settings, account configuration, stream lifecycle rules or a platform-side issue. YouTube says that to end a stream, you stop sending content from the encoder, and it states that streams under twelve hours are automatically archived. Those are YouTube lifecycle details, not promises that a detached process will continue indefinitely.
Diagnose the failure before changing the tool
If the stream stops overnight, do not begin by assuming SSH was the cause. Reconnect and check whether the tmux session exists:
tmux list-sessions
If the session is missing, check whether the host is the one you expect, whether the user account is correct and whether the machine rebooted or was replaced. If the session exists, attach to it and inspect the pane. A returned shell prompt usually means the foreground encoder ended, while a running command points you towards the input, network or YouTube side.
Then separate four questions:
- Did the encoder process exit?
- Is the remote host reachable and sufficiently resourced?
- Can the host reach the relevant YouTube endpoint?
- Is YouTube reporting an error or no longer receiving usable video and audio?
YouTube’s live-stream troubleshooting guidance recommends checking the encoder, stream quality, dashboard errors, encoder CPU load and outbound internet connectivity. Follow that sequence rather than treating tmux as a replacement for monitoring.
For a long-running devotional or ambience channel, test the exact overnight command with the exact media files you plan to use. A command that handles one short clip may fail at the end of the file, when a playlist changes, or when an input becomes unavailable. If your channel depends on slow or variable connectivity, the advice in Slow Internet? You Can Still Run a 24/7 Live Stream is relevant to the network side, while tmux remains the terminal-side solution.
Keep a small recovery note containing the host address, SSH user, tmux session name, encoder command location, log location and the YouTube Live Control Room page. Do not put the stream key in a shared note unless it is protected. A recovery note helps you distinguish “I cannot see the terminal” from “the broadcast has actually stopped”.
If you do not want to maintain a remote encoder and its recovery process yourself, StreamNeo removes the SSH-session problem by letting you upload the video once, connect the YouTube channel, and run the broadcast without leaving your own computer switched on. It still does not change YouTube’s content rules or make every source file and channel configuration suitable for live streaming.
Choose the recovery level before going live
For a small channel, tmux may be all you need when the main risk is losing your SSH connection during a healthy broadcast. It gives you a familiar terminal to revisit and makes the first failure investigation straightforward.
For a channel that must recover from encoder crashes, use a supervisor or service manager designed for that host. Configure and test its restart behaviour with the actual encoder rather than assuming that a detached terminal will relaunch anything. For a host that must recover after reboot, test the boot sequence as well, including network availability, file mounts and credentials.
For a channel where you mainly need to publish an uploaded loop and avoid maintaining a remote command, a managed workflow may be a better operational fit. The YouTube-only versus multi-platform tools comparison is useful when deciding whether you need YouTube alone or several destinations.
Whatever you choose, make one controlled failure test before relying on it. With tmux, the test is an SSH disconnect. With a supervisor, it includes stopping the encoder and observing whether the configured policy behaves as intended. With a managed workflow, it includes checking the YouTube feed after your own computer is disconnected.
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
Will tmux keep my YouTube stream running if my laptop loses internet?
It can keep the remote terminal session separate from your laptop’s SSH connection, provided the remote encoder, host and host-to-YouTube network connection remain healthy. It cannot repair a failure on the remote host or in the encoder.
Should I run tmux on my laptop or on the server?
Run tmux on the remote host where the encoder runs. A tmux session on your laptop does not protect a remote process after the SSH session on the server ends.
How do I reconnect to the stream later?
Connect to the same host with the same user account, run tmux list-sessions, then use tmux attach-session -t '=youtube-live'. Read the existing pane before entering commands, because the encoder may still be running or may have stopped.
Is tmux enough for a 24/7 channel?
It is enough for separating a process from an SSH disconnect, but not for automatic recovery from crashes or reboots. If those failures matter, use a correctly configured service manager or supervisor and test it with your real encoder command.