A reliable 24/7 YouTube stream needs a publisher process that can read prerecorded media, send it to YouTube continuously, and recover when a connection or compute instance stops. On Google Cloud Run, do not design that publisher as one permanent HTTP request to a service: use a better-suited always-on workload as your starting point, then verify current regional availability, quotas and costs.
A Cloud Run service can still be useful for controls such as start, stop, status and configuration. Keep the media and stream state outside the running container, and treat the encoder as replaceable. That gives you a recovery plan instead of relying on one process staying alive forever.
Design for a continuous publisher
Separate the work into a control plane and a publishing workload. The control plane receives requests from you or a small dashboard; the publisher reads media, prepares the output and sends the live feed to YouTube. They have different lifetimes, so they should not be forced into one service request.
Cloud Run offers distinct resource types for different work: services respond to HTTP requests, jobs run tasks to completion, worker pools are intended for always-on background work, and instances can suit long-lived singleton workloads. Google’s Cloud Run resource comparison and product documentation describe the available execution choices; check the current definitions before deciding which one fits your deployment.
A typical flow is straightforward. Store the video files and playlist metadata in cloud storage. A continuously running publisher fetches or streams an asset, then encodes or remuxes it using FFmpeg or another suitable encoder. It publishes to the YouTube ingest address using the stream key associated with the live destination. A supervisor watches the encoder and records whether it is running, reconnecting or failing.
Keep desired state outside the process. For example, record whether the channel should be live and which playlist item is next. If a process is replaced during maintenance or after a crash, the replacement can consult that state and make a deliberate decision about where playback resumes. A container’s local filesystem should not be the only copy of either the media library or the playback position.
Why an open service request is fragile
A Cloud Run service is built around an HTTP request and response, not an endless broadcast session. Google documents a maximum service request timeout of 60 minutes; when the timeout is exceeded, the connection closes and the request receives a 504 response. A single request therefore cannot be the lifetime boundary for a 24/7 YouTube stream. Check the current request timeout documentation rather than building around assumptions about how long a client may remain connected.
A request that lasts a long time also ties stream continuity to request handling. Clients are not guaranteed to reconnect to the same instance after a connection ends. Even if you add retries, each new request may not have the previous process’s in-memory playlist position, encoder state or view of the desired running state. The resulting stream might restart, repeat an item or fail to resume cleanly.
Billing mode does not make an HTTP request permanent. Request-based billing allocates CPU while requests are being processed. Instance-based billing provides CPU over an instance’s lifecycle, but autoscaling and termination still matter. Minimum instances and shutdown handling can affect behaviour, but they are not a promise that one particular instance will publish forever. See Google’s Cloud Run billing guidance for the current mechanics.
There are still useful jobs for a service: accept an authenticated request to change the desired state, expose status, or update a playlist. Keep those short-lived operations separate from the publisher. If the control plane is temporarily unavailable, the active publisher should have enough external configuration to continue its intended work and report its condition when the control plane returns.
Choose an always-on workload as the starting point
For the publishing process, begin by evaluating Cloud Run worker pools or a long-lived singleton-capable instance. Google describes worker pools as supporting always-on background workloads and instances as suitable for long-lived singleton processes. These are starting points, not guarantees of availability or fit in every region. Confirm the current feature status, lifecycle behaviour and quotas for your chosen region before committing to either.
A Cloud Run job is usually a better fit for finite tasks: validate a file, generate a thumbnail, or transcode an asset and then exit. It is not the natural lifetime model for a publisher intended to keep sending a live feed. A service is valuable for request-driven control and status. This distinction matters more than whether all the components happen to be packaged as containers.
| Cloud Run choice | Possible role | Main issue to validate |
|---|---|---|
| Service | Start/stop, status or configuration API | A service request has a maximum timeout; do not use one request as the permanent broadcast session. |
| Job | File validation or finite media preparation | The task is expected to complete rather than remain an always-on publisher. |
| Worker pool | Continuous background publishing candidate | Verify feature availability, configuration, quota and lifecycle behaviour in the target region. |
| Singleton-capable instance | Long-lived publisher candidate | Plan for termination, replacement, state recovery and the current regional limits. |
You will still need an explicit ownership rule: which process is allowed to publish to the channel, and what should happen if it stops? If a replacement starts while the previous encoder is still connected, two publishers can compete for the same live destination. Use the platform’s current lifecycle and health signals, plus external desired state, to coordinate a clean handover rather than assuming deployments are instantaneous.
Keep prerecorded media and state outside the container
Put source videos in durable object storage and let the publisher read the selected item. For a single loop, the playlist can point back to the same asset after it finishes. For a rotation, store the order and any scheduling rules separately from the process so that a restart does not silently reset the channel to an unintended position.
Decide how the publisher handles a missing, corrupt or not-yet-uploaded file. It might skip to a known fallback asset, pause publishing and raise an alert, or retry a bounded number of times. The right response depends on the channel: a devotional station might prefer a known ambient fallback, while a news loop may need to stop rather than repeat an outdated bulletin. Do not let an unhandled storage error become an unexplained black screen.
Avoid treating one long object-storage download as the recovery plan. A transient network interruption can break a read, and a persistent YouTube upload connection can also be reset. Reopen the media or resume it according to the playback design, and reconnect the ingest output. Record which asset and playlist position were active so you can tell whether a recovery resumed or restarted.
If you are using FFmpeg, test the exact loop and input behaviour before deployment. A simple file loop and a playlist scheduler have different failure modes. The guide to looping a video with FFmpeg for YouTube Live is useful for understanding the single-file case, while avoiding a black screen when looping videos can help you investigate a common failure after a loop transition.
Publish to YouTube using a compatible output
First confirm that your channel can go live. YouTube’s live encoder setup guidance explains the encoder workflow and channel requirements. Create the live destination in YouTube Studio or Live Control Room, obtain its ingest URL and stream key, and check the preview before announcing the stream. Eligibility and interface details can change, so use YouTube’s current instructions for the channel you are configuring.
The stream key is a credential. Do not put it in a public image, source repository, command output or ordinary application logs. Store it with a secret-management mechanism and inject it into the publisher at runtime. Restrict who can read it and rotate it if it is exposed. Be careful with FFmpeg command-line logging, since a verbose command can accidentally reveal credentials.
YouTube accepts software encoders and documents supported ingest protocols and media settings. Its current recommended encoder settings include RTMP or RTMPS, supported video and audio codecs, constant bitrate guidance, frame-rate limits and keyframe recommendations. Prefer RTMPS where supported for encrypted transport. Match the chosen encoder’s protocol, codec, resolution, frame rate, audio and keyframe behaviour to the official guidance for your intended output.
Do not copy a bitrate from an unrelated profile. YouTube’s recommendation varies with codec, resolution and frame rate; choose the appropriate row in its current settings table. For example, the research notes identify 14 Mbps as YouTube’s recommended value for SDR 1080p30 H.264, with 5 Mbps listed as a minimum. Treat those as YouTube’s published guidance for that profile, not a guarantee that a particular Cloud Run deployment can encode or deliver it successfully. Confirm the input media and network path, then inspect the Live Control Room preview for picture and sound.
A stream can connect successfully and still have poor playback. Look for silent audio, a frozen frame, incorrect aspect ratio, clipped transitions or a frame rate that does not match the source. If your channel depends on a fixed output profile, test representative files, including the longest and most demanding clips, before you rely on a full playlist.
Supervise reconnects, playlist state and logs
Treat the encoder as a child process that can fail independently from its supervisor. The supervisor should detect an unexpected exit, decide whether retrying is appropriate, wait according to a bounded backoff policy, and then start a new encoder attempt. Avoid an aggressive endless restart loop that hides a bad stream key or malformed command; distinguish configuration errors from transient network failures and make persistent failures visible.
Cloud infrastructure updates or network events can reset outbound connections. Google’s Cloud Run troubleshooting guidance discusses connection and instance issues; design for recreating a connection rather than relying on one upload socket remaining healthy. A reconnect should reopen the YouTube ingest session and confirm that output is flowing again. Where the product’s lifecycle allows shutdown signals, handle them deliberately and persist any state needed for a replacement process.
Log events in a way that lets you answer practical questions: did the encoder start, which asset was selected, when did the ingest connection fail, how many retries have occurred, and when was output observed again? Avoid logging the stream key or other secrets. Alerts should focus on meaningful conditions such as repeated process exits, prolonged absence of output, or a playlist item that cannot be read.
Playlist state deserves its own design. Decide whether a restart should resume the current item, restart it from the beginning or move to the next item. Persist the choice and update it at a well-defined point, such as after a clip completes. If a channel schedules different material by time of day, use a clock-aware schedule and define what happens when the publisher returns late. The playlist rotation guide using PowerShell covers a different runtime, but its planning questions about ordering and rotation remain useful here.
Before a public launch, run the stream in advance and inspect the Live Control Room preview. YouTube recommends monitoring audio and video quality. Test a reconnect, a process restart and a missing asset deliberately, so you know what viewers will see and what your alerting will report. Deployment success only means the workload started; it does not prove the broadcast remains healthy overnight.
Verify regional availability, quotas and costs
Cloud Run capabilities, quotas and costs can vary by resource type, configuration and region. Before you settle on a design, check that the selected workload type is currently available in the intended region, review the applicable quotas, and confirm any limits that affect instance count, CPU, memory, networking or storage. Google’s product pages and console are the authority for your account and deployment region; do not assume a feature documented elsewhere is enabled for your case.
Estimate cost from the actual operating pattern. Include the publisher’s CPU and memory for the time it is active, object storage, requests to retrieve media, and network egress for the continuous upload. Add any control-plane or media-preparation work separately. A 24/7 workload has a different cost shape from a job that runs briefly, and the result depends on region, resource sizing and how the media is delivered. Use Google’s current pricing calculator and pricing pages with your assumptions; do not rely on a monthly figure from another region or deployment.
Also estimate the cost of recovery, not just steady state. More aggressive encoding may require more CPU, while a design that repeatedly downloads large files can add transfer and storage activity. A playlist that uses a pre-encoded compatible file may reduce work compared with re-encoding, but only if the output is appropriate for YouTube and the source does not need transformations. Test resource use with representative media rather than selecting a configuration by guesswork.
Keep a short deployment checklist: target region confirmed, workload type available, quota reviewed, CPU and memory measured, stream key stored as a secret, reconnect behaviour tested, and monthly estimate checked against current prices. Revisit it when you change resolution, codec, schedule or region. Those changes can affect both resource needs and charges.
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 leave one Cloud Run service request publishing all day?
No. A service request has a documented maximum timeout of 60 minutes, so a single request is not a suitable lifetime for a 24/7 publishing session. Keep the service for brief controls and evaluate an always-on workload for the publisher.
Should I use a Cloud Run job for the stream?
A job is designed for work that runs to completion, such as validating or preparing a video. For a continuous publisher, assess worker pools or a long-lived singleton-capable instance instead, and verify current regional availability and limits before deployment.
Can I use a prerecorded file without re-encoding it?
Possibly, if its streams and output behaviour are compatible with YouTube’s current ingest guidance. Test the actual file in Live Control Room and check audio, video and reconnect behaviour; otherwise, use an encoder configuration suited to the intended output.
What should I check before launching?
Confirm channel eligibility, protect the stream key, inspect the preview, and test a reconnect and restart with representative media. Then review the chosen Cloud Run workload’s current regional availability, quotas and costs. A successful first connection is not proof of uninterrupted publishing.