Error: passphrase must be the same as the last time the stack was updated

Error: passphrase must be the same as the last time the stack was updated

TL;DR

You changed PULUMI_CONFIG_PASSPHRASE after the stack was created. The passphrase is baked into the state's encryption and cannot be rotated in place. Restore the old passphrase, or destroy and recreate the stack with the new one.

The error

error: passphrase must be the same as the last time the stack was updated

Fix it

1. Put the original passphrase back: export PULUMI_CONFIG_PASSPHRASE='[original passphrase]'.

   • Success check: pulumi preview works again.

2. If you must move to a new passphrase, plan a migration: pulumi stack export with the old passphrase to back up.

   • Success check: you have a restorable backup.

3. pulumi destroy --yes, then pulumi stack init a fresh stack (or re-init) with the new passphrase, and pulumi up.

   • Success check: the new stack encrypts with the new passphrase from birth.

4. Update every place the passphrase is stored (CI secrets, vault, team docs) so nobody reintroduces the old one.

   • Success check: all environments use the one current passphrase.

When to use this

You hit this after changing PULUMI_CONFIG_PASSPHRASE on an existing passphrase-encrypted stack.

When NOT to use this

Do not use this for a missing passphrase (passphrase must be set with ...). That is unset, not changed; just set it.

Compatibility

Pulumi CLI 3.x, passphrase secrets provider, self-managed backends.

Variants

• The same failure surfacing as a secrets-manager construction error mentioning the passphrase mismatch

Root cause

The data key that encrypts state is derived from the passphrase at stack creation. There is no re-key operation: a different passphrase derives a different key, which cannot decrypt the existing state.

Edge cases

• pulumi change-secrets-provider migrates between providers (e.g. passphrase to KMS), not between passphrases.
• If the old passphrase is lost entirely, the encrypted secrets in state are unrecoverable. Non-secret resources can still be adopted into a new stack via import.