Pulumi.

Where Pulumi fits on a long engagement.

Using a real language removes genuine friction. Complex conditional infrastructure, which becomes awkward in a declarative DSL, is ordinary code here, and it can be unit tested with the tools the team already uses. For organisations where the same people write applications and infrastructure, the reduction in context switching is real.

The same property is the risk. A general-purpose language permits abstraction that infrastructure does not benefit from, and a deeply factored Pulumi program can be much harder to reason about than verbose declarative code. Infrastructure is read in emergencies, and clever code is expensive precisely then.

What an assigned team does with Pulumi.

The choice between Pulumi and a declarative tool usually comes down to who maintains it. Application teams that own their infrastructure get real value from one language; a dedicated platform function often prefers the constraint of a DSL.

Establishing which of those a client actually is, before committing, is a scoping question rather than a preference. What that scoping covers is set out in how the monthly fee is built.

What we use Pulumi for.

• Conditional infrastructure without contortion Environment differences expressed as ordinary control flow rather than DSL workarounds.
• Infrastructure under unit test Policies and resource shapes asserted in tests before anything is applied.
• One language across application and platform Shared types and tooling where the same people own both.

How Pulumi capacity is assigned.

Pulumi capacity is assigned under devops managed services, with readability under incident conditions treated as a review criterion.