Hey guys! We’re a small company that is evaluating using Pulumi to define and maintain our infra. Our systems differ a bit between environments (dev, prod, staging) and I read that using different stacks per environment is a common pattern. You use different configs per stack and then use those properties to ideally spin up the same infrastructure but with different configuration per environment. However as I said, our infrastructure currently differs between environment, and the underlaying structure of the resources that defines it, varies. For this reason, having multiple stacks doesn’t really add much value in our case. I know we can just

if/else

the creation of resources based on the current stack, etc, but I wonder if that’s a good pattern to follow? Or it would be much simpler to just have 1 stack and that’s it. I wonder if we are approaching the problem right, or we should find a better way. Thanks in advance

If you environments are reasonably-sized, there will probably be multiple projects per environment. Common patterns include: • a few single-stack projects for things that are supposed to be accessible to all projects (e.g. secrets for external resources, shared product-wide DNS, some logging resources, and more); • multi-stack projects for things that are mostly the same between environments (e.g. DB +logs +backups, CDNs, VPCs and routing, etc.) • muti-stack projects for things that have a very different deployment cycle to those shared resources (k8s clusters, apps, Cognito / user directories, etc.) Since there's usually quite a few projects working together and dependent on each other, you'll find that at least some of your infra will be pretty much identical between environments (so you'll have multiple stacks in single projects) and some won't (so you'll have some projects that are specific only to a subset of the environments). Pulumi supports it all. Good luck!

In our case we have different infrastructure per environment. For example, we mainly use AWS S3, and we have 3 buckets, one per environment, to store data. The buckets are NOT named after the environment name, for legacy reasons, so the naming can’t be parametrized. The production bucket has stricter policies, the other don’t. Then we have a common bucket to store CDN static assets, and it’s used by all environments. So I guess bullet point 1 applies to us here, I think (?). Thanks for your support!

The bucket name can be stack-level configuration. The policies can be different per stack: you just build the bucket configuration with

if (Pulumi.getStack() == "prod"

or similar. (Plus, this could be a good opportunity to firm up the weaker policies). The common bucket (and the CDN, if appropriate) would be set up in a different project.

Yeah agree, ideally the buckets per environment should all have almost the same policies, otherwise it can be a security risk. Maybe we will refactor this and setup a proper stack based environment as you mentioned, and a separate project for the CDN and common infra. Thank you very much for your input and your time 🙏 Pulumi is great

In addition to @little-cartoon-10569’s great advice, you may find some useful information in our “IaC Recommended Practices” series, the first of which is found here: https://www.pulumi.com/blog/iac-recommended-practices-code-organization-and-stacks/ Let us know if you have additional questions, or if we can help in some way. Welcome to the Pulumi community!

This is great! Thank you 🙏 I will take look