To run a 24/7 YouTube live stream on an Azure virtual machine, put an encoder on a Linux VM and send its output to YouTube Live over RTMPS. YouTube receives the broadcast; Azure supplies a computer that can keep the encoder running while your own computer is off.
Here, “24/7” means the schedule you intend to operate, not a promise that the VM, connection, encoder or YouTube ingest will never fail. Eligibility, bandwidth, stream-key security, monitoring and recurring charges all need attention before you leave a channel unattended.
Check the channel before preparing the VM
Start in YouTube, not Azure. A channel must be verified and have no live-streaming restrictions during the preceding 90 days to be eligible to stream, according to YouTube’s live-streaming eligibility guidance. If this is your first time enabling live streaming, activation can take up to 24 hours. Enable it well before your planned launch and confirm that the channel can actually create a live event.
Once live access is available, open YouTube Studio’s Live Control Room and create or schedule a stream. YouTube provides a stream URL and a stream key for the encoder to use. Treat the key like a password: anyone who obtains it may be able to send a broadcast to your channel. Do not put it in a public script repository, a screenshot, a support forum post or a document shared more widely than necessary.
You can use a private or unlisted event for a setup test, then schedule the public event when the channel, source and operator are ready. A successful test confirms more than account eligibility: it can reveal a wrong key, an unsuitable output setting or audio that is difficult to hear. If you are learning how the key fits into encoder setup, this guide to adding a YouTube stream key to Castr explains the general role of the key, though the VM encoder’s controls may differ.
Also decide how you will handle the event itself. A continuously intended channel is not necessarily one unbroken YouTube event or one complete archive. YouTube says streams under 12 hours are automatically archived; do not assume an indefinite broadcast will become a single, complete recording. Plan event boundaries and any separate recording process deliberately, and check YouTube’s current event and archive guidance before relying on a recording.
Know which job belongs to which system
The basic path is source media or a live input, then an encoder on the Azure VM, then YouTube Live. The source might be a playlist of devotional songs, an ambience video or a camera feed. The encoder packages picture and sound into a stream and sends it to YouTube using the endpoint and key from Live Control Room. Viewers watch YouTube’s delivery of that stream, not the VM directly.
This distinction matters when troubleshooting. A VM can be running while the encoder has stopped; an encoder can be sending data while the source has reached its end; and a healthy source can still fail to reach YouTube if the key or connection is wrong. YouTube’s ingest health and preview provide another signal, but they do not replace checking the VM process and the material being played.
Azure does not create the programme or decide when one track follows another. You must choose and configure an encoder, supply media that you have the right to use, and make the source behave as intended. For a playlist, determine whether it should repeat, what should happen at end-of-file and whether transitions or gaps are acceptable. For a live camera or audio input, plan for what the encoder should do if that input disappears.
If the stream uses music, video or other material you did not create, check the relevant permissions before broadcasting. A cloud VM does not change the rights associated with your source. The practical distinctions between owning a recording, having permission to stream it and receiving a platform claim are discussed in this guide to live-stream copyright.
Choose capacity for the actual workload
Choose an Azure VM around the encoder workload and sustained outbound traffic, rather than selecting a size based on a vague rule that any cloud machine can stream. A simple, static video loop has different processing needs from a live camera, several layered scenes or a higher-resolution programme. If encoding is computationally intensive, compare the encoder’s requirements with the VM’s available CPU or supported hardware acceleration. Do not assume acceleration is available or useful without confirming the selected VM and encoder support it.
Network capacity is just as important. Azure publishes expected bandwidth by VM size, and outbound traffic from attached network interfaces counts against the VM’s allocated bandwidth. Your output bitrate is not the only traffic to account for: protocol overhead and any other traffic need room too. Consult the current Azure VM bandwidth specifications for the size and region you are considering, then leave headroom rather than running at the edge of the published capacity.
| Workload consideration | What to check | Why it matters |
|---|---|---|
| Static loop or playlist | Encoder CPU use and the chosen output resolution | A simple source may be easier to encode than complex scenes, but test the actual file and settings. |
| Live camera or layered scenes | CPU or supported acceleration under sustained encoding | The workload can change when scenes, filters or inputs change. |
| Outbound stream | VM’s published network bandwidth and other traffic | The encoded feed must reach YouTube continuously, with capacity for overhead. |
| Source and archive plan | Disk space, source location and any separate recording needs | Media availability and recording storage are different from sending the live feed. |
The right output resolution and bitrate also depend on the source and the connection. YouTube’s encoder settings and bitrate guidance gives recommendations by output quality; use the applicable table rather than treating one bitrate as universal. If you are considering other small-computer or VPS approaches, the workload trade-offs in the Raspberry Pi 4 playlist guide can help frame the decision, but verify Azure’s own specifications for the VM you deploy.
Create and secure the Azure VM
In Azure, select a region and Linux image, then create a VM with the network and disk configuration the workload needs. Microsoft’s Linux VM quickstart documents the portal-based deployment pattern. The exact screen labels and available sizes can change, so use the current Azure portal and documentation rather than copying an old walkthrough blindly.
Use SSH key authentication for administration and restrict who can reach SSH. Azure’s Linux VM connection guidance describes connecting to a Linux VM. A network security group controls network traffic; allow the administrative access you need, scoped as narrowly as practical. Since the encoder sends its stream outward to YouTube, you generally do not need to expose an inbound media-ingest port on the VM for this workflow. Avoid opening ports simply because an unrelated streaming tutorial lists them.
Think about public IP configuration as part of the management and network design, not as a box that must always be enabled. Azure notes that public IP addresses support inbound communication and predictable outbound connectivity, and fees may apply; check Azure’s public IP documentation and the current cost estimate for your case. If you do assign one, keep administrative access restricted. If your design uses a different egress arrangement, confirm that it supports the outbound connection the encoder needs.
Install your chosen encoder using instructions appropriate to the selected Linux distribution and the encoder’s maintained documentation. This guide does not provide an installation command or claim a tested deployment: package names, supported codecs and configuration options depend on the software and operating system versions. Before you expose a channel key to the process, make sure the configuration file or environment in which you store it is readable only by the intended account, and know how you will replace the key if it is exposed.
Set up the encoder and YouTube ingest
In the encoder, select YouTube’s RTMPS ingest URL from Live Control Room and supply the matching stream key. RTMPS is RTMP carried over TLS/SSL, which encrypts the connection between the encoder and ingest. YouTube explains how to find the URL and key in its stream setup instructions. Do not substitute a guessed endpoint or send the key to a third-party tool unless you understand how that tool handles credentials.
Choose video and audio settings that the source, VM and available egress can sustain. YouTube’s current encoder guidance lists H.264, H.265/HEVC and AV1 video, and AAC or MP3 audio. It recommends constant bitrate (CBR) and keyframes every two seconds, with intervals no longer than four seconds. These are platform recommendations, not proof that a particular VM can encode a given format at a particular resolution. Match the chosen profile to YouTube’s quality guidance and test it with the real source.
Set audio deliberately as well as video. A devotional stream with a still image can appear visually stable while the music is silent, distorted or repeatedly interrupted. Listen to the preview on a device and connection similar to those your audience might use. For a camera feed, check that motion remains clear and that the audio stays in sync. Keep a record of the output settings and the source version used in your test, so you can distinguish a change in the media from a change in encoder configuration later.
A long-running process needs a plan for launch and recovery. A process supervisor or equivalent managed-process approach can be part of that plan, but the exact configuration depends on the encoder, Linux distribution and how the source is supplied. Do not assume that a process will reconnect properly after a network drop or repeat a playlist after end-of-file merely because it starts at boot. Validate those behaviours using the encoder’s own documentation and controlled tests before leaving the stream unattended.
Mentioning StreamNeo is relevant when this particular VM workflow is more administration than you want: StreamNeo takes an uploaded video and runs it as a YouTube live stream without leaving your own encoder computer on to manage a long-running process. It is YouTube-only, so a VM remains the path to consider when you specifically need to configure and operate your own cloud encoder.
Test health before depending on a schedule
Run a private or unlisted test using the material and settings you intend to broadcast. Watch the Live Control Room preview and health indicators, and check the audio and video yourself. YouTube recommends testing with representative content and monitoring stream health; its live control room and streaming help is a useful reference for the checks available there. Do not treat a preview appearing once as evidence that an overnight run will behave the same way.
Observe the VM while the test runs. Confirm that the encoder remains active, the source continues to produce output, and outbound traffic is consistent with the intended stream. Look for resource pressure or a process that exits without an obvious on-screen warning. Keep access to the VM and Live Control Room available so you can identify which side has stopped sending or receiving data. Record what normal operation looks like for your specific workload; that gives you something concrete to compare against when a later alert appears.
Deliberately exercise likely failure cases while an operator can intervene. Interrupt the network, restart the VM, use a test key that has been changed or revoked, and let a test source reach end-of-file. Check whether the encoder stops, reconnects, resumes the source or requires a person to act. This is not a claim that the system will fail in any particular way; it is a way to discover what your chosen combination actually does. Do not use an unverified reconnect command or service configuration as a substitute for this testing.
Monitoring needs a response plan, not just a dashboard. Decide who will notice a stopped process, where they can check the encoder and YouTube status, and how they will restart or replace the source safely. If the channel is used for a shop promotion, local information or a scheduled devotional programme, a blank or stale broadcast may matter even if the VM itself is still running. For a channel built around a repeatable playlist, this guide to a scheduled-track lo-fi station raises similar operational questions about source continuity and programming.
Budget for continuous use and plan for interruption
A 24/7 schedule means the selected Azure resources are in use continuously, even when few people are watching. Estimate compute, OS and data disks, any public IP, and outbound data transfer for the region and configuration you actually intend to deploy. Use the Azure pricing calculator or a current estimate in the Azure portal; prices vary by region and choices, so a fixed monthly figure would not be meaningful without those inputs. Check the estimate again if you change the VM size, region, storage or egress design.
Separate recurring resource charges from setup effort. A smaller VM may reduce compute expense but leave less capacity for encoding or network headroom; a larger choice may be unnecessary for a simple source and still does not prevent a source or ingest failure. Compare the expected workload with the published specifications, then test the selected configuration instead of paying for capacity based on an unverified assumption. For another view of the cost categories around always-on YouTube use, see the 24/7 store-promo stream cost guide.
Write down the likely failure points and the first check for each. If the preview disappears, check whether YouTube is receiving data and whether the encoder is still running. If the encoder is active but the picture is frozen, inspect the source and its end-of-file behaviour. If the VM has restarted, verify whether the encoder launched and whether it still has valid credentials. A changed stream key, a VM interruption, a network problem, depleted disk or an exhausted source can each call for a different response.
Finally, decide what viewers should see during recovery. You might schedule a replacement event, prepare a holding image or have an operator ready to intervene, depending on the channel’s purpose. That is an editorial and operational choice, not something Azure or YouTube can decide for you. Make the event and archive plan explicit too: a continuously intended channel may need repeated event handling or separate recordings, and streams lasting 12 hours or more are outside the automatic-archive condition described by YouTube.
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
Can I run a YouTube stream when my own computer is off?
Yes, if the encoder and source run on the Azure VM rather than on your personal computer. The VM must remain provisioned and able to send the feed, and you still need a way to monitor and respond if the process stops.
How early should I enable YouTube Live?
Enable it before the planned launch because first-time activation may take up to 24 hours. You also need an eligible, verified channel without a live-streaming restriction in the preceding 90 days, according to YouTube’s current guidance.
Does a 24/7 stream become one archived video?
Do not assume that it does. YouTube’s automatic archive guidance applies to streams under 12 hours, so an indefinite schedule needs a deliberate event-boundary and recording plan.
Which Azure VM size should I use?
There is no single size that fits every source, encoder setting and region. Check the VM’s published outbound bandwidth and compute capabilities against the stream you plan to encode, estimate the costs in Azure, and test the selected setup with representative material.