This message was deleted.

The advise I tend to give is: logically divide up your resources (networking, databases, application etc) into projects. Stacks should be equivalent to environments, so dev/staging/prod. When it comes to regions, You can use a provider for each region and and then set the provider for the resource

Thanks @brave-planet-10645 is there any good example showing that setup?

We have this one: https://github.com/pulumi/examples/tree/master/aws-stackreference-architecture It doesn't have multi-region, and it doesn't have multi stack, but the multi projects is what you're looking for really

Thanks that looks good. Are stacks conceptually just an overlay config to apply onto a project?

Without trying to hijack this conversation, I have a related question also... 🙂 How do workspaces fit into this idea? I have a stack that is going to be deployed per feature development for a repo, and I'm trying to figure out how to organize that. So I have two projects (one with shared resources and one with resources that will be deployed every time the request is made), then my stacks will determine environment. How would I organize the project that gets deployed per request? Just with naming conventions? Or should I use workspaces somehow?

You mean TF workspaces?

Ok thanks, so conceptually I could just use lots of projects to achieve what I want and have a default stack in most cases

Yes

Awesome, thanks.

Not by default. You should look at our automation api, which allows you to integrate your pulumi programs in an application. In this case you could have an application that would orchestrate your deployments like you've said.

Check #C01PF3E1B8V channel we've had a discussion about it not so long ago, scroll little bit up in history https://pulumi-community.slack.com/archives/C01PF3E1B8V/p1627281036093300

Thanks @great-sunset-355 will dig into it