Google Cloud Run

At a glance

Cloud Run is worth evaluating for an API, web application or batch task when you want managed execution on Google Cloud without operating a cluster. Its service model turns your code or container into an HTTPS endpoint with scaling and revision management. It removes host administration from the application workflow, but does not remove decisions about state, authentication, concurrency, startup behavior and cost.

Good fit

Request-driven applications that can tolerate replaceable instances, and teams that benefit from Google Cloud identity and service integration. A service handles requests; a job runs tasks to completion. Current documentation also distinguishes worker pools for continuous background work and a preview instance model for long-lived singletons. Choose the resource type before assuming every Cloud Run workload has the same lifecycle. Store durable files separately, for example in Cloud Storage, rather than depending on the service container’s writable filesystem.

Consider something else when

Your application requires a durable local database file, privileged host control or a service instance that must never be replaced. The default writable filesystem uses instance memory and loses its contents when the instance stops. Services can scale to zero, so the first request may wait for startup; minimum instances trade some of that delay for ongoing cost. Request-based CPU allocation is not a promise that arbitrary work continues after the response. For continuous or singleton work, evaluate the worker-pool or preview instance model instead of treating an HTTP service as an always-on machine.

Start here

In an authorized billing-enabled sandbox, open Cloud Run Services, choose Deploy container and Test with a sample container, then select a region and authentication mode deliberately. The official hello-world quickstart demonstrates a public sample; a private service needs an authorized invoker and an appropriate ID token. A useful first result is the expected response plus a request log, followed by checking the deployment’s identity, scaling and cost settings. Adapt your own ingress process to listen on the injected PORT on 0.0.0.0. These are documented evaluation steps; no deployment, image build or invocation was performed for this guide.

Cost and requirements

Services offer request-based and instance-based billing. The former charges for requests and relevant processing/startup/shutdown resources; configured minimum instances can add idle costs. The latter charges across the instance lifecycle. Free allowances and rates depend on billing configuration, region and billing-account usage. Source builds, image storage and network or connected services can add separate charges. Current spend caps can pause Cloud Run resources in a project, but enforcement is not instant, overages can still be billed and other services remain outside that cap. A traffic or instance setting is not a complete bill estimate.

Limits to know

An authenticated endpoint is only one boundary: the runtime service identity also needs appropriate permissions for databases, buckets and other services. Scaling can multiply concurrent requests and downstream connections, so test those limits with your actual workload. Minimum instances and instance-based CPU do not make service instances permanent. The separate instance resource is documented as Preview, with potentially limited support. Regional placement also affects latency and transfer costs when dependencies live elsewhere. The recommendation is source-researched, not evidence of a successful migration, measured cold start, load test, billing result or security assessment. The earlier “pay only while handling requests” description does not cover all current billing modes.

Related work

• Google Cloud: projects, identities, locations and billing (context)
• Cloud Storage: durable objects outside the service instance (context)

Still unclear

• Cold-start latency, application throughput, downstream capacity and total cost were not measured.
• Compatibility with a specific application and its recovery, identity and networking needs was not tested.