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

~why not name them descriptively? Idk why you have separate stacks so these names are just examples but like `dev-networking`, `dev-storage`, `dev-api` etc~

actually h/o, how do you have multiple stacks for the same env since they're all just instances of the same resources?

Keeping in mind that in Pulumi, conceptually a stack _is_ 1:1 an environment

We do have multiple dev stacks in the same environment internally, for each engineer’s dev stack. We usually follow a pattern of `Pulumi.dev-[user].yaml`

Yes <@U01038HJ93R> ‘s example is a use case. The others are similar just not ties to a user exactly. I was hoping to keep human names out of it and be a little more systematic.

Are the character limits on Pulumi logical names? I didn’t see this the docs. <@U01038HJ93R> 

The stack being 1:1 with an environment I can understand, but this is the scenario where we want replicas of stacks/environments within the account or footprint.

It would be nice if we could reference a standard ‘Pulumi.dev.yaml’ and then all of the ‘Pulumi.dev-user.yaml’ would inherit those defaults and override as necessary. Save a lot of duplication.

To achieve this, you can get config details from other sources; you're using a full programming language so you can use other libraries to do it. Maybe even use a single Pulumi.dev.yaml file and some properties are the names of environment variables, other config files, something like that?

Pulumi already goes quite a way beyond the "do one thing, well" philosophy and offers a myriad of features, but sometimes you will have to pull features in from other sources to get all the functionality you want.

<@U01REF1TC5T> There is `pulumi config cp` so you could setup a stack as your "schema" stack and put the config in that and then make part of your process that after you create the new stack you copy the config from the schema stack.

Or you could use Automation API to manage your stacks. Then like <@U012UJTT55M> said spawning a new replica stack and moving config around would just be programmatic

Thank you both! I’ll look into your suggestions.