To run a YouTube 24/7 stream from an Ubuntu Azure VM, provision the VM first, then install FFmpeg, prepare media and send it to the current ingest address shown in YouTube Live Control Room. Run FFmpeg under systemd and watch both its logs and YouTube’s stream-health indicator; a restart can recover from some process exits, but it cannot fix every network, VM or YouTube-side failure.
This guide keeps those jobs separate: Azure provides a remote machine, while FFmpeg reads media stored on that machine and encodes or passes it to YouTube. Start with a short test before leaving anything unattended, and treat the stream key like a password.
Plan the VM and media workflow
The basic path is local media on the VM → FFmpeg → YouTube Live ingest. You upload or copy your video files to the VM, select the stream’s current destination in Live Control Room, and run FFmpeg so the file is read at playback speed rather than sent as fast as storage can provide it. For a single file, FFmpeg can loop the input; for a rotation, you can prepare a playlist and confirm its behaviour with your installed version.
The phrase “local media” means local to the VM, not necessarily to your home computer. Once the files are on the VM, your laptop can be switched off without interrupting the encoder process. You still need a way to transfer and maintain the files, and you should check that the VM’s disk has room for the media you intend to keep there. If your source is currently in cloud storage, this is distinct from asking YouTube to read it directly: FFmpeg needs a readable input path. The explanation of using Google Drive files for a YouTube podcast live stream may help clarify that difference.
Choose a VM based on the work FFmpeg must do, not on the assumption that every stream needs the same machine. If you are re-encoding video with a CPU-based encoder, the selected resolution, frame rate and codec affect the processing load. If you can use a compatible input without re-encoding, the load profile may be different. This guide does not establish a universal Azure size, region or price; check Microsoft’s current portal and pricing tools for your intended region and configuration before provisioning.
Also check that the VM can make outbound connections to YouTube’s ingest endpoint. A public inbound port is not needed simply to push a live stream. Avoid opening management access more broadly than necessary, and decide how you will securely administer the machine and transfer files before you create it. An Azure VM is cloud infrastructure for the workflow; it does not imply that you need a separate physical encoder.
Provision and access the Ubuntu VM
Create a Linux virtual machine in Azure using Microsoft’s Linux VM quickstart. Select an Ubuntu image and a region that suit your needs, then choose a size according to the encoding work you expect. Microsoft’s quickstart walks through creating and connecting to a VM, but the right operational settings depend on your account, region and use case.
Use the access method you have arranged for administration, such as SSH, and keep administrative credentials private. Before installing the encoder, confirm that you can connect, that the VM has outbound network access, and that the disk where media will live is mounted and writable by the account you plan to use. If you will run FFmpeg as a dedicated service user later, plan the file ownership and permissions so that account can read the media without giving it broad write access to the system.
Copy a small sample file to the VM and check that it is intact before moving a large collection. Consider how you will replace files without disrupting the active input: changing or deleting a file while FFmpeg is reading it can cause an input error. Keep source media in a clearly named directory and keep service configuration separate from the media. For a broader look at another cloud-hosted route, compare the workflow with running a 24/7 stream on a Google Cloud VM; the platform-specific provisioning steps are not interchangeable.
Install FFmpeg and prepare the media
Install FFmpeg from a trusted package source suitable for your Ubuntu release, then inspect the installed build before designing the command around particular protocols or codecs. The available features depend on how the package was built. In particular, an rtmps:// destination does not by itself prove that your local FFmpeg build can connect using RTMPS. FFmpeg’s protocol documentation covers RTMP variants and notes build-dependent support.
Check what the file contains and whether it decodes before attempting a long run. Confirm that it has the expected video and audio streams, that playback has the intended duration and that audio is present. Use media you have permission to stream, and review YouTube’s current guidance and policies for your content. If you are moving from a desktop encoder, the diagnostic thinking in this guide to fixing missing audio from prerecorded video in Streamlabs Desktop is relevant: first establish whether the source itself has the audio you expect.
For a single file, the general FFmpeg pattern uses real-time input with looping, then sends output in a format YouTube accepts. The following is a shape to adapt, not a universal tested command:
ffmpeg -re -stream_loop -1 -i /path/to/video.mp4 \
-c:v libx264 -c:a aac -f flv "$INGEST_URL"
Do not treat the codec choices here as a guaranteed fit for your source or account. Confirm that your FFmpeg build includes the chosen encoders and that the output settings suit the media and YouTube’s current encoder guidance. A file that already has suitable streams may call for a different approach; re-encoding can use more CPU and can introduce quality changes. Test a finite session in the foreground and observe both the local output and YouTube’s health report before turning it into a service.
For several files, use a playlist workflow rather than repeatedly editing a command while it is live. Playlist syntax and options vary with FFmpeg version and use case, so validate the list with the installed version and test that it advances in the order you intend. If the channel is meant to play episodes in sequence, the guide on making a YouTube podcast stream play episodes in order addresses the editorial side of that rotation. Keep a known-good test file available so you can distinguish a bad playlist entry from a network or ingest problem.
Get the YouTube destination and protect the key
In YouTube Live Control Room, open or schedule the stream and retrieve the current server URL and stream key for that stream. YouTube’s RTMPS guidance explains that RTMPS is the secure extension to RTMP and directs you to use the URL supplied in Live Control Room. Do not copy a sample destination from an old tutorial and assume it is still the right one for your stream.
Some encoder interfaces accept a server URL and stream key in separate fields. FFmpeg commands commonly pass a destination as one URL, so you must follow the format required by the current YouTube settings and your encoder workflow. The Google/YouTube Live Streaming API documentation exposes ingestion addresses and a stream name as separate configuration values. Use the actual values issued for your stream, and do not publish them in documentation, screenshots, shell history or support messages.
Treat the key as a credential. Do not paste a real key into an example command, commit it to source control, or place it in a world-readable script or service file. A shell variable can keep a value out of the command text, but it is not, on its own, a complete secret-management plan: interactive shell history, process environments and permissions still matter. For a durable service, restrict access to the configuration that provides the destination and key, and ensure logs do not print the full URL if it includes a secret. Use a dedicated account and narrow file permissions.
If you suspect exposure, replace or rotate the stream key from Live Control Room and update the service’s protected configuration. The current YouTube interface is authoritative for the stream’s destination. If RTMPS reports an SSL or connection issue, verify the exact protocol and server address first; YouTube’s Help guidance says to investigate port 443 if an SSL error persists. That is a troubleshooting step, not proof that every connection problem is a port issue.
Run FFmpeg and inspect its logs
Before creating a system service, run a short test in a foreground session. This makes command errors visible and lets you check that the input opens, FFmpeg advances through the file and YouTube receives a signal. Store the destination securely rather than typing a real key into a command that may be retained in shell history. Do not leave a terminal session as your only operations plan: disconnects, shell exits and machine restarts are different from process supervision.
Read FFmpeg’s output for input errors, missing streams, unsupported codecs, connection failures and repeated reconnect messages. A process that has not exited may still be stuck, sending unusable data or unable to reach the ingest service. Conversely, an FFmpeg error can come from a damaged media file or permission problem rather than YouTube. Record the time and the exact symptom, but redact any destination details that could expose the key before sharing logs.
A foreground test should be short enough to diagnose, but long enough to confirm that the video and audio reach the intended stream. Watch the preview and stream-health information in YouTube Studio, not only the terminal. If the preview is black, has no sound or reports a configuration issue, first establish whether FFmpeg is reading the expected streams and whether its output parameters match the source. Change one thing at a time and test again rather than changing the VM, command and YouTube settings together.
Supervise the process with systemd
Once the foreground test works, run FFmpeg as a systemd service under a dedicated unprivileged user. A service can start the process at boot, keep it separate from an interactive login and apply a restart policy when the process exits unsuccessfully. Give the user read access to its media and protected configuration, but avoid granting it unrelated administrative rights. Keep unit files and secret-bearing files readable only by the accounts that need them.
The service should call a maintained script or a carefully formed command, with paths that do not depend on your interactive shell’s working directory. If the destination is read from a protected environment file, lock down that file’s ownership and permissions and do not print its contents during troubleshooting. Confirm systemd can read the media and configuration as the service user; a command that works in your own shell may fail under the service account because it has a different home directory, environment or file access.
Configure restart-on-failure behaviour deliberately, then reload systemd, enable the service if you want it to start at boot and start it for the first supervised test. A restart policy can bring FFmpeg back after a process exit, but it does not diagnose a malformed input, repair a missing file, restore a failed VM or force a remote ingest endpoint to accept the stream. A process may also remain alive while its connection is unhealthy, so a restart policy alone is not a complete monitor.
Use systemctl status to inspect the service state and journalctl -u your-service-name to review its logs. Add a time range when reviewing a particular incident, and check the same period in YouTube Studio. Keep operational notes on the symptom, the change made and the result. Do not copy unredacted logs into a public forum. The important distinction is between process supervision, which reacts to certain process states, and end-to-end observation, which asks whether YouTube is actually receiving usable media.
Check YouTube health and test recovery
In Live Control Room, confirm the stream becomes active and inspect the stream-health panel and any configuration issues it reports. YouTube’s API documentation distinguishes stream status from health information, including active or inactive states and health values such as good, ok, bad and noData. Those are useful signals, but they do not replace checking the actual preview and sound. A running systemd service is not evidence by itself that viewers are receiving a healthy stream.
Test recovery before relying on the setup unattended. First, confirm that a deliberate FFmpeg process exit is handled as expected by systemd and that the service log records the restart. Then test a safe input or configuration failure in a controlled way, rather than disrupting a public stream, and confirm that you can recognise the resulting symptom. Avoid inventing a fixed restart schedule based on someone else’s anecdote: the right response depends on whether the fault is a process exit, a bad media file, an unavailable route, a VM problem or a YouTube-side issue.
When a failure occurs, compare three views: systemd state, FFmpeg’s recent log lines and YouTube’s stream-health report. If systemd says the service is active but YouTube reports no data, investigate the connection and ingest path rather than assuming that restarting repeatedly will solve it. If FFmpeg exits on an input error, check the file path, permissions and playlist. If the VM itself is unavailable, a process restart cannot help until the host is reachable again.
Treat network, host and platform failures as separate operational risks. The stream may be interrupted by a route or connection issue, a VM outage, an ingest problem or a change in the source or configuration. Supervision reduces the manual work of recovering from some process failures; it cannot promise uninterrupted service or recover every upstream fault. Keep a way to reach the machine, retrieve logs and confirm the stream in YouTube Studio, and decide how you will handle a prolonged interruption.
For channel planning, also review the current YouTube guidance on whether 24/7 looped streaming is allowed. Policies and account requirements can change, so check the official page rather than treating a setup tutorial as an approval guarantee.
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 FFmpeg on Ubuntu always support YouTube RTMPS?
No. RTMPS support can depend on how the FFmpeg package was built, so inspect the installed build and test the exact current URL from Live Control Room. An rtmps:// destination in a command does not establish that the protocol is available in your installation.
Does systemd make a YouTube stream uninterrupted?
No. systemd can start the service and restart a process after certain failures, but it cannot repair every media, network, VM or YouTube ingest problem. Check both service logs and YouTube’s stream health.
Do I need an inbound streaming port open on Azure?
Not just to send a stream from the VM to YouTube. The encoder makes an outbound connection to YouTube’s ingest endpoint; secure administrative access separately and avoid opening unnecessary inbound access.
Where should I get the stream key?
Retrieve the current stream key and ingest URL from YouTube Live Control Room for the stream you are configuring. Keep the key private, protect any file or environment that contains it, and replace it if it is exposed.