🧱 Pulumi Error: 'the stack's secrets provider does not match' the Configured One

Exact Error Message

error: getting secrets manager: the stack's secrets provider does not match
the specified provider: the stack "prod" was created with secrets provider
"awskms://alias/pulumi-old?region=us-east-1" but the configured secrets
provider is "awskms://alias/pulumi-new?region=us-east-1"

error: constructing secrets manager: secrets provider mismatch

The passphrase-vs-cloud variant reads:

error: the stack's secrets provider does not match the specified provider:
expected "passphrase" but got "awskms://..."

What It Means

A Pulumi stack records the secrets provider that encrypted its secrets in two places: the secretsprovider (and encryptedkey/encryptionsalt) fields in Pulumi.<stack>.yaml, and the secrets_providers block inside the stack’s state/checkpoint. On every operation Pulumi checks that these agree before it tries to decrypt anything.

This error means the two no longer match — for example, the config file was edited to point at a new KMS key or switched from passphrase to KMS, but the state still expects the original provider. Pulumi refuses to guess, because using the wrong provider would fail to decrypt existing secrets (or silently mis-handle them). It is a consistency guard, not a broken key.

Common Causes

• Someone hand-edited secretsprovider in Pulumi.<stack>.yaml instead of using pulumi stack change-secrets-provider.
• The stack was migrated between backends and the config file’s provider URL was updated but state was not re-encrypted.
• A Pulumi.<stack>.yaml from a different stack/environment was copied over.
• Switching a stack from the default passphrase provider to KMS (or vice versa) without the migration command.
• A KMS alias was re-pointed to a new key, changing the effective provider URL.

Diagnostic Commands

See the provider the state expects:

pulumi stack export | jq '.deployment.secrets_providers'

See the provider the config file specifies:

grep -A2 secretsprovider Pulumi.prod.yaml

Confirm which stack you are actually operating on:

pulumi stack ls

Check that your identity can reach both the old and new KMS keys if migrating:

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

Step-by-Step Resolution

1. Decide the source of truth. If the config file was edited by mistake, revert it to the provider recorded in state:

git checkout -- Pulumi.prod.yaml
pulumi preview --stack prod

2. If you genuinely intend to move to a new provider, use the migration command — this re-encrypts all secrets and updates both config and state atomically. The old provider must still be reachable so Pulumi can decrypt first:

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

3. To move to the passphrase provider instead, pass the literal passphrase and set the new passphrase:

export PULUMI_CONFIG_PASSPHRASE='new-strong-passphrase'
pulumi stack change-secrets-provider passphrase --stack prod

4. If the config file was copied from another environment, restore the correct file for this stack rather than migrating.

5. Verify config now decrypts cleanly under the reconciled provider:

pulumi config --stack prod --show-secrets

6. Re-run the original command:

pulumi up --stack prod

Prevention

• Never edit secretsprovider, encryptedkey, or encryptionsalt by hand — always use pulumi stack change-secrets-provider.
• Keep the old provider/key available until the migration completes; the command must decrypt with the old key before re-encrypting.
• Use per-stack config files and avoid copying Pulumi.<stack>.yaml between environments.
• Point KMS aliases at stable keys, and migrate deliberately rather than re-aliasing under a running stack.
• Commit the migration in its own change so reviewers can see the provider transition.

Related Errors

• could not decrypt configuration value — the provider matches but the key/passphrase is wrong.
• passphrase must be set with PULUMI_CONFIG_PASSPHRASE — the passphrase provider with no passphrase supplied.
• AccessDeniedException from KMS — an IAM issue reaching the key during migration.
• getting secrets manager failures generally — the umbrella category this mismatch falls under.

Frequently Asked Questions

How do I switch secrets providers the correct way? Run pulumi stack change-secrets-provider <new-provider>. It decrypts every secret with the current provider and re-encrypts under the new one, updating both the config file and state so they stay in sync.

Why not just edit Pulumi.<stack>.yaml to the new provider? Because the state still records the old provider and the secrets are still encrypted with the old key. Editing only the config file produces exactly this mismatch error.

Do I need access to the old key during migration? Yes. Pulumi must decrypt existing secrets with the old provider before re-encrypting, so both old and new keys (or the old passphrase) must be available at migration time.

Can this happen from a bad merge? Yes — a merge that pulls in another environment’s Pulumi.<stack>.yaml will change the provider URL. Restore the correct file for the stack instead of migrating. Reusable secrets-migration checklists are in the prompt library.

Where can I read related fixes? Browse the full Pulumi guides for more secrets and state troubleshooting.