Choosing a Deployment Target
For a simple stateless web app, Cloud Run is usually the fastest path to production on GCP: you provide a container image, and Cloud Run handles provisioning, autoscaling (including scaling to zero when idle), and HTTPS termination automatically. This contrasts with App Engine, which is more opinionated about runtimes and buildpacks, and GKE, which gives full Kubernetes control but requires managing a cluster — overkill for a single small service.
Cricket analogy: Choosing Cloud Run over GKE is like opting for a franchise T10 tournament with a fixed format rather than organizing your own five-day Test match venue — you get to play immediately without building the ground yourself.
Building and Deploying the Container
The typical flow is: write a Dockerfile, build the image with Cloud Build (or docker build locally), push it to Artifact Registry, then deploy with a single gcloud run deploy command that references the image and sets configuration like memory limits, concurrency, and environment variables. Cloud Run automatically assigns a stable HTTPS URL and can be configured for both public access and authenticated-only invocation via IAM.
Cricket analogy: This pipeline is like nets practice (build), a warm-up match (push to registry), then walking out for the actual game (deploy) — each stage validates readiness for the next.
# Build with Cloud Build and push to Artifact Registry
gcloud builds submit --tag us-central1-docker.pkg.dev/my-project/my-repo/simple-app:v1
# Deploy to Cloud Run
gcloud run deploy simple-app \
--image us-central1-docker.pkg.dev/my-project/my-repo/simple-app:v1 \
--region us-central1 \
--platform managed \
--allow-unauthenticated \
--memory 512Mi \
--concurrency 80 \
--set-env-vars "ENV=production,LOG_LEVEL=info"Cloud Run keeps every deployed revision by default, tagged with a unique URL. You can split traffic between revisions (e.g., 90% to the stable revision, 10% to a canary) using --traffic flags without redeploying.
Rollback and Configuration Management
Because each Cloud Run deployment creates an immutable revision, rolling back is just a matter of shifting traffic back to a previous revision — no rebuild required. Configuration such as secrets should be pulled from Secret Manager at startup rather than baked into the image or passed as plain environment variables, since env vars are visible to anyone with read access to the service configuration.
Cricket analogy: Rolling back to a previous revision is like a captain reverting to the tried-and-tested batting order from the last series after an experimental lineup underperformed — the old configuration still exists and can be reinstated instantly.
Setting --allow-unauthenticated makes the service publicly reachable on the internet. For internal services, omit this flag and instead grant the roles/run.invoker IAM role to specific service accounts or users.
- Cloud Run is the fastest path for deploying a simple stateless container, with automatic scaling and HTTPS.
- The standard flow is: build with Cloud Build, push to Artifact Registry, deploy with gcloud run deploy.
- Every deployment creates a new immutable revision, enabling instant traffic-based rollback.
- Traffic can be split between revisions for canary releases without a rebuild.
- Secrets should come from Secret Manager, not baked into images or set as plain environment variables.
- Use --allow-unauthenticated carefully — omit it and use IAM invoker roles for internal-only services.
- App Engine and GKE remain valid alternatives, but add more operational overhead for simple apps.
Practice what you learned
1. What happens by default when a Cloud Run service receives no traffic?
2. Where should application secrets be stored for a Cloud Run service?
3. How does Cloud Run enable rollback to a previous version?
4. What does the --allow-unauthenticated flag do?
5. Which artifact repository is typically used to store the container image before Cloud Run deployment?
Was this page helpful?
You May Also Like
Cloud Monitoring Basics
Learn how Google Cloud Monitoring collects metrics, logs, and traces so you can observe the health and performance of resources running on GCP.
The GCP Architecture Framework
An overview of Google Cloud's Architecture Framework pillars — system design, operational excellence, security, reliability, cost optimization, and performance — for building well-architected workloads.
GCP Quick Reference
A condensed cheat sheet of core GCP services, gcloud commands, and IAM/networking concepts for fast lookup during study or work.