This message was deleted.

This is an excellent question. We don't currently have docs on the topic, but we should -- especially because stacks are so central to how Pulumi works. I'll make sure this is added to our near-term todos. Stacks are intentionally flexible, a bit like Git repos, so that you can choose to organize differently based on your scenario. We see a pretty broad range of approaches • For small teams, having a single stack that contains your app and its infra is a fine way to start; in that case, you'd then have a stack per environment (prod, stage, test, dev, etc), and perhaps per-region (prod-west, prod-east, etc). • For medium teams, folks often split around boundaries like what you suggest (infra, data, multiple app tiers), even if it's the same people managing the project. Similar to why you'd break things into multiple repos, this just helps to manage independent delivery cadences. • Finally, for large enterprise orgs, where infra/IT and dev are often entirely separate teams, stacks almost certainly follow this finer grained break-down, especially since usually any one team member won't have IAM permissions to manage the entire collection of resources in the stacks. I hope this helps -- in any case, we definitely need better docs here, and are happy to chat through details if it helps!

thanks for the reply Joe, something about having all the data resources in bed with the fast changing things makes me a bit nervous. I'd definitely feel better if they were in a separate stack/project. However, it seems from my brief testing that when you change a stack, the same code in the folder goes with it, so it seems multiple projects would be my best bet? And then print out the outputs from one and use that as a config into another? Example might be network/vpc/security groups in a project, ebs/managed disks in another, database in another etc, but eventually the compute layer would need those various bits of info, however querying the other projects and retrieving the outputs at runtime on the compute doesnt seem like it would be difficult. Am I making sense?

That makes perfect sense, and is what we see many users doing for exactly the reasons you cite. So, a common approach is something like

app/
    Pulumi.yaml
    ... app-level stuff that versions rapidly ...
    ... ephemeral in nature, easy to blow recreate ...
data/
    Pulumi.yaml
    ... data tier, protected resources, ...
    ... backed up, so not catastrophic if lost, but bad ...
infra/
    Pulumi.yaml
    ... very disruptive if lost, under lock and key ...

This is all great info, I really appreciate it. As a newcomer to the project (recommend to me by an engineer I highly respect) this was an area that had me a bit puzzled, so I think some more docs around the organization or larger projects would be helpful for others as well 👍

Absolutely, I filed https://github.com/pulumi/docs/issues/607 to do this. We'll definitely get something better here in the next week or so. In the meantime, don't hesitate to ask away if you have other questions! Hope you enjoy trying out Pulumi.