Pulumi Secrets Fail to Decrypt After a Stack Moves from the Local Backend to Pulumi Cloud

Question

A stack prototyped with pulumi login --local encrypts secrets with a key held by the local file backend. When that stack is adopted under Pulumi Cloud, the existing ciphertext stays bound to the original key material, so secret reads and deployments fail until each value is re-encrypted under the new backend's key.Two documented constraints frame the decision. pulumi stack change-secrets-provider, available since CLI v3.40, rotates the secrets provider in place, but only while the source backend is still logged in and reachable — an exported stack file alone is not enough. External providers such as AWS KMS, Azure Key Vault, or HashiCorp Vault avoid the backend-bound key entirely, but only if configured before the first secret is set.As of the v3.x CLI line — worth re-checking against current release notes — no automatic migration path exists for a local-only stack whose original key is gone.For a team standardizing on Pulumi Cloud after local development, the unresolved points are:Is change-secrets-provider the intended local-to-cloud path, or is re-setting each secret with config set --secret still the documented fallback?Does an exported stack file carry enough key material for offline re-encryption, or is the source backend required live?Should a passphrase- or KMS-backed provider be set before the first secret, so future backend moves stay lossless?

Tasadduq Burney · Answer

Why decryption failsWhen a stack is created with pulumi login --local, Pulumi encrypts every secret using a key that lives only in the local file‑backend store. The ciphertext stored in the stack file is bound to that key. If the stack is later adopted under Pulumi Cloud, the backend changes but the original key is no longer available, so Pulumi cannot decrypt the existing ciphertext and secret reads (or pulumi up) fail.
Confirmed facts
The command pulumi stack change-secrets-provider (available since CLI v3.40) can rotate the secrets provider in place, but it requires the stack to remain logged into the source backend at the time of execution.
An exported stack file (pulumi stack export) does **not** contain the local backend’s encryption key, so without an active local backend the command cannot re‑encrypt the ciphertext.
If the source backend is unreachable, the only practical fallback is to re‑enter each secret with pulumi config set --secret  , which writes new ciphertext under the destination provider’s key.
To avoid loss of secrets during future backend moves, configure a passphrase‑ or KMS‑backed secrets provider **before** any secret is set; such providers encrypt with a key that survives backend changes.

Steps for this case
Check whether the local backend is still reachable: run pulumi whoami and verify you see a login to the local backend.
If reachable:
  pulumi stack select 
pulumi stack change-secrets-provider --provider=passphrase   # or your desired provider

Then run pulumi preview or pulumi up to confirm secrets decrypt correctly.
If NOT reachable:
  You must re‑enter each secret:
  pulumi stack select 
pulumi config set --secret  
  # repeat for every secret

After all secrets are reset, verify with pulumi preview.

Missing diagnostic detailIs the local backend still reachable (can you run pulumi whoami and see you are logged in to the local file backend)? The answer determines whether you can use change-secrets-provider or must fall back to re‑entering secrets.

Pulumi Secrets Fail to Decrypt After a Stack Moves from the Local Backend to Pulumi Cloud

1 answer

Why decryption fails

Confirmed facts

Steps for this case

Missing diagnostic detail

Your perspective belongs here.

0 question comments