This message was deleted.

I’m not sure I understand the question/context. Are you saying you have a storage container in Azure that was created by and is managed by a Pulumi stack?

I mean blob storage is where the state is stored... A self hosted backend.

So, to do a

pulumi up

a stack has to be init-ed or selected, which requires being able to login to the state backend. If the intent is for individuals to have their own stacks, they could use the “local” backend (https://www.pulumi.com/docs/intro/concepts/state/#logging-into-the-local-filesystem-backend). Otherwise, you would need to set up another storage container for the devs to use if the goal is to not use the production storage.

Hmm... That feels like a major limitation vs Terraform. The idea is that there is a single container in each environment (dev, uat, prod), that contains the shared infrastructure that they need to reference, and therefore the stack that a team would create for a service would need to be created in there. If what you're saying is correct, then the devs need direct access to the production container to create the stack there, which is less than ideal.

Yeah, I see it the same way as you do - its a bit strange to have to init each stack locally before I’m able to hand it over to our CI/CD System…

Just to clarify, in Pulumi, the stack’s state is a fundamental artifact and thus Pulumi needs to be able to update it to match the desired state defined in the project’s code when a

pulumi up

is run. So, if the intent is to have multiple developers working against the same stack (i.e. a given instantiation of a project’s declared resources), those developers need to be able to access the state backend. Otherwise, devs can work against their own stacks as they develop the code before committing it to source control. And, then the CI/CD can deploy the staging, test, prod stacks as the code is committed. FWIW, state management is one of the advantages of the Pulumi SaaS since it takes care of all that for you and allows you to manage user (i.e. devs, CI/CD systems) read and/or write access to specific stacks.

I agree and fully understand for most of the stacks. But we don’t want multiple developers to have access to the “production” stack - this stack “must” exclusively be managed by CI/CD automation. But as it is now, I have to manually set it up once and then hand over. I guess I would be able to do it with the automation API and I might look into it in the near future…

@prehistoric-nail-50687 I have a solution for this now thanks to some help from Pulumi. I'm going to get it in place and then blog about. In essence, it's using the fact that the stack YAML in your project is separate to the state backend, so you can test to see if the state back end knows about your stack, and do an init if not. There's a couple of nuances around secrets providers that I'm working through, but the short story is that it looks like it's doable. @witty-candle-66007 this is explicitly about stacks that 100% managed by CI/CD pipelines, that developers should never have access to, but should be able to generate new ones of easily.

thanks, but I’m not using GH-Actions 🙂

essentially all it's doing is:

pulumi login
pulumi stack select {stackname}
if (err)
  pulumi stack init {stackname}