This message was deleted.

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.