No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

Does the encryptionsalt (In the `Pulumi.&lt;stack&gt;.yaml`) change every time you (re)create the project state, and is there a way to keep this static?

I'm using the password secrets provider and I recreate the state to spin up a local lab, but this is causing a load of needless changes in git

The salt will change if you regenerate the stack file - but its just YAML so you can store your salts in whatever manner is acceptable.

Generally if you're storing actual secrets in the pulumi config, then you would want the salts to change.

I'm not regenerating the stack file, I'm just clearing the state (Stored on the local filesystem)

I could just inject an empty salt into the config when spinning up I guess

The secrets aren't actually 'secret' as this is just for a lab where all passwords are generated etc.

But I'm also trying to make it emulate production processes as much as possible still

Personally I don't like relying on Pulumi for secrets, I use AWS Parameter Store, or Secrets Manager.

If you're committing your stack files to Git though, I wouldn't expect there to be huge or problematic changesets.

Well in production pulumi projects we use the GCP Secrets Manager secrets provider and Pulumi secrets, then we parse all of the config with Zod

But in this scenario, I have a monorepo of different Pulumi projects for Kubernetes, to provision a fully-functional gitops cluster. Every time I bootstrap it via. my CLI, the encryptionsalt changes on all the repos

I'll just add a step into the CLI to set the the encryptionsalt to something static :shrug:

&gt; Does the encryptionsalt (In the `Pulumi.&lt;stack&gt;.yaml`) change every time you (re)create the project state, and is there a way to keep this static?
It shouldn't this sounds like it might be a bug.
Are you removing the state by just deleting the state files, or running destroy and/or stack rm?