If your FFmpeg command is running on a VPS, tmux lets the remote terminal session continue after your SSH connection closes. You can detach from the session, disconnect your computer, and later reconnect to inspect the same terminal and any FFmpeg output still on screen.
That does not make the VPS stay powered on, restart FFmpeg after it exits, or prove that YouTube is accepting the stream. tmux solves terminal disconnection; process supervision, VPS reboots, input failures and YouTube ingest errors need separate checks.
What tmux does and does not do
tmux is a terminal multiplexer. You start a tmux server on the VPS, create a named session, and run commands inside that session. Your SSH client displays the session, but the session belongs to the remote machine rather than to your laptop.
When you detach, the tmux session remains available on the VPS. The FFmpeg process continues to run as long as the remote tmux server, VPS and process remain active. You can then close your terminal or lose the network connection without sending the usual hang-up signal to the command inside tmux.
The tmux manual describes each session as persistent through an accidental SSH disconnection or intentional detachment. Read that as terminal persistence, not as a streaming service promise. A session can still disappear if the VPS is shut down, the tmux server is terminated, or the operating system encounters another failure.
There are four separate questions to keep in mind:
| Question | What answers it | What tmux contributes |
|---|---|---|
| Did SSH disconnect? | Your local network and SSH client | Keeps the remote terminal session available for reattachment |
| Is FFmpeg still running? | Process inspection and the FFmpeg pane or logs | Shows the process output when you reattach |
| Is the VPS still running? | The VPS provider and operating system | Nothing beyond running on the host |
| Is YouTube accepting valid media? | YouTube Live Control Room and ingest behaviour | Nothing; tmux cannot correct stream settings or rejected media |
This distinction matters for a devotional loop, local news replay or study channel that must run overnight. If the only problem is your home broadband dropping while you are administering the server, tmux is useful. If FFmpeg exits at 2 am, tmux leaves you a place to investigate but does not relaunch it.
For a wider comparison of the software choices, see FFmpeg or OBS for 24/7 YouTube streaming from prerecorded videos. The choice of encoder and the choice of terminal session are related, but they solve different problems.
Connect to the VPS and check the basics
Start from a computer with an SSH client and the login details for the VPS. The exact username, address and authentication method depend on your host. A typical connection looks like this:
ssh username@your-vps-address
Run this command on your local computer, not inside a remote shell. Once it succeeds, the commands that follow are being executed on the VPS. This is important: a tmux session started on your laptop does not protect a process running on the VPS, and a tmux session started on the VPS does not protect a process that you accidentally launched locally.
Before starting the stream, confirm where you are and which user is active:
hostname
whoami
pwd
These checks are simple, but they prevent a common mistake when you have several servers or terminal windows open. You can also check whether tmux is installed:
tmux -V
If the command is missing, install tmux using the package instructions for the Linux distribution on the VPS. Do not paste a package command from an unrelated distribution without checking. You should also confirm that FFmpeg is present and identify the build you are actually using:
ffmpeg -version
Do not treat the version output as proof that a particular input, codec or protocol will work. It only tells you what executable is available. Test the complete FFmpeg command in an ordinary foreground shell before putting it into tmux. That gives you a clean view of syntax errors, missing files, permissions and input problems.
If the source is a prerecorded file, confirm its path and permissions. An absolute path is usually clearer for an unattended command:
ls -lh /home/username/media/stream.mp4
A relative path can work during a manual test and then fail later because the command is started from a different directory. The same applies to fonts, playlists, overlays, audio files and scripts referenced by the command.
Create a named tmux session
Once you are inside the VPS, create a session with a name that tells you what it is for:
tmux new -s youtube
The name youtube is only an example. If you operate more than one channel, use names such as bhajan, study, or news-loop. Avoid spaces and keep names easy to type. A named session is safer than relying on whichever unnamed session happens to be listed later.
After running the command, the screen may look almost unchanged. You are now inside tmux. Start the verified FFmpeg command only after checking that the shell prompt belongs to the VPS and that you are in the intended session.
You can list sessions from a normal shell with:
tmux ls
A session list may show a name, an attached or detached state, and the number of windows. If you are already inside a tmux session, creating another one without noticing can make later reattachment confusing. Check the status line at the bottom of the terminal and use tmux ls when in doubt.
The session name is not a password or a health check. Anyone with sufficient access to the VPS may be able to inspect or attach to it. Protect your SSH account and stream key, and avoid posting terminal screenshots that expose either one.
Run the verified FFmpeg command
There is no single FFmpeg command that fits every input, FFmpeg build and YouTube ingest mode. The correct command depends on whether you are looping a file, forwarding another source, encoding on the VPS, copying already suitable streams, or using a protocol selected by YouTube.
Paste the command that you have already tested, with the current ingest address and stream key supplied through the method you normally use. A deliberately incomplete example shows the placement without pretending to be a universal recipe:
ffmpeg [input options] -i /absolute/path/to/source [encoding and output options] \
-f flv "rtmp://your-current-youtube-ingest-url/your-stream-key"
Treat the URL above as a placeholder. Use the server URL and stream key currently shown for the specific broadcast in YouTube Live Control Room. The YouTube Live API documentation explains that a live stream has an ingestion address, while YouTube’s current encoder guidance should be checked for the particular setup.
Do not add HLS options to an RTMP command, or assume that an RTMP example describes HLS. YouTube’s HLS streaming guidance describes HTTPS delivery in segments rather than continuous RTMP delivery. It specifies requirements for segment format, segment duration, playlist behaviour and supported media formats. Those requirements apply when HLS is the selected ingest protocol, not as a general set of flags for every FFmpeg stream.
Watch the first part of the command’s output. Look for the input being opened, streams being mapped, the output being created and frames continuing to be processed. A command that returns immediately to the shell has not started a continuing FFmpeg process. A command that prints an error and waits for no input needs fixing before you detach.
For prerecorded material, decide what should happen at the end of the file. If the channel should repeat a video, the loop behaviour must be part of the tested command. If the stream should move through several files, use the playlist or concatenation method you have tested. tmux does not make a finite input infinite. The article on keeping a YouTube live stream running after the first video ends covers that separate media-flow problem.
Encoding settings also affect whether the VPS can keep up. Watch the reported processing speed and the host’s CPU usage during a test. If the source is being re-encoded, a VPS with insufficient capacity may fall behind even though the command is still running. If you are choosing settings for a modest machine, use the encoder settings checklist for YouTube Live and then test those settings with your actual input.
Keep the stream key out of shell history where practical. At minimum, do not include it in notes, screenshots or support messages. If the key has been exposed, rotate it through YouTube rather than assuming that tmux changes its visibility.
Detach safely from the session
When FFmpeg is running and you have confirmed that the output is progressing, detach from tmux with this two-key sequence:
- Press
Ctrl-b. - Release both keys, then press
d.
Ctrl-b is tmux’s default command prefix. The d tells tmux to detach the current client. You should return to the ordinary VPS shell, and a message should indicate that the session was detached. The FFmpeg command remains in the tmux pane.
Do not press Ctrl-c first. In the FFmpeg pane, Ctrl-c normally sends an interrupt to the foreground process and may stop the stream. Detaching is different from stopping. If you are unsure which screen you are viewing, pause and check the bottom status line before using a control key.
After detaching, you can close the SSH connection:
exit
Closing the local terminal window is also reasonable after the SSH session has ended. The important sequence is that tmux was created on the VPS, FFmpeg was started inside it, and you detached rather than interrupting the process.
This protects against an SSH client disconnect, not every event between the VPS and YouTube. A local Wi-Fi failure does not necessarily affect the remote process, but a VPS network failure can affect FFmpeg’s output. Similarly, a YouTube-side rejection can occur while tmux remains perfectly healthy.
Reconnect and reattach later
When you want to inspect the stream, establish a new SSH connection:
ssh username@your-vps-address
List the available tmux sessions:
tmux ls
Then attach to the named session:
tmux attach -t youtube
The pane should show the existing terminal state. If FFmpeg is still running in the foreground, you will see its current output rather than a fresh command. This is useful for checking whether frames are advancing, whether FFmpeg is reporting connection errors, and whether the command has returned to the shell.
If tmux reports that the session does not exist, do not immediately create a new session and start a second stream. First consider whether the VPS rebooted, whether the session was deliberately terminated, whether you used a different session name, or whether FFmpeg and tmux were started under another user. A second process can create two broadcasts or two competing connections using the same key.
If another client is attached, tmux may show the session as attached. You can attach normally and decide whether both views are needed, or use a deliberately chosen detach-and-attach command only when you understand who is connected. Avoid terminating another operator’s session without checking.
To leave the session running after your inspection, use Ctrl-b, then d again. If you need to stop FFmpeg deliberately, return to its pane and press Ctrl-c, wait for it to exit, and then leave or close the tmux session as appropriate.
Inspect the process and logs
A visible tmux pane is helpful, but it is not a complete health check. Reattaching tells you what the process is printing; it does not confirm that YouTube is receiving a valid, viewable broadcast. Check YouTube Live Control Room separately for the current stream state and warnings.
From another VPS shell, or after detaching from the pane, inspect the process list:
pgrep -a ffmpeg
ps -ef | grep '[f]fmpeg'
The first command is less noisy. The second can show the full command line on systems where the output is available. Confirm that the process belongs to the intended user and command. If nothing is returned, FFmpeg is not running under that account, or it has exited.
You can also inspect resource use with tools available on the distribution:
top
Look for sustained CPU pressure, memory problems and a process that is no longer making progress. A running process is not automatically a healthy process. It may be waiting on an input, repeatedly reporting an output error, or processing too slowly for the intended stream.
If you redirected output to a log file, inspect the end of it:
tail -n 100 /path/to/ffmpeg.log
If you did not create a separate log, the tmux pane may contain the most useful output. You can also use tmux’s scrollback to review recent messages. The exact log location and verbosity depend on how the command was started, so decide this before moving from a manual test to unattended operation.
Keep an eye on the input and output directions separately. FFmpeg’s protocol documentation lists options including reconnect, reconnect_at_eof, reconnect_on_network_error, reconnect_on_http_error, reconnect_streamed, reconnect_delay_max, reconnect_max_retries and reconnect_delay_total_max. The FFmpeg protocol documentation explains their scope, but the relevant option depends on the protocol and direction.
Those options may help with specified input-side interruptions. They do not restore a process that has already exited, and they do not guarantee recovery from every output-side RTMP failure. Add them only after checking the protocol documentation and testing the behaviour with your actual source.
What to do if FFmpeg exits
If you reattach and find a shell prompt instead of FFmpeg output, the process has probably exited. Read the final error carefully before restarting. Common categories include an unavailable input file, a permissions problem, an invalid option, a failed connection, a rejected key, a media-format mismatch or a resource problem on the VPS.
Correct the underlying issue first. If the input path is wrong, fix the path. If the stream key or ingest address is outdated, obtain the current details from YouTube. If the command is too demanding for the VPS, change the tested encoding approach or choose a host with suitable capacity. Restarting the same failing command only replaces one error message with another.
You can restart a corrected command in the existing session:
tmux attach -t youtube
# run the corrected FFmpeg command here
If the old session has ended, create a new one with the same or a clearer name:
tmux new -s youtube
Do not describe this as automatic recovery. You performed the diagnosis and restart manually.
For a process that must restart after an exit, use a deliberately configured service manager such as systemd rather than assuming tmux provides supervision. The systemd service manual documents service lifecycle and restart settings. A service unit can also be enabled for boot-time startup, but you must configure and verify its command, user, working directory, environment, permissions and restart policy on the target VPS.
A service manager and tmux are not mutually exclusive. systemd can run FFmpeg independently of an SSH terminal, while tmux remains useful for administrative commands or a one-off investigation. Decide whether you need an interactive session or an unattended service, and do not confuse the presence of both with proof that the stream is healthy.
The failure modes are easier to reason about when kept separate:
| Failure | Does tmux address it? | Next check |
|---|---|---|
| Your SSH connection drops | Usually, while the remote tmux server remains active | Reconnect and attach to the named session |
| FFmpeg exits | No automatic restart from tmux | Read the final error, fix it and restart, or configure supervision |
| The VPS reboots or shuts down | No | Check the host and configure verified boot-time service startup |
| The input network fails | Not by itself | Use protocol-appropriate FFmpeg options and test their limits |
| YouTube rejects the ingest | No | Check the current Live Control Room settings and official guidance |
This is why a nightly test should include more than an SSH disconnect. Confirm that the source loops as intended, the VPS has enough capacity, the command survives your planned detachment, and you know how to find the final error if it exits.
Choose the right operating method
For a first manual setup, tmux is a practical way to keep an FFmpeg session running while you close your SSH client. It is especially useful when you are still tuning a command, watching output, or making occasional changes to a small channel.
It becomes less suitable as the only control layer when the channel must recover without a person. A systemd unit can be configured for restart behaviour and boot-time startup, while FFmpeg’s protocol options can address only the documented interruption cases for the relevant protocol. These layers have different jobs.
| Approach | Survives SSH disconnect | Restarts FFmpeg after exit | Starts after VPS reboot | Best fit |
|---|---|---|---|---|
| tmux session | Yes, while the remote tmux server remains active | No, not by itself | No, not by itself | Interactive operation and inspection |
| systemd service | Yes, because it runs independently of an attached SSH terminal | Can be configured according to the unit policy | Can be enabled and tested for boot startup | Unattended operation |
| FFmpeg reconnect options | Not a terminal-session feature | May recover specified protocol interruptions | No | Protocol-level recovery attempts |
Before choosing a VPS, compare the access method, CPU and network capacity for your chosen encode, storage for the source files, restart controls and support. A VPS gives you control, but it also leaves you responsible for the command, operating system and recovery design. The VPS versus cloud streaming comparison for a 24/7 lecture channel can help you assess that trade-off.
If you do not want to administer SSH, tmux, FFmpeg and service policies, a managed workflow may remove the terminal work rather than improve the same VPS setup. StreamNeo removes the need to keep this interactive session open by taking an uploaded video and running the YouTube broadcast remotely after you supply the stream key. It is a different operating model, so check that YouTube-only delivery and your source workflow meet your needs.
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
Does tmux keep my YouTube stream running after I close SSH?
It keeps the remote terminal session available after an SSH disconnection, provided the VPS and tmux server remain active. It does not confirm that FFmpeg is still running correctly or that YouTube is accepting the media.
Can tmux restart FFmpeg if it crashes?
No. tmux preserves the session and leaves the pane available for inspection, but it is not a process supervisor. Diagnose the error and restart manually, or configure a tested systemd service when automatic recovery is required.
Should I start tmux on my computer or on the VPS?
Start it after you have SSHed into the VPS. The FFmpeg command must also be started inside that remote tmux session, otherwise disconnecting from SSH will not protect the process you intended to run.
Is an FFmpeg reconnect option enough for a 24/7 stream?
Not necessarily. Reconnect options apply to particular protocols and interruption conditions, and they do not relaunch an exited process or fix invalid YouTube settings. Check the installed FFmpeg documentation, the selected YouTube ingest protocol and the Live Control Room state.