This message was deleted.

That vastly depends on the trust you have for anyone that is going to make changes to the repo. having a single repo for all that is a bit dangerous in my opinion. I am currently changing all of our infra from terraform to pulumi and I went with dividing the repos in multi-stacks depending on the purpose. The reason was just that I am afraid someone will make a mistake in one resource impacting some other more important resource. With multi-stack this is minimized. For instance, I have this main repo where I spin up the main stuff (vpc, subnets, networking,etc) and then multiple other repos for things like new services on lambda, api gateways etc. The idea is the main repo wont need to be updated often unless necessary, otherwise we call that repo' libraries in case we want to interact with those resources (vpc, routing etc)

In our org, we have a single stack. Every user with enough permissions is allowed to create repository and then

pulumi up

queries the list of repos and updates the configuration. On top of that, there is a project-specific configuration for special projects.

https://www.pulumi.com/blog/managing-github-with-pulumi/ <- @shy-arm-32391 wrote a blog about how we manage github with pulumi at pulumi, might be a good read first

It's worth noting that we at Pulumi do not put the repos themselves under IaC, but we do manage branch protection, permissions, etc. with Pulumi.

@fierce-xylophone-92490 The Pulumiverse community manages the org via Pulumi: https://github.com/pulumiverse/infra

Thank you everyone!! @stocky-restaurant-98004 that is really interesting. Do you happen to know what advantage the Pulumi company saw in not creating repos with iac? How does your pulumi code discover the repos to apply branch permissions to?

We create too many repos to make folks go through IaC for everything. You also typically don't want to delete repos as you would cloud resources (although

retainOnDelete

can certainly help). I'm not sure how the branch perms are managed, but we use an external YAML file to manage teams and repo access.

@flaky-arm-38472 in your example above with the VPC repo, how exactly did your dependent repos (like the Lambda one) receive the VPC and subnet info from the main VPC stack? Did you use stack outputs & references, just copied values into the stack config, or something else?

@magnificent-glass-81378 We have procedures enforcing strict naming conventions so is easier for us to use the Pulumi helper methods for searching resources (i.e LookupVpc) , but we also read the main/core state file from other repositories if we need to know the state of a specific resource.

OK cool, so it sounds like you're using a combination of data queries and stack outputs. Thanks!