🧱 Pulumi Error: 'could not decrypt configuration value' Wrong Passphrase or Secrets Change

Exact Error Message

error: constructing secrets manager of type "passphrase": could not decrypt
configuration value: incorrect passphrase, please set PULUMI_CONFIG_PASSPHRASE
to the correct passphrase or use PULUMI_CONFIG_PASSPHRASE_FILE

error: getting secrets manager: passphrase must be set with
PULUMI_CONFIG_PASSPHRASE or PULUMI_CONFIG_PASSPHRASE_FILE environment variables

With a cloud KMS secrets provider you may instead see:

error: could not decrypt configuration value 'db:password': decrypting: AccessDeniedException:
The ciphertext refers to a customer master key that does not exist, does not
exist in this region, or you are not allowed to access.

What It Means

Pulumi encrypts values marked as secrets in your Pulumi.<stack>.yaml file. Each stack records which secrets provider encrypted those values — the default passphrase provider, or a cloud KMS/Key Vault/GCP KMS key. When you run a command that must read config (pulumi up, preview, config get), Pulumi reconstructs that secrets manager and decrypts the values.

This error means the decryption inputs no longer match what encrypted the data: a wrong or missing PULUMI_CONFIG_PASSPHRASE, a KMS key that was deleted/rotated/moved to another region, or credentials without permission to use the key. The ciphertext in the stack file is intact — Pulumi simply cannot unlock it.

Common Causes

• PULUMI_CONFIG_PASSPHRASE is unset, empty, or different from the one used when the secret was set.
• A CI job uses a different passphrase (or a stale secret) than a developer’s laptop used originally.
• The cloud KMS key referenced by encryptionsalt/encryptedkey was deleted, disabled, or rotated with material removed.
• Running against the wrong AWS region/account so the KMS key ARN cannot be resolved.
• The stack was copied between backends and the secretsprovider in Pulumi.<stack>.yaml no longer matches available keys.

Diagnostic Commands

Confirm which secrets provider the stack expects:

pulumi stack export | jq '.deployment.secrets_providers'

Check the stack config file for the encryption metadata:

cat Pulumi.prod.yaml

Verify the passphrase environment is actually set in the current shell/CI context:

echo "PASSPHRASE set: ${PULUMI_CONFIG_PASSPHRASE:+yes}"

For a KMS provider, confirm the identity can use the key:

aws kms describe-key --key-id alias/pulumi-prod --region us-east-1

Step-by-Step Resolution

1. For the passphrase provider, set the correct passphrase and retry. Use PULUMI_CONFIG_PASSPHRASE_FILE to avoid shell history leaks:

export PULUMI_CONFIG_PASSPHRASE_FILE=~/.pulumi-passphrases/prod
pulumi config get db:password --stack prod

2. If you genuinely lost the passphrase, the encrypted values cannot be recovered — re-set each secret with a new passphrase you control:

export PULUMI_CONFIG_PASSPHRASE='new-strong-passphrase'
pulumi config set --secret db:password 's3cr3t' --stack prod

3. For a KMS provider, point your CLI at the correct account/region and confirm access, then re-run:

aws sts get-caller-identity
pulumi preview --stack prod

4. If the KMS key was rotated or replaced, migrate the stack’s secrets to the new key with pulumi stack change-secrets-provider:

pulumi stack change-secrets-provider "awskms://alias/pulumi-prod-v2?region=us-east-1"

5. In CI, inject the passphrase as a masked secret and confirm it reaches the runner:

pulumi login && pulumi config --stack prod   # should list values, not error

6. Re-run the original command to confirm decryption now succeeds:

pulumi up --stack prod

Prevention

• Store the passphrase in a team secrets manager (Vault, 1Password, CI secret store), never only on one laptop.
• Prefer a cloud KMS secrets provider for shared stacks so access is IAM-controlled and auditable rather than a single shared string.
• Enable automatic KMS key rotation that preserves old key material, and never delete a key a live stack still references.
• Keep PULUMI_CONFIG_PASSPHRASE_FILE out of version control and mount it at runtime.
• Document each stack’s secrets provider in your runbook so region/account mismatches are caught fast.

Related Errors

• the stack's secrets provider does not match — the configured provider differs from the stack’s recorded one.
• passphrase must be set with PULUMI_CONFIG_PASSPHRASE — the variable is entirely missing, not merely wrong.
• AccessDeniedException from KMS — an IAM permission issue on the key rather than bad ciphertext.
• could not decrypt config value on pulumi stack export — the same root cause surfacing during export.

Frequently Asked Questions

Can I recover secrets if I lost the passphrase? No. The passphrase provider uses your passphrase as the key, so a lost passphrase means the ciphertext is unrecoverable — you must re-set each secret with a new passphrase.

Why does it work locally but fail in CI? The CI runner almost certainly has a different or missing PULUMI_CONFIG_PASSPHRASE. Inject it as a masked pipeline secret and verify with pulumi config before the deploy step.

How do I switch from a passphrase to KMS without losing values? Run pulumi stack change-secrets-provider with the new KMS URL while the old passphrase is still valid; Pulumi re-encrypts all secrets under the new provider in place.

Does this error mean my state is corrupt? No. The encrypted values are intact; only the decryption inputs are wrong. Fixing the passphrase or key access resolves it without touching state. Ready-made secret-handling patterns live in the prompt library.

Where are more config and secrets fixes? See the complete Pulumi guides for related troubleshooting.