If your YouTube encoder is running on a remote Linux machine, start it inside a named tmux session before disconnecting SSH. You can then close your laptop terminal while the encoder continues running on the remote host.
The exact workflow is tmux new-session -A -s youtube-live, start the encoder in that session, detach with Ctrl+b followed by d, and later reconnect with tmux attach-session -t youtube-live. This protects an interactive process from an ordinary SSH disconnect, but it does not restart a crashed encoder or survive a server reboot.
Know what tmux does, and what it does not do
SSH gives you a terminal on another computer. If you start FFmpeg, VLC, or another encoder directly in that SSH terminal, the process may receive a hangup when the connection ends. The result can be a stopped encoder and a YouTube broadcast with no incoming video.
tmux is a terminal multiplexer. It creates a session on the remote host and keeps that session available after you detach from it. The shell and the encoder continue inside the remote session, while your SSH connection is free to close. The tmux manual documents this session and reattachment model.
That protection has a clear boundary. A tmux session does not restart FFmpeg after a process crash, repair a broken input file, restore a failed network route, or bring a machine back after a reboot. It also cannot override a host policy that terminates user processes when an account logs out or when the instance is stopped.
This distinction matters for a 24/7 channel. If your only requirement is, “Do not stop the encoder when I close SSH,” tmux may be enough. If the requirement is, “Keep streaming without anyone watching it and recover from failures overnight,” you need a service supervisor, logging, and a way to check the YouTube ingest status.
The same separation applies to YouTube. YouTube receives the media sent by your encoder. If the encoder stops transmitting, the sending side of the broadcast has stopped, even if a tmux session still exists. You can review the encoder setup in YouTube's official live-streaming help, including the stream URL and key used by the encoder.
SSH into the remote host
First connect to the Linux machine that will run the encoder. Use the same host, username, and authentication method that you normally use for administration. A typical command looks like this:
ssh username@example-host
Replace both values with those for your machine. If you normally specify a private key or a non-standard SSH port, use the same options you use for other remote work. The important point is that tmux must run on the remote host, not only on your laptop.
You can check where you are before starting anything:
hostname
whoami
pwd
This is a small check, but it prevents a common mistake: opening a tmux session locally and assuming it protects a process running on the VPS. A local tmux session only protects local commands. The encoder must be launched after you have connected to the machine that is sending the stream to YouTube.
Next check whether tmux is available:
tmux -V
If the command is not found, install tmux using the package method supported by your Linux distribution, or ask the host administrator to install it. Do not guess the package manager if you are working on a managed system. The installation command is separate from the streaming workflow and varies by distribution.
Before starting the encoder, check the practical parts of the stream as well. Confirm that the media file or playlist is present, that the account can read it, and that the encoder command already works while you are connected. If the source is a playlist, make sure it has the behaviour you expect when one item ends. If you are building a loop, the guide to setting up a 24/7 YouTube stream with a static image between videos covers a different part of the same operating problem.
Create or attach to a named tmux session
Use one named session for this channel:
tmux new-session -A -s youtube-live
The -s youtube-live option gives the session a memorable name. The -A option attaches to the session if it already exists, or creates it if it does not. You should see a new shell, usually with a status line along the bottom of the terminal.
You are now inside tmux. Commands typed here run on the remote host, within the named session. If you already had an encoder running in this session, look at the screen before entering anything. The -A option can attach you to an existing session, so typing immediately could send a command to a process or shell you did not expect.
To see existing sessions without attaching to one, use:
tmux list-sessions
A session might be shown with a name such as youtube-live, along with the number of windows and whether it is attached. If you want to attach explicitly, use:
tmux attach-session -t youtube-live
The name is not cosmetic. It gives you a reliable target when the host runs more than one workload, such as a devotional channel and a local-news loop. Use distinct names for distinct encoders rather than putting unrelated processes into one terminal.
For example:
tmux new-session -A -s devotional-live
tmux new-session -A -s local-news-live
Do not create a second encoder simply because the screen looks empty after reconnecting. First list the sessions and inspect the process state. Two encoders using the same stream key can produce confusing results, and a new tmux shell does not tell you whether another process is already transmitting.
Start the encoder inside tmux
With the named session open, run the encoder command in that shell. It could be an existing FFmpeg command, a VLC command, or another configured encoder. The essential requirement is that the command is started after entering the remote tmux session.
For a placeholder example:
ffmpeg -re -stream_loop -1 -i /path/to/video.mp4 \\
-c:v libx264 -c:a aac \\
-f flv "rtmps://your-ingest-url/your-stream-key"
Do not copy this as a complete production command without checking the input, codecs, output settings, and ingest address for your stream. The stream URL and key should come from YouTube Live Control Room. Treat the key as a secret: do not put it in a public article, screenshot, shell history shared with others, or repository.
YouTube also documents RTMPS, which sends RTMP over TLS/SSL. If your encoder and account setup support it, use the current RTMPS address provided by Live Control Room and follow the official RTMPS ingestion guidance. The address, port, and hostname are part of the ingest configuration, not values to invent from memory.
Watch the encoder output for enough time to establish that it is doing more than merely starting. Look for frames being processed, audio being read if the programme includes audio, and the absence of immediate input or connection errors. Then open YouTube Live Control Room and check that the expected incoming preview or status appears. A live tmux session is not proof that YouTube is receiving media.
This is also the point to check the picture and sound settings. If the stream is technically running but the output is unsuitable, detaching will only leave the wrong configuration running unattended. The YouTube RTMP resolution and frame-rate settings guide can help you check those choices before leaving the machine.
If your command uses a playlist, confirm what happens when the current item finishes. If it exits at the end of the file, tmux will keep the shell available but it will not restart the encoder. If it loops internally, watch for the first transition and confirm that the process remains active.
Detach and close SSH safely
Once the encoder is running inside the correct session, detach from tmux with this key sequence:
- Press
Ctrl+b. - Release both keys.
- Press
d.
These are separate key presses. Do not hold Ctrl while pressing d. You should return to the ordinary SSH shell and see a message indicating that the tmux client has detached. The tmux session, shell, and encoder remain on the remote host.
You can now close SSH normally:
exit
Or close the local terminal after detaching. The important action was detaching from the remote tmux session before ending SSH, not leaving a laptop window open.
You can test the workflow deliberately. Start a short test stream, detach, close SSH, wait, and reconnect. If the process is still present and YouTube continues to show incoming media, you have confirmed the ordinary disconnect case on your host. This test does not prove recovery from every other failure.
A network drop during an already-detached session is handled in the same general way: the tmux session remains on the remote machine and can be attached to later. If you lose the connection before detaching, tmux is still designed to preserve the session, but reconnect and inspect it rather than assuming the encoder is healthy.
Some hosts apply account, shell, or instance policies that affect long-running processes. If the session disappears after logout, check the host documentation and system logs. Do not conclude that tmux failed until you have confirmed that you reconnected to the same hostname and account.
Reconnect and reattach later
When you want to inspect the encoder, SSH into the same remote host again:
ssh username@example-host
List the available tmux sessions:
tmux list-sessions
If youtube-live is present, attach to it:
tmux attach-session -t youtube-live
You should see the terminal where the encoder was running, including its current output or its last messages. If the encoder is still active, avoid pressing keys that send input to it. Read the output first and decide whether you need to interrupt or reconfigure anything.
If you know the session exists and want the shorter form, this also works:
tmux attach -t youtube-live
After inspecting it, detach again with Ctrl+b, then d. Do not use exit inside the encoder's shell unless you intend to close that shell and possibly end the process. If the encoder is attached to the terminal and you send an interrupt, it may stop the broadcast.
If no session is listed, check the basics in this order:
- Are you on the same host, rather than a replacement VPS or a different IP address?
- Are you using the same Linux account that created the session?
- Did the server reboot or get replaced?
- Did the encoder exit because its input ended or an error occurred?
- Does the host terminate user processes after logout or at an administrative reset?
You can also check running processes, if you have permission:
ps -ef | grep '[f]fmpeg'
The absence of a tmux session and the absence of an encoder process are related but not identical findings. A process may have been launched outside tmux, or a supervisor may have started it separately. Inspect before starting another copy.
If the encoder is running but YouTube shows no incoming media, investigate the ingest path rather than tmux. Check the encoder's latest error, the configured URL, the network route, and the stream key. YouTube's status page in Live Control Room is a more useful signal than the mere presence of a terminal session.
For a stream that must preserve a continuous watch page while you correct a failure, review how to restart a 24/7 YouTube stream without losing its watch page. The operational decision is separate from the tmux command itself.
When tmux is not enough
For a channel that must run unattended, use a service supervisor rather than treating tmux as one. On many Linux systems, systemd can start a process at boot, define restart behaviour, record logs, and expose a status command. Those controls require a service file and validation on the actual host.
A service might be configured to run the encoder as a particular user, use absolute paths, load a protected environment file, and restart after a process exit. The exact policy depends on your distribution and the failure you are trying to handle. A restart rule can respond to an exited process; it cannot guarantee that the input is valid, the network is available, or YouTube accepts the connection.
An example project showing FFmpeg managed by systemd is available in this open-source repository. Treat it as an implementation example, not as a universal configuration or a guarantee for your host. Check the service file, permissions, paths, logging, and restart behaviour before using any part of it.
A sensible service-testing sequence is:
- Run the encoder command manually and confirm the stream works.
- Put the same command into the service configuration with absolute paths.
- Start the service and inspect its status and logs.
- Stop the encoder process intentionally and check whether the configured policy responds as expected.
- Reboot only during a planned test window, then confirm both the service and YouTube ingest.
Do not use tmux and systemd for the same encoder unless you understand which one owns the process. If systemd starts FFmpeg, attaching to a tmux shell will not show that process unless you separately run a monitoring command there. Conversely, if you start FFmpeg manually in tmux and also enable a systemd unit, you can accidentally create duplicate encoders.
Here is the practical comparison:
| Approach | Useful for | What it does not provide |
|---|---|---|
tmux |
Starting an encoder interactively, viewing output, and reconnecting after SSH closes | Automatic recovery from a crash, reboot, failed input, or failed YouTube ingest |
nohup or another detached command |
A simple non-interactive process where you do not need to return to its terminal | A named interactive session, service lifecycle controls, and a complete recovery policy |
systemd |
Boot startup, service status, logs, and configured restart behaviour | A guarantee that the network, media source, host, or YouTube will remain available |
For many first deployments, tmux is the clearest way to prove that the encoder command works remotely. Once the channel has to operate without a person checking it, move the lifecycle responsibility to a supervisor and add monitoring. Keep tmux available for maintenance if you want an interactive inspection tool, but do not mistake it for the recovery layer.
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 closing my SSH window stop FFmpeg?
Not if FFmpeg was started inside a tmux session on the remote host and you detached from that session first. Closing SSH still ends your connection, but the remote tmux session can remain available. This does not protect against an FFmpeg crash, a reboot, or a host policy that terminates the process.
Can I run tmux on my laptop instead?
A local tmux session protects commands running on your laptop, not commands running on a remote VPS. SSH into the machine that sends the stream, then create or attach to tmux there. Confirm the host with hostname before starting the encoder.
How do I get back to the running stream?
Reconnect to the same host and account, run tmux list-sessions, and attach with tmux attach-session -t youtube-live. If the session is missing, check the hostname, username, reboot history, host policies, and whether the encoder exited. Do not start a second encoder until you know what happened to the first one.
Does tmux restart the stream after a server reboot?
No. tmux preserves a terminal session across an ordinary SSH disconnect, not across a host reboot or server termination. Use a properly tested service supervisor such as systemd for startup and configured process-restart behaviour, while checking network and YouTube ingest separately.