Hello everyone! I am a Platform Engineer at Veeam and we are considering Pulumi Cloud for our platform. We've signed up and created an org. Are there any best practices / docs / guidelines on how to configure and manage Pulumi Cloud for a large org? How should we split projects? How should we manage env stacks (dev / prod) vs stacks used for feature development by engineers? Did some searching but didn't find much.

The best always-applies guideline I have is: if you'd want to deploy / update / destroy resources at different times, then they should be in different projects.

Thanks for that. What about devs that use pulumi cloud for their personal deployments? For example, every engineer has their own azure subscription so there are no naming conflicts there. But they all use the same pulumi org and as such we get errors like "this stack already exists". We thought about prefixing the stacks with the engineer's GitHub username but that would require us to maintain

Pulumi.<dev-specific-stack-name>.yaml

config files for each dev. Feels like we need another layer of abstraction to avoid name conflicts but can't imagine we're the first to hit this issue.

Any number of people can use a single stack, but it's the shared stack, and you should be on the same code branch. If you want parallel development, you'll need per-developer stacks. You can use Pulumi Cloud for that, you'll just need to create the stack. You don't particularly need a naming convention, you almost certainly shouldn't be sharing those per-developer stacks: leave them out of the code base. You can also use Review Stacks for this. If you've set up Pulumi Deployments, they're ideal.

Thank you! I'll take a look into those options.

You don't particularly need a naming convention, you almost certainly shouldn't be sharing those per-developer stacks: leave them out of the code base.

Fair but that means each developer needs their own config file that needs to sync with the other env stacks before they begin development. Wondering if creating a project per dev is a good approach... then no name name clashes in pulumi cloud and devs can still use esc environments for shared secrets

Not sure what in a config file would need to sync. Yes you'd want to ensure that there aren't clashes if the same stack is created in the project, but (at least for me) that's a business process: when creating a stack, make sure that it doesn't exist already.

Another option would be to require devs to use their personal orgs

some tried but we want to use esc for sharing secrets in a centralized fashion and you cannot access esc envs across orgs

In my experience, per-dev stacks are not needed.

how so? let me try to layout our setup.. maybe I'm not communicating this properly... We have a repo that has a pulumi project in it. It deploys our Azure infrastructure. If a developer wants to build something, they first need to deploy the infra to their personal azure subscription. When a developer runs

pulumi up -y

this in turn creates a stack in the org / project setup in companies org. The

Pulumi.personal.yaml

config file name needs to match the name of the stack being deployed. Therefore, every developer needs to have a different config file for their personal stacks (

Pulumi.dp-personal.yaml

). My goal was avoid that in someway. If we change some config in say the

Pulumi.dev.yaml

we'll need developers to make that change in their personal config files as well. Does that make sense? Or are we using pulumi incorrectly? Maybe you're suggesting personal devs don't use pulumi cloud at all? 🤔

Are ESC orgs the same as IAC orgs? If they are, then your conundrum is understandable. If they're separate, you might be able to use personal IAC orgs and the shared ESC org. I don't use ESC enough to know if this is feasible. If your infra needs to be completely replicated (e.g. you can't share VPC, DB server, etc.) then personal stacks is a reasonable approach. It'd be nice to be able to share all that, and use only just enough per-dev infrastructure (e.g. a pod in a k8s cluster) that you don't use Pulumi for it, but that's often not possible. Per-dev stacks can work even if the dev stack YAML files aren't in source control. The only time anyone else would want to interact with another person's stack would probably be to destroy it if they leave the company, and

pulumi destroy --stack myorg/theproj/thatdev

works fine for that. You might also want to investigate Review Stacks. They last as long as the related PR, so that might be perfect for per-unit-of-work stacks, even better than per-dev stacks.

ESC falls under a specific Pulumi org. Any project under the org can access an esc environment in that same organization.

they're separate, you might be able to use personal IAC orgs and the shared ESC org.

attempted this and did not work 😞

If your infra needs to be completely replicated (e.g. you can't share VPC, DB server, etc.) then personal stacks is a reasonable approach. It'd be nice to be able to share all that, and use only just enough per-dev infrastructure (e.g. a pod in a k8s cluster) that you don't use Pulumi for it, but that's often not possible.

I think we will eventually get there (costs will continue to rise if not) but currently we let every engineer use their own subscription with their own AKS cluster

Per-dev stacks can work even if the dev stack YAML files aren't in source control.

We ended up doing this.

Pulumi.dp-personal.yaml

and add

Pulumi.*-personal.yaml

to .gitignore. If we update a pulumi stack config file, folks just need to update their personal stack config file with the new config. I'll see if we can't leverage pulumi esc + imports to avoid this syncing problem. Instead of updating the config file. we update the shared esc config / secrets and imports will pull the latest every time a dev runs

pulumi up

.

You might also want to investigate Review Stacks. They last as long as the related PR, so that might be perfect for per-unit-of-work stacks, even better than per-dev stacks.

This feature looks great! We've been focused on shifting-left and this would help a ton in having infra stood up on each PR so we can test + merge quickly. @little-cartoon-10569 THANK YOU! Really appreciate you talking this through with me.

@thankful-painting-31068 I’m late to this comment after the holiday, but if I’m understanding you correctly--I think this could be achieved with a shared environment config for developer stacks by leveraging ESC. In our case, during onboarding each developer runs a script that generates their

Pulumi.myalias.yaml

config file, but the file generally looks like this in the basic case:

environment:
  - dev-stacks
config:
   # some custom, one-off stuff per-developer

Then, we maintain the

dev-stacks

environment separately and share this configuration across all the developer stacks. Quite a few devs run their own bespoke config on top of this, but it abstracts away a lot of the core config necessary that is shared across all developer environments. The generated, untracked

Pulumi.<alias>-dev.yaml

file approach you are suggesting makes sense to me. This is roughly how we do it. Highly recommend checking out review stacks as well if it is reasonable enough to deploy your service on every PR! It looks like you were headed down this path anyway, but just giving another data point based on what we are doing in-house!

Sorry - seeing this so late but the ESC approach is what we decided to go with. Thanks Devon!