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

Two approaches I think _could_ work:

1. Use Pulumi automation -- you write a separate program that calls your one-off step when a flag is passed, and then runs your Pulumi stack, passing any necessary data from the one-off step as necessary.
2. Write a custom resource that e.g. uses Pulumi's `command` resources to run arbitrary commands. To prevent the disaster scenario, you could opt not to provide the `delete` command (so that deleting the resource is a no-op -- requires manual clean-up from you), mark the resource as `protect: true` so that it's harder to delete it accidentally, or some combination of the two.
Disclaimer: while I've used both Pulumi automation and protected resources, I might be a missing a case where these might not offer the kind of guarantees you are looking for!

there's 3: write a small dynamic provider.

Command or a dynamic provider is probably the best way to do this today. I do have a plan to add a builtin resource to handle these sorts of cases, but it needs some function callback groundwork in place in the engine first which should be coming soon.

<@U06BU3LR18E> I wonder if you ever worked out a satisfactory solution?

It occurred to me that one might use a flag in pulumi ESC environment for this. I can't remember if pulumi has a way of updating (rather than just reading) values in ESC, from within a pulumi program, but if so, it could be useful.

Another way I'm thinking of is using the value of a secret as the input to your job. This wouldn't be possible in yaml, would require a full programming language

Pseudocode thoughts
```if bootstrap_completed is empty or false {
   run bootstrap_database
   set secret bootstrap_completed = true // external secret within your environment, e.g. AWS Secrets Manager
}```
If I'm not making some kind of huge logic flaw, this will only ever run once
Scenario 1: new stack. Secret doesn't exist yet. bootstrap runs, secret gets set.
Scenario 2: subsequent runs on existing stack. Secret exists and is true. bootstrap doesn't run.