In the docs I'm not finding any detailed reference to how the state is actually organized. I know that with TF there's a good amount of up-front consideration necessary for how the code base is organized to avoid issues with blast radius when doing different operations (e.g. https://blog.gruntwork.io/how-to-manage-terraform-state-28f5697e68fa?gi=a302ddf41849). Is that still a necessary consideration in Pulumi?

There's a few references in the docs around Stacks and Projects: • Organizing Stacks and Projects: https://www.pulumi.com/docs/intro/concepts/organizing-stacks-projects/ • Stacks: https://www.pulumi.com/docs/intro/concepts/stack/ • Projects: https://www.pulumi.com/docs/intro/concepts/project/ • State and Backends: https://www.pulumi.com/docs/intro/concepts/state/ In general, we aim to make it so you shouldn't have to think about state and backends - you can just use the default Pulumi Service. At that point you just create a Project per codebase you want to manage (and version), and a Stack per isolated deployment (dev, prod, etc.) of a Project. If you want to manage things in your own local or S3 backend there are more details you have to think about - but the same ideas all apply.

Yeah, I'm planning on using the S3 backend so wanted to make sure I don't shoot myself in the foot with state boundaries.