Deploying Serverless Containers with Cloud Run

Overview and What You Will Learn

In this lab, you will deploy a container to Cloud Run, deploy a second revision, split traffic between the two revisions for a gradual rollout, and configure scaling parameters to control cost and cold-start behavior.

Why This Matters in Production

A team deploys a new version of their API directly to 100% of production traffic, discovers a bug affecting live requests within minutes, and has to scramble to roll back while customers are actively affected. Cloud Run's traffic splitting lets that same team send just 10% of traffic to the new revision first, catching the issue with limited blast radius before it ever reaches most customers.

Core Principles

Cloud Run runs a container as a fully managed, serverless service - each deployment creates a new Revision, and traffic can be split between revisions by percentage, enabling gradual rollouts without any separate infrastructure to manage.

Unlike a traditional deployment where "the new version" simply replaces "the old version," Cloud Run keeps both revisions available simultaneously, letting traffic be shifted gradually and rolled back instantly by simply adjusting the percentage split back to the previous revision.

Detailed Step-by-Step Practical Lab

1. Create a project and enable Cloud Run:

2. Deploy an initial version of a service:

3. Deploy a second revision without shifting any traffic to it yet:

4. List the current revisions and confirm the new one is deployed but receiving zero traffic:

5. Gradually shift 10% of traffic to the new revision:

6. After confirming the new revision behaves correctly, shift all traffic to it:

7. Configure scaling parameters - a minimum instance count to avoid cold starts for a latency-sensitive service, and a maximum to cap cost:

Note

--min-instances=1 keeps at least one instance warm at all times, eliminating cold-start latency for the first request after a quiet period, at the cost of paying for that one instance continuously rather than scaling fully to zero. This is a deliberate trade-off for latency-sensitive services, not the default for every workload.

8. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Deploying a new revision directly to 100% of traffic with no gradual rollout, discovering a critical bug only after customers are already affected. Cloud Run's traffic splitting costs nothing extra and gives a real, live testing path with limited blast radius before a full cutover.

Tip

Set --min-instances specifically for latency-sensitive, user-facing services where a cold start would be noticeable, and leave it at the default (scaling to zero) for internal or infrequently-used services where occasional cold-start latency is an acceptable trade-off for not paying for idle capacity.

• Rolling back is as simple as shifting traffic back to the previous revision - since Cloud Run keeps prior revisions available (up to a retention limit), a bad deployment can be reversed in seconds without needing to rebuild or redeploy the old version from source.
• --allow-unauthenticated makes a service publicly reachable with no authentication at all. For internal services, omit this flag and rely on IAM-based invoker permissions instead, restricting who can call the service to specific identities.

Quick Reference & Troubleshooting Commands