What does a Cloud Run service need from your app?

The web process has to listen on the port Cloud Run provides. The container must accept requests on all its internal network interfaces, written as 0.0.0.0, so the service can reach it.

You can deploy a compatible image or submit supported source. The source path uses Cloud Build to make an image and Artifact Registry to store it. Before a hosted setup, identify the project, billing, Region, enabled services and deployment access you need.

A new service is private by default. Decide who should be allowed to call it. A public shop-status page and a private staff tool need different access settings.

How can you check a new version before sending visitors to it?

Use paper or two versions of a disposable local shop-status page. Before running either copy, verify the address and port, remove live credentials and check that neither copy can reach live records, accounts, payments or messages. Keep this exercise local. If any connection is uncertain, use paper.

Write down the response for each version
Give version A a status page that says “Taking repairs” and version B one that says “Pickup only”. Use the same page path for both.
Check the candidate on its own address
In a local rehearsal, give each running copy a different local port and open both addresses. Confirm A still answers with its original text and B shows the expected change. On paper, label one address for visitors and another for the test.
Rehearse pointing visitors back
On paper, point the visitor address to B and then back to A. Check which message each address should return after each change. Keep a copy of A and the settings it needs to start.

What does a Cloud Run revision tag actually change?

Cloud Run saves a deployment as a revision. On an existing service, you can deploy a revision with no normal traffic and give it a tag, a label that provides a direct test address. Later you can move some or all traffic to it, or return traffic to an earlier revision.

A direct address can still receive requests. A tag decides which revision answers and service access rules decide who can reach it. For a later hosted test that needs its own data or permissions, use a separate authenticated service or project and verify its connections before sending any requests.

Which Cloud Run charges depend on requests?

Request-based billing counts requests and measures CPU and memory during request processing, startup and shutdown. If you configure minimum instances, check the idle charge. Instance-based billing meters allocated CPU and memory over the instance’s lifetime, including time between requests.

Check the rates for your Region and mode. CPU is measured in vCPU-seconds and memory in GiB-seconds. Build time, image storage, network transfer and a separate service such as Cloud SQL can add charges of their own.

Budget alerts notify you at configured spending thresholds. Cloud Run can also exceed a configured maximum instance count briefly in documented cases. Estimate costs using your actual traffic and resource settings.

What stays after a Cloud Run instance stops?

Files written to the container’s ordinary filesystem use memory and disappear when the instance stops. Store records and uploads in services that retain them. A mounted storage service has its own behavior and permissions.

Returning traffic to an earlier revision changes which code handles requests. Recover database records and uploaded files through their own backups. Rehearse recovery in a separate empty test destination with sample data and test-only access.

Keep the source and build files, the exact image version and the exported service configuration. Treat the export as private until you have checked it for sensitive values. Record the setting names and service permissions you need, and store secret values separately. Check that a replacement host can run the image and connect to a restored sample database and files.