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

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?