To run a file-based YouTube Live stream from a Linux VPS, install FFmpeg and tmux, copy the stream URL and key from YouTube Studio, then start FFmpeg inside a named tmux session. You can detach from that session and reconnect over SSH later to inspect it; tmux keeps the session available, but it does not restart FFmpeg if the process exits.
The reliable part is not just getting the command to run. You also need to protect the stream key, choose a bitrate the VPS can sustain continuously, and test the whole path before relying on it overnight. The commands below use a video file and a Linux shell; package names and FFmpeg features can differ by distribution and build.
Prepare the VPS and install the tools
Connect to your VPS over SSH using the account that will own the stream files and run FFmpeg. Installing software may require administrative privileges, but keep the actual streaming process under a normal user where practical. That makes file permissions and access to the tmux session easier to reason about.
Install FFmpeg and tmux with your distribution’s package manager. For example, on Debian or Ubuntu, the package names are usually ffmpeg and tmux; use the package manager’s normal update and install process for that system. Do not assume those exact commands apply to every Linux release. On another distribution, check its documentation and package names first.
After installation, check that the programs are present:
ffmpeg -version
tmux -V
The version output confirms what is installed, but it does not prove that every protocol or codec you want is available. In particular, if you intend to send to YouTube over RTMPS, check the FFmpeg build’s protocol support, for example with ffmpeg -protocols, and look for the relevant RTMPS support. FFmpeg’s protocol documentation describes supported protocols and options. Builds assembled by different distributions or providers can vary, so test the actual executable on your VPS rather than relying on a command copied from elsewhere.
Put the input video in a stable location, such as a directory under your home folder, and confirm the account can read it. Avoid paths under temporary directories that might be cleaned, and avoid renaming or replacing the file while FFmpeg is using it. Check available disk space as well if you plan to keep several large source files on the VPS. You do not need to upload a file to YouTube first: FFmpeg reads the local file and sends the live output to YouTube’s ingest endpoint.
A VPS plan is not suitable just because it is labelled for streaming. Compare sustained outbound capacity, CPU if you will encode video, storage, region, and the provider’s own availability and restart features. For a broader discussion of what to compare for a radio stream, see the VPS selection considerations for an internet radio station. No universal VPS size guarantees a given stream quality.
Get the YouTube Live URL and stream key
In YouTube Studio, open the Live Control Room and create or select the stream you intend to use. YouTube’s encoder setup guidance explains the stream URL and stream key fields used to connect an encoder. Copy the endpoint and key for the selected stream, and confirm whether YouTube is showing an RTMP or RTMPS endpoint.
Prefer RTMPS when YouTube provides it and your FFmpeg build supports it. YouTube describes RTMPS as RTMP sent over a TLS/SSL connection in its RTMPS guidance. The address is not interchangeable with an arbitrary example endpoint: use the exact URL and format shown for your stream, then append or enter the key in the way that endpoint expects.
Treat the key like a password. Anyone who obtains it may be able to send a broadcast to your stream, so do not paste a real key into a public issue, screenshot, shared document or blog example. YouTube documents resetting a compromised stream key; if you think one has been exposed, replace it in Studio rather than merely deleting the text from a terminal window.
There is a practical shell-history risk when a secret appears directly in a command. Depending on your shell and how you connect, commands may be saved in history or visible to other users with access to process information. A private VPS account is not the same as a secret manager. Limit who can log in, avoid sharing the account, and decide how you will keep the endpoint and key private before launching. Do not use a real key in the template later in this article.
Choose a source and a sustainable quality
For a straightforward file-to-live workflow, start with a local video whose audio and picture have already been checked. Make sure it plays from beginning to end as expected and has the correct soundtrack. If you need a repeating programme rather than a single file, build and test that workflow separately; playlist handling, transitions and recovery add their own failure cases. The guide to running a pre-recorded video on an always-on YouTube channel covers the broader content-planning question.
YouTube’s encoder recommendations are useful targets, not a promise that your VPS can deliver them. Its current live encoder settings guide recommends, among other settings, CBR and a two-second keyframe interval, with a four-second maximum. For H.264, its listed examples include 10 Mbps for 1080p30 and 8 Mbps for 720p60. These are YouTube recommendations accessed in October 2026; check the current guide before configuring a production stream.
The important constraint for this setup is sustained upload capacity from the VPS to YouTube, not a brief speed-test peak. A path that briefly reaches a target but falls below it later may produce buffering or stream-health warnings. Measure the VPS’s outbound performance under realistic conditions, leave room for variation and overhead, and choose a lower resolution or bitrate if the connection cannot carry the target steadily. A guide to checking encoder settings when YouTube Live buffers on Airtel Broadband can help you think through bitrate and network symptoms, although a VPS network path is not the same as a home broadband connection.
| Configuration example | YouTube H.264 recommendation | What to verify on your VPS |
|---|---|---|
| 1080p at 30 fps | 10 Mbps | The sustained upload path must carry the stream continuously, with headroom for variation. |
| 720p at 60 fps | 8 Mbps | Verify the same way; a lower resolution does not remove the need to test the actual route. |
| A lower custom setting | No single figure given here | Select it from measured upload performance and the quality your audience needs. |
These figures are not capacity estimates for any VPS provider. If FFmpeg is encoding from a source into another format, the CPU must also be able to do that work continuously. If the file already has suitable codecs and you use stream copy, CPU demand may be different, but stream copy does not fix an inadequate upload path or an incompatible input. Start with an uncomplicated configuration, monitor it, and change one factor at a time so you can identify the cause if the stream degrades.
Start a named tmux session
A named session makes it easier to distinguish this stream from other shell work. Create one with:
tmux new -s ytstream
You are now inside a tmux session named ytstream. Run the FFmpeg command from this terminal so its output remains associated with the session. If you later manage multiple channels, use a descriptive name for each and check the name before attaching; a short name such as ytstream is fine for one stream, but a channel or purpose in the name can reduce mistakes on a busy server.
You can check sessions from a normal SSH shell with:
tmux ls
If you close SSH before starting FFmpeg, tmux will not have a streaming process to preserve. Likewise, creating a tmux session and then starting FFmpeg in a separate ordinary SSH terminal does not put that process into the session. Confirm that the FFmpeg output is visible in the tmux window before you detach.
The tmux manual documents session creation, detachment and attachment. Think of tmux as a way to leave a terminal session running and return to it, not as a service manager. The distinction matters most when something fails: tmux can show you that a command ended, but does not itself rerun the command.
Run the real-time FFmpeg command
FFmpeg documents a basic pattern for sending a file to an RTMP server: read the input in real time, then send FLV output to the server. In your tmux window, the command has this shape:
ffmpeg -re -i /path/to/video.mp4 -f flv 'rtmps://HOST/APP/STREAM_KEY'
This is a template, not a tested command for your VPS. Replace the file path with the path readable by your account and replace the endpoint with the exact RTMPS URL and key format provided in YouTube Live Control Room. Do not paste a real key into an article, support request or screenshot. Confirm the installed build supports the protocol before using the command, and check FFmpeg’s output for connection errors.
The -re option reads the file at its natural rate rather than sending it as quickly as the machine can process it. -i identifies the input. -f flv selects the container format used in the documented RTMP-style pattern. That does not mean every video file can be sent without adjustment: codecs, audio format, frame rate and YouTube’s ingest requirements still matter. FFmpeg can also be configured to encode, but adding codec options without knowing the source and CPU can make the process harder to troubleshoot.
The single-quoted destination in the example helps the shell treat the URL as one argument; it does not make the key private. If your key contains shell-significant characters, follow the shell’s quoting rules carefully. More importantly, remember that placing the URL and key on a command line may leave traces. For a one-off test on an account you control, understand that exposure before proceeding. For a longer-running setup, use a private, access-controlled way of supplying credentials appropriate to your environment, and test that method before the broadcast starts.
When FFmpeg connects, leave the output visible long enough to see whether it continues sending frames and audio. A command that prints a successful connection message once can still encounter a later network problem. Do not regard the command as proven simply because the first few seconds appear in YouTube’s preview.
Detach and reattach over SSH
Once FFmpeg is running inside the named session, detach from tmux with its default key sequence: press Ctrl-B, release it, then press D. This returns you to the SSH shell while leaving the tmux session available on the VPS. It is different from typing exit inside the window or terminating FFmpeg; those actions can close the shell or stop the streaming process.
You can now disconnect from SSH. Later, connect to the same VPS account and attach again with:
tmux attach -t ytstream
You should see the session and the terminal output that accumulated while you were away. If you have more than one matching session or are uncertain which one is active, list sessions first with tmux ls. Reattach to the intended one rather than starting another FFmpeg command against the same YouTube stream by mistake.
Detaching is useful for routine remote administration, not recovery. If the SSH client disconnects after a proper detach, the tmux session remains available. If FFmpeg exits inside that session, tmux may still be there to show the exit or shell prompt, but it will not restart FFmpeg. Nor can it protect the session from a VPS reboot, account termination or other event that stops processes on the machine. If you want automatic recovery, choose and test a separate process supervisor or restart policy that fits your input and FFmpeg command.
Test stream health and handle process exit
Before relying on a stream, test from the same VPS, with the same file, credentials method, endpoint and quality settings you expect to use. YouTube recommends testing with audio and movement similar to the real broadcast, then checking stream health. A static image or a brief connection test may not expose a problem that appears when audio plays, motion increases or the process runs for longer.
Watch FFmpeg’s terminal output while attached and check the Live Control Room preview and health indicators. Look for whether frames and audio are being sent consistently, whether the preview is playing, and whether YouTube reports a connection or bitrate issue. If the preview stalls, distinguish between an FFmpeg error, an upload-capacity problem, a credential or endpoint mistake, and an input file that has reached its end. Change one item at a time and test again rather than changing the bitrate, file, endpoint and encoding options together.
If the process exits, first inspect the output in tmux. An error may identify a missing file, unsupported protocol, rejected key or interrupted connection. If the session is detached, reattach to inspect it. If the session itself is no longer present, check whether the VPS rebooted or whether the account or machine stopped; tmux cannot preserve a session across a machine shutdown.
For a supervised restart, do not assume a generic loop is safe. A process that repeatedly reconnects may behave differently depending on FFmpeg version, input type and YouTube’s response, and a loop can conceal a persistent configuration error. Decide what should happen after failure, how often it should retry, and how you will notice that it is failing. Test the policy by deliberately stopping the process during a non-critical test, then confirm both that the intended recovery occurs and that you can still inspect logs.
YouTube states that streams under 12 hours are automatically archived after the encoder stops sending. That guidance does not establish the same archive outcome for streams longer than that, so if your programme is expected to run longer, monitor it and verify the archive behaviour rather than assuming one continuous recording. For an always-on channel, also plan who will notice a failure and what content viewers will see while you investigate. An apparently running tmux session is not a substitute for checking the stream itself.
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 FFmpeg running after I disconnect from SSH?
Start FFmpeg inside a tmux session, then detach using Ctrl-B followed by D. The session remains available on the VPS after you disconnect, and you can return with tmux attach -t ytstream. This only preserves access to the session; it does not restart FFmpeg if it exits.
How do I stream a video file to YouTube Live from a VPS?
Install FFmpeg, copy the correct stream URL and key from YouTube Live Control Room, and run an FFmpeg file-to-live command inside tmux. Use the endpoint format YouTube supplies, check that your FFmpeg build supports the chosen protocol, and test the resulting broadcast in YouTube’s preview and health display before depending on it.
Does tmux reconnect YouTube automatically if the stream drops?
No. tmux is a terminal session tool: it lets you detach and reattach, but it is not a process supervisor or automatic retry mechanism. If you need restarts, configure and test a separate supervisor or recovery policy, and make sure you can distinguish a real network interruption from a persistent error such as a bad key.
Which bitrate should I use on a VPS?
Use YouTube’s current encoder recommendations as a starting point, then confirm that the VPS can sustain the selected upload rate to YouTube. YouTube’s listed H.264 examples include 10 Mbps for 1080p30 and 8 Mbps for 720p60, but neither figure guarantees that a particular VPS or route can carry it continuously. Choose a lower setting if testing shows the path cannot hold the target.