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

<https://www.pulumi.com/docs/intro/concepts/resources/options/protect/>

or maybe <https://www.pulumi.com/docs/intro/concepts/resources/options/retainondelete/>

RetainOnDelete will keep the resource around but the stack state loses track after a destroy

Protect might be a good option, if it can also import a resource which already exists

I have used protect in conjunction with programatically importing resources and it works fine. we use it to manage some repositories in github :thumbsup:

```getRepository(jugoRepo).then((impRepo) =&gt; {
      // Import the repository
      const importedRepository = new github.Repository(
        `${jugoRepo.name}-repository`,
        {
          ...(impRepo as unknown as RepositoryArgs),
          defaultBranch: undefined,
          private: undefined,
          pages: undefined,
          deleteBranchOnMerge: true,
        },
        {
          protect: true,
          import: jugoRepo.name,
          ignoreChanges: ["vulnerabilityAlerts", "isTemplate"],
        }
      );```
it can be a bit of a nightmare importing if the inputs/outputs dont match up

In my opinion: no, this isn't the best way to handle this. I suggest moving these resources to a different project. I find that thinking of projects as _groups of related resources which share a single deployment cycle_ is very helpful. If your current project needs two deployment cycles, then (in my opinion) it should be two projects.

<@U012UJTT55M> I follow the same philosophy. How do you then handle these multi step deployments when you need to deploy multiple projects in a sequence?

I mean programmatically? I'm thinking about using Azure Logic apps.

We use a pattern for "base infrastructure" or "shared resources" for projects that have common for base resources that "child projects/stacks" will reference via the outputs of those projects using StackReferences.

In our case, these projects have their own explicit lifecycles, and we explicitly deploy the base, then the children

Separate Pulumi projects are very easy to deploy in a fixed sequence at initial deployment: a short script can do it, or you can use automation-api to call out to the projects. In the simplest case of just calling one project then the other, with the same stack name in both, then I recommend the simple script: automation-api brings a lot more power, but that comes at the normal cost of additional complexity.

<@U013Q0AKUCW> I’m tending toward this separation pattern also. But even then… reducing destroy/deploy timeframes and leaving alone “network” infrastructure / connections can be desirable