Cross-posting this for visibility, any help, comment or idea is highly valuable 😅!

Hi Santiago, in our project we have multiple YAML files with the resources for each application. We are indeed using

StackReferences

for refering to resources that have been created in other files. It works fine and I also think it's nice and clean. Separation of concerns. Each yaml files contains only the resources needed for that application. Some advantages we see: • You can delete an application including all the resources that that application has in one go • Developers now exactly where to add/remove/update resources for each application.

Hi Yuri, really helpful to hear from someone who’s already running with this setup, thanks a lot for sharing! I’m exploring a similar direction where each YAML file corresponds to a different type of resource and I’d like to understand a bit more about how you’re handling the multi-stack structure. Do you treat each YAML file as a separate Pulumi stack with its own state file? If so, are you running

pulumi up

for each stack individually, or have you set up any sort of orchestration (e.g., CI/CD workflows, scripts) to run them in sequence? Also, in our case, all resources target the same org — meaning the stack config (URL, PAT, etc.) is shared. Have you found a clean way to avoid duplicating that config across stacks, or do you handle that through automation or shared templates? Again, appreciate any details you can share, TIA!

Yes, we treat each YAML file as a separate Pulumi stack. We do store the state files in the same cloud storage bucket, but since it's separate stacks, they state files are also stored in separate folders by Pulumi. We are running

pulumi up

for each stack individually using an automated pipeline, where we create a small job for each stack. I guess if your good at scripting, you could probably loop over all stack folders and execute

pulumi up

for each folder, effectively automating the rollout of all stacks. In regards to sharing secrets/keys across all stacks (if that's what you mean?), some stacks have their own secrets for config values etc, but their value is injected through CI/CD into the Pulumi config file. Before injecting the values, you could retrieve secrets from your cloud service or wherever you have your secrets stored

Exactly, I thought that going this route would require this, but hearing from experience really helps me narrow down to that option. I'll do a PoC implementation and check pros vs. cons about it to formalize a decision for our use case. Again, thank you very much Yuri for sharing the info!!