Hey 👋 I am interested in implementing Pulumi projects and stacks and wanted to introduce a super "DRY (Do not Repeat Yourself)" setup that takes advantages of different stacks. Context on our use case for DRY: We have customers that we provision resources for. These resources are the same for all customers (with some variable differences), each customer will have 1 or 2 environments (I.E sandbox and/or production). Each environment is the same with some variable differences. I would ideally like each component for that environment (i.e VPC) to be a stack. I would like to have a single repository that holds the code for all the customers, but each customer to be its own project. To try and visualise an ideal repo setup:

.
└── customer
    ├── common
    │   └── route53
    │       └── main.go
    ├── env
    │   ├── eks
    │   │   └── main.go
    │   └── vpc
    │       └── main.go
    ├── pulumi.customerA.yaml <--- Variables that define some customer values and both sandbox and production values.
    └── pulumi.customerB.yaml

The project file,

Pulumi.yaml

has a

config

section that can be applied to all stacks. You can override these values in the stack

pulumi.customerA.yaml

files as well.

Yeah I think having a customer on its own stack is a better idea. However, how would a single stack for a customer perform when there are ~50 packages being used per environment, and if the customer has 2 environments it will be referencing 100 packages. Would this slow down the speed of making a changes. For example, I am updating a s3 bucket to add a policy, would the full stack need to perform a refresh just for a policy update to a bucket?

I'm not sure I follow. By packages, what are you referring to? Each stack would have its own resource graph, e.g. if each customer has their own s3 bucket, each stack has an s3 bucket, and a policy update would have to happen to all of them. These deployments could be run in parallel. If you are saying you have shared resources between stacks, that's a slightly different pattern you're asking for, and you want a "shared" infrastructure stack that other "child" stacks can reference.

> By packages, what are you referring to? I am still new to the Pulumi lingo, but I am using package in replacement of module as you would in terraform (if you are familiar with tf)

You may want to check out these documents if you haven't already, they may answer some of your questions, and provide examples for your use case. • https://www.pulumi.com/docs/concepts/ • https://www.pulumi.com/docs/using-pulumi/organizing-projects-stacks/ • https://www.pulumi.com/blog/iac-recommended-practices-code-organization-and-stacks/

Thank you, I will definitely review the links you have provided.

That being said, I think if you read through the various use cases and options, you might find a pattern that already fits your needs within the Pulumi constructs, e.g. projects/stacks.

Might be a stupid question, but would a stack need to be in a single folder?

The minimum/expected configuration of a stack is just the configuration, e.g. your customer YAMLs. So I think your layout works within Pulumi design concepts, yes.

Cool, in that case if I were to make a change to

eks

will pulumi only preview/apply eks?

Pulumi, like terraform uses a "desired state" model, so it compares the previous state to the new desired state, calculates the difference and uses the providers to apply the changes (yes, only the what has changed). Because of the asynchronous design, and inferred, or explicitly declared relationships in the resource graph, these operations are optimized to run in parallel by the Pulumi engine.

Thank you for the help! I might be back with more questions 😅