🚨 Pulumi Error: 'failed to decrypt configuration value' — Cause, Fix, and Troubleshooting Guide

Overview

error: failed to decrypt configuration value appears when Pulumi has an encrypted secret in Pulumi.<stack>.yaml but cannot decrypt it with the secrets manager currently configured for the stack. Every stack has a secrets provider — a passphrase, a cloud KMS key, or the Pulumi Cloud service — and each encrypted config value carries an encryptedkey/ciphertext tied to that provider. If the provider Pulumi resolves at runtime does not match the one that encrypted the value, decryption fails.

The message typically reads:

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

Or, for a KMS/cloud-backed stack:

error: failed to decrypt configuration value: decrypting: rpc error: code = InvalidArgument

This is not corruption of your infrastructure — it is a key/provider mismatch. The ciphertext is fine; Pulumi just does not have the right key to open it.

Symptoms

• Any command that reads config (pulumi preview, pulumi up, pulumi config) fails with failed to decrypt configuration value.
• The message mentions incorrect passphrase or references KMS/cloud decrypt errors.
• Happens after cloning a repo on a new machine, in CI, or after copying config between stacks.
• pulumi config --show-secrets fails, but non-secret operations may still work.
• Occurs right after changing secretsprovider or rotating a passphrase/KMS key.

Common Root Causes

1. Wrong or missing passphrase

The stack uses the passphrase secrets provider and PULUMI_CONFIG_PASSPHRASE is unset, empty, or different from the one used to encrypt.

error: constructing secrets manager of type "passphrase": ... incorrect passphrase

2. Config copied from a different stack

Someone pasted an encrypted secure: value from Pulumi.prod.yaml into Pulumi.dev.yaml. Each stack’s ciphertext is bound to that stack’s data key, so the copy cannot be decrypted.

config:
  myproject:dbPassword:
    secure: AAABAK1p...   # encrypted for a *different* stack

3. Secrets provider mismatch

The stack was created with a cloud provider (awskms://, azurekeyvault://, gcpkms://, or Pulumi Cloud) but the current environment resolves a different one — e.g. local runs assume passphrase while the config was encrypted with KMS.

4. Rotated or deleted KMS key / lost passphrase

The KMS key was disabled, deleted, or the caller lost kms:Decrypt; or the original passphrase is simply gone. The ciphertext is now unrecoverable without the key.

5. Corrupted encryptedkey in the stack file

A bad merge conflict or manual edit mangled the encryptedkey/secretsprovider fields at the top of Pulumi.<stack>.yaml.

How to Diagnose

Confirm the stack’s declared secrets provider:

pulumi stack select dev
grep -E 'secretsprovider|encryptedkey' Pulumi.dev.yaml

Check whether the passphrase env var is set (for passphrase stacks):

echo "${PULUMI_CONFIG_PASSPHRASE:-<unset>}"

Try reading just the secrets to reproduce cleanly:

pulumi config --show-secrets

For a KMS-backed stack, confirm you can actually use the key with the same identity Pulumi uses:

aws sts get-caller-identity
aws kms describe-key --key-id alias/pulumi-dev --region us-east-1

If describe-key or a test kms:Decrypt is denied, that is your root cause.

Fixes

Cause 1 — wrong passphrase: Set the correct passphrase and re-run. Prefer a file so it is not in shell history:

export PULUMI_CONFIG_PASSPHRASE='the-correct-passphrase'
# or
export PULUMI_CONFIG_PASSPHRASE_FILE=~/.pulumi-dev-passphrase
pulumi config --show-secrets

Cause 2 — copied config: Remove the pasted value and re-set the secret on the target stack so it is encrypted with that stack’s key:

pulumi config rm myproject:dbPassword
pulumi config set myproject:dbPassword 's3cr3t' --secret

Cause 3 — provider mismatch: Point the stack at the provider that actually encrypted the values. If you intend to switch providers, use pulumi stack change-secrets-provider (this re-encrypts all secrets):

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

Cause 4 — rotated/deleted key: If the key or passphrase is truly gone, the ciphertext cannot be recovered — re-set every secret from source-of-truth values after restoring a working provider. Re-enable a disabled KMS key or grant kms:Decrypt if the key still exists.

Cause 5 — corrupted stack file: Restore Pulumi.<stack>.yaml from version control so the secretsprovider/encryptedkey header is intact, then re-run.

git checkout -- Pulumi.dev.yaml

What to Watch Out For

• Never copy secure: values between stack files — each is bound to its stack’s data key. Re-set the secret instead.
• Store passphrases in a secrets manager, not in shared docs; a lost passphrase means unrecoverable config.
• Commit Pulumi.<stack>.yaml (the encrypted config is safe to commit) so the encryptedkey header is versioned and merge conflicts are visible.
• In CI, inject PULUMI_CONFIG_PASSPHRASE (or KMS credentials) as a secret env var — an unset passphrase is the #1 cause of this in pipelines.
• Prefer cloud KMS or Pulumi Cloud for team stacks so decryption is tied to IAM, not a shared string.
• Use pulumi stack change-secrets-provider to migrate providers — never hand-edit encryptedkey.

Related Guides

• Managing Secrets in Infrastructure as Code
• Pulumi Error: ‘inputs to import do not match’ — Troubleshooting Guide
• GitOps for Infrastructure Explained