Google Cloud Run: Services, Jobs, Revisions, and the Container Runtime Contract
How Cloud Run turns containers into managed services and jobs, including scaling, traffic splitting, IAM, networking, observability, and cold-start tradeoffs.
Cloud Run is Google Cloud’s fully managed application platform for containerized code. A service exposes a stable endpoint and creates immutable revisions; a job runs tasks to completion; worker pools cover continuously running non-request workers where available. Source deployment is a build convenience—the runtime still executes a container image.
Revisions and traffic
Configuration or image changes create a revision. Traffic can move all at once, split between revisions, or roll back without rebuilding the old artifact. Keep database migrations backward-compatible while two revisions coexist. Tags and friendly names help operators, but deployments should still pin an image digest when provenance matters.
Scaling and cost controls
Services scale with request demand and can scale to zero. Concurrency, CPU allocation, minimum instances, maximum instances, request timeout, and billing mode influence both latency and cost. Minimum instances reduce cold starts but create baseline spend; maximum instances protect budgets and downstream systems. Jobs and worker pools have different scaling behavior, so do not transfer service assumptions to them.
Security and networking
Each revision runs as a service account. Grant only the Google Cloud permissions needed at runtime, keep deployment identities separate, and use Secret Manager rather than environment variables containing long-lived credentials. IAM controls invocation, while ingress settings and VPC connectivity control network reachability. Public URL does not require public invocation permissions.
Observability and limitations
Cloud Logging and Monitoring capture platform telemetry; application traces and structured logs should carry request context. The writable filesystem is disposable, so durable state belongs in an external service. Cloud Run is an excellent fit for stateless HTTP/event services and finite jobs. Workloads needing privileged containers, host access, or tightly coupled state usually need another platform.
The runtime contract is the portability boundary
A Cloud Run service container must listen for requests on the configured PORT and on all network interfaces, not only loopback. The container filesystem is writable but in-memory and does not persist when an instance stops. Processes must handle termination and should finish or checkpoint work within the platform’s documented shutdown behavior. Container image architecture and manifest support must match the current runtime contract.
The service may process multiple requests concurrently in one instance. Application code, connection pools, global state, and libraries must therefore be concurrency-safe. Lowering concurrency can isolate expensive requests but may increase instance count and cost; raising it can improve utilization but exhaust memory or downstream connections. Load-test the chosen CPU, memory, concurrency, and request timeout together.
Revisions and gradual delivery
Every deployable configuration creates an immutable revision. Keep the image digest, service account, environment and secret references, concurrency, resources, ingress, VPC settings, and scaling controls in versioned deployment configuration. Tags give revisions stable URLs for testing, while traffic percentages support canaries and rollbacks. They do not reverse database or message side effects, so use backward-compatible schema and protocol changes.
Cloud Run can gradually move traffic, but the release system should decide from service-level evidence. Compare error rate, latency, saturation, and business correctness for the candidate revision. Preserve a minimum rollback window and the exact prior digest. If deploying from source, capture the Cloud Build output and resulting image; source identity alone is not runtime identity.
Identity, invocation, and networking
The service identity is the service account used by running instances. Give it only required data-plane roles and keep it separate from the deployer account. Use Secret Manager references or API access under that identity rather than service-account key files. Decide whether a secret update requires a new revision or an application refresh, and test rotation.
IAM invocation and ingress settings are separate controls. A URL can exist without allowing unauthenticated invocation. Internal or load-balancer-oriented ingress changes which network sources are accepted, while VPC egress controls access from instances to private resources. Verify DNS, routes, connector or direct-VPC configuration, firewall policy, and outbound internet needs. Maximum instances should protect private databases and APIs from a scaling burst.
Jobs, retries, and durable work
Cloud Run jobs execute tasks to completion rather than serving requests. Configure task count, parallelism, timeout, and retries according to workload and dependency capacity. A retry may repeat completed external work, so use idempotency keys, checkpoints, and transactional boundaries. Store outputs and progress externally; local files disappear with the task instance.
For services that accept asynchronous events, acknowledge only after work is durably recorded or make the handler idempotent against redelivery. Do not hold an HTTP request open as a substitute for a queue when work exceeds request semantics. Worker pools and jobs have distinct lifecycle and availability contracts; consult their current documentation before transferring service assumptions.
Operational acceptance
Alert on request errors, latency, instance saturation, startup failures, maximum-instance pressure, job failures, retry growth, and dependency SLOs. Structured logs should include trace and request correlation without secrets. Test cold start, scale-out, scale-in, termination, canary, rollback, denied invocation, secret rotation, private dependency access, and regional recovery. Review quotas before traffic events and request increases where supported.
Represent the service and job configuration declaratively, including image digest, service account, resources, concurrency, scaling bounds, ingress, egress, secrets, and traffic. Retain revision history, but do not treat it as the only backup of configuration. Emergency console changes should be reconciled to source. Separate ownership of the runtime service from ownership of databases, event subscriptions, DNS, load balancing, and security policy.
Cost review should include minimum instances, CPU and memory allocation, request duration, job task time, build and registry storage, logging ingestion, VPC networking, load balancing, and egress. Compare cost per successful business operation, not only cost per instance. A configuration that saves idle compute but causes repeated cold-start timeouts or duplicate job work is not economical. Related: Google Container Registry After Shutdown: What GCR Was and How Migration Works · Fixing ‘No Space Left on Device’ from Docker Image and Container Buildup
Sources: What is Cloud Run, container runtime contract, revisions, traffic rollouts, service identity, ingress, jobs