Google Cloud Run can run a containerised encoder that sends a prerecorded video to YouTube Live, but it does not create the event, provide the video, or supply a stream destination for you. For a finite file, a Cloud Run Job is often the first resource to evaluate; its task duration, retry behaviour and access to durable media need deliberate planning.
A Service is built around HTTP requests, not an encoder process that should stay attached to one request indefinitely. Before you build anything, decide how long the broadcast must run, how the file and stream key reach the container, and what should happen if an attempt ends unexpectedly.
Map the video-to-YouTube workflow
Think of the setup as four separate parts: a source file, an encoder, a Cloud Run resource to run that encoder, and a YouTube Live event that receives its output. Cloud Run runs the container you provide; it does not automatically loop a file or know which YouTube event to target. Google’s overview of Cloud Run resource options is a useful starting point for distinguishing the available execution models.
A typical finite-file workflow looks like this:
- Put the video somewhere the running task can read it, such as Cloud Storage or another durable storage system.
- Build a container image with an encoder such as FFmpeg and configure it to read the file.
- Create or schedule a live event in YouTube Studio, then obtain that event’s stream URL and stream key.
- Run the encoder in a Cloud Run Job, passing it the media location and protected ingest credentials.
- Check the YouTube preview and stream health, then start the scheduled event when you are ready.
This is an architecture outline, not a tested, copy-and-paste recipe. You will still need to configure and test the container, its network access, the encoder parameters and the event workflow. If you need repeated playback rather than one pass through a file, make looping an explicit encoder behaviour and test what happens at the transition; Cloud Run will not infer that requirement. For background on the playback side, see ways to loop a video on YouTube Live.
Choose a Service, Job or longer-lived model
A Cloud Run Service responds to HTTP requests. That can suit an encoder task that starts in response to a request and finishes within the request’s deadline, but an ongoing broadcast should not depend on a single HTTP connection remaining open. Google documents a maximum Service request timeout of 60 minutes; when the deadline expires, the connection can close with HTTP 504 even though the container may continue processing. A response timeout is not a safe way to supervise a live encoder.
A Cloud Run Job runs tasks to completion and exits. That makes it a natural first option to assess for a finite prerecorded file: start a task, have it run the encoder, and let it finish when the file is done. A Job is not an unlimited-duration stream runner. Its task duration is bounded, and a configured retry may launch another attempt rather than smoothly resume the same feed.
| Resource or approach | What it is designed to do | Main constraint for a live encoder |
|---|---|---|
| Cloud Run Service | Handle HTTP requests | The request has a maximum timeout; do not make a long broadcast depend on one open request. |
| Cloud Run Job | Run tasks to completion | Each task attempt has an execution-duration limit; retries need deliberate handling. |
| Longer-lived Cloud Run execution model | Support workloads that need a process to remain active beyond a request pattern | Compare lifecycle and supervision requirements with the actual broadcast; do not assume uninterrupted encoding. |
| Separate streaming or automation approach | Keep a broadcast running or manage recurring output | Choose based on duration, operator involvement and recovery needs, then test the full chain. |
Google also documents instances and worker pools for long-lived workloads. They may be more appropriate to investigate where a continuously supervised process matters, but resource choice alone does not guarantee an uninterrupted YouTube feed. If you are weighing a continuously running encoder against a hosted approach, the practical differences are described in FFmpeg versus a cloud service for a 24/7 YouTube podcast stream.
The deciding question is not simply whether the video is prerecorded. It is whether one finite task fits comfortably inside the chosen execution model and what interruption or restart means for the audience. A one-hour programme scheduled for one pass and a channel intended to run the same material around the clock are different operating problems.
Account for task execution duration
Google Cloud’s current Cloud Run Jobs documentation lists a default task timeout of 10 minutes and a maximum of 168 hours (seven days) for a task; GPU tasks have a maximum of one hour. These are platform limits, not recommended broadcast durations. Check Google Cloud’s task timeout documentation before deployment because the configured timeout must suit the task and the applicable resource constraints.
Set the task timeout longer than the expected media duration, allowing for startup, file access, encoder initialisation and orderly shutdown. If a file is expected to run for several hours, a timeout close to its nominal duration leaves no room for those steps. Conversely, raising a timeout does not make the task permanent: it remains subject to the maximum and to the lifecycle of the resource.
Retries need the same attention as the timeout. A failed attempt may be run again, but that does not mean YouTube will treat the new encoder process as a seamless continuation. Depending on when the failure occurs and how the event is configured, a restart could interrupt the feed or produce an unwanted second start. Decide whether a failure should stop the broadcast for an operator to inspect, or whether a retry is appropriate, and test that path rather than assuming it is harmless.
Do not treat a Service’s request timeout as interchangeable with a Job’s task timeout. Google lists a default Service request timeout of five minutes and a maximum of 60 minutes. Those figures govern a request-response path; they do not provide a duration setting for a Job or a promise that a process will be supervised after the response ends. The relevant control depends on the resource you choose.
For 24/7 operation, one task that eventually reaches its limit is not a complete scheduling or recovery design. You would need to decide how a new run is started, how it connects to the intended event, how duplicate starts are avoided, and who checks a failed run. If you cannot state those behaviours clearly, begin with a short test event rather than committing a long programme to an untested task.
Decide how the encoder accesses media
Cloud Run’s writable container filesystem is disposable. A video copied into the image can make the image large and complicate updates; a file written to a task’s local storage should not be treated as durable after the task completes. Google’s Cloud Run storage guidance describes options for accessing persistent files, including Cloud Storage and NFS.
For a straightforward design, keep the source video in durable storage and make its location a configurable input to the container. The encoder can then read the chosen object at runtime instead of relying on a file that exists only inside a particular task instance. Check access permissions and test the exact file path from a running task; a correctly built container cannot stream a file it cannot read.
Cloud Run Job ephemeral disk is another choice, but it is not a durable archive. Google labels the feature Preview in its documentation and says its contents are deleted when the instance shuts down, including after task completion. Treat it as temporary working space, not as the authoritative copy of the programme. If the encoder produces an output or log that you need after a run, arrange to store it outside disposable local storage.
Also decide whether the file is read directly, staged temporarily, or mounted through a persistent storage option. A large file that is downloaded to temporary disk has different storage and startup implications from one read through a mount. Do not assume the container’s memory or local disk can accommodate the media simply because the image starts successfully. Test with the actual file size and duration, and observe the task’s behaviour under realistic conditions.
Create the YouTube event and protect credentials
The YouTube destination is an explicit event setting, not a Cloud Run feature. In YouTube Studio, use Live Control Room to create or schedule a stream. YouTube supplies the stream URL and stream key for the encoder; for RTMPS, retrieve the RTMPS address shown for the event. YouTube explains event setup and stream-key handling in its live streaming help.
Treat the stream key as a credential: anyone who obtains it may be able to send ingest to that stream. Do not bake it into a public container image, commit it to source control or print it in task logs. Provide it through protected runtime configuration or a secret-management service, and limit access to the people and runtime identities that need it. If you believe a key has been exposed, replace it in Live Control Room and update the protected configuration before the next run.
A scheduled event may require an operator step after the encoder connects. Start the feed, inspect the preview in Live Control Room, and select Go live when you intend the event to become public. Sending data to the ingest address is not necessarily the whole launch workflow. YouTube’s current eligibility guidance also says a channel must be verified, have no live-streaming restriction in the previous 90 days, and meet its minimum age requirement of 16; check the official eligibility page for current requirements before automating a launch.
Keep event management separate from task execution. A container can be told to send data to a URL and key, but that does not create or schedule the event, decide its visibility, or click Go live for you. Establish who owns those actions and what should happen if the scheduled time changes.
Configure the encoder feed
Package an encoder such as FFmpeg in the container image, and make the input path, destination and key configurable rather than hard-coded. This keeps a media change or key rotation from requiring an image rebuild. The exact command depends on the input format, desired output, and how you handle looping; validate the command against the file you will actually broadcast rather than treating an illustrative command as a production-tested recipe.
YouTube recommends RTMPS for encoder ingest. Its published encoder guidance lists H.264, H.265 (HEVC) or AV1 for video, AAC or MP3 for audio, constant bitrate, and frame rates up to 60 fps. It recommends a two-second keyframe interval and says not to exceed four seconds. Use YouTube’s encoder settings guidance to confirm current settings, then choose a resolution and bitrate the source and connection can sustain.
The source file’s properties matter. A video encoded at a particular frame rate or resolution may need to be re-encoded or passed through depending on compatibility and resource needs. Monitor CPU use and output quality during a representative test; a container that starts is not evidence that its encoder settings can sustain the intended feed. If YouTube reports a bitrate warning, use the bitrate settings troubleshooting guide to think through the encoder and upload path together.
HLS is an alternative for specific supported codec and HDR workflows, but it is not interchangeable with RTMPS in every setup. It uses segments and can have higher latency, with format and playlist requirements. Choose it only when the workflow needs its supported capabilities and the encoder can meet the documented requirements. For the usual prerecorded-file-to-event path, RTMPS is the simpler starting point to evaluate.
Test runtime and stream behaviour
Test the complete chain before relying on it for an audience: task launch, media access, encoder output, YouTube preview, stream health and the audience-facing watch page. Use a representative clip with the same audio and motion characteristics as the real programme. YouTube recommends testing and monitoring stream quality; its live encoder troubleshooting guidance can help interpret problems in the preview and health indicators.
A practical preflight should establish that the task can read the intended file, obtain the protected key without exposing it, connect to the intended event and stop in a controlled way. Check the event preview before going live. After the test, confirm that the public watch page behaves as expected and that any archive is accessible. YouTube says streams shorter than 12 hours are automatically archived, but do not treat that as a substitute for checking the result or for keeping your source file.
Test failures deliberately in a non-critical event. Observe what happens when the input is unavailable, the encoder exits, or a task reaches its timeout. Confirm whether a retry occurs and whether it would reconnect to the same event in a way you actually want. A retry policy that is sensible for a batch task may be unsuitable when a duplicate or interrupted live feed is costly.
If the encoder runs from Cloud Run, also check the stream over the duration you expect to use. A brief preview does not demonstrate that a long task will reach its intended finish, and successful task completion does not by itself establish that viewers saw a clean ending. YouTube guidance on stream health and monitoring is useful, but the particular combination of your media, encoder and Cloud Run configuration still needs your own validation.
For a local encoder comparison, the causes and remedies for dropped frames are covered in why OBS skips frames when streaming video files. The broader lesson applies here too: inspect the actual output and network conditions rather than guessing from the encoder’s configuration screen.
If the operational burden is the repeated handling of a file, key, task timeout and recovery plan, StreamNeo removes that specific setup work by letting you upload a video and provide the YouTube stream key, then run the broadcast without keeping your own computer on. It is YouTube-only, so it is not the answer if you need a destination or a custom Cloud Run deployment.
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 a Cloud Run Job stream a video to YouTube Live?
Yes, if you configure a containerised encoder to read the file and send output to the event’s ingest URL with its stream key. The Job runs a task to completion; it does not create the YouTube event, supply a destination or automatically loop the media. Its execution-duration limit and retry behaviour need to fit the planned broadcast.
Is a Cloud Run Service better for a continuous stream?
A Service is request-oriented, and its request has a maximum timeout. Do not make a long-running encoder depend on one request staying open. Compare a Job for a finite task with longer-lived execution models if continuous process supervision is central to your requirement.
Where should I keep the video and stream key?
Keep the video in durable storage such as Cloud Storage or another persistent option, rather than relying on disposable local task files. Keep the stream key in protected runtime configuration or a secret-management service, not in an image, source control or logs. Test that the task can access both without exposing the key.
Does sending RTMPS data make a scheduled event live automatically?
Not necessarily. For a scheduled event, start the encoder and check the preview in Live Control Room, then choose Go live when appropriate. Confirm the current event workflow in YouTube’s official guidance before you automate or schedule a broadcast.