Cloud Run Secrets Missing After Deploy? Check Your Update Flag First

You've just pushed a new version of your Cloud Run service, perhaps adding a new feature or fixing a bug. The deployment went through without a hitch, gcloud reported success, and your service is running. But then, you notice critical parts of your application are silently failing: checkout flows are broken, or transactional emails aren't being sent. You check your logs, but there's no obvious crash, just a lack of expected activity. This insidious problem, where your cloud run secrets missing after deploy without any error message, can be hard to track down.

What Actually Happened: Our Silent Secret Wipe

We hit this exact scenario in our own production systems. We deployed one of our Cloud Run services using gcloud run deploy with the --set-secrets flag. That flag doesn't merge the secrets you name with the existing ones; it replaces the entire list. Our Stripe payment keys and transactional email secrets were silently wiped from the service's environment configuration. Nothing crashed; the service just stopped being able to process payments or send emails. The application kept running, but checkout and transactional email no longer worked.

This is exactly the kind of silent configuration issue Oculix helps teams diagnose.

How to Check if You Have the Same Problem

If your Cloud Run service is exhibiting silent failures after a deployment, especially related to external integrations that rely on secrets, here's how you can investigate if the --set-secrets flag is the culprit:

1. Inspect Your Current Service Configuration: First, get the YAML configuration for your currently deployed service. This will show you exactly what secrets are configured for your active revision.

gcloud run services describe SERVICE --region REGION --format=yaml ``` Look under spec.template.spec.containers and then within each container's env list for entries using valueFrom.secretKeyRef. Note down all the secrets you expect to see.

2. List Previous Revisions: Identify the revision that was running successfully before your latest deployment. You can list all revisions for your service:

gcloud run revisions list --service SERVICE --region REGION ``` Find the REVISION name of the last known good deployment.

3. Compare with a Known Good Revision: Now, describe the previous, working revision using its name:

gcloud run revisions describe REVISION --region REGION --format=yaml ``` Again, examine the spec.template.spec.containers and env sections for valueFrom.secretKeyRef entries. Compare this list of secrets with what you found in your current service configuration. If secrets are missing in the current configuration that were present in the previous one, you've likely found your problem.

The Fix and How to Prevent a Repeat

The root cause of our incident was the use of --set-secrets, which performs a replacement rather than a merge. The fix is straightforward: use --update-secrets instead. This flag is designed to merge new secret configurations with existing ones, preserving any secrets not explicitly mentioned in the command.

To restore your missing secrets, you can redeploy your service using gcloud run deploy SERVICE --region REGION and include all necessary secrets with the --update-secrets flag. For example, to update or add a secret named ENV_NAME referencing SECRET_NAME:latest:

gcloud run deploy SERVICE --region REGION --update-secrets=ENV_NAME=SECRET_NAME:latest

To prevent this from happening again, we've adopted a strict policy: always use --update-secrets when you intend to add or modify individual secrets. The --set-secrets (and similarly, --set-env-vars) flags are powerful but dangerous if you don't intend to completely overwrite your service's configuration. Our pre-deploy checklist now includes steps to verify the presence of all critical secrets, deploy with --update-secrets, compare the configuration before and after deployment, and smoke-test the service thoroughly.

Need a Second Pair of Eyes? Oculix Diagnostic Services

For early-stage SaaS teams facing exactly this kind of issue – where cloud run secrets missing after deploy causes silent outages – our Cloud Run secrets/env var diagnosis service provides a clear root cause and fix. Priced at $65, this service delivers a recorded video walkthrough or a written report detailing the problem and actionable steps for resolution. We work from read-only access to your Google Cloud project or a screen share session, and we never need access to your secret values themselves.

If you're grappling with a similar issue and can't pinpoint the root cause, Oculix is here to help. Don't let silent configuration issues or deployment mishaps consume your valuable time; a targeted diagnosis can get you back on track quickly.