A secret can be correctly stored in Secret Manager and still fail at Cloud Run startup. It can also rotate successfully in Secret Manager while an already-running application continues using an older value. Both outcomes make sense once you separate the deployment identity, the runtime service account, and the way the secret enters the container.
Cloud Run supports exposing a secret as an environment variable or mounting it as a file. Neither option is a complete rotation strategy on its own. The important question is when your application reads the value, how it handles a changed credential, and how you will roll back.
Understand the two identities
The deployer changes the Cloud Run service. The service identity, a service account, is used by the running container to access Google Cloud resources. Giving your personal account Secret Manager access does not grant that access to the service account. Google documents roles/secretmanager.secretAccessor for the runtime identity that needs to read the secret.
Inspect the service’s configured identity and the IAM policy for the intended secret. Prefer a dedicated service account and the narrowest practical secret scope. Deployment permissions are separate: the person or automation deploying the service also needs appropriate Cloud Run access and permission to use the selected service identity.
Compare the delivery modes
| Choice | When the value is read | Operational consequence |
|---|---|---|
| Environment variable | Resolved before an instance starts | Existing process environments do not update in place; Google recommends pinning a specific version. |
| Mounted secret file | Retrieved when the mounted value is read | Can support rotation, but the application must reread the file and handle access failures. |
For environment variables, failure to retrieve the secret prevents the instance from starting. For mounted secrets, Cloud Run does not perform the same startup-time retrieval check; a read can fail at runtime. During deployment, Cloud Run checks whether the configured service account can access the referenced secrets.
A mounted file is useful when the application can reload credentials. It does not rewrite a database client’s in-memory connection pool. If the application reads the file only once at boot, it behaves like a cached value until the process rereads it or restarts.
Use an explicit version for predictable deployments
Google recommends pinning the version for environment-variable secrets. For example, a service can deliberately use version 3 until a tested revision is ready to use version 4. The command below is a configuration-change example: replace the placeholders and review its impact before running it.
gcloud run services update YOUR_SERVICE --region YOUR_REGION --update-secrets=DB_PASSWORD=YOUR_SECRET:3For a file mount, the configuration names a path and secret version:
gcloud run services update YOUR_SERVICE --region YOUR_REGION --update-secrets=/etc/app-secrets/db-password=YOUR_SECRET:latestUse a dedicated mount directory. Review ownership and file access for your execution environment and container user. Google’s documentation distinguishes single-container first-generation deployments from other deployment types; do not assume a local filesystem ownership test exactly represents the deployed service.
Build the rotation sequence around the dependency
- Prepare the downstream system. Determine whether old and new credentials can overlap. A database or third-party API may impose its own rotation rules.
- Create the new secret version. Keep the previous version available for the defined rollback window, subject to your incident and security requirements.
- Test a revision or reload path. Verify the actual dependency call without logging the credential. A health check that only returns HTTP 200 may miss a broken database connection.
- Move traffic deliberately. Monitor startup failures, application error rates, and downstream authentication failures.
- Retire the old credential after validation. Confirm old instances or cached clients no longer depend on it before disabling it.
When revoking a compromised credential, incident containment can take priority over overlap and graceful rollback. Document that exception instead of assuming all rotations follow the same timing.
Make failures diagnosable without exposing secrets
Log the service revision, secret resource name where appropriate, version reference, and the category of the failure. Never log the secret payload. If you need community help, share whether you use an environment variable or file mount, the runtime service-account configuration, the generation and container layout, and the sanitized error.
Bring questions to the Google Cloud forum. For cross-cloud designs, keep provider-specific identity and refresh semantics explicit; similar product names do not imply identical behavior.
Sources and review
Reviewed against Google Cloud documentation on 11 September 2026. Command examples are illustrative and were not deployed as part of preparing this guide.