Why we use Pulumi (important context) We don't use Pulumi just to write infrastructure configuration in a programming language. The primary reason is: > To control infrastructure lifecycle and execution flow programmatically via Automation API. Not because TypeScript is inherently better than YAML for describing infrastructure settings. What IaC should guarantee (in our view) Regardless of tool choice, IaC should ensure: • *Infrastructure configuration always leaves artifacts*Code + state remain for inspection, recovery, and audit • *The same infrastructure code must be operable via:*CLI (for import, migration, emergency fixes) • API / Automation (CI, IDP) • Common infrastructure patterns should be reusable and modular • Git should remain the source of truth Where the dilemma starts From this perspective: • *Infrastructure configuration itself does not necessarily need to be written in a programming language*YAML could be simpler and more readable However, writing infrastructure definitions in a programming language does have advantages: • Conditionals, branching, and complex logic can be expressed naturally • YAML quickly hits limits when these are needed This leads to a tension: > If Pulumi is mainly used for execution and orchestration via Automation API, do infrastructure definitions really need to be written in a programming language? At first, YAML seems sufficient. But realistically: • Eventually, infrastructure definitions themselves need conditionals • At that point, YAML either becomes a DSL nightmare or insufficient • Which makes me wonder whether trying to keep "infra definitions in YAML" is actually fighting Pulumi instead of using it properly Where I'm currently leaning (but unsure) Because of this, I'm starting to think: > Writing infrastructure definitions in a programming language might actually be the correct long-term choice. Not because it's more powerful, but because it avoids artificial constraints and DSL complexity. But I'm still uneasy about the implications. Our current operational model Given the above, the model we're gravitating toward is: W

request
  → IDP (generate or modify git-based Pulumi code)
      → IDP (clone & apply via Automation API)

Which implies: • The IDP generates or modifies Pulumi programs (e.g.

index.ts

) • Those programs live in Git • Pulumi executes them via Automation API • The same repo can be operated via CLI when needed This works—but it feels heavy, and I'm not fully confident it's the right abstraction boundary. What I'd really like feedback on My core concern is this: Is it the right approach for an IDP to generate and modify programming language code (e.g. TypeScript) to persist infrastructure definitions in Git? If it were YAML, parsing and modifying would be straightforward. But generating and modifying actual programming language code from an IDP feels fundamentally more complex and fragile. • Is this a common or accepted pattern for Pulumi-based IDPs? • Is this an inevitable outcome of using Pulumi "correctly", or a sign we're overcomplicating things? • Are there simpler or more established patterns people use in practice for this problem? Any insights, war stories, or references would be hugely appreciated. Thanks in advance 🙏

No need to have complicated code generation when you can make a library that implements your standardized patterns 🙂

As a concrete example of what you can do: awhile back I was working on a system that would precompile Pulumi programs into executable artifacts. These artifacts had a special mode that would print the configuration schema instead of running normally. As part of CI/CD I would then export the schema and publish it so that deployment parameters could be set via a web UI. It also enabled me to do schema comparisons for environment upgrades & ensure that a particular deployment configuration was compatible with a particular artifact.

Also it seems that Pulumi is advertising itself for IDPs specifically. If you haven't seen this, might be worth looking into. Could give you some ideas at least. It might be that you don't need any fancy tooling at all, and you're just looking at creating a set of reusable components for your use case.