2. In relation to the above question: I suspect my scenario might be quite common for others too - is there a way to work with pulumi without making usage of stacks explicit? I suspect I might need to go with single stack per pulumi project (with one pulumi project/stack per my actual environment) and a necessity to always think about stacks will be unnecessary distraction.

It's totally fine to have a single stack per program - there shouldn't be much that gets in the way here. Is there anything in particular you are worried about?

Not a major issue but all these different slugs like project ID, stack ID and so on - it’s easy to get lost 🙂

@gifted-island-55702 It’s fine to do this — people do it all the time. The main disadvantages are that every time you update app code, you are potentially blowing away core infrastructure like your prod DB. There are other disadvantages, like the fact that it’s easier to spot errors in smaller plans, smaller plans are quicker to generate, etc. There isn’t really a concrete disadvantage to grouping resources by risk class, as it’s super easy to get stacks to communicate information between each other. So — up to you and your business objectives, but I personally would always split up a set of prod resources between stacks.

Thanks @creamy-potato-29402. My question was rather about having one pulumi program for all the deployment environments and having stack per environment (e.g. dev, staging, prod). What you are suggesting is to split resources of one environment (e.g. prod) into multiple pulumi programs to group resources by risk class, access restrictions etc. and I totally agree with such approach. My main concern is stack per env and how often it is really used that it is useful to make it explicit in every pulumi program/project instead of having an implicit default stack with an option to add more stacks if they are needed. I don’t think Terraform workspaces (a similar concept to pulumi stacks) is that useful and widely used due to the reasons I mentioned in https://pulumi-community.slack.com/archives/C84L4E3N1/p1546032487170300?thread_ts=1545945943.127500&cid=C84L4E3N1

@gifted-island-55702 hmm, so, if I understand you, I don’t know that you necessarily have to separate by region by stack, but in practice I would say it’s almost always a good idea. You want regions to be natural fault isolation boundaries.

Oh, that’s really interesting - using stack per cloud region - thanks!

And, FWIW, the k8s the prod way doc really shows off how Pulumi is really built with this idea in mind.

@creamy-potato-29402 I would definitely incorporate some of the information I got today (e.g. using stacks for deploying in different regions in https://pulumi.io/reference/stack.html) or more consistent usage of program vs project throughout the Concepts section of the docs. But I guess the most issues I had are because of my misunderstanding the design of pulumi. And definitely https://github.com/pulumi/pulumi/issues/2039 will make everything more clear 🙂

indeed.

Yes, it’s definitely challenging to write a doc for people new to your software when you know it so well and everything is so obvious because you created it 🙂

We’ll get somewhere good with it, but I think we’re still figuring it out. 🙂

Thank you @creamy-potato-29402 and @white-balloon-205 for your time and patience with my questions