A Cloud Run deployment checklist for dependable releases

A Cloud Run revision is healthy only when it can start, listen on the expected port, pass its startup behavior, and serve the contract users depend on. Write that contract before deployment. It should include required environment variables, secret versions, database reachability, outbound dependencies, authentication expectations, and a lightweight readiness check. A process that returns 200 from a root route while its worker or webhook path is broken is not healthy for the product.

Keep startup work bounded. Pulling a large dataset, running an unbounded migration, or waiting for an optional provider can cause cold starts and failed revisions. Build artifacts in CI, keep the runtime image small, and perform only the initialization required to accept traffic. A separate job can handle migrations or backfills with its own permissions and rollback plan.

Use a pinned base image and a lockfile so a rebuild does not silently change dependencies. Multi-stage builds keep compilers and test tools out of the runtime image. Run the process as a non-root user when the platform and framework support it. Remove development files, local credentials, and source maps that are not needed in production. Scan the final image for vulnerable packages and document exceptions with an owner and review date.

The container must bind to the port supplied by the runtime and should handle termination signals so in-flight requests can finish within the shutdown budget. Avoid writing important state to the local filesystem because instances are replaceable. Temporary files should have a size limit and cleanup policy. Confirm the image starts with the same command in a clean environment rather than relying on a developer machine's global tools.

Environment-specific values should be supplied through deployment configuration or a managed secret store, not baked into the image. Keep public client configuration distinct from server-only credentials. Verify the service account can read exactly the secrets it needs, and confirm that a missing secret fails clearly at startup. Secret rotation should produce a new revision or a controlled reload path; do not edit a running container by hand and assume the change is durable.

Record the configuration fingerprint and secret version metadata used by each revision without recording secret values. This lets operators explain why two revisions behave differently. Avoid printing the entire environment at startup. If a provider key or price ID is wrong, a targeted health check and categorized log are safer than a dump that may include unrelated credentials.

Deploy a new revision without immediately moving all traffic when the product allows it. Send a small percentage or a controlled test request to the revision, then compare error rate, latency, logs, and dependency behavior. A canary should exercise the routes that changed, not only a generic health endpoint. Keep the previous revision available until the new one has passed a normal traffic window.

When a release is unhealthy, roll traffic back to the known-good revision before debugging in place. A rollback should be a documented command or console action that an on-call operator can perform quickly. Do not delete the previous revision until logs and active requests no longer need it. For schema changes, use backward-compatible migrations so either revision can serve during the transition.

CPU, memory, request timeout, minimum instances, maximum instances, and concurrency shape both cost and reliability. A CPU-bound handler may need lower concurrency, while an I/O-bound API can share an instance more efficiently. Set a maximum instance count that protects dependencies and a queue or rate limit for work that can grow without bound. A high timeout does not make a slow request healthy; it may keep connections and memory occupied until the platform gives up.

Use minimum instances when cold-start latency matters and the budget supports it. Watch memory growth across requests because an instance that survives many calls can reveal leaks that a short local test misses. Align connection pools with the maximum instance count so a scale-out event does not overwhelm the database. Revisit limits after traffic or dependency capacity changes.

Confirm that request logs include revision, region, route, status, latency, and correlation IDs. Check that failed startup, secret access, and dependency errors are visible to the owning team. Keep logs redacted and restrict access to payloads. Verify authentication at the public boundary and confirm that internal admin routes are not reachable through a default path. A successful deploy command is not evidence that the right users can reach the right operations.

Run smoke tests for the homepage, authentication, checkout or subscription state, webhook receipt, DNS tool, and the Resources hub when those paths are part of the release. Exercise an error response and a timeout path so alerting is not theoretical. Compare the canary's metrics with the previous revision rather than looking only for an absolute threshold.

Record the source revision, image digest, deployed revision, configuration versions, migrations applied, traffic change, smoke-test result, and rollback owner. This can be a release note or deployment record, but it should be searchable when an incident starts. Note any known risk, such as a provider with a narrow rate limit or a migration that requires a later cleanup step.

A dependable Cloud Run release is a controlled change: reproducible image, explicit configuration, bounded startup, compatible data changes, observable canary, and a fast rollback. Use the platform's revision history as an asset, not just a list of old containers. When each release leaves enough evidence to explain what changed, the team can move quickly without guessing which tool or secret broke production.

A release checklist is incomplete until an operator can move traffic back to the previous revision and confirm the old configuration still works. Record the revision, image digest, environment and secret versions, migration state, smoke-test URLs, and rollback owner. Keep database changes backward compatible during the overlap window. This evidence makes a failed deploy recoverable in minutes and protects the authentication, billing, webhook, and tool paths that users rely on.

Build an immutable image, inject public build arguments at build time, and bind server secrets by name and version at runtime. Define the service account, port, timeout, concurrency, scaling limits, startup probe, and traffic strategy in the deployment record. Keep database migrations backward compatible while old and new revisions overlap.

Smoke-test the homepage, authentication, checkout, webhook receipt, DNS tool, Resources hub, and one error path on the canary revision. Compare startup time, status codes, latency, logs, dependency access, secret references, and revision health with the previous revision. Do not promote a revision because its root route returns 200 while a changed business path is failing.

Move traffic gradually when the release is risky and keep the previous revision available. Record image digest, configuration versions, migration state, smoke-test results, owner, and rollback command. If the revision is unhealthy, restore traffic first, then investigate. Never edit a running container or delete the known-good revision before the release window closes.

Use Cloud Run revision, traffic, container runtime, Secret Manager, and deployment documentation. Keep the service's required environment variables and rollback procedure versioned with the application.