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; Do you know of any concerns I should have?
Nothing concrete comes to mind. It sounds like you are asking the right questions.
&gt; How transactional is pulumi?
It’s not really transactional in the sense that a deployment may fail on any resource (if a resource can’t be created) and it will stop at that point. The state file will be self-consistent but the a multi-resource deployment is not atomic. There are no built-in rollbacks. Providers do some number of retries for transient errors.
&gt; Hoping to mitigate them when temporal attempts to retry.
Retries may help for long-ish transient errors that a provider did not wait to resolve but retries wont help for a lot of errors in practice (say, a resource’s properties aren’t configured correctly, or a conflict with pre-existing infra).

<@UB39JFCKC> Thanks for the info.   I've been tasked with cleaning up some Infrastructure deployment code / patterns.    Probably going to attempt to create workflows / patterns where we limit the amount of resources and state in 1 single TF / Pulumi by wrapping it in workflow.

At the moment,  I think we may just dump state before every execution.  Not sure if there is a happy path to be able to take the current state file,  the intended state file, and what is actually in the infrastructure and inline remediate a deployment with "import"