If you start a YouTube encoder directly in an SSH terminal, closing that connection can also stop the encoder. To keep it running while you disconnect, start the encoder inside a named tmux session on the Indian VPS, detach from that session, and then close SSH.
This protects the process from a terminal or SSH disconnection only. tmux does not restart an encoder that crashes, bring a VPS back after shutdown or reboot, or keep YouTube live after the encoder stops sending content.
Why closing SSH can stop a foreground encoder
An SSH connection gives you a remote terminal. When you type an encoder command there, the encoder is normally a foreground process attached to that terminal. Its output appears in the same window, and you can stop it with the usual interrupt command or by closing the session.
That arrangement is convenient while you are setting up a stream. It is less suitable for an always-on channel. If your broadband connection drops, your laptop sleeps, a mobile hotspot changes network, or the SSH client times out, the terminal can disappear while the VPS remains powered on. A process tied directly to that terminal may then receive a hang-up signal or otherwise lose the environment it was using.
The important distinction is between the VPS and the terminal. The VPS can still be running even though your SSH window is gone. Your encoder may also be capable of continuing, but only if it was started in a session designed to remain available after the terminal disconnects.
A remote tmux session provides that separate session. The tmux manual describes each session as persistent through accidental disconnection, including an SSH timeout, and says it can later be reattached. See the tmux manual for the behaviour and keyboard controls.
This is why starting tmux on the local computer is not enough. If you open tmux on your laptop and then SSH into the VPS from inside it, the tmux session belongs to the laptop. Closing the local terminal may still remove the remote command's terminal. You need to log in to the VPS first, then create tmux there.
Install tmux and create a named session on the VPS
First connect to the VPS in the usual way. From your computer, that may look similar to this:
ssh your-user@your-vps-address
Use the username and address supplied by your VPS provider. Once the shell prompt shows that you are on the remote machine, check whether tmux is already available:
tmux -V
If the command is not found, install it using the package tool for the Linux distribution on the VPS. On a Debian or Ubuntu-based system, the command is commonly:
sudo apt update
sudo apt install tmux
On a distribution that uses DNF, the equivalent package command is commonly:
sudo dnf install tmux
The exact package permissions and commands can vary with the image supplied by your VPS provider. If you do not have sudo, ask the account administrator to install tmux or use the distribution's documented package instructions.
Now create a session with a name you will recognise:
tmux new -s youtube
The name youtube is only an example. A name such as bhajan, news-loop, or study-channel can be easier to identify if you run more than one channel. The name matters later because it lets you attach to the intended session rather than guessing which terminal is active.
After the command runs, you are inside tmux on the VPS. You will usually notice a status bar along the bottom of the terminal. That is a sign that commands entered now are running inside the remote tmux session.
You can confirm the session exists with:
tmux ls
Run that from inside tmux or from another shell on the same VPS. You should see the session name and its attached state. Do not create a second session accidentally if the first one already contains your encoder.
Start the encoder inside the remote session
With tmux open on the VPS, start the encoder exactly as you normally would for the channel. This might be FFmpeg, another command-line encoder, or a graphical encoder available through a remote desktop. The requirement is that the encoder command is launched after tmux new -s youtube has created the session.
For a command-line workflow, your existing command may be stored in a script or copied into the terminal. Do not replace working video, audio, codec, bitrate, or looping settings merely to use tmux. tmux is the terminal layer around the encoder; it does not alter the media feed.
The encoder still needs the YouTube live server URL and the stream key from YouTube Studio. YouTube describes the stream key as the credential used by the encoder to send the feed and have YouTube accept it. Treat it like a password: do not paste it into a public support forum, commit it to a public code repository, or share a screenshot that shows it.
In YouTube Studio, create or select the live stream in the Live Control Room, then copy the server URL and stream key into the encoder's stream settings. YouTube's guide to creating a live stream with an encoder explains the standard setup and the steps for starting the feed.
Wait for the encoder to establish its connection before detaching. Read its output rather than assuming the command succeeded. A successful process should normally remain running and show ongoing activity, while a configuration error, rejected key, unavailable input file, or network problem should be visible in the terminal.
If you use a loop of recorded files, check that the input paths are available on the VPS, not only on your home computer. A command can start correctly and then stop when it reaches a missing file or an inaccessible mount. A tmux session preserves the process environment, but it cannot provide files that the encoder cannot read.
For a continuous church stream, you may also want to review the OBS setup guide for a continuous church stream. The same principle applies even when the encoder software differs: first make the feed work, then run the encoder within the remote session that you plan to leave unattended.
Detach before closing SSH
Once the encoder is running inside the youtube session, detach from tmux instead of closing the terminal window first. The keyboard sequence is:
- Press
Ctrl+B. - Release both keys.
- Press
D.
The Ctrl+B combination is tmux's command prefix. The second key, D, tells tmux to detach the client from the session. It does not send a stop command to the encoder. You should return to the ordinary VPS shell prompt, with a message indicating that the session was detached.
At this point, the encoder remains in the tmux session on the VPS while your SSH client is no longer watching it. You can now close the SSH window or type:
exit
If you use exit before detaching, you risk closing the shell that is hosting the encoder. The safe order is encoder inside tmux, detach from tmux, then leave SSH.
A common mistake is pressing Ctrl+C when intending to detach. Ctrl+C is normally delivered to the foreground encoder and can stop it. Another is typing exit inside the tmux window while the encoder is in the foreground. Neither is the same as the tmux detach sequence.
You can test the arrangement before relying on it overnight. Start a harmless test feed or your normal encoder, detach with Ctrl+B followed by D, close SSH, wait, and reconnect. The test should answer a practical question: does your chosen encoder continue sending data when the SSH client is gone?
Do not treat the test as proof that every failure will recover. It checks the terminal-disconnection case only. The VPS still needs power, the encoder still needs a working input, and the route to YouTube still needs to accept the feed.
Reconnect and reattach later
To inspect the encoder later, SSH into the same VPS again:
ssh your-user@your-vps-address
List the available tmux sessions:
tmux ls
If the session is called youtube, reattach to it with:
tmux attach -t youtube
You should see the encoder's current output, or the last output it produced before stopping. This is useful for checking warnings, input errors, connection messages, and whether the command is still running. If you have multiple sessions, use the name you chose when creating the relevant session.
If tmux says that the session does not exist, investigate before starting another encoder. The session may have ended because the encoder stopped and its shell exited, because the VPS was restarted, or because the session was created under a different user account. Running a second encoder with the same stream key can create confusion and may interrupt the feed.
If you are unsure whether a session is attached elsewhere, tmux ls will show its state. You can attach to a detached session normally. If another SSH window is already viewing it, tmux may move the view to the new connection or report that the session is attached, depending on the command and configuration. Reattach deliberately rather than creating a replacement session.
To leave the encoder running again, repeat the detach sequence. If you want to stop the encoder, first reattach, bring the encoder's terminal into view, and use the encoder's own stop method. After it stops, you can leave tmux with exit if you no longer need the session.
For channels built around repeated recorded material, YouTube's guidance on looping videos on YouTube Live and reused content is a separate consideration. tmux keeps a terminal session available; it does not decide whether your channel's content or presentation meets YouTube's current policies.
What tmux will not recover from
tmux is a session manager, not a complete unattended-stream recovery system. Its useful promise here is narrow: the session can remain available when the SSH connection is accidentally or intentionally detached. The following cases need to be considered separately.
| Event | What tmux does | What you must check or arrange |
|---|---|---|
| SSH disconnect or timeout | Keeps the tmux session available for later attachment | Reconnect to the same VPS and inspect the encoder |
| Encoder crash | Leaves the session, but does not prove that the encoder restarts | Find the error and use a separately configured process supervisor if needed |
| YouTube ingest interruption | Does not guarantee that the encoder reconnects or that YouTube accepts the feed | Inspect the encoder and YouTube stream health |
| VPS shutdown or reboot | Does not preserve a running session through the machine being stopped | Configure and test an appropriate startup and restart method |
| VPS host or network failure | Cannot repair an unavailable machine or route | Contact the provider or use a separately tested continuity plan |
If the encoder crashes, tmux may still exist with a shell prompt. That can look like persistence when the actual stream process has already ended. Reattach and look at the terminal output. A blank prompt is not evidence that YouTube is receiving content.
Likewise, tmux does not turn a VPS reboot into a normal SSH disconnect. When the operating system stops, the running tmux process stops with it. After a reboot, a separate service-start or process-supervision arrangement may launch the encoder again, but that is outside tmux's basic behaviour and must be configured and tested for your VPS's Linux distribution.
Automatic restart also has consequences for YouTube's stream state. YouTube says that stopping content from the encoder ends the stream, and streams under 12 hours are automatically archived. Do not assume that restarting the command will resume the same live event indefinitely. Check the current YouTube encoder instructions and plan how you will handle a stopped or recreated broadcast.
For a 24/7 channel, compare the tools by the failure they address. tmux is useful for SSH disconnection and for inspecting an interactive command. A service manager may be more appropriate for startup after reboot or automatic process restart, but the correct configuration depends on the operating system and encoder command. Do not install a restart mechanism without testing whether it can create duplicate processes or repeatedly launch a command with a bad stream key.
You also need to distinguish an encoder failure from an input failure. If a disk fills, a media file becomes unreadable, a mounted directory disappears, or the encoder loses access to its audio source, restarting the same command may simply fail again. Monitoring and clear logs are more useful than assuming every interruption is an SSH problem.
Check YouTube ingest and stream status
A running process on the VPS is only one part of the chain. The encoder must still send data to YouTube, and YouTube must still receive and process it. After starting the encoder, open YouTube Studio's Live Control Room and check the preview and stream health indicators before treating the broadcast as ready.
YouTube recommends previewing the feed before going live, monitoring stream health, and testing failover by stopping the primary encoder or disconnecting its network. Its guidance also recommends allowing bandwidth headroom above the total streaming bitrate. YouTube's live streaming troubleshooting guidance is the place to check current recommendations rather than relying on an old VPS tutorial.
The VPS's upload connection matters as much as its location. An Indian VPS may reduce distance to some viewers or suit your operations, but the stream still needs a stable route from that VPS to YouTube's ingest service. Check the actual encoder messages and YouTube's health information instead of inferring quality from the server's country alone.
YouTube recommends RTMPS, its secure extension to RTMP, in its encoder guidance. Use the protocol and settings supported by your encoder and the current YouTube documentation. The correct bitrate, keyframe interval, codec, and resolution depend on the media and the available upload connection, so do not copy a setting merely because it appeared in a different channel's command.
You can also use a small operational checklist:
- Start the encoder inside the named tmux session on the VPS.
- Confirm that the encoder reports an active connection rather than only an open terminal.
- Check the Live Control Room preview and stream health.
- Detach with
Ctrl+B, thenD. - Reconnect later and inspect the encoder output.
- Record what happened if the stream stopped, including the time and the last visible error.
If the stream is important enough to run unattended, perform the test when you can observe the result. Disconnect your own SSH client and confirm that the feed continues, then test the failure cases separately. A terminal-disconnection test should not be described as a reboot-recovery test or an encoder-failover test.
There is also a content and channel-policy layer. If you run a repeated playlist, review whether a 24/7 YouTube stream with a repeating playlist can be monetised. That question is separate from whether tmux keeps the encoder process attached to a remote terminal.
A practical overnight runbook
Before leaving the stream unattended, use the same sequence every time. Consistency makes it easier to tell whether a problem came from the encoder, the VPS, YouTube, or the SSH connection.
First, log in to the VPS and check the named session with tmux ls. If it already exists, attach to it rather than starting another copy of the encoder. If it does not exist, create it with tmux new -s youtube and launch the encoder there.
Second, watch the encoder output long enough to see that it has connected and is processing the intended input. Check YouTube Studio at the same time. If either side shows an error, fix that before detaching.
Third, detach using Ctrl+B, then D. Close SSH only after the detach has returned you to the normal remote shell. If you want an additional check, log in from another SSH window and use tmux attach -t youtube to inspect the session.
Finally, write down the session name, the encoder command location, the VPS login details, and the steps for checking YouTube. Keep the stream key out of that note unless it is stored in an appropriately protected password manager or configuration file. A written runbook is particularly useful when the channel owner is not the person who originally configured the VPS.
If this setup becomes too dependent on leaving a command running in an interactive shell, consider a separately tested service configuration. Keep the roles clear: tmux helps you detach and return to the terminal, while a service or supervisor is the separate mechanism you would investigate for startup and restart behaviour. Neither removes the need to inspect YouTube's stream state.
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
How do I keep my YouTube live stream running when I close SSH?
Start the encoder inside a tmux session created on the VPS, then detach with Ctrl+B followed by D before closing SSH. Reconnect to the same VPS later and run tmux attach -t youtube to inspect it.
Will tmux restart my stream after a VPS reboot?
No. tmux protects a session from terminal disconnection, but it does not survive the VPS operating system stopping and does not provide reboot startup. Use and test a separate service or process-supervision arrangement if reboot recovery is required.
Does tmux reconnect the encoder if YouTube stops receiving it?
No. tmux preserves the terminal session, not the encoder's connection to YouTube. Reattach, inspect the encoder output and YouTube stream health, and troubleshoot the feed or use a separately tested restart method.
Is the stream safe to leave overnight after detaching?
Detaching removes the SSH terminal as a single point of failure, but it does not guarantee that the stream continues. The encoder, input files, VPS, network route and YouTube ingest must all continue working, so test the setup and monitor it before relying on it.