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

&gt; It’d be interesting if you could have multiple stacks that shared some state - ie. a project that was for a single microservice instance and a monolithic project that was for an entire environment that included the microservice. Obviously there’d be a challenge in reading multiple pieces of state across multiple storage areas (eg.GCS buckets) and co-ordination/locking.
The popular method for achieving this is with a "shared-" or "base-" project that has the resources which other stacks share.  The "child" stacks get the values of the Outputs via StackReferences, and use the resource getters to get a copy of the resource in the current scope.

<https://www.pulumi.com/blog/iac-recommended-practices-using-stack-references/>

I would recommend against the monolithic approach.

The more resources you manage, the longer deployments will take just to calculate the resource graph.  When your plan fails, it will fail big.  Operationally, micro stacks help you limit the damage in the case of an incident.

my gripe is that stacks feel more like different envs (staging/test/prod) instead of different vertical slices

That's where I think you're looking for the Stack References pattern

It's also worth noting there is "project level configuration" that all stacks can inherit, but not resources.

My organization uses this pattern fairly heavily in conjunction with a few other patterns.

1. `shared-infrastructure` for your account-wide resources
2. `shared-project-name` for resources shared across other stacks in a project (e.g. you have a 3 tier web application, and they all have to share some S3 bucket) 
3. `pulumi-components` for our "level 2" abstractions of our resources (e.g. custom resource) distributed as a library for Stacks to use to simplify resource declarations

do StackReferences work when not using Pulumi’s backend?

Yes, there is a note about a recent change regarding that though

<https://www.pulumi.com/blog/project-scoped-stacks-in-self-managed-backend/>

TL;DR, before this change, YOU WILL NOT have "fully qualified stack names" like you do in the Pulumi service. e.g. `my-org/my-project/my-stack` .

The work-around was to create your own namespace convention, and all states live as siblings in the state storage backend. e.g. `my-org.my-project.my-stack`

One thing to remember about the stack references is that the parent stack can decide to remove the reference and there's no way to notify downstream about the change or removal.

So I'd advise combining stack references with lookup aka `get_&lt;resource&gt;` functions.