When would you pick Pulumi over Terraform or OpenTofu?

I’d lean toward Pulumi when the team already writes and reviews the language you plan to use, and there’s a real need to compose infrastructure into higher-level components. Being able to package a repeatable environment as a typed component can be cleaner than wiring together many low-level resources and modules.

That only pays off if the team also treats the infrastructure code as a maintained software project. Set conventions, review abstractions, test changes, and make ownership clear. A general-purpose language makes more patterns possible, not automatically more understandable.

For a fairly standard setup, Terraform or OpenTofu would be my default. Their declarative model is familiar to a lot of infrastructure practitioners, and plenty of problems that look like they need custom logic can often be handled with modules, variables, and a better resource structure.

I’d be cautious about choosing a tool just because loops and conditionals are easier in a programming language. If the result is harder for the next person to inspect or change, that flexibility can turn into a maintenance cost.

The deciding question for me is who will own this in a couple of years. If application developers are expected to build and operate their own infrastructure, Pulumi may fit their existing skills better. If the people maintaining it are more comfortable with configuration languages and established infrastructure workflows, Terraform or OpenTofu may be the easier handoff.

Also check the operational model, not just the language. Compare how each option fits your needs for state storage, access controls, automation, and recovery. Don’t assume those details will take care of themselves just because the code is pleasant to write.

I’d pick Pulumi when the project genuinely benefits from a software-style abstraction layer, not just because the team prefers writing TypeScript or Python. For example, if several environments need the same carefully designed component with a small set of parameters, that can be a good fit.

But keep the components boring and predictable. If every stack ends up with its own conventions, the abstraction has stopped helping. A small proof of concept with a second person reviewing it can reveal whether the design is actually easier to maintain.