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

Yes, if you just remove the code, then Pulumi will tear things down.
If you want to leave them up _and_ comment out the code (or hide it behind a feature flag), then you will need to remove the resources from state, using `pulumi state delete &lt;urn&gt;`.

A common pattern here is to have different projects for the rarely-changed resources and the frequently-changes resources.

The issue is… I still *need* references. I just don’t want pulumi to alter something.

They can reference each other whether they are projects or stacks.

From your description, I think most people would use projects: a shared longlived resources project (network + DB), and a per-app or per-env project (EKS etc.)

And you might have multiple stacks for each project, maybe based on region or purpose (dev, staging, prod etc.)

The issue is I want to have everything contained within one “thing”, for export purposes.

I think, a feature I’d like is the ability to mark stuff as “frozen”“.
That way VPC, RDS, Security Groups and other stuff could just be defined as they are, and even be accessible, but frozen so no changes occur.

Yeah already have stacks for environments, even have dynamically created stacks for Pull Requests. It’s expensive, but worth it.

The two projects can be beside each other on the file system, and in the same repo, for packaging purposes