No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

Hi everyone, I have a project with *multiple stacks*. There are some *common configuration* with the same values for some stacks.
For example, I have 4 stacks:
```#Pulumi.network.dev.yaml
encryptionsalt: ....
config:
  aws:region: us-east-2
  network:env.name: dev```
```#Pulumi.services.dev.yaml
encryptionsalt: ....
config:
  aws:region: us-east-2
  services:env.name: dev```
```#Pulumi.network.prod.yaml
encryptionsalt: ....
config:
  aws:region: us-east-1
  network:env.name: prod```
```#Pulumi.services.prod.yaml
encryptionsalt: ....
config:
  aws:region: us-east-1
  services:env.name: prod```
*Is this possible to extract common configurations to a file and import it when needed?*
For example, I would like to have something similar to this:
```#Pulumi.common.dev.yaml
encryptionsalt: ....
config:
  aws:region: us-east-2
  common:env.name: dev```
```#Pulumi.network.dev.yaml
encryptionsalt: ....
config:
  aws:region: {{common.dev/aws:region}}
  network:env.name: {{common.dev/common:env.name}}```
*Or do you have other ideas to solve this issue?*

I believe the issue <https://github.com/pulumi/pulumi/issues/2307> describes the feature that you are looking for. Latest activity is that it was removed from 0.30 milestone. Currently, I think that you have to repeat your shared configuration in all stacks.

Personally I've created a dynamic provider that loads a json file, validates it against a json schema, and loads outputs with it's values.

The typical solution is to set the defaults in your code. If you have shared defaults at the project level (most common and sounds like the case you have here?) then this is works particularly well. 

For more complex configuration inheritance - you can just do it in code as <@UUGHNMDC4> suggests - though you shouldn’t even need a dynamic provider - you code can just read files off disk that define your own customized notion of configuration defaults inheritance.

Sorry I should have clarified - the only reason I'm using a dynamic provider is so that all the properties from the config are grouped together in the state. Makes tracking some things much easier. If that wasn't important to me specifically I'd 100% just read the file.

Thanks for your replies! Sadly the config value is not possible to be imported. I will check your suggestion in the future. For now, manually add duplicated configuration is easier for my case.

Can your share your dynamic provider code?