Hi, we want to organise the code in pulumi to handle multiple environments: 1. we have dev, staging, prod. 2. Each environment will have set of resources to be deployed such s3,rds, eks by using common pulumi modules developed. 3. Here, do we need to use dev, staging, prod as projects or environments since we wanted to use s3 backend for state management and stackreferences for the one module output to other ones - little confused over pulumi environments vs projects in this case since full url has to match to for stackreferences. 4. I wanted to provide the configs each of them in their own block from single file such as dev/config.yaml s3: name: test-bucket type: private-ro rds: name: rds-staging replication: false eks: type: staging name: staging-01 can someone help on this ?

If your environments (dev, staging, prod) are roughly identical, then you can use a single project with multiple stacks. Each stack can represent an environment, and you can use stack configuration values to parameterize the program to account for small differences in each environment (different instances types or counts of instances, for example). I’m on my mobile at the moment but later today I’ll share some links to some blog posts that may be helpful.

Thanks @salmon-account-74572 - Most of them are same, just the config options will change. I already went through the series of blogs on best practices but esc concept has created confusion again and if you could guide us that will be a great help. having single project and multiple stacks would involve problem since s3/rds/eks each of them would form the different stack for each environment right ? and also how can we maintain the versions for each provider such as aws/gcp etc which we initialise during the stack creation and avoid the download of every time in air-gapped environment - downloading and creating python virtual environment & keeping them in git would solve the problem to some extent ?

@breezy-television-71515 The easiest way to approach ESC right now is to consider it a replacement for stack configuration values. Instead of using

pulumi config set <key> <value>

to write values into the stack configuration file (

Pulumi.<stack>.yaml

), you create an ESC environment and store the configuration values there. You can then reference that ESC environment from multiple stacks; changing the ESC environment will then change it for all stacks that reference it (the change will take effect on the next

pulumi up

). ESC doesn’t fundamentally change any of the guidelines or recommendations around when to use multiple stacks---it just makes using configuration across multiple stacks potentially MUCH easier. As for maintaining versions of a provider, the versions are specified using whatever language-specific mechanisms are in place. For Python, there’s a

requirements.txt

that specifies the versions, and

pulumi new

will automatically create a virtual environment when a Python template is selected. So, yes---using virtual environments and installing the versions specified in

requirements.txt

(which would be checked into version control) is the right approach.

Thank you @salmon-account-74572 - It makes sense

Happy to help!