# Cloud Run: deploying container services to a customer's Google Cloud without building a cluster

> Cloud Run spares you days of waiting for someone to approve and build a cluster. The price is that you have to deal with cold starts and answer networking questions in the very first meeting.

Original: https://fdetimes.net/en/tools/cloud-run-customer-deployments/

Picture this: a customer hands you a Google Cloud project, a service account and two weeks to run a pilot. Nobody on their team wants to operate yet another Kubernetes cluster. In that situation Cloud Run is often the shortest path, but you should only choose it once you know where it can break.

Google describes Cloud Run as a fully managed application platform that can run code, functions or containers. For an FDE, the most valuable point is the documentation's assurance that you can get work done without creating a cluster or managing infrastructure.

On a customer site, every day you don't spend requesting permission to build infrastructure is another day spent on the real problem.

## Services wait for requests, jobs run to completion

A service sits waiting for incoming requests. A job is for parallelisable tasks that run, manually or on a schedule, until they finish.

A 2019 Google blog post called Cloud Run an ideal home for stateless container microservices, the kind that don't need Kubernetes features such as namespaces or node management. The post is old, so product details may have changed. Even so, "does this service hold state?" is still the first question worth asking.

## A concrete pilot, step by step

Imagine the customer is an insurer that needs to extract information from claims files. You have two parts: an API that receives files from internal systems, and a nightly task that reprocesses the whole backlog. The API is a Cloud Run service; the nightly task is a scheduled Cloud Run job.

Where should your image live? Google recommends Artifact Registry and says Docker Hub should only be used for popular images. An image you build yourself for a customer is not in that group, so push it to Artifact Registry inside the customer's own project.

A small but useful detail: Cloud Run imports the image at deploy time and does not pull it again from the registry each time a new instance starts. So if the registry has trouble just when the service needs to scale up, scaling is not affected. This belongs in the runbook you hand over to the customer's operations team.

## The customer wants the service on the internal network

Every insurer will ask: does customer data travel over the internet? The answer lies in the ingress setting. In All mode, every request is accepted, including requests from the internet hitting the run.app URL directly.

In Internal mode, requests from other sources, including the internet, cannot reach the service through the run.app URL, custom URLs or custom domains.

So in the first meeting, ask the customer which systems will call your API and where they sit on their network. Then check the answer against the definition of internal sources in the ingress documentation; don't wait until go-live day.

## Scaling to zero: cheap, but paid for in cold starts

When a service has no requests, Cloud Run removes even the last instance. A new request therefore needs a new instance, and Google's documentation confirms that requests sometimes have to wait for an instance to finish starting before they are handled. A 2020 Google blog post also acknowledged that serverless platforms have long accepted a trade-off in first-response latency.

According to the documentation, a request may wait up to 3.5 times the instance's average startup time, or 10 seconds, whichever is greater. For example, if your container takes 2 seconds to start on average, 3.5 times that is 7 seconds.

That is less than 10, so the request may wait up to 10 seconds. If Monday morning's demo is the first request after the weekend, the person waiting is the customer.

A "warm-up" call scheduled before the demo is not reliable either: if no further requests arrive after that call, the last instance can still be removed.

Google's recommended way to reduce cold starts is to set minimum instances. An independent guide on the OneUptime blog points out the cost: standby instances that are not handling requests are billed at a lower rate, but they are not free.

For an important demo, you are trading a little cost for latency, and you should spell out that trade-off to whoever approves the customer's budget.

## When to stop and choose GKE

Google's reference architecture compares Cloud Run with GKE Autopilot and states one trade-off plainly: Cloud Run does not support Kubernetes. If the customer's application needs namespaces or node management, don't force it onto Cloud Run.

**Key point:** Ask early whether the application needs Kubernetes; the answer decides where it runs.

## Common mistakes on a first pilot

Most trouble with Cloud Run lies not in the tool itself but in questions that weren't asked early enough.

| Mistake | Why it hurts | What to do instead |
|---|---|---|
| Using a service for batch work | Running to completion is what jobs are for | Split batch processing into a job, run manually or on a schedule |
| Asking late who will call the service | With Internal ingress, the internet cannot reach the run.app URL | Ask in the first meeting and verify before go-live |
| Trusting a "warm-up" schedule without testing | Instances can still be removed once requests stop | Consider min instances, rehearse and measure the first request |
| Keeping a private image on Docker Hub | Google only recommends Docker Hub for popular images | Use Artifact Registry |
| Forcing a Kubernetes-dependent app onto Cloud Run | Cloud Run does not support Kubernetes | Look at GKE Autopilot for that part |

## What to learn first

Start with containers: write a lean Dockerfile, run it locally and keep the service stateless. Then get the difference between services and jobs firmly in hand, followed by ingress, because that is where the customer's security team will look hardest. Finally, measure cold starts on your own service.

On your CV, don't just write "Google Cloud". Write a specific line, for example: deployed a document-extraction API to Cloud Run with Internal ingress, plus a nightly processing job, with min instances set to cut cold starts during demo hours.

When a job description asks for deployment on a customer's GCP, that is exactly the story to have ready.

Cloud Run doesn't do the hardest part of the job for you, which is understanding the customer's network and processes. But it takes some of the infrastructure load off, leaving you more time for that hard part.

**Try this week:**

- Push the image of a small API to Artifact Registry, deploy it to Cloud Run, leave it idle for a while, then measure the latency of the first request.
- Turn a periodic script into a Cloud Run job, run it manually once, then put it on a schedule.
- Set Internal ingress on a test service, then call the run.app URL from the internet to confirm the request is blocked.

## Sources

- [What is Cloud Run | Google Cloud Documentation](https://docs.cloud.google.com/run/docs/overview/what-is-cloud-run)

- [General development tips | Cloud Run documentation](https://docs.cloud.google.com/run/docs/tips)

- [Cloud Run min instances: Minimize your serverless cold starts](https://cloud.google.com/blog/products/serverless/cloud-run-adds-min-instances-feature-for-latency-sensitive-apps)

- [How to Configure Minimum Instances on Cloud Run to Eliminate Cold Starts for Production Services](https://oneuptime.com/blog/post/2026-02-17-how-to-configure-minimum-instances-on-cloud-run-to-eliminate-cold-starts-for-production-services/markdown)

- [Restrict network endpoint ingress for Cloud Run services and instances | Google Cloud Documentation](https://docs.cloud.google.com/run/docs/securing/ingress)

- [Deploy container images to Cloud Run services | Google Cloud Documentation](https://docs.cloud.google.com/run/docs/deploying)

- [Google Kubernetes Engine vs Cloud Run: Which should you use?](https://cloud.google.com/blog/products/containers-kubernetes/when-to-use-google-kubernetes-engine-vs-cloud-run-for-containers/)

- [Select a managed container runtime environment | Cloud Architecture Center](https://docs.cloud.google.com/architecture/select-managed-container-runtime-environment)