Hi all, Bit of a long post, but I am trying to figure out the best way to organize a dynamic set of Pulumi projects and stacks. I am planning to use Pulumi to deploy resources to Kubernetes and cloud providers on behalf of our customers. Some of our customers pay us to manage their infrastructure, and some of them prefer to manage it themselves. The first group deploy workloads to infrastructure that we manage, while the second group will need to execute pulumi projects using their own cloud credentials. There are serveral apps and microservices that customers will want to deploy, and a few of these will be deployed multiple times per customer. A dashboard app is first deployed for a customer. The dashboard will make use of the pulumi automation API to deploy additional apps and microservices at the customers request. I am not sure how best to organize the projects and stacks in Pulumi. Option 1: One project per customer workload, with one stack per environment. /my-organization/infra/qa (for our infrastructure) /my-organization/infra/prod (for our infrastructure) /my-organization/customer-a-dashboard/qa /my-organization/customer-a-dashboard/prod /my-organization/customer-a-app1/qa /my-organization/customer-a-app1/prod /my-organization/customer-a-app2/qa /my-organization/customer-a-app2/prod /my-organization/customer-b-app1/qa /my-organization/customer-b-app1/prod /my-organization/customer-b-app2/qa /my-organization/customer-b-app2/prod Each time a customer deploys a new app, a new project would be created. When a customer removes an app, the project would be destroyed. Option 2: One project per customer, with one stack per environment. /my-organization/infra/qa (for our infrastructure) /my-organization/infra/prod (for our infrastructure) /my-organization/customer-a/qa /my-organization/customer-a/prod /my-organization/customer-b/qa /my-organization/customer-b/prod

If the 2nd group are managing their own infrastructure and Pulumi projects, wouldn't they need their own Pulumi organization, API token, etc.? This case sounds like it should be a completely separate fork of the code, with no overlap of project, stacks or infrastructure.

Yes. Option 1 and 2 are for customers where we manage. The hope would be that we could transfer stacks to their org if they wanted to take over.

Okay, so option 1 and option 2 are both for the first group. That works. If the only difference is whether to use projects per customer or projects per customer group, then I think you should ask yourself about deployment cycles and code-change cycles. If two customers should always have the same Pulumi code, and will update their /my-organization/infra/... projects at the same time (because you get to say when they're updated), then you might not want separate projects per customer at all; separate (groups of) stacks might be enough. If one customer may have completely separate code-change/deployment cycles for different apps, then option 2 won't work at all. You'd need option 1, or some variation of it.

Ok. That helps. Thank you.