Pulumi Blog: Platform engineering

Best Terraform Alternatives in 2026

Pulumi Content Team — Sat, 18 Jul 2026 00:00:00 +0000

The strongest Terraform alternatives in 2026 split into three groups: general-purpose-language platforms like Pulumi and AWS CDK, HCL-compatible forks like OpenTofu, and cloud- or platform-specific tools like AWS CloudFormation, Azure Bicep, and Crossplane. (Pulumi also supports HCL directly and can serve as a Terraform-compatible state backend, so teams don’t have to choose between staying in HCL and gaining Pulumi Cloud’s platform capabilities.) Which one fits depends less on syntax preference than on how well it lets your team, and increasingly your AI coding agents, read, test, and safely change infrastructure code.

Why teams are re-evaluating Terraform in 2026

Terraform has been the default infrastructure-as-code tool for most of the last decade, and for good reason: a mature provider ecosystem, a large community, and a state model that most platform teams have learned to live with. But three forces are pushing teams to look again at what else is available.

The first is licensing. HashiCorp moved Terraform from the open-source Mozilla Public License to the Business Source License in August 2023, a shift that triggered the community fork now known as OpenTofu. HashiCorp itself became a wholly owned subsidiary of IBM when that acquisition closed in February 2025. Neither event breaks anything for existing Terraform users, but both changed how governance and long-term product direction get decided, and that’s enough for some platform teams to want a documented Plan B.

The second is the accumulated cost of working in a domain-specific language. HCL wasn’t designed for the abstraction, composition, and testing patterns that platform engineering now expects: sharing logic across teams, writing meaningful unit tests, and building internal libraries that read like software rather than templated configuration. Terraform has closed some of this gap over time, adding a native test framework in version 1.6, but the ceiling on what a declarative DSL can express is still lower than what a general-purpose language offers.

The third, and the one reshaping the conversation fastest, is agentic AI. Coding agents like GitHub Copilot, Claude, and Pulumi’s own Neo are now a standing part of how engineering teams write and review code, and infrastructure is not exempt. These agents were trained on enormous volumes of real Python, TypeScript, Go, and Java, plus their entire testing and tooling ecosystems, but on comparatively little well-formed HCL. When an agent can write and modify infrastructure in a language it already understands deeply, the feedback loop of propose, test, preview, and ship gets tighter. When it has to reason about a purpose-built DSL, that loop lengthens and the agent is more likely to produce configuration nobody would write by hand. That gap doesn’t disqualify Terraform, but it does mean “which IaC tool works best with AI agents” is now a first-class question when teams evaluate alternatives, alongside the perennial ones about multi-cloud reach and governance.

None of this is an argument that Terraform is going away. It remains a capable, widely adopted tool with a genuinely large provider catalog. It’s an argument that 2026 is a reasonable moment to look at what else exists, honestly, and pick the tool that fits where your infrastructure and your engineering workflow are actually headed. For a broader look at how AI agents are changing infrastructure work generally, see building for agentic infrastructure. For a head-to-head look at Pulumi and Terraform specifically, see our Pulumi vs. Terraform comparison.

Pulumi

Pulumi is an infrastructure-as-code platform that lets you define cloud infrastructure in general-purpose languages, including Python, TypeScript, Go, C#, and Java, plus a YAML option for teams that prefer a declarative format. Rather than compiling down to another tool’s templates, Pulumi programs run directly against a deployment engine that supports more than 180 providers in total, covering AWS, Azure, Google Cloud, Kubernetes, and a long tail of SaaS and on-prem targets.

Pulumi also supports HCL as a first-class language, and Pulumi Cloud can serve as a drop-in state backend for existing Terraform code. That means teams with a large, working Terraform estate aren’t required to rewrite anything to get Pulumi Cloud’s state management, access controls, and policy enforcement — they can point existing HCL at Pulumi with minimal changes, then migrate configuration into a general-purpose language on their own timeline rather than all at once.

Writing infrastructure in a real language means you get the tooling that comes with it for free: IDE autocomplete and type checking, unit and integration test frameworks, package managers for sharing reusable components, and the same code review and CI/CD conventions your application teams already use. It also means Pulumi programs run directly through Pulumi’s own deployment engine against any cloud or SaaS platform, with no separate compile-to-template step in between, unlike CDK-style tools that transpile into another system’s format before anything deploys. For an AI agent iterating on infrastructure, fewer steps between “write code” and “see the result” means a tighter feedback loop. Pulumi Neo, the platform’s infrastructure agent, builds on this directly: it can propose Terraform-to-Pulumi migrations, run policy-checked previews, respond to failures, and open pull requests inside a team’s existing review workflow.

For platform teams, Pulumi adds built-in guardrails that Terraform typically requires bolting on through third-party tooling: policy as code for enforcing organizational rules before a deployment ships, a secrets and configuration management layer (ESC), human-in-the-loop approval gates, and reusable components that teams can publish and consume like any other internal library, in whatever language they use. The tradeoff is ecosystem maturity in the opposite direction from Terraform: Pulumi’s provider catalog, while broad, has a shorter history than Terraform’s for a handful of niche or long-tail providers, and some teams will need to weigh that against the language and workflow benefits.

At scale, Pulumi customers report concrete outcomes. BMW’s Software Factory manages more than 20,000 cloud resources with Python-based infrastructure code for over 11,000 developers. Wiz manages more than a million cloud resources through Pulumi’s Automation API and Kubernetes operator, pushing hundreds of thousands of daily infrastructure updates across hundreds of data centers. Supabase scaled from a single region to 16 regions and roughly 80,000 resources. Atlassian’s Bitbucket team reported a 50% reduction in infrastructure maintenance time after adopting Pulumi.

OpenTofu

OpenTofu is an open-source fork of Terraform, governed by the Linux Foundation rather than a single vendor. It emerged directly from HashiCorp’s August 2023 license change: a group of Terraform users and vendors forked the last MPL-licensed Terraform release and committed to keeping the fork under a permissive open-source license going forward.

The practical pitch is continuity: OpenTofu aims to stay a close drop-in replacement for Terraform, using the same HCL syntax, the same provider ecosystem (most Terraform providers work unmodified), and largely the same workflow, so teams can migrate with minimal rewriting. Since forking, OpenTofu’s maintainers have also started adding features HashiCorp hadn’t shipped, including state encryption at rest, giving it a case for teams who want to stay in HCL but prioritize community governance over vendor governance.

The tradeoff is that OpenTofu inherits HCL’s ceiling along with its familiarity. It solves the licensing and governance concern cleanly, but it doesn’t address the testing, composability, or general-purpose-language advantages that come with moving to a platform like Pulumi or AWS CDK, and AI coding agents face the same reasoning gap with OpenTofu’s HCL that they do with Terraform’s.

AWS CloudFormation

CloudFormation is AWS’s native infrastructure-as-code service, using YAML or JSON templates that AWS itself parses, validates, and rolls back on failure. Because it’s built and operated by AWS, it gets first access to new AWS service features, and its state is managed entirely by AWS rather than a separate backend your team has to configure and secure.

The obvious limit is scope: CloudFormation only provisions AWS resources, so any team running infrastructure across more than one cloud, or alongside Kubernetes and SaaS resources, will need a second tool for everything outside AWS. Authoring in raw YAML or JSON also means the same testing and abstraction limitations that HCL-based tools face, without even Terraform’s ecosystem of community modules to offset it. Many AWS-focused teams increasingly write CloudFormation stacks through AWS CDK rather than by hand.

AWS CDK

AWS CDK (Cloud Development Kit) lets you define AWS infrastructure using general-purpose languages including TypeScript, JavaScript, Python, Java, C#, and Go. Under the hood, CDK code compiles down to standard CloudFormation templates, which AWS then deploys the same way it deploys any other CloudFormation stack.

CDK gives AWS-only teams most of the general-purpose-language benefits that Pulumi offers: real loops, functions, tests, and packages, plus the IDE support that comes with a mainstream language. The compile step is the notable difference from a platform like Pulumi, which runs your program directly against cloud provider APIs: CDK synthesizes a CloudFormation template first, then hands that off, which adds a layer between what your code says and what gets deployed, and can slow the feedback loop an AI coding agent depends on when it’s proposing and testing changes iteratively. CDK is also AWS-only, so it doesn’t help teams who need one consistent authoring model across multiple clouds.

It’s worth distinguishing AWS CDK clearly from HashiCorp’s CDK for Terraform (CDKTF), which offered a similar general-purpose-language wrapper around Terraform’s HCL engine. HashiCorp sunset and archived CDKTF in December 2025, stating in its own FAQ that the project “did not find product-market fit at scale” and redirecting investment to Terraform core instead. Existing CDKTF code still runs, but the project receives no further commits, fixes, or provider updates, which makes it a poor foundation for new work regardless of language preference.

Crossplane

Crossplane is a Kubernetes-native framework for infrastructure as code, letting platform teams define and provision cloud resources as Kubernetes custom resources, managed by controllers running inside a cluster. Rather than running a separate CLI-driven apply cycle, Crossplane treats the cluster’s control plane as the single source of truth for both application and infrastructure state.

This model is a natural fit for teams already standardized on Kubernetes as their platform layer: infrastructure gets the same GitOps, RBAC, and reconciliation patterns as application workloads, and platform teams can build self-service abstractions (Crossplane calls these Compositions) that let application developers request infrastructure without learning Crossplane’s own resource model directly. The tradeoff is that Crossplane assumes a Kubernetes-centric operating model; teams without an existing cluster-based platform will be adopting Kubernetes as a prerequisite, not just an infrastructure tool, and Crossplane’s ecosystem of documented, named enterprise deployments is thinner than Terraform’s or Pulumi’s, making it harder to evaluate at-scale track record from public case studies alone.

Azure Bicep

Bicep is Microsoft’s domain-specific language for deploying Azure resources, designed as a cleaner authoring layer over Azure Resource Manager templates. Bicep code transpiles to ARM JSON, but with syntax that’s considerably easier to read and write than hand-authored ARM. It’s open source under the MIT license, and Microsoft’s own documentation recommends it over raw ARM JSON for new Azure-only infrastructure work.

Like CloudFormation, Bicep’s scope is a single cloud, in this case Azure exclusively, so it isn’t a candidate for teams managing infrastructure across providers. It’s also a DSL rather than a general-purpose language, which means the same testing and reuse ceiling as HCL, though for teams fully committed to Azure and nothing else, it remains a well-supported, low-friction choice.

Ansible

Ansible is an agentless configuration management and automation tool that uses YAML playbooks to describe the desired state of servers, software, and application deployments. Red Hat, which acquired Ansible in 2015 and was itself acquired by IBM in 2019, maintains it today as part of Red Hat Ansible Automation Platform.

Ansible is often grouped with Terraform in “IaC tool” comparisons, but the two solve different problems and are frequently used together rather than as substitutes: Terraform or Pulumi provisions the resource, and Ansible then configures the operating system, installs software, and manages ongoing configuration state on top of it. Ansible does ship cloud provisioning modules and can create resources directly, but its design center is procedural configuration management, not declarative resource provisioning at the scale Terraform-class tools target. Teams evaluating Terraform alternatives for cloud provisioning specifically will usually want a tool from this list’s other categories, with Ansible layered in afterward for day-two configuration.

Terragrunt

Terragrunt is a thin orchestration wrapper maintained by Gruntwork that sits on top of Terraform or OpenTofu, rather than replacing either one. Its job is keeping multi-environment, multi-module HCL configurations DRY, and coordinating the order in which modules apply across a larger infrastructure codebase.

It’s worth being precise about what Terragrunt is not: it doesn’t introduce a new language, provider model, or state backend, and it doesn’t address HCL’s testing or abstraction limitations on its own. Teams considering Terragrunt aren’t choosing a Terraform alternative; they’re choosing a companion tool that makes Terraform or OpenTofu easier to operate at scale. If the underlying frustration is with HCL itself rather than with configuration sprawl, Terragrunt won’t resolve it.

Comparison table

Tool	Language	Cloud coverage	AI-agent readiness	Governance & policy	Best for
Pulumi	Python, TypeScript, Go, C#, Java, YAML, HCL	180+ providers, any cloud	High — real languages agents are trained on; Neo agent built in	Policy as code, ESC secrets, human-in-the-loop approvals	Teams standardizing on AI-native, multi-cloud engineering workflows
OpenTofu	HCL	Same provider ecosystem as Terraform	Same as Terraform — DSL limits agent reasoning	Community-governed; adding features like state encryption	Terraform users prioritizing open governance with minimal migration
AWS CloudFormation	YAML/JSON	AWS only	Low — templated config, no native testing	AWS-managed state and rollback	Teams fully committed to AWS wanting a fully managed native service
AWS CDK	TypeScript, Python, Java, C#, Go	AWS only (compiles to CloudFormation)	Medium — real languages, but a compile step slows feedback	Inherits CloudFormation governance	AWS-only teams wanting general-purpose languages
Crossplane	Kubernetes YAML/CRDs	Any cloud, via Kubernetes control plane	Medium — benefits from Kubernetes-native agent tooling	RBAC and GitOps via Kubernetes	Platform teams already standardized on Kubernetes
Azure Bicep	Bicep DSL (compiles to ARM)	Azure only	Low — DSL, no general-purpose tooling	Inherits Azure Resource Manager governance	Azure-only teams wanting a cleaner ARM authoring layer
Ansible	YAML playbooks	Any cloud, config-management focused	Low for provisioning; not its design center	Role-based playbooks, limited policy tooling	Day-two configuration management alongside an IaC tool
Terragrunt	HCL (wraps Terraform/OpenTofu)	Same as underlying Terraform/OpenTofu	Same as underlying Terraform/OpenTofu	Same as underlying Terraform/OpenTofu	Keeping large Terraform/OpenTofu codebases DRY, not a language alternative

How to choose

If your team is standardizing on a single cloud and wants the deepest, most tightly integrated tooling for it, the native option, CloudFormation for AWS or Bicep for Azure, is a reasonable default, especially for smaller platform teams that don’t need cross-cloud abstraction. If you’re on AWS specifically and want general-purpose languages without leaving the CloudFormation ecosystem, AWS CDK is the more capable choice, with the caveat that its compile-then-deploy step adds a layer between code and infrastructure.

If your team is already running Kubernetes as its platform layer and wants infrastructure provisioning to follow the same GitOps and RBAC model as application workloads, Crossplane is worth a serious look, understanding that it comes with Kubernetes as a hard dependency.

If you’re deep in Terraform today, comfortable with HCL, and your primary concern is licensing and governance rather than language or workflow, OpenTofu is the lowest-friction path: same syntax, same providers, community governance instead of vendor governance.

If your team is investing in AI coding agents as part of its engineering workflow, wants multi-cloud reach without maintaining separate tools per provider, and values real testing, packaging, and code review practices for infrastructure the same way it does for application code, Pulumi is built specifically for that combination. It’s also the most direct migration path for teams currently on Terraform or CDKTF who want to move to a general-purpose language without changing which clouds they manage.

Frequently asked questions

Is Terraform still free to use?

Yes, for most teams. Terraform’s core CLI and the vast majority of its providers remain free under the Business Source License that HashiCorp adopted in August 2023. The license restricts a narrow set of commercial use cases, mainly building a competing managed offering on top of Terraform, which doesn’t affect ordinary infrastructure teams using it internally.

What is the best open-source Terraform alternative?

OpenTofu is the closest open-source alternative if you want to keep using HCL and the Terraform provider ecosystem, since it’s a direct fork governed by the Linux Foundation. If open-source licensing matters but you’re open to a different language, Pulumi’s SDKs and CLI are open source (Apache 2.0), and Crossplane is a CNCF project for teams standardized on Kubernetes.

Which IaC tool works best with AI coding agents?

Tools built on general-purpose languages give AI coding agents the strongest foundation, since those agents have far more training exposure to real Python, TypeScript, Go, C#, and Java than to any infrastructure-specific DSL. Pulumi and AWS CDK both fit this category; AWS CDK’s compile step to CloudFormation adds a layer of indirection that Pulumi, which runs directly against provider APIs, doesn’t have.

Can I migrate from Terraform without rewriting everything?

It depends on which alternative you choose. Moving to OpenTofu requires essentially no rewriting, since it’s HCL-compatible by design. Moving to Pulumi can be just as light-touch, since Pulumi Cloud works as a Terraform state backend and Pulumi IaC speaks HCL natively; teams that do want to move into a general-purpose language, or that are adopting AWS CDK or a similar platform, will need to translate configuration into program code, though tools like Pulumi’s import and conversion tooling, and increasingly AI coding agents themselves, can automate a meaningful share of that translation rather than requiring a manual line-by-line rewrite.

Is Pulumi a drop-in Terraform replacement?

It can be, if you want it to be. Pulumi Cloud now works as a Terraform state backend, so a team can point its existing Terraform or OpenTofu CLI at Pulumi Cloud and keep every .tf file exactly as written — no rewrite required. Pulumi also supports HCL as a first-class language alongside Python, TypeScript, Go, C#, Java, and YAML, so HCL modules can be authored and consumed natively inside Pulumi IaC.

For teams that do want to move off HCL entirely, that’s also an option: Pulumi’s general-purpose languages let infrastructure code get loops, functions, tests, and packages that HCL doesn’t offer. Moving to that model means translating configuration into code rather than reusing files unchanged, though the underlying model carries over — state, providers, and resources map conceptually in similar ways — and Pulumi provides tooling to import existing Terraform-managed infrastructure and convert Terraform configuration into a starting Pulumi program, which teams typically use as a first draft rather than a finished migration.

Does OpenTofu support everything Terraform does?

OpenTofu tracks Terraform’s last open-source release closely and remains compatible with most existing Terraform configurations and providers. Since forking, its Linux Foundation-governed maintainers have also shipped features Terraform hadn’t offered, such as state encryption, while newer HashiCorp-only Terraform features naturally won’t appear in OpenTofu unless the community implements equivalents independently.

For a broader roundup covering the full infrastructure-as-code category rather than Terraform alternatives specifically, see our guide to the best IaC tools.

Conclusion

Terraform remains a capable, widely used tool, and for teams with no appetite to change, OpenTofu offers a nearly friction-free path to the same workflow under different governance. But the more interesting question for 2026 isn’t whether Terraform still works, it’s whether your infrastructure tooling can keep pace with how your engineering organization is actually building software now: with AI coding agents as active participants, not just autocomplete. That question favors platforms built on real, general-purpose languages, tested and reviewed the same way application code is, over any tool, new or established, still built around a purpose-specific configuration syntax. Evaluate honestly against your own cloud footprint, existing platform investment, and how central AI-assisted development already is to your team, and the right alternative, or the right reason to stay put, becomes clear quickly.

Knowledge as Code: The Memory File Just Got a Spec

Engin Diri — Tue, 14 Jul 2026 00:00:00 +0000

Five weeks ago I wrote that the least glamorous piece of an agent loop is also the one that decides whether it compounds: memory. A markdown file outside the context window that holds what is done, what is next, and what was learned, because the model forgets all of it between runs. Write the memory file before the loop.

What I left open, because there was nothing to point at, was the format. My memory file looked nothing like yours, and neither of our agents could read the other’s.

Three days after that post went live, Google shipped an answer.

The pattern everyone copied

Andrej Karpathy published a gist in April he called the LLM wiki, and it collected thousands of stars and forks. It’s meant to be pasted straight into a coding agent. Instead of indexing your documents for RAG and re-deriving answers from raw text on every query, the agent builds a wiki and keeps it current: interlinked markdown pages, an index.md with a one-line summary per page, a log.md recording every change, entity pages that grow as sources come in. Drop in a meeting transcript and the agent reads it, updates a dozen existing pages, fixes the cross-references, and appends to the log in one pass.

It took off for the same reason wikis usually die. A knowledge base is valuable in exact proportion to the bookkeeping nobody wants to do: summarizing, linking, reconciling contradictions, pruning stale claims. Karpathy’s line, which Google now quotes back in its own announcement, is that LLMs “don’t get bored, don’t forget to update a cross-reference, and can touch 15 files in one pass.” The human curates sources and asks questions. The agent does the janitorial work that made every previous wiki rot.

A wiki only your agent can read

Then everyone built one, and every one is a dialect. Mine links related pages in the frontmatter; yours links them at the bottom of the body. Mine has a tags field; yours calls it categories. None of this matters while the wiki serves one person, because the schema lives in your CLAUDE.md and your agent reads it on every run.

It matters the moment the wiki has to travel. Hand your knowledge base to a teammate and their agent starts guessing at your conventions, or misses half the structure entirely. A platform team that wants one shared wiki, queried independently by everyone’s agents, has no format to agree on. A knowledge base you can’t hand to someone else’s agent is a silo of one. And a team’s collective knowledge should outlive any single person’s markdown habits.

What Google actually shipped: the Open Knowledge Format

On June 12, two tech leads in Google Cloud’s data analytics engineering org announced the Open Knowledge Format, with a spec and reference tooling on GitHub. Strip the branding and OKF v0.1 is a formalization of the Karpathy pattern:

A bundle is a directory tree of markdown files. Two filenames are reserved: index.md for progressive disclosure and log.md for update history. Everything else is a concept document.
Every concept carries YAML frontmatter with exactly one required field: type. Five more are recommended: title, description, resource, tags, timestamp. Producers can add anything; consumers must preserve what they don’t understand.
A markdown link from one concept to another asserts a relationship. The prose around the link says what kind.

The whole spec fits on a page, and that’s deliberate. The announcement names three principles: minimally opinionated; producers and consumers independently swappable; a format rather than a platform. No required SDK, no compression scheme, no new runtime. Reading a bundle is cat; distributing one is git clone. The repo backs it up with reference tooling: an enrichment agent that drafts concept docs from BigQuery datasets, and a static visualizer that renders a bundle as a graph. Three sample bundles, built by that same agent, give you something to copy from.

The critique is the feature

The pushback writes itself: there is almost nothing here. Folder indexes and five suggested frontmatter fields, on top of a pattern the community already had. True. Also the point.

The standards that stick are embarrassingly small. MCP didn’t model your tools; it standardized the socket they plug into. AGENTS.md fixed nothing but a filename, and that was enough for Neo to read the same conventions file as every other agent. Agent Skills gave procedure a place to live, and docs sites settled on /llms.txt for published content. Knowledge was the layer still missing its boring little standard. Whether OKF specifically is the one that survives matters less than the shape it commits to: markdown, frontmatter, git. Every other layer of the agent stack already landed there, so that bet is safe.

Knowledge as code

Platform teams should care about this before anyone else. Infrastructure as code captures the what: the resources, the config, the dependency graph. It has never captured the why. The runbook for rotating credentials, the decision record explaining the pinned CNI version, who owns the cluster, what the incident in November taught you. That knowledge lives in a wiki behind an API, a shared drive, a Slack thread, and the heads of two senior engineers. Google’s announcement frames this fragmentation as the problem: agents reassembling answers from systems that each speak a proprietary format.

OKF’s answer is a move platform engineers will recognize, because it’s the same one that produced IaC: put it in git, make it diffable, review changes in pull requests. Knowledge as code, sitting next to the infrastructure as code it explains:

platform/
├── index.md
├── log.md
├── services/
│ ├── index.md
│ ├── checkout-api.md
│ └── payments-worker.md
├── runbooks/
│ ├── index.md
│ └── rotate-database-credentials.md
└── decisions/
├── index.md
└── why-we-pin-the-vpc-cni-version.md

The recommended resource field takes a URI naming the asset a concept describes, and a Pulumi URN is exactly that:

---
type: runbook
title: Rotate the payments database credentials
description: Zero-downtime credential rotation for the payments Postgres instance.
resource: urn:pulumi:prod::payments::aws:rds/instance:Instance::payments-db
tags: [payments, postgres]
timestamp: 2026-07-01T09:30:00Z
---

Now the runbook names the exact resource it operates on. An agent planning a change to that database can walk from the URN to the runbook to the decision record that explains the constraint, before it proposes anything. In the loop post I said skills are intent written down, the conventions an agent reads instead of guessing. A knowledge bundle is the other half: experience written down. Tools give the loop hands, skills give it habits, and the bundle is what it gets to remember.

Before writing any of that down, I ran the test. A fresh agent got two inputs, the spec and this bundle, and one question: which services touch the payments database, and how do I rotate its credentials without downtime? It read six files and answered correctly, down to why rotating a second time too soon is the dangerous move. What sold me was the file it didn’t read. It left the CNI decision record closed, because the cross-links mark that page as a cluster concern, not a database one.

The bundle is public, exactly the tree above. Clone it, hand your agent the spec, and ask your own questions:

github.com/dirien/pulumi-platform-okf-bundle

What a standard won’t do for you

Three caveats, so nobody mistakes this for magic.

It formats knowledge; it doesn’t create it. The warning from the loop post applies with no edits: memory is what lets a loop compound, and slop compounds right alongside it. A wrong runbook in a beautifully conformant bundle is still a wrong runbook, now served to every agent on the team with confidence. The leverage isn’t the format. It’s that knowledge changes finally go through review like code changes.

v0.1 is a draft, and the name may not survive. Google says so itself: the announcement calls v0.1 “a starting point, not a finished standard.” OKF could lose to a better spec next year. I’d start anyway, because converting markdown with frontmatter into markdown with slightly different frontmatter is the cheapest migration you’ll ever run, and it’s precisely the kind of mechanical pass an agent finishes in an afternoon. The shape is the commitment. The name is a detail.

Conformance is a floor, not hygiene. The spec requires consumers to tolerate broken links, missing indexes, and unknown types. That tolerance keeps readers working, and it also means nothing forces your bundle to stay healthy. Karpathy’s gist included a lint pass for a reason: contradictions, orphaned pages, stale claims. Keep it, and run it the way you lint code, on a schedule, with findings that reach a human.

Where to start

Pick the knowledge that already hurts. The runbook nobody can find during an incident, the onboarding doc that’s wrong in ways only one person knows. One domain, not the whole org.
Let the agent do the conversion. Paste the spec into your coding agent, point it at the existing folder of docs, and have it refactor them into a bundle. This is exactly the bookkeeping LLMs are good at, and it works as well on a wiki export as on a fresh start.
Put the bundle where the code lives. Same repo or a sibling, but in git, behind pull requests. The day a knowledge change gets a review comment is the day the bundle becomes trustworthy.
Wire it into the loop. Agents read index.md first and drill down only when a concept earns it, which keeps the context window small. The memory file I told you to write before the loop now has a format, and every agent you run, in whatever harness you built, can read the same one.

The advice from June holds: write the memory file before the loop. What changed is that the file no longer has to be a private dialect. There’s now a one-page, git-native spec for the layer your agents think with, and the smallness that makes it look trivial is the property that lets it spread. The loop does the typing. The wiki does the remembering. And the remembering is now something you can put in a pull request and hand to the next agent, like everything else you ship.

Wire Pulumi context into your agents

Stop Prompting. Design the Loop.

Engin Diri — Tue, 09 Jun 2026 00:00:00 +0000

For about two years, the unit of work with a coding agent was the prompt. You wrote a good one, you gave it enough context, you read what came back, and you wrote the next one. The agent was a tool, and you were holding it the entire time, one turn after another.

That part is ending. Addy Osmani, a director of AI at Google Cloud, has a name for what replaces it, and I have not stopped thinking about it since: loop engineering. You stop being the person who prompts the agent. You design the loop that prompts it for you.

In my phrasing: you stop being the thing that runs, and start designing the thing that runs. The leverage moves up a layer. What I want to do here is take an honest look at the pieces, and at the part nobody automates.

The leverage moved up a layer

The people building these tools have already made the jump. Peter Steinberger has been posting it as a monthly reminder.

Peter Steinberger (@steipete) on X.

Boris Cherny, who heads Claude Code at Anthropic, says the same thing about his own job. He does not prompt Claude anymore. He has loops running that prompt Claude and decide what to do next, scanning the issue tracker, the team chat, and the timeline for what to build. “My job is to write loops.”

A loop is a goal that prompts itself. You set the purpose, and the system keeps iterating until it’s met. In practice it finds the work, hands it out, checks the result, writes down what got finished, and decides the next thing, then it pokes the agent instead of you. You build that small system once and let it run.

Look closer, and a loop is really two loops nested. The inner one does the work against a spec. The outer one decides what the work should be: it watches an issue tracker, an error feed, a changelog, then writes the next spec and hands it down. Most people are still running that outer loop by hand, in their head, and calling it a backlog.

The part that surprised me is that this is barely a tooling problem anymore. A year ago a loop meant a pile of bash you wrote and maintained forever. Now the pieces ship inside the products, and the same shapes show up in Claude Code and in Codex. Osmani puts loop engineering one floor above the harness, the context and tooling you wire around a single agent. I wrote about that harness a couple of weeks ago. The loop is the thing that runs on top of it: it runs on a timer, it spawns helpers, and it feeds itself.

The five pieces, and the one that holds them together

Strip loop engineering down and you get roughly five building blocks, plus one place to remember things. Both Claude Code and Codex have all five now. The names differ here and there; the capability is the same.

Automations are the heartbeat. They are what make a loop an actual loop and not one run you did once. A prompt or command on a cadence, a scheduled task, a hook that fires at a point in the agent’s lifecycle, or a job on CI that keeps running after you close the laptop. Discovery and triage run themselves, and the findings that matter come to you.
Worktrees keep parallel from turning into chaos. The second you run more than one agent, the files start colliding. Two agents writing the same file is the same headache as two engineers committing to the same lines with nobody talking first. A git worktree is a separate working directory on its own branch, so one agent’s edits cannot touch another’s checkout.
Skills are intent, written down. An agent starts every session cold and fills any hole in your intent with a confident guess. A skill is that intent written on the outside: the conventions, the build steps, the “we don’t do it like this because of that one incident,” recorded once where the agent reads it every run. Without skills, the loop re-derives your whole project from zero every cycle.
Connectors let the loop touch your real tools. Built on MCP, they let the agent read the issue tracker, query a database, hit a staging API, or drop a message in chat. This is the difference between an agent that says “here is the fix” and a loop that opens the pull request, links the ticket, and pings the channel once CI goes green.
Sub-agents keep the maker away from the checker. The model that wrote the code is far too generous grading its own homework. A second agent with different instructions, and sometimes a different model, catches the things the first one talked itself into. Worktrees and a cold-context reviewer are two pieces I have written about before, back when the question was running agents in parallel without them trampling each other.

Then the sixth thing: memory. A markdown file, a Linear board, a state file, anything that lives outside the single conversation and holds what is done and what is next. It sounds too dumb to matter, and it’s the whole game. The model forgets everything between runs, so the memory has to live on disk, not in the context window. The agent forgets. The repo does not.

What makes a loop hold together

A loop running unattended is also a loop making mistakes unattended. The one thing that keeps it honest is verification, and verification needs an oracle, something outside the model that returns a hard yes or no. Passing tests, a clean build, a green pipeline, a real production signal. Without an oracle, the loop compounds confidently wrong work, faster than you can read it.

The cleanest version of this already ships in the tools. Claude Code’s /goal keeps working across turns until a condition you actually wrote holds, something like “every test in auth/ passes and lint is clean,” and after every turn a separate, faster model reads the transcript and decides whether you are there yet. The agent that wrote the code is not the one that grades it. That is the maker-and-checker split applied to the stop condition itself. Codex’s /goal reaches the same finish line a different way: the agent audits its own work against the evidence before it can call the goal done.

What the loop still won’t do for you

The loop changes the shape of the work. It does not take it off your desk. And a few things get sharper as the loop gets better, not softer.

Verification is still on you. The split reviewer is what makes “it’s done” mean something, but “done” is a claim, not a proof. Your job is still to ship code you confirmed works, which is harder to remember when the diff arrived while you were at lunch.

The bill comes in two currencies. Tokens and attention. A single unattended run can burn through millions of tokens, and that is only worth it when the tokens buy something worth more than they cost. The quieter trap is the second currency: memory is what lets a loop compound over time, and slop compounds right alongside it. A loop pointed at a vague goal does not get tired and stop. It gets faster.

Your understanding rots if you let it. The faster the loop ships code you did not write, the wider the gap between what exists in the repo and what you actually understand. A smooth loop grows that gap faster, not slower, unless you read what it made. The comfortable posture, where you stop having an opinion and take whatever the loop gives back, is the risky one. Two engineers can build the exact same loop and get opposite results, one moving faster on work they understand deeply, the other avoiding the work entirely. The loop cannot tell which one you are.

When the loop reaches production

Most of this thinking grew up around application code, where a bad run costs you a revert. When the loop reaches into infrastructure, the blast radius is a production outage rather than a revert, and the verification bar has to rise to meet it. The upside is that infrastructure hands the loop a better oracle than application code does. A plan diff is deterministic and machine-readable, a policy check returns a hard verdict, and drift and cost are numbers you can put a threshold on. A reviewer, whether human or agent, can read the change cold, with no memory of the prompt that produced it. That cold-context check is exactly what an unattended loop needs, and it’s the reason an infrastructure loop can be built to hold together while you sleep. Pulumi Neo reasons over the state graph directly, so the checker grounds every claim in what the change actually does, not in what the writer says it does.

Give your loop a real oracle

Infrastructure gives an agent loop a strong oracle: a deterministic plan diff to read and policy checks that return a hard verdict before anything ships. Wire that verification in through the Pulumi MCP server, Agent Skills, or Pulumi Neo.

Get started

Where to start

Pick the loop you can actually trust first. In order:

Start where “done” is unambiguous. CI triage, dependency bumps, a flaky-test hunt, a failing job you keep re-running by hand. Loops need an oracle, so begin where the oracle already exists.
Write the memory file before the loop. One markdown file, or a board. What is done, what is next, what was tried and failed. This is the spine, and everything else hangs off it.
Split the checker from the maker. Use /goal with a verifiable condition, or a second agent with its own instructions. Never let the agent that did the work be the one that decides the work is finished.
Cap it, then read everything. A max-iteration count, a token budget, a teardown step. Run it once, end to end, then read every line it shipped. The first run is the measurement, not the payoff.

Then look at what you built. You designed it once, and it ran without you steering each step. That is the real shift. But the leverage only holds if you wire the loop like an engineer, not like someone looking for permission to stop thinking. Read what it ships. Keep an opinion. Judgment is the one part that does not move up a layer.

The loop will do the typing. The thinking is the work.

See how Pulumi Neo closes the loop on your infrastructure

Build an EKS Environment Factory with Pulumi and vCluster

Pablo Seibelt — Thu, 04 Jun 2026 00:00:00 +0000

AWS reports in an AWS Architecture Blog case study that Deloitte’s move to a virtual cluster model on Amazon EKS resulted in 89% faster testing environment provisioning. By consolidating dozens of disparate clusters into a single host cluster with over 50 vCluster instances, the case study says Deloitte saved about 500 QA hours per year. This “Environment Factory” pattern allows platform teams to provide isolated, ephemeral Kubernetes environments on demand without the cost or lag of full cluster provisioning.

This post adapts that general architecture with Pulumi to orchestrate Amazon EKS Auto Mode and vCluster.

The problem: environment sprawl and provisioning lag

Traditional development workflows often rely on one full EKS cluster per developer or feature branch. While this provides strong isolation, it introduces major pain points. Provisioning a full cluster can take 15 minutes or more, which slows down CI/CD pipelines. Managing dozens of clusters also leads to high costs and significant operational overhead.

Platform teams need a “soft multi-tenancy” model. This model should feel like a dedicated cluster to the developer but run on shared infrastructure to keep costs low and startup times fast.

Architecture overview: the host and the tenants

The environment factory architecture consists of two main layers.

Host cluster: A single, reliable EKS cluster managed with EKS Auto Mode. This cluster provides the underlying compute, networking, and storage.
Tenant environments: Virtual clusters (vCluster) running as pods within host namespaces.

According to the vCluster architecture, the virtual control plane handles API requests while a syncer maps virtual resources to the host cluster. This separation allows tenants to manage their own CRDs, namespaces, and RBAC while platform teams use quotas, NetworkPolicies, pod security, IAM boundaries, and node isolation controls to protect the host and other tenants.

Implementation: the EKS Auto Mode host

EKS Auto Mode simplifies the host cluster by automating infrastructure management. It handles node provisioning, scaling, and updates based on pod requirements.

The following snippet shows how to define an EKS cluster with Auto Mode enabled using Pulumi.

import * as awsx from "@pulumi/awsx";
import * as eks from "@pulumi/eks";
import * as k8s from "@pulumi/kubernetes";
import { SubnetType } from "@pulumi/awsx/ec2";

const clusterName = "environment-factory";

const vpc = new awsx.ec2.Vpc("environment-factory", {
 enableDnsHostnames: true,
 cidrBlock: "10.0.0.0/16",
 subnetSpecs: [
 {
 type: SubnetType.Public,
 tags: {
 [`kubernetes.io/cluster/${clusterName}`]: "shared",
 "kubernetes.io/role/elb": "1",
 },
 },
 {
 type: SubnetType.Private,
 tags: {
 [`kubernetes.io/cluster/${clusterName}`]: "shared",
 "kubernetes.io/role/internal-elb": "1",
 },
 },
 ],
 subnetStrategy: "Auto",
});

// Create an EKS cluster with Auto Mode enabled.
const hostCluster = new eks.Cluster("host-cluster", {
 name: clusterName,
 authenticationMode: eks.AuthenticationMode.Api, // Use API authentication mode for EKS access entries.
 vpcId: vpc.vpcId,
 publicSubnetIds: vpc.publicSubnetIds,
 privateSubnetIds: vpc.privateSubnetIds,
 autoMode: {
 enabled: true,
 },
});

const hostProvider = new k8s.Provider("host-provider", {
 kubeconfig: hostCluster.kubeconfig,
});

Implementation: the environment factory

Once the host cluster is ready, we can build the factory that stamps out tenant environments. Each tenant needs a dedicated namespace, resource quotas, and the vCluster itself.

Tenant guardrails

Before installing vCluster, we set up a namespace and resource quotas to ensure one tenant cannot consume all host resources.

import * as k8s from "@pulumi/kubernetes";

// Define a tenant namespace on the host cluster.
const tenantNamespace = new k8s.core.v1.Namespace("tenant-alpha", {
 metadata: { name: "tenant-alpha" },
}, { provider: hostProvider });

// Apply resource quotas to the tenant namespace.
const quota = new k8s.core.v1.ResourceQuota("tenant-quota", {
 metadata: { namespace: tenantNamespace.metadata.name },
 spec: {
 hard: {
 pods: "20",
 "requests.cpu": "4",
 "requests.memory": "8Gi",
 "limits.cpu": "8",
 "limits.memory": "16Gi",
 },
 },
}, { provider: hostProvider });

// Define a Role for the tenant within their namespace.
const tenantRole = new k8s.rbac.v1.Role("tenant-role", {
 metadata: { namespace: tenantNamespace.metadata.name },
 rules: [{
 apiGroups: [""],
 resources: ["pods", "services", "configmaps", "secrets"],
 verbs: ["get", "list", "watch", "create", "update", "patch", "delete"],
 }],
}, { provider: hostProvider });

// Bind the Role to a tenant user or group.
const tenantRoleBinding = new k8s.rbac.v1.RoleBinding("tenant-role-binding", {
 metadata: { namespace: tenantNamespace.metadata.name },
 subjects: [{
 kind: "User",
 // Replace "tenant-user" with the IAM-mapped user or group for this tenant.
 name: "tenant-user",
 apiGroup: "rbac.authorization.k8s.io",
 }],
 roleRef: {
 kind: "Role",
 name: tenantRole.metadata.name,
 apiGroup: "rbac.authorization.k8s.io",
 },
}, { provider: hostProvider });

For production use, map these Kubernetes identities to IAM principals using EKS Access Entries, with the legacy aws-auth ConfigMap still appearing in older clusters.

Deploying vCluster with Helm

We use the kubernetes.helm.v3.Release resource to install vCluster. This resource provides controlled Helm lifecycle management for the vCluster release. The values block should be adjusted for each tenant profile to control resource synchronization and control plane behavior. Review the vCluster release notes when changing chart versions because values schema and generated secret names can change across releases.

import * as k8s from "@pulumi/kubernetes";

// Install vCluster using the Helm Release resource.
const vcluster = new k8s.helm.v3.Release("vcluster-alpha", {
 name: "vcluster-alpha",
 chart: "vcluster",
 version: "0.20.0", // Tested with vCluster 0.20.x; review release notes before changing versions.
 repositoryOpts: {
 repo: "https://charts.loft.sh",
 },
 namespace: tenantNamespace.metadata.name,
 values: {
 // Explicit sync configuration; adjust per tenant profile.
 sync: {
 toHost: {
 pods: { enabled: true },
 },
 },
 },
}, { provider: hostProvider });

Accessing the virtual cluster

The vCluster generates a kubeconfig that allows developers to interact with the virtual API server. We must treat this kubeconfig as a secret, and the endpoint in that kubeconfig must be reachable from the Pulumi runner before using it to create resources inside the virtual cluster.

import * as pulumi from "@pulumi/pulumi";
import * as k8s from "@pulumi/kubernetes";

// Retrieve the vCluster kubeconfig from the generated secret.
// The vCluster-generated secret can lag behind Helm release readiness on first creation,
// so teams may choose an explicit readiness check or rerun after the virtual control plane initializes.
const vclusterKubeconfig = k8s.core.v1.Secret.get("vcluster-secret",
 pulumi.interpolate`${tenantNamespace.metadata.name}/vc-vcluster-alpha`,
 {
 provider: hostProvider,
 dependsOn: [vcluster],
 }
).data.apply(data => Buffer.from(data["config"], "base64").toString());

// Export the kubeconfig as a secret.
export const tenantKubeconfig = pulumi.secret(vclusterKubeconfig);

// Create a provider for the virtual cluster using the secret kubeconfig.
const vclusterProvider = new k8s.Provider("vcluster-provider", {
 kubeconfig: tenantKubeconfig,
});

Provision environments on demand

Model your host cluster, vCluster tenants, and guardrails in Pulumi so your platform team can hand developers isolated test environments and clean them up as code.

Get started

Operational caveats

RBAC and permissions: vCluster generates default RBAC rules that work for most scenarios. However, if your host cluster is heavily locked down, you may need to provide additional permissions to the vCluster service account.
Helm release previews: When using kubernetes.helm.v3.Release, Pulumi previews may not show every detail of the rendered Kubernetes resources. It primarily tracks the state of the Helm release itself.
EKS Auto Mode node lifetime: EKS Auto Mode uses immutable AMIs and has a 21-day node lifetime. Kubernetes reschedules vCluster pods and tenant workloads when nodes are replaced, so configure replicas, PodDisruptionBudgets, requests, and persistent storage for disruption tolerance.

Conclusion: ephemeral environments at scale

By combining Pulumi with EKS Auto Mode and vCluster, you can build a scalable environment factory. This approach provides the isolation developers need while maintaining the speed and cost-efficiency required by platform teams.

The snippets provided here are adapted for illustration. In a production environment, you would likely wrap these resources into a Pulumi ComponentResource to provide a clean, reusable API for your internal developers. When a feature branch is merged, deleting the Pulumi stack removes the resources managed by that stack, but validate namespace finalizers, persistent volume reclaim policies, and external cloud artifacts as part of cleanup.

For more on managing EKS with Pulumi, see the EKS guide.

Why Choose Pulumi Over Terraform?

Pablo Seibelt — Tue, 02 Jun 2026 00:00:00 +0000

Terraform is a proven infrastructure as code tool with a large provider and module ecosystem. Many teams choose Pulumi when they want to keep that infrastructure as code model, but write and maintain infrastructure with general-purpose programming languages, familiar package managers, IDEs, testing, and software engineering patterns, while still understanding the refactoring tradeoffs in Terraform’s own module refactoring guidance.

Why choose Pulumi over Terraform? Pulumi’s language SDKs let teams define cloud infrastructure in TypeScript, Python, Go, C#, Java, or YAML while adding first-class workflows for refactoring with Pulumi aliases, secrets, protect, retainOnDelete, deleteBeforeReplace, replaceOnChanges, provider resources, Pulumi stacks, testing, and incremental migration with pulumi import. Pulumi does not remove every hard problem in cloud infrastructure, but it gives teams stronger tools for many day-to-day pain points.

Executive summary

Pulumi is often a better fit when infrastructure code needs to behave like application code: reviewed, tested, packaged, refactored, and shared across teams. The biggest advantages show up when teams need safer refactors, encrypted secret values, reusable components, clearer provider resources, and guardrails around destructive changes.

The tradeoff is important: Pulumi is still an infrastructure as code engine. Provider bugs, cloud API eventual consistency, drift, preview-time unknowns, and poorly designed abstractions still require engineering discipline. The advantage is not magic. The advantage is a stronger programming model and a more familiar developer workflow.

Need	Terraform pattern	Pulumi advantage	What still needs care
Languages and tooling	HCL plus Terraform-specific functions and expressions	Pulumi supports general-purpose languages, YAML, and now HCL natively, with the normal IDE, test, and package workflows for each	Teams still need code review and shared conventions
Refactoring	Moved blocks or state commands for resource identity changes	Pulumi aliases can map old resource identities to new ones during refactors	Aliases must model the old identity correctly
Secrets	Sensitive values can still require careful state and plan handling	Pulumi tracks secrets and encrypts secret values in state	Secrets are still available to code at runtime
Lifecycle safety	Lifecycle meta-arguments and plan review	Pulumi resource options such as protect, retainOnDelete, deleteBeforeReplace, and replaceOnChanges make intent explicit	Provider behavior and replacement semantics still matter
Environments	Workspaces or separate configurations	Pulumi stacks model environments with per-stack config, secrets, history, and outputs	Stack boundaries still need thoughtful design
Code reuse	Modules and HCL composition patterns	Pulumi components and packages use normal language abstractions	Over-abstracted components can become hard to use
Imports and migration	Import blocks, generated config, and state operations	`pulumi import` and migration tooling support gradual adoption	Imported code still needs review and cleanup
Terraform state	S3, Azure Blob, or Terraform Cloud backends	Pulumi Cloud can serve as a Terraform state backend with encrypted storage, locking, history, and RBAC, while you keep using the Terraform or OpenTofu CLI	State still needs a clean migration plan as resources move to Pulumi
Provider wiring	Provider inheritance and aliases inside modules	Explicit provider resources make multi-region and multi-account wiring visible in code review	Provider versions and bugs can still affect deployments
Testing	Validation, plan review, and external test harnesses	Pulumi programs can use normal unit and integration test frameworks	Tests complement previews, they do not replace them
Drift detection	Refresh and refresh-only plans, plus external scheduling	`pulumi refresh` reconciles state, and Pulumi Cloud adds scheduled drift detection and remediation on a configurable cadence	Detection still depends on provider behavior and a healthy state backend
Caveats	Declarative planning still has unknowns and drift	Pulumi improves the workflow around many pain points	It does not eliminate provider bugs or eventual consistency

Use programming languages and familiar tools

Terraform modules are powerful, but larger HCL codebases can require teams to maintain separate conventions for composition, validation, and reuse. Pulumi lets infrastructure teams use the features of whichever supported programming language they choose, such as classes, functions, types, loops, package managers, linters, and test frameworks.

Teams with HCL muscle memory are not left out, either. Pulumi now supports HCL natively as one of its languages, alongside Python, TypeScript, Go, C#, Java, and YAML. Part of a team can keep authoring in HCL while the project still benefits from Pulumi components, testing, and the same engine and package workflows as every other language.

For example, a platform team can wrap a standard storage pattern in a ComponentResource and share it like any other TypeScript abstraction:

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";

interface WorkQueueArgs {
 visibilityTimeoutSeconds: number;
}

class WorkQueue extends pulumi.ComponentResource {
 public readonly queueUrl: pulumi.Output<string>;

 constructor(name: string, args: WorkQueueArgs, opts?: pulumi.ComponentResourceOptions) {
 super("platform:queue:WorkQueue", name, {}, opts);

 const queue = new aws.sqs.Queue(`${name}-queue`, {
 visibilityTimeoutSeconds: args.visibilityTimeoutSeconds,
 }, { parent: this });

 this.queueUrl = queue.url;
 this.registerOutputs({ queueUrl: this.queueUrl });
 }
}

const jobs = new WorkQueue("image-jobs", {
 visibilityTimeoutSeconds: 60,
});

Refactor infrastructure without surprise replacement

Renaming a resource, moving it into a component, or reorganizing a project should not automatically mean replacing production infrastructure. Pulumi aliases let you tell Pulumi how a resource used to be addressed, so refactors can preserve resource identity when the old and new resources represent the same cloud object.

const queue = new aws.sqs.Queue("app-jobs", {
 visibilityTimeoutSeconds: 60,
}, {
 aliases: [{ name: "jobs" }],
});

Aliases are not a substitute for review. They work when the old identity is modeled correctly, including details such as name, parent, type, project, and stack when those changed.

Handle secrets with encrypted configuration and secret outputs

Secrets are one of the most common places where infrastructure workflows become risky. Terraform has sensitive values and backend guidance, but teams still need to understand how plans, state, outputs, and backend access interact. Pulumi treats secrets as first-class values, encrypts them in state, and preserves secrecy as values flow through outputs.

const config = new pulumi.Config();
const dbPassword = config.requireSecret("dbPassword");

const passwordParameter = new aws.ssm.Parameter("db-password", {
 type: "SecureString",
 value: dbPassword,
});

This improves the default experience, but it’s not runtime isolation. In the TypeScript SDK, config.requireSecret("dbPassword") retrieves secret configuration, and your program can still access the decrypted value while it runs, so reviews, least privilege, and secret-provider choices still matter. If a value starts as a plain input instead of coming from requireSecret, pulumi.secret(...) can mark it as secret.

For secrets that shouldn’t live in stack config at all, Pulumi ESC (Environments, Secrets, and Configuration) centralizes them in environments that your stacks consume through config. ESC can pull secrets dynamically from external stores such as HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and 1Password, and mint short-lived OIDC credentials for AWS, Azure, and GCP. That lets you wire an environment into a Pulumi program instead of storing long-lived credentials in state.

Add safer lifecycle controls for destructive changes

Infrastructure mistakes are expensive when they replace or delete stateful resources. Pulumi gives teams explicit resource options for safety-sensitive intent, such as protect, retainOnDelete, deleteBeforeReplace, and replaceOnChanges.

const database = new aws.rds.Instance("orders-db", {
 instanceClass: "db.t4g.micro",
 allocatedStorage: 20,
 engine: "postgres",
 username: "app",
 password: dbPassword,
}, {
 protect: true,
 retainOnDelete: true,
});

These controls are guardrails, not guarantees. Provider bugs, cloud API eventual consistency, and replacement behavior still require preview review and operational judgment. replaceOnChanges applies to custom resources only, not component resources.

Model environments with stacks

Terraform workspaces can represent environments, but many teams eventually need stronger boundaries for configuration, secrets, history, and cross-environment outputs. Pulumi stacks make environment boundaries explicit and pair them with per-stack config and outputs.

const networking = new pulumi.StackReference("acme/networking/prod");
const vpcId = networking.requireOutput("vpcId");

const appSecurityGroup = new aws.ec2.SecurityGroup("app-sg", {
 vpcId,
 ingress: [{
 protocol: "tcp",
 fromPort: 443,
 toPort: 443,
 cidrBlocks: ["10.0.0.0/8"],
 }],
 egress: [{
 protocol: "-1",
 fromPort: 0,
 toPort: 0,
 cidrBlocks: ["0.0.0.0/0"],
 }],
});

Cross-stack references are cleaner than sharing an entire remote state file, but they are still dependencies. Keep stack outputs intentional and avoid turning one stack into a global variable bag.

Test infrastructure with normal language tooling

Because Pulumi programs are real programs, infrastructure testing can use familiar test runners and assertions. Teams can test component defaults, naming conventions, required tags, and policy assumptions before a deployment reaches production.

pulumi.runtime.setMocks({
 newResource: (args) => ({
 id: `${args.name}_id`,
 state: args.inputs,
 }),
 call: (args) => args.inputs,
});

Testing does not replace previews. It catches a different class of problems: broken abstractions, missing required inputs, invalid defaults, and regressions in shared components.

Wire providers explicitly

Provider configuration is another place where explicit code can reduce ambiguity. In Terraform, provider inheritance and aliases are often managed across module boundaries. In Pulumi, provider resources are normal resources that can be passed through resource options, which makes multi-region or multi-account deployments easier to follow in code review.

const west = new aws.Provider("west", {
 region: "us-west-2",
});

const east = new aws.Provider("east", {
 region: "us-east-1",
});

const primary = new aws.sqs.Queue("primary-jobs", {}, {
 provider: west,
});

const replica = new aws.sqs.Queue("replica-jobs", {}, {
 provider: east,
});

The provider object does not remove provider versioning or schema-change risk, but it makes provider wiring visible in the same language and review flow as the rest of the program.

Detect and reconcile drift

Infrastructure drifts when something changes outside your IaC tool: a hotfix in the console, another controller, or a manual break-glass change. Pulumi gives you first-class tools to find and fix it instead of leaving it to chance. pulumi refresh reconciles your state with what is actually running in the cloud, and pulumi preview --diff shows what the next update would change.

For teams that want this continuously, Pulumi Cloud adds scheduled drift detection and remediation that runs on a configurable cadence and can automatically remediate drift when it is detected. That turns finding and correcting out-of-band changes into a managed workflow rather than something a person has to remember to check.

Drift detection still depends on accurate provider behavior and a healthy state backend, so it complements review and operational discipline rather than replacing them.

Adopt Pulumi at your own pace

Bring your existing Terraform infrastructure across one stack at a time, using general-purpose languages and the software workflows your team already relies on.

Get started

Import and migrate incrementally

Teams rarely get to rebuild infrastructure from scratch. Pulumi supports incremental adoption with pulumi import, generated code, and Terraform interoperability paths. That makes it possible to start with one resource, one component, or one stack instead of forcing a big-bang migration.

Pulumi also supports interoperability paths for teams that need to bring existing Terraform assets forward over time, including Terraform provider access and migration workflows. That makes migration an engineering sequence, not an all-or-nothing rewrite.

const importedRepository = new aws.ecr.Repository("app", {
 name: "existing-app-repo",
}, {
 import: "existing-app-repo",
});

The CLI flow can also generate declarations with pulumi import. Generated code is a starting point, not a finished architecture. Review names, options, providers, secrets, and component boundaries before treating imported resources as production-ready Pulumi code.

You also don’t have to do it alone. Pulumi provides self-serve conversion tools and expert migration services, and for teams leaving HashiCorp, credits you can apply toward Pulumi to avoid paying for two tools at once, so budget and timing don’t have to block getting started.

Manage Terraform state in Pulumi Cloud

You don’t have to rewrite anything to start getting value from Pulumi. Pulumi Cloud can serve as a Terraform state backend, letting you store and manage Terraform state alongside your Pulumi stacks. Your team can keep using the Terraform or OpenTofu CLI for day-to-day operations while gaining encrypted state storage, update history, state locking, role-based access control, audit policies, and unified resource visibility through Pulumi Insights — with agentic infrastructure coding through Neo on top.

It uses Terraform’s standard remote backend, so you point the CLI at Pulumi Cloud without changing your infrastructure code:

terraform {
 backend "remote" {
 hostname = "api.pulumi.com"
 organization = "your-pulumi-org"

 workspaces {
 name = "_dev"
 }
 }
}

From there, Pulumi can also read outputs from that state, so a new Pulumi stack can consume Terraform-managed values such as VPC IDs and subnet IDs while you migrate one piece at a time. When you’re ready to bring resources fully across, pulumi import --from terraform reads a .tfstate file and generates matching declarations, and pulumi convert --from terraform translates the surrounding configuration into your chosen language.

Storing Terraform state in Pulumi Cloud keeps both tools pointed at one system of record, which is what makes a gradual, low-risk migration practical.

What Pulumi does not magically fix

Pulumi does not eliminate cloud API eventual consistency. A deployment can finish successfully while downstream reads, controllers, or other operators still see stale state for a short window. That is a property of the cloud control plane, not of the IaC tool.

Pulumi also does not eliminate provider bugs. If a provider has a schema issue, a bad default, or a flaky update path, Pulumi still has to ride that provider behavior. Drift will still happen when infrastructure changes outside Pulumi, too. The difference is that Pulumi gives you first-class tooling to detect and reconcile it, as covered in Detect and reconcile drift above — but the drift itself, and the discipline to act on it, do not disappear.

Pulumi does not eliminate preview-time unknowns either. Some values are not known until deployment, so the plan can still contain uncertainty. Bad project decomposition and side-effect-heavy deployment code remain risks too, which is why testing, clear stack boundaries, and disciplined component design still matter.

OpenTofu compatibility caveat

OpenTofu users face many of the same infrastructure-as-code concerns around state, providers, drift, secrets, lifecycle behavior, and migration planning. This post stays Terraform-focused because that is where most teams begin the Pulumi comparison, but the same Pulumi capabilities are relevant when evaluating OpenTofu alternatives or hybrid migration paths.

Pulumi can also work with Terraform provider ecosystems, including long-tail providers that may not have a native Pulumi package yet. Treat that as an interoperability path, not a promise that every Terraform or OpenTofu workflow maps one-for-one without design work.

Get started with Pulumi

If your team is evaluating infrastructure as code options, start with the workflow that creates the most leverage: write infrastructure in the language your team already uses, test shared components, protect critical resources, and migrate one stack at a time.

To go deeper, get started with Pulumi or read the Terraform migration guide.

Five Stacks Before Lunch: The Parallel Coding Playbook for Pulumi

Engin Diri — Tue, 02 Jun 2026 00:00:00 +0000

AI coding has two shapes right now. One agent in a loop, sequential work, you babysitting the chat window. Call that 2x. Most teams live here. Five agents in worktrees, parallel work, fresh-context review on every change. Call that 10x. The trick: 2x is mostly prompting, 10x is mostly plumbing.

The parallel coding playbook is a five-pattern setup for running multiple AI coding agents at the same time without them stepping on each other: an issue used as the spec, a plan/build/validate loop, parallel git worktrees, fresh-session review, and a self-healing layer. The whole thing targets application code. The interesting question, and the one I keep ending up at, is what changes when the five agents are touching infrastructure.

2x is prompting, 10x is plumbing

2x is one human, one agent, one repo, one branch. The agent writes, you review, you tell it to try again, it tries again. The bottleneck is your attention. Whatever the agent’s raw throughput, your reading speed sets the ceiling.

10x moves you out of the per-change loop and into the issue loop. You write five issues with sharp acceptance criteria, send each one to its own agent in its own worktree, and let them plan, build, and validate end-to-end. You read five PRs at lunch instead of pair-programming on one all morning.

Concurrent isolation does the work. And isolation is mostly an infrastructure problem.

The five pillars

The five pillars, in one sentence each.

Issue is the spec. The GitHub issue carries the acceptance criteria. The pull request is the artifact that gets validated. Input and output of every implementation are versioned, scoped, and reviewable on their own.
Plan, build, validate. Three stages, three artifacts. A markdown plan you can read in thirty seconds. A build that produces a diff. A validate step that checks the diff against the spec.
Parallel worktrees. Each agent runs in its own git worktree so concurrent changes never trample each other. One repo, five working trees, five branches.
Fresh-session review. A different agent, a different conversation, no shared context, reads the output and judges it. The reviewer never sees the writer’s chat. An agent reviewing its own output in the same context is theater.
Self-healing layer. When the same issue keeps coming back, fix the system that allowed it. Update the rules, the skills, the AGENTS.md. The agent gets better; the bug class disappears.

The application-code version of this playbook leans on ports, node_modules, and databases to get isolation right. The infrastructure version has a different toolbox.

What changes when the agents are touching infrastructure

Walk the pillars again, this time with a Pulumi shop in mind.

Issue is the spec. For application code, the spec describes behavior. For infrastructure, the spec is a Pulumi component contract plus a Pulumi Policies excerpt. “The resulting bucket is private, lives in eu-west-1, has SSE-KMS, and is tagged owner=team-x.” That sentence compiles to a typed component signature and three policy assertions. The agent does not get to interpret “looks right.” The acceptance criteria are deterministic, which is the whole reason this works.

Plan, build, validate. Pulumi already ships the validate step. pulumi preview produces a deterministic, machine-readable diff a second reviewer can judge without the conversation that produced it. The plan is a markdown doc the agent writes before touching code. The build is pulumi up --target against a review stack scoped to the resources the issue covers. The validate step is the preview output plus the Pulumi Policies verdict.

Parallel worktrees. Worktrees alone are not enough. Two worktrees pointing at the same Pulumi stack will fight over state on the first concurrent up. The unit of isolation for infrastructure is the stack, not the worktree. Each worktree gets its own ephemeral review stack and its own ESC environment for credentials. State branches with the work, credentials branch with the work, and the cloud account does not see five agents elbowing each other.

Fresh-session review. The hardest part of the application-code version is keeping the reviewer cold. For infrastructure, the substrate hands you the cold context. The pulumi preview JSON has no memory of the prompt that produced it. A separate agent reading it has the same starting point a human reviewer has: a diff, a stack name, a policy report. Pulumi Neo reasons over the state graph directly, so the reviewer grounds every claim in what the change actually does, not what the writer says it does. Reviewer quality still depends on how well your policies cover the stack, but the cold-context part comes built in.

Self-healing layer. Most Pulumi Policies rule messages today read like assertions. “S3 bucket has no encryption.” A self-healing layer needs them to read like instructions. “S3 bucket has no encryption. Set serverSideEncryptionConfiguration with SSE-KMS to fix.” That single rewrite is the difference between an agent flailing and an agent fixing the violation on the first try. When the same rule keeps tripping, the fix is upstream of the next pull request: in the rules, in the skills, in the policy itself.

The five catches, infra edition

Every parallelism story has a catch list. The application-code version lists port conflicts, node_modules sprawl, database conflicts, token blowouts, and PR pile-up. The infrastructure equivalents map almost one to one.

Port conflicts become stack-name collisions. Two agents naming their stack dev and racing each other into Pulumi Cloud. The fix is the same hash-the-path trick the app-code playbook uses: derive the stack name from pulumi.getProject() plus a hash of the worktree path. Resource names follow the same pattern. Collisions go away.

node_modules sprawl becomes provider plugin sprawl, mostly already solved. Three worktrees each pulling their own copy of pulumi-aws would add up fast, except Pulumi already shares plugins through a single cache at ~/.pulumi/plugins. Identical provider versions are reused across worktrees automatically. Per-worktree language SDKs (node_modules, venv) still need the usual care, but the provider layer is free.

Database conflicts become state conflicts. Two agents racing each other into pulumi up on the same stack is the same hazard as two agents writing to the same migrated database. The app-code playbook reaches for Neon branches or per-worktree SQLite files to isolate state. The infra answer is simpler: each worktree gets its own review stack. State branches with the work, by construction.

Token blowouts become cloud spend per ephemeral stack. The cost vector flips. For app code, the worry is LLM bills. For infrastructure, the worry is what your five agents just spun up in five review stacks. The mitigations are boring and they work. Use TTL stacks to tear review stacks down on a schedule. Avoid retainOnDelete on review-stack resources so the teardown actually frees them. Cap retries per spec. Watch the bill.

PR pile-up is the same problem. Five reviewed diffs are still five things waiting on the merge queue. The infra-flavored mitigations: stack-scoped reviewers (the human who owns the stack approves the change to it), the Pulumi Cloud audit log for grouping by stack and time, and auto-merge for the narrow class of changes where the preview diff is clean and every policy passes. That last one is where most of the throughput hides.

Run any agent on your stacks

Pulumi hands every coding agent a deterministic preview, isolated stacks, and policy as code to work against, whether that agent is Claude Code, Cursor, or Pulumi Neo.

Get started

Where to start, this afternoon

Three steps, in order, on a stack with a small blast radius.

Write an AGENTS.md for the repo. Five paragraphs is enough. The component library, the stack naming convention, the policy rules, the review-stack TTL, and the one thing in this repo that bites every newcomer. Neo reads AGENTS.md natively, as do most coding agents. This file is the spec for how the agent should behave even before you write a spec for what it should build.
Cut a 24-hour review-stack TTL. Spin up a review stack on PR open, tear it down on PR close or after 24 hours, whichever comes first. This is the gate that turns “ephemeral” from a slogan into a line item that does not appear on next month’s bill.
Run three issues in parallel. Pick three open issues that touch unrelated resources. Spin up three worktrees, three review stacks, three ESC environments. Let each agent run end-to-end against its own stack. Then have a fourth agent read each preview JSON cold and produce a one-paragraph review. Read three PRs plus the reviewer’s summary at lunch.

That last step is the measurement. The first time you run it, half of the changes will fail validation. The second time, fewer. By the third time you will know whether your spec quality, your policies, and your stack hygiene are good enough to scale this to five, then ten, then to every issue tagged infra:fix.

If three issues finish cleanly, you have the substrate. If they do not, the gap is almost always in the spec or the policy rules, not the agent. Fix the spec, tighten the rule, run it again.

Five stacks before lunch

10x is five concurrent agents, working from five issues, against five stacks, behind five fresh-session reviews. The substrate is already there. Stacks isolate state. ESC isolates credentials. pulumi preview is the deterministic artifact a fresh reviewer can read cold. Pulumi Policies is the self-healing layer when you write the rule messages as instructions.

The remaining work is small and mostly wiring. Write the AGENTS.md. Cut the TTL. Pick three issues that touch unrelated resources. Read three PRs at lunch. Five stacks before the room empties out is a realistic Monday.

See how Pulumi Neo runs your stacks

Best AI Infrastructure Tools in 2026

Alex Leventer — Mon, 25 May 2026 00:00:00 +0000

“AI infrastructure tools” covers two distinct markets: infrastructure for AI (GPU clouds like CoreWeave, MLOps platforms like Weights & Biases) and AI for infrastructure (agentic platforms like Pulumi Neo that generate, deploy, and govern cloud resources for you). Most teams need tools from both categories, and picking the wrong one wastes budget and adoption goodwill.

The pressure to get this right is real. McKinsey research puts the productivity lift from generative AI in software development at 20–45%, which is great for application teams and a problem for platform teams trying to keep up with the resulting feature flow. Infrastructure investment is climbing on both fronts: more spend on the compute that trains and serves models, more spend on AI tools that manage everything else.

This guide covers both categories: the compute and MLOps stack in Part 1, and AI-powered infrastructure management in Part 2, where the more interesting product shift is happening.

AI infrastructure tools overview

Tools for building AI infrastructure

CoreWeave: GPU cloud built for AI workloads
Lambda Labs: straightforward GPU cloud for research and startups
Modal: serverless GPU compute
Weights & Biases: ML experiment tracking and model management
MLflow: open-source ML lifecycle platform
Hyperscaler AI platforms: AWS SageMaker, Google Vertex AI, Azure ML

AI-powered infrastructure management tools

Pulumi Neo: agentic AI with policy automation
Firefly AIaC: asset codification and IaC generation
env0 Cloud Compass: multi-IaC insights and analysis
Spacelift AI: run explanation and troubleshooting
Crossplane with Upbound: Kubernetes-native infrastructure
General-purpose code assistants: Copilot, Claude Code, Cursor, Gemini
AWS Application Composer: visual serverless builder

Quick picks

If you only have two minutes:

Enterprise compliance: Pulumi Neo. Executes changes (not only suggestions), ships with policy packs for CIS, HITRUST, NIST, and PCI DSS, and works with Terraform, CloudFormation, and resources created by hand.
Serious GPU compute: CoreWeave. Purpose-built for AI workloads, deep NVIDIA partnership, and prices that generally undercut the hyperscalers.
Best developer experience for ML: Modal. Decorate a Python function, get a GPU, pay by the second.
Open-source MLOps: MLflow. No vendor lock-in, runs anywhere, plays well with everything.

What is AI infrastructure?

The term covers two distinct categories that share almost no vendors.

Infrastructure for AI is the compute, storage, and orchestration that AI workloads run on. Training a large model is not a normal cloud workload: it wants thousands of GPUs talking to each other over fat, low-latency networks for weeks at a time. Inference is different again: lower latency, smarter batching, different hardware. General-purpose cloud was not designed for either case, which is why specialized GPU clouds and MLOps platforms exist.

AI-powered infrastructure management is the inverse: AI tools that manage cloud infrastructure. They generate infrastructure as code, run deployments, detect drift, and remediate policy violations. The pitch is that modern infrastructure (multi-cloud, containers, microservices, regulated workloads) has gotten too complex for humans to manage by hand and too varied for scripted automation to keep up with.

Most organizations end up needing both: somewhere to run their ML workloads, and something to keep the rest of the cloud sane.

Part 1: Tools for building AI infrastructure

These are the platforms you run AI and ML workloads on: GPU clouds for raw compute, MLOps platforms for the lifecycle around them.

CoreWeave

CoreWeave is the GPU cloud that broke out of the AI hype cycle into a real public company. They went public in 2025, signed a multi-billion-dollar capacity deal with OpenAI, and acquired Weights & Biases. Their thesis from day one was that AI workloads deserve infrastructure designed for AI workloads, not a GPU SKU bolted onto a general-purpose cloud.

License: Proprietary
Best for: Large-scale training and high-throughput inference; teams that need dedicated GPU capacity with first access to new NVIDIA hardware
Strengths: GPU infrastructure designed for AI; Kubernetes-native; direct NVIDIA partnership; handles distributed training at scale
Watch out for: Smaller global footprint than AWS/GCP/Azure; not a general-purpose cloud, so if you need RDS, S3, and a managed Kafka in the same provider, this isn’t it

Lambda Labs

Lambda has been the approachable GPU cloud for a long time. Environments come pre-configured with PyTorch and TensorFlow, and you can be running on an H100 in about as long as it takes to copy your SSH key.

License: Proprietary
Best for: Research teams, startups, and individual practitioners who want GPUs without a configuration tax
Strengths: Straightforward to start on; pre-configured deep learning environments; competitive on-demand pricing; strong learning resources
Watch out for: Smaller scale than CoreWeave or the hyperscalers; availability gets tight during demand spikes

Modal’s pitch is that you write a Python function, decorate it, and Modal handles the GPU. No capacity planning, no idle instances burning money overnight, no Dockerfile to maintain.

License: Proprietary
Best for: Variable ML workloads where reserved capacity would sit idle; data scientists who’d rather not learn Kubernetes
Strengths: Strong developer experience; serverless GPUs with automatic scaling; pay-per-second pricing; cold starts are fast for what they are
Watch out for: You give up infrastructure control. Not ideal for long training jobs that need reserved hardware or strict configuration requirements.

Weights & Biases

Weights & Biases is the de facto standard for ML experiment tracking and model management, integrated with essentially every framework and cloud you’d plausibly use. CoreWeave acquired the company in 2025, which has accelerated the joint roadmap but raised some neutrality questions for teams that prefer their tooling cloud-agnostic.

License: Proprietary with a free tier
Best for: ML teams that need shared experiment tracking, model versioning, and reporting
Strengths: Industry-leading experiment tracking and visualization; comprehensive model registry; strong team collaboration; broad integration surface
Watch out for: Costs scale quickly past the free tier; some teams self-host alternatives for data residency reasons

MLflow

MLflow is the leading open-source MLOps platform: experiment tracking, packaging, registry, and serving, with no lock-in. Originally built at Databricks, it’s now a broad open-source ecosystem with managed offerings from multiple vendors (including Databricks and the major clouds).

License: Apache 2.0
Best for: Teams that want MLOps without a vendor; or want the option to start managed and self-host later
Strengths: Open source; covers the full ML lifecycle; runs locally, on-prem, or managed; broad framework support
Watch out for: Self-hosting carries the usual operational tax; commercial alternatives have stronger collaboration UX out of the box

Hyperscaler AI platforms

The major clouds all sell end-to-end ML platforms. Each leads on the dimensions that line up with its parent cloud (Vertex for Google’s models and TPUs, SageMaker for AWS-native data pipelines, Azure ML for Microsoft-stack integration), but the wider integration with the rest of the cloud is the deciding factor.

AWS SageMaker: end-to-end ML on AWS, deeply integrated with S3 and Glue, with first-class connections to Lambda for serverless inference and to the rest of the AWS data stack. The default pick if your data already lives in AWS.
Google Vertex AI: Google’s ML stack, including TPUs for workloads that need them, plus access to Google’s foundation models. Strongest when paired with BigQuery.
Azure Machine Learning: the natural choice when the rest of your stack is Microsoft; first-party MLOps integrations across GitHub Actions, Azure DevOps, and Microsoft Fabric for downstream reporting. The right choice if you’re already an Azure shop with Microsoft compliance requirements.

The shared tradeoff: hyperscaler GPU compute typically runs 2–3x the per-hour price of specialized providers, and the platforms work best when you commit to them top to bottom. For organizations already inside one cloud, the unified billing and single support contract usually justifies the premium. For a new ML team starting from scratch, it rarely does.

Part 2: AI-powered infrastructure management tools

This is where the more interesting product shift is happening. Instead of running AI on infrastructure, these tools point AI at your infrastructure and let it do work. They’re a newer, AI-native layer on top of the broader infrastructure as code tooling landscape.

From code generation to agentic execution

Before the tool list, one distinction matters more than any feature comparison: whether the tool generates code or executes changes.

Code generation tools like GitHub Copilot suggest infrastructure code based on context. You review it, maybe edit it, run it yourself. The AI helps, but you’re still the one doing the work.

Agentic platforms generate the code and run it, with the guardrails you define. They understand your environment, handle multi-step workflows, and enforce policies on the way through. You describe the outcome; the platform makes it happen.

Capability	Code generation	Agentic execution
Generates infrastructure code	Yes	Yes
Understands infrastructure context	Limited	Deep
Executes changes	No	Yes
Handles multi-step workflows	No	Yes
Enforces policies automatically	No	Yes
Remediates drift and violations	No	Yes

Where you want to land on this spectrum is mostly a governance question, not a productivity one.

Pulumi Neo

Pulumi Neo is Pulumi’s agentic AI for infrastructure. The distinguishing claim is execution: Neo doesn’t only suggest a Terraform snippet, it figures out the right resources, generates the code, and runs the deployment inside whatever guardrails you’ve set.

License: Proprietary (Pulumi Cloud)
Best for: Platform engineering teams that want AI automation with real policy controls, especially in regulated industries

A few things that set it apart in practice:

Policy automation and compliance. Neo is integrated with Pulumi Insights and Governance, which ships pre-built policy packs for CIS benchmarks, HITRUST CSF, NIST SP 800-53, and PCI DSS. Detection and remediation run in the same loop: Neo finds a violation, generates a fix, and (subject to approvals) applies it. You can batch-remediate across stacks and accounts with prompts like “find and fix all unencrypted S3 buckets across our AWS accounts.”

Works with infrastructure you didn’t create with Pulumi. Neo’s governance applies to Pulumi-managed resources, Terraform state, CloudFormation stacks, and resources someone clicked together in the AWS console. That matters because the realistic adoption path is to point Neo at what you have, audit it, and gradually bring it under management, not to migrate everything first.

Progressive autonomy. Trust levels are configurable. Start with human approval for everything; loosen it for well-defined, low-risk operations as confidence builds; keep production and sensitive resources behind strict approvals. This is the part that tends to determine whether enterprises actually deploy agentic AI in anger, versus letting it sit as a sandbox toy.

IDE and CI/CD integration. The Pulumi MCP Server brings Neo into Cursor, Claude Code, Claude Desktop, Windsurf, and any other MCP-compatible client. The Pulumi Cloud UI is the home base for approvals, history, and remediation status. Neo also slots into CI/CD pipelines for pre-merge policy remediation.

Case studies:

Werner Enterprises reduced infrastructure provisioning time from 3 days to 4 hours using Pulumi.
Spear AI cut their Authority to Operate (ATO) timeline from an expected 1.5 years to roughly 3 months by using policy-as-code to evidence compliance controls for auditors.

Tradeoff to be honest about: Neo gets more valuable the deeper you are in the Pulumi ecosystem. If you’re running IaC, ESC, and policy packs already, Neo has a lot of context to draw on. If you’re kicking the tires, it’s still useful, but the differentiating capability (context-aware, policy-respecting agentic execution) is harder to feel.

Firefly AIaC

Firefly is an asset management platform with AI features bolted on top of a strong core. The core capability is asset codification: it discovers cloud resources you already have and generates the IaC for them.

License: Proprietary
Best for: Teams that need to codify existing cloud footprints or generate IaC from natural language

Strengths: solid asset discovery, multi-cloud coverage, natural-language IaC generation, drift detection with remediation hooks. Caveat: AI features here are supplementary to the asset management product, not the main event, and Firefly is less focused on agentic execution than on inventory and policy.

env0 Cloud Compass

env0’s Cloud Compass adds AI to env0’s IaC automation platform, focusing on analysis rather than autonomous execution.

License: Proprietary
Best for: Multi-IaC shops that want AI-generated PR summaries, drift explanations, and cost insights

Strengths: multi-tool support across Terraform, OpenTofu, Pulumi, and Terragrunt; AI-generated PR summaries; drift cause analysis; cost estimation. Caveat: this is analysis and explanation, not action: Cloud Compass complements an agentic tool rather than replacing one.

Spacelift AI

Spacelift’s AI work is focused on the post-run experience: explaining what happened in a deployment and helping troubleshoot failures.

License: Proprietary
Best for: GitOps shops that want AI assistance reading complex runs and diagnosing failed deployments

Strengths: AI-powered run explanation; troubleshooting guidance for failures; broad IaC tool support; mature CI/CD integration. Caveat: like Spacelift as a whole, this is observation and explanation, not generation or execution. Pair with something that writes the code.

Crossplane with Upbound

Crossplane brings Kubernetes-style declarative management to cloud resources. Upbound is the company that commercializes it, and is layering AI-native control-plane capabilities into the 2.0 generation.

License: Apache 2.0 (Crossplane); proprietary (Upbound)
Best for: Teams already deep in Kubernetes that want to manage cloud resources the same way

Strengths: Kubernetes-native model; native GitOps fit; very active OSS community; AI control-plane work emerging from Upbound. Caveat: the learning curve is real if you’re not already living in Kubernetes; the commercial AI features are still maturing.

General-purpose code assistants

General-purpose AI coding assistants are the tools your developers already have open: GitHub Copilot, Claude Code, Cursor, and Google’s Gemini and Antigravity. They write Terraform HCL, Pulumi programs, and CloudFormation templates competently, about as well as they write anything else.

License: Proprietary (subscription), varies by tool
Best for: Developers who want broad code assistance, including infrastructure code, inside their existing editor

Strengths: excellent line-by-line code completion; broad language support; first-class editor integration; trained on huge corpora. Caveat: no infrastructure context. They don’t know what’s in your account, what your policies are, or which subnet you should pick. Treat their IaC suggestions as first-pass scaffolding, not production output.

AWS Application Composer

Application Composer is AWS’s visual builder for serverless applications. Drag services onto a canvas, get a CloudFormation template out, with AI suggestions for service configuration along the way.

License: Proprietary (AWS, included)
Best for: Teams building AWS serverless apps who prefer a visual workflow

Strengths: visual development for serverless; direct AWS integration; AI suggestions for service configuration; emits CloudFormation. Caveat: AWS-only, CloudFormation-only, and best suited to serverless rather than general infrastructure.

Comparison tables

Infrastructure for AI

Tool	Category	Key strength	Limitation	Pricing	Best for
CoreWeave	GPU cloud	Purpose-built GPU infra, NVIDIA partnership	Not a general-purpose cloud	Per-GPU-hour	Large-scale AI training
Lambda Labs	GPU cloud	Approachable, pre-configured environments	Smaller scale	Per-GPU-hour	Research teams, startups
Modal	Serverless GPU	Developer experience, pay-per-second	Less infrastructure control	Pay-per-use	Variable ML workloads
Weights & Biases	MLOps	Industry-standard experiment tracking	Costs scale quickly	Free tier + paid	ML team collaboration
MLflow	MLOps	Open source, no lock-in	Self-hosting overhead	Free (self-hosted)	Flexible ML lifecycle
AWS SageMaker	Hyperscaler	AWS ecosystem integration	Higher cost, lock-in	Per-use	AWS-native orgs
Google Vertex AI	Hyperscaler	Google models, TPU access	Lock-in	Per-use	Google Cloud users
Azure ML	Hyperscaler	Microsoft integration, enterprise features	Lock-in	Per-use	Microsoft ecosystem

AI-powered infrastructure management

Tool	Approach	Key strength	Limitation	Pricing	Best for
Pulumi Neo	Agentic AI	Execution + policy automation	Best within Pulumi ecosystem	Pulumi Cloud tiers	Enterprise platform teams
Firefly AIaC	Asset management	Asset codification, IaC generation	AI is supplementary	Proprietary	Codifying existing infra
env0 Cloud Compass	Multi-IaC platform	Multi-tool support, PR analysis	Analysis, not execution	Proprietary	Multi-IaC environments
Spacelift AI	CI/CD platform	Run explanation, troubleshooting	Observation, not action	Proprietary	GitOps workflows
Crossplane / Upbound	Kubernetes-native	K8s patterns for infra	Requires K8s expertise	Open source + commercial	Kubernetes-native teams
Code assistants	Code assistant	Broad language support, IDE	No infrastructure context	Subscription	General code assistance
AWS Composer	Visual builder	Visual serverless development	AWS- and CFN-only	Included with AWS	AWS serverless apps

See agentic infrastructure in action

Pulumi Neo generates, deploys, and governs cloud infrastructure across the resources you already have, with the policy guardrails you define.

Explore Pulumi Neo

How to choose

There’s no universal best tool. Five questions sort the field quickly:

Cloud strategy. Multi-cloud means tools like Pulumi Neo, Firefly, env0, or Crossplane. Single-cloud commitment means hyperscaler-native tools may integrate more deeply (AWS Composer, SageMaker, and so on).
Team expertise. Programmers gravitate to tools that use real languages (Pulumi Neo, Pulumi IaC). Kubernetes teams find Crossplane natural; everyone else finds it steep. Teams that prefer visual workflows should look at AWS Composer or env0’s UI.
Compliance. Regulated industries (healthcare, finance, government) get the most value from tools with pre-built compliance packs and audit trails. Pulumi Neo’s CIS/HITRUST/NIST/PCI packs are the most direct fit. If preventative policy enforcement matters, prefer tools that block non-compliant deployments rather than flag them after the fact.
Existing footprint. Greenfield projects can use anything. Brownfield is where it gets interesting: Pulumi Neo works against Terraform, CloudFormation, and manually-created resources, which lets you adopt incrementally instead of migrating first. Mixed-IaC shops should also look at env0.
Budget. Open source first: MLflow for MLOps, Crossplane for Kubernetes-native infra. Open source is not free, though: self-hosting carries a real total cost of ownership in hosting, maintenance, and the expertise to operate it. Commercial tools (Pulumi Cloud, env0, Spacelift) fold that operational cost into the price, on top of support, SLAs, and the enterprise-tier features open source can lack.

Before adopting anything, get visibility into what you have today, pilot on staging where mistakes are cheap, and define success metrics up front: time to provision, policy violation rates, mean time to remediate. The best AI infrastructure tool is the one your team will actually use, which means meeting developers where they already work.

Key trends and outlook

From copilots to agents. “AI suggests code” and “AI runs the deploy” are different products with different governance implications. The teams getting value from agentic tools have figured out which tasks to delegate fully, which to keep human-in-the-loop, and which to leave alone.

Progressive autonomy. Enterprise adoption follows a predictable shape: visibility → recommendations → human-approved execution → autonomous execution for well-understood scenarios. Tools that support that graduation will see stronger enterprise traction than tools that force an all-or-nothing choice.

Policy as the control plane. As AI takes on more infrastructure tasks, policy frameworks become the primary control plane. Done well, policy becomes an enabler (guardrails that let you safely expand automation) rather than a brake on velocity.

MCP standardization. The Model Context Protocol is becoming the integration standard between AI assistants and infrastructure tools. The practical upshot is that the IDE is increasingly a viable surface for managing infrastructure, with AI mediating between natural language and the underlying APIs.

Consolidation. CoreWeave acquiring Weights & Biases and NVIDIA acquiring Run:ai both point toward integrated platforms across the AI infrastructure stack. For tool selection today, that’s an argument for picking vendors with clear strategic direction over point solutions likely to be acquired or out-competed.

Frequently asked questions

What is the best AI agent for cloud infrastructure management?

For enterprise governance plus true agentic capability, Pulumi Neo is currently the most complete offering: it executes changes (not just suggests them), integrates with pre-built compliance frameworks, and works with infrastructure regardless of how it was provisioned. For Kubernetes-native shops, Crossplane with Upbound’s emerging AI features is worth tracking.

How can I use generative AI to manage cloud infrastructure?

Start by identifying the repetitive, time-consuming infrastructure work in your team. The highest-value early use cases tend to be:

Code generation: write IaC from natural-language descriptions, then review.
Documentation: explain unfamiliar configurations and reduce onboarding time.
Troubleshooting: analyze logs, errors, and configs to suggest likely causes.
Security and compliance: scan for violations and generate fixes.
Full automation: for shops that want it, agentic platforms like Pulumi Neo execute provisioning workflows end-to-end with governance controls intact.

What is agentic AI for infrastructure?

Agentic AI for infrastructure means AI systems that autonomously execute infrastructure tasks, not just generate code suggestions. The difference from a code assistant is action: an agent understands your environment, respects your policies, and performs multi-step work (provisioning, configuration, security controls) within the boundaries you’ve defined.

How do AI agents improve DevOps workflows?

By automating the repetitive parts (provisioning, drift remediation, policy enforcement), reducing context-switching, and catching issues earlier. Teams that have rolled out agentic tools well report faster provisioning, fewer policy violations slipping into production, and quicker compliance remediation. The compounding effect (engineers freed for higher-value work as the agent absorbs the routine) is the actual point.

What’s the difference between AI code generation and agentic execution?

Code generation suggests IaC for a human to review and run. Agentic execution generates the code and runs it, with policy and governance enforced along the way. It’s the difference between a knowledgeable colleague who suggests an approach and a knowledgeable colleague who also ships the change with appropriate oversight.

Can AI generate Terraform or Pulumi programs?

Yes. Most general-purpose AI assistants (Copilot, Claude, Gemini, ChatGPT, Cursor) can produce Terraform HCL, Pulumi programs in TypeScript / Python / Go, and CloudFormation. Quality varies. Generic assistants lack environment context and will happily emit syntactically correct but operationally wrong code. Infrastructure-specific tools like Pulumi Neo generate code that’s aware of your existing resources, policies, and provider constraints.

Can AI help with infrastructure compliance and policy automation?

Yes, and this is one of the highest-leverage uses of AI in infrastructure. Tools like Pulumi Neo detect policy violations across your footprint (including resources created outside IaC), generate compliant remediation, and apply it with the approvals you require. Pre-built frameworks for CIS, HITRUST, NIST, and PCI DSS shorten what would otherwise be a long manual compliance project.

Are AI infrastructure tools secure for enterprise use?

Enterprise-grade ones are. Look for RBAC, full audit logging of AI actions, preventative policy enforcement (not just detection), and human-in-the-loop approvals for sensitive operations. SOC 2, data residency options, and configurable autonomy levels are table stakes. The risk to avoid is wiring a consumer AI assistant directly into a production cloud account without those controls.

How do I choose between different AI infrastructure tools?

Match the tool to your context: existing clouds and IaC, team skills, compliance requirements, budget. Enterprise platform teams with governance needs should evaluate Pulumi Neo first. MLOps-focused teams should look at Weights & Biases or MLflow. For general code assistance inside the editor, a general-purpose assistant like Copilot, Cursor, or Gemini is the default. Most organizations end up with more than one: a code assistant for daily development and an agentic platform for production infrastructure.

What are the best tools for machine learning infrastructure?

For GPU compute, CoreWeave leads at scale, Modal wins for variable workloads and developer experience, and the hyperscalers are the default pick if you’re already inside one of them. For experiment tracking and model management, Weights & Biases is the leading commercial platform; MLflow is the leading open-source one. Most teams pick on the deploy model and pricing fit rather than capability gap. For the cloud infrastructure underneath the ML workloads, the same infrastructure management story applies: Pulumi Neo can provision and govern ML infrastructure the same way it handles everything else.

Conclusion

Two categories, two problems. GPU clouds and MLOps platforms (CoreWeave, Lambda, Modal, hyperscaler trio, W&B, MLflow) solve the compute and lifecycle problem for running AI workloads. AI-powered infrastructure tools (Neo, Firefly, env0, Spacelift, Crossplane, code assistants, Composer) solve the management problem for everything else.

For GPU workloads, the choice mostly comes down to scale and where you already are. For infrastructure management, the real question is how much you actually want AI to do. Code assistants help you write IaC faster, but you’re still running it. Agentic platforms like Pulumi Neo execute changes and enforce policy on the way through, with the guardrails you control.

The pattern from teams getting real value: treat AI as a force multiplier on routine work (provisioning, drift, compliance) and keep human judgment in the loop for the architecture and the edge cases.

If you want to see agentic infrastructure management running against real resources, start with Pulumi Neo.

Ten More Things You Can Do With Pulumi Neo

Adam Gordon Bell — Tue, 19 May 2026 05:00:00 -0700

Last fall, after launching Pulumi Neo, we wrote up 10 things you could do with it. In the months that followed, as platform teams handed Neo more real work, we watched and listened, shipping a steady stream of features like plan mode, read-only mode, AGENTS.md, an integration catalog, cross-cloud migration, and task sharing. With today’s release, Neo extends beyond the Pulumi Cloud console into the Pulumi CLI, GitHub, and Slack.

So here are 10 more things you can do with Neo.

1. Deploy your app to AWS without writing IaC

Hand Neo a repo. Neo picks the right services — ECS, AWS Fargate, ALB — writes the Pulumi, and opens a PR.

The cloud infrastructure part of getting a new service running, especially one in a new language, is always a few hours of boilerplate: a VPC and subnets, an IAM role, security groups, a load balancer, DNS, and a TLS cert.

With Neo, that work collapses into a prompt. Point Neo at a repo and ask:

Deploy this app to AWS as a publicly accessible service.

Plan mode comes back with the resources Neo will create, named and sized: ECS running on AWS Fargate, an ALB, and the VPC wiring. Approve, and Neo writes the Pulumi program, runs a preview, and opens a PR. You, the human in the loop, merge it after review.

Neo planning a PR and deploying an app to AWS.

Start a Neo task Ask Neo to deploy your app to AWS and make a PR

2. Diagnose a slow API from metrics, logs, and code

Slow endpoints live at the seam between runtime metrics and the stack that runs them. Neo reads both and proposes a fix with the metric evidence as the rationale.

Production incidents often involve multiple tools. When the checkout endpoint’s p95 latency climbs from 200ms to 1.2s, the metric is in Datadog, but the cause might be somewhere in your AWS account: maybe RDS is out of IOPS, maybe the connection pool is too small, maybe the autoscaler isn’t keeping up. Connecting “this metric looks bad” to a recent backend change and then to a one-line fix in your Pulumi program is an exercise in detective work.

Neo’s integration catalog bridges this gap. With built-in Datadog APM, PagerDuty, and Honeycomb integrations sitting alongside your Pulumi state, Neo can read traces and metrics from the tools your team already uses and take action.

Ask Neo:

Find the scaling bottleneck on /checkout from the last 7 days of metrics and propose a fix.

Neo pulls the metric history, matches the Datadog tag db.cluster=checkout-rds to the RDS instance in your prod-checkout Pulumi stack, and opens a PR with a Pulumi diff that bumps the storage IOPS and raises the connection-pool ceiling. You review and roll out the fix.

Toggle on the Honeycomb integration so Neo can read traces and metrics alongside your Pulumi stacks.

3. Automate PagerDuty incident response from Slack

A page comes in. You paste it into your on-call channel and tag Neo, and Neo replies with the cross-system view you’d otherwise spend the first 20 minutes assembling.

On-call triage is often about getting up to speed quickly. You get paged because something is in the red, and you don’t know why.

You mention Neo in the on-call Slack channel:

@neo, what’s going on with this alert?

Neo starts querying metrics and traces. With PagerDuty and Datadog in the integration catalog, it correlates the alert with every deploy and stack change tagged with the alert’s service in the last hour, and finds the change that lines up:

Two deploys in the last hour touched services tagged service:checkout: checkout-api@a3f9c2 (12 min ago, app-layer deploy) and Pulumi stack prod-checkout-rds (45 min ago, decreased max_connections from 200 → 100). p99 latency inflection at 14:03 lines up with the stack change. Likely cause: the connection-pool reduction is starving the API under current load.

You ask a couple of clarifying questions in-thread, then ask Neo to open a rollback PR against the Pulumi stack.

Authorize PagerDuty and Datadog in Neo's settings. Neo can then read alerts in your on-call Slack channel, find the change that correlates, and open a PR when you ask.

4. Implement a Jira or Linear ticket end-to-end

Hand Neo a ticket number from Linear, Jira, or GitHub Issues. Neo reads the description and acceptance criteria, plans against your stack, and opens a PR.

Tickets often pile up not because they’re unimportant, but because they’re not urgent. Ongoing maintenance quietly accumulates. Bumping a provider version, centralizing secret management, working through small policy violations: each one matters, but none of them ever moves to the top of the queue. Explaining each one to an agent is its own overhead.

The fix is letting Neo read the ticket itself. Connect Linear integration or Jira automation through the integration catalog (GitHub Issues works too), and Neo pulls the ticket the same way an engineer would: title, description, acceptance criteria.

Ask Neo:

Implement CAD-1234 in our payments stack.

Neo reads the ticket, plans against your existing stack, opens a PR, and drops a comment back on the ticket. The ticket and the PR end up linked, and your backlog shrinks.

Neo running locally in the Pulumi CLI: fielding a Linear issue, analyzing the codebase, and producing a PR that upgrades multiple projects to the latest Pulumi and AWS provider versions.

Start a Neo task Implement a Linear ticket end-to-end

5. Audit and tighten over-privileged IAM roles

Neo audits each role against what your stack code actually does, and proposes scoped policies that improve your security posture.

IAM cleanup is the kind of work nobody has the time to prioritize. Production has 40 roles. Half of them started with s3:* because nobody had time to scope them, and the cleanup slips quarter to quarter.

Ask Neo:

Audit IAM permissions across my accounts and propose narrower policies for over-privileged stack-managed roles.

Neo cross-references each role’s policy against what the stack code actually calls, and opens a PR per role. The PR body lists the API calls Neo found in the stack code, like s3:GetObject on audit-logs-* and s3:PutObject on audit-logs-staging, as the justification for the scoped policy. The evidence sits next to the diff.

If you’re unclear about which roles count as in-scope or what your team considers over-privileged, start in plan mode and agree on that with Neo first.

Neo auditing an over-privileged IAM role and proposing a narrower policy, with the actually-used permissions as evidence.

Start a Neo task Audit IAM and tighten over-privileged roles

6. Migrate from AWS CDK onto your platform’s golden paths

Neo reads your existing AWS CDK app and lands a PR that swaps AWS’s defaults for your team’s published components.

CDK’s L2 constructs encode AWS’s defaults. s3.Bucket with encryption: BucketEncryption.S3_MANAGED is a sane choice, but it’s AWS’s idea of sane, not yours. A platform team that’s published its own components to the Pulumi Private Registry has already decided what your bucket defaults look like: encryption with the right KMS key, tagging by cost center.

Ask Neo:

Migrate the payments-vpc CDK stack to Pulumi using our published components.¹

Neo reads the source CDK app and your registry side by side. It maps each CDK construct to its closest team-published equivalent, clarifying with you where the mapping is ambiguous.

// Before (AWS CDK, AWS's defaults)
const bucket = new s3.Bucket(this, "Assets", {
 bucketName: "payments-assets",
 encryption: s3.BucketEncryption.S3_MANAGED,
 versioned: true,
});

// After (Pulumi, your team's published component)
import * as platform from "@payments/platform";

const bucket = new platform.Bucket("assets", {
 bucketName: "payments-assets",
 classification: "internal",
});

Start a Neo task Migrate CDK onto your golden paths

Neo handles Terraform and Azure ARM migrations the same way.

7. Containerize a service and migrate it to Kubernetes from a runbook

Write the containerization pattern down once. Every service after that is a prompt away.

Containerizing an application and moving it to Kubernetes involves several small decisions: which Docker image, what labels go on deployments, how ingress is wired, and how secrets reach the pod. But after a team has moved two or three services, the pattern is set. The decisions get written down in a runbook, and every subsequent migration is mostly the same shape.

Ask Neo:

Containerize the billing-api service and write its Kubernetes manifests, following our K8s migration runbook in Confluence.

Neo reads the source repo and the runbook in Confluence via the integration catalog and starts working on your request.

You can save this as a Neo skill that splits the work into multiple PRs — Dockerfile first, ECR config next, Deployment/Service/Ingress manifests after — and link back to each runbook convention for ease of review. The output reflects your conventions: the labels you actually use, the ingress class you’ve standardized on, and the External Secrets Operator config your team prefers.

You’re still the one reviewing the PRs and deciding what the cutover looks like in production. Neo follows your internal standards, so the new service ends up shaped like the last one you migrated.

Neo migrating a VM-based service to Kubernetes step by step, following the team's Confluence runbook.

Once you’ve delegated something a few times, the next move is to automate it. The remaining three tasks are the kind Neo doesn’t need to be asked for. Drift, deps, compliance: they’re the operations you put on a schedule via Neo Automations.

8. Schedule daily configuration drift detection across your cloud infrastructure

Schedule a daily drift check across your cloud. Wake up to PRs that fix what changed overnight.

Configuration drift is an ongoing challenge. The security team rotated an IAM role at 04:47 UTC. Someone changed a security group in the AWS console three weeks ago. Left alone, drift turns into security gaps, into compliance issues, and into the kind of “wait, who changed that?” confusion nobody wants to chase down.

Pulumi Cloud is already good at configuration drift detection. Neo takes it a step further.

Ask Neo:

Every morning at 6 AM, check all production infrastructure for drift and create PRs to fix any issues you find.

From then on, the task runs on its own, and you wake up to a PR per drifted resource. The description spells out what happened (iam_role.audit-reader had inline policy AllowReadAuditLogs added at 04:47 UTC) and cites the section of infra/runbooks/drift.md Neo followed.

Some drift gets encoded into the Pulumi program, like the IAM rotation above. Some gets reverted, like the security group rule added from the console. Some gets ignored entirely, like autoscaler-managed Lambda concurrency reservations the runbook tells Neo to skip. You write the runbook once; Neo follows it every morning to decide what to do.

Neo's morning drift PR. The body names the resource, the change, when it happened, and the section of the runbook Neo followed to decide what to do.

Start a Neo task Schedule a daily drift check

9. Schedule weekly upgrades for outdated Lambda runtimes and providers

Lambda runtimes and container base images age out. Schedule the upgrade pass; review the PRs Neo opens.

AWS Lambda end-of-life notices come out months ahead. Node 20 stopped receiving updates as an AWS Lambda runtime at the end of April. Python 3.9 reached end-of-support last December. After the deadline, AWS blocks new deploys and eventually stops invoking the function. Each one needs to move to a supported runtime before the cutoff.²

Schedule it:

Every Sunday night at 10 PM, check our Lambda functions for runtimes nearing end-of-support and open PRs to upgrade them.

Neo reads the AWS Lambda runtime deprecation page, matches the end-of-support runtimes against every Lambda function in your stacks, and opens one PR per stack.

If Python 3.9 is reaching end-of-support, the upgrade is to Python 3.12, and datetime.utcnow() calls need to move to datetime.now(datetime.UTC). Neo can make all of those replacements in the same PR.

The same task can catch container base images with critical CVEs and bump them too.

Setting up a weekly task in the Scheduled Tasks UI. Once saved, Neo runs the prompt every Sunday night and opens PRs you review on Monday.

Start a Neo task Schedule a weekly runtime upgrade check

10. Fix AWS CIS Benchmark failures with daily PRs

Run the AWS CIS Benchmark on a schedule. Wake up to PRs that fix every failure.

The CIS AWS Foundations Benchmark, available through AWS Security Hub, is something every team should be keeping an eye on. The benchmark finds issues like S3 buckets that allow public read access (S3.1), root user access keys that shouldn’t exist (IAM.4), or CloudTrail not being enabled (CloudTrail.1). Scanning for these issues is a solved problem, but closing and addressing them is not. They pile up between audits because each one is a code change in a different stack, and nobody owns the cross-stack cleanup.³

Schedule the cleanup:

Every morning, read CIS Benchmark failures from Security Hub. For every failure on an IaC-managed resource, open a PR with the fix.

Neo opens one PR per failure. A bucket failing S3.1 arrives as a Pulumi diff that adds blockPublicAccess to the bucket in your prod-checkout stack. The PR body lists the CIS rule number, the resource ID, the diff, and a clean pulumi preview against the live infrastructure.

The runbook is where your security team writes down what each control means for your stacks. Block public S3 buckets, except the ones tagged public-content=true for CloudFront origins. Don’t auto-touch the break-glass IAM roles; page a human instead. Multi-region CloudTrail stays on, no exceptions. Neo reads that file, checks each Security Hub finding against it, and only opens a PR for the ones you’ve said are safe to fix. The rest get routed or ignored, the way your team already handles them.

A PR raised by Neo to fix a CIS Benchmark failure, with the failing rule, the resource, and the runbook decision laid out in the body.

Start a Neo task Schedule daily AWS CIS Benchmark scans

Neo: your newest platform engineer

Over the past year, many product teams have stopped treating AI as a request-by-request assistant and started delegating to it outright.⁴ Agents open pull requests, investigate issues, and iterate on review feedback.

But platform engineers have held back because a bad infrastructure change doesn’t just fail, it can take production down. Coding agents benefit from fast, forgiving feedback loops, but infrastructure recovery is rarely as simple as reverting a commit.

What was missing wasn’t the appetite. It was an agent with enough organizational context and grounding to plan reliably, enough guardrails to feel safe and contain mistakes, and enough discipline to keep working without being asked.

The theme across these tasks is clear. A thing platform engineers used to keep in their heads becomes a task you delegate, then becomes work that runs without you. Neo isn’t generating infrastructure from a template. It’s a teammate who knows your code, your providers, your conventions, your production metrics, and can raise PRs for you to review.

Neo now lives in your terminal, in your pull requests, in your Slack workspace, and in Pulumi Cloud. Pick one of these workflows and give it a try.

The observant reader will notice Terraform-to-Pulumi was covered in the original post. ↩︎
Also covered in the original post. Last year you could ask Neo to do it once. This year you can put it on a schedule. ↩︎
Also covered in the original post. Last year Neo could remediate violations on demand. This year Security Hub feeds findings to a scheduled task that knows your runbook’s interpretation of each control. ↩︎
For a concrete example, see Seven Rules for Building an AI-Native Software Factory: Ewan Dawson, CTO of Compostable AI, runs nineteen client deployments with five engineers, using Pulumi Neo to handle most of the infrastructure work. ↩︎

The Dark Factory Pattern for Infrastructure: Running Pulumi Lights-Out

Engin Diri — Tue, 05 May 2026 00:00:00 +0000

The original dark factory was Fanuc’s robotics plant in Oshino, Japan, where the lights are off because nobody is on the floor. Robots build robots. Parts move through the line for weeks at a time without a person walking past them.

The same pattern is now showing up in software. Three engineers at StrongDM shipped roughly 32,000 lines of production code without writing or reviewing any of it. Stripe’s “Minions” agent system merges over a thousand pull requests every week. In January, Dan Shapiro of Glowforge published a five-level autonomy ladder that landed cleanly enough to become the shorthand most people now use, and BCG put out a piece calling it the dark software factory.

Almost every public writeup so far is about application code. The harder question is what this looks like for infrastructure.

What a dark factory actually is

Shapiro’s ladder is the cleanest framing I’ve seen. He borrows it from the SAE’s self-driving levels, and it fits surprisingly well:

Level	What it is	Driving analogy
0	Spicy autocomplete	Stick shift; you do everything.
1	Coding intern (boilerplate)	Cruise control.
2	Junior developer (interactive pair)	One hand on the wheel.
3	AI writes the majority; you review every PR	Eyes still on the road.
4	Spec-driven; agent runs unattended for hours; you review later	Sleeping at the wheel, you can still wake up.
5	Dark factory; no human review of code before production	No steering wheel at all.

Most teams are at level 2 or 3. A few of the more aggressive ones are at 4. Level 5 is the experiment. Most teams won’t get there safely, and probably shouldn’t try to. The interesting design question is what has to be true for level 5 to be safe at all, and that question gets sharper when the thing being shipped is infrastructure.

A dark factory is not a coding harness. A harness is the framework an agent runs inside; the dark factory is the surrounding system that makes a harness’s output mergeable without a human reading the diff. Copilot and Cursor sit at the other end: interactive, the human stays in the loop on every keystroke. The dark factory takes the human out of the per-change loop entirely and puts them at the top, writing the spec and the acceptance criteria.

The wall between generator and validator

Strip the dark factory down to its layers and there are four of them.

flowchart LR
A[Inputs<br/>Humans] --> B[Code Generation<br/>Autonomous]
B --> C[Validation<br/>Autonomous, isolated]
C -->|pass| D[Merge & Deploy<br/>Autonomous + existing CI/CD]
C -->|fail| B
A -.->|holdout scenarios<br/>generator never sees these| C

The single most important rule is that Code Generation and Validation must be completely isolated. The generator never sees the acceptance scenarios. A separate evaluator does, and it judges the generator’s output against scenarios the generator could not have memorized.

The reason is sycophancy. LLMs are too eager to agree with their own prior turns and too willing to declare victory on something they just produced. Without isolation, the same model that wrote the change is the one telling you it’s fine. The practical concern is direct: a test stored in the same codebase as the implementation will get lazily rewritten to match the code, not the other way around. It isn’t malice; it’s the agent doing exactly what it was asked, badly. The wall is what stops that.

StrongDM’s pattern for this is holdout scenarios: plain-English BDD acceptance tests stored where the generator cannot reach them. Each scenario runs three times against an ephemeral deployment, two of three must pass, and the overall pass rate has to clear 90% before the change moves forward. If the generator fails, it gets a one-line failure message (“SQL Injection Detection failed: endpoint returned 500”), not the scenario text. It cannot game the test.

Without that wall, you don’t have a quality gate. You have theater.

Why infrastructure is the harder version

Application code factories can lean on tests, linters, and type checkers. Infrastructure adds blast radius, drift, secrets, irreversible actions, and multi-region state. A code dark factory shipping a broken UI causes a bad user experience. An infrastructure dark factory shipping a broken IAM policy ends in a postmortem.

A few things make this manageable on Pulumi specifically.

The orchestrator does not need to be invented. The Pulumi Automation API is the engine as an SDK in Python, TypeScript, Go, .NET, Java, or YAML, which is the same surface a dark factory orchestrator runs on. Credentials don’t have to be long-lived: ESC and OIDC issue short-lived ones per run, so the agent never sees a static secret.

Policy doesn’t have to be probabilistic: CrossGuard enforces deterministic rules at preview time. Execution doesn’t have to happen on a laptop: Pulumi Cloud Deployments runs pulumi up inside a governed runner with audit logs and approval rules already wired. And the reasoning layer doesn’t have to start from scratch: Pulumi Neo is grounded in your state graph and ships with three modes (Auto, Balanced, Review) that line up cleanly with Shapiro’s levels 5, 4, and 3.

That doesn’t make Pulumi a dark factory by itself. It means the parts that an application-code factory has to build from scratch are pieces a Pulumi shop already has: a credential broker, a policy engine, a governed runner, a state-aware reasoning layer, an audit trail.

And one more piece nobody talks about: pulumi preview produces a clean, deterministic validation artifact, and CrossGuard evaluates that artifact without ever seeing the conversation that produced the program. That’s the same context-free judgment the holdout pattern depends on, applied at the policy layer instead of the acceptance-test layer. For infrastructure, half the wall is already built.

The interesting work is the part that nobody ships in a box.

The interesting work

What no platform ships for you is the wall: the holdout scenarios for infrastructure, the isolated evaluator that runs them, and the agreement on which stacks are even allowed to run lights-out.

The happy-path orchestrator is small. It pulls a spec, runs preview, hands the preview to an isolated evaluator (with its own credentials and its own access to the cloud, no access to the generator’s prompt or output), and branches on the verdict. Auto mode runs up immediately. Balanced mode submits a deployment that requires approval. Review mode opens a PR for a human. Every branch records a stack version traceable in the audit log. Retries, observability, secret rotation, and the rest of the production-grade plumbing add up to real code, but the shape is small.

The wall is the part that takes a week to get right. You write five plain-English scenarios for one stack (“after pulumi up, the bucket is private, has SSE-KMS, lives in eu-west-1, and is tagged owner=team-x”) and a janky evaluator that runs preview and up against an ephemeral copy, queries the cloud, and asks a separate model whether the resulting state satisfies the scenario. Triple-run, 90% pass gate. Then you watch it for a few weeks before you let anything auto-apply.

Ground your agent in real state

Pulumi Neo reasons over your actual state graph and runs in Review, Balanced, or Auto mode, so you can grant it more autonomy as your confidence grows.

Get started

A four-phase rollout

This is the same path the application-code factories walked, with the gates tightened.

Phase 1: better context, this afternoon

Write an AGENTS.md for your most active stack repo. Pulumi Neo reads it natively, as do most coding agents. While you’re there, look at your CrossGuard rules and rewrite the error messages as instructions. Not “S3 bucket has no encryption” but “S3 bucket has no encryption. Set serverSideEncryptionConfiguration with SSE-KMS to fix.” That single change is the difference between an agent flailing and an agent fixing the policy violation on the first try. Wire pulumi preview as a build-before-push gate so PRs don’t show up just to fail CI.

Phase 2: spec-driven with holdouts, this week

Pick one stack with a small blast radius. A review-stack lifecycle is ideal. Write five plain-English holdout scenarios for it and the janky evaluator above. Humans still approve every PR. Don’t auto-merge yet. You’re earning the data, not declaring trust.

Phase 3: take the human out of the merge

Only after the three measurable gates hold over twenty PRs (scenario pass rate above 90%, false positive rate below 5%, human override rate below 10%) flip auto-apply on for that one stack. Add a weekly drift sweep that goes through the same scenario gate as everything else.

Phase 4: lights out

Expand the auto-apply flag to every stack with strong scenario numbers. Wire your issue tracker so tickets tagged infra:fix flow through the pipeline. Mock the cloud APIs that are slow or flaky enough to make scenario evaluation expensive. At this point the orchestrator is configuration, not architecture.

What could go wrong

None of these have clean fixes. The mitigations below reduce risk; they don’t eliminate it. Any team running level 5 should expect to eat one or two of these in the first year.

The validator approves a bad change. This is the obvious one. The standard mitigation is layered: triple-run each scenario with a 2-of-3 threshold, a 90% gate over the run set, a human audit of the first fifty auto-applied changes, and your existing policies still run after the validator says yes.

The agent gets a destroy permission it shouldn’t have. There’s a class of operations that should not sit in the autonomous loop yet: dropping a database, deleting a hosted zone, rotating a root key, anything that crosses a regulated data boundary. Scope what each agent identity can do at the credential layer, require human approval for anything destructive, and start every stack at Review mode. Tag changes, security-group adjustments, and instance resizes can run autonomously today. Release-branch cuts and config promotions can probably run by next quarter. The destructive class earns its way in over months.

You need all three of those layers. Approvals without policy means anything a human approves in a hurry ships. Policy without approvals means a sufficiently clever spec eventually finds the gap. Both without a human kill switch means an incident at 3 a.m. has nobody to escalate to.

Costs blow up. Cap retries at three per spec, alert on token spend per run, and remember that StrongDM reported roughly $1,000 per day per engineer-equivalent. That’s still cheaper than a salary, but only if you put the cap in place before you find out.

Where to start

Most of what a dark factory needs already exists in any reasonably mature platform. Whatever you have for state, policy, credentials, audit, and a deployment runner is the substrate. The interesting work is not building the factory. It’s the wall: the holdout scenarios that make the gap between “the model says it’s fine” and “the system is actually fine” mean something.

For most teams, Phase 1 alone is the win. Full Level 5 may stay out of reach indefinitely, and that’s fine. The path itself forces useful work: clearer specs, named bottlenecks, the deterministic gates humans had been running in their heads.

Write an AGENTS.md and five holdout scenarios for one stack this week. That’s enough to get a real signal on whether the pattern fits your team. The rest of the path is the same problem the application-code factories have already worked through, with the gates set tighter.

Agent Sprawl Is Here. Your IaC Platform Is the Answer.

Engin Diri — Wed, 22 Apr 2026 00:00:00 +0000

Somewhere in your company right now, a developer is building an AI agent. Maybe it’s a release agent that cuts tags when tests pass. Maybe it’s a cost agent that shuts down idle EC2 overnight. It’s running, it’s in production, and there’s a decent chance the platform team doesn’t know it exists.

This isn’t a thought experiment. OutSystems just surveyed 1,900 IT leaders and the numbers are rough: 96% of enterprises run AI agents in production today, 94% say the sprawl is becoming a real security problem, and only 12% have any central way to manage it. Twelve percent. You can read the full report here.

The real question is where those agents run. Inside the platform you’ve already built, or somewhere off to the side where nobody on the platform team can see them.

The new platform tension

Platform teams have always had two jobs that pull in opposite directions. Let developers ship without waiting on a ticket. Keep the infrastructure coherent while they do. Golden paths, review stacks, a catalog of components that don’t fight each other.

Agents break the second half of that deal.

A developer with a sharp prompt can spin up an SRE agent that watches a queue, a release agent that cuts tags when the test suite goes green, or a cost agent that kills idle infra at 2 a.m. That’s useful. It’s also running on your production cloud account, using credentials you never provisioned, writing to systems you never approved, and the only audit trail is whatever the developer remembered to log. The Salesforce 2026 Connectivity Benchmark pegs the average enterprise at twelve agents today, projected to grow 67% over the next two years. Most teams aren’t ready for one, let alone twenty.

This is the same shape as every sprawl problem before it. I wrote about the last one in How Secrets Sprawl Is Slowing You Down, and the pattern keeps repeating. When something useful gets cheap, it proliferates. When it proliferates without structure, it becomes a liability.

The clock is also ticking on the compliance side. The EU AI Act’s high-risk obligations kick in on 2 August 2026. Colorado’s AI Act goes live on 30 June 2026 after last year’s delay. A folder of unreviewed agent scripts isn’t going to hold up against either of those.

Three ways to respond (only one of them works)

There are roughly three paths from here.

Do nothing. Accept the sprawl and hope nothing catches fire. This is the default, and it’s also how you end up explaining to an auditor why some finance agent moved data between three systems last Thursday and nobody remembers which prompt triggered it.

Mandate centralization. Tell developers every agent has to be registered and approved before it runs. This sounds responsible on a slide, and it falls apart inside a sprint. Developers route around friction. If the official path takes a week and the unofficial path takes an afternoon, the unofficial path wins, and you’ve just pushed the sprawl underground where you can’t see it anymore.

Make the platform the obvious path. Build the thing developers actually want to use. A place where an agent inherits the guardrails, credentials, policies, and audit trail by default, because that’s what’s on offer. Adoption becomes a side effect of shipping something good.

Option three is the only one that scales. It’s also the one where most platform teams look at their existing stack and assume they need to build a pile of new scaffolding. I don’t think they do, and the rest of this post is why.

The seven things an AI agent needs from your platform

An agent needs seven concrete things from the platform it runs on. Each one maps to a Pulumi primitive you already own.

1. A trustworthy context lake

Agents are only as good as the context they can reason over. Drop a generic LLM into your cloud account and you’ll get plausible-sounding nonsense, because the model has never seen your environment. What you actually need is a grounded source of truth: what resources exist, how they relate, which stack owns what, which version is running where.

Pulumi state is already that. Your program graph, your stack outputs, your resource metadata, all of it adds up to a structured record of what you’ve actually deployed. Pulumi Neo reasons directly over that graph, which is why it can tell you why a deployment drifted instead of guessing. I wrote the long version of that argument there. Short version: you already have the context lake. Point agents at it.

2. Pre-cleared integrations

An agent that needs to touch five systems shouldn’t need five separate credential dances. That’s where credential sprawl starts. Every agent gets a long-lived key, every key ends up in somebody’s .env, and every rotation turns into an incident.

The Pulumi surface here is the 200+ providers plus Pulumi ESC handling dynamic credentials through OIDC. An agent doesn’t ask for an AWS access key. It asks ESC for a short-lived, scoped token bound to the environment it’s allowed to operate in, and the token expires when the task ends. No static keys, no rotation pain, no awkward postmortem about how something got committed to GitHub. The ESC patterns I walked through in the Claude skills post work just as well for an autonomous agent as they do for a human developer, which is really the whole point.

3. Governed actions

There’s a real difference between “an agent can see your infrastructure” and “an agent can change your infrastructure.” The second one is where you actually need structure. Pulumi Deployments gives you that structure: defined workflows, controlled triggers, running inside your Pulumi Cloud boundary instead of whatever environment the developer happened to spin up. The Automation API lets you build higher-order orchestration on the same primitives your developers already use.

The framing I keep coming back to goes like this. An agent shouldn’t call pulumi up directly. It should submit an action to a governed pipeline that runs pulumi up on its behalf, inside an environment you control, with a log trail and the guardrails already in place. Same effect, very different threat model.

4. Deterministic policy

Real governance lives outside the prompt. “Please don’t delete production” is a wish written into a system prompt, not an enforced control. And when an agent overrides your intent to do what it thought you meant, it’s behaving exactly the way the technology was designed to behave.

Pulumi Policies is the answer the IaC community landed on years ago: policy as code, written in a real programming language, evaluated deterministically at preview and update time. Disallow production RDS deletions. Require encryption at rest. Block S3 buckets with public ACLs. An agent running through Pulumi hits those gates whether it “wants” to or not, because the gates live in the pipeline and not in the prompt. This is the pillar most teams underweight, and it’s the first one most auditors ask about.

5. An audit trail

When something goes wrong at 3 a.m. (and with enough agents running, something will), you need answers fast. What changed, who changed it, and why. Not just “which agent,” but which version of which agent, triggered by what event, authorized by which policy, touching which resources.

Pulumi Cloud’s activity log, the stack update history, and ESC audit logs already capture all of that. Every update is versioned. Every secret access is logged. Every policy evaluation is recorded. When an agent submits a change through your Pulumi pipeline, it inherits that audit surface for free. The alternative is reconstructing an incident from a mix of Slack messages, container logs, and developer memory, which is roughly the state most teams without a platform are in today.

6. A review process

Not every agent action should wait for a human. But agents do need a promotion path, the same way new platform components do. Experimental, then reviewed, then trusted, then autonomous. That’s exactly what pulumi preview, review stacks, and Deployments PR workflows already model for human contributors. An agent that wants to make a change should have to submit it the same way a junior engineer would. As a diff, with a plan, against a preview environment, until it earns the trust to skip steps.

This connects back to the pattern I laid out in Golden Paths: Infrastructure Components and Templates. Golden paths were never only for humans. They’re just paths, and agents can walk them too.

7. Human-in-the-loop approval

The last pillar is the one that keeps the other six honest. Some decisions shouldn’t be automated, full stop. Production rollbacks outside business hours. Destructive changes above a certain blast-radius threshold. Anything that touches a regulated data boundary. For those cases, you want a forced human checkpoint that the agent can’t route around.

Pulumi Deployments approvals already play that role for human changes. Pulumi Neo’s review steps add the AI-aware version: a structured plan, a diff, a named approver, and a record of what they decided and why. I walked through what this looks like in practice in Self-Verifying AI Agents. Short version: an agent that proposes is much safer than an agent that commits.

Govern agent changes through your platform

Route changes from any coding agent, including Claude Code, Cursor, and Pulumi Neo, through the same infrastructure as code controls, policies, and audit trail your team already runs.

Get started

Why IaC is the natural substrate for this

Step back from the seven pillars and look at what they have in common. Context, integrations, governed actions, deterministic policy, audit, review, approval. None of those are new problems that AI agents invented. They’re the problems infrastructure-as-code has been quietly solving for a decade, for human developers.

Every meaningful agent action ends up being a change, whether that’s to infrastructure, configuration, secrets, or state. IaC is the one layer in your stack that already treats change as the unit of work. Plan, preview, apply, record. If you want governance for agents and you don’t want to build it twice, the most efficient move is to route agent changes through the same substrate your humans already use.

I made the same point from a different angle in Token Efficiency vs Cognitive Efficiency: Choosing IaC for AI Agents. An IaC platform that models your world as a graph of typed resources is a much better reasoning surface for an agent than a stack of YAML or a bash script somebody wrote on a Friday. The structure is what makes it work.

What this means for the platform engineer

There’s a narrative floating around that AI is going to make platform engineers less relevant. I haven’t seen it hold up against an actual production environment. Every stat I’ve looked at points the other way. Gartner expects 70% of enterprises to deploy agentic AI as part of IT infrastructure and operations by 2029, up from less than 5% in 2025. LangChain’s State of Agent Engineering report already has 57% of teams running agents in production today. And Gartner projects that 80% of large software engineering orgs will have a platform team by end of 2026, up from 45% in 2022. More agents means more changes, more changes means more blast radius, and more blast radius means more need for the thing platform teams are uniquely equipped to provide.

Your classic responsibilities haven’t gone anywhere either. Golden paths, service catalogs, CI/CD, on-call rotations, all of that is still yours. Agents are an additional layer that needs the same discipline. The upside is that if your platform already runs on a mature IaC surface, you’re extending a muscle you’ve been building for years instead of growing a new one.

The developer-facing side matters too. A developer building an agent needs to know what’s available to them, needs templates that work on the first try, and needs to see what teammates have already built so they don’t start from a blank page. That’s the territory the Claude skills post and IDP Strategy: Self-Service Infrastructure That Balances Autonomy With Control cover. That’s the experience layer that makes developers actually choose your platform instead of routing around it. You need both sides working at once. The governance your security team cares about, and the experience your developers will actually reach for.

Close the window

The agents your developers are shipping this week are going to outlive the experiment that started them. Some of them will become critical. At least one will cause an incident. At least one will eventually show up in an audit. All of them are going to be easier to govern if they were built on your platform from day one than if you try to wrap policy around them later.

If you want the longer view on where this is going, AI Predictions for 2026: A DevOps Engineer’s Guide is the companion piece. If you want the developer-facing version of the grounding argument, Grounded AI is what to read next.

Either way, here’s where I land. The substrate for agent governance is already running in your stack. You’ve been pointing it at human changes for years. Now point it at the agents too.

See how Pulumi Neo governs agent actions

KubeCon EU 2026 Recap: The Year AI Moved Into Production on Kubernetes

Engin Diri — Wed, 01 Apr 2026 00:00:00 -0700

Amsterdam in late March still has that sharp North Sea wind, but inside the RAI Convention Centre, 13,350 people generated enough energy to heat the building twice over. KubeCon + CloudNativeCon EU 2026 was the biggest European edition yet, and the shift from previous years was impossible to miss. AI dominated the conference.

I spent most of the conference at the Pulumi booth, and that turned out to be the best vantage point. Hundreds of visitors stopped by over four days, and I kept asking the same question: what are you actually running in production with AI on Kubernetes? The answers shaped this post more than any keynote did. Almost everyone had a proof of concept. Almost nobody had a production story they were happy with.

Here is the stat that framed the entire conference for me: 66% of organizations use Kubernetes to host generative AI workloads, but only 7% deploy to production daily. That gap between experimentation and actual production use matched what I was hearing at the booth. The CNCF’s own survey now counts 19.9 million cloud native developers worldwide, 7.3 million of them building AI workloads. The tooling and the infrastructure need to catch up.

My takeaway after four days on the ground: lots of working demos, very few production setups people trust. Teams are trying to scale inference, put guardrails around agents, and make GPU infrastructure behave like anything else they run.

Here is what I saw.

From training to inference: the big pivot

About 67% of AI compute now goes to inference, not training. The inference market is projected to hit $255 billion by 2030. It’s also where most of the operational complexity lives.

NVIDIA leaned into this hard. Their open-source stack around NeMo and Dynamo got significant stage time, but the bigger move was donating three projects to the CNCF: the DRA driver for fractional GPU allocation, the KAI Scheduler for GPU-aware scheduling, and Grove. Moving these to community governance signals that GPU infra is becoming part of the standard Kubernetes toolkit.

The CNCF donations that will reshape AI on Kubernetes

Every KubeCon has its crop of new CNCF projects, but this year’s batch felt different. We are starting to see the building blocks of an AI runtime for Kubernetes.

llm-d was the headline donation. Created by IBM Research, Red Hat, and Google Cloud, it splits inference workloads by separating prefill and decode phases across different pods. The collaborator list reads like an industry consortium: NVIDIA, CoreWeave, AMD, Cisco, Hugging Face, Intel, Lambda, Mistral AI, UC Berkeley, and UChicago. When that many organizations agree on a single approach to distributed inference, pay attention.

NVIDIA’s DRA driver enables fractional GPU allocation and multi-node NVLink support. GPU multi-tenancy is one of the hardest unsolved problems in Kubernetes right now. Scheduling, isolation, cost attribution — all of it breaks down when multiple workloads share a GPU. The DRA driver does not solve everything, but it gives the community a real starting point.

KAI Scheduler entered the CNCF Sandbox for GPU-aware scheduling. If llm-d handles the inference runtime and the DRA driver handles allocation, KAI Scheduler handles placement. Together, these three projects form the skeleton of a GPU-native Kubernetes stack.

Velero, donated by Broadcom, moved into CNCF Sandbox for backup and restore. AI workloads are stateful now (model weights, checkpoints, fine-tuning data), and backup is no longer optional. Good timing.

Microsoft AI Runway is an open-source Kubernetes API for inference that plugs in Hugging Face model discovery, GPU memory fit calculations, and cost estimates. Think of it as a model-aware control plane. HolmesGPT and Dalec, also from Microsoft, entered CNCF Sandbox for AI-powered troubleshooting and dependency analysis.

The Kubernetes AI Conformance Program is growing fast, with certifications nearly doubled and three new requirements proposed for Kubernetes 1.36. Conformance programs are boring until they are not. This one will determine which distributions can credibly claim AI readiness.

Agentic AI gets an identity layer

If inference was this year’s production story, agentic AI was the architecture story. Agents are proliferating, and nobody has quite figured out how to manage and secure them inside Kubernetes yet.

kagent, donated to CNCF Sandbox by Solo.io, defines agents as Kubernetes CRDs. It ships with pre-built MCP (Model Context Protocol) servers for Kubernetes, Istio, Helm, Argo, Prometheus, Grafana, and Cilium. An agent becomes a first-class Kubernetes resource, schedulable and observable and subject to RBAC, instead of a rogue process running in someone’s notebook.

kagenti from IBM goes after the identity problem directly. Using SPIFFE/SPIRE, it gives agents cryptographic identities. When an agent calls an API, you can verify exactly which agent made the call, what trust domain it belongs to, and whether it is authorized. This kind of security work needs to happen before agents proliferate across production clusters. Retrofitting identity later is ugly.

Dapr Agents took a different angle with the actor model and durable execution. Each agent gets reliable state management and exactly-once messaging semantics. If your workflows cannot tolerate lost messages or duplicate actions, this matters.

agentregistry showed up as a centralized discovery service for MCP servers and agents. As agents and tool servers multiply, you need a registry to find and manage them, the same way container registries became necessary for images.

David Soria Parra from Anthropic gave a talk on MCP evolving beyond simple tool-calling into richer interaction patterns (sched). Google announced the Kubernetes Agent Sandbox for running agentic AI workloads in secure, isolated environments — we’ve since published a full walkthrough of what it is and how to deploy it.

AI gateways and inference routing

Gateway infrastructure had its own mini-conference within KubeCon. The Gateway API Inference Extension from the Kubernetes SIG introduces model-aware routing and load balancing at the gateway level. Instead of routing by URL path, your gateway routes by model name, version, and capacity. That changes how inference traffic flows through a cluster in a fundamental way.

Envoy AI Gateway builds on Envoy’s existing proxy capabilities with token-aware rate limiting and provider failover. If your primary inference provider is saturated, traffic shifts to a secondary automatically. Rate limiting by token count rather than request count makes much more sense for LLM workloads, where a single request can consume vastly different amounts of compute.

I want to call out Agentgateway specifically. Written in Rust, it proxies LLM traffic, MCP connections, and agent-to-agent communication, with Cedar and CEL policy engines for fine-grained access control. Rust’s performance characteristics matter here because inference gateway latency adds directly to user-perceived response time.

Kuadrant, now in CNCF Sandbox, layers policy on top of gateway infrastructure and includes MCP server aggregation. Gateways are evolving from dumb traffic proxies into intelligent control planes for AI workloads, and these four projects are driving that shift.

Platform engineering absorbs LLMOps

The observability and platform engineering vendors showed up in force. The message was consistent: LLMOps is just platform engineering with new requirements.

Chronosphere demonstrated parallel AI investigation, with multiple agents analyzing different aspects of an incident simultaneously and combining their findings. SUSE Liz takes a domain-specialized approach, deploying different AI agents for different operational domains rather than one general-purpose assistant. groundcover combines eBPF with OpenTelemetry to give coding agents rich runtime context about the systems they are modifying. That last one is subtle but important: if an AI agent is writing code that touches a service, it should understand that service’s actual runtime behavior, not just its source code.

Dynatrace and DevCycle partnered to make feature flags observable primitives via OpenFeature. Rolling out AI features behind feature flags is table stakes, but having those flags show up in your observability pipeline as first-class signals closes a real gap.

Shadow AI governance emerged as its own theme. CAST AI’s Kimchi can route requests across 50+ models while providing centralized visibility into what models are being used, by whom, and at what cost. Every large organization I talked to had some version of the same problem: teams spinning up model endpoints without central oversight, burning through GPU budgets, creating compliance blind spots they did not even know about.

GPU multi-tenancy remains genuinely unsolved. Scheduling, workload isolation, cost attribution across shared GPUs — all of it breaks down at scale. Multiple talks addressed pieces of this, but nobody had a complete answer.

Sovereignty shapes infrastructure architecture

Regulation came up in almost every conversation. The EU Cyber Resilience Act is driving compliance requirements deep into software supply chains, and every European organization I spoke with is feeling the pressure. Teams are already changing how they build and deploy software.

Sovereign Kubernetes is a platform architecture requirement now, not something you can defer to next quarter. Organizations need Kubernetes distributions and cloud regions that guarantee data residency, and they need the tooling to enforce those guarantees programmatically. Self-hosted models are proliferating partly because of capability and cost, but data sovereignty is the accelerant. If your data cannot leave a jurisdiction, neither can your model.

Runtime isolation is expanding beyond containers. Several talks covered KVM-based isolation for AI workloads, which is heavier than containers but necessary when the threat model includes side-channel attacks on shared GPU memory. The sandboxing conversation has gotten more sophisticated since last year.

These constraints are not uniquely European. Any organization operating across jurisdictions faces similar pressures, and the regulatory direction globally is toward more data sovereignty requirements, not fewer.

What this means for your team

Four days in Amsterdam distilled into five things I would act on now:

Treat inference workloads like production services. If you are still deploying models with scripts and hope, stop. Inference infrastructure needs the same IaC discipline as any other production system: version-controlled, tested, policy-enforced.
Evaluate the Gateway API Inference Extension and llm-d. These are not speculative projects. They have broad industry backing and solve real problems around inference routing and distributed serving. Get them into your test environments.
Plan agent identity before agents proliferate. SPIFFE/SPIRE for agent identity is not optional if you are running agents in production. Retrofitting identity onto an existing agent fleet is painful. Start with kagenti now.
Platform teams should own AI infrastructure. Shadow AI is already happening in your organization. The platform engineering team needs to provide self-service AI infrastructure with guardrails before ungoverned model endpoints become a security and cost problem.
Sovereignty and GPU multi-tenancy are universal. Even if you are not subject to the EU Cyber Resilience Act today, data residency requirements are spreading globally. GPU multi-tenancy will affect every organization running inference at scale.

Kubernetes spent the past decade proving it could orchestrate containers. The next decade will test whether it can orchestrate intelligence. Based on what I saw in Amsterdam, the community is building the right pieces, but the gap between what exists and what production demands is still wide. That gap is where the interesting work happens.

Registry usage insights: know which stacks run which versions

Pulumi IDP Team — Thu, 12 Feb 2026 00:00:00 +0000

Platform teams need visibility into package adoption at scale. Responding to security advisories, planning deprecations, and tracking version sprawl all require knowing which stacks run which package versions across your organization.

From Individual to Organizational Visibility

Previously, we introduced the “Used by” tab on individual package pages, giving you visibility into which stacks use a specific package. However, navigating package by package doesn’t scale when you’re managing dozens of packages across hundreds of stacks.

Today, we’re extending that visibility to the organization level. You can now see adoption data for all packages at a glance, filter by usage status, and share specific views with your team.

What You Can See

The package list now displays three usage columns for each package:

Stacks on latest: the number of stacks running the latest version
Not on latest: the number of stacks running older versions
Total: all stacks using any version of the package

These numbers update as stacks are deployed, giving you a real-time view of adoption across your organization.

Find What Matters with Filters

Three filters help you find packages that need attention:

Used: packages with at least one stack
Unused: packages with zero usage
Not on latest: packages where stacks are running older versions

Combine filters with search to find specific packages.

Browse All Packages in One Place

The new Registry tab under Platform shows all packages available to your organization, including public providers and components from pulumi.com/registry alongside your organization’s private packages. The Private Components tab (previously called Components) now includes the same usage columns and filters.

Search queries, filters, and pagination sync to the URL. Copy the URL to share a specific view with your team, or bookmark it for quick access to your regular monitoring workflow.

Why This Matters

These features are designed for the scenarios platform teams face regularly:

Security response: filter to “Not on latest” to identify stacks running vulnerable versions
Deprecation planning: before retiring a package, check its usage to understand the migration scope
Version sprawl: identify packages where teams are running many different versions and prioritize standardization efforts
Adoption tracking: see which packages are gaining traction and which aren’t being adopted

Get Started

Navigate to Platform > Registry in Pulumi Cloud to explore your organization’s packages with the new usage columns and filters. For more details on the private registry features, see the Private Registry documentation.

The Claude Skills I Actually Use for DevOps

Engin Diri — Mon, 09 Feb 2026 00:00:00 +0000

When Claude Code first released skills, I ignored them. They looked like fancy prompts, another feature to add to the pile of things I would get around to learning eventually. Then I watched a few engineers demonstrate what skills actually do, and something clicked. By default, language models do not write good code. They write plausible code based on what they have read. Plausible code turns into bugs, horrible UX, and infrastructure that breaks at 3am.

Skills fill that gap. They package engineering expertise into something Claude can use. The workflows and judgment matter more than the raw information. Without skills, every conversation starts from zero. You explain the same conventions and correct the same mistakes. Every morning, back to zero.

Think about what separates a junior engineer from a senior one. Both can write code that compiles. Both can deploy infrastructure that runs. The difference is that the senior engineer knows the patterns that prevent problems before they happen. They know when to use component resources instead of plain resources. They know that creating infrastructure inside an apply() callback (Pulumi’s way of transforming outputs that are not known until deployment) breaks preview. They know that hardcoded credentials will eventually end up in a git log somewhere embarrassing.

This knowledge takes years to accumulate through painful experience. Skills let you transfer that knowledge to Claude in minutes. And here is the thing that makes them practical: if you find yourself doing the same type of task with different content each time, that is a skill waiting to be built. You encode the process once, then feed it new inputs forever.

The mechanic, the tools, and the manual

I heard an analogy recently that made skills click for me. Imagine Claude as a mechanic. A capable mechanic who knows engines, can diagnose problems, and fix most cars that come through the shop.

MCP servers are like giving that mechanic a set of tools. Wrenches, diagnostic equipment, lift systems. Without tools, the mechanic cannot do much. With tools, the mechanic can work on whatever comes through the door.

But what happens when someone brings in a Formula 1 race car? Or a 1967 Ford Mustang that has been modified beyond recognition? The mechanic knows engines in general, but these specific vehicles require specific knowledge. The F1 car has procedures that must be followed in exact order. The vintage Mustang has quirks that only someone who has worked on that model would know.

Skills are the user manuals and standard operating procedures for these specific vehicles. They tell the mechanic what needs to happen and when. They encode the expertise of someone who has done this work a thousand times.

Or think about it from a carpenter’s perspective. Skills are the process to make the table: the measurements, the design, the exact steps. MCPs are the tools: the saw, the hammer, the drill. You need both. The process alone is theoretical, and tools without a process just sit in the garage.

For DevOps engineers working with Pulumi, this matters because infrastructure as code has its own quirks and patterns. Generic AI assistance produces code that looks reasonable but breaks conventions the community learned the hard way. Skills teach Claude those conventions.

Why skills instead of MCPs

Before skills clicked for me, I tried solving the expertise problem with MCPs. I kept adding servers until I noticed Claude getting slower and making worse decisions. Turns out the GitHub MCP alone eats 46,000 tokens across 91 tools before you type anything. Cursor eventually capped MCPs at 40 tools because too many options made everything worse.

Slash commands were another option, but you had to remember to invoke them. Anthropic apparently agreed, because in January 2026 they merged slash commands into skills. One unified system instead of two.

Skills avoid this through progressive disclosure. Claude reads just the description at startup, maybe a hundred tokens. The full procedures only load when Claude decides they are relevant. Unlike those massive system prompts that used to eat through your context window, skills stay out of the way until they are needed. For DevOps engineers running long infrastructure sessions with dozens of resources, this matters. You keep your context budget for the actual work instead of burning it on instructions. Skills can also fork context, spinning up isolated subagents that do work without polluting your main conversation. Think of it like handing a colleague a written brief. They go work on it, hand back a summary, and never sit in on your conversation.

I still use MCPs for connecting Claude to external systems. The Pulumi MCP server lets Claude query the registry and validate code. But MCPs give Claude access to things. Skills teach Claude how to think about things. Different jobs. They get more useful when you combine them. One engineer built a financial reporting skill that connects to his Mercury bank account via MCP, pulls every transaction for a given month, classifies the expenses into categories, and generates a styled HTML report with totals and breakdowns. A skill that knows your deployment process connecting to MCPs that talk to your actual infrastructure is the same idea, just pointed at ops instead of accounting.

Skills are portable. They follow an open standard, so a skill you write for Claude Code works in Cursor, GitHub Copilot, or anywhere else that supports agent skills. You can even copy the skill content into ChatGPT as a starting prompt. No vendor lock-in.

Teaching Claude to write Pulumi like an expert

The first time you ask Claude to help with a Pulumi project, the process is painful. You have to explain the patterns you want. You correct mistakes. You explain why creating resources inside apply() breaks things. By the third or fourth project, you start copying your corrections from previous conversations.

I built the dirien/claude-skills pulumi-typescript skill after going through this painful process too many times. It knows the patterns that prevent common mistakes: Pulumi ESC (Environments, Secrets, and Configuration) integration, OIDC (OpenID Connect) instead of hardcoded access keys, ComponentResource abstractions (reusable groups of related resources), and proper output structuring so dependent stacks can consume them cleanly.

Skill	What it teaches Claude
`pulumi-typescript`	Pulumi with TypeScript, ESC secrets management, component patterns, and multi-cloud deployment

npx skills add https://github.com/dirien/claude-skills --skill pulumi-typescript

Skills install as markdown files in your project’s .claude/skills/ directory, so they travel with your repo and are easy to review.

The next time you ask Claude to create infrastructure, it applies these patterns automatically. You do not have to remember to invoke the skill or correct the same mistakes repeatedly.

The official Pulumi skills

Pulumi maintains its own skills repository at pulumi/agent-skills, which they announced recently. The repo includes skills for ComponentResource patterns, Automation API, and migration from Terraform, CDK, CloudFormation, and ARM. The two I use daily are pulumi-esc and pulumi-best-practices.

The pulumi-esc skill teaches Claude how to work with Pulumi ESC (Environments, Secrets, and Configuration). It knows the difference between pulumi env get, pulumi env open, and pulumi env run. It sets up OIDC for dynamic credentials, integrates with external secret stores like AWS Secrets Manager and Vault, and structures layered environment composition so your dev, staging, and production configs inherit from a shared base.

The pulumi-best-practices skill catches the mistakes that burn you in production. It stops Claude from creating resources inside apply() callbacks, enforces proper parent relationships in ComponentResources, encrypts secrets from day one, and makes sure pulumi preview runs before any deployment. These are the patterns that took me years to internalize, and now Claude follows them by default.

Skill	What it teaches Claude
`pulumi-esc`	Environment, secrets, and configuration management with OIDC, dynamic credentials, and secret store integration
`pulumi-best-practices`	Resource dependencies, ComponentResource patterns, secret encryption, and safe refactoring

npx skills add https://github.com/pulumi/agent-skills --skill pulumi-esc
npx skills add https://github.com/pulumi/agent-skills --skill pulumi-best-practices

Making Claude a monitoring expert by default

You deploy something, it works, and six months later something breaks and you realize you never added monitoring. We have all been there. The monitoring skills from the community teach Claude to add observability from the start.

The jeffallan/claude-skills repository contains a monitoring-expert skill that knows Prometheus, Grafana, and DataDog.

Skill	What it teaches Claude
`monitoring-expert`	Structured logging, metrics, distributed tracing, alerting, and performance testing for production systems

npx skills add https://github.com/jeffallan/claude-skills --skill monitoring-expert

In my testing, deploying a static website with these skills installed looks different from vanilla Claude. Instead of just creating the S3 bucket and CloudFront distribution, Claude asked about error rate thresholds before writing any code. It suggested CloudWatch alarms and created an SNS topic for alerts. The results are not always this clean. Sometimes the monitoring suggestions are generic or miss your specific SLO requirements. But the baseline shifted from “no monitoring at all” to “monitoring that needs tuning,” and that is a better starting point.

Kubernetes configuration that actually passes security review

Kubernetes has hundreds of configuration options. Most deployments use a handful of them. The problem is that the important options like security contexts, resource limits, and pod disruption budgets are easy to forget when you are focused on getting something to run.

The jeffallan/claude-skills kubernetes-specialist skill focuses on configurations that production deployments actually need. Without it, ask Claude for a deployment and you get something that runs: the right image, the right ports, maybe a service. With the skill, the same request comes back with runAsNonRoot: true in the security context, resource requests and limits that reflect actual usage patterns, liveness and readiness probes with sensible intervals, and a pod disruption budget. These are the things that make the difference between “it works in staging” and “it survives a node failure in production.” The skill also understands when RollingUpdate makes sense versus Recreate, which is the kind of judgment call that usually requires context a generic model does not have.

The wshobson/agents repository fills in the gaps around Kubernetes with CI/CD, cost management, and deployment workflows:

Skill	What it teaches Claude
`kubernetes-specialist`	Production cluster management, security hardening, and cloud-native architectures
`cost-optimization`	Cloud cost reduction across AWS, Azure, and GCP with right-sizing and reserved instances
`github-actions-templates`	CI/CD workflows, Docker builds, Kubernetes deployments, security scanning, and matrix builds
`gitops-workflow`	ArgoCD and Flux CD for automated Kubernetes deployments

npx skills add https://github.com/jeffallan/claude-skills --skill kubernetes-specialist
npx skills add https://github.com/wshobson/agents --skill gitops-workflow
npx skills add https://github.com/wshobson/agents --skill github-actions-templates
npx skills add https://github.com/wshobson/agents --skill cost-optimization

Debugging like a senior engineer

The obra/superpowers repository contains a skill that changed how I debug with Claude. The systematic-debugging skill implements a four-phase framework: root cause investigation, pattern analysis, hypothesis testing, and implementation.

Without this skill, Claude tends to suggest solutions immediately. Something is broken, here are five things that might fix it. This feels helpful but often wastes time because none of the suggestions address the actual problem.

With the systematic debugging skill, Claude approaches problems differently. It asks clarifying questions. It wants to see logs. It builds a model of what is happening before suggesting changes. When it proposes a fix, it explains why that fix addresses the root cause. Sometimes skills find problems you did not know about. One engineer pointed a skills-equipped Claude at a set of SEO pages and discovered they had been decaying for months with nobody watching. The infrastructure parallel is obvious: configuration drift, unused resources, permissions that expanded over time. A debugging skill that investigates before prescribing will find these things.

Skill	What it teaches Claude
`systematic-debugging`	Root cause investigation, pattern analysis, hypothesis testing, and verified implementation

npx skills add https://github.com/obra/superpowers --skill systematic-debugging

Catching security issues before they ship

Two skills cover different sides of security review. The wshobson/agents k8s-security-policies skill handles Kubernetes-specific hardening: NetworkPolicies, Pod Security Standards, RBAC, OPA Gatekeeper constraints, and service mesh mTLS configuration. The sickn33/antigravity-awesome-skills security-review skill covers application-level concerns like secrets management, SQL injection, XSS prevention, and input validation.

I asked Claude to check a Pulumi program that created an S3 bucket. Without the security skills, Claude confirmed the code was correct and moved on. With the skills loaded, it flagged that the bucket had no server-side encryption configured, the bucket policy allowed s3:* from an overly broad principal, and there was no access logging enabled. On the Kubernetes side, the k8s-security-policies skill catches things like missing default-deny NetworkPolicies and containers running as root. These skills are not a replacement for deterministic tools like tfsec, checkov, or trivy. Those catch known issues every time. Skills are probabilistic and work best as an extra layer during development, not as your only security gate.

Skill	What it teaches Claude
`k8s-security-policies`	Network policies, pod security standards, RBAC, and admission control for defense-in-depth
`security-review`	Secrets management, input validation, SQL injection, XSS/CSRF prevention, and dependency auditing

npx skills add https://github.com/wshobson/agents --skill k8s-security-policies
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill security-review

Incident response before you need it

At 3am when something breaks, you want runbooks. The incident-runbook-templates skill from wshobson/agents helps Claude create these before you need them. It includes a four-level severity model (SEV1 through SEV4) with response time expectations, escalation decision trees, and communication templates for status updates.

When you ask Claude to document your deployment process, it produces runbooks with diagnostic steps, rollback protocols, and verification checks. It knows kubectl commands for Kubernetes recovery and SQL procedures for PostgreSQL troubleshooting. The output needs editing. Generated runbooks tend to be thorough on the happy path but thin on the failure modes that matter most at 3am. I treat them as a first draft that gets me to 60% in minutes instead of hours, then fill in the gaps from experience.

Skill	What it teaches Claude
`incident-runbook-templates`	Detection, triage, mitigation, resolution, and communication procedures for production incidents

npx skills add https://github.com/wshobson/agents --skill incident-runbook-templates

General-purpose DevOps and SRE skills

The skills above target specific problems. The jeffallan/claude-skills repository also includes two broader skills that cover the day-to-day work that does not fit neatly into one category.

The devops-engineer skill gives Claude a senior DevOps engineer persona covering CI/CD pipelines, container management, deployment strategies like blue-green and canary, and infrastructure as code across AWS, GCP, and Azure. It enforces constraints I care about: no deploying to production without approval, no secrets in code, no unversioned container images.

The sre-engineer skill focuses on reliability: SLO/SLI definitions, error budget calculations, golden signal dashboards, and toil reduction through automation. It produces Prometheus/Grafana configs, remediation runbooks, and reliability assessments. If you run production systems and want Claude to think about error budgets instead of just uptime, this is the skill.

Skill	What it teaches Claude
`devops-engineer`	CI/CD pipelines, container management, deployment strategies, and infrastructure as code across clouds
`sre-engineer`	SLI/SLO management, error budgets, monitoring, automation, and incident response

npx skills add https://github.com/jeffallan/claude-skills --skill devops-engineer
npx skills add https://github.com/jeffallan/claude-skills --skill sre-engineer

Vetting the skills you install

Before you install everything in sight, a warning. Skills run with the same permissions as your AI agent. A malicious skill can exfiltrate credentials, download backdoors, or disable safety mechanisms, and it will look like your agent doing it.

Snyk researchers published ToxicSkills in February 2026 after scanning 3,984 skills from public registries. 13.4% had critical-level vulnerabilities, and they found 76 confirmed malicious payloads. The attack techniques included base64-encoded commands that steal AWS credentials, skills that direct you to download password-protected executables from attacker infrastructure, and jailbreak attempts that try to disable safety mechanisms. 91% of malicious skills combine code-level malware with prompt injection, so they attack on two fronts simultaneously.

Treat skills like you treat any third-party dependency:

Read the source before installing. Skills are markdown and YAML files. If you cannot read the full skill in a few minutes, that is a red flag.
Check the repository. Look at stars, contributors, and commit history. A single-commit repository from an unknown account deserves scrutiny.
Run uvx mcp-scan@latest --skills to scan installed skills for known malicious patterns, prompt injection, and credential exposure.
Be cautious with skills that fetch external content at runtime. The Snyk research found 17.7% of skills on ClawHub pull from third-party URLs, which means the skill’s behavior can change after you install it.
Stick to known repositories. Every skill recommended in this post comes from a repository with visible maintainers and community activity.

Eight malicious skills were still publicly available on ClawHub when Snyk published their findings. The skills ecosystem is young, and the vetting infrastructure is still catching up.

Build infrastructure with agent skills

Pulumi’s Agent Skills teach Claude Code, Cursor, or any coding agent the infrastructure patterns covered here. Install them, then build and deploy your stacks with fewer corrections.

Get started

Putting it together

Stacking skills is where this pays off. Install the Pulumi skills and Claude writes better infrastructure code. Add monitoring and security on top and you start catching problems that used to slip through to production.

A note on stacking: I have not hit conflicts running all of these simultaneously, but more skills means more descriptions for Claude to evaluate at startup. If you notice Claude getting slower or making odd choices, pare back to the skills you actually use for that project. Start with the Pulumi and monitoring skills, add others as you need them.

Here is how to set up a new project with all of them:

mkdir -p pulumi-skills-demo && cd pulumi-skills-demo
pulumi new aws-typescript --name skills-demo --yes

npx skills add https://github.com/dirien/claude-skills --skill pulumi-typescript
npx skills add https://github.com/pulumi/agent-skills --skill pulumi-esc
npx skills add https://github.com/pulumi/agent-skills --skill pulumi-best-practices
npx skills add https://github.com/obra/superpowers --skill systematic-debugging
npx skills add https://github.com/jeffallan/claude-skills --skill monitoring-expert
npx skills add https://github.com/jeffallan/claude-skills --skill kubernetes-specialist
npx skills add https://github.com/wshobson/agents --skill gitops-workflow
npx skills add https://github.com/wshobson/agents --skill github-actions-templates
npx skills add https://github.com/wshobson/agents --skill cost-optimization
npx skills add https://github.com/wshobson/agents --skill incident-runbook-templates
npx skills add https://github.com/jeffallan/claude-skills --skill devops-engineer
npx skills add https://github.com/jeffallan/claude-skills --skill sre-engineer
npx skills add https://github.com/wshobson/agents --skill k8s-security-policies
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill security-review

Then try these two prompts to see how many skills activate at once:

# Static website — triggers Pulumi TypeScript, monitoring, and security skills
Create a Pulumi TypeScript program for a static website on AWS with S3, CloudFront, OIDC credentials via Pulumi ESC, CloudWatch monitoring, and /security-review the infrastructure before deploying

# EKS cluster — stacks Kubernetes, GitOps, incident response, cost, and SRE skills
Create a Pulumi TypeScript program for an EKS cluster with /kubernetes-specialist security hardening, /gitops-workflow for ArgoCD deployment, /incident-runbook-templates for the cluster, /cost-optimization recommendations, and /sre-engineer SLO definitions for the services

The first prompt triggers the Pulumi TypeScript, monitoring, and security review skills in a single conversation. The second stacks Kubernetes, GitOps, incident response, cost, and SRE skills on one cluster build. You get infrastructure code, operational runbooks, and security policies from a single request.

What changes

Fair warning: not every skill works perfectly on the first try. Some need iteration. Some produce output that you have to review and tweak before it matches your standards. Skills do not replace your judgment.

That said, after a few weeks with these skills installed, I stopped correcting the same mistakes. The code Claude writes now looks like code I would write, not code I would have to fix. That is the whole point. Skills just stop you from repeating the same corrections across every conversation.

Get started

Every skill in this post includes its install command. Pick the section that matches your biggest pain point, run the npx skills add command, and try it on your next task. Skills work in Claude Code, Cursor, GitHub Copilot, and anything else that supports the Agent Skills standard.

The Pulumi Agent Skills announcement has more details, and the GitHub repository has the source. If you want something that goes further, with organizational context and deployment governance, look at Pulumi Neo. Neo is grounded in your actual infrastructure, not internet patterns. The 10 things you can do with Neo post shows what that looks like in practice.

Give it one project. That is all it took for me.

Try Pulumi for Free

Pulumi Agent Skills: Best practices and more for AI coding assistants

Pulumi Neo Team — Thu, 29 Jan 2026 00:00:00 +0000

AI coding assistants have transformed how developers write software, including infrastructure code. Tools like Claude Code, Cursor, and GitHub Copilot can generate code, explain complex systems, and automate tedious tasks. But when it comes to infrastructure, these tools often produce code that works but misses the mark on patterns that matter: proper secret handling, correct resource dependencies, idiomatic component structure, and the dozens of other details that separate working infrastructure from production-ready infrastructure.

We built Neo for teams that want deep Pulumi expertise combined with organizational context and deployment governance. But developers have preferred tools, and we want people to succeed with Pulumi wherever they work. Some teams live in Claude Code. Others use Cursor, Copilot, Codex, Gemini CLI, or other platforms. That is why we are releasing Pulumi Agent Skills, a collection of packaged expertise that teaches any AI coding assistant how to work with Pulumi the way an experienced practitioner would.

What are agent skills?

Skills are structured knowledge packages that follow the open Agent Skills specification. They work across multiple AI coding platforms including Claude Code, GitHub Copilot, Cursor, VS Code, Codex, and Gemini CLI. When you install Pulumi skills, your AI assistant gains access to detailed workflows, code patterns, and decision trees for common infrastructure tasks.

Available Pulumi skills

We are launching a set of skills organized into two plugin groups: authoring and migration. You can install all skills at once or choose specific plugin groups based on your needs.

Authoring skills

This plugin includes four skills focused on code quality, reusability, and configuration.

Pulumi best practices encodes the patterns that prevent common mistakes. It covers output handling, component structure, secrets management, safe refactoring with aliases, and deployment workflows. The skill flags anti-patterns that can cause issues with preview, dependencies, and production deployments.
Pulumi Component provides a complete guide for authoring ComponentResource classes. The skill covers designing component interfaces, multi-language support, and distribution. It teaches assistants how to build reusable infrastructure abstractions that work across TypeScript, Python, Go, C#, Java, and YAML.
Pulumi Automation API covers programmatic orchestration of Pulumi operations. The skill explains when to use Automation API versus the CLI, the tradeoffs between local source and inline programs, and patterns for multi-stack deployments.
Pulumi ESC covers centralized secrets and configuration management. The skill guides assistants through setting up dynamic OIDC credentials, composing environments, and integrating secrets into Pulumi programs and other applications.

Migration skills

Convert and import infrastructure from other tools to Pulumi. This plugin includes four skills covering complete migration workflows, not just syntax translation.

Terraform to Pulumi walks through the full migration workflow. It handles state translation, provider version alignment, and the iterative process of achieving a clean pulumi preview with no unexpected changes.
CloudFormation to Pulumi covers the complete AWS CloudFormation migration workflow, from template conversion and stack import to handling CloudFormation-specific constructs.
CDK to Pulumi covers the complete AWS CDK migration workflow end to end, from conversion and import to handling CDK-specific constructs like Lambda-backed custom resources and cross-stack references.
Azure to Pulumi covers the complete Azure Resource Manager and Bicep migration workflow, handling template conversion and resource import with guidance on achieving zero-diff validation.

How to install

Claude Code plugin marketplace

For Claude Code users, the plugin system provides the simplest installation experience:

claude plugin marketplace add pulumi/agent-skills
claude plugin install pulumi-authoring # Install authoring skills
claude plugin install pulumi-migration # Install migration skills

You can install both plugin groups or choose only the ones you need.

Universal installation

For Cursor, GitHub Copilot, VS Code, Codex, Gemini and other platforms, use the universal Agent Skills CLI:

npx skills add pulumi/agent-skills --skill '*'

This works across all platforms that support the Agent Skills specification.

Using skills

Once installed, skills activate automatically based on context. When you ask your assistant to help migrate a Terraform project, it draws on the Terraform skill’s workflow. When you are debugging why resources are being recreated unexpectedly, the best practices skill helps the assistant check for missing aliases.

In Codex and Claude Code, you can invoke skills directly via slash commands.

/pulumi-terraform-to-pulumi

Or describe what you need in natural language:

“Help me migrate this CDK application to Pulumi”

“Review this Pulumi code for best practices issues”

“Create a reusable component for a web service with load balancer”

The assistant will follow the skill’s procedures, ask clarifying questions when needed, and produce output that reflects Pulumi best practices rather than generic code generation.

Get started

We expect this collection to grow. If you have Pulumi expertise worth packaging, whether provider-specific patterns, debugging workflows, or operational practices, we welcome contributions. See the contributing guide for details.

The skills are available now in the agent-skills repository. Install them in your preferred AI coding environment and let us know what you build.

AI Predictions for 2026: A DevOps Engineer's Guide

Engin Diri — Thu, 11 Dec 2025 00:00:00 +0000

The IDE is dying, and so is tool calling. OpenAI is not going to win. And next year, you’re going to be shipping code that you’ve never reviewed before, even as an experienced engineer.

These are bold claims, but the way we use AI in 2026 for coding and agents is going to look completely different. In this post, I want to cover my predictions and why they matter right now for DevOps engineers. Some of these are definitely hot takes, but that’s what makes this conversation worth having.

IDEs are dead (at least as we know them)

Traditional IDEs where the code is the focus of the interface are simply going to become irrelevant. We’re moving toward agent manager interfaces where we can kick off agents in parallel to work on different features in a codebase or even work on different projects at the exact same time.

We’re already seeing this transition. Google Antigravity combines a familiar AI-powered coding experience with a new agent-first interface. You can deploy agents that autonomously plan, execute, and verify complex tasks across your editor, terminal, and browser. Cursor 2.0 lets you run up to eight agents in parallel on a single prompt, using git worktrees or remote machines to prevent file conflicts. Each agent operates in its own isolated copy of your codebase.

AWS validated this direction at re:Invent 2025 by announcing “frontier agents” including Kiro for autonomous coding, along with dedicated security and DevOps agents. These agents maintain state, log actions, operate with policy guardrails, and integrate directly with CI/CD pipelines.

For infrastructure specifically, Pulumi Neo represents this same shift. Instead of writing code or running CLI commands for every operation, you describe what you need in natural language and Neo handles the implementation. It works across your entire infrastructure, understanding dependencies and creating execution plans that go through pull requests for review.

For DevOps engineers, this means your pipelines need to accommodate AI-generated code at scale. Multiple agents working simultaneously need isolated, reproducible environments. More generated code means more artifacts to track, version, and deploy.

The different paths to AI dominance

A lot of people think that in the future, a single large language model will have a monopoly and be the best at absolutely everything. But what’s really going to happen is different providers will specialize and focus on being the best at different things.

Google is going down the generalist route with Gemini, aiming to be the jack-of-all-trades. Anthropic is focusing on being the best for coding. You can see this in the benchmarks: when Opus 4.5 came out, the first benchmark they highlighted was for software engineering, because that’s what Anthropic is focusing on.

Amazon is carving out its own niche with the Nova model family, announced at re:Invent 2025. The Nova 2 lineup includes specialized models: Pro for complex reasoning, Sonic for real-time voice conversations, and Omni for simultaneous text, audio, and video processing. With Nova Forge, organizations can build custom frontier models by combining their proprietary data with AWS open weight models. The re:Invent message was clear: leveraging your first-party data is now fundamental to going beyond generic AI. We’re talking about 30-40% increases in accuracy when you bring your own data into the equation.

But here’s the hot take: I don’t think OpenAI is going to come out on top with any kind of specialization. They’ve disappointed time and time again with GPT-5 and GPT-4.5. With 4.5, they seemed to try to be the creative specialist, but it just didn’t work. The GPT-5 launch in August 2025 was described as “barely better than last month’s flavor of the month” and on some metrics it’s actually worse than earlier models.

For DevOps teams, this specialization means you’ll need infrastructure that’s model-agnostic and supports multiple AI backends. Plan for secrets management across multiple LLM providers and design your systems to swap models based on the task at hand.

The local AI breakthrough

2026 will be the year of local AI. We didn’t see that much this year besides DeepSeek at the start of 2025, which was a big deal. We had a couple of new models like Qwen 3, but nothing that fundamentally changed the game. Now we’re starting to see new hardware that makes it obvious we’re going to be able to run very large models on smaller devices.

There’s new AI chips that can run upwards of 120 billion parameter large language models on the edge, which would be a complete game-changer. Right now, hardware requirements are one of the biggest challenges for scaling local AI. If we can solve the hardware problem, we get 100% data privacy and zero-millisecond latency for our agents.

AWS is addressing this with Trainium3 UltraServers, their 3nm AI chips delivering 4.4x more compute than the previous generation. More significantly, AWS AI Factories allow organizations to deploy racks of Trainium chips and NVIDIA GPUs directly into their own data centers, addressing data sovereignty concerns while keeping AI inference close to the data.

For DevOps, this opens the door to zero-latency inference in CI/CD pipelines, complete data privacy for sensitive codebases, and reduced cloud costs for AI-heavy workloads.

Engineers as system architects

We’re finally going to get to the point where we’re not the coders. We delegate that entirely to our coding agents, and we become the system architects. This mirrors the evolution of other engineering disciplines. Civil engineers don’t fabricate the steel beams; they design the structure and verify the integrity.

I think of this as a three-step process:

Define: Set your objectives and the system that your agents will operate under
Orchestrate: Delegate the coding to your agents
Validate: Ensure the quality of the outputs and the overall system

We’re still in the loop. We are the final say in whatever is created, but we’re delegating the grunt work to our coding agents.

This is exactly the model that Pulumi Neo implements for infrastructure. When you give Neo a complex request, it creates a task plan outlining the steps it will take to accomplish your goal. This plan provides transparency into Neo’s approach and gives you the opportunity to adjust the strategy before execution begins. Neo operates in different modes: Review mode where everything requires approval, Balanced mode where only deployments need sign-off, or Auto mode for full autonomy. You define the boundaries, Neo orchestrates the work, and you validate through pull requests and previews.

For DevOps engineers, this shift means building robust validation infrastructure becomes critical. When AI writes the code, you need automated testing pipelines, security scanning, and verification systems that can operate at the speed of AI-generated changes.

Code execution is replacing tool calling

Here’s a key insight that kept coming up at re:Invent: models are no longer the bottleneck. Context is. Our agents are going to change a lot next year because code execution is starting to replace tool calling. The problem with tool calling right now is that all the capabilities you give an agent take up context upfront. When you try to give a lot of different tools to an agent, you completely overwhelm it.

Anthropic’s research on code execution with MCP addresses exactly this problem. Code execution is a massive token reduction, faster, and more flexible. You’re giving the agent the ability to generate its own capabilities at runtime by writing code to interact with APIs. A workflow that previously consumed about 150,000 tokens when tools were passed directly through the model was reimplemented with code execution and used only about 2,000 tokens. That’s a 98.7% reduction.

AWS embraced this pattern with Amazon Bedrock AgentCore, which now includes code interpretation capabilities. AgentCore supports any agent framework (CrewAI, LangGraph, OpenAI SDK) and provides memory, browser tools, and observability features that make code execution practical at enterprise scale.

For DevOps, this means you need sandboxed, secure execution environments for AI-generated code. Running agent-generated code requires appropriate isolation, resource limits, and monitoring.

Progressive disclosure and composable skills

The best part about code execution flexibility is it unlocks progressive disclosure. All I mean by that is: you have a lot of capabilities for an agent, but you don’t actually give all of them upfront. Instead, you allow the agent to discover capabilities and then leverage them in a more flexible way.

For each capability, you just have a bit of metadata or description that loads upfront. When the agent decides to leverage that capability, then you load the full instructions. Now you can practically scale to infinity because all capabilities don’t have to be loaded at runtime.

Claude Skills is a good example of this pattern. Skills are organized folders of instructions, scripts, and resources that agents can discover and load dynamically. At session start, the agent scans available skills and populates the system prompt with just a brief name and description (around 100 tokens). The full skill prompt loads only after Claude selects it, preventing context bloat while maintaining discoverability.

Kiro Powers addresses the same problem. Connecting five MCP servers can consume over 50,000 tokens, roughly 40% of an AI model’s context window, before you even type your first request. Powers bundle MCP servers, steering files, and hooks into units that load dynamically based on conversation context. Mention “payment” and the Stripe power activates. Datadog, Figma, and others have powers available.

For DevOps, this translates to modular infrastructure definitions, on-demand capability loading, and efficient resource utilization. Think about how you can apply this pattern to your own automation.

Equip your agents with Pulumi skills

Give Claude Code, Cursor, or any coding agent working Pulumi patterns through Agent Skills and the Pulumi MCP server, so it generates infrastructure that deploys.

Get started

Agent-to-agent protocols are finally happening

Agent-to-agent protocols are where AI agents operate in a peer network, discover each other’s capabilities in real time, and interact autonomously. When Google released their A2A protocol earlier this year, there was a ton of buzz. A lot of people thought it was going to be the next big standard, like the next MCP. But then it kind of fell to the wayside.

The big reason is the chicken-and-egg problem. For A2A to be useful, you need many people to adopt it at the same time. Otherwise, if you build an A2A-compatible agent, it has no other agents to talk to. The whole value proposition is lost unless you already have a big network to attach to.

But that’s finally changing. The Linux Foundation launched the A2A project in June 2025, and adoption is accelerating. Adobe, Microsoft, SAP, ServiceNow, and S&P Global are all implementing A2A. In July 2025, Google released version 0.3 of the A2A protocol with a more stable interface critical to accelerating enterprise adoption.

Machines paying machines

My next big prediction is that machines paying machines is going to become a very big thing. Coinbase released the x402 protocol for exactly this: building AI agents that you expose over the internet but require payment whenever someone else interacts with them.

This goes really well with agent-to-agent protocols. You can create a peer network where you monetize your agents. They all leverage each other but make payments whenever they take advantage of another agent’s capabilities. Cryptocurrency is the perfect solution for this kind of machine-to-machine network because it enables micropayments to be made quickly and globally.

The x402 protocol has achieved 156,000 weekly transactions with 492% growth since launching in May 2025. It’s now integrated with Anthropic’s MCP Protocol, Google Gemini, OpenAI Codex, and other platforms. Stablecoins like USDC enable charging per request, per service, or per second of usage at near-zero transaction costs, enabling payments as low as $0.001 per request.

Artifact reviews instead of diff reviews

When we want to do a rigorous code review, traditionally, we look line by line at all the changes. But coding agents are getting to the point where they can prove their code works through artifacts. Instead of reviewing line by line, we can look at browser recordings, full working demos of a backend API, and other artifacts.

Google Antigravity is a perfect example. As part of its coding process, it can autonomously spin up your website, visit it, scroll through it, take screenshots, and record everything. Agents generate artifacts, including tangible deliverables like task lists, implementation plans, screenshots, and browser recordings. You can verify the agent’s logic at a glance.

Amazon Nova Act takes this further. It enables AI agents to automate browser-based tasks like form filling, QA testing, and workflow validation with over 90% reliability. The service includes built-in observability through live viewing, CloudTrail logging, and session replay, making it possible to review what an agent actually did rather than parsing through code changes.

Shipping code you’ve never read

For the last prediction, we’re tying everything together. We’ve talked about reviewing artifacts instead of diffs, creating systems instead of coding, and the new capabilities for agents with code execution.

We’re going to get to the point very quickly where we’re shipping code that we have never read before. And I’m not talking about people who vibe code. Even experienced engineers are going to trust their systems so much that they have the ability to review the code but they’re not going to. We’re just going to ship to production after reviewing the artifacts.

I presented on this exact topic at the Tel Aviv Pulumi User Group meetup at Qodo HQ back in October, where I demonstrated how Pulumi Neo’s autonomous decision-making capabilities can handle infrastructure tasks that we traditionally managed manually. Qodo is doing fascinating work in this space with their agentic development tools, building systems that let you trust the output without necessarily reviewing every line.

I’m not saying we’re taking the human completely out of the loop. I’m saying we’re going to have a lot of trust in our systems and a validation process that includes us, but that doesn’t necessarily have to be us actually looking at the code. Tools like Pulumi Neo create pull requests with clear documentation of changes, run previews to validate infrastructure modifications, and provide the transparency needed to ship with confidence.

The path forward

The predictions I’ve outlined point to a fundamental shift in how software gets built and deployed. For DevOps engineers, this isn’t a threat but an opportunity to become more strategic and less operational. We’re entering the battle of the agentic frameworks, where the winners will be those who can build faster, cheaper agentic applications through their platforms.

The immediate reality is that your CI/CD pipelines need to accommodate AI-generated code at scale, your secrets management needs to handle multiple LLM providers, and your execution environments need proper sandboxing for agent-generated code. These aren’t future concerns; they’re requirements for working effectively with the AI tools available today.

Looking further out, the engineers who thrive will be those who embrace the system architect role. Define clear objectives and constraints for your AI agents. Build validation frameworks that can verify outcomes without requiring line-by-line code review. Design infrastructure that’s modular enough to load capabilities on demand.

The technology to make this happen already exists. Agent orchestration platforms are shipping. Code execution is replacing tool calling. Progressive disclosure patterns are proven. The question isn’t whether these changes are coming; it’s whether you’ll be ready when they arrive.

Start building for the AI-driven future today

If you want to experience what this future looks like right now, Pulumi Neo is the place to start. Neo lets you make natural language requests for routine infrastructure tasks, analysis, and management. Instead of writing code for every operation, you describe what you need, and Neo handles the implementation, creating task plans, running previews, and opening pull requests for your review.

Whether you’re looking to update outdated resources across your infrastructure, analyze your cloud spend, or automate complex multi-step workflows, Neo provides the agent-first experience that’s defining the next generation of DevOps tooling.

Get started with Pulumi Neo and see how AI-powered infrastructure automation can transform your workflow.
Project: Build a production-ready AI agent by moving from local prototypes to deployed infrastructure with Amazon Bedrock AgentCore, the Strands SDK, and Pulumi.

Encode What You Know With Neo: Custom Instructions and Slash Commands

Pulumi Neo Team — Tue, 09 Dec 2025 00:00:00 +0000

Every organization builds up knowledge over time: naming standards, compliance requirements, patterns your team has settled on, and proven approaches to common tasks. Until now, bringing this knowledge into Neo meant repeating it manually each time - specifying preferences, describing how your team works, and recreating prompts that someone already perfected.

Two new features change this. Custom Instructions teach Neo your standards so it applies them automatically. Slash Commands capture proven prompts so anyone on your team can use them with a keystroke.

Custom Instructions: Standards Applied Automatically

Custom Instructions let you define what Neo should know about your organization and how it should behave. This includes naming conventions, required tags and compliance requirements, technology preferences, and cost guidelines - but also actions Neo should take automatically, like including a rough cost estimate whenever it proposes new infrastructure. You configure them once in your organization settings, and Neo applies them to every task from that point forward.

Consider the difference. Before Custom Instructions, a simple request required loading context:

“Neo, update our Lambda functions to Node 20. Remember, we use TypeScript exclusively, our naming convention is service-region-env, we always deploy to us-east-1 first for testing, and all resources need our standard compliance tags including CostCenter and DataClassification.”

With those details captured in Custom Instructions, the same request becomes:

“Neo, update our Lambda functions to Node 20.”

Neo already knows how your team works, so you can focus on what you’re trying to accomplish.

Slash Commands: Capture What Works

Over time, your team figures out the right way to ask Neo for certain tasks. Maybe someone wrote the perfect prompt for checking policy violations, or discovered an approach to drift detection that catches issues others miss. That knowledge tends to live in someone’s head or buried in a Slack thread.

Slash Commands turn these prompts into shortcuts anyone can use. When you type / in Neo, you’ll see available commands, select one, and Neo receives the full prompt behind it.

Neo ships with built-in commands for common tasks:

Command	What it does
`/get-started`	Learn what Neo can do and how to structure effective requests
`/policy-issues-report`	Lists your most severe policy violations
`/component-version-report`	Lists components that are outdated in your private registry
`/provider-version-report`	Lists providers that are outdated

You can also create your own. In Pulumi Cloud, you define the prompt - no coding required. Once saved, your team can start using it immediately. If a command needs more information than what’s provided, Neo will ask follow-up questions to fill in the gaps.

Get Started

Custom Instructions and Slash Commands are available now. You can configure Custom Instructions in Neo Settings. Slash Commands come with several built-in options, and you can create custom ones tailored to your workflow.

Future of the Cloud: 10 Trends Shaping 2026 and Beyond

Sara Huddleston — Thu, 04 Dec 2025 07:56:40 +0000

In 2026, several trends will dominate cloud computing, driving innovation, efficiency, and scalability. From Infrastructure as Code (IaC) to AI/ML, platform engineering to multi-cloud and hybrid strategies, and security practices, let’s explore the 10 biggest emerging trends.

On This Article

1. Cloud Will Become a Business Necessity by 2028
2. Hyperscalers Accelerate AI-Driven Cloud Expansion
3. Hybrid and Multi-Cloud to Drive Innovation
4. Enterprises Rebuild Their Cloud Foundations to Operationalize AI
5. IaC Drives Scalable Cloud, Multi-Cloud, and AI Operations
6. DevSecOps Evolves Into AI-Integrated Security
7. Platform Engineering and Internal Developer Platforms
8. AIOps Matures Into a Cloud Operations Standard
9. Kubernetes Dominance and Increased Complexity
10. AI Code Assistants in the Enterprise
The Future of Cloud: Reinvented for an AI-First Decade

1. Cloud Will Become a Business Necessity by 2028

According to Gartner, by 2028 the cloud will be the key driver for business innovation, and estimates that over 95% of new digital workloads will be deployed on cloud-native platforms.

The future of cloud computing. Credit: Gartner

According to McKinsey & Company’s “In search of cloud value” report:

Cloud value is driven by innovation, worth 5x more than cost savings.
EBITDA uplift of 20–30% by 2030 for high-performing organizations.
Asia leads in projected cloud value, followed by the US and Europe.
High-ROI organizations excel by aligning cloud strategy with business priorities, building strong cloud foundations, and using modern operating models.

Teams succeeding in this transition increasingly use Infrastructure as Code, automation, and unified governance frameworks like Pulumi Insights + Policies to operationalize this value.

2. Hyperscalers Accelerate AI-Driven Cloud Expansion

Hyperscalers are making the largest infrastructure investments in cloud history — nearly all centered on AI workloads, inference, and high-performance compute.

AWS has integrated Anthropic’s Claude 3 and Claude 4 models into Amazon Bedrock for enterprise LLM workflows. “Claude Opus 4 and Claude Sonnet 4 are available today in Amazon Bedrock, enabling customers to build agents with stronger reasoning, memory, and tool use.” — AWS, May 2025
Microsoft Azure revenue rose 33% year-over-year in Q3 (ended March 31), outperforming estimates of ~29.7%. AI contributed 16 percentage points to this growth, up from 13 points in the prior quarter. “Microsoft is on track to invest approximately $80 billion to build out AI-enabled datacenters to train AI models and deploy AI and cloud-based applications around the world,” said Brad Smith, the Microsoft Vice Chair and President.
Google Cloud is committing $25 billion over two years for data center and AI infrastructure expansion across the PJM grid, with total capital expenditure for 2025 ranging from $75–85 billion. “As our CEO has said, in these early days of a very transformative technology, the risks of under-investing are dramatically higher than the risks of over-investing,” said Eunice Huang, Head of AI and Emerging Tech Policy.
Oracle anticipates 15–20% cloud revenue growth in FY 2026–2027 attributable to AI infrastructure demand, tied to its partnership in the Stargate initiative.

As hyperscalers integrate AI deeper into their service layers, engineering teams must adapt with IaC-driven automation, reusable patterns, and policy controls to deploy cloud and AI infrastructure consistently. See how organizations deploy AWS infrastructure at the speed of AI with Pulumi and Pulumi Policies.

3. Hybrid and Multi-Cloud to Drive Innovation

Hybrid and multi-cloud strategies are now mainstream:

Hybrid cloud will grow from $130B to $310–330B by 2030 (ResearchAndMarkets).
87% of enterprises run workloads across multiple clouds (Mordor Intelligence).
Gartner predicts that 40% of enterprises will adopt hybrid compute architectures in mission-critical workflows by 2028 (up from 8%).

Credit: Cloud Worldwide Service, Forbes

As AI and regulatory requirements grow, organizations must deploy workloads across AWS, Azure, Google Cloud, on-prem, and edge — while maintaining consistent security, compliance, and configuration.

Modern cloud teams use:

Infrastructure as Code for consistent multi-cloud provisioning and environment standardization, forming the backbone of AI infrastructure orchestration
Reusable components and internal platforms to define scalable architecture patterns and accelerate delivery across Kubernetes, AI/ML pipelines, and hybrid environments
Policy-driven guardrails to maintain cost, security, and compliance across environments, supporting cloud governance automation and modern cloud cost governance

Pulumi enables all three through its multi-cloud IaC model, Pulumi Policies, and internal developer platform capabilities.

4. Enterprises Rebuild Their Cloud Foundations to Operationalize AI

While hyperscalers are transforming the global cloud platform, enterprises face a different challenge: adapting their own cloud foundations to support AI at scale. Organizations are moving beyond prototypes and integrating AI into core products, internal workflows, and customer-facing systems, requiring new levels of automation, governance, and AI infrastructure orchestration.

According to Gartner, global AI infrastructure spending is expected to surpass $2 trillion in 2026. IDC predicts that by 2027, more than 50% of enterprises will use AI agents to drive core workflows, which requires scalable, secure, and automated cloud architectures to support model execution and orchestration.

To enable this transition, enterprises are investing in:

GPU provisioning and orchestration, data pipelines, vector databases, feature stores, and LLM infrastructure needed for real-time AI workloads.
Data pipelines, vector databases, and feature stores needed for real-time AI workloads
Model-serving infrastructure, including gateways, inference routers, and autoscaling layers
Strong identity, secrets, and access controls as AI systems increase security exposure
Automation through Infrastructure as Code to ensure reproducibility and reduce drift
Policy-driven governance to secure cost, compliance, and architectural consistency

As AI becomes deeply embedded across engineering organizations, teams are increasingly using software engineering approaches such as Infrastructure as Code, reusable components, platform engineering, and policy automation to standardize how AI infrastructure is deployed, scaled, and secured across clouds.

To support this shift, Pulumi’s perspective on Superintelligence Infrastructure explains why AI workloads, from pre-training to inference at massive scale, require dynamic infrastructure orchestration rather than static configuration.

Pulumi users increasingly rely on:

Pulumi IaC for standardized AI infrastructure
Pulumi ESC to manage all secrets and configuration at scale
Pulumi Insights for visibility and misconfiguration analysis
Pulumi Policies for AI-specific guardrails in code, cost detection, and to provide automated compliance protections

5. IaC Drives Scalable Cloud, Multi-Cloud, and AI Operations

As cloud environments expand and AI workloads demand highly dynamic infrastructure, Infrastructure as Code (IaC) is becoming the foundation for scaling reliably across all environments. Organizations are increasingly adopting IaC in general-purpose languages to unify development and infrastructure workflows, reduce configuration drift, and deliver cloud resources at speed.

Modern Infrastructure as Code is advancing far beyond simple provisioning:

Standardizing multi-cloud and hybrid patterns so teams can deploy consistently across AWS, Azure, Google Cloud, on-prem, and edge environments.
Integrating seamlessly with cloud providers and third-party services, including data platforms and messaging systems like CockroachDB, Confluent Cloud, and Kafka.
Providing deeper validation and type-safety, ensuring parameters, dependencies, and security controls are correct before deployment.
Improving cloud resource efficiency and visibility with tools like Pulumi Insights Discovery.
Embedding security and compliance through Policy as Code, enforcing guardrails, cost controls, and regulatory requirements automatically, enabling truly policy-driven cloud management.
Enabling intelligent automation, from unit and integration tests to auto-remediation policies and policy-driven approvals.
Incorporating AI-driven optimization and insights, helping teams detect misconfigurations, analyze usage patterns, and generate infrastructure updates with tools like Pulumi Neo and Pulumi Policies.

As organizations scale both traditional cloud workloads and AI-driven systems, IaC has become critical for achieving secure, repeatable, and high-velocity operations across every environment.

6. DevSecOps Evolves Into AI-Integrated Security

As AI becomes embedded across cloud-native systems, DevSecOps is entering a new era. Gartner predicts that by 2028, over 50% of enterprises will use AI security platforms to protect their AI investments. Below are the 3 key predictions for the future of DevSecOps:

AI-driven security automation: Teams will increasingly rely on AI to detect threats, enforce policies, and generate secure infrastructure patches. See Pulumi’s capabilities in AI-powered remediation.
More focus on secrets management: With AI systems accessing more sensitive data, secure secret storage will be essential. Pulumi ESC helps teams centralize and govern credentials, keys, and tokens safely.
Greater cross-team collaboration: Dev, Sec, and Ops workflows will converge under shared frameworks: IaC, policy automation, runtime scanning, and GitOps.

As organizations increase their use of AI across cloud-native systems, the need for tightly aligned security, governance, and cloud governance automation becomes even more urgent. At the Gartner Data & Analytics Summit in Sydney, Carlie Idoine, VP Analyst at Gartner, emphasized this growing dependency:

"[AI]… it doesn’t deliver value on its own – AI needs to be tightly aligned with data, analytics, and governance to enable intelligent, adaptive decisions and actions across the organization."

This perspective mirrors what we’re seeing across modern DevSecOps practices: AI can amplify security, but only when paired with strong foundations in secrets management, governance, and cross-team collaboration.

Build for an AI-first cloud

Pulumi gives teams infrastructure as code, reusable components, and policy guardrails to deliver consistently across every cloud and AI workload.

Get started

7. Platform Engineering & Internal Developer Platforms (IDPs)

According to Gartner, by 2026, 80% of large software engineering organizations will establish platform engineering teams as internal providers of reusable services, components, and tools for application delivery. Platform engineering will ultimately solve the central problem of cooperation between software developers and operators.

Mid-size to large companies will begin or continue to invest in implementing platform engineering practices, with large tech companies as first adopters. They will provide Internal Developer Platforms (IDP) to elevate the Developer Experience (DX, sometimes referred to as DE or DevEx), helping them work faster, like abstracting the complexities of configuring, testing, and validation, deploying infrastructure, and scanning their code for security.

Internal developer platform-in-a-box. Credit: Pulumi

IDPs are reshaping how developers interact with cloud infrastructure, bringing together platform engineering, automation, and emerging AI platform engineering practices.

8. AIOps Matures into a Cloud Operations Standard

AIOps is becoming mainstream, helping teams predict failures, auto-scale infrastructure, and resolve incidents with minimal manual effort. As AI and automation continue to evolve, the fusion of these technologies will enable organizations to achieve unprecedented levels of efficiency and scalability.

Proactive Operations: AI-powered tools will assist teams in foreseeing issues with greater accuracy, minimizing downtime, and reducing the firefighting nature of incident management. These tools will automatically detect anomalies, optimize performance, and trigger remediation actions.
Intelligent Automation: Routine operational tasks like patching, monitoring, and resource scaling will be fully automated. AI-driven decision-making will allow for smarter resource allocation and optimization, dynamically adjusting infrastructure and workloads in response to real-time demands and predictions.
Data-Driven Insights: AIOps will analyze vast amounts of operational data and provide actionable insights, enabling teams to focus on high-impact tasks such as improving system architecture and user experience. The AI-powered insights will also inform better strategic decisions, helping teams to continuously evolve their DevOps practices.
Collaboration Across Teams: AIOps will bridge the gap between DevOps, SecOps, and IT operations by bridging monitoring and automation. Cross-team collaboration will improve as AI systems consolidate and interpret data from various departments, allowing for a more cohesive approach to system management.

AIOps features include observability, automation, and real-time analytics to bridge DevOps, SRE, and IT operations.

9. Kubernetes Dominance and Increased Complexity

Kubernetes will continue its ascent in 2026. According to Research & Markets, the global Kubernetes market was valued at USD 2.3 billion in 2024 and is projected to reach USD 8.2 billion by 2030, with a CAGR of 23.8% over the forecast period.

The CNCF Annual Survey shows AI/ML workloads rapidly moving onto Kubernetes — including batch pipelines, model experimentation, real-time inference, and data preprocessing — even as only 41% of ML/AI developers are cloud-native today. This shift is accelerating as teams need flexible GPU scheduling, distributed pipelines, and portable execution environments.

Kubernetes is also evolving in response to AI demands. Inference workloads, powered by LLMs and GPUs, now require low-latency execution closer to the user. This shift is pushing organizations to build intelligent orchestration layers that schedule AI pipelines across edge and core clusters, often leveraging Kubernetes as the common control plane for AI cluster orchestration.

As we move into 2026, three patterns are becoming clear:

Kubernetes is evolving to support AI through GPU-aware scheduling, Kubernetes GPU scheduling optimizations, and more advanced workload orchestration.
Governance and consistency matter more than ever, as teams struggle to secure and manage multi-cluster, multi-cloud environments.
Platform engineering is essential, providing curated patterns and automation rather than raw YAML to reduce cognitive load.

Kubernetes will remain a strategic foundation — but operating it effectively now depends on robust automation, strong security controls, and standardized delivery models that scale across clouds, clusters, and AI pipelines.

10. AI Code Assistants in the Enterprise

AI-powered coding assistants like GitHub Copilot, Claude Code, Cursor, and others are rapidly becoming part of modern software development.

By 2027, the use of AI assistants will dramatically increase developer velocity to meet functional business requirements for 70% of new digital solutions in production (source: IDC).

The value of AI code assistants. Credit: Gartner

According to Gartner, by 2028, 75% of enterprise software engineers will use dedicated AI code assistants, and 63% of organizations are currently piloting, deploying or beginning to use AI code assistants.

As enterprise adoption of AI assistants increases, expectations are rising: they must not only generate code but also understand the state of infrastructure, configurations, and security posture. That means being able to answer questions about environments, surface misconfigurations, or act directly on infrastructure.

One of the newest developments is the release of Pulumi Agent Skills, a collection of infrastructure expertise packaged for use in AI coding assistants. These skills teach tools such as Claude Code, Cursor, or Gemini CLI to reason about Pulumi projects, reducing hallucination and improving outputs based on real infrastructure conventions and practices.

Combined with infrastructure access via tools like Pulumi’s Remote MCP Server, teams can build secure, AI-driven workflows where assistants provide insights and Pulumi Neo safely executes actions with previews, policies, and orchestration.

AI code assistants are no longer experimental; they’re fast becoming a competitive advantage in cloud software development.

The Future of Cloud: Reinvented for an AI-First Decade

Cloud infrastructure is entering its most transformative era since the rise of Kubernetes. The trends shaping 2026 reveal a clear pattern: AI is no longer a workload — it’s becoming the organizing principle of cloud strategy.

AI-native cloud architectures that require elastic compute, GPU orchestration, fast data access, and governance built into every layer
Infrastructure as Code as the operational backbone, standardizing deployments across AI, cloud, and hybrid environments
Platform engineering and IDPs to enable self-service, gold-standard patterns, and automated guardrails
Security integrated into every pipeline, with AI-assisted threat detection, strong secrets management, and policy-driven compliance
AIOps and intelligent automation are becoming standard for scaling modern cloud systems
Kubernetes evolving for AI, driving new orchestration patterns across edge, core, and inference clusters
Multi-cloud and hybrid ecosystems accelerating to support interoperability, resilience, and global workload placement

Taken together, these shifts point to a new model of cloud operations that is intelligent, automated, policy-aware, and built on software engineering principles rather than manual configuration.

Organizations that invest now in modern IaC, unified governance, reusable components, and policy frameworks — all core capabilities of the Pulumi Cloud platform — will be positioned to lead in an AI-first world. The gap between teams that modernize and those that do not will widen rapidly in 2026 and beyond.

Try Pulumi for Free

Beyond YAML in Kubernetes: The 2026 Automation Era

Sara Huddleston — Wed, 12 Nov 2025 07:09:46 +0000

Kubernetes continues to evolve, powering not only applications but entire AI and ML systems across clouds, edges, and enterprises. By 2026, DevOps engineers, SREs, cloud engineers, and platform teams face growing pressure to deliver faster, smarter, and more secure infrastructure at scale.

Kubernetes automation is entering a new era where infrastructure as code, policy enforcement, and AI-driven orchestration work together to manage cloud environments intelligently.

Pulumi’s 2025 advancements, including Pulumi Kubernetes Operator 2.0 GA, new Kubernetes best practices playbooks, Pulumi Neo for AI assisted infrastructure management, and Policy Automation, set the foundation for a new era of Kubernetes automation that extends across every role involved in managing modern infrastructure.

In this Kubernetes article:

Why Kubernetes Needs to Go Beyond YAML

The article Kubernetes Best Practices I Wish I Had Known Before highlights a key challenge: relying solely on YAML as the source of truth for Kubernetes is no longer sustainable. Clusters are dynamic, environments multiply, and static YAML files cannot keep up with the complexity of modern infrastructure.

Teams across disciplines face similar challenges:

Multi-cluster and hybrid-cloud sprawl
Inefficient manual configuration and drift
Lack of policy enforcement and governance at scale
Secrets scattered across systems

Pulumi addresses these challenges by introducing general-purpose programming languages such as TypeScript, Python, Go, C#, and Java into Kubernetes management. This approach enables teams to define, test, and share reusable infrastructure code, bridging the gap between declarative manifests and modern software engineering practices.

Learn more: Pulumi Kubernetes documentation

The 2026 Convergence of AI, Platforms, and Policy in Kubernetes

The CNCF State of Cloud Native Development Q3 2025 report shows that more than half of DevOps professionals and nearly a third of all developers now identify as cloud native. Adoption of hybrid and multi-cloud architectures continues to grow, while AI and ML workloads are becoming first-class citizens in Kubernetes environments. The report notes that 41% of professional ML and AI developers are cloud native, confirming that Kubernetes has become a foundational technology for building intelligent, scalable systems.

This trend highlights how the next generation of Kubernetes operations is evolving. Teams need unified platforms that simplify AI-driven workloads, automatically enforce governance, and reduce operational complexity across environments. Pulumi already delivers this through an integrated platform that brings automation, security, and developer productivity together in one place.

Pulumi’s platform provides a complete foundation for intelligent infrastructure management that extends from development to production.

Pulumi Neo adds AI-assisted infrastructure management that turns natural language into production-ready Kubernetes and cloud code.
Pulumi IDP enables engineering and platform teams to build self-service environments that abstract complexity for developers while maintaining consistency and control.
Pulumi Policies brings continuous compliance and policy enforcement directly into the delivery workflow.
Pulumi ESC secures credentials, API keys, and sensitive configurations across Kubernetes and cloud environments.

Together, these capabilities form a unified automation and governance layer for Kubernetes and cloud native systems.

The result is a model where infrastructure, policy, and developer experience work together to power secure, scalable, and AI-ready platforms that meet the needs of engineering teams of every size and discipline, from application development to security and cloud operations.

The 2026 Shift: AI-Assisted Kubernetes Operations

The next phase of Kubernetes management will be AI-driven, context-aware, and self-healing. Infrastructure will not only follow instructions but also understand intent. This is the vision behind Pulumi Neo, an AI Infrastructure Agent designed to help teams automate complex systems.

Pulumi Neo can interpret natural-language requests such as “deploy a GPU-backed EKS cluster with three node groups,” generate infrastructure code that adheres to organizational policies, and continuously refine that code as environments change.

AI-powered observability and decision-making. According to the CNCF Annual Survey, 93% of organizations already use or plan to adopt AI-driven monitoring and predictive analysis for Kubernetes environments. The goal is to identify performance and reliability issues before they affect users. Pulumi Policies assists to get clean and stay clean, while Neo extends this capability by acting on those insights, transforming detected issues into actionable infrastructure updates that teams can validate or deploy.
ML and GPU workloads on Kubernetes. As organizations expand AI and ML pipelines across clusters, automation and cost efficiency become critical (FinOps Foundation). Pulumi Insights is an intelligent infrastructure management service that helps you discover, understand, manage, and improve your infrastructure. Insights improves security, compliance, and efficiency through AI-powered asset and compliance management.
Unifying DevOps, SRE, and MLOps workflows. The convergence of software and model delivery continues to accelerate (TechRadar). Pulumi’s code-based approach, combined with Neo’s agentic reasoning, creates a unified workflow for infrastructure, applications, and AI systems.

Additional insights and demonstrations:

Kubernetes and Pulumi Neo together represent a future of autonomous infrastructure management, where AI assists teams in deploying, maintaining, and improving their environments intelligently and securely.

Operator-First: Kubernetes Deploys Your Cloud

The Pulumi Kubernetes Operator 2.0 GA introduced a Kubernetes-native approach to infrastructure management. Each Pulumi stack becomes a Kubernetes Custom Resource, allowing Kubernetes itself to execute Pulumi programs written in any supported language. This enables:

Management of AWS, Azure, and GCP infrastructure from within the cluster
Integration with GitOps systems such as Argo CD and Flux
Continuous reconciliation and drift detection through Pulumi’s state and policy engine

With the new Pulumi Kubernetes Operator 2.3, the operator gets even more production-ready features:

Faster and more resilient stack updates through improved workspace lifecycle management
Support for multi-namespace and multi-tenant deployments
Better visibility with enhanced events, status reporting, and error surfacing
Performance improvements for large-scale environments and parallel stack operations

Documentation: Using the Pulumi Kubernetes Operator

Kubernetes beyond YAML

Define clusters, workloads, and policies in TypeScript, Python, or Go, and manage EKS, AKS, and GKE from a single code-first workflow.

Get started

Intelligent Infrastructure Across Every Cloud

Kubernetes has become the control plane for everything from application deployments to AI and ML workloads across clouds and environments. Engineering teams are running clusters on Amazon EKS, Microsoft AKS, and Google GKE while also managing edge, hybrid, and on-premises environments. Pulumi extends Kubernetes automation across all of them, unifying clusters, workloads, and cloud resources under a consistent model of infrastructure as code.

With Pulumi, teams can use familiar programming languages to define Kubernetes resources, cloud infrastructure, and policies together. This approach provides a single workflow for managing compute, networking, storage, and identity across multiple clouds without relying on brittle YAML templates. It enables consistent provisioning, policy enforcement, and automation across every cluster and environment.

By treating Kubernetes as the universal control plane for cloud infrastructure, Pulumi gives teams a scalable foundation that adapts to any workload and environment. The result is an intelligent, multi-cloud Kubernetes infrastructure that combines the flexibility of cloud providers with the reliability of modern automation.

Bring Your YAML and Helm, Then Evolve

Teams do not need to start from scratch. Pulumi supports importing existing YAML manifests and Helm charts to help organizations adopt a code-first approach incrementally. Many teams begin by wrapping existing manifests in Pulumi code, then refactor them into reusable components that enforce best practices and compliance policies.

This hybrid approach enables modernization without disrupting existing CI/CD pipelines or team workflows.

Begin Your Kubernetes Automation Journey

For teams preparing for the next phase of Kubernetes management in 2026:

Get Started with Kubernetes to create your first Pulumi program.
Add the Pulumi Kubernetes Operator to enable infrastructure deployments from within your clusters.
Integrate GitOps workflows with Argo CD, Flux, or Jenkins X.
Apply policy guardrails to enforce security and compliance automatically.
Refactor infrastructure into reusable components for consistent, scalable operations.

Agentic Workflows for Production-ready Kubernetes

Experience Kubernetes automation in practice. See how agentic workflows power production-ready Kubernetes by automating GitOps operations, managing environments, and reducing manual effort in this on-demand workshop.

Watch Agentic Workflows for Production-ready Kubernetes to learn how to:

Provision and manage clusters across clouds using general-purpose programming languages
Multi-cloud Kubernetes infrastructure management
Fleet management with GitOps (Argo CD)
Reduce YAML complexity while maintaining reliability and speed

Watch On Demand.

Final Thoughts

Kubernetes in 2026 and beyond is not just for platform engineers. It is for DevOps professionals, SREs, and cloud teams, big and small, responsible for maintaining infrastructure security, reliability, and performance. Pulumi unifies infrastructure as code, secrets management, policy governance, and AI automation into a single platform, enabling every team to adopt an intelligent, code-driven approach to Kubernetes that scales across workloads, clouds, and the AI-driven future.

Try Pulumi for Free

Announcing the Next Generation of Pulumi Policies: AI-Accelerated Governance for the Cloud

Craig Symonds — Wed, 05 Nov 2025 00:05:00 +0000

The era of AI-accelerated development has created a paradox: the faster developers move, the bigger the governance challenge becomes. For years, security and platform teams have worked to “shift left,” but the tools available have been incomplete. Most focus on detection, which is necessary but not sufficient. They identify thousands of policy violations across an organization’s infrastructure but leave teams with an overwhelming backlog and no scalable way to remediate it. This creates a persistent gap between finding a problem and fixing it. The result is an impossible choice between development velocity and organizational control, forcing leadership to slow down innovation to manage risk.

Today, we end that compromise.

We are thrilled to announce the next generation of Pulumi Policies, a comprehensive governance solution that moves beyond detection to deliver AI-powered remediation at scale. We’re introducing a new lifecycle to secure your cloud: first, Get Clean by using AI to fix your existing policy violations. Second, Stay Clean by using policy as a universal guardrail that makes AI-driven development not just fast, but fundamentally safe. These are not strictly sequential steps; you can begin enforcing “Stay Clean” policies for all new infrastructure while you simultaneously work on the “Get Clean” process for your existing footprint.

Watch our Launch Video:

Part 1: Get Clean - From Thousands of Issues to a Compliant State

The first step to a secure cloud is tackling the mountain of existing misconfigurations spread across your environments.

First, Gain Complete Visibility with the New Policy Findings Hub

To fix your issues, you first need to see them clearly. We have introduced a powerful Policy Findings Hub designed to give every stakeholder the exact view they need.

The Overview Tab: A high-level dashboard with compliance scores for leadership to track trends and measure your organization’s posture.
The Compliance Tab: A control-centric view for auditors and infosec teams, grouping findings by policy (e.g., CIS, NIST) to simplify evidence gathering and prove compliance.
The Issues Tab: A collaborative workspace for platform and development teams to triage, assign, prioritize, and track the remediation of every policy issue.

This hub is powered by our flexible audit capabilities. With Audit Scans for IaC Stacks, you can get an instant compliance baseline on all your existing Pulumi-managed infrastructure without blocking developers or re-deploying thousands of stacks. This is combined with discovery scans of your cloud accounts to give you a single, unified view of every resource, whether managed by Pulumi or not.

The Solution to Remediation at Scale: AI-Powered Fixes with Pulumi Neo

Visibility creates a new problem: an overwhelming backlog. Manually fixing thousands of issues is an impossible task.

This is where Pulumi Neo provides a powerful solution.

Pulumi Neo, our AI platform engineer, is now integrated directly into the Policy Findings hub to automate the most difficult part of the process: the fix itself. From the Issues tab, your teams can now select a group of policy issues, assign them to Neo, and trigger a remediation flow.

Neo is smart. It will:

Analyze the non-compliant resources and the policies they are violating.
Understand the required configuration to make them compliant.
Generate a pull request with the exact code changes needed to fix the issues.

Most powerfully, for an unmanaged resource discovered via a cloud scan, Neo will generate the code to import the resource into a Pulumi stack and apply the fix. This “Import and Fix” workflow transforms unmanaged infrastructure into governed, compliant code, turning a task that could take a developer hours into a simple review-and-merge process. Your teams can finally burn down their issue backlog and achieve a state of continuous compliance.

Part 2: Stay Clean - The Universal Guardrail for Humans and AI

Once you begin cleaning your environment, the next challenge is to stay clean. As AI accelerates infrastructure creation, you need robust guardrails to ensure it doesn’t also accelerate the creation of security risks.

The answer is Policy as Real Code. Pulumi Policies uses general-purpose languages like TypeScript and Python to create sophisticated guardrails that govern every change. To help you establish these controls immediately, we are launching a new suite of pre-built compliance packs authored and maintained by Pulumi experts.

Framework	AWS	Azure	Google Cloud
CIS Controls v8.1	✅	✅	✅
NIST SP 800-53 Rev. 5	✅
PCI DSS v4.0	✅
HITRUST CSF v11.5	✅	✅	✅
Pulumi Best Practices	✅	✅	✅

These policies act as a universal guardrail for your entire organization by blocking non-compliant changes during pulumi up, before they are ever created. Learn more about our compliance packs.

And now, you can even use Neo to author new policies. You can ask Neo in plain English to “create a policy that prevents overly permissive IAM roles,” and it will generate the code for you. This creates a powerful, dynamic governance system where AI can help you build the very rules that then govern its own actions. If you then ask Neo to create an admin role, the deployment will be blocked by the policy it just helped write. This is how we make AI safe to go fast.

A New Era of Collaboration

This “Get Clean, Stay Clean” lifecycle transforms how teams work together:

Platform Teams lead prevention by building real-code guardrails, proving their value with measurable compliance scores.
Security Teams drive the “Get Clean” process with continuous, non-blocking audit scans and use the Findings hub to manage compliance without slowing development.

Governance That Accelerates You

The age of AI-driven development demands AI-powered governance. With this new generation of Pulumi Policies, we are providing the essential infrastructure for platform engineering teams to not just survive, but thrive. You can finally build preventative guardrails that developers love, secure your cloud at scale, and transform governance from a blocker into a business accelerator. Learn more about Pulumi Insights & Governance capabilities.

This powerful new experience is available today. Navigate to the Policies and Policy Findings tab in Pulumi Cloud to explore your new governance capabilities and meet the future of platform engineering.

Try Pulumi Policies

Ready to try these features?

Sign up for Pulumi Cloud and start a Neo task
Read the Get Started guide to set up and apply a policy group to stacks and clouds.
Join the Community Slack to share feedback on the new features

For complete documentation, visit our Policies documentation.

Component Usage Tracking in Pulumi Private Registry

Pulumi IDP Team — Tue, 28 Oct 2025 00:00:00 +0000

Platform teams publishing components to the Pulumi Private Registry can now see exactly which stacks are using each component and at which version.

The visibility problem

You’ve published a new major version of a component to your private registry. Most teams across your organization have adopted it. Then you need to answer a critical question: “Which teams still haven’t adopted it?”

This visibility gap creates real consequences. When a security vulnerability appears in an old version, you can’t assess the blast radius. When you want to deprecate a version, you don’t know which teams need to migrate. When you release a new feature, you can’t measure adoption. Version sprawl accumulates silently.

Centralized components, centralized visibility

The Pulumi IDP registry solves this by providing both centralized distribution and centralized insight. When you publish a component to the registry, you automatically gain visibility into its usage across your organization.

The new usage tracking feature shows:

Which stacks are using your component
What version each stack is running
When each stack was last updated

Access usage data through the “Used By” tab on any component’s detail page in the registry. The view respects your existing access controls, showing only stacks you have permission to see.

Why this matters

This visibility transforms conversations that were previously not possible or painfully slow.

Security response: When a vulnerability is discovered in version 1.2.0 of your component, you can immediately identify every affected stack and reach out to the right teams. What used to take hours or days of detective work now takes minutes.

Deprecation planning: Before removing support for version 1.x, you can see exactly which teams are still using it and coordinate migration timelines with complete information.

Version sprawl management: See the full distribution of versions in use across your organization and make informed decisions about consolidation.

The registry becomes your source of truth, not just for distributing components, but for understanding how they’re used.

Get started

If you’re already publishing components to the Pulumi IDP registry, usage tracking is automatically available. Visit any component detail page to see the “Used By” tab.

If you haven’t published to the registry yet, now is the time to start. Publishing a component is as simple as running pulumi publish.

For more information, see the private registry documentation.

Grounded AI: Why Neo Knows Your Infrastructure

Engin Diri — Fri, 24 Oct 2025 00:00:00 +0000

Ask a generic LLM to “fix my broken deployment,” and you’ll get generic advice. Ask Pulumi Neo the same question, and you’ll get a fix plan grounded in your actual infrastructure state.

The difference isn’t about better prompts or newer models. It’s about what the AI actually knows. Generic LLMs have been trained on the internet. Neo has been trained on your infrastructure.

This distinction matters more than you’d think.

The grounding problem

Most AI tools treat infrastructure like a text generation problem. You describe what you want, the model produces code, and you hope it works.

This approach fails more often than it succeeds because the AI has no connection to your actual infrastructure. It doesn’t know what resources you’ve already deployed, what dependencies exist, or what policies you need to follow. It’s generating code from patterns it learned on the internet, not from understanding your environment.

Pulumi Neo takes a different approach. It’s trained on your infrastructure context: your programs, your state, your resource relationships. When you ask Neo about drift, it doesn’t guess. It queries your actual deployment history. When it suggests a fix, it reasons from your program graph, not generic examples.

Neo doesn’t just autocomplete code. It understands state, resources, dependencies, and cloud behavior. When something fails, Neo explains why, not just what.

This is what makes it grounded AI: it’s anchored to the reality of your infrastructure, not floating in a sea of internet-trained probabilities.

What makes Neo different

The foundation matters more than you’d think.

Traditional AI tools fail in DevOps because they operate in a vacuum. Ask a generic LLM to “fix my broken deployment,” and you’ll get generic advice that ignores your specific infrastructure, your state, your constraints.

The difference with systems like Pulumi Neo comes down to what powers them: not just data, but context.

Think of it this way: a data lake is a massive repository of information sitting inert, waiting to be queried. A context lake is something else entirely. It’s a structured repository that aggregates knowledge about your domain and feeds it to AI systems.

A context lake contains things that matter:

Your infrastructure programs, resource definitions, API schemas, service dependencies. In Pulumi’s case, this includes your program graph, component models, stack configurations.

Real-time metrics, deployment history, drift detection, policy violations. The live pulse of your infrastructure as it actually runs in production.

Ownership information, compliance policies, access controls, quality signals. The organizational context that determines what changes are safe, who can make them, and why they matter.

Pulumi’s approach builds on this principle. Your infrastructure programs, state files, resource metadata, policy definitions. All of this becomes queryable context. Neo doesn’t hallucinate solutions because it’s grounded in your actual infrastructure. It knows what you’ve deployed, how resources relate to each other, what dependencies exist, what’s drifted.

This is the architectural shift that makes AI-powered DevOps actually work. AI agents are only as effective as the context they can access and the guardrails you have in place to keep them in check. You’re not just automating actions anymore. You’re automating understanding.

Grounded reasoning in practice

Early DevOps automated actions. Modern AI agents automate decisions. But grounded AI does something different: it automates understanding.

When you combine observability data, infrastructure-as-code programs, and deployment history into a context lake, the AI doesn’t just predict what might happen. It reasons about what is happening based on your actual infrastructure state.

Neo can watch infrastructure drift, identify whether it stems from a manual change or a misconfigured resource, and generate a fix plan that maps back to your Pulumi program. That feedback isn’t guesswork. It’s grounded in the same infrastructure metadata developers already use. The context lake ensures Neo isn’t making probabilistic predictions. It’s reasoning from your specific infrastructure truth.

This is what separates grounded AI from generic LLMs. Neo doesn’t just automate deployment. It understands the intent behind it.

The human layer stays critical

Grounded AI doesn’t replace engineering judgment. Every engineer who’s tried to prompt a generic LLM to “write a Pulumi program for me” knows how quickly hallucinations creep in. You still need human context: the judgment to choose the right platform, the discipline to model dependencies, the awareness of compliance and cost.

That’s where grounded AI like Neo fits best. It’s not a chatbot for infrastructure. It’s an extension of your own reasoning.

Neo learns from the same program graph and state data you already manage, drawing from a continuously updated context lake of your infrastructure reality. Its recommendations stay grounded in your environment, not floating in a generic prompt window trained on the public internet.

The opportunity isn’t about replacing engineers. It’s about creating smarter feedback loops between human expertise and AI that actually understands your infrastructure.

What grounded AI enables

The first generation of DevOps automated deployment. Grounded AI automates understanding.

Infrastructure becomes queryable. AI-powered observability correlates incidents before they cascade. CI/CD becomes continuous reasoning rather than continuous execution. Platform teams spend less time fighting YAML and more time guiding systems that reason alongside them.

The context lake architecture makes this possible. Instead of static documentation and scattered tribal knowledge, your infrastructure context becomes something AI agents can actually query and reason over.

Grounded AI won’t replace engineers. But it will change what engineering means: less time translating intent into YAML, more time reasoning about systems at a higher level.

Try it yourself

Want to see what infrastructure cognition looks like in practice? Get started with Neo and ask it about your infrastructure. Watch it reason through drift detection, generate fix plans, or explain complex resource relationships in plain English. For a wider survey of the category, see our guide to the best AI infrastructure tools.

Neo is available today for teams using Pulumi Cloud. The cognitive layer isn’t coming. It’s already here.

Day 2 Operations: Drift Detection and Remediation

Mitch Gerdisch — Fri, 24 Oct 2025 00:00:00 +0000

Welcome to the fourth post in our IDP Best Practices series. Today we’re diving into the world of drift detection and remediation, those critical day 2 operations that keep your infrastructure aligned with its intended configuration long after the initial deployment.

You’ve built a beautiful platform with robust guardrails, comprehensive templates, and well-defined golden paths. Your developers are productive, deployments are smooth, and everything seems perfect. Then reality hits. An on-call engineer makes an emergency change through the AWS console during a 3 AM incident. A team member tweaks a security group rule to debug a connection issue and forgets to revert it. Auto-scaling adjusts capacity based on load patterns. Before you know it, your actual infrastructure has quietly diverged from what your code describes.

This post continues our journey through the IDP Best Practices series. We’ve covered strategy and self-service infrastructure, built golden paths with components and templates, and established deployment guardrails through policy as code. Now we’re tackling what happens after deployment when the real world starts making changes to your carefully crafted infrastructure.

The Reality of Infrastructure Drift

Let me paint you a picture that might feel uncomfortably familiar. It’s Saturday afternoon, and you’re enjoying a barbecue with friends when your phone buzzes with that dreaded alert: production is down. You rush to your laptop, but you’re not on the corporate VPN. The AWS console is accessible, but you can’t reach the application itself to properly diagnose the issue.

Faced with a growing incident and impatient stakeholders, you make a quick decision. You modify the security group directly in the console, temporarily allowing access from anywhere (0.0.0.0/0) just so you can get in and fix the problem. Twenty minutes later, the issue is resolved, everyone’s relieved, and you return to your barbecue. That temporary security group change? It stays there, a silent time bomb waiting to be discovered in your next security audit.

This scenario plays out in organizations every day. Your infrastructure has now drifted from its intended state, and it will continue drifting, accumulating more changes, until someone or something notices and fixes it. Each untracked change increases the gap between what you think you have and what actually exists in production.

Understanding the Prevention vs. Detection Paradigm

When building a robust platform, you need to think in layers of defense. Your first instinct might be to prevent all drift from happening in the first place, and that’s absolutely the right starting point. But prevention alone isn’t enough in the messy reality of production operations.

Prevention: The First Line of Defense

Prevention is what we’ve been building throughout this series. You establish code reviews where teammates scrutinize infrastructure changes before they go live. You implement automated testing that validates configurations before deployment. You deploy CrossGuard policies that act as guardrails, blocking misconfigurations before they can cause damage. You create standardized components that encode best practices, making it easier to do the right thing than the wrong thing.

These preventative measures work brilliantly for changes that flow through your normal IaC pipeline. They catch typos, enforce standards, and maintain consistency across your infrastructure. But they have a critical blind spot: they can’t see changes that bypass your pipeline entirely.

Detection and Remediation: The Safety Net

This is where drift detection enters the picture. Think of it as continuous verification, constantly comparing what should exist with what actually exists. While prevention blocks most issues at the gate, detection catches everything that finds another way in.

What kinds of changes slip past prevention? Emergency modifications made during incidents when there’s no time for a proper code review. Console changes made by well-meaning engineers debugging production issues. External factors you can’t control, like AWS changing service limits or deprecating API endpoints. Even accidental modifications by team members who thought they were in the staging environment.

The truth is, no matter how robust your preventative controls, you need detective controls to maintain infrastructure integrity. Prevention and detection work together, creating a comprehensive defense against infrastructure chaos.

What Is Infrastructure Drift?

Infrastructure drift sounds technical, but the concept is surprisingly simple. Drift occurs when your actual infrastructure state doesn’t match your declared state in code. It’s the gap between intention and reality, between what you coded and what’s actually running.

To understand drift properly, you need to grasp three distinct states that Pulumi manages. First, there’s the desired state, which is what your Pulumi program declares in code. This is your intention, your blueprint for how things should be. Then there’s the current state, stored in Pulumi’s state file, which tracks what Pulumi believes exists based on its last interaction with your cloud provider. Finally, there’s the actual state, the ground truth of what really exists in your cloud provider right now.

The journey to drift typically follows a predictable pattern. You start by running pulumi up to deploy your resources, and everything is in perfect harmony. Pulumi creates the resources, records their configuration in its state file, and all three states align perfectly. Time passes, and your resources continue running in the cloud, serving traffic and doing their job.

Then someone makes a manual change. Maybe they modify a resource directly in the console, or an external system alters a configuration. Suddenly, your actual state has diverged from both your current state (what Pulumi thinks exists) and your desired state (what your code says should exist). You now have drift, and it will persist until you detect and address it.

Pulumi’s Drift Detection and Remediation Workflow

Pulumi provides a complete workflow for handling drift that’s both powerful and surprisingly straightforward. Rather than treating drift as an exceptional case, Pulumi makes it a routine part of infrastructure management.

1. Drift Detection with `pulumi refresh`

The foundation of drift detection is the pulumi refresh command. When you run this command, Pulumi springs into action, querying your cloud providers to discover the actual state of your resources. It then compares this reality against what it has recorded in its state file:

# Run drift detection
pulumi refresh --preview-only

# This command:
# 1. Reads your current Pulumi state
# 2. Queries cloud providers for actual resource configurations
# 3. Identifies any differences
# 4. Reports what has drifted

The --preview-only flag is particularly useful here. It shows you exactly what’s drifted without making any changes to your state file. You get a clear report of the differences, allowing you to review and understand the drift before deciding how to handle it.

2. State Reconciliation with `pulumi refresh`

After reviewing the drift, you face a decision. If the changes are legitimate and should be preserved, you can update your state file to match reality:

# Update state file to match cloud reality
pulumi refresh

# This command:
# 1. Detects drift (as above)
# 2. Updates state file to match actual cloud state
# 3. Prepares for remediation via pulumi up

This reconciliation step is crucial. It acknowledges the current reality and updates Pulumi’s understanding of your infrastructure without making any actual changes to your resources. You’re essentially telling Pulumi, “This is what actually exists right now.”

3. Drift Remediation with `pulumi up`

With your state file now reflecting reality, you can use pulumi up to remediate the drift. This command compares the updated state against your code and determines what changes are needed to restore your infrastructure to its intended configuration:

# Remediate drift - restore to desired state
pulumi up

# This command:
# 1. Compares updated state with your Pulumi program
# 2. Identifies required changes
# 3. Applies changes to restore infrastructure

This three-step dance of detect, reconcile, and remediate gives you complete control over how you handle drift. You can review changes, decide whether to keep or revert them, and ensure your infrastructure returns to its intended state.

Automating Drift Detection with Pulumi Deployments

Running pulumi refresh manually works great for small teams and simple infrastructures, but it doesn’t scale. As your platform grows to dozens or hundreds of stacks across multiple environments, manual drift detection becomes impossible. This is where Pulumi Deployments transforms drift detection from a manual chore into an automated safeguard.

Setting Up Automated Drift Detection

The journey to automated drift detection starts with connecting your infrastructure code to Pulumi’s deployment system. Let’s walk through the setup process.

Step 1: Configure Deployment Settings

Your first step is connecting Pulumi to your source control system using Deployment Settings. This integration allows Pulumi to access your infrastructure code and run automated operations:

Pulumi offers native integrations with all major version control systems. If you’re using GitHub, you get full app integration with PR previews, making it easy to see the impact of changes before merging. GitLab users enjoy similar functionality with merge request automation. For other Git providers or self-hosted solutions, you can use raw Git integration with direct repository access using credentials.

Step 2: Create Drift Detection Schedules

With your source control connected, you can now configure automated drift detection to run on whatever schedule makes sense for your organization. Some teams check hourly for production environments, while others might run daily checks for development stacks:

For environments where you’re confident in your automation, you can take it a step further and enable automatic remediation:

With auto-remediation enabled, Pulumi not only detects drift but automatically runs pulumi up to restore your infrastructure to its intended state. This is powerful but should be used carefully, especially in production environments.

Step 3: Configure Webhooks for Notifications

Detecting drift is only valuable if the right people know about it. Pulumi’s webhook system ensures your team stays informed when drift occurs:

You can route notifications wherever your team actually pays attention. Send alerts directly to Slack channels where your ops team congregates. Push notifications to Microsoft Teams if that’s your collaboration platform. Use custom webhooks to integrate with PagerDuty, Datadog, or any other monitoring system. You can even use deployment triggers to automatically run dependent stacks when drift is detected and fixed.

Automate drift detection with Pulumi

Connect your stacks to Pulumi Deployments, schedule drift checks across every environment, and route alerts to Slack or Teams the moment your infrastructure diverges from code.

Get started

Handling Common Drift Scenarios

Every organization faces similar drift scenarios. Understanding how to handle these common cases will prepare you for real-world operations.

Scenario 1: Emergency Hotfix

The most common drift scenario occurs during incidents. Someone makes an emergency change to fix production, and now you need to decide whether to keep or revert that change:

# 1. Acknowledge the drift
pulumi refresh --stack production

# 2. Review the changes
pulumi preview --stack production

# 3. Either incorporate or revert
# Option A: Accept the change
pulumi refresh --stack production --yes

# Option B: Revert to code
pulumi up --stack production --yes

The key here is having a clear process. First, acknowledge the drift by running refresh to update your state. Then review the changes carefully. Finally, make an explicit decision: either accept the change by updating your code to match, or revert it by running pulumi up to restore the original configuration.

Scenario 2: Legitimate External Changes

Not all drift is bad. Auto-scaling groups adjust capacity based on load. Managed services update configurations automatically. Some changes are legitimate and should be preserved:

// Mark resources that can change externally
const autoScalingGroup = new aws.autoscaling.Group("app-asg", {
 minSize: 2,
 maxSize: 10,
 // ... other config
}, {
 ignoreChanges: ["desiredCapacity"] // Ignore scaling changes
});

The ignoreChanges option tells Pulumi to ignore specific properties when detecting drift. Use it for fields that legitimately change outside your control, like auto-scaling capacity or last-modified timestamps.

Scenario 3: Configuration Drift

Sometimes drift occurs in configuration values rather than resource structure. IP allowlists, feature flags, and environment-specific settings often drift. Handle these with Pulumi’s configuration system:

# Use Pulumi's configuration system
config = pulumi.Config()
allowed_ips = config.get_object("allowed_ips") or ["10.0.0.0/8"]

security_group = aws.ec2.SecurityGroup("app-sg",
 ingress=[{
 "from_port": 443,
 "to_port": 443,
 "protocol": "tcp",
 "cidr_blocks": allowed_ips # Managed via configuration
 }]
)

By externalizing configuration values, you make them easier to update without code changes. This pattern works particularly well for values that change frequently or differ between environments.

The Value of Automated Drift Detection

After implementing drift detection for hundreds of stacks, patterns emerge that tell a compelling story about its value. The transformation begins subtly but grows profound as teams discover what they’ve been missing.

The first change most organizations notice is in their security posture. Where once unauthorized changes might lurk undetected for weeks, only surfacing during quarterly audits or worse, during incident investigations, now they’re caught within minutes. Security teams who previously dreaded audit season find themselves with continuous compliance data at their fingertips. Every change, whether legitimate or not, creates an audit trail that transforms compliance reporting from a scrambling fire drill into a routine export of already-collected data.

As teams settle into this new reality, operational improvements become apparent. Incidents that used to take hours to diagnose now resolve in minutes because engineers can immediately check whether drift contributed to the problem. One team reported that their mean time to recovery dropped by 40% simply because they could eliminate drift as a cause within seconds rather than spending hours manually comparing configurations. Change management, once a bureaucratic nightmare of spreadsheets and approval chains, transforms into an automated system where every modification is tracked, timestamped, and traceable to its source.

Then come the unexpected discoveries. Drift detection becomes a cost optimization tool that nobody anticipated. It uncovers orphaned resources spinning away forgotten in some corner of your cloud account, created during a debugging session six months ago. It catches that instance someone manually upgraded to a larger size during a performance investigation and forgot to downsize. One organization discovered they were spending $15,000 monthly on resources that weren’t even supposed to exist, all caught by their drift detection system in its first week of operation.

Perhaps most importantly, drift detection changes how teams work. Engineers stop wasting time on manual infrastructure audits. Debugging accelerates when you have clear reports showing exactly what changed and when. The constant anxiety about whether production matches your code disappears, replaced by confidence that any discrepancies will be caught and reported immediately. Teams report feeling more empowered to move quickly, knowing they have a safety net that will catch configuration drift before it causes problems.

The cumulative effect is transformative. Organizations running drift detection report not just fewer incidents and lower costs, but a fundamental shift in how they think about infrastructure management. It becomes proactive rather than reactive, confident rather than anxious, automated rather than manual. What starts as a simple scheduled check evolves into a cornerstone of operational excellence.

Getting Started with Drift Detection

Ready to implement drift detection for your IDP? Here’s a practical action plan that you can execute today.

Quick Start Checklist

Begin with the simplest possible drift detection: a manual check on your production stack. Run pulumi refresh --preview-only --stack production to see if you have any existing drift. This takes just 15 minutes and often reveals surprising discrepancies.

Next, invest 30 minutes in setting up automated detection. Configure Pulumi Deployments, create an hourly detection schedule for your most critical stack, and set up Slack notifications so you’ll know immediately when drift occurs.

Spend the next week monitoring and learning. Review the drift patterns that emerge. Identify common causes. Are certain resources drifting repeatedly? Are changes happening at predictable times? Document which changes are legitimate and which represent problems.

After a week of observation, you’re ready to implement remediation. Start with non-production environments where mistakes have lower impact. Enable auto-remediation gradually, monitoring success rates and adjusting your configuration based on what you learn.

Finally, optimize and scale your drift detection. Adjust schedules based on the patterns you’ve observed. Implement custom workflows for complex scenarios. Expand coverage to all your environments and stacks. What starts as a simple check becomes a comprehensive system protecting your entire infrastructure.

Conclusion: Day 2 Operations as a Competitive Advantage

Drift detection and remediation represent more than just good hygiene; they’re competitive advantages in a world where infrastructure complexity keeps growing.

Teams with robust day 2 operations move faster because they have confidence in their infrastructure state. They recover quickly from incidents because they can immediately identify what changed. They maintain security without slowing development by automatically detecting and reverting unauthorized modifications. Most importantly, they scale operations without scaling headcount, automating work that would otherwise require armies of engineers manually checking infrastructure.

The math is compelling. A single undetected security group change could lead to a breach costing millions. One overlooked configuration drift might cause hours of downtime. Yet implementing comprehensive drift detection takes just hours of setup and minutes of ongoing maintenance. The ROI is immediate and substantial.

Our IDP journey continues with “Extend Your IDP for AI Applications: GPUs, Models, and Cost Controls”. As AI workloads become central to modern applications, we’ll explore how to adapt your platform for machine learning workflows. You’ll learn about GPU orchestration, model deployment pipelines, and the unique cost management challenges that AI infrastructure presents.

But don’t wait for the next post to get started with drift detection. Even a simple hourly check can prevent major incidents. Set up basic detection today, and your future self will thank you the next time you’re debugging a production issue at 3 AM. More importantly, your on-call team will appreciate not having to debug issues caused by accumulated drift that could have been prevented.

Ready to implement drift detection? Start your free Pulumi Cloud trial and set up your first drift detection schedule in minutes. No credit card required.

Neo Gets Smarter: New Modes, CLI Access & Sonnet 4.5

Pulumi Neo Team — Mon, 20 Oct 2025 00:00:00 +0000

Neo just got significantly more capable. We’ve shipped three major updates: Operating Modes for flexible control, full ecosystem tool access, and Claude Sonnet 4.5 for better performance on complex infrastructure tasks.

You decide how much control you keep

The same action has different risks in different contexts. Building a new dev environment is low risk. Opening a PR that changes shared infrastructure requires more scrutiny.

Operating Modes let you adjust autonomy based on context:

Review Mode: You approve the task plan, preview, and PR. You see everything before it happens.
Balanced Mode: Neo handles planning and previews. You approve mutating operations, such as updates or destroys. Less friction, control where it matters.
Auto Mode: Neo runs without stopping. For when you need speed and trust the outcome.

You can use Review Mode when Neo is updating production infrastructure. Use Balanced Mode when deploying application updates where you want to verify destructive changes but trust routine operations. Switch to Auto Mode when spinning up temporary dev environments for testing. You pick the mode that matches your situation. The same agent, flexible levels of autonomy.

Neo can do more

Neo now has access to more tools and information. This means it can handle more complex scenarios and work with the broader ecosystem your infrastructure depends on.

Full Pulumi CLI access: Neo can now run all Pulumi CLI operations, including stack imports, state management, and plugin operations that previously required manual intervention.
Ecosystem tooling built in: Neo now includes kubectl, Helm, AWS CLI, GCP, and Oracle Cloud CLI. This means Neo can verify Kubernetes deployments, install Helm charts, and run cloud-specific operations without leaving your workflow.
Private registry search: Your team builds reusable components to accelerate development and codify standards. Neo can now search your organization’s private registry, including READMEs, to find and use them. You get the benefit of your team’s existing work.

Sonnet 4.5

Neo now runs on Anthropic’s Sonnet 4.5 by default. Sonnet 4.5 delivers better performance on complex, multi-step infrastructure tasks that require sustained reasoning across multiple files and services.

Try Neo

Ready to try these features?

Sign in to Pulumi Cloud and start a Neo task
Read the Neo documentation for detailed guides
Join the Community Slack to share feedback on the new features

10 Things You Can Do With Our Infrastructure Agent, Neo

Meagan Cojocar — Mon, 06 Oct 2025 00:00:00 +0000

Since launching Pulumi Neo two weeks ago, we’ve seen platform teams discover creative ways to put their newest AI teammate to work. We have also been using Neo internally for a handful of use cases. Neo shifts the conversation from “what could AI do for infrastructure?” to “what can I actually accomplish with Neo today?”

The answer is quite a bit. Here are 10 concrete workflows that platform teams can use Neo for right now, each one designed to save hours of manual work while keeping humans in the driver seat.

1. Explain infrastructure in plain English or diagrams

Neo answers questions about your infrastructure instantly, turning complex resource relationships into conversational insights (and diagrams!).

No more digging through AWS consoles or parsing state files to understand what you have deployed. Neo speaks your language about your infrastructure. Ask questions like “What databases do we have?”, “Which S3 buckets aren’t encrypted?”, “Show me all resources in us-east-1” or “draw an architecture diagram of our service” and get immediate, accurate answers.

2. Generate infrastructure code from natural language

Neo turns plain English descriptions into production-ready Pulumi code, eliminating the blank-page problem that slows down new projects.

Instead of starting from scratch or hunting through documentation, describe what you need and Neo generates the complete infrastructure. Ask Neo: “Create a serverless API with PostgreSQL database and Redis cache on AWS” and it produces fully configured resources with proper networking, security groups, and IAM policies.

3. Assist with Terraform to Pulumi migration

Neo analyzes existing Terraform code (and/or state files) and generates equivalent Pulumi programs, accelerating migration without starting from scratch.

Migrating from Terraform to Pulumi traditionally means rewriting everything. Neo understands both languages and can convert HCL to TypeScript, Python, or Go while preserving your infrastructure patterns. You can also use the Terraform state file. Ask Neo: “Analyze the provided terraform state. Based on it, generate a python pulumi program that imports the resources without requiring updates.” and it generates equivalent code with proper typing and best practices.

Using this prompt with a Terraform state file containing EC2 instances and supporting resources, Neo generated a complete Pulumi program that imported everything without requiring updates:

4. Automate CI/CD pipeline generation

Neo creates complete GitHub Actions workflows configured specifically for Pulumi deployments, with proper preview stages.

Setting up CI/CD for infrastructure projects usually involves copying workflows from other repos and adapting them. Neo generates purpose-built pipelines that understand your stack structure and deployment patterns. Ask Neo: “Create a GitHub Actions pipeline for this Pulumi project with preview and production stages” and it produces workflows with proper secrets management, approval gates, and deployment strategies.

Here is what Neo gives us using that prompt on a very basic Pulumi project:

name: Simple Pulumi Deploy

on:
 push:
 branches: [main]
 workflow_dispatch:

env:
 PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
 AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
 AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

jobs:
 deploy:
 runs-on: ubuntu-latest
 steps:
 - name: Checkout code
 uses: actions/checkout@v4

 - name: Install Pulumi
 uses: pulumi/actions@v4
 with:
 pulumi-version: latest

 - name: Configure AWS credentials
 uses: aws-actions/configure-aws-credentials@v4
 with:
 aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
 aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
 aws-region: us-west-2

 - name: Deploy infrastructure
 run: |
 pulumi stack select production
 pulumi up --yes
 working-directory: ./infrastructure

5. Identify inefficient infrastructure patterns

Neo analyzes your infrastructure and spots patterns that create unnecessary management overhead, helping you consolidate and optimize.

When you have 10 identical EC2 instances that should be an auto-scaling group, or multiple Lambda functions doing the same job, Neo spots these patterns. Ask Neo: “Analyze our infrastructure for inefficient patterns” and it can identify consolidation opportunities.

Example analysis:

Neo identified these optimization opportunities:

1. Duplicate EC2 Instances (High Priority)
 • Found 8 identical t3.medium instances running the same application
 • Recommendation: Consolidate into an Auto Scaling Group
 • Benefits: Simplified management, automatic scaling, reduced configuration drift

2. Scattered Lambda Functions (Medium Priority)
 • Found 12 Lambda functions with identical runtime and dependencies
 • Recommendation: Combine into a single function with routing logic
 • Benefits: Reduced cold starts, simplified monitoring, easier updates

3. Redundant Security Groups (Low Priority)
 • Found 15 security groups with identical rules
 • Recommendation: Create shared security groups for common patterns
 • Benefits: Easier rule management, reduced complexity

6. Upgrade EKS/Kubernetes clusters

Neo manages Kubernetes version upgrades across multiple clusters, planning upgrade paths and validating compatibility.

Kubernetes upgrades are complex, especially across multiple clusters with different workloads. Neo analyzes your cluster configurations, identifies upgrade blockers, and creates systematic upgrade plans. Ask Neo: “Plan an upgrade path for our EKS clusters from 1.27 to 1.28” and it maps dependencies, checks add-on compatibility, and sequences the upgrades.

7. Respond to security vulnerabilities

When CVEs are announced, Neo can help security teams move at machine speed addressing them.

Security vulnerabilities require immediate response across your entire infrastructure. Neo understands your resource inventory and can quickly identify what’s affected by new CVEs. When you ask Neo: “Identify all resources affected by CVE-2025-XXXXX and create remediation PRs”, it scans your infrastructure, maps vulnerable components, and generates targeted fixes.

8. Remediate policy violations

Neo detects non-compliant resources and generates pull requests to fix them, turning compliance headaches into automated workflows.

When your policy violations detect unencrypted EBS volumes, overly permissive security groups, or missing resource tags, Neo identifies the issues and proposes specific fixes. Ask Neo: “Fix all policy violations in our production account” and it analyzes your compliance dashboard, identifies the problematic resources, and creates PRs with the exact changes needed.

9. Update Lambda runtimes across multiple accounts

Neo identifies outdated Lambda runtimes, stages updates, and manages the rollout across your entire AWS organization.

When AWS announces runtime deprecations, Neo scans all your accounts, identifies functions running outdated versions, and creates a systematic upgrade plan. Ask Neo: “Upgrade all Lambda functions to Python 3.11” and it maps your functions, checks compatibility, and generates account-by-account PRs.

Before (outdated runtime):

// Create the process email Lambda function
const lambdaFunction = new aws.lambda.Function("emailProcessor", {
 runtime: aws.lambda.Runtime.Python3d8, // ❌ Deprecated
 code: new pulumi.asset.AssetArchive({
 ".": new pulumi.asset.FileArchive("./lambda"),
 }),
 // ... other configuration
});

After (Neo’s upgrade):

// Create the process email Lambda function
const lambdaFunction = new aws.lambda.Function("emailProcessor", {
 runtime: aws.lambda.Runtime.Python3d11, // ✅ Upgraded
 code: new pulumi.asset.AssetArchive({
 ".": new pulumi.asset.FileArchive("./lambda"),
 }),
 // ... other configuration
});

10. Enforce multi-account policy compliance

Neo applies organizational policies across your entire AWS Organizations structure, ensuring governance at scale without creating bottlenecks.

Large organizations struggle to maintain consistent policies across dozens of AWS accounts. Neo understands your organizational structure and can enforce tagging standards, encryption requirements, and security policies uniformly. Ask Neo: “Ensure all accounts follow our tagging and encryption policies” and it audits compliance across your organization.

Your newest platform engineer

These workflows represent just the beginning of what’s possible when an AI agent deeply understands infrastructure context.

The outcome is simple: spend less time on operational toil and more time on the architecture and policies that make your organizations successful.

Get started with Neo and discover what becomes possible when AI truly understands infrastructure.

The future of platform engineering isn’t about choosing between speed and safety. It’s about having tools that help you with both simultaneously.

How to Implement Robust Security Guardrails Using Policy as Code

Adam Gordon Bell — Tue, 30 Sep 2025 00:00:00 +0000

Welcome to the third post in our IDP Best Practices series, where we explore how to implement policy as code with Pulumi CrossGuard to create deployment guardrails that make self-service infrastructure both powerful and safe.

Platform engineering presents a fundamental tension: we want to enable developer velocity while maintaining security and compliance. Every platform team faces the same question: how do you give teams the freedom to deploy infrastructure quickly without compromising on safety, security, or organizational standards? The answer isn’t to choose between speed and safety, but rather to embrace automated guardrails powered by policy as code that make both possible simultaneously.

Want hands-on experience? Access the complete demo code and policy examples from this workshop.

The Platform Engineering Challenge: Speed vs. Safety

Let me tell you a story that perfectly captures the platform engineering dilemma. Statsig, a fast-growing feature flag platform processing an incredible 2 trillion events daily, had one infrastructure engineer named Jason who handled all infrastructure requests. Everything worked smoothly until Jason went on parental leave. Suddenly, the entire engineering organization ground to a halt. Infrastructure requests piled up, deployments slowed to a crawl, and the team faced a stark realization: their entire infrastructure capability depended on a single person.

This crisis forced them to confront a fundamental question that every growing engineering team eventually faces: How do you enable self-service infrastructure without sacrificing security, compliance, or operational stability? The answer wasn’t to hire more Jasons or to lock down infrastructure even tighter. Instead, they discovered that deployment guardrails with policy as code could transform their infrastructure conversation from “talk to the infrastructure person” to “ship with confidence, knowing guardrails will catch any issues.”

Think of it like building a system of roads with guardrails. When you create well-designed infrastructure components with proper safety barriers, teams can drive fast and confidently, knowing they’re protected from going off the cliff. The guardrails don’t slow them down; they enable speed by removing fear.

Understanding Platform Engineering Layers

Before we dive into implementing guardrails, we need to understand the architecture of a modern platform and where policies fit within it. Think of your platform as having three distinct layers, each with different security and access requirements.

At the foundation, you have your Layer 1: Foundational Infrastructure, which includes security controls, shared networking, and identity management systems like OIDC and IAM. Platform teams typically manage this layer with strict access controls because it forms the security backbone of your entire infrastructure.

Building on that foundation is Layer 2: Shared Infrastructure, which encompasses VPCs, compute platforms, and load balancers. These are standardized components that teams can use but with some room for customization based on specific needs.

The most dynamic layer is Layer 3: The Workloads Layer, where deployable artifacts, pipelines, and operability tools live. This is where the rubber meets the road, where most self-service activity happens and, consequently, where guardrails become absolutely critical. Developers need maximum freedom at this layer to innovate and ship quickly, but this freedom also introduces the most risk. It’s precisely here that policy-driven guardrails prove their worth, enabling that freedom while automatically preventing dangerous configurations.

What Are Deployment Guardrails?

Deployment guardrails are automated policies that act as your infrastructure’s safety net. Rather than relying on manual reviews or hoping developers remember all the security requirements, guardrails automatically prevent misconfigurations before they reach production. They enforce security standards without human intervention, guide developers toward best practices through immediate feedback, and enable safe self-service by catching issues at the earliest possible moment.

A helpful analogy is to think of guardrails like type checking in programming languages. Just as TypeScript doesn’t restrict your ability to write JavaScript but rather catches type errors before runtime, deployment guardrails don’t limit your infrastructure creativity. They simply ensure you’re following secure patterns and catch potentially dangerous configurations before they cause problems in production.

Introducing Pulumi CrossGuard: Policy as Code

Pulumi CrossGuard is Pulumi’s policy as code framework that brings the same engineering rigor to compliance and security that you apply to your application code. Instead of maintaining policy documents in wikis or relying on manual reviews, you can write policies in familiar programming languages like Python, TypeScript, or Go. These policies then enforce themselves across all your cloud resources and providers, running at different stages of the deployment lifecycle and integrating seamlessly with your CI/CD pipelines for automated enforcement.

Key Policy Types

CrossGuard supports two fundamental types of policies, each serving different validation needs:

Resource Policies: Validate individual resources

def restrict_dangerous_ports(args: ResourceValidationArgs, report_violation: ReportViolation):
 if args.resource_type == "aws:lb/targetGroup:TargetGroup":
 port = args.props.get("port")
 dangerous_ports = ["22", "23", "3389"]
 if str(port) in dangerous_ports:
 report_violation("Dangerous port detected. Avoid using SSH, Telnet, or RDP ports.")

Stack Policies: Validate relationships across resources

def validate_microservice_encryption(args: StackValidationArgs, report_violation: ReportViolation):
 microservice_components = []
 s3_buckets = []

 for resource in args.resources:
 if resource.resource_type == "custom:infrastructure:Microservice":
 microservice_components.append(resource)
 elif resource.resource_type == "aws:s3/bucket:Bucket":
 s3_buckets.append(resource)

 if microservice_components and s3_buckets:
 for bucket in s3_buckets:
 encryption = bucket.props.get("serverSideEncryptionConfiguration")
 if not encryption:
 report_violation("S3 bucket must have encryption enabled when used with microservice components.")

Building Practical Guardrails: Real-World Examples

Let’s walk through building guardrails for a microservice platform, starting with the component from our previous workshop.

Example 1: Port Security Policy

Problem: Developers might accidentally expose services on dangerous ports like SSH (22) or RDP (3389).

Solution: A policy that blocks dangerous port configurations.

import pulumi_policy as policy

def restrict_dangerous_ports_validation(args, report_violation):
 """Prevent services from running on dangerous ports."""
 if args.resource_type == "aws:lb/targetGroup:TargetGroup":
 port = args.props.get("port")
 dangerous_ports = ["22", "23", "3389", "5432", "3306"]

 if str(port) in dangerous_ports:
 report_violation(
 f"Port {port} is not allowed. This port is commonly used for "
 f"administrative services and should not be exposed via load balancer."
 )

restrict_dangerous_ports = policy.ResourceValidationPolicy(
 name="restrict-dangerous-ports",
 description="Prevent services from using dangerous ports",
 validate=restrict_dangerous_ports_validation,
 enforcement_level=policy.EnforcementLevel.MANDATORY
)

Example 2: Resource Limits Policy

Problem: Teams might request oversized resources, leading to cost overruns.

Solution: A policy that enforces reasonable resource limits with advisory warnings.

def limit_memory_validation(args, report_violation):
 """Limit memory allocation for microservices."""
 if args.resource_type == "custom:infrastructure:Microservice":
 # Extract memory from component tags or properties
 memory_str = args.props.get("memory", "512Mi")

 # Parse memory value (assuming format like "2Gi", "1024Mi")
 if memory_str.endswith("Gi"):
 memory_gb = float(memory_str[:-2])
 if memory_gb > 1:
 report_violation(
 f"Memory allocation of {memory_str} exceeds recommended limit of 1Gi "
 f"for microservices. Consider optimizing your application or "
 f"contact the platform team for exceptions."
 )

limit_memory = policy.ResourceValidationPolicy(
 name="limit-microservice-memory",
 description="Enforce reasonable memory limits for microservices",
 validate=limit_memory_validation,
 enforcement_level=policy.EnforcementLevel.ADVISORY
)

Example 3: Cross-Resource Security Policy

Problem: When microservices use S3 buckets, encryption should be mandatory.

Solution: A stack policy that validates encryption across related resources.

def microservice_s3_encryption_validation(args, report_violation):
 """Ensure S3 buckets used with microservices have encryption enabled."""
 microservice_resources = []
 s3_buckets = []

 # Collect relevant resources
 for resource in args.resources:
 if resource.resource_type == "custom:infrastructure:Microservice":
 microservice_resources.append(resource)
 elif resource.resource_type == "aws:s3/bucket:Bucket":
 s3_buckets.append(resource)

 # If we have both microservices and S3 buckets, check encryption
 if microservice_resources and s3_buckets:
 for bucket in s3_buckets:
 sse_config = bucket.props.get("serverSideEncryptionConfiguration")
 if not sse_config:
 report_violation(
 f"S3 bucket '{bucket.name}' must have server-side encryption "
 f"enabled when used with microservice components."
 )

microservice_s3_encryption = policy.StackValidationPolicy(
 name="microservice-s3-encryption",
 description="Ensure S3 buckets used with microservices are encrypted",
 validate=microservice_s3_encryption_validation,
 enforcement_level=policy.EnforcementLevel.MANDATORY
)

Policy Enforcement Models

Pulumi CrossGuard supports multiple enforcement models to fit different workflows, and understanding when to use each model is crucial for effective policy implementation.

The Preventative Model

The most common approach is the preventative model, where policies run before resources are created. This gives you fast feedback and prevents bad deployments from ever reaching the cloud. When you run pulumi preview, policies are evaluated immediately, and if violations are found during pulumi up, the deployment is blocked. This model works particularly well for validating port configurations, resource limits, and other settings that you can check without needing to see the actual deployed resource.

# Policies run automatically during preview and deployment
pulumi preview # Policies evaluated here
pulumi up # Policies block deployment if violations found

The Detective Model

Sometimes you need to validate the actual cloud state, including auto-generated values like ARNs or IP addresses. That’s where the detective model comes in. These policies run after resources are created, making them perfect for compliance scanning and drift detection. While they can’t prevent initial deployment of non-compliant resources, they excel at catching configuration drift and validating properties that only exist after deployment.

CI/CD Integration

The third model integrates policies directly into your deployment pipeline. This ensures consistent enforcement across all teams and creates natural deployment gates. For example, you might configure GitHub Actions to run policy validation on every pull request, blocking merges if violations are found. This approach combines the best of both worlds: early feedback during development and guaranteed enforcement before production.

# GitHub Actions example
- name: Run Policy Validation
 run: |
 pulumi preview --policy-pack ./policies
 if [ $? -ne 0 ]; then
 echo "Policy violations found. Deployment blocked."
 exit 1
 fi

Policy Remediation: Beyond Detection

Modern policy frameworks don’t just detect violations; they can automatically fix them:

def auto_tag_resources(args, report_violation):
 """Automatically add required tags to resources."""
 if args.resource_type == "aws:s3/bucket:Bucket":
 tags = args.props.get("tags", {})

 if "Department" not in tags:
 # Instead of just reporting, fix the issue
 if not hasattr(args, 'tags'):
 args.props["tags"] = {}
 args.props["tags"]["Department"] = "Engineering"
 return args.props # Return modified properties

 return None # No changes needed

auto_tag_policy = policy.ResourceValidationPolicy(
 name="auto-tag-resources",
 description="Automatically add required tags",
 validate=auto_tag_resources,
 enforcement_level=policy.EnforcementLevel.REMEDIATE
)

Server-Side Policy Enforcement

For enterprise deployments, Pulumi provides server-side policy enforcement that ensures policies can’t be bypassed. The process starts by publishing your policies to your Pulumi organization with pulumi policy publish ./my-policies. Once published, you can create policy groups that combine multiple policies with specific enforcement levels, targeting particular stacks or environments while configuring exceptions for special cases. The beauty of this approach is that policies run automatically without requiring CLI flags, providing consistent governance across your entire organization without relying on developers to remember to include policy packs in their commands.

Compliance-Ready Policies

While custom policies address your specific organizational needs, compliance requirements often follow industry standards. Pulumi provides hundreds of pre-built policies for common compliance frameworks:

import { PolicyManager } from "@pulumi/policy";
import { policyManager } from "@pulumi/compliance-ready-policies/policy-manager";

new PolicyPack("aws-compliance-ready-policies-typescript", {
 policies: [
 ...policyManager.selectPolicies({
 vendors: ["aws"],
 services: ["ec2", "s3"],
 severities: ["medium", "high", "critical"],
 topics: ["encryption"],
 frameworks: ["pcidss"],
 }, "mandatory"),
 ],
});

This automatically includes policies for major compliance frameworks like PCI DSS for payment card industry standards, SOC 2 for security and compliance controls, ISO 27001 for information security management, and CIS Benchmarks for security configuration standards.

Add guardrails with policy as code

Write policies in Python or TypeScript, enforce them across every deployment, and give teams self-service infrastructure that stays secure and compliant.

Get started

Best Practices for Policy Implementation

After implementing policies at dozens of organizations, we’ve learned that successful policy adoption follows predictable patterns. The key is to adopt a product mindset: think of your policies as a product serving your development teams, not as bureaucratic rules imposed from above. Start small and iterate based on real feedback rather than trying to implement a comprehensive policy framework from day one.

Start Small and Iterate

Begin with just two or three critical policies that address your most pressing risks. Use advisory enforcement initially, which warns developers about violations but doesn’t block deployments. This gives your team time to understand and adapt to the policies. Only after gathering feedback and refining the policies should you graduate to mandatory enforcement.

Provide Clear, Actionable Error Messages

Nothing frustrates developers more than cryptic policy violations. Your error messages should explain not just what’s wrong, but how to fix it:

def good_error_message(args, report_violation):
 if violation_detected:
 report_violation(
 "S3 bucket encryption is required for compliance. "
 "Add serverSideEncryptionConfiguration to fix this. "
 "See: https://docs.company.com/s3-encryption"
 )

Embrace Progressive Enforcement

Think of enforcement levels as a dial, not a switch. Start with advisory mode to warn about issues, move to mandatory to block deployments, and eventually implement remediation to automatically fix common issues. This progression gives teams time to adapt while gradually raising the security bar.

Test Your Policies Thoroughly

Policies are code, and like any code, they need testing. Write unit tests for your policies to ensure they catch violations correctly and don’t produce false positives:

# Test policies with unit tests
def test_dangerous_port_policy():
 # Mock resource with port 22
 args = create_mock_args("aws:lb/targetGroup:TargetGroup", {"port": 22})
 violations = run_policy(restrict_dangerous_ports, args)
 assert len(violations) == 1
 assert "dangerous port" in violations[0].message.lower()

Document Escape Hatches

No matter how well-designed your policies are, there will always be edge cases. Rather than forcing teams to work around policies in dangerous ways, provide clear, documented escape hatches. Create processes for requesting exceptions, handling emergency exemptions, and appealing for policy changes. As one platform engineer put it, you need “guardrails outside the guardrails” because platform adoption will never be 100%, and that’s okay. This transparency builds trust and ensures policies remain effective enablers rather than bureaucratic obstacles to circumvent.

Real-World Success: Statsig’s Transformation

Remember Statsig’s infrastructure crisis when Jason went on parental leave? Let’s look at how they transformed their platform using the guardrails approach we’ve been discussing. After implementing policy-driven guardrails, their infrastructure story completely changed.

As Tyrone Wong, Infrastructure Engineer at Statsig, explains: “We had a single infra owner. Parental leave forced us to build self-service, and that’s when everything clicked. Developers open a PR, Pulumi previews the change right in the PR, and CI blocks risky changes. That’s how you move fast safely. The magic was turning ’talk to the infra person’ into ‘ship with guardrails.’”

The results speak for themselves. Deployment times dropped from 1.5 weeks to mere minutes. The infrastructure ticket queue that once haunted their Slack channels disappeared entirely. Security actually improved through automated policy enforcement, eliminating the human error factor. Most importantly, developer satisfaction soared as teams gained the autonomy to ship infrastructure changes without friction or fear.

When asked if developers were actually using the self-service platform, Tyrone’s response was telling: “Yeah, people are actually using it because there’s changes they wanted to get done. Previously it became this giant effort with lots of meetings, people being concerned, and Google docs about what the changes would be. Now people can just put together a PR, we have our discussions there, see if anything gets flagged, and move forward.”

Building Your Policy Strategy

Implementing deployment guardrails isn’t a big-bang transformation; it’s a journey that unfolds in phases. Based on patterns we’ve seen across successful implementations, the first week or two should focus on assessment. Start by understanding your current state, auditing existing infrastructure patterns to identify what teams are actually deploying. Look for common misconfigurations that have caused incidents or near-misses, and document your security and compliance requirements as specific, enforceable rules. Most importantly, survey your developers to understand their pain points with the current infrastructure process, as this assessment forms the foundation for policies that solve real problems rather than creating new ones.

In weeks three and four, build your foundation by implementing three to five core policies that address your most critical risks. Set up CI/CD integration so policies run automatically on every pull request, starting with advisory enforcement to gather feedback without blocking deployments. Create clear documentation and runbooks that explain not just what the policies do, but why they exist and how to work with them.

By the second month, you’re ready to expand. Add compliance-specific policies for regulatory requirements and implement server-side enforcement to ensure policies can’t be bypassed. Create formal processes for policy exemptions and exceptions, and begin measuring policy effectiveness through metrics like violation rates and remediation times.

Remember that policy implementation is never “done.” Continuously monitor violation patterns to identify areas where policies might be too strict or too lenient. Refine policies based on developer feedback and incident data, add automated remediation for common violations to reduce manual fixes, and gradually expand coverage to new services and teams using lessons learned from early adopters.

Measuring Policy Success

You can’t improve what you don’t measure, and policy effectiveness is no exception. Successful teams track metrics across three critical dimensions to validate their policy strategy.

From a security perspective, start by monitoring your policy violation rate: the percentage of deployments that trigger policy warnings or blocks. This tells you whether your policies are catching real issues or creating unnecessary friction. Track time to remediation to understand how quickly teams fix violations when they occur. Most importantly, measure the reduction in security incidents caused by misconfigurations. If your policies aren’t reducing incidents, they’re not addressing the right risks.

Security is only half the equation, though. The developer experience dimension is equally important. Monitor deployment velocity to ensure policies aren’t slowing teams down. Regular developer satisfaction surveys reveal whether teams see policies as helpful guardrails or annoying obstacles. Track support ticket volume; successful policy implementation should reduce infrastructure-related requests as teams become more self-sufficient.

Finally, don’t forget to measure the operational health of your policy system itself. Policy coverage shows what percentage of your resources are protected by policies, while the exemption rate reveals whether policies are practical or if teams constantly need exceptions. Track remediation automation to see how many violations are fixed automatically versus requiring manual intervention. Together, these metrics paint a complete picture of your policy program’s health and help you continuously improve your approach.

Common Pitfalls and How to Avoid Them

Even with the best intentions, policy implementations can go wrong. Through years of helping organizations implement policy as code, we’ve identified four critical pitfalls that can derail your efforts.

The first and most common trap is over-engineering policies. It’s tempting to create sophisticated policies that handle every edge case, but overly complex policies are hard to understand and maintain. Teams won’t trust what they don’t understand. Instead, start with simple, clear policies that address specific risks. Use descriptive naming and provide examples of both compliant and non-compliant configurations. Remember, a simple policy that everyone follows is better than a perfect policy that everyone circumvents.

Equally dangerous is falling into “policy theater”: implementing policies because you think you should, not because they address real risks. This creates friction without improving security. Every policy should trace back to an actual incident, security requirement, or compliance need. If you can’t explain why a policy exists with a concrete example, it probably shouldn’t exist.

Poor developer experience is another common failure point. Nothing kills policy adoption faster than cryptic error messages and unclear remediation steps. When a developer hits a policy violation at 5 PM on a Friday, they need clear guidance on how to fix it. Invest heavily in documentation, helpful error messages, and examples. Consider your policies’ error messages as part of your product’s user experience.

Finally, inadequate testing can erode trust quickly. Policies that break legitimate use cases will be worked around or disabled. Before enforcing any policy, test it thoroughly with real scenarios from your production workloads. Run policies in advisory mode first to catch false positives, and have teams attempt real deployments with policies enabled to ensure they don’t block valid configurations.

The Future of Policy as Code

As infrastructure becomes increasingly complex and distributed, policy as code is evolving beyond simple rule enforcement to become an intelligent layer that understands context and intent. Three major trends are shaping this evolution.

First, we’re seeing the emergence of AI-enhanced policies with smart detection systems that use machine learning to identify anomalies that rule-based policies might miss. These systems learn from your infrastructure patterns and can provide contextual recommendations that adapt based on actual usage. Even more exciting is predictive enforcement: imagine policies that can identify risky patterns before they become violations, guiding developers away from problems they haven’t encountered yet.

Second, the multi-cloud reality is driving the need for universal governance. Organizations need policies that work seamlessly across AWS, Azure, and GCP, with federated enforcement that maintains consistency across multiple cloud accounts and regions. Compliance automation is also maturing, with systems that automatically collect evidence for audits and generate compliance reports without manual intervention.

Finally, policy enforcement is moving closer to where developers actually work. IDE integration will soon provide real-time policy feedback as you write infrastructure code, catching issues before you even attempt to deploy. Self-service exemption workflows will let developers request and receive policy exceptions through automated approval processes. Perhaps most intriguingly, we’re seeing the development of learning policies: systems that improve and adapt based on developer feedback and usage patterns, becoming more helpful over time rather than more restrictive.

Conclusion: Enabling Safe Self-Service at Scale

We started this post with a fundamental tension in platform engineering: the need for both speed and safety. Through the lens of Statsig’s transformation and the technical deep-dive into Pulumi CrossGuard, we’ve seen that this isn’t actually a tension that needs resolving. It’s a false dichotomy that policy as code eliminates entirely.

The key insight from successful platform teams like Statsig is that guardrails don’t restrict freedom; they enable it. When developers know that automated policies will catch dangerous configurations, they gain the confidence to move fast and experiment. When platform teams know that policies automatically enforce security and compliance standards, they can focus on building better platforms instead of reviewing every change. This is the magic of policy as code: it transforms infrastructure governance from a bottleneck into an accelerator.

But perhaps the most important lesson is that policy as code isn’t about saying “no” to developers. It’s about intelligent automation that makes the secure path the path of least resistance. It’s about catching mistakes before they become incidents. It’s about encoding your organization’s hard-won knowledge into systems that help every developer benefit from that experience.

As you embark on your own journey to implement deployment guardrails, remember that perfection isn’t the goal; progress is. Start small, iterate based on feedback, and gradually expand your coverage. Your developers will thank you for the clarity and confidence that comes with well-designed guardrails, and your security team will sleep better knowing that policies are enforced automatically and consistently.

The path from manual reviews to automated guardrails is well-traveled and well-documented. Our complete policy examples provide real-world implementations you can adapt to your needs, while the CrossGuard documentation offers deep technical details for advanced use cases. If you’re on AWS, AWSGuard’s pre-built policies offer immediate value, and our compliance-ready policy catalog addresses specific regulatory requirements.

The future of infrastructure management isn’t about choosing between developer autonomy and operational control. It’s about using policy as code to achieve both, creating platforms that are simultaneously powerful and safe, flexible and compliant, fast and secure.

In our next post, we’ll explore Day 2 Platform Operations, diving into how to maintain infrastructure compliance after deployment and automatically remediate configuration drift. Because getting to production is just the beginning; keeping your infrastructure secure and compliant over time is where the real challenge lies.

Get Started with Pulumi

Use Pulumi's open-source SDK to create, deploy, and manage infrastructure on any cloud.

Meet Neo, Your Newest Platform Engineer

Pulumi Neo Team — Tue, 16 Sep 2025 07:00:00 -0600

AI coding assistants have transformed the speed at which developers can write and deploy code. Pull request velocity has increased significantly. Feature delivery has accelerated beyond what we thought possible just two years ago. This should be a victory for everyone in the software organization.

Instead, it’s created significant challenges for infrastructure and platform teams.

Every line of code that ships faster creates new platform needs: monitoring, secrets management, deployment pipelines, and compliance checks. The rapid pace also increases the risk of insecure or non-compliant code reaching production. Developer velocity has increased dramatically, but platform teams haven’t scaled to match.

Platform teams are struggling because they lack the proper tools for their unique challenges. They’re caught in a velocity trap where generic AI accelerates developers while leaving platform teams behind. We’re optimizing software development speed while creating global infrastructure debt.

The very success of developer AI has become a challenge for the platform team.

Introducing Pulumi Neo

Neo is a purpose-built infrastructure automation agent that amplifies your platform engineering capabilities. Built on Pulumi’s platform, Neo has a deep understanding of cloud context, IaC, secrets and configuration, internal developer platforms, and more. It automatically respects your security and policy guardrails and works in tandem with human-in-the-loop approvals and controls.

For years, we’ve worked closely with platform and infrastructure teams. We’ve observed how the demands on these teams have intensified as development velocity has increased. We understand the challenges they face in keeping pace with rapidly evolving infrastructure needs.

The pattern became clear. Generic AI tools excel at generating code but lack the context to understand the unique challenges of infrastructure, including state management, tracking dependencies across services, scaling across tens to hundreds of repositories, and anticipating the effects of changes across an organization.

We’ve heard countless stories from platform engineers about spending hours tracking down dependencies, credential locations, and configuration relationships across their systems. When they try to use generic AI tools for these tasks, the tools often suggest changes without understanding the broader organizational context and dependencies.

That’s when we realized: Platform engineers don’t need faster AI tools. They need their own dedicated AI tool, one that understands infrastructure context, speaks their language, and works within their constraints.

These insights led us to develop Neo, an AI agent specifically designed for platform and infrastructure engineering teams. Unlike generic coding assistants, Neo understands the full context of infrastructure: it knows that changes span multiple repositories, that every modification has downstream effects, and that compliance and security policies matter as much as the code itself.

Built for Enterprise Trust

Neo represents a fundamentally different approach to AI in infrastructure. We view the Pulumi platform’s existing features, like IaC, ESC, and policies, as the foundation for trustworthy AI automation. These aren’t additional guardrails we’ve added; they’re the very platform capabilities you’re already using. Understanding the impact scope through your infrastructure graph gives you confidence to move faster. Knowing compliance implications through your existing policies before making changes is what actually accelerates platform teams.

While other solutions retrofit generic AI models with infrastructure plugins, Neo is built from the ground up on proven enterprise foundations. It operates within your existing Pulumi governance frameworks, respects your policies, and maintains the audit trails and compliance controls your organization requires. Your investment in Pulumi’s platform features—the same ones that govern your infrastructure today—becomes Neo’s operational guardrails.

This isn’t experimental AI, it’s enterprise-ready automation that amplifies your expertise while working within the same platform controls that keep your infrastructure secure and compliant. The Pulumi features you rely on for governance become the accelerants that enable confident, rapid automation.

The Reinforcement Cycle

Neo becomes more capable the more you invest in infrastructure as code. Every Pulumi component you write, every policy you define, every environment configuration you establish becomes Neo’s operational context that guides its decisions.

This is the key shift. We’re talking about AI amplifying platform expertise. The engineers who understand the why behind infrastructure decisions become even more valuable when they have tools that can execute the how at scale.

The teams that lean into this cycle will find themselves accelerating while others are still struggling. They’ll be writing policies while others are responding to issues. They’ll be designing systems while others are updating versions.

The Platform Engineering Evolution

The bigger picture extends far beyond task automation. Platform engineering evolves from reactive to proactive. Teams shift from ticket takers to strategic enablers. Infrastructure becomes self-healing and self-documenting. The profession transforms from responding to urgent issues to crafting foundations.

Imagine infrastructure that evolves as fast as the code it supports. Imagine platform teams that can actually think about next quarter instead of just surviving next sprint. Imagine organizations that can sustain AI-driven development velocity because their infrastructure keeps pace automatically.

For the industry, this means the end of the “platform team bottleneck” narrative. No longer will infrastructure be the reason features don’t ship. No longer will platform engineers be seen as blockers in the velocity story. Instead, they’ll be the enablers who made sustainable speed possible.

This is the rise of strategic platform engineering. These are professionals who shape how organizations build and operate software, who establish the foundations that make everything else possible, and who finally have tools that match the complexity and importance of their work.

The Choice Before Us

What we’re launching is more than an AI agent. We’re introducing your newest platform engineer, who gets smarter as your infrastructure evolves. We’re launching a new era for platform engineering, one where the teams that enable everyone else finally have tools built specifically for their reality.

Neo represents our belief that platform engineers shouldn’t have to choose between speed and safety, between automation and control, between serving developers and driving strategy. These are false choices created by tools that lack an understanding of infrastructure.

The age of generic AI taught us what’s possible. The era of specialized AI shows us what’s practical. Platform teams have been overloaded by everyone else’s velocity long enough.

It’s time for platform engineering to keep pace instead of falling behind.

Neo is available today in public preview. Ready to meet your newest platform engineer? Join thousands of teams already transforming their infrastructure workflows with the Pulumi platform.

The future of platform engineering starts now, and it starts with Neo.

Introducing Automatic API Docs in Private Registry

Pulumi IDP Team — Wed, 27 Aug 2025 00:00:05 -0600

Building and maintaining reusable infrastructure has always been about more than just writing good code. It’s about making that code discoverable, understandable, and easy to adopt across your organization. Today, we’re excited to announce a new feature that removes significant friction from sharing and consuming infrastructure components: automatic multi-language API documentation in Pulumi Private Registry.

Platform teams invest significant effort in creating reusable infrastructure components. But creating the infrastructure is only half the battle. The real challenge comes in making these resources discoverable and usable by development teams across the organization.

Until now, platform teams publishing components faced a discovery challenge. While developers get excellent IDE support with autocomplete once they’re coding, teams first need to know what components exist, understand their capabilities, and evaluate which one fits their needs. Without browsable API documentation in the registry, developers couldn’t easily discover available components or compare versions. Security and compliance teams lacked visibility into what infrastructure patterns were being shared. And platform teams had no central place to showcase their catalog of approved, battle-tested components that encode organizational best practices.

From Code to Comprehensive Docs

Starting today, whenever you publish a component to your Pulumi private registry, whether it’s a brand new component or an updated version, Pulumi automatically generates comprehensive API documentation for all of the component’s resources.

How It Works

When you run pulumi package publish for your component, we analyze your component’s structure, inputs, outputs, and resources to generate rich, interactive API documentation. This documentation is immediately available in your private registry, formatted consistently across all Pulumi-supported languages.

Multi-Language Support Out of the Box

One of Pulumi’s core strengths is our multi-language components: write once in your preferred language, and teams can consume the component in Python, TypeScript, Go, C#, Java, or YAML. The automatic documentation generation embraces this philosophy.

When you publish a component written in Python, developers using TypeScript can view the TypeScript-specific documentation. The same component shows Go developers idiomatic Go code. This language-specific documentation removes the last barrier to cross-team component adoption.

Improving Discoverability and Adoption

With automatic API documentation, your private registry transforms from a simple package repository into a comprehensive catalog. Developers can:

Browse available components and immediately understand their purpose and usage
See all available configuration options with type information
Evaluate what infrastructure each component provisions before choosing to adopt it

This dramatically reduces the time from component discovery to successful deployment, accelerating your organization’s infrastructure velocity.

Getting Started

Automatic API docs are available today for all Pulumi Cloud customers with access to private registry. To start generating docs, simply publish your component. Documentation generation happens automatically with no configuration required, and docs will automatically appear for existing components.

Looking Ahead

Automatic API docs represent our continued investment in making Pulumi the most productive platform for infrastructure teams. By removing friction from the component lifecycle, we’re enabling platform teams to focus on what matters most: building robust, secure, and scalable infrastructure patterns that accelerate their entire organization.

We’re excited to see how teams use them to build more effective internal developer platforms. As always, we’d love to hear your feedback and learn about your use cases on our Pulumi Cloud requests repository.

Ready to streamline your infrastructure development workflow? Get started with Pulumi Cloud or check out our IDP documentation to learn more about building with components and workflows.

Golden Paths in IDPs: A Complete Guide to Reusable Infrastructure with Pulumi Components and Templates

Engin Diri — Wed, 20 Aug 2025 10:00:00 +0200

Welcome to the second post in our IDP Best Practices series. In this article, we explore how to create golden paths, pre-architected, reusable infrastructure patterns that help standardize and accelerate cloud development.

Modern cloud platforms offer endless options, over 200 AWS services, sprawling Azure catalogs, and countless DevOps tools. The result? Developers face decision fatigue and inconsistent implementations. Golden paths solve this by providing ready-to-use, production-grade infrastructure that encodes your organization’s best practices, security policies, and operational standards.

In this guide, you’ll learn how to build golden paths for your Internal Developer Platform using two core Pulumi constructs: Components, reusable infrastructure building blocks, and Templates, predefined, deployable patterns. You’ll see how to create infrastructure abstractions that are written once, shared across teams, and consumed in any language, turning weeks of setup into minutes of developer-ready infrastructure.

The complete code examples from this post are available on GitHub.

The Platform Engineering Layer Cake: A Model for IDPs

To understand where golden paths fit into an Internal Developer Platform (IDP), think in layers. This three-tier model structures your platform to deliver increasing levels of abstraction, reuse, and developer value:

Layer 1: Infrastructure Layer

This is the foundation: raw cloud resources include VMs, databases, networks, and storage, which are the fundamental building blocks from AWS, Azure, GCP, and other providers. Pulumi gives you programmatic access to these resources through native providers, but working at this level requires deep infrastructure knowledge.

Layer 2: Platform Layer - Components

This is where the magic happens. Pulumi Components take those raw resources and package them into higher-level abstractions. Instead of manually configuring 20+ AWS resources for a secure web application, you create a component that handles all that complexity and exposes just the configuration that matters:

const app = new SecureWebApplication("my-app", {
 instanceType: "t3.medium",
 minReplicas: 2,
 maxReplicas: 10,
 enableWAF: true,
 environment: "production"
});

Part 1: Building Reusable Infrastructure Components

Reusable infrastructure components act as the foundation of your platform. They encapsulate complexity while remaining composable and scalable. Let’s build a real-world example: a component that deploys containerized microservices to AWS Fargate.

The Power of Multi-Language Components

Here’s what makes Pulumi components revolutionary: write once, consume anywhere. Your platform team can author components in TypeScript, but application teams can consume them in Python, Go, .NET, Java, or even YAML. This separation of concerns is crucial for scaling platform engineering across diverse teams.

Building a Microservice Component Step-by-Step

Let’s create a component that encapsulates everything needed to deploy a production-ready microservice:

// microservice-component.ts
import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";
import * as awsx from "@pulumi/awsx";

export interface MicroserviceArgs {
 appPath: string; // Path to application code
 cpu?: number; // CPU units (256, 512, 1024, etc.)
 memory?: number; // Memory in MB
 port?: number; // Application port
 desiredCount?: number; // Number of tasks
}

export class MicroserviceComponent extends pulumi.ComponentResource {
 public readonly url: pulumi.Output<string>;
 public readonly serviceName: pulumi.Output<string>;
 public readonly clusterName: pulumi.Output<string>;

 constructor(name: string, args: MicroserviceArgs, opts?: pulumi.ComponentResourceOptions) {
 super("custom:infrastructure:Microservice", name, {}, opts);

 // Set defaults
 const cpu = args.cpu || 256;
 const memory = args.memory || 512;
 const port = args.port || 8080;
 const desiredCount = args.desiredCount || 2;

 // Create ECR repository for Docker images
 const repository = new awsx.ecr.Repository(`${name}-repo`, {
 forceDelete: true
 }, { parent: this });

 // Build and push Docker image
 const image = new awsx.ecr.Image(`${name}-image`, {
 repositoryUrl: repository.url,
 context: args.appPath,
 platform: "linux/amd64",
 }, { parent: this });

 // Create Application Load Balancer
 const loadBalancer = new awsx.lb.ApplicationLoadBalancer(`${name}-lb`, {
 defaultTargetGroup: {
 port: port,
 protocol: "HTTP",
 healthCheck: {
 path: "/health",
 interval: 30,
 timeout: 5,
 healthyThreshold: 2,
 unhealthyThreshold: 3,
 }
 }
 }, { parent: this });

 // Create ECS cluster
 const cluster = new aws.ecs.Cluster(`${name}-cluster`, {}, { parent: this });

 // Create Fargate service
 const service = new awsx.ecs.FargateService(`${name}-service`, {
 cluster: cluster.arn,
 taskDefinitionArgs: {
 container: {
 name: name,
 image: image.imageUri,
 cpu: cpu,
 memory: memory,
 essential: true,
 portMappings: [{
 containerPort: port,
 targetGroup: loadBalancer.defaultTargetGroup,
 }],
 },
 },
 desiredCount: desiredCount,
 assignPublicIp: true,
 }, { parent: this });

 // Export outputs
 this.url = pulumi.interpolate`http://${loadBalancer.loadBalancer.dnsName}`;
 this.serviceName = service.service.name;
 this.clusterName = cluster.name;

 // Register outputs
 this.registerOutputs({
 url: this.url,
 serviceName: this.serviceName,
 clusterName: this.clusterName,
 });
 }
}

Documenting for Discoverability and Adoption

To make your component easy to use, add comprehensive documentation and examples to a README.md file:

# MicroserviceComponent

Abstraction for resources needed when using AWS container services.

A component to abstract the details related to:
- Creating a docker image and pushing it to AWS ECR.
- Deploy to ECS Fargate using the docker image.

# Inputs

* appPath: Path to local folder containing the app and Dockerfile.
* port: Port to expose via an ALB.
* cpu (Optional): CPU capacity. Defaults to 256 (i.e. 0.25 vCPU).
* memory (Optional): Memory capacity. Defaults to 512 (i.e. 0.5GB).
* containerName (Optional): Name of the container. Defaults to "my-app".

# Outputs

* publicUrl: The DNS name for the loadbalancer fronting the app.

# Usage
## Specify Package in `Pulumi.yaml`

Add the following to your `Pulumi.yaml` file:
Note: If no version is specified, the latest version will be used.

... omit for brevity ...

This documentation will help developers understand how to use your component effectively, including required inputs, outputs, and example usage.

Publishing Your Component via Private Registry

Once your component is ready, publish it to your Pulumi Private Registry:

# Tag your component version
git tag v1.0.1

# Publish to your organization's registry
pulumi package publish https://registry.pulumi.com/myorg/microservice-component

Now any team in your organization can discover and use your component, regardless of their language preference. All they need is to navigate to the Components section in the Pulumi IDP and search for microservice-component.

Part 2: From Building Blocks to Golden Paths

While components are powerful, they’re just the starting point. Golden path templates layer on opinionated scaffolding, workflows, and compliance best practices that guide developers to production.

Golden Path Maturity: From Zero to Product-Grade Platforms

Teams evolve from ad hoc deployments to mature, productized templates with versioning, metrics, and governance. These maturity levels reflect how deeply your platform enables safe, consistent delivery.

Organizations typically progress through three stages of golden path maturity:

Stage 1: No Golden Paths

Every team reinvents the wheel
Inconsistent practices across projects
High cognitive load on developers
Security and compliance gaps

Stage 2: Dawn of Templates

Basic cookie-cutter templates emerge
Some standardization begins
Manual processes still dominate
Limited support and evolution

Stage 3: Templates as Products

Golden paths have dedicated owners
Regular release cycles and versioning
Migration guides for updates
Metrics track adoption and success
Continuous improvement based on feedback

What Makes a Golden Path Golden?

Drawing from Spotify’s pioneering work, golden paths share these characteristics:

Pre-architected and Supported: The platform team owns and supports the path
Optional but Recommended: Developers can deviate, but staying on the path ensures support
Transparent Abstractions: The implementation is visible, not a black box
Extensible: Teams can add project-specific resources without breaking the pattern
Evolutionary: Templates improve based on feedback and new requirements

Building a Go Microservice Golden Path

Let’s create a complete golden path for Go microservices that includes:

Application scaffolding with best practices
Infrastructure deployment using our component
CI/CD pipeline configuration
Observability setup
Security controls

Step 1: Template Structure

go-microservice-boilerplate/
├── Pulumi.yaml # Infrastructure definition
├── src/ # Application code
│ ├── main.go # Go microservice
│ ├── Dockerfile # Container definition
│ └── go.mod # Dependencies
└── README.md # Documentation

Step 2: Application Scaffolding

The src/main.go file contains a minimal Go microservice with all the best practices and compliance guardrails baked in. This helps developers to quickly get started and extend the application without worrying too much about selecting the right libraries or frameworks.

// source/main.go
package main

import (
 "context"
 "flag"
 "net/http"
 "os"
 "os/signal"
 "time"

 "github.com/labstack/echo/v4"
 "github.com/labstack/echo/v4/middleware"
 "go.opentelemetry.io/contrib/instrumentation/github.com/labstack/echo/otelecho"
 "go.opentelemetry.io/otel"
 "go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp"
 "go.opentelemetry.io/otel/sdk/resource"
 sdktrace "go.opentelemetry.io/otel/sdk/trace"
 semconv "go.opentelemetry.io/otel/semconv/v1.34.0"
)

func initTracer() (*sdktrace.TracerProvider, error) {
 exporter, err := otlptracehttp.New(context.Background())
 if err != nil {
 return nil, err
 }

 resource, err := resource.Merge(
 resource.Default(),
 resource.NewWithAttributes(
 semconv.SchemaURL,
 semconv.ServiceNameKey.String("${PROJECT}"),
 semconv.ServiceVersionKey.String("1.0.0"),
 ),
 )
 if err != nil {
 return nil, err
 }

 tp := sdktrace.NewTracerProvider(
 sdktrace.WithBatcher(exporter),
 sdktrace.WithResource(resource),
 sdktrace.WithSampler(sdktrace.AlwaysSample()),
 )

 otel.SetTracerProvider(tp)
 return tp, nil
}

func echoHandler(c echo.Context) error {
 message := c.QueryParam("message")
 if message == "" {
 message = "Hello from Go microservice!"
 }

 return c.JSON(http.StatusOK, map[string]string{
 "echo": message,
 "service": "${PROJECT}",
 "timestamp": time.Now().UTC().Format(time.RFC3339),
 })
}

func healthHandler(c echo.Context) error {
 return c.JSON(http.StatusOK, map[string]string{
 "status": "healthy",
 "service": "${PROJECT}",
 })
}

func main() {
 healthCheck := flag.Bool("health-check", false, "Run health check and exit")
 flag.Parse()

 if *healthCheck {
 resp, err := http.Get("http://localhost:8080/health")
 if err != nil || resp.StatusCode != http.StatusOK {
 os.Exit(1)
 }
 os.Exit(0)
 }

 tp, err := initTracer()
 if err != nil {
 panic(err)
 }
 defer func() {
 if err := tp.Shutdown(context.Background()); err != nil {
 panic(err)
 }
 }()

 e := echo.New()

 e.Use(middleware.Logger())
 e.Use(middleware.Recover())
 e.Use(middleware.CORS())
 e.Use(otelecho.Middleware("${PROJECT}"))

 e.GET("/echo", echoHandler)
 e.GET("/health", healthHandler)

 go func() {
 if err := e.Start(":8080"); err != nil && err != http.ErrServerClosed {
 e.Logger.Fatal("shutting down the server")
 }
 }()

 quit := make(chan os.Signal, 1)
 signal.Notify(quit, os.Interrupt)
 <-quit
 ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
 defer cancel()
 if err := e.Shutdown(ctx); err != nil {
 e.Logger.Fatal(err)
 }
}

Step 3: Infrastructure Template with YAML

Here’s how you define the infrastructure using Pulumi YAML. You can instantly spot one of the features of Pulumi Components. We consume the micorservice-component in YAML without knowing that it was authored in a different language. This is the power of Pulumi Components: write once, consume anywhere.

And we see another feature of Pulumi Components: As it is a first-class citizen, we can embed the component and add additional resources like auto-scaling policies, alarms, and more directly in the YAML file. This allows us to create a complete golden path for deploying Go microservices on AWS ECS with auto-scaling capabilities.

# Pulumi.yaml
name: ${PROJECT}
description: ${DESCRIPTION}
runtime: yaml
packages:
 component-microservice: https://github.com/smithrobs/component-microservice@v1.0.1
template:
 description: A template for deploying a Go microservice on AWS ECS with auto-scaling capabilities.
resources:
 microserviceComponent:
 type: component-microservice:MicroserviceComponent
 properties:
 appPath: ./src
 port: 8080
 containerName: ${PROJECT}
 ecsTarget:
 type: aws:appautoscaling:Target
 name: ecs_target
 properties:
 maxCapacity: 4
 minCapacity: 1
 resourceId: service/${microserviceComponent.clusterName}/${microserviceComponent.serviceName}
 scalableDimension: ecs:service:DesiredCount
 serviceNamespace: ecs
 ecsPolicyUP:
 type: aws:appautoscaling:Policy
 name: ecs_policy_up
 properties:
 name: ecs_policy_up
 policyType: StepScaling
 resourceId: ${ecsTarget.resourceId}
 scalableDimension: ${ecsTarget.scalableDimension}
 serviceNamespace: ${ecsTarget.serviceNamespace}
 stepScalingPolicyConfiguration:
 adjustmentType: ChangeInCapacity
 cooldown: 60
 metricAggregationType: Maximum
 stepAdjustments:
 - metricIntervalUpperBound: 0
 scalingAdjustment: 1
 ecsPolicyDown:
 type: aws:appautoscaling:Policy
 name: ecs_policy_down
 properties:
 name: ecs_policy_down
 policyType: StepScaling
 resourceId: ${ecsTarget.resourceId}
 scalableDimension: ${ecsTarget.scalableDimension}
 serviceNamespace: ${ecsTarget.serviceNamespace}
 stepScalingPolicyConfiguration:
 adjustmentType: ChangeInCapacity
 cooldown: 60
 metricAggregationType: Maximum
 stepAdjustments:
 - metricIntervalLowerBound: 0
 scalingAdjustment: -1
 serviceCPUHighUtilization:
 type: aws:cloudwatch:MetricAlarm
 name: service_cpu_high_utilization
 properties:
 name: service_cpu_high_utilization
 comparisonOperator: GreaterThanOrEqualToThreshold
 evaluationPeriods: 2
 metricName: CPUUtilization
 namespace: AWS/ECS
 period: 60
 statistic: Average
 threshold: 80
 alarmActions:
 - ${ecsPolicyUP.arn}
 dimensions:
 ClusterName: ${microserviceComponent.clusterName}
 ServiceName: ${microserviceComponent.serviceName}
 serviceCPULowUtilization:
 type: aws:cloudwatch:MetricAlarm
 name: service_cpu_low_utilization
 properties:
 name: service_cpu_low_utilization
 comparisonOperator: LessThanOrEqualToThreshold
 evaluationPeriods: 2
 metricName: CPUUtilization
 namespace: AWS/ECS
 period: 60
 statistic: Average
 threshold: 10
 alarmActions:
 - ${ecsPolicyDown.arn}
 dimensions:
 ClusterName: ${microserviceComponent.clusterName}
 ServiceName: ${microserviceComponent.serviceName}

outputs:
 publicUrl: ${microserviceComponent.publicUrl}

Step 4: Documentation and Examples

Add a README.md file to your template directory to provide clear instructions on how to use the template, including prerequisites, configuration options, and example commands:

# Go Microservice Golden Path

A **golden path** template that gets your Go microservice from code to production on AWS in minutes, not weeks.

## What You Get

This golden path provides everything your development team needs to deploy production-ready Go microservices:

✅ **Production-ready Go microservice** with Echo framework and OpenTelemetry tracing
✅ **AWS infrastructure that scales** - ECS with auto-scaling from 1-4 instances
✅ **Security by default** - Hardened containers, IAM roles, security groups
✅ **Monitoring built-in** - Health checks, load balancer monitoring, CloudWatch alarms
✅ **One-command deployment** - `pulumi up` handles everything
✅ **No AWS expertise required** - Complex ECS setup abstracted away

## For Development Teams: What to Expect

### Your Experience

**Day 1: Getting Started**

- Clone this repo, run `pulumi up`
- Your service is live on AWS in 5-10 minutes
- Public URL provided automatically - no manual setup needed

**Day 2-N: Development Workflow**

- Write your Go code in `microservice/main.go`
- Test locally with `go run main.go`
- Deploy changes with `pulumi up`
- AWS automatically rebuilds and redeploys your container

**Production Operations**

- Service automatically scales with CPU load (80% up, 10% down)
- Health checks ensure unhealthy containers are replaced
- Load balancer distributes traffic across healthy instances
- Distributed tracing helps debug issues across services

### What's Handled For You

You **don't** need to learn or configure:

- ECS clusters, services, and task definitions
- Application Load Balancers and target groups
- Auto-scaling policies and CloudWatch alarms
- Security groups and IAM roles
- Container registries and image building
- Health check configuration

You **do** focus on:

- Writing your Go application logic
- Adding your business endpoints
- Testing your service locally
- Deploying with confidence

Making Templates Available in Pulumi IDP

Publishing your template to Pulumi IDP enables true self-service. Head to Settings → Integrations → Organization Template Sources and add your template repository.

Once published, developers can discover and deploy it directly from the IDP interface.

Now developers can deploy through multiple interfaces:

CLI Deployment:

pulumi new https://github.com/myorg/go-microservice-boilerplate

No-Code Deployment: Navigate to Pulumi IDP → Templates → Deploy with Pulumi → Configure and launch

Pulumi Deployment: Navigate to Pulumi IDP → Templates → Deploy with Pulumi → Configure and launch

Build golden paths with Pulumi

Package your infrastructure patterns into reusable components and templates, publish them to a private registry, and let teams deploy production-ready stacks in minutes.

Get started

Best Practices for Reusable Infrastructure Components and Templates

Well-designed components and templates are the foundation of scalable, self-service infrastructure. These best practices ensure your abstractions are maintainable, discoverable, and production-ready.

1. Design for Day 2 Operations from Day 1

Think beyond deployment. A golden path must also support ongoing operations:

How will teams safely update their infrastructure?
What happens during scaling events?
How do you handle disaster recovery?
What metrics and logs are needed for troubleshooting?

2. Expose Complexity Progressively

Provide sensible defaults that work, while enabling customization for advanced use cases:

interface ComponentArgs {
 // Required - what users must provide
 appName: string;

 // Common customizations with good defaults
 instanceType?: string; // default: "t3.micro"
 replicas?: number; // default: 2

 // Advanced options for power users
 networkConfig?: NetworkConfig;
 securityPolicies?: SecurityPolicy[];
 customMetrics?: MetricDefinition[];
}

4. Use Semantic Versioning Everywhere

Clear versioning for both components and templates indicate stability and reliability:

Major versions (1.0.0 → 2.0.0): Breaking changes
Minor versions (1.0.0 → 1.1.0): New features, backward compatible
Patch versions (1.0.0 → 1.0.1): Bug fixes

This lets teams adopt updates with confidence and control.

5. Test Your Abstractions

Don’t ship black boxes. Create automated tests to validate key functionality and resource creation. Focus on:

Smoke tests that validate resource existence
Output validation to ensure correctness
Integration tests to confirm end-to-end behavior

import { expect } from "chai";
import * as pulumi from "@pulumi/pulumi";

describe("MicroserviceComponent", () => {
 it("should create required resources", async () => {
 const component = new MicroserviceComponent("test", {
 appPath: "./test-app",
 port: 3000
 });

 const resources = await pulumi.runtime.allResources();
 expect(resources).to.include("aws:ecs/cluster:Cluster");
 expect(resources).to.include("aws:ecs/service:Service");
 expect(resources).to.include("aws:lb/loadBalancer:LoadBalancer");
 });
});

How to Measure Golden Path Success

Golden paths aren’t complete until they deliver measurable value. Use these KPIs to assess performance and drive iteration:

Adoption Metrics

Template usage rate: Percentage of new projects using golden paths
Component reuse: Number of stacks consuming shared components
Time to first deployment: Deployment time and frequency from code to production

Quality Metrics

Security compliance rate: Percentage of deployments passing security policies
Stability: Deployment incident frequency
Mean time to recovery (MTTR): Time to recover from production issues

Developer Experience Metrics

Developer satisfaction: Survey teams about their platform experience
Support ticket volume: Ticket volume related to infrastructure
Contribution: Number of PRs or issues submitted to platform templates

Real-World Results: Success Stories

Organizations using golden paths report significant improvements in speed and reliability:

Snowflake reduced deployment time from 1.5 weeks to less than a day
Mercedes-Benz decreased infrastructure provisioning from weeks to minutes
Starburst Data cut deployment time from 2 weeks to 3 hours

These results show that golden paths are not just developer tools, they’re a competitive advantage. To learn more, download the whitepaper: The Golden Path to Cloud Success: Your IDP Roadmap.

Common Pitfalls and How to Avoid Them

Pitfall 1: Over-Abstraction

Problem: Creating components so abstract they’re unusable Solution: Start with concrete use cases, then generalize based on actual patterns

Pitfall 2: Insufficient Escape Hatches

Problem: Golden paths become golden cages Solution: Always provide ways to extend or override default behavior

Pitfall 3: Poor Versioning Strategy

Problem: Breaking changes without migration paths Solution: Maintain backward compatibility and provide clear upgrade guides

Pitfall 4: Lack of Ownership

Problem: Templates become orphaned and outdated Solution: Assign clear ownership and establish maintenance schedules

The Future of Golden Paths: AI and Beyond

The future of golden paths is intelligent, cross-cloud, and fully integrated with modern workflows.

AI-Enhanced Templates

Imagine templates that adapt based on your application’s actual behavior, automatically tuning resources and configurations for optimal performance and cost.

Cross-Cloud Portability

Components that abstract not just resources but entire cloud providers, enabling true multi-cloud golden paths.

GitOps-Native Workflows

Templates that include not just infrastructure but complete GitOps pipelines, from code commit to production deployment.

Your First Steps to Golden Paths

Ready to get started? Here’s your action plan:

Audit Current Patterns: Document the infrastructure patterns your teams use most frequently
Build one reusable component: Pick your most common pattern and build a reusable component
Create Your First Template: Build a complete golden path for one project type
Gather Feedback: Deploy with a pilot team and iterate based on their experience
Scale Gradually: Expand your component library and template catalog based on demand
Measure and Iterate: Track adoption and continuously improve based on metrics

Conclusion: From Fragmentation to Flow

Golden paths aren’t about restricting creativity or enforcing rigid standards. They’re about removing friction from the development process, encoding expertise into reusable patterns, and empowering developers to move at the speed of business.

By building a library of components and templates, you transform your Internal Developer Platform from a collection of tools into a force multiplier for your entire engineering organization. You give developers the gift of not having to solve solved problems, while maintaining the flexibility to innovate where it matters.

Start small. Solve one problem well. Expand from there. With the right foundation, your developer platform will evolve into a system of self-service, speed, and stability.

Ready to Build Your Golden Paths?

Code examples: Explore golden path examples on GitHub
Build with Components: Pulumi Components documentation
Enable Self-Service: Pulumi IDP documentation
Join the Community: Connect with platform engineers in our Pulumi Slack

Next in our series: Policy as Code for Safer IDPs. You will learn how to add automated guardrails that make sure every deployment meets your security and compliance standards without slowing down development.

How to Build an Internal Developer Platform: Strategy, Best Practices, and Self-Service Infrastructure

Mitch Gerdisch — Thu, 14 Aug 2025 05:13:02 +0200

Welcome to the first post in our IDP Best Practices series. In this guide, we’ll walk through the strategic foundations for designing an Internal Developer Platform that empowers developers without sacrificing governance, security, or operational control.

At Pulumi, we’ve worked with hundreds of teams facing the same core challenge: How do you give developers the infrastructure access they need, while maintaining the governance and security your organization requires?

That tension is at the heart of every IDP conversation. Teams want to move faster and innovate, but also need to stay compliant, control costs, and maintain operational stability.

The good news? You can do both, with a clear strategy and the right approach. This series shares proven best practices for designing, building, and scaling IDPs using Pulumi.

These lessons come from real-world implementations across industries and company sizes—and are built to grow with you.

Understanding the Platform Engineering Layers in Your Internal Developer Platform

When we work with customers on their platform strategy, we often start by referring to the “platform engineering layer cake.” Here is a quick walkthrough of each layer and how Pulumi IDP constructs fit this layer cake approach:

Layer 1: Infrastructure Layer - This is your raw cloud resources: VMs, databases, networks, storage. These are the fundamental building blocks that exist in AWS, Azure, GCP, and other cloud providers.

Layer 2: Platform Layer - This is where Pulumi Components live. Components take those raw infrastructure resources and package them into higher-level abstractions that encapsulate best practices, security policies, and organizational standards. For example, instead of manually configuring 15 different AWS resources to create a secure web application, you create a component that handles all that complexity and exposes just the configuration options that matter to your developers.

Layer 3: Developer Experience Layer - This is where Pulumi Templates and the Private Registry come into play. Templates provide ready-to-deploy patterns that developers can customize, while the private registry makes everything discoverable and manageable at scale.

In our workshop, we focused specifically on those top two layers because that’s where the transformation happens. This is where you turn raw infrastructure into something developers can actually use productively without becoming infrastructure experts themselves.

Here’s how this maps to what you’re actually building:

Infrastructure Layer → Raw Cloud Resources

Your foundation is still the same: AWS EC2 instances, Azure Virtual Networks, GCP Cloud Functions. Pulumi’s providers give you access to these resources using real programming languages instead of YAML or proprietary DSLs.

Platform Layer → Pulumi Components

This is where you create your reusable building blocks. A component might encapsulate:

A complete microservice infrastructure pattern (load balancer, auto-scaling group, database, monitoring)
A secure data pipeline (storage, processing, access controls, encryption)
A standardized Kubernetes application deployment (ingress, service, deployment, secrets management)

Components are written once in any supported language (TypeScript, Python, Go, .NET, Java) but can be consumed by teams using any of these languages. This is crucial. Your platform team might write components in Go, but your application teams can consume them in Python or TypeScript.

Developer Experience Layer → Templates + Private Registry

Templates are complete, deployable projects that use your components. They provide:

Getting started patterns: “Deploy a new microservice”
Reference architectures: “Deploy a three-tier web application”
Environment patterns: “Set up a complete dev/staging/prod pipeline”

The Private Registry is your distribution mechanism. It’s where components and templates become discoverable, versioned, and manageable. Developers don’t need to hunt through Git repositories or Slack channels to find the right building blocks. Everything is catalogued, documented, and accessible through familiar package management workflows.

IDP Example: Building a Web Application Platform Step-by-Step

Let’s make this concrete with an example from our workshops. Say you want to enable teams to deploy secure web applications:

Infrastructure Layer: You need an Application Load Balancer, EC2 Auto Scaling Group, RDS database, VPC with proper subnets, Security Groups, IAM roles, CloudWatch monitoring, and S3 bucket for static assets. That’s about 20+ individual AWS resources that need to be configured correctly and securely.

Platform Layer (Components): You create a WebApplication component that encapsulates all this complexity. Your component exposes simple configuration options like:

const app = new WebApplication("my-app", {
 instanceType: "t3.medium",
 minSize: 2,
 maxSize: 10,
 databaseSize: "small",
 environment: "production"
});

Behind the scenes, your component handles all the security configurations, networking setup, monitoring, and best practices. You publish this component to your private registry.

Developer Experience Layer (Templates): You create templates like:

web-app-starter: A simple web application using your WebApplication component
microservice-template: API service with database and monitoring
full-stack-template: Frontend, backend, and database in a complete environment

Developers can now run pulumi new web-app-starter and get a production-ready, secure web application in minutes instead of weeks. The template uses your component, which handles all the underlying infrastructure complexity.

This layered approach solves the core challenge we see every platform team struggling with: how do you provide developers with the infrastructure they need without creating operational bottlenecks or compromising security standards.

Why Internal Developer Platforms Matter in 2025 and Beyond

While DevOps brought us incredible advances in how we ship and maintain software, we’ve watched many organizations struggle with the unintended consequences: tool sprawl, Day 2 operational pain, and developers who are drowning in infrastructure complexity.

That’s why platform teams have emerged. You exist to solve these challenges by building tools and workflows that enable your internal customers (the developers) to provision infrastructure and deploy software without getting blocked. But here’s the thing I’ve learned from working with hundreds of platform teams: success isn’t just about the tools you choose. It’s about the strategy behind how you implement them.

5 Core Components of a Successful Internal Developer Platform

Through years of working with platform teams and analyzing what separates successful IDPs from those that struggle to gain adoption, we’ve identified five essential components that every platform strategy needs. These aren’t theoretical concepts. They’re battle-tested patterns that work across organizations of all sizes and industries.

1. Abstractions

Let me be clear about something: abstractions aren’t about dumbing down infrastructure for developers. The abstraction is really where you’re hiding the complexity of the underlying infrastructure from your end users, but you’re doing it intentionally to provide appropriate interfaces for different personas in your organization.

We’ve seen too many platform teams get this wrong by either over-abstracting (creating black boxes that developers can’t customize) or under-abstracting (exposing too much complexity). The sweet spot is creating component resources that encapsulate your infrastructure patterns and best practices into reusable building blocks that can be consumed across different programming languages and deployment scenarios, while still providing escape hatches when needed.

2. Blueprints

Blueprints are your templatized, well-architected patterns that developers can use to bootstrap their infrastructure. But here’s what I want you to understand about blueprints: they’re not just starting points that you throw over the wall to developers. They’re carefully designed patterns that embody your organizational best practices and architectural decisions.

When we see successful platform teams, their templates serve as both accelerators and guardrails. They give developers a fast path to production-ready infrastructure while ensuring that everything they deploy follows your organization’s standards. That’s the power of good blueprint design: speed and compliance working together, not against each other.

3. Workflows

Here’s where many platform teams get trapped: they try to build one workflow to rule them all. But in our experience working with organizations across every industry, you need to support multiple consumption patterns because you have multiple types of users. You need:

No-code workflows for users who want point-and-click deployment (think product managers or junior developers who just need to spin up a database)
Low-code workflows using tools like Pulumi YAML for configuration-driven infrastructure (perfect for developers who understand infrastructure but don’t want to write Go or TypeScript)
Full-code workflows for developers who need maximum flexibility and want to leverage the full power of general-purpose programming languages

The key insight? These aren’t three different platforms. They’re three different interfaces to the same underlying components and templates.

4. Security guardrails

This is probably the most important distinction we can share with you: you want to have guardrails, not gates. Too many platform teams create approval processes and manual checkpoints that completely undermine the self-service promise they’re trying to deliver.

Guardrails are different. They start with the best practices and security built into the reusable abstractions. But even the most secure solutions need a safety net. This safety net is policy-as-code that runs automatically, preventing violations before deployment happens. When we work with customers on implementing Pulumi CrossGuard, we’re not creating new friction. We’re embedding security, compliance, and cost controls directly into the deployment process. The developer gets immediate feedback, and you get the assurance that nothing goes to production without meeting your standards.

5. Self-service

Everything we’ve talked about so far builds toward this moment: enabling developers to provision and manage infrastructure independently. But self-service isn’t just about providing a UI. It’s about carefully orchestrating all the other components to create experiences that are both powerful and intuitive.

When we walked through the demo in our workshop, what you saw was the culmination of thoughtful platform design. Developers can discover available services, deploy infrastructure through whatever interface makes sense for them, and manage their resources over time, all without requiring tickets or manual intervention from platform teams. That’s the promise of a well-designed IDP: developer autonomy without operational chaos.

Put your IDP strategy into practice

Build reusable components, golden paths, and self-service workflows on Pulumi, and give developers autonomy while you keep governance and costs in check.

Get started

How to Implement Your IDP Strategy

Supporting Different Personas in Your Internal Developer Platform Design

One of the biggest mistakes we see platform teams make: they try to build for their most sophisticated users first. But here’s what I’ve learned from working with hundreds of organizations: you need to think about all your personas from day one.

In most organizations, you’re serving:

Infrastructure engineers who want full control and flexibility (they’ll use the full-code workflows)
Application developers who need infrastructure but prefer higher-level abstractions (perfect for low-code approaches)
Non-technical users who want simple, point-and-click deployment (your no-code users)

The breakthrough insight that separates successful platform teams from struggling ones is this: all these personas can be served by the same underlying components and templates, just consumed through different interfaces. You don’t need to build three different platforms—you need to build one platform with three different consumption models.

Why a Private Registry Is Key to IDP Adoption

Here’s something we always tell platform teams: if you don’t solve the discoverability problem, your beautiful components and templates will sit unused in Git repositories where no one can find them. That’s why the private registry isn’t just a nice-to-have. It’s the foundation that makes everything else work.

When you establish a private registry as your source of truth for components, templates, providers, and policies, you’re solving two critical problems at once. First, discoverability: developers can actually find and explore what’s available. Second, lifecycle management: you can see where each package is being used, track version drift, and understand the impact of changes before you make them.

The workflow is beautifully simple: you publish standardized building blocks with a single pulumi publish command, and developers discover and consume these assets through familiar package management workflows they already know.

Aligning Your IDP to Organizational Context and Services

One pattern we see in every successful IDP implementation is that the platform reflects how the organization actually works. Your developers don’t think in terms of individual stacks or resources. They think in terms of services, applications, and business functionality.

That’s why we built Pulumi Services - to let teams logically group stacks and ESC environments in ways that make sense to your organization. Pulumi Services improve organization by helping your team model infrastructure in a way that’s familiar - simplifying Day 2 operations by providing additional context like links to relevant dashboards, Slack channels and more. When something breaks at 2 AM, your on-call engineer needs to understand dependencies, track usage, and manage infrastructure in the context of the business services that are actually impacted.

How to Measure the Success of Your Internal Developer Platform

Here’s something that might surprise you: the most successful platform teams we work with don’t measure their success by how many cool features they’ve built. They measure success by the business outcomes they’re driving:

Reduced time-to-market through faster infrastructure provisioning (because at the end of the day, your platform exists to help the business move faster)
Improved developer productivity by eliminating infrastructure bottlenecks (happy developers ship more features)
Enhanced security posture through consistent policy enforcement (security that doesn’t slow people down is security that actually gets used)
Lower operational overhead through standardization and automation (because your platform team’s time is better spent on innovation than toil)

The numbers speak for themselves. We’ve worked with customers like Snowflake who reduced deployment times from one and a half weeks to less than a day. Starburst Data cut their infrastructure deployments from two weeks to just three hours. These aren’t vanity metrics. They’re business transformations.

IDP Strategy: 5 Key Steps to Build a Strong Foundation

If you’re just starting your IDP journey, here’s the roadmap we give to every platform team we work with:

Start with user research: Before you write a single line of code, go talk to your developers. Understand your different personas and their actual needs, not what you think they need. Do your users like to work from the command line? Do they prefer interacting with a UI?
Identify common patterns: Look for infrastructure patterns that get repeated across teams. These are your goldmine—the patterns that, once abstracted and templatized, will provide immediate value.
Begin with components: Build reusable infrastructure building blocks before you worry about fancy UIs or workflow orchestration. You need solid foundations before you can build the house.
Implement progressive disclosure: Give people simple interfaces for common use cases, but always provide escape hatches for complex scenarios. The moment your abstraction becomes a prison, developers will route around it.
Measure and iterate: Track adoption and gather feedback religiously. Your platform is only as good as its adoption rate, and adoption only happens when you’re solving real problems for real people.

The Future of IDPs and Platform Engineering

Trends come and go, but platform engineering is here to stay. It’s not just another tool or methodology. This is how modern organizations scale infrastructure to match the speed of innovation. The companies that win are the ones that treat their Internal Developer Platform (IDP) as a strategic foundation, not just a tool.

Your job isn’t just to manage infrastructure and choose the right tools - it’s to enable developers to move faster while keeping governance, security, and costs under control. Get that balance right, and your platform becomes a force multiplier across your entire engineering department.

The fastest way to get there? Focus on these five essential components:

Abstractions
Blueprints
Workflows
Security guardrails
Self-service

Together, they turn your IDP into more than just infrastructure automation, they create a platform that developers trust and your business relies on.

Ready to Build a Successful IDP that Scales?

Pulumi makes it easy to go from static IaC to dynamic, self-service infrastructure with real programming languages and built-in guardrails.

Explore Pulumi IDP or sign up for free to get started today.

Backstage vs Pulumi IDP: Why Infrastructure-First Wins!

Engin Diri — Wed, 13 Aug 2025 00:00:00 +0000

Developers are losing days every month to infrastructure bottlenecks, compliance hurdles, and inconsistent environments. Platform engineering promised to fix that, yet too many platforms fail before they deliver real impact.

In this comparison of Backstage vs Pulumi IDP, we’ll explore why choosing the right architectural approach matters more than the tool itself.

Quick comparison: Backstage vs Pulumi IDP

Backstage is an open-source developer portal framework from Spotify that focuses on service catalogs and documentation. It requires significant setup time (12-18 months) and ongoing maintenance (3-5 FTEs).

Pulumi IDP is an infrastructure-first internal developer platform that embeds governance, cost control, and security from day one. It can be deployed in hours with minimal ongoing maintenance.

The problem isn’t whether you choose Backstage or Pulumi IDP. The real question is: Will your platform treat infrastructure as a first-class concern, or as an afterthought?

According to Gartner, 80% of large enterprises will deploy internal developer platforms within the next two years. But without a strong infrastructure foundation, those platforms risk becoming expensive, hard-to-maintain bottlenecks instead of accelerators.

Why platform engineering efforts fail: Common mistakes

Platform teams consistently make four critical mistakes:

Neglecting Infrastructure Foundations
Over-focusing on the developer portal experience while letting infrastructure governance and scalability lag behind.
Ignoring Cost Efficiency
Prioritizing productivity at the expense of cloud cost management.
Example: One company considered giving every developer their own cluster, a scaling nightmare both technically and financially.
Treating Security & Governance as Add-Ons
Bolting on compliance after launch leads to constant firefighting and security debt.
Building for Yesterday’s Architecture
Designing general-purpose platforms that can’t keep up with Kubernetes-native workloads.

Portal-first vs infrastructure-first platform engineering

There are two dominant approaches:

Portal-First typified by Backstage, which starts with developer experience and service catalogs.
Infrastructure-First exemplified by Pulumi IDP, which builds the platform foundation around scalable, policy-driven infrastructure.

Platform Engineering Feature	Backstage (Portal-First)	Pulumi IDP (Infrastructure-First)
Primary Focus	Developer portal & catalog	Scalable, policy-driven infrastructure
Setup Time	12-18 months	Hours
Maintenance	3-5 FTE ongoing	Minimal ongoing overhead
Infra Provisioning	Requires separate tooling	Built-in
Cost Awareness	Depends on infra layer	Native
Security & Governance	Add-on	Built-in from day one

Backstage: The portal-first platform engineering approach

Backstage is an open-source framework for building developer portals. Originally built by Spotify, it excels at unifying tools, services, and documentation.

Strengths

Mature Ecosystem with over 1,200 integrations and a large community.
Excellent Service Catalog providing centralized metadata, ownership, and discovery.
Docs-as-Code that keeps documentation close to the codebase.
Self-Service Templates that standardize scaffolding for new projects.

Challenges

High Maintenance Overhead requiring 3-5 FTEs just to keep it running in large orgs.
Complex Setup with Yarn version headaches, TypeScript complexity, plugin upkeep.
Infra as an Afterthought that lacks built-in provisioning, often pushing infra concerns down the road.
Hidden Costs resulting in multi-million dollar TCO over three years for a 300-dev team when factoring in staffing and infra complexity.

Pulumi IDP: the infrastructure-first platform engineering approach

Pulumi IDP brings Infrastructure Platform Engineering (IPE) to the forefront by embedding scalable, secure, cost-aware infrastructure into the platform from day one.

Strengths

Infrastructure as a First-Class Concern with built-in multitenancy, isolation, and governance.
Efficiency & Cost Awareness through golden paths and reusable components optimized from the start.
Policy-Driven by Design that enforces security, compliance, and cost policies automatically.
Cloud-Native Ready ideal for ephemeral workloads, Kubernetes, and multi-cloud.

Considerations

Newer Platform with a smaller plugin ecosystem than Backstage’s.
Infra-Heavy Focus that’s best fit for infra-intensive orgs; overpowered if you only need a catalog and docs.

Real-world platform engineering outcomes: Backstage vs Pulumi IDP

Pulumi IDP Adoption: CLEAR leveraged Pulumi IDP’s prebuilt capabilities instead of building infra automation from scratch, speeding up delivery while keeping governance tight.

Backstage vs Pulumi IDP decision guide

When to choose Backstage

Choose Backstage for platform engineering if you:

Have a dedicated platform team with strong React/TypeScript skills
Primarily need service cataloging and documentation
Already have robust infrastructure provisioning and governance tools
Have 18+ months and budget for ongoing maintenance (3-5 FTEs)

When to choose Pulumi IDP

Choose Pulumi IDP for platform engineering if you:

Need infrastructure governance from day one
Want cost management and policy automation built in
Must scale efficiently across Kubernetes and multi-cloud
Prefer to avoid building everything from scratch
Need to deploy quickly (hours vs months)

Build your platform on infrastructure

Pulumi IDP embeds governance, cost control, and security into your platform from day one, giving your teams self-service golden paths with policy enforced automatically.

Get started

The shift to infrastructure platform engineering (IPE)

Platform engineering isn’t failing because the idea is flawed. It’s failing because too many efforts start with the portal and leave infrastructure for later.

Infrastructure Platform Engineering flips that model, ensuring the platform’s foundation is:

Hybrid approaches are also possible. Pulumi offers a Backstage plugin so teams can pair Backstage’s portal features with Pulumi IDP’s infrastructure power.

Bottom line: infrastructure-first wins for platform engineering

If your platform is slow, costly, or hard to govern, it’s not a developer problem. It’s an infrastructure problem. Treating infrastructure as a first-class concern from day one isn’t optional. It’s the difference between a platform that scales and one that stalls.

Frequently asked questions

What is the main difference between Backstage and Pulumi IDP?

Backstage is a portal-first developer platform that focuses on service catalogs and documentation, requiring separate tools for infrastructure provisioning. Pulumi IDP is an infrastructure-first platform that embeds governance, cost control, and infrastructure automation from the start.

How long does it take to implement Backstage vs Pulumi IDP?

Backstage typically requires 12-18 months for full implementation with ongoing maintenance by 3-5 FTEs. Pulumi IDP can be deployed in hours with minimal ongoing maintenance overhead.

Can I use Backstage and Pulumi IDP together?

Yes, Pulumi offers a Backstage plugin that allows teams to combine Backstage’s portal features with Pulumi IDP’s infrastructure capabilities for a hybrid approach.

What are the costs of running Backstage vs Pulumi IDP?

Backstage’s TCO for a 300-developer team can reach multiple millions over three years when factoring in staffing and infrastructure complexity. Pulumi IDP has lower operational costs due to built-in automation and minimal maintenance requirements.

Which platform is better for Kubernetes environments?

Pulumi IDP is purpose-built for cloud-native and Kubernetes environments with built-in support for ephemeral workloads and multi-cloud deployments. Backstage requires additional tooling for Kubernetes infrastructure management.

Learn more about Pulumi IDP and how infrastructure-first platform engineering avoids common failure patterns.

Governance as an Enabler: Scaling Safely and Confidently

Adam Gordon Bell — Tue, 17 Jun 2025 00:00:00 +0000

In previous articles in this series, we’ve explored how platform engineering transforms infrastructure chaos into consistent provisioning, empowers engineering teams through self-service infrastructure, optimizes workflows, embeds security directly into your platform, and provides observability as a superpower. Each pillar builds upon the previous ones, creating a cohesive foundation that accelerates innovation and productivity.

But as your platform scales, new challenges inevitably emerge. You’ve empowered engineering teams with self-service infrastructure, streamlined workflows, and embedded security directly into your platform. But as your platform scales, new challenges emerge: How do you ensure consistency, compliance, and cost control without slowing your teams down?

In this article, we’ll explore how Platform Engineering transforms governance from a manual, bureaucratic process into an automated, built-in enabler, helping your organization scale safely and confidently. By embedding governance directly into your platform, you can maintain control, ensure compliance, and manage costs effectively, all while preserving the autonomy and speed your engineering teams have come to expect.

The Problem: Governance as a Manual Bottleneck

Dealing with manual compliance checks and red tape

With increased team autonomy and self-service capabilities, how do you ensure consistency, compliance, and cost control across your entire organization?

Governance often feels like a necessary evil: manual, bureaucratic, and slow. Application teams see it as red tape, while operations teams struggle to maintain control. Manual compliance checks, lengthy audits, and unclear or inconsistent policies create friction and frustration. Teams may bypass governance processes entirely, leading to shadow IT, inconsistent resource configurations, and hidden risks.

The consequences of manual, bureaucratic governance are clear:

Increased compliance risks and audit failures: Without automated enforcement, compliance becomes reactive and error-prone, increasing the likelihood of regulatory violations and audit findings.
Unpredictable cloud costs and budget overruns: Without clear guardrails, self-service infrastructure can lead to resource sprawl, wasted resources, and unexpected cloud bills.
Reduced team autonomy and slower innovation: Manual governance processes reintroduce bottlenecks, slowing down deployments and undermining the agility your platform was designed to achieve.

The Solution: Embedding Governance into Your Platform

Successfully scaling safely with embedded governance

Governance should live inside your platform, not off to the side as a separate process. To make that happen, build these four capabilities into your IDP:

Policy-as-Code for Automated Compliance: Declare rules (like approved regions or required tags) as code. The platform enforces them whenever infrastructure is created or updated, so compliance happens automatically.
Platform-Level RBAC for Permission Boundaries: Decide who can act on projects, stacks, and templates before any cloud credentials run. This early check prevents unauthorized requests from ever reaching cloud provider.
Audit Logs and Drift Detection for Real-Time Visibility: Record every deployment, who ran it, and what changed. Continuously compare live infrastructure to the desired state in code. If someone bypasses approved processes, the platform flags it and alerts the team.
Resource Lifecycle and Deployment Controls: Automatically retire idle environments after a set time (Resource TTLs) so forgotten test clusters don’t rack up bills. Also if needed, gate production changes behind lightweight approval workflows. Routine dev or staging updates roll out instantly, but high impact production changes wait until a reviewer signs off.

Let’s dive into each of these.

A. Policy-as-Code for Compliance and Operational Standards: Automating Trust and Consistency

An engineering team is ready to launch a new service. They’ve tested it and everything looks good, until the deployment fails. Not because of a bug. Because it’s targeting an unapproved cloud region.

Now they’re stuck. A compliance review kicks off. Slack threads fly. A ticket gets filed. What should’ve been a smooth release turns into a delay, all because of a policy someone missed.

Policy-as-code prevents this.

When teams deploy something that breaks the rules (like using an unapproved region), the platform blocks it automatically. The error shows up right away, with a clear message. Nothing gets provisioned, and nobody has to file a ticket.

If you’re already using intent-based components (“I need a Java service with Kafka and PostgreSQL”), most details are handled for you: tags, regions, naming. But people still override things. That’s why policy-as-code matters.

Think of it as a safety net. A menu of components handle the defaults. Policies catch anything that slips through. Together, they keep your platform consistent without slowing anyone down.

B. Role-Based Access Control (RBAC): Balancing Autonomy and Control

Stopped by lengthy approval processes

As your platform grows, managing permissions manually gets messy. If an engineer needs to fix a production issue but doesn’t have access, they file a ticket and wait, sometimes for days. Give developers too many rights, and they might change production by accident. Both options slow teams down and increase risk.

The fix is an RBAC model built into your platform. First, the platform decides who can deploy, who can publish components, and who can manage templates. This check runs before any cloud credentials are used, so invalid requests get blocked early. Second, the cloud IAM layer controls which API calls are allowed, like creating an EC2 instance or updating a database.

This pairs well with a two-level intent-based approach. Teams describe what they need (“I want a Python Lambda with an SQS queue”), and the platform enforces access only for users with the right scopes. Everyone gets just enough access to do their job, no more, no less.

A Platform with RBAC makes permissions clear, reduces mistakes, and keeps everything auditable. Devs move fast, spinning up resources as needed, while strong guardrails stay in place. The result is a scalable, least-privilege model that balances autonomy and control, so your organization can grow safely.

C. Auditability, Traceability, and Drift Detection: Ensuring Visibility and Trust

Anxious about audit failures and compliance risks

An ops engineer spots a production database misbehaving. A quick check shows someone changed its configuration outside the approved workflow. Without an audit trail or drift detection, the team scrambles to figure out who made the change and when. Meanwhile, the incorrect setting stays active, posing a security and compliance risk. No one can fix it without guessing.

A platform with audit logs records every action: who deployed, when, and what changed. Drift detection watches live infrastructure and compares it to the desired state in code. If someone bypasses the workflow (say, editing a database setting in the console), the platform flags it and alerts: “User Alice changed max_connections on prod-db-01 at 3:42 PM, which no longer matches the expected state.” Now the team can pinpoint the change, talk to the right person, and revert or update the code, restoring consistency in minutes, not hours.

Together, audit logs and drift detection give you real-time visibility into every change. You stop playing detective. You see who did what, when, and how it deviated from code, all in one place. That transparency speeds audits, catches unauthorized changes fast, and builds trust across teams. With automatic traces of every change, your platform scales without surprises.

D. Resource Lifecycle and Deployment Controls: Scaling Responsibly and Safely

An engineer spins up a test environment, then walks away. Another pushes a change straight to production without review. The abandoned test cluster runs up cloud costs; the unreviewed prod tweak risks an outage. Without automation, both lead to wasted spend and stressful cleanups.

A modern platform handles this with ephemeral environments where possible and approval gates where it matters.

In dev and staging, engineers can move quickly. They can create test or preview environments, often tied to users or pull requests, that shut down automatically after a set time. TTL rules keep things tidy without manual cleanup.

Production, by contrast, is gated. High-impact changes, like modifying a database schema or adjusting a load balancer, require approval. Before anything is provisioned, sign-off is required. Every approval (or denial) is logged: who, when, and why.

This setup keeps development fast and flexible, while making production changes deliberate and auditable. Your platform stays clean, cost-effective, and safe without getting in the way.

Drowning in resource sprawl and unexpected costs

Real-World Example: Governance Enablement in Action

An engineering team opens a pull request for a new customer-facing service. The platform spins up a preview environment using a template with secure defaults, pre-approved modules, and policy checks. CI runs tests and policy checks in preview (names, regions, encryption, compliance) so the team catches issues early. If a rule fails (say, an unencrypted database), the PR fails before it reaches main. After the PR merges to main, it deploys to production, confident all policy validations have passed.

Idle QA environments shut down after 48 hours, so forgotten clusters don’t rack up bills. Sensitive production changes, like updating a load balancer or altering a critical schema, are carefully reviewed via pull request. Once approved, the platform deploys automatically and logs every action. Drift detection flags console edits, letting the team revert or update code in minutes.

Result: Governance becomes an invisible safety net. Engineers move fast, knowing policy-as-code, RBAC, TTL cleanup, approval gates, and change tracking catch mistakes. Ops stays in control without firefighting or chasing orphan resources. The platform scales safely, balancing freedom with built-in guardrails.

Metrics: Measuring Governance Enablement

To ensure your governance practices truly empower your organization, it’s essential to track clear, actionable metrics. These metrics help you understand the effectiveness of your governance processes, identify areas for improvement, and ensure governance remains frictionless and enabling:

Time Spent on Manual Compliance Checks and Audits: Measure how much time your teams spend manually verifying compliance or performing audits. Effective governance automation should significantly reduce this overhead, freeing teams to focus on higher-value tasks.
Number of Compliance Violations or Audit Findings: Track how frequently compliance violations or audit issues occur. Effective governance should reduce these incidents, demonstrating that automated policies and guardrails are working as intended.
Cloud Cost Predictability and Budget Adherence: Monitor how accurately your cloud spending aligns with forecasts and budgets. Good governance practices, such as automated tagging, resource lifecycle management, and cost controls, should improve predictability and reduce unexpected cost overruns.
Engineering Team Satisfaction with Governance Processes: Regularly survey engineering teams to gauge their satisfaction with governance processes. High satisfaction indicates that governance is enabling rather than hindering their workflows.

Tracking these metrics helps you continuously improve your platform’s governance practices, ensuring they remain effective and frictionless.

Working within clear, automated guardrails

Pulumi and Governance Enablement

Pulumi provides built-in governance features that help you scale safely and confidently, embedding compliance, consistency, and control directly into your platform:

CrossGuard (Policy as Code) Define and enforce compliance and operational policies automatically. CrossGuard checks every resource against your organization’s standards before deployment, preventing non-compliant resources and reducing manual audits.
Role-Based Access Control (RBAC) and Teams Manage permissions with precision. Pulumi’s RBAC ensures teams get exactly the access they need, no more, no less, so developers can move quickly within clear boundaries and ops can reduce risk.
Audit Logs and Drift Detection Capture a full history of every change and compare live infrastructure to the desired state in code. Audit logs simplify compliance reviews, drift detection spots unauthorized edits, and teams can fix issues in minutes.
Time-to-Live (TTL) Stacks / Ephemeral Environments Spin up short-lived environments for testing or previews. You can assign a TTL to any stack so it shuts down automatically after a set period. That keeps forgotten test resources from racking up costs and ensures your platform stays clean.

By leveraging Pulumi’s governance features, including CrossGuard, RBAC, audit logs, and TTL stacks, your platform becomes a powerful enabler. You automate compliance, maintain consistency, and empower engineering teams to innovate quickly and safely.

Conclusion: Governance as a Platform Feature

Having autonomy with built-in controls

Governance doesn’t have to slow you down. By embedding governance directly into your platform, you empower engineering teams to innovate quickly while ensuring compliance, consistency, and control. Instead of manual checks, governance becomes automatic, transparent, and frictionless, enabling your organization to scale safely and confidently.

Your engineering teams gain autonomy and speed, your operations teams gain visibility and control, and your organization gains the confidence to innovate at scale.

You’ve now seen all six pillars of a modern internal developer platform—provisioning, self-service, developer experience, security, observability, and governance. If you’d like to see how Pulumi makes building and running a platform like this simpler, check out Pulumi IDP.

Observability as a Developer Superpower

Adam Gordon Bell — Tue, 10 Jun 2025 00:00:00 +0000

Frustratedly trying to figure out what's actually happening

In previous articles in this series, we’ve shown how platform engineering turns infrastructure chaos into consistency, gives teams self-service tools, smooths developer workflows, and bakes security into the platform. Each pillar builds on the last. Together, they create an internal developer platform that cuts friction and speeds innovation.

Even so, teams still face a big challenge: seeing what’s really happening. Whether things go wrong or run smoothly, engineering teams need clear, actionable insights into their systems. Without observability, you end up guessing, reacting slowly, and hunting through scattered data.

This article shows how observability can be a superpower, giving teams the visibility, insights, and confidence to build better software. Embedding observability into your platform lets teams spot, understand, and fix problems fast, turning reactive firefighting into proactive innovation.

The Problem: Data Overload Without Insights

Teams drown in metrics, logs, and traces but lack useful insights. In practice, this shows up in three common friction points:

Tool sprawl: Teams use separate tools for metrics, logs, and traces. They waste time flipping between dashboards and stitching data together.
Alert fatigue: Teams get hit with noisy, context-free alerts. With no clear priority or context, key alerts get lost, causing missed issues or slow responses.
Reactive debugging: Troubleshooting turns into a late-night fire drill. Teams spend hours digging through logs and metrics after users have already noticed the problem.

When observability is limited to post-mortems and fragmented dashboards, your team wastes time reacting instead of preventing problems, and innovation grinds to a halt.

The Solution: Observability as an Engineering Superpower

Exhausted from hours of reactive debugging when the problem could have been caught earlier

The solution isn’t just about bolting on more monitoring tools. it’s about baking visibility, context, and guidance into your platform. To do this, embrace three key principles:

Centralized Service Dashboards & Service List Surface every running service (or database, function, etc.) in one “Services” portal, complete with health badges (CPU, error rate), on-call owner info, and one-click links to that service’s metrics, logs, and traces. By unifying all telemetry behind a single service card, you eliminate context-switching and help engineers find exactly what they need in seconds, not minutes.
Actionable Alerts and Insights Replace vague, noisy notifications with context-rich, prioritized alerts that include severity, correlated root-cause data, and recommended next steps (“Database latency jumped 200% since last deploy: rollback or scale up replicas”). Group and surface only the most critical issues first to reduce alert fatigue and speed up resolution.
Embedding Observability into Engineering Workflows Ship every new microservice with built-in logging, metrics, and tracing by including those hooks in your platform’s service templates and CI/CD pipelines. When instrumentation is automatic, “oops, I forgot to add a span” moments disappear, and teams gain immediate visibility into performance and errors from day one.

When observability becomes a superpower, engineering teams gain the visibility and insights they need to confidently build, deploy, and operate software. Instead of drowning in data, they proactively identify and resolve issues, optimize performance, and innovate with confidence.

A. Centralized Service Dashboards & Service List

Reading the Service Catalog

Imagine you’re paged at 2 AM because “OrderService” is failing, but you don’t know where to look. Metrics live in Grafana, logs are in Elasticsearch, traces in Jaeger, and you still have to hunt down who’s on call. You spend precious minutes clicking through multiple UIs and Slack channels just to figure out who owns the service and where its telemetry lives.

A centralized service list solves this by surfacing every running microservice (or database, or function) in one place. In your platform’s web portal, you land on a “Services” page that shows OrderService alongside CPU and error‐rate badges, an on-call owner, and links to its real-time dashboard, filtered logs, and trace waterfall. No matter which team spun it up, you know exactly where to click: metrics, logs, traces, deployment history, and contact info all live behind a single service card.

By embedding a service list into your platform, you eliminate context switching and reduce onboarding friction. If a service isn’t listed, it isn’t properly instrumented, so gaps stand out immediately. In practice, this “one‐pane‐of‐glass” approach means engineers spend seconds finding the right dashboard and the right person, instead of minutes piecing together fragments across disconnected tools.

B. Actionable Alerts and Insights: Reducing Noise and Accelerating Response

Digging through alert noise

It’s 4 AM and your phone buzzes with three simultaneous alerts, each with vague descriptions like “High CPU usage detected” or “Error rate increased.” Without clear context or recommended actions, you must manually investigate each alert, digging through logs and metrics to determine severity and root cause. This manual triage process is slow, frustrating, and error-prone, increasing the risk of missing critical issues or delaying resolution.

Engineering teams often face a constant barrage of alerts, many of which lack clear context, severity, or actionable next steps. This flood of noisy, ambiguous notifications creates alert fatigue, causing your team to overlook critical issues or waste valuable time investigating false positives.

A platform approach should focus on actionable metrics. Instead of vague notifications, clearly state the issue (“Database latency increased by 200%”), provide relevant context (“Latency spike correlated with recent deployment”), and suggest immediate actions (“Rollback recent deployment or scale database resources”). Additionally, alerts are automatically grouped and prioritized based on severity and impact, ensuring you focus on the most critical issues first.

By holistically approaching alerts and insights, you significantly reduce alert fatigue and noise, accelerate incident response and resolution, and empower engineering teams with greater confidence and autonomy. Your team spends less time manually triaging alerts and more time proactively resolving issues, improving reliability, productivity, and overall team satisfaction.

C. Embedding Observability into Engineering Workflows: Visibility from Day One

At 2 AM, where are the logs for this service.

You’ve just deployed a brand-new microservice to production, only to discover performance issues or unexpected behavior. Sure, you should remember to add tracing, logging, and metrics by hand, but in practice, things slip through the cracks. It isn’t until real-world traffic hits that you realize you forgot to instrument X or Y, and now you’re scrambling to retroactively add code, redeploy, and wait for data to appear, delaying resolution and frustrating your team.

If your platform’s service templates already include all the necessary logging, metrics gathering, and tracing out of the box, it makes life a lot easier. Embedding observability into those templates and engineering workflows ensures every new microservice ships with built-in instrumentation.

This proactive approach reduces “oops, I forgot” moments, accelerates troubleshooting, and increases team productivity and satisfaction, ultimately improving the reliability and quality of your software.

Real-World Example: Observability Superpower in Action

Applying an Actional Metric

At 3:15 AM, your pagerduty alert goes off: “CheckoutService latency spiked 150%.” You log into your platform’s Services portal and immediately see CheckoutService highlighted with a red latency badge and Todd Rivera listed as the on-call owner. Rather than scouring multiple dashboards, you click its service card to jump straight to the metrics, logs, and trace views.

The alert itself is remarkably precise: “CheckoutService latency rose 150% at 3:10 AM following the v2.3.1 deployment. PaymentGatewayService upstream error rate jumped from 0.2% to 2.3%. Recommendation: rollback v2.3.1 or scale PaymentGateway pods. Contact Todd Rivera.” Instantly, you know where the problem lies, which upstream service is impacted, and what the next step should be. In the trace waterfall, you spot a 200 ms delay on CheckoutService calls to PaymentGateway. The logs, automatically instrumented by your service template, filter to TimeoutException entries all timestamped at 3:10 AM. Opening the “Ask Platform” AI widget, you type, “Why did CheckoutService latency spike at 3:10 AM?” The AI responds: “Likely cause: v2.3.1 added index idx_created_at to PaymentGateway’s transactions table, causing an 80 ms delay per request. Rollback v2.3.1 or patch queries to remove the new index.”

Armed with this precise diagnosis, you open a rollback pull request and, after Todd’s ok, deploy it within minutes.

CheckoutService latency and PaymentGateway errors immediately return to baseline. By moving from alert to resolution entirely within the platform (thanks to built-in instrumentation, actionable alerts, and AI-driven analysis, you’ve squashed a major incident before most users ever noticed.

Metrics: Measuring Observability Enablement

To ensure your observability practices truly empower engineering teams, it’s essential to track clear, actionable metrics. These metrics help you understand the effectiveness of your observability tools and processes, identify areas for improvement, and demonstrate the tangible impact observability has on your organization.

Key metrics to measure observability enablement include:

Mean Time to Detection (MTTD):
How quickly are issues identified after they occur? Effective observability should significantly reduce the time it takes to detect problems, enabling faster responses and minimizing user impact.
Mean Time to Resolution (MTTR):
How quickly are issues resolved once detected? With clear, actionable insights and unified observability, your teams should resolve issues faster, reducing downtime and improving reliability.
Engineering Team Satisfaction with Observability Tools:
Regularly survey your teams to gauge their satisfaction with observability tools and workflows. Higher satisfaction indicates that observability is effectively embedded into engineering workflows, reducing friction and increasing productivity.
Adoption Rate of Observability Tools and Dashboards:
Track how widely observability tools and dashboards are adopted across teams. Increased adoption indicates that your teams find these tools valuable, intuitive, and helpful in their daily work.
Reduction in Alert Noise and False Positives:
Measure the volume and accuracy of alerts over time. Effective observability should reduce noisy, irrelevant alerts, ensuring your teams focus on meaningful, actionable notifications.

Tracking these metrics helps you continuously improve your observability practices, ensuring they remain effective and empowering. By regularly reviewing and acting on these insights, you can proactively enhance team productivity, reliability, and overall satisfaction.

Pulumi and Observability Enablement

Platform insights

Pulumi’s platform features let you explore observability without bolting on extra tools. Key Pulumi features that enable observability include:

Pulumi Insights:
Provides unified visibility and powerful search across all your cloud resources. Your teams can quickly discover, explore, and understand their infrastructure, eliminating manual searches and reducing cognitive load.
Centralized Service List: Pulumi IDP’s Services portal gives you a single place to register each microservice, database, or cloud resource and link to its dashboards, logs, and traces.
Pulumi Co-Pilot:
Delivers AI-powered troubleshooting and insights directly within your workflows. Your teams can ask natural-language questions about their infrastructure (such as “What infrastructure changed yesterday?”) and receive immediate, actionable answers.
Built-In Instrumentation via IDP Components:
When you author components and templates in Pulumi IDP, you can bake in standard logging, metrics, and tracing hooks. Every service spun up from those templates ships with consistent instrumentation on day one.

With Pulumi, observability can become an integrated part of your platform, accelerating innovation, improving reliability, and empowering engineering teams to confidently build, deploy, and operate software.

Conclusion: Observability as a Platform Feature

Happy resolving an incident in minutes.

Observability isn’t just about plugging in more tools. It’s about baking-in consistent instrumentation, measurement, and context so every engineer (platform, DevOps/SRE, or application) knows exactly where to look and how to act.

Service-Templates with Built-In Telemetry By providing service templates that already include logging, metrics gathering, and tracing, you eliminate “Oops, I forgot to instrument X” moments. Every new microservice inherits a standard setup, so you never have to retroactively add code or scramble when traffic first hits production.
Consistent Service Dashboards & Centralized Service List Instead of hunting across eight different dashboards, engineers always start from a single “Service List” page. From there, one click takes them to that service’s metrics overview, log stream, or trace waterfall. This unified entry point reduces cognitive load and cuts straight to “Where’s the problem?”
Measuring Alert Quality and Actionability A truly mature platform doesn’t just send alerts. It tracks whether those alerts are helpful or noise. By measuring “ratio of actionable alerts vs. false positives,” you continuously fine-tune thresholds and eliminate alert fatigue. The result? Engineers trust their notifications and respond faster to real incidents.
AI-Driven Context and Natural-Language Troubleshooting On top of unified telemetry and alert quality metrics, AI can instantly correlate recent deployments, configuration changes, and error spikes. Engineers can ask, “Why did latency jump at 3 AM?” or “What changed in production last night?” in plain English, and the platform provides a clear, context-enriched answer. This additional layer turns reactive firefighting into proactive problem prevention.

When you combine these elements (components and templates, a single service dashboard, alert quality measurement, and AI/natural-language querying), you transform observability into a genuine superpower. Issues are spotted, triaged, and fixed before customers even notice.

Next time, we’ll dive into the final pillar, Platform Governance, showing how to enforce policy, manage costs, and keep your platform secure and compliant as it scales.

Platform Engineering Buffet at SEITENBAU

Nico Thomas — Tue, 27 May 2025 00:00:00 +0000

This post is based on my video interview with Nico Thomas, a platform engineer at SEITENBAU. In this article, Nico shares how he and his team built a flexible, reusable platform to support 20+ diverse projects using Pulumi. Watch the video below or read on for Nico’s take on building an infrastructure buffet. - Adam Gordon Bell

Imagine your company isn’t Spotify with one product pipeline, but 20 independent government projects running on Ansible-provisioned VMs—some on Kubernetes, some delivered into other customer data centers, some operated by clients themselves. Each team is building its own CI/CD, secrets management, and integrations. You’re left with a million reinvented wheels.

That was the situation my team and I faced at SEITENBAU, a German software company specializing in custom development for both public and private sectors. Unlike the typical platform engineering stories—where teams build infrastructure for a single product with multiple microservices—we had a fundamentally different challenge: How do you build a platform that serves dozens of completely independent projects, each with their own technology choices, deployment targets, and operational models?

The answer? Stop trying to force everyone onto the same plate. Instead, build a buffet.

The Buffet Philosophy

Think of a traditional platform as a set menu—also known as prix fixe—where everyone gets the same courses, prepared the same way, in the same order. But what if your diners include vegans, carnivores, and people with various dietary restrictions? What if some want a quick snack while others need a seven-course meal?

That was exactly the situation we faced. We had:

Government projects that needed to run on-premises due to data sovereignty requirements.
Modern cloud-native applications leveraging Kubernetes and GitOps.
Legacy systems still operating on virtual machines managed with Ansible.
Projects we ran as managed services and others we simply delivered to customers.
Teams using various CI/CD tools, artifact repositories, and deployment strategies.

A one-size-fits-all platform would have been a disaster. Instead, my team built a platform offering a rich selection of pre-configured, production-ready components. Teams could mix and match according to their specific needs, creating their own unique infrastructure combinations.

The Challenge: Beyond Microservices

Most platform engineering resources assume you’re building infrastructure for a single product – Spotify’s Backstage, for example. But what happens when you’re dealing with over 20 completely independent projects, each with distinct requirements?

Each project is distinct, featuring its own:

Technology stack (Java predominates, but we support various frameworks and languages).
Infrastructure requirements (cloud, on-premises, or hybrid setups).
Security and compliance constraints.
Operational models (managed by us, the client, or jointly).
Release cadences and deployment strategies.

Initially, this diversity seemed chaotic, but we quickly noticed that underneath these variations, common patterns emerged. Every project consistently required source control, CI/CD pipelines, artifact storage, secrets management, and deployment targets. The critical realization was that we didn’t need to standardize what teams chose—we needed to standardize how they connected these building blocks.

That’s where Pulumi became essential. Its flexibility allowed us to construct an infrastructure buffet that genuinely accommodated the diverse appetites and needs of every team.

Building the Kitchen: Architecture with Pulumi

Behind every great buffet is a well-organized kitchen. For our infrastructure, that kitchen is powered by Pulumi and Python, orchestrating a complex web of infrastructure services, configurations, and deployments. Using Pulumi together with Python has proven extremely valuable—it makes our day-to-day tasks easier to maintain and understand.

The Multi-Stack Approach

Rather than creating a single monolithic infrastructure program, we adopted a modular approach with multiple Pulumi stacks. This decision was essential for managing complexity and empowering team autonomy.

Our architecture comprises several specialized Pulumi programs:

GitLab System: Manages installations and configurations of GitLab.
Project Configuration: Sets up team-specific GitLab groups, CI/CD runners, and agents.
Cluster Management: Provisions Kubernetes clusters complete with standard add-ons.
VM Infrastructure: Manages traditional VM-based deployments utilizing Ansible.
Platform Services: Configures shared services such as artifact repositories and identity providers.

Each program can maintain multiple stacks (dev, staging, prod), allowing us to manage various environments independently while leveraging shared infrastructure code.

From Ingredients to Ready-Made Dishes: Reusable Components

The real magic happens in our component library. Just as a buffet offers complete dishes rather than raw ingredients, we’ve built high-level components that encapsulate complex infrastructure patterns.

Example: The Kubernetes Storage Component

Consider our Longhorn storage component. Instead of requiring teams to understand Helm charts, storage classes, and snapshot configurations, they simply declare they need persistent storage.

The component handles all the complexity: installing Longhorn, configuring appropriate replication for test vs. production environments, setting up snapshot classes, and integrating with our internal certificate authority.

Two Years Later: The Buffet is Open

After two years of running this platform in production, we’ve learned what works and what we’d do differently.

Building a platform for diverse, independent projects requires a different mindset than traditional platform engineering. Instead of forcing standardization, we’ve embraced flexibility while maintaining consistency where it matters.

The buffet approach—powered by Pulumi’s flexibility and Python’s expressiveness—has allowed us to serve 20+ different projects efficiently while giving teams the autonomy they need. It’s not about having one perfect dish; it’s about having a kitchen flexible enough to satisfy everyone.

If you’re facing similar challenges with diverse project requirements, consider building a buffet instead of a prix fixe menu. Your teams will thank you for it.

Want to build your own infrastructure buffet? Get started with Pulumi and join our community Slack to connect with engineers solving similar challenges.

Platform Engineering: Evolution or Rebranding?

Adam Gordon Bell — Mon, 12 May 2025 00:00:00 +0000

2 Months ago, user deacon91, after years of working in the industry has declared DevOps to be a dead end on Reddit’s r/devops. And I’ve been thinking about his thoughts on the industry since then.

His point was that DevOps, the breaking down of silos between development and operations, had been tried. We learned the lessons of this approach and need to do something better: Platform Engineering.

And platform engineering has certainly emerged as a new hot area. But is it truly an evolutionary step toward a greater way of developing and operating software? Or is it, as others in that same Reddit group declare, merely a fad and a rebranding of existing ideas?

That’s what I want to explore: is platform engineering a rebrand or a genuine evolution?

Let’s start by summarizing the cynical case - that it’s merely a rebrand.

The Rebrand Case

Title Drift

This title drift happens in many fields. Just as the garbage man becomes the sanitation worker so does the sysadmin becomes the DevOps engineer.

This creates title inflation in our competitive industry. People who job-hop regularly update their LinkedIn profiles from “business analyst” to “product manager.” Meanwhile, the person who stays put for years might still be called a “programmer” while everyone around them becomes a “Staff-plus Senior Backend Engineer.”

That ops wizard who’s been at the same company for eight years? Still an “Operations Engineer.” Their friend who switches jobs every 18 months? Now a “Senior SRE” making 50% more money.

Title drift becomes a self-reinforcing cycle. When the recruiter discovers that the best DevOps candidates now call themselves “Platform Engineers,” your company’s job postings change overnight—even if no one plans to build an actual platform.

This is how you end up with people like u/hajimenogio92 doing the exact same sysadmin work they’ve always done, just with “Platform Engineer” on their LinkedIn profile.

This is one aspect of what people mean why they say “platform engineering is just a rebrand.” The other thing they sometimes mean is that it’s a fad everyone is chasing.

Hype Cycle Reboot

Tech movements decay in predictable ways. Remember Extreme Programming? It began as a revolution to empower developers. Then it morphed into Agile, and in some places, into the 12 steps, 7 competencies, and many processes of SAFe.

The Scaled Agile Framework® (SAFe®) is a set of organization and workflow patterns for implementing agile practices at enterprise scale.

Maybe SAFe makes sense for your work place, but it’s certainly a lot more complex than it’s root and this pattern is what skeptics see in platform engineering.

DevOps started at grassroots conferences with a simple message: “Let’s tear down the wall between developers and operations.” But once it peaked, everyone scrambled to slap “DevOps” on whatever they were already doing. Just like companies today adding “AI” to their products.

Eventually, the original movement gets so diluted that we need a fresh start. New terminology. New conferences. New keynote speakers recycling old ideas with updated slides. New vendors selling solutions to problems you didn’t know you had.

In this view, platform engineering isn’t revolutionary—it’s just the next square on the buzzword bingo card. DevOps plateaued. SRE plateaued. The Kubernetes experts ran out of things to say. So the industry needed something new to hype.

There’s some truth to this cynicism, but it blinds us to what platform engineering actually offers. More importantly, this view misses something crucial: where a platform approach succeeds, it reveals fundamental flaws in the original DevOps vision.

The Case for Evolution

The original DevOps movement introduced valuable ideas about breaking down silos and encouraging collaboration. However, its purest vision—where “everybody does everything”—faces practical limitations at scale.

Totally cross-functional teams work well at small organizations but struggle when engineering teams grow beyond 20 people because:

People naturally have different specializations and preferences
Few individuals want to perform both development and operations roles
Staying current on everything in your Ops and Dev stack is often unrealistic

But most importantly, as organizations grow, specializations natuarally emerge. Governance and corporate policies often force the issue. A platform team is one such specialization and a powerful one if done right.

Instead of focusing on eliminating silos, it focuses on creating productive abstractions and interfaces between application teams and operating services. The platform functions as an abstraction layer (similar to how a database abstracts data storage), with dedicated teams treating it as a product with clear boundaries.

This approach contradicts the original DevOps vision but represents a necessary evolution. Platform Engineering acknowledges inevitable organizational divisions while still enabling collaboration. It leverages skills and organizational workflows from application development and product management to build a way to operate software effectively.

Why not both?

So yeah, title drift is a thing. And the hype cycle is real. But the idea of a dedicated team removing frictions by building tools and reusable abstractions is an idea that’s here to stay.

In fact, it’s just a way to scale the principles inherent in the original ideas of DevOps. It may technically diverge from the literal principles of DevOps, but it is most definitely true to the spirit.

At Pulumi, we see this evolution firsthand. Our most forward-looking users aren’t chasing titles—they’re building internal platforms that empower teams, reduce friction, and let developers focus on what matters most. That’s why we’re investing in platform team features.

Not because it’s trendy—but because, done well, it works. And I think that’s the insight deacon91 was getting at.

Get a Free Platform Engineering Guide →

Security as an Enabler: Building Trust into Your Platform

Adam Gordon Bell — Fri, 11 Apr 2025 00:00:00 +0000

In previous articles, we looked at how platform engineering fixes infrastructure chaos, enables self-service, and improves developer workflows. These pillars work together to boost both developer productivity and organizational speed.

But there’s still one critical element that can make or break all this progress: security.

Traditional security efforts — even “shift-left” initiatives — often create friction instead of clearing the way for innovation. Embedding security directly into your platform changes that. By weaving in policy-as-code, centralized secrets management, and identity-based authentication, you turn security from a blocker into an enabler. And with the right metrics, you can measure how well your platform balances protection and speed.

When security is baked into your internal developer platform, it stops being a gatekeeper. Developers move faster — and with more confidence.

Done right, your teams gain autonomy without compromising safety. Security people become partners instead of blockers. Your organization builds trust that speeds up innovation rather than slowing it down.

The Problem: Security as a Gatekeeper

Traditional security practices often create friction rather than enable innovation. Developers run into several pain points: last-minute security reviews that delay deployments, unclear policies that feel arbitrary, and security teams that act more like blockers than partners.

This friction has real consequences. When security becomes a bottleneck, developers find ways around it. They take shortcuts. All of this increases risk through inconsistent security practices.

The end result is that innovation slows down. Developer autonomy shrinks. And the agility your platform was supposed to deliver disappears.

Many organizations try to fix this by “shifting security left” - moving security checks earlier in development. But just dumping security responsibilities onto developers isn’t the answer. It overwhelms them and can still create inconsistencies.

The real solution isn’t just about changing when security happens. It’s about changing how it works.

Key Security Functions within a Platform

Effective platform security involves several key functions, regardless of how they are distributed across teams or individuals in your organization:

Defining Security Strategy & Policy:
- Developing and maintaining security policies, standards, and architectural best practices tailored to the organization.
- Providing security guidance, education, and support across engineering teams.
- Performing threat modeling, security architecture reviews, and proactive security assessments.
Monitoring & Responding to Threats:
- Actively monitoring systems to detect security events and potential threats in real-time.
- Managing security tooling (like SIEMs, vulnerability scanners) and orchestrating incident response procedures.
- Investigating incidents, coordinating remediation efforts, and managing security automation.
Integrating Security into Development & Infrastructure:
- Embedding security controls directly into the development lifecycle and infrastructure provisioning processes.
- Implementing secure-by-default configurations, automated security checks (SAST, DAST, SCA), and policy-as-code guardrails.
- Ensuring security considerations are built into CI/CD pipelines, service templates, and infrastructure modules from the start.

Collaboration between these functions is crucial. A successful platform ensures that policy definition, operational monitoring, and practical implementation work together seamlessly to create a secure environment without hindering velocity.

The Solution: Embedding Security into Developer Workflows

The key to solving security friction isn’t just adding more checkpoints earlier. It’s weaving security directly into your platform and your developers’ daily work.

Adding automated scans to your CI/CD pipeline is a good start. Tools like Dependabot, Snyk, and Trivy catch problems early and alert developers quickly. But these “shift-left” checks alone aren’t enough. Developers still need to interpret findings and fix issues, often without adequate support.

Platform engineering takes a different approach. It builds security in from the start, rather than treating it as a final hurdle or dumping complex responsibilities on developers. It uses secure-by-default components and automated guardrails that work continuously.

Let’s see what this looks like in practice.

Policy-as-Code for Security: Automating Trust

If you’ve implemented the intent-based approach we covered earlier, your developers already use secure-by-default modules. They simply request what they need (“I need a Java service with Kafka and PostgreSQL”), and the platform handles security details like IAM roles, encryption, and permissions.

But secure defaults aren’t enough. You still need automated guardrails. Policy-as-Code adds this enforcement layer, keeping security standards consistent—even when someone tries to bypass or change the modules. It’s a backup system: secure modules provide your first defense, and Policy-as-Code catches anything that might slip through.

For Example:

IAM Roles with Least Privilege:
- Secure Default (Module): The platform team’s IAM module automatically generates roles with least-privilege permissions. Developers don’t specify IAM roles directly.
- Policy-as-Code (Additional Guardrail): A policy explicitly checks all IAM roles provisioned by the platform, ensuring no role grants overly broad permissions (e.g., no wildcard permissions). If a module is accidentally modified or misconfigured, the policy catches it immediately.
Mandatory Encryption at Rest:
- Secure Default (Module): The platform team’s database module automatically provisions databases with encryption at rest enabled. Developers don’t specify encryption settings directly.
- Policy-as-Code (Additional Guardrail): A policy explicitly checks all storage resources to ensure encryption at rest is always enabled. If a developer or platform engineer accidentally modifies the module or bypasses it, the policy immediately flags the issue.

When you add Policy-as-Code to your platform, security becomes automatic and clear. Developers get instant feedback they can trust, and security teams maintain control without slowing things down. Your teams can move fast without taking shortcuts that create risk.

Protecting Sensitive Credentials by Default

Policy-as-Code secures your infrastructure, but you still need to protect how applications access sensitive resources like databases and APIs.

Here’s what often happens: A developer copies database passwords into a local .env file. They accidentally commit this file to Git, exposing the credentials to anyone with repository access. Or they inadvertently bake these secrets into a Docker image that others can download. Worse yet, if their laptop gets hacked, attackers can use these credentials to break into production systems.

When these breaches happen, everything stops. Teams scramble to rotate credentials, investigate the damage, and fix systems—creating delays and increasing risk.

Centralized secrets management provides a robust solution to credential security. It stores sensitive information in a secure vault and offers controlled access methods at runtime. Developers work with the secrets management solution instead of handling credentials directly, which significantly reduces exposure risk.

Platform teams build these secure patterns into their service templates. They create clear pathways for accessing credentials that guide developers toward secure practices in both development and production environments.

With this approach, your deployments become both faster and safer. Developers follow simpler, more consistent security procedures, while security teams gain confidence that credentials are properly protected throughout your systems.

Identity and Access Management: Frictionless Security through Identity

Your platform must also solve another security problem: how people and systems safely access cloud resources.

Developers hate juggling multiple credentials—cloud provider keys, passwords, or tokens. These credentials can expire, get lost, or leak, causing headaches and security risks.

Consider a common scenario: A developer trying to fix a broken production system finds their credentials have expired. Now they’re stuck hunting for new credentials instead of fixing the problem.

Identity-based authentication fixes this. Developers just use their regular login. When developers log in normally, they automatically get secure access to cloud resources through OIDC or SAML. No more managing credentials. Access stays secure and current.

This approach simplifies access and removes barriers. Developers get secure access to resources when they need them, speeding up work without weakening security.

Identity-based authentication, combined with policy-as-code guardrails and centralized secrets management, creates a comprehensive security system that protects without impeding work. To see how these practices function together, let’s look at a real example.

Real-World Example: Security Enablement from Build to Incident Response

A developer deploys a new microservice. They select a secure template from the service catalog. Policy-as-code instantly checks that encryption and permissions are set correctly, and credentials are setup in a centralized secrets management environment.

As the service builds, automatic scans check dependencies and container images for vulnerabilities. The system creates a dependency list (SBOM), tracking every component used. Build pipelines verify and sign code, so only trusted code reaches production.

Once deployed, security monitoring begins automatically, showing the service’s security status in real time. Later, someone discovers a vulnerability in a library used by the microservice. Thanks to the dependency list, the security team immediately knows which services are vulnerable. Monitoring spots suspicious activity and sends clear alerts to the team’s dashboards.

Clear incident response plans help teams contain and fix the problem. The team patches the vulnerable component, using the same secure pipelines to quickly roll out the fix.

In this scenario, security helps rather than blocks at every stage. From building to responding to incidents, your platform helps teams build secure software quickly.

But how do you know if your security practices are truly enabling your teams? To answer that, you need clear, actionable metrics.

Metrics: Measuring Security Enablement

To check if your security approach works, track two things:

Security Incident Rate:
Count how many security problems reach production. Fewer incidents means your security is working.
Developer Security Friction Score:
Include security questions in your regular developer surveys. Ask how much security processes slow their work or cause frustration. Improving scores show that security fits naturally into their workflow.

These two measures combined tell you your security works and at what cost, so your team can build good software fast.

Pulumi and Security Enablement

Achieving these goals, a decreasing incident rate coupled with a low developer friction score, requires a platform built with the right foundations. Pulumi helps you construct such a platform by providing built-in capabilities that directly embed security into your infrastructure workflows:

Policy as Code (CrossGuard): Automatically enforce security and compliance standards.
Secure Secrets Management (Pulumi ESC): Centralize and securely inject secrets without manual handling.
Identity-Based Authentication: Simplify secure access to cloud resources using existing identities.

With Pulumi, security becomes an integrated, frictionless part of your platform—accelerating innovation while building trust.

Security as a Platform Feature

Security can help, not hinder. By building security into your platform, you help developers work faster and safer. Security becomes a feature, not an obstacle.

Security completes the platform foundation we’ve built in previous articles on Provisioning, Self-Service, and Developer Experience, creating a platform that speeds up development.

But developers still need to see what’s happening in their systems. Next time, we’ll explore how Observability helps developers spot and fix problems quickly.

Why Choose Pulumi Cloud Over DIY Backends?

Aaron Kao — Wed, 19 Mar 2025 09:00:00 -0700

Note: This post discusses Pulumi Copilot, which Pulumi Neo has replaced. Learn about Neo →

Pulumi Cloud empowers engineers to automate, secure, and manage modern infrastructure platforms.

Many companies are building internal developer platforms or modern infrastructure platforms to provide developer self-service while maintaining security and compliance. Companies adopt Pulumi IaC so they can apply software engineering practices to their infrastructure scaling problems and because it is fully open source with a strong community and public roadmap.

At Pulumi, we’re committed to open source—always have been; always will be. Pulumi IaC is entirely open source (Apache 2.0 license), meaning you can adopt and extend it however you like. If you’re new to Pulumi, the open source edition is an excellent way to start modernizing your infrastructure. But as your organization grows and the complexity of your environment increases, you may find yourself devoting significant time to rolling your own enterprise IaC backend features.

That’s why we built Pulumi Cloud—to help you avoid building and maintaining these capabilities from scratch while ensuring you can automate, secure, and manage your infrastructure at scale. Pulumi Cloud provides enterprise capabilities that make it easier to build modern infrastructure platforms. Companies receive increasing value from Pulumi Cloud as their organization and their infrastructure platforms grow in size and complexity.

As companies expand or platform engineering mandates become more expansive, challenges arise around collaboration, security, governance, and scaling. Some questions that need answering include:

How do teams collaborate?
How do you securely manage infrastructure state?
How do you enable self-service infrastructure?
How do you adhere to IT security standards?
How do you enforce governance policies?
How do you protect sensitive data?
How do you enforce least privileged access across the organization?
How do you maintain uptime or get support for your architecture?
How do you manage the cost and complexity of multi-cloud environments?

If some of these questions apply to you or your team, learn more about Pulumi Cloud below to understand when it makes sense to transition to a paid Pulumi offering.

What drives the most value in Pulumi Cloud?

The most frequent business values that our existing customers experience with Pulumi Cloud relate to speed, scale, security, and savings.

Speed

There are speed benefits that customers typically experience across three areas: the infrastructure platform, developer productivity, and operations. Pulumi Cloud simplifies building and running complex infrastructure automation workflows through the Automation API. It also makes it easy to componentize best practices that can be easily shared and distributed through a centralized repository.

Pulumi Cloud streamlines the software delivery pipeline with Pulumi Deployments and a wide range of 3rd party CI/CD integrations.

Pulumi Cloud provides Pulumi Insights, offering search, analytics, and AI-driven insights over your infrastructure. With Insights, you can instantly search for critical information - such as finding MySQL databases on end-of-life versions across all your cloud assets, reducing the operational time it takes to find needles in haystacks.

Scale

Part of building an infrastructure platform is so your organization can scale and make it easy to onboard new developers. Pulumi Cloud integrates seamlessly with various identity providers like Azure ActiveDirectory, Okta, G Suite, or any SAML/SSO provider, offering deep support for role-based access control (RBAC) and SCIM for automatic synchronization and revocation of access based on identity provider groups. Audit logs keep track of developer activity within an organization, recording what actions were taken, when, and by whom.

Pulumi Cloud also makes it easy to build developer portals for developer self-service. Organization Templates can provide a centralized repository for cloud components, best practices and configurations. The New Project Wizard also provides a gallery interface to pick a template and easily walk through configuration and deployment of the infrastructure.

Security

Another reason your organization is investing in an infrastructure platform is so that security and compliance can be automated as infrastructure is self-serviced. Your platform must prevent infrastructure deployments that violate security, reliability, cost, or compliance policies. Pulumi Cloud, through Pulumi CrossGuard, provides out-of-the-box support for common security and compliance policies, ensuring PCIDSS, ISO27001, SOC2, and CIS compliance for cloud applications and infrastructure.

For applications being built across the organization, securing sensitive information like database passwords, cloud credentials, and API keys is paramount. Secrets can inadvertently end up in insecurely stored state files, leading to potential breaches. Pulumi Cloud, however, encrypts all data in transit and at rest, utilizing hardware security module (HSM) based encryption. Read the Pulumi Cloud Security Whitepaper for more information.

Pulumi Cloud further enhances security with Pulumi ESC, a centralized secrets management and orchestration service. This service pulls and syncs secrets from various stores like HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, and 1Password, making it easy to adopt dynamic, short-lived secrets on demand. Secrets can be accessed via CLI, API, Kubernetes operator, the Pulumi Cloud UI, and in-code with TypeScript/JavaScript, Python, and Go SDKs. Pulumi ESC leverages the same identity, RBAC, Teams, SAML/SCIM, OIDC, and scoped access tokens used by Pulumi IaC, ensuring that secrets management complies with enterprise security policies.

Savings

Building a platform and managing cloud infrastructure demands considerable time and energy. As discussed above, Pulumi Insights X-Rays your entire cloud footprint, so you can observe, plan, and drive changes across your infrastructure. With this total visibility, Pulumi Insights helps you reduce waste by showing you usage information and identifying potentially stale infrastructure, which can lead to substantial cost savings.

You can also have a conversation with Pulumi Copilot about your infrastructure in natural language and get answers to operational questions that would take hours to piece together from other sources.

Why not build your own enterprise features on top of Pulumi IaC open source?

Build vs buy is a question of opportunity cost. Should you and your team build and operate your own enterprise backend service that engineers at Pulumi have already built to handle the needs and scale of the world’s biggest companies? Or is their time better spent focused on building a modern infrastructure platform that will increase development velocity across the company and drive business growth?

Maintenance costs

When you build and operate your own enterprise backend, you’ll need to dedicate one full-time engineer for every team of ten - that’s nearly 10% of your engineering expense. Running a backend requires maintenance, updates, and troubleshooting. Outages and incidents can lead to significant financial losses. Pulumi Cloud, as a fully managed service, frees up your team’s time from the operational and maintenance burdens of managing an IaC backend.

Operational reliability and availability

One of the primary functions of the enterprise backend is managing state. State management involves managing concurrency controls, preventing state corruption, ensuring backup and recovery, maintaining high availability of the state service, and providing consistent visibility across all managed resources; this is easy to get wrong. Manual human intervention is frequently required to recover and repair state files, a process that is time-consuming, can create or prolong outages, and carries significant risk.

Security and compliance

Building your own enterprise backend also requires you to design and manage the service to adhere to numerous IT security standards, including SOC 1/SSAE 16/ISAE 3402, SOC 2, SOC 3, FISMA, FedRAMP, DOD SRG Levels 2 and 4, PCI DSS Level 1, EU Model Clauses, ISO 9001 / ISO 27001 / ISO 27017 / ISO 27018, ITAR, IRAP, FIPS 140-2, MLPS Level 3, and MTCS. This involves a manual assessment and validation process for each standard, which can be time-consuming and complex.

Customer support

You will also be giving up 12x5 or 24x7 customer support, which helps ensure your organization receives immediate assistance with any architectural, cloud-related, or Pulumi best-practices issues. Pulumi also has an experienced group of Solutions Architects and Customer Success Architects that have experience scaling infrastructure as code and building modern infrastructure platforms.

Conclusion

Pulumi Cloud is an enterprise-ready solution that comes with less risk and less maintenance costs than the DIY approach. With Pulumi Cloud, you get a fully managed service that automates deployments, ensures compliance, and offers comprehensive security features out-of-the-box. You’ll get a clear understanding of the product roadmap as well as talented engineers supporting your architecture and use cases.

Pulumi Cloud gives you the platform to automate, secure, and manage your modern infrastructure platform so your company can choose to focus on innovation and growth.

Try Pulumi Cloud for free and see how it can accelerate your infrastructure automation. Sign up today and start building with Pulumi Cloud.

Improve Developer Experience: Increase Dev Productivity with Internal Developer Platforms

Adam Gordon Bell — Thu, 13 Mar 2025 00:00:00 +0000

In the last article in this Platform Engineering Pillars series, we explored how self-service infrastructure frees developers from bottlenecks and dependency gates. By providing reusable infrastructure modules and intent-based configurations, platform teams dramatically reduce infrastructure friction. This self-service model powers faster deployments, increased autonomy, and fewer delays.

However, infrastructure provisioning alone isn’t enough to improve developer experience. Even with efficient provisioning, developers can still face inconsistent local setups, sluggish CI/CD pipelines, poor documentation, and fragmented tooling. These obstacles quietly reduce developer productivity, slow developer velocity, and increase operational overhead.

Your platform’s ability to support daily workflows directly impacts core success metrics like time to first commit, time to production, and developer satisfaction.

When improving developer experience as part of a platform engineering initiative, measure:

Time to First Commit – How quickly a developer can become productive in a new environment or project. Pay particular attention to new hires.
Time to Production – How fast code moves from commit to successful production release.
Developer Satisfaction – Regularly survey friction points and prioritize fixing the top issues.

Friction logs are also a powerful way to identify roadblocks, recording every obstacle encountered during common workflows. This reveals hidden friction and provides a roadmap for improvement.

A great developer experience accelerates iteration, improves problem-solving, and drives better products. An internal developer platform (IDP) designed for DevEx is a fundamental competitive advantage.

The Service Catalog: Foundation for Developer Experience

Developer friction often starts with something simple: not knowing what’s already available or who owns it. Without a single, reliable source of truth, developers reinvent the wheel, duplicate work, and waste time chasing information.

A well-structured service catalog in your internal developer platform addresses this by providing a central repository for all services and applications. At its most basic, it’s just a web page with each service’s README, service metadata, and operational information.

But, properly structured, this delivers some large benefits:

Context at a Glance: Every catalog entry follows a standardized template, capturing core information such as purpose, interfaces (REST, gRPC, events, etc.), language/runtime, and environment requirements. New developers can quickly grasp a service’s role and easily jump into productive work.
Discoverability and Reuse: Without a catalog, teams often recreate services they don’t realize already exist. Duplicate services not only waste resources but lead to fragmented knowledge and inconsistencies. With a catalog, developers quickly find and leverage existing solutions, increasing reusability and reducing churn.
Ownership Transparency: Each entry in the catalog explicitly names team ownership, CODEOWNERS files, and pertinent contact details like Slack channels or on-call rotations. Clear ownership streamlines communication, issue resolution, and collaboration, saving precious time and avoiding frustrations.

A service catalog supports autonomy, reduces wasted cycles, and increases developer velocity by making essential information instantly accessible.

But a Service Catalog alone isn’t enough. To fully streamline and enhance your development workflow, you must pair it with consistent local environments and reliable CI/CD processes. Both of which can be serviced by standardized service templates.

Service Templates: Golden Paths for Improving Developer Productivity

Earlier in this series, we introduced service templates as a way to scaffold consistent, ready-to-go services. In an internal developer platform, templates aren’t just for infrastructure, they’re the golden paths that define how developers start and succeed.

If 90% of new services are Go GRPC services, then a carefully crafted, opinionated go GRPC service blueprint will remove a lot of friction. It will give developers everything they need to begin delivering real business value immediately. A few select curated options of common starting points will help guide developers to generate projects complete with standardized structure, built-in quality checks, documentation, and clear guidelines for contribution.

A great service template provides:

Project Bootstrapping

The template quickly scaffolds an entire service—including all necessary files and directories. Everything essential for your organization’s standards should be included, from CI/CD configurations and dependency management to directory structures and environment-specific configuration files.

Built-in Quality Tools

Templates embed guardrails that maintain consistency and high-quality standards across teams:

Linting rules and formatters: Tools like ESLint, flake8, or Checkstyle that ensure code style and consistency across your codebase.
Testing frameworks: Unit tests, integration tests, and contract testing tools set up and pre-configured (JUnit, pytest, Jest, Pact), helping teams maintain high quality right out of the gate.

Documentation and Contribution Guides

Many platform teams overlook how clear, consistent documentation is crucial for initial and ongoing developer productivity. Every new service should arrive out-of-the-box with:

README: Describing at a glance what the project does, why it exists, and how to run it.
Documentation: Service template establishes a place for service-specific documentation that will be surfaced in the Service catalog. Markdown explanations, example input/output, and real-world use-cases.
Contribution guidelines and coding standards: Clearly documenting the expectations, conventions, and standards every developer can follow with confidence.

Embedding this documentation into templates ensures that even brand-new services are discoverable, understandable, and maintainable — right from their first commit.

A great template means the service catalog becomes more than just an organizational listing. These thoughtfully designed templates can directly power it. Every new service entering your catalog aligns neatly with your organization’s best practices in code quality, documentation, and process standards.

When paired with your service catalog, templates ensure every new service aligns with best practices — boosting developer productivity and developer velocity from day one.

Streamlining Local Development to Reduce Friction

One of the fastest ways to improve time to first commit is to standardize local development workflows through your internal developer platform.

Your service templates provide the ideal mechanism for simplifying how quickly developers can get projects running locally. By embedding standardized local-development tooling into these templates, you ensure they’re available consistently across your service catalog. Good templates typically contain:

A preconfigured, containerized environments: Using Dev Containers, Docker Compose, or similar tools lets developers launch an environment that closely resembles production with minimal friction, completely avoiding dependency drift or local environment inconsistencies.
Simple, standardized command runner: Makefiles, just scripts, package.json scripts—whatever works as they’re consistently documented and easy to run commands such as make build, make test, or make lint. Teams might diverge on preferred tooling over time; if so, simply record clearly in the project’s readme (and thus in your service catalog) exactly what’s needed.
Built-in documentation: Each service template includes clear instructions in a README outlining step-by-step processes for setup, running tests, and other everyday developer tasks.

With these pieces fully integrated into your catalog and templates, you significantly reduce friction and speed up development cycles, moving you meaningfully closer to improving your core developer-experience metrics.

The next critical area we need to address is how smoothly and quickly code moves from a local commit to a production release.

CI/CD Integration: Fast, Reliable Pipelines for Experienced Developers

Experienced developers cite unreliable or slow pipelines as major productivity killers. Their frustrations often revolve around flaky builds, unreliable tests, and cumbersome environment setups. Slow or unpredictable pipelines break developer flow, causing frustration, delays, and lower productivity.

A strong internal developer platform integrates fast, stable, and predictable CI/CD processes:

Stable, Fast Feedback:
Every new service comes pre-configured with build acceleration strategies like intelligent caching (Gradle, Bazel, Docker layers) and automatic parallel test execution. Stable and speedy pipelines help teams iterate quickly and confidently.
Ephemeral, Self-service Environments:
Instead of battling shared staging environments – which get blocked by other teams— developers spin up short-lived testing environments directly from pull requests. Need to test your payment-service changes against the latest user-authentication service? Create a dedicated, temporary environment on-the-fly, validate interactions, then shut it down automatically when finished.
Test Reliability:
Strictly enforce policies to quarantine flaky tests, quickly escalate notifications to responsible developers, and provide clear paths for fixing instabilities. Proactive flakiness management ensures credibility and reliability for test pipelines over time.

Reliable CI/CD pipelines protect developer focus, reduce cognitive load, maintain developer velocity, and prevent wasted time, increasing developer productivity.

Developer experience is a vast, nuanced topic, and there’s much more a comprehensive platform can include than we’ve been able to explore fully here. Even just within your Service Catalog and developer workflows, valuable additions might include:

Onboarding Guides: Step-by-step guides rapidly bringing new developers up to speed on teams, tools, and processes.
Frictionless Product Backlog Integration: Quick access from codebases to the product backlog to connect code directly with the business context.
Code Coverage & Quality Dashboards: Easy-to-use visualizations offering fast insights into quality metrics and test coverage.
Deprecation Notices & Change Management: Automated notifications about changes, upcoming maintenance, or decommission plans to keep developers informed and prepared.
Pre-built Common Components: Shared libraries and components solving everyday needs like logging, authentication, validation, and configuration.

And that’s truly just scratching the surface. But remember: Platform engineering is an iterative journey, you don’t need to tackle every single area all at once. If you start with friction logs and surveys to regularly identify and address pain points affecting daily workflows, you’ll already be heading confidently in the right direction.

Conclusion: IDPs as a DevEx Multiplier

A great developer experience is not optional — it’s a force multiplier for developer productivity and developer velocity. An internal developer platform with service catalogs, golden path templates, streamlined local dev, and integrated CI/CD removes friction at every step of the developer journey.

The result? Faster onboarding, quicker delivery, and happier teams.

With Pulumi, platform teams can automate consistent environments, implement golden paths, and enable self-service infrastructure that scales with your organization.

Organization Templates enables standardized service creation and consistent developer experiences
Stack References for managing dependencies between environments and services
Pulumi Deployments to streamline CI/CD workflows and enable self-service infrastructure
Review Stacks for creating ephemeral, on-demand testing environments
Automation API for programmatically managing infrastructure and implementing platform workflows

By prioritizing developer experience in your platform engineering strategy, you empower teams to move faster, build better, and maintain momentum, making your internal developer platform one of the most valuable assets in your organization.

Self-Service Infrastructure: From Tickets to Tools

Adam Gordon Bell — Thu, 06 Mar 2025 00:00:00 +0000

Previous articles in this series explored platform engineering principles and how Infrastructure as Code creates a solid foundation. But there’s still an important challenge to address: the infrastructure provisioning process itself. Without proper modularity and a clear separation between intent and infrastructure details, things get messy—leading to friction, delays, and unnecessary complexity.

The Missing Layer: Abstraction Through Modularity

The root issue here is how teams define and work with infrastructure. Without good abstraction layers, infrastructure code typically becomes unwieldy and complex.

You end up with

Highly detailed specifications that require deep domain knowledge
Environment-specific configurations with subtle variations across resources
Complex interdependencies that are difficult to trace and verify

This approach burdens developers with low-level details they don’t need to worry about, while platform teams become gatekeepers, reviewing intricate configurations. Alternatively, a traditional ticketing model takes over, discarding the benefits of modern practices.

Solution: A Platform Engineering Approach

What’s missing is a proper abstraction layer between raw infrastructure code and developer needs. That layer is the platform. A Platform for self-service infrastructure. Without modular, reusable infrastructure patterns, every new application deployment becomes an exercise in starting from scratch and defining every detail instead of just stating what the application requires and deferring details to the platform.

Common Anti-Patterns Without Proper Abstraction

Without this modular platform approach to cloud infrastructure, organizations typically fall into one of two problematic patterns.

The Copy-Paste Anti-Pattern

Developers copy infrastructure code from previous projects. They find something similar, duplicate large chunks of configuration, make a few changes, and hope everything is right, and submit it for review. This leads to a brittle system with siloed knowledge. Security fixes must be applied manually across every instance – no one has a full picture of the infrastructure – and Day 2 Operations become error prone.

And this isn’t limited to infrastructure: CI scripts get copied and modified, Dockerfiles and Kubernetes manifests get copied and modified.

It feels like control, but it’s not. Developers still rely on platform specialists to validate changes and catch mistakes.

The Ticketing Anti-Pattern

Alternatively, some organizations rely on rigid ticketing systems for infrastructure changes. A platform specialist applies writes and applies all changes, ensuring consistency — but also creating bottlenecks. Developers might wait days or weeks for simple modifications, leaving the process entirely unfinished.

This guarantees expert oversight but strips developers of autonomy, making the platform team a bottleneck for every deployment.

Neither anti-pattern strikes a balance between standardization and autonomy, leading to either sloppy infrastructure (copy-paste) or slow deployments (ticketing).

The Resulting Problems

Day 1 Bottleneck: Slow, Manual Infrastructure = Developer Gridlock

When provisioning becomes a bottleneck, developers with finished code wait days for infrastructure. This disrupts focus and forces frequent context switching. They juggle tasks to stay productive and then have to rebuild focus when the requested infrastructure is ready.

These delays slow the entire delivery pipeline. Teams add buffer time for infrastructure delays, projects slip, and the business sees technology as slow-moving. Meanwhile, the real culprit is slow provisioning that kills momentum.

Day 2 And Beyond Chaos: Sprawling, Unpredictable Infrastructure = Operational Nightmare

Day 1 bottlenecks frustrate developers, but the real long-term cost is patching hell. Copy-paste infrastructure creates hundreds of snowflakes, each needing manual attention for every security fix or version bump. One-off configurations and custom environments pile up, creating technical debt no one fully understands.

Operations teams are overwhelmed by the basic, critical task of simply keeping the lights on across a sprawling, inconsistent landscape.

The Solution: A Platform of Options and Self Service

A Self-service platform is the solution to these problems. The platform is this curated list of modules, providing application developers with a set of pre-built options that let them work at a higher level of abstraction. By choosing from these modules, developers express their intent for infrastructure, leaving the platform to handle the implementation details. Let me explain.

A strong self-service approach divides responsibilities into two clear layers:

Level 1: Platform Team (Module Definition)

Builds and updates reusable infrastructure modules
Bakes in security, compliance, and best practices
Hides complexity so developers don’t need to worry about copy and pasting low-level details
Sets guardrails for scalability, security, and compliance
Updates modules as technologies and needs change

Level 2: Application Developers (Module Consumption)

Browse a catalog of ready-made modules
Compose pre-built modules to set up application infrastructure
Spend time on code, not cloud configurations
Operate within built-in guardrails
Deploy applications faster using standardized components

This setup keeps things fast and flexible. Developers get the autonomy to build without reinventing infrastructure, while platform teams maintain control where it matters.

The Power of Intent-Based Specification

Layer of Abstraction to the Rescue

The two-level approach works by replacing over-specification with intent-based design.

Over-specification happens when developers specify too many infrastructure details that:

Require expertise they might not have
Tightly coupled infrastructure to specific implementations
Make future changes hard or even impossible

Intent-based specification means developers state what their app needs, not how to implement it, meaning:

Platform teams can update underlying infrastructure without breaking applications
New capabilities can be added without disrupting existing applications

Focusing on what developers need, not how it’s built, creates a system that’s easier to maintain and evolve for both platform teams and developers.

Let’s walk through an example.

Practical Example: Java Application with Kafka, PostgreSQL, and Redis

The platform team provides reusable modules:

Java Application Module

This module handles everything needed to run a Java app. It covers the Java runtime, memory settings, JVM options, scaling rules, health checks, monitoring, and Kubernetes namespacing. It also manages containers, security scans, resource limits, and logging integration—so developers don’t have to.

Kafka Integration Module

Similarly, this module simplifies Kafka integration, handling broker connections, authentication, topics, and security. It takes care of SASL/SSL authentication, replication factors, ACLs, and encryption. Developers just specify topics and schemas.

And so on for common infrastructure components used in the org.

Level 2: Developer Implementation

Developers use a simpler interface. To deploy a new Java service with Kafka, PostgreSQL, and Redis, they only need to specify the required input parameters in the platform-defined modules:

# Developer's intent-based configuration
application:
 name: order-processing-service
 module: java-application
 version: 17
 memory: 2GB
 scaling:
 min: 2
 max: 10

integrations:
 - module: kafka
 topics:
 - name: incoming-orders
 partitions: 5
 - name: processed-orders
 partitions: 3
 consumer_group: order-processors

 - module: postgresql
 database: orders_db
 size: medium
 backup: enabled

 - module: redis
 size: small
 ttl: 3600

( Note: YAML not required. This pseudo-code could be UI driven, or it could be written in your programming language of choice. The point is it specifies intent and defers specifics to the platform. )

Solving Day 1 and Day 2 Challenges

The intent-based specification solves immediate and long-term problems:

The Self-Service Transformation in Action:

Developer Experience	Platform Response
Submits simple intent-based configuration	Expands into complete infrastructure
Focuses on application needs, not infrastructure details	Provisions resources with appropriate sizing and security controls
Specifies “what” is needed, not “how” to configure it	Handles networking, monitoring, backups, and credentials
Limited expertise required in Kubernetes, networking, or security	Implements best practices automatically across all deployments
	Maintains and updates the underlying implementation over time

This approach transforms infrastructure from a developer burden into an organizational asset that becomes more valuable over time, rather than decaying into technical debt.

Developer Interaction Models: Choosing Your Platform Interface

Hopefully, now you are bought in on the value of separate layers of abstraction and building a platform to expose those.

The next key decision is how developers will actually use this platform. The ideal interface balances ease of use with the necessary flexibility. Organizations and requirements vary, so a spectrum of interaction models exists, each with its own trade-offs. Tree common approaches are: CLI-Driven Infrastructure as Code, the Self-Service Portal, and a Hybrid model.

Aspect	CLI-Driven	Self-Service Portal	Hybrid Approach
Developer Experience	Code-based, using IaC modules and components directly	Click-based UI with forms and catalogs	Portal for common tasks, code for customization
Code Visibility	Full visibility and control	Limited or no visibility	Visible but with varying levels of access
Governance	Trust-based or PR reviews	Enforced through portal constraints	Guided paths with managed exceptions
Learning Curve	Higher (requires IaC knowledge)	Lower (minimal infrastructure knowledge)	Moderate (basic UI with optional advanced use)
Best For	Experienced teams needing flexibility	Teams prioritizing speed and standardization	Organizations with diverse skill levels

1. CLI-Driven Infrastructure as Code: Empowering Developers with Familiar Tools

In this approach, platform teams build reusable infrastructure modules while developers consume them directly through code. Developers use familiar IaC tools like Pulumi CLI to instantiate these modules, with changes flowing through version control like any other code.

The key strength is transparency and familiarity. Developers maintain visibility and ownership of their intent-based definitions. This code-centric workflow integrates naturally with existing development practices.

However, this flexibility creates governance challenges and requires either strong trust or approval processes that might reintroduce bottlenecks. The approach also assumes developers have some IaC knowledge, making it best suited for organizations with mature DevOps practices and experienced teams.

2. Self-Service Portal: Click-Ops Simplicity for Rapid Provisioning

The self-service portal approach creates a web interface where developers provision infrastructure without writing code. They simply browse a catalog, fill out forms, and click buttons to deploy standardized resources—all pre-configured by the platform team.

This approach keeps infrastructure code completely centralized and hidden from developers. The portal translates simple selections (“Add Database: Medium Size”) into the appropriate underlying configurations, ensuring perfect compliance with organizational standards.

The result is dramatically reduced friction and learning curve, enabling even infrastructure novices to deploy resources in minutes. However, this simplicity comes at the cost of flexibility. Customizations and unique needs typically require platform team involvement, making this model ideal for organizations with predictable workloads or where standardization outweighs customization needs.

3. Hybrid Approach: Code-Backed Self-Service

The hybrid approach generates and modifies infrastructure code via pull requests from UI interactions. When developers configure resources through the portal, the system commits code to repositories automatically, creating a transparent workflow where changes are visible, reviewable, and auditable through standard Git processes.

This model provides both simplicity and flexibility. Routine tasks remain point-and-click while complex scenarios allow direct code editing within the same PR workflow. The approach maintains a complete audit trail through commit history while giving platform teams visibility into all changes.

A significant tradeoff is implementation complexity: building a system that generates commits and PRs based on version control integration requires substantial investment. Organizations must weigh this upfront cost against the long-term benefits of combining UI simplicity with code transparency.

Lifecycle Management

More effective lifecycle management is an advantage of a platform approach. Consider migrating from Kafka to AWS Kinesis. Traditionally, this would involve significant application developer effort, including updating connection details, authentication, and application logic. However, with the two-level abstraction and intent-based approach described earlier, this migration becomes simpler. Platform teams introduce a new Kinesis module matching the existing Kafka module’s intent-based interface. Data is mirrored, and developers can plan a switchover. Migration will not be free, but efforts and coordination will be reduced.

Life-Cycle management is a huge topic in Day 2 operations and outside the scope of what can be covered here, but introducing abstractions and a platform of modules will pay off long term.

Looking Ahead: Operational Excellence and Beyond

The two-level abstraction model does not just simplify provisioning. It also lays a strong foundation for operational excellence. By standardizing infrastructure through reusable modules and intent-based specifications, we create consistency and visibility that significantly simplify critical operational concerns such as:

Drift Detection and Reconciliation: Standardized modules make it easier to detect and correct deviations from desired state.
Continuous Compliance and Security: Centralized module definitions allow security and compliance controls to be consistently enforced and audited.
Cost Management and FinOps: Intent-based specifications enable clearer cost attribution and optimization opportunities.
Observability and Incident Response: Consistent infrastructure patterns simplify monitoring, alerting, and troubleshooting.

Later articles in this series will explore each of these areas in greater depth, demonstrating how a platform approach provides a powerful foundation for addressing them effectively.

Self-Service with Pulumi

The two-level architecture of IDP self-service creates a powerful interface between platform teams and application developers. By embracing intent-based specification, this approach enables developers to clearly express what they need with minimal complexity while giving platform teams the flexibility to implement and evolve the underlying infrastructure.

As you build out your self-service approach, consider how Pulumi might fit in. With Pulumi, you get:

Component resources for creating reusable infrastructure modules that encapsulate best practices.
Organization templates for building a catalog of infrastructure templates.
Packages in your language of choice for a code-first self-service workflow.
A Platform-in-the-box experience for those who want a portal-first experience for self-service infrastructure.
A Backstage plugin for those who prefer to use Backstage for an IDP.

A great self-service workflow and abstraction layer are key to making platform engineering work. Next in this series, we’ll tackle developer experience directly.

Provisioning: From Chaos to Control

Adam Gordon Bell — Thu, 27 Feb 2025 00:00:00 +0000

Provisioning is the first pillar of platform engineering. Without consistent infrastructure provisioning – the automated creation and management of the underlying cloud resources – the rest of the platform suffers. Self-service, governance, and streamlined developer workflows all depend on it. Ultimately, a self-service layer on top of your cloud infrastructure is the goal, enabling developers to quickly and safely provision the resources they need, while adhering to organizational best practices and policies. But before self-service, the foundation of a good IDP is a robust and reliable provisioning system.

By defining cloud resources as code and automating deployments, platform engineering teams ensure every environment – development, staging, and production – stays consistent and maintainable. This cuts down on configuration drift, reduces manual work, and supports auditable, collaborative workflows for every change.

Let’s explore how platform engineering teams can achieve this by version-controlling infrastructure, automating deployments, separating environments properly, and limiting console interventions. By applying these principles, teams can create a platform where developers can move fast without breaking things, and where infrastructure supports innovation rather than slowing it down.

Top 5 IaC anti-patterns

Console-Only Changes: Making “quick fixes” in production without updating IaC leads to drift, confusion, and hidden risks.
Hard-Coded Secrets: Sensitive values in code or config files are a security liability. Use encrypted state or a secrets manager.
Copy-Paste Config: Reusing half-baked snippets across projects creates cruft. Break out shared modules or templates.
No Clear File Structure: Throwing all configs into a single file or folder obscures dependencies. Organize by environment, service, or module.
Skipping Peer Reviews: Infrastructure mistakes can be costly. A simple pull request process can catch errors before deployment.

💡 Tip: Read our list of IaC Best Practices 💡

Building a reliable IaC foundation

It’s not enough to simply define your resources in code. A reliable IaC foundation should ensure that infrastructure changes move smoothly from idea to production, without surprising developers or straining operations. Here’s how to structure these workflows so they’re both transparent and resilient:

Version control as the single source of truth

Whether you’re using GitHub, GitLab, or something else, every infrastructure definition needs to live in version control. This is just the basics – and hopefully, you are already doing this, as you have been for years. Version-controlled changes allow you to track history, compare revisions, and peer review. A pull request might catch a misconfigured subnet or a database that was accidentally left publicly accessible, mistakes that could be catastrophic if they slip into production. This also means anyone can propose improvements or bug fixes, expanding the pool of expertise beyond a single “infrastructure guru.”

Automating changes with CI/CD

Next, consider how to apply infrastructure modifications after they’re merged into main. A CI pipeline can automatically run a “plan” or “preview,” then only proceed with the actual update if no blockers appear. Policy checks can also be added, enforcing rules such as “no public S3 buckets” or “use encrypted volumes only.” By codifying these conditions, you avoid manual verification steps and reduce the chance of risky configurations slipping past manual review.

Trunk-based infrastructure workflow

Protected main Branch: No direct commits
Pull Request Merges: Integrate changes via Pull Requests
Automated PR Checks: Previews and Policy-as-Code run on every PR
Merge: Merge to main triggers automated deployments

Distinguish each environment

Not all environments have the same requirements or budgets, so it’s wise to separate dev, staging, and production configurations. You might share core modules across these environments, but keep each environment’s parameters and secrets in independent config files or stack definitions. This deliberate separation ensures that dev changes are tested in a realistic but contained environment before they can impact production. As a result, teams can experiment more confidently without risking live workloads.

Modularity and reusability

A key principle of effective IaC, and a cornerstone of any good Internal Developer Platform, is reusability. You shouldn’t be copying and pasting large chunks of infrastructure code. Instead, you should build reusable components (or modules, or constructs, depending on the tool’s terminology) that encapsulate best practices and can be easily consumed by developers. This achieves several critical goals:

Consistency: Ensures that similar resources are provisioned in the same way, reducing configuration drift.
Abstraction: Hides complexity from developers. They don’t need to know how a secure, compliant database is created, just that it is.
Maintainability: Changes to the underlying implementation of a component can be rolled out to all consumers of that component.
Speed: Developers can provision infrastructure faster by using pre-built components.
Reduced Errors: Standard components means that there will be less opportunities to make mistakes.

Think of these reusable components as the “building blocks” of your IDP. Your platform team creates and maintains them, and developers use them to assemble their applications.

Regardless of the specific IaC tool you choose, reusable components generally share these characteristics:

Parameterized Inputs: Components accept inputs (parameters, properties, configuration – the term varies) that allow users to customize their behavior. For example, a “database” component might accept a database_size parameter.
Defined Outputs: Components expose outputs that other parts of the infrastructure can consume. For example, a “database” component might output the database’s connection string.
Encapsulation: The internal implementation details of the component are hidden from the consumer. The consumer interacts with a well-defined interface (inputs and outputs).
Versioned: Components should be versioned (e.g., using semantic versioning) to allow for controlled updates and rollbacks.
Discoverable: Components should be easily discoverable by developers, often through a central catalog or registry.

Example: An IAM roles component

IAM roles are one of the most commonly misconfigured AWS resources, making them a perfect candidate for abstraction into a reusable component. Developers frequently make mistakes when setting up roles, leading to overly permissive access, broken permissions, or operational headaches.

Common IAM role mistakes

Overly Broad Permissions – Developers often grant * permissions instead of following the principle of least privilege.
Missing Assume Role Policies – Without a proper trust policy, services may not be able to use the role at all.
Directly Attaching Policies to Users – Instead of assigning roles to groups, users might manually attach policies, leading to hard-to-audit permission structures.
Lack of Naming Conventions & Tagging – Unstructured role names and missing tags make governance difficult.

How a reusable IAM module fixes this

A platform team can provide a self-service IAM role module that enforces best practices while still allowing customization. This module would:

✅ Require a Least Privilege Policy – The module only allows explicitly defined permissions, preventing wildcards.
✅ Auto-Generate Trust Policies – Ensures correct settings, reducing misconfigurations.
✅ Enforce Naming Standards & Tagging – Ensures roles are easily identifiable and trackable.

By using a reusable IAM role module, developers can self-service their permissions while the platform team ensures security, consistency, and maintainability. This removes a major source of security risk and operational overhead.

No console interventions

No matter how carefully IaC is managed, emergencies may occasionally necessitate direct console changes. However, such interventions are strictly forbidden except under an official “break glass” procedure. If a quick fix is applied in the cloud console, it’s critical that the change is immediately documented and returned to code. Regular drift detection can help with this: once a day or once a week, automated scans can compare actual cloud resources to your declared infrastructure. When it detects a mismatch, you decide whether the code or the running resource is the correct version. Either way, human “hotfixes” never linger as hidden surprises for long.

By combining version control, automation pipelines, environment-based configs, and drift checks, you build a solid provisioning foundation. Once you have that in place, the next step is making these patterns easy to use, so teams can start new services without reinventing the wheel.

But first, let’s cover some metrics and roadblocks.

Metrics that matter

The classic DORA metrics focus on software delivery. Adapting and modifying them for infrastructure provisioning can help measure how effectively your platform delivers reliable, self-service cloud resources:

Lead Time for Infrastructure Changes: How fast does a merged PR turn into running infrastructure? Shorter indicates efficient automation and fewer manual steps.
Infrastructure Drift Frequency: Are developers constantly making console tweaks, or does your infrastructure stay in sync with code? A low drift rate means your code and actual resources stay aligned.
Infrastructure Change Failure Rate: What percentage of infrastructure changes result in incidents or rollbacks? A low failure rate indicates a robust, well-tested infrastructure pipeline, reducing wasted effort and potential outages.
Platform Self-Service Rate: What percentage of provisioning changes are implemented by the requesting team (without needing to involve a central operations team)? A high self-service rate shows that your platform empowers developers and reduces bottlenecks.

Common roadblocks

Adopting Infrastructure as Code helps teams automate provisioning, but common pitfalls can slow progress before they see results. Left unaddressed, problems hidden configuration tweaks, scattered code, or reliance on a single “infrastructure hero” make it hard to keep environments consistent and secure.

By spotting these roadblocks early, teams can build a stronger foundation for a repeatable, collaborative IaC workflow.

Knowledge silos: Relying on just one person (“Go ask Sarah”) for all infrastructure tasks creates a risky bottleneck. The broader team can’t replicate or improve the process, slowing new initiatives and leaving you vulnerable if that individual is out of office or leaves the company. Moving to a collaborative, version-controlled IaC model ensures that no single engineer is a gatekeeper for new environments or configuration changes.
Overly complex or unstructured IaC: Bloated or disorganized infrastructure code leads to confusion, duplication, and frequent errors. Engineers might copy-paste configurations from previous projects or cram all resources into a single file. By refactoring IaC into smaller modules, adopting a clear folder structure, and removing dead code, teams gain consistency and accelerate ramp-up times for new services.
Learning curves: Teams new to IaC often encounter a steep learning curve. There is initially a lot to learn, and resistance from people used to quickly working through cloud UI can slow down full adoption. But time invested in learning tools and setting cultural norms pay off in agility and a platform strategy with guidance and golden paths can help reduce the burden.
Cultural inertia: The adoption of a platform engineering approach is a shift in how organizations manage infrastructure, and like all, change is not merely technical but also organizational. Resistance to change and organizational inertia can make it difficult to implement new ways of getting work done. Expecting, understanding, and working through this resistance is key to overcoming it.
Lack of comprehensive approach: IaC tools are great for provisioning, but without a full platform approach, covering monitoring, logging, and the full life cycle of cloud resources, provisioning efforts may fall short. We will see in this series how the pillars of a comprehensive approach strengthen themselves.

These roadblocks highlight why a thoughtful, well-structured approach to provisioning is essential. But that’s not enough because the next step is to make these consistent patterns easily accessible so teams can spin up entire services without starting from scratch. And that’s where “golden path” templates come in.

Platform team provisioning responsibilities

Setting up the initial IaC foundation
Creating and maintaining templates
Automating workflows
Monitoring usage and compliance
Internal Platform Evangelism

Service templates

Even with a solid IaC foundation and reusable modules, spinning up a brand-new service can still require developers to understand how to pull in the underlying infrastructure components and how to use them. That’s where templates come in.

These are pre-vetted, ready-to-use blueprints that capture your organization’s best practices for a complete service or application, including infrastructure, application, and security components. They are the key to enabling true self-service.

Think of service templates as the next step up from the reusable components we discussed earlier. While a component might represent a single “building block” (like a secure S3 bucket or a database), a service template represents an entire structure built from those blocks (like a complete web application with a database, load balancer, and containerized application). They combine those building blocks with sensible default configurations and best practices for things like logging, Kubernetes setup, and security baked in.

Beyond bundling your organization’s best practices into a single repository, these service templates can also include a preconfigured CI/CD pipeline.

This means that when a team spins up a new service from the template, they inherit not just the infrastructure modules and best-practice configurations, but a fully operational CI/CD workflow. No extra setup is required. Developers get immediate feedback on their changes, and the merge to main triggers automatic deployments that keep every environment consistent.

Instead of cobbling together snippets from old repos, teams can scaffold out a service by simply selecting the template that fits their need – whether it’s a containerized web app, a serverless function, or a data-processing pipeline – and providing a few key parameters.

These curated paths cut onboarding time, reduce configuration missteps, and ensure that the IaC modules are used in new services. If developers don’t have to remember which tags to apply or how to route logs, or even where to import infrastructure modules from, they can focus on delivering features rather than wrestling with infrastructure details. And as your platform matures, and new versions of your modules are introduced, you can update these templates, automatically sharing improvements with every new project.

Bringing it all together: The impact of effective provisioning

With reusable modules and service templates in place, and a deployment workflow that takes changes from git commits all the way to your cloud account, your platform engineering team creates a foundation that transforms how developers interact with infrastructure. This transformation yields measurable benefits:

Lower Infrastructure Change Failure Rate: Automated validations and peer reviews catch issues early, reducing the number of failed deployments.
Increased Platform Self-Service Efficiency: Developers can provision resources in minutes instead of days, boosting productivity and reducing bottlenecks.
Reduced Lead Time for Infrastructure Changes: Streamlined automation shortens the time from code commit to deployed infrastructure.
Minimized Infrastructure Drift: Fewer manual console interventions mean your actual infrastructure stays aligned with what’s declared in code.

(In the upcoming article, we’ll dig deeper into how governance guards these golden paths, ensuring that new projects comply with security and corporate policies right from day one.)

Managing infrastructure provisioning with Pulumi

As you build out your platform engineering plan, consider how Pulumi might fit in. With Pulumi, you get:

Infrastructure as Code in the language of your choice.
Component resources for creating reusable infrastructure modules that encapsulate best practices.
Pulumi Deployments for a fully managed infrastructure deployment solution.
And a Platform in the box experience.

Reliable infrastructure provisioning is the cornerstone that supports your entire platform engineering initiative. By implementing the practices outlined in this article – version-controlled IaC, automated CI/CD workflows, environment separation, and golden-path templates – you establish a foundation that enables consistency, speed, and trust.

But provisioning alone isn’t enough. In upcoming articles, we’ll explore how policy-as-code and broader governance tie into this foundation, ensuring that all those newly created services meet security and compliance standards from the moment they’re deployed. But first, we’ll look at expanding the provisioning foundation covered here into a true self-service platform, so teams can quickly spin up services without risking the organizational chaos that often accompanies speed.

Provisioning is the foundation – next in this series we’ll build on it.

Platform Pillars: Build Platforms, Not Infrastructure

Adam Gordon Bell — Wed, 26 Feb 2025 00:00:00 +0000

Software drives innovation. Development teams face pressure to ship features faster. But speed collides with infrastructure complexity. Developers struggle with cloud setups, juggle scattered tools, and wait on operations teams for resources. The result is friction and slower innovation.

This is where Platform Engineering comes in. It helps developers move faster by creating tools that actually work. A good internal platform lets teams self-serve infrastructure, find documentation, follow best practices, and focus on what they do best: writing useful software.

Building a platform isn’t about finding one perfect tool. It’s about assembling the right pieces, or pillars. These pillars define what every successful internal developer platform needs.

This series explores these key pillars of Platform Engineering, offering a practical guide to building platforms that remove barriers to developer speed. Each pillar addresses a specific challenge organizations face when scaling developer productivity. The first challenge is overcoming infrastructure chaos.

Problem: Infrastructure chaos and bottlenecks

Developers face many pain points with manual provisioning, which is why Infrastructure as Code has become so essential:

Inconsistent environments: Dev, staging, and production drift apart. “Works on my machine” becomes everyone’s excuse.
Slow processes: Console clicking and waiting on ops creates bottlenecks. Developers wait days for basic infrastructure.
Configuration drift: Manual configs lead to errors. Quick production fixes become undocumented mysteries that cause problems later.
Lack of repeatability: Spinning up new environments or replicating existing ones is a complex, time-consuming, and often unreliable process.

That’s why provisioning is the first pillar to master if you want to build a successful developer platform.

Problem: Dependency bottlenecks and limited developer autonomy

Even with automated provisioning, another challenge emerges - developers still struggle when tools are provided without considering usability.

Hard to find what you need: Developers waste time hunting for the right infrastructure modules. They end up searching docs, bothering colleagues, or rebuilding something that already exists.
Too much complexity: Most developers aren’t infrastructure experts. Learning all the options and parameters creates hesitation and mistakes.
Lack of real autonomy: Developers have the tools but not the confidence to use them. They still need approvals or fear breaking production.
Inconsistent workflows: Teams create their own ways of using infrastructure, making collaboration harder.

By implementing self-service infrastructure provisioning, you transform your platform from a centrally controlled system to a developer-centric environment. You unlock developer autonomy, accelerate development cycles, and free up operations teams to focus on higher-value activities.

Problem: Inefficient and fragmented development processes

Infrastructure is just one piece of the puzzle. Developers still face daily friction moving code to production.

A typical developer’s day is full of frustrations:

Inconsistent local environments: Variations in local setups, dependency conflicts, and operating system differences lead to debugging headaches and wasted time getting started.
Slow CI/CD pipelines: Long builds, flaky tests, and mysterious pipeline configs block progress. Developers stare at progress bars instead of writing code.
Cumbersome testing and staging setups: Provisioning environments for testing and staging can be a manual process. Environments may not accurately mirror production, leading to surprises and integration issues late in the development cycle.
Lack of discoverability and reusability: Nobody knows what code already exists, so everyone rebuilds it. Duplication becomes the norm.
Developer toil and context switching: Developers spend more time on environment setup and troubleshooting than on writing features.

These inefficiencies add up, creating significant friction in the developer workflow. Developers spend more time wrestling with processes and less time focused on building and innovating. A Platform approach can help solve these challenges.

Problem: Security as a bottleneck and source of friction

Speed and efficiency matter, but security can’t be compromised. Traditionally, security acts as a gate – a necessary hurdle before releasing software. Platform Engineering aims to transform security from a bottleneck into an enabler.

For many developers, security feels like a roadblock, leading to common friction points:

Last-minute security: Checks happen at the end of development, causing costly rework when issues are found.
Restrictive policies: Security rules feel arbitrary and unclear, slowing down deployments.
The “No” department: Security teams are seen as blockers who enforce policies without offering solutions.
Speed vs. security mindset: Everyone believes you must choose between going fast and being secure.
Security is “Someone else’s job”: Developers think security is only the security team’s responsibility.

This “security as a gate” approach not only slows things down but leads to workarounds as developers try to bypass security to meet deadlines.

By integrating security into your platform, you transform security from a gatekeeper into a built-in feature of the development process. Security becomes an enabler of trust and speed, letting developers innovate with confidence.

Problem: Data overload without insights

Developers in modern cloud environments often find themselves in a paradox: they are drowning in data, yet starving for actionable information. Monitoring systems pump out metrics, logs, and traces, but finding what matters feels impossible. An ideal internal developer platform shifts the focus from data collection to actionable insights.

Here’s what developers typically experience:

Tool sprawl: Teams use different tools for metrics, logs, and traces. Developers waste time jumping between dashboards and manually connecting the dots.
Alert noise: Developers get bombarded with alerts lacking context or clear next steps. Important signals get buried in the noise.
Dashboard overload: Existing dashboards overwhelm developers with granular metrics that are hard to connect to application behavior.
Reactive debugging: Troubleshooting becomes a time-consuming fire drill. Developers spend hours sifting through logs to pinpoint issues.
Missing proactive insights: Observability is only used for firefighting. Developers lack insights to optimize performance or prevent issues before they affect users.
Disconnected from production: Many developers feel blind to how their code actually runs in production, limiting their ability to improve it.

This data flood without clear insights leaves developers reactive rather than proactive, hampering their ability to build reliable applications.

By improving observability in your platform, you transform it from an operations function into a developer superpower. Developers gain the insights they need to build better applications with greater confidence, using AI to focus on what truly matters.

Problem: Balancing autonomy with control and cost efficiency

Empowering developers with self-service is essential, but unchecked autonomy leads to chaos. As platform adoption grows, organizations need to maintain control without creating bottlenecks. This is where Governance as Code becomes critical, establishing guardrails while preserving speed.

Self-service creates new challenges:

Configuration drift: In decentralized environments, infrastructure setups diverge from standards, creating security risks.
Cloud cost explosion: Without proper controls, self-service can lead to wasted resources and budget overruns. Teams over-provision or forget to clean up unused environments.
Compliance headaches: Meeting regulatory requirements becomes harder when infrastructure is created in an uncontrolled way.
Audit gaps: Without clear governance, tracking who created what and when becomes nearly impossible.
Manual governance slows everything: If governance relies on approvals and tickets, it defeats the purpose of self-service.

These challenges highlight the need for automated governance that scales with your platform, ensuring control without slowing developers down.

By implementing Governance as Code, you ensure that self-service doesn’t conflict with security, compliance, and cost efficiency. Governance becomes an automated part of your platform, enabling responsible scaling.

Conclusion

These six challenges represent the core obstacles standing between your organization and true developer velocity. When properly addressed, each transforms into a capability that empowers developers and accelerates innovation.

The upcoming articles in this series will explore each area in depth, with practical strategies and real-world examples to help you build an effective internal developer platform.

Ready to implement these principles in your organization? Check out “Platform Engineering: Recommended Practices for Infrastructure as Code”. It provides detailed guidance on building scalable internal developer platforms.

How to structure infrastructure code for scalability
Managing development environments with developer stacks and Git branches
Designing modular and reusable Pulumi projects
Implementing cross-stack dependencies with stack references
Setting up RBAC, security, and governance at scale
Automating infrastructure management with stack orchestration

Get the Free Platform Engineering Ebook →

And don’t miss the next article in this series, where we’ll explore provisioning as the foundation of your developer platform journey.

Integrating DevOps and Security in Platform Engineering

Sara Huddleston — Wed, 11 Dec 2024 07:41:06 +0000

Platform engineering has become essential for mid-to-large organizations, moving beyond a DevOps trend. Gartner predicts that by 2026, 80% of software companies will have internal platform services to streamline development. The goal is to empower developers with self-service tools while maintaining security, compliance, and reliability through DevSecOps practices.

At PulumiUP Europe 2024, experts shared insights on aligning DevOps with security to build scalable, secure platforms:

Jess Mink, Sr. Director of Platform Engineering at Honeycomb
Kief Morris, Global Head of Infrastructure Engineering at ThoughtWorks
Lindsay Jack, VP of Engineering & Security at Snyk
Nariman Aga-Tagiyev, Application Security Architect at WiseFrog Security
Komal Ali, Engineering Manager at Pulumi

The panel discussed key strategies, challenges, and pillars of successful platform engineering.

The Core Pillars of Platform Engineering

Platform engineering teams comprise multiple professionals with many responsibilities and focus areas. According to our panel of experts, the core pillars of platform engineering include:

Developer Experience (DevEx): Provide developers with the tools, frameworks, and abstractions they need to be productive and proactive without getting stuck in infrastructure or operational concerns.
Reliability and Scalability: Ensure that the platform and infrastructure can support the organization’s needs, with the ability to scale up or down as required.
Security and Compliance: Embed robust, accessible security and compliance frameworks into the development lifecycle while making it easy for developers to adhere to these policies.
Automation and Tooling: Leverage Infrastructure as Code (IaC) and automation to enforce standardized processes and consistency and reduce cognitive load and manual effort.
Observability and Monitoring: Provide visibility into the platform’s health and performance, delivering actionable insights that allow teams to identify and resolve issues quickly.

These pillars work together to create a platform that empowers developers to innovate and deliver value to the organization and customers while maintaining the necessary controls and safeguards.

As Jess Mink, Director of Platform Engineering at Honeycomb, explains:

“The goal of platform engineering is to help the company run smoother and faster and unlock things people didn’t know were possible […] We tend to focus on tools and software, but it’s really about people, processes, and tools. If you consider this, platforms are responsible for social and technical support across the organization. A common pitfall is building tools no one uses because you didn’t meet people where they are.”

Aligning DevOps and Security for Secure Platform Engineering

Integrating security into platform engineering ensures it becomes a proactive part of the development lifecycle and ensures that “DevSecOps” is not an afterthought but a core consideration.

Key best practices shared by the panel include:

Shift Left Security

One of the fundamental principles of DevSecOps is to “shift left” - that is, to integrate security earlier in the development process rather than waiting until the end. This can involve activities such as:

Incorporating security requirements and threat modeling into the initial design phase
Automating security scans and tests as part of the continuous integration (CI) pipeline
Providing developers with secure coding guidelines and tools to identify and remediate vulnerabilities

By addressing security concerns upfront, organizations can reduce the time and cost of remediating issues later in the development lifecycle.

Embrace Automation and Standardization

Consistency is key. Platform engineering teams should leverage automation and built-in safeguards and security processes. This may include:

Automating the provisioning of secure infrastructure and application environments
Implementing Infrastructure as Code (IaC) to define and manage infrastructure in a declarative, version-controlled manner
Standardizing security controls, policies, and configurations across the platform

By automating these tasks, platform engineering teams can reduce the risk of human error, improve visibility and auditability, and free up developers to focus on building features rather than managing infrastructure.

Prioritize Observability and Monitoring

Effective security requires visibility into the health and performance of the platform. Platform engineering teams should invest in robust observability and monitoring solutions to:

Detect and respond to security incidents and anomalies in real-time
Gain insights into the behavior and usage patterns of the platform
Identify and address vulnerabilities or misconfigurations proactively

By integrating security-focused monitoring and alerting into the platform, organizations can quickly identify and mitigate threats while also providing developers with the necessary context to understand and address security-related issues.

Foster a Culture of Collaboration

Platform engineering is often referred to as being the practical application of DevOps practices. Integrating security practices often requires a cultural shift towards collaboration and shared responsibility between all teams in development, operations, and security, thus the name DevSecOps. Platform engineering teams can facilitate this by:

Treating Platforms as Products
Involving security stakeholders in the design and planning of platform initiatives
Providing security training and education to developers to empower them to make informed decisions
Establishing communication channels and feedback loops between teams

As Kief Morris, Global Head of Infrastructure Engineering at ThoughtWorks, explains:

“There is a new way of thinking that is trying to avoid that “build it, and they will come mentality,” which leads to building it and nobody using it. One of the trends we are seeing is product thinking […]—using techniques like creating user personas of different types of users in the organization, conducting research to understand their needs, and talking with them.”

Breaking silos and fostering communication helps organizations build secure, scalable platforms that support the needs of developers, platform engineers, architects, and security teams.

Challenges of Integrating Security in Platform Engineering

While the benefits of integrating DevOps and security in platform engineering are clear, the journey has expected challenges. Our panel of experts highlighted several key obstacles that organizations may face:

Balancing Autonomy and Control

The primary goal is to empower developers to be more productive and proactive. However, this autonomy needs to be balanced with necessary security controls and governance measures.

Jess Mink points out the importance of achieving harmony between developer autonomy and operational control, stating:

“It’s a delicate balance - you want to make things easy for developers, but you also need to maintain the right level of control and security. It’s about finding the right abstractions and interfaces that give developers the freedom they need while still ensuring the platform remains secure and compliant.”

Driving Adoption and Changing Mindsets

Integrating security into the platform engineering workflow can often be met with resistance from developers accustomed to moving quickly and may view security as an obstacle to their productivity.

As Nariman, a Software Security Architect, notes:

“The challenge is not just about the tools or the technology - it’s about changing the mindset and getting people to understand the importance of security. You need to find ways to motivate developers and make them feel like they’re part of the solution rather than just imposing more rules and processes.”

Effective communication, education, and a focus on the business value of security are key to driving adoption and fostering a culture of shared responsibility.

Adapting to Evolving Needs and Technologies

As organizations grow and their technology stacks evolve, the demands on the platform engineering team can shift rapidly. Keeping up with these changes, while maintaining a secure and reliable platform, can be a significant challenge.

Lindsay Jack, VP of Engineering for the Platform Division at Snyk, explains:

“You might have a platform team that’s really good at a certain set of technologies, but then the organization starts moving in a new direction, and suddenly those skills don’t match up anymore. It’s about being agile and adaptable and making sure you have the right mix of skills and expertise to support the organization’s evolving needs.”

Fostering internal mobility, continuous learning, and a flexible, modular platform architecture can help platform engineering teams navigate these changes more effectively.

Measuring Success in Secure Platform Engineering

Measuring the success of a platform engineering initiative can be complex as it involves balancing a range of technical, operational, and business-oriented metrics but also considers human factors. According to our panel, some key metrics to include:

Developer Experience: Metrics such as developer satisfaction surveys, time-to-onboard new developers, and the number of self-service platform capabilities can provide insights into the effectiveness of the platform in supporting developer productivity and autonomy.
Reliability and Scalability: Monitoring service-level objectives (SLOs), incident response times, and the ability to handle increased traffic or user demands can help assess the platform’s reliability and scalability.
Security and Compliance: Tracking the number of security incidents, the ratio of security issues found during threat modeling versus post-deployment, and the adoption of security best practices can indicate the platform’s security posture.
Automation and Tooling: Metrics like the percentage of infrastructure provisioned through code, the frequency of platform updates, and the time saved through automation can demonstrate the platform’s operational efficiency.
Observability and Monitoring: Measuring the effectiveness of observability tools, the time to detect and resolve issues, and the quality of incident reports can provide insights into the platform’s overall health and performance.

As Jess Mink emphasizes, it’s important not just to collect these metrics but to use them to drive meaningful action and improvement:

“We look at all of those [metric categories] every quarter and write summaries that go up to the executive level. This creates visibility and a shared understanding of problems so that there’s room for movement and change in the right ways.”

The Future of Secure Platform Engineering

Software development and infrastructure management are evolving, and the role of platform engineering will only become more critical to support it. By integrating DevOps and security practices, platform engineering teams can create scalable, secure platforms that empower developers to be more productive and innovate, delivering business value.

Learn how Pulumi customers build secure, scalable platforms and empower their development teams:

Tivity Health: DevSecOps Game-Changer: Security Automation That Delivers Business Results
BMW Group: Unified and Programmatic Approach to Infrastructure Management at BMW Using Pulumi
Lemonade: How the DevOps team supports a much larger group of developers using by Pulumi to standardize infrastructure components and enforce best practices.

Discover platform engineering best practices in The Guide to Platform Engineering: 7 Steps to Get It Right.

Build secure, scalable platforms with confidence—get started with the Platform Engineering Workshop Series & Course

Why Every Platform Engineer Should Care About Kubernetes Operators

Engin Diri — Tue, 10 Dec 2024 09:31:38 +0100

In one of my recent talks, I mentioned that the foundation of a successful Kubernetes-powered platform is the use of Kubernetes Operators, as they are a great way to automate operational tasks and the lifecycle of complex applications and services on Kubernetes.

In case you missed the talk, here is the link to the recording:

After the talk, I received feedback from the audience that they would like to have more information about Kubernetes operators and some of the advanced operators I would recommend to use in their Kubernetes-powered platforms. And who am I to reject such a great opportunity to share my knowledge with the community?

As you guess, the base for a Kubernetes Operator is, well, Kubernetes. So, if you are not familiar with Kubernetes, let me give you a brief introduction. Kubernetes, or K8s in short, is by far the most powerful open-source container orchestration platform out there - especially for its capability to maintain a desired state. This means you, as the platform admin, can define how you want your cluster and the workload on top of it to look, and Kubernetes (aka the control plane) executes the necessary steps to ensure the desired state is achieved using a feedback loop.

And how does Kubernetes achieve this complex operational task management? Kubernetes leverages the concept of controllers and operators. Both ensure that the cluster resources are in the desired state. But why is there a distinction between controllers and operators inside the Kubernetes ecosystem? There is also great confusion when folks talk about controllers and operators, as the differences are in the details and operators are a subcategory of controllers.

Kubernetes Controllers vs. Operators

K8s controllers are control loops that watch your resources and reconcile the current state with the desired state in a continuous loop. Think about how a thermostat works in your house. The thermostat watches the current temperature and, if it is below the desired temperature, it turns on the heating. If it is above the desired temperature, it turns off the heating. This is how a controller works in Kubernetes - it watches the resources and conditions defined in the desired state and executes the necessary steps to make sure the current state matches the desired state.

Here are some typical Kubernetes controller key functions as part of the maintain, observe, and enforce loop of the control loop:

Function	Description
Rollouts and Rollbacks	Deployment controller takes care of rolling out new versions of your application and rolling back to the previous version in case of failure.
Cluster maintenance	Node controller watches the nodes in the cluster and makes sure that the nodes are in the desired state.
Event handling	Event controller watches for events and takes action based on the events.
Schedule	Controller to run jobs and cron jobs at a specific time.
Resource enforcement	Resource controller watches the resource usage and enforces resource limits in a namespace.
State enforcement	Different controllers watch the state of the resources and enforce the desired state.

As you can see, controllers automate the routine operational tasks, enforce policies, handle failures and take actions to continuously maintain the desired state of the cluster.

Some of the typical use cases for controllers are:

Limit resource usage - Prevent the overload of the cluster by enforcing resource limits with controllers like ResourceQuota.
Auto-scaling - Automatically scales the number of pods based on the different metrics with HorizontalPodAutoscaler.
Task scheduling - Run jobs and cron jobs at a specific time with Job and CronJob controllers.
Run stateful workloads - Deploy and manage stateful workloads like databases with StatefulSet controller, by ensuring that the pods are created in a specific order and have a stable network identity.
Scaling deployments - Deploy and manage stateless workloads like web applications with the Deployment controller, by ensuring that the desired number of pods is running and handling the rolling updates and rollbacks.

Controllers, as you see, reduce the manual effort for the platform engineering teams and gives the cluster self-managing capabilities.

With all the above points, the benefits of controllers are clear - Let me list some of the main ones:

Automation - Controllers automate the routine operational tasks and enforce policies.
Availability - Controllers ensure that the resources are always available, addressing failures and taking actions to maintain the desired state.
Efficiency - Controllers provide an efficient way to manage the resources and workloads in the cluster with quota management and auto-scaling.
Reliability - Controllers help to make workload management more reliable with features like replica management, pod creation and deletion, and scheduling.
Flexibility - Controllers provide a flexible way to handle a variety of workloads and resources in the cluster, such as DaemonSet, StatefulSet, jobs, cron jobs, deployments, and services.
Observability - Controllers provide a view into the cluster resources and the state of the resources via the Kubernetes API.

With Controllers explained, let’s move on to the next level of automation in Kubernetes and talk about Kubernetes Operators.

Kubernetes Operators

As mentioned before, Kubernetes Operators are a subcategory of controllers that use API extensions (Custom Resource) to complete the automation task. Operators are a set of independent controllers, with each controller responsible for its own task. And while controllers can share similar functions with a controller, it is only focused on one domain and only uses Custom Resources to manage the domain.

Keep in mind that controllers work without the need for custom resources or a link to a specific domain.

Operators are custom-built controllers that focus on the deployment, management, and operation of a specific application or service. Some key functions of operators include:

Function	Description
Security	Operators integrate security best practices and policies, such as encryption, access control, and secret management, to protect the application. You can customize these measures and adjust them to the specific needs of the application.
Workload Lifecycle management	Operators manages the full lifecycle of complex stateful applications through deployment, upgrades, and scaling. It even applies logic to automate operations like backup and restore.
Error Handling	Operators detects and handles errors, such as application crashes, network failures, and resource constraints.
Migration	Operators help to migrate the application to a new version, a new cluster, or a new cloud provider.
Disaster Recovery	Operators help to recover the application from a disaster, such as data loss, network failure, or hardware failure.

Operators are a great way to encode the operational knowledge of the platform engineering team into automated controllers. This way, the platform engineering team can focus on the strategic tasks and let the operators handle the boring routine operational tasks. This reduces the manual effort and increases the reliability of the platform.

Some of the typical use cases for operators are:

Database management - Deploy and manage databases such as MySQL, PostgreSQL, and MongoDB.
Storage management - Deploy and manage storage such as Ceph, GlusterFS, or NFS.
Logging and monitoring - Simplify the deployment and management of logging and monitoring solutions like Prometheus, Grafana, or ELK stack.
CI/CD - Automate the deployment and management of CI/CD pipelines like Jenkins, GitLab, or Tekton. - Backup and restore - Automate the backup and restore of applications and data.
Messaging and event streaming - Simplify the deployment and management of messaging and event streaming solutions like Kafka, RabbitMQ, or NATS.
Machine learning - Automate the deployment and management of machine learning workloads such as TensorFlow, PyTorch, or Kubeflow.

With the applications-centric approach provided by operators, the platform engineering team can now enable fully automated operations while enhancing the reliability, efficiency, and observability of the platform and ensuring adherence to best practices and compliance requirements.

And similar to controllers, operators also have distinct benefits:

Simplification - Operators simplify the deployment and management of complex applications and services by providing a declarative way (via Custom Resources).
Higher Productivity - Operators increase the productivity of the platform engineering team by automating the routine operational tasks and allowing users to focus on delivering business value.
Extensibility - Extending the K8s API with Custom Resource Definitions (CRDs) allows administrators to support new applications and services without changing the core Kubernetes code.
Consistency - Operators ensure that they deploy and run the applications and services consistently across different environments, such as on-premises, cloud, or hybrid.
Modularity - Operators are modular and focused on a specific domain.
Legacy Transformation - Operators help to transform legacy applications into cloud-native applications by automating the deployment and management of complex applications.

Here is a visual representation of a Kubernetes Operator in action, which I found very nice and helpful:

Kubernetes Operators: what are they? Some examples Credit: SparkFabrik

Comparison of Kubernetes Controllers and Operators

Here is a quick summary of the differences between Kubernetes controllers and operators:

Feature	Kubernetes Controllers	Kubernetes Operators
Definition	Core control loops within Kubernetes that reconcile the current state with the desired state of resources.	Custom-built controllers with domain-specific logic, typically extending Kubernetes API with Custom Resource Definitions (CRDs).
Scope	General-purpose automation for cluster-wide resource management and workload operations.	Focused on application or service-specific lifecycle management and operations.
Custom Resources (CRDs)	Not mandatory. Most controllers work with built-in Kubernetes resources like Pods, Deployments, and StatefulSets.	Mandatory. Operators depend on CRDs to define and manage application-specific resources.
Domain-Specific Logic	Limited. Primarily focuses on generic Kubernetes operations like scheduling, scaling, and resource enforcement.	Extensive. Includes application-specific tasks such as backups, upgrades, migrations, and disaster recovery.
Automation	Automates operational tasks like resource scheduling, scaling, and maintaining cluster states.	Automates both operational and domain-specific tasks, often encoding deep operational knowledge of specific applications.
Complexity	Relatively low complexity as they focus on Kubernetes-native workflows.	Higher complexity due to domain-specific implementations and integrations with external systems.
Observability	Provides insight into cluster resource states via Kubernetes API and built-in events.	Enhances observability with application-specific metrics, logs, and health checks tailored to the managed application.
Use Cases	- Pod scaling (e.g., HPA) - Resource enforcement (e.g., ResourceQuota) - Rolling updates and rollbacks - Scheduling jobs (e.g., CronJob).	- Database management (e.g., MySQL Operator) - CI/CD pipelines (e.g., Tekton) - Backup and restore - Monitoring solutions (e.g., Prometheus Operator) - Stateful applications (e.g., Kafka Operator).
Deployment	Part of Kubernetes core components or extensions like kube-controller-manager.	External tools developed by vendors, community, or in-house, deployed using Custom Resources.
Key Benefits	- Cluster-wide automation - Ensures resource availability - Efficient and reliable workload management.	- Simplifies application lifecycle management - Increases productivity with domain-specific automation - Consistent deployments across environments.
Flexibility	Flexible for general Kubernetes operations but limited to built-in resources.	Highly flexible and extensible for custom applications and domain-specific requirements.
Target Audience	Platform administrators and Kubernetes users looking to automate Kubernetes-native workflows.	Developers and platform engineers needing advanced automation and lifecycle management for specific applications or services.
Maintenance	Managed and updated by Kubernetes core or community projects.	Requires domain-specific knowledge and regular updates to accommodate application changes and best practices.

With this detailed explanation of Kubernetes controllers and operators, I would like to share some advanced Kubernetes operators that I recommend for use in your Kubernetes-powered platform.

Advanced Kubernetes Operators

As we have seen, Kubernetes Operators are the go-to way to automate operational tasks and lifecycle management. I should mention that not all operators are created equal. Some operators are more advanced and provide more features than others. That is why, for example, OperatorHub.io categorises operators into five capability levels:

Basic Install - Installs the application on the cluster.
Seamless Upgrades - Manages Application upgrades.
Full Lifecycle Management - Manages the full lifecycle of the application.
Deep Insights - Provides monitoring and metrics.
Auto Pilot - Automatically optimizes and tunes the application.

The more advanced the operator, the more features it provides and the more automation it offers. At its most advanced level, the Auto Pilot, the operator automatically optimizes and tunes the application based on the workload and environment.

Here is a list of advanced Kubernetes operators that I recommend using in your Kubernetes-powered platform:

CloudNativePG Operator

CloudNativePG Operator Credit: cloudnative-pg.io

CloudNativePG Operator is a PostgreSQL operator that covers the full lifecycle of PostgreSQL databases on Kubernetes. It simplifies the deployment, management, and scaling of PostgreSQL databases by providing a declarative way to define and manage PostgreSQL clusters using custom resources.

Some of the key features of CloudNativePG Operator are:

Automated Backups - Schedule and manage backups of PostgreSQL databases.
High Availability - Deploy and manage high-availability PostgreSQL clusters.
Scaling - Scale the number of PostgreSQL instances based on the workload.

Installation

Either use the Helm chart or the Kubernetes manifests to deploy the CloudNativePG Operator:

helm repo add cloudnative-pg https://cloudnative-pg.io/charts/
helm repo update
helm upgrade --install cloudnativepg cloudnative-pg/cloudnative-pg --namespace cnpg-system --create-namespace

Or use Pulumi to deploy the CloudNativePG Operator:

import * as k8s from "@pulumi/kubernetes";
import * as k8shelm from "@pulumi/kubernetes/helm/v3";

const ns = new k8s.core.v1.Namespace("cnpg-system", {
 metadata: {
 name: "cnpg-system",
 },
});

new k8shelm.Release("cloudnativepg", {
 chart: "oci://ghcr.io/cloudnative-pg/charts/cloudnative-pg",
 namespace: ns.metadata.name,
 createNamespace: true,
});

import pulumi_kubernetes as k8s
import pulumi_kubernetes.helm.v3 as k8shelm
import pulumi_kubernetes.meta.v1 as meta

ns = k8s.core.v1.Namespace(
 "cnpg-system",
 metadata=meta.ObjectMetaArgs(
 name="cnpg-system",
 ),
)

release = k8shelm.Release(
 "cloudnativepg",
 chart="oci://ghcr.io/cloudnative-pg/charts/cloudnative-pg",
 namespace=ns.metadata["name"],
 create_namespace=True,
)

package main

import (
 k8s "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes"
 apiv1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/apiextensions"
 corev1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/core/v1"
 helmv3 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/helm/v3"
 metav1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/meta/v1"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {

 ns, err := corev1.NewNamespace(ctx, "cnpg-system", &corev1.NamespaceArgs{
 Metadata: &metav1.ObjectMetaArgs{
 Name: pulumi.String("cnpg-system"),
 },
 })
 if err != nil {
 return err
 }

 _, err = helmv3.NewRelease(ctx, "cloudnativepg", &helmv3.ReleaseArgs{
 Chart: pulumi.String("oci://ghcr.io/cloudnative-pg/charts/cloudnative-pg"),
 Namespace: ns.Metadata.Name().Elem(),
 CreateNamespace: pulumi.Bool(true),
 })
 if err != nil {
 return err
 }
 return nil
 })
}

using System.Threading.Tasks;
using Pulumi;
using Pulumi.Kubernetes.Core.V1;
using Pulumi.Kubernetes.Helm.V3;
using Pulumi.Kubernetes.Types.Inputs.Core.V1;
using Pulumi.Kubernetes.Types.Inputs.Helm.V3;
using Pulumi.Kubernetes.Types.Inputs.Meta.V1;
using System.Collections.Generic;
using Pulumi.Kubernetes.ApiExtensions;

class MyStack : Stack
{
 public MyStack()
 {
 var ns = new Namespace("cnpg-system", new NamespaceArgs
 {
 Metadata = new ObjectMetaArgs
 {
 Name = "cnpg-system"
 }
 });

 var release = new Release("cloudnativepg", new ReleaseArgs
 {
 Chart = "oci://ghcr.io/cloudnative-pg/charts/cloudnative-pg",
 Namespace = ns.Metadata.Apply(m => m.Name),
 CreateNamespace = true
 });

}

class Program
{
 static Task<int> Main() => Deployment.RunAsync<MyStack>();
}

Usage

Here is a simple example of a PostgreSQL cluster with backup configured on S3 API-compatible storage:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
 name: cluster-example-with-backup
spec:
 instances: 3
 primaryUpdateStrategy: unsupervised

 # Persistent storage configuration
 storage:
 storageClass: standard
 size: 1Gi

 # Backup properties
 # This assumes a local minio setup
 backup:
 barmanObjectStore:
 destinationPath: s3://backups/
 endpointURL: http://minio:9000
 s3Credentials:
 accessKeyId:
 name: minio
 key: ACCESS_KEY_ID
 secretAccessKey:
 name: minio
 key: ACCESS_SECRET_KEY
 wal:
 compression: gzip

Or use Pulumi:

new k8s.apiextensions.CustomResource("cluster-example-with-backup", {
 apiVersion: "postgresql.cnpg.io/v1",
 kind: "Cluster",
 metadata: {
 name: "cluster-example-with-backup",
 },
 spec: {
 instances: 3,
 primaryUpdateStrategy: "unsupervised",

 // Persistent storage configuration
 storage: {
 storageClass: "standard",
 size: "1Gi",
 },

 // Backup properties
 backup: {
 barmanObjectStore: {
 destinationPath: "s3://backups/",
 endpointURL: "http://minio:9000",
 s3Credentials: {
 accessKeyId: {
 name: "minio",
 key: "ACCESS_KEY_ID",
 },
 secretAccessKey: {
 name: "minio",
 key: "ACCESS_SECRET_KEY",
 },
 },
 wal: {
 compression: "gzip",
 },
 },
 },
 },
});

from pulumi_kubernetes import apiextensions

postgresql_cluster = apiextensions.CustomResource(
 "cluster-example-with-backup",
 api_version="postgresql.cnpg.io/v1",
 kind="Cluster",
 metadata=meta.ObjectMetaArgs(
 name="cluster-example-with-backup",
 ),
 spec={
 "instances": 3,
 "primaryUpdateStrategy": "unsupervised",
 # Persistent storage configuration
 "storage": {
 "storageClass": "standard",
 "size": "1Gi",
 },
 # Backup properties
 "backup": {
 "barmanObjectStore": {
 "destinationPath": "s3://backups/",
 "endpointURL": "http://minio:9000",
 "s3Credentials": {
 "accessKeyId": {
 "name": "minio",
 "key": "ACCESS_KEY_ID",
 },
 "secretAccessKey": {
 "name": "minio",
 "key": "ACCESS_SECRET_KEY",
 },
 },
 "wal": {
 "compression": "gzip",
 },
 },
 },
 },
)

package main

import (
 k8s "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes"
 apiv1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/apiextensions"
 corev1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/core/v1"
 helmv3 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/helm/v3"
 metav1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/meta/v1"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {

 _, err = apiv1.NewCustomResource(ctx, "cluster-example-with-backup", &apiv1.CustomResourceArgs{
 ApiVersion: pulumi.String("postgresql.cnpg.io/v1"),
 Kind: pulumi.String("Cluster"),
 Metadata: &metav1.ObjectMetaArgs{
 Name: pulumi.String("cluster-example-with-backup"),
 },
 OtherFields: k8s.UntypedArgs{
 "instances": pulumi.Int(3),
 "primaryUpdateStrategy": pulumi.String("unsupervised"),
 "storage": pulumi.Map{
 "storageClass": pulumi.String("standard"),
 "size": pulumi.String("1Gi"),
 },
 "backup": pulumi.Map{
 "barmanObjectStore": pulumi.Map{
 "destinationPath": pulumi.String("s3://backups/"),
 "endpointURL": pulumi.String("http://minio:9000"),
 "s3Credentials": pulumi.Map{
 "accessKeyId": pulumi.Map{
 "name": pulumi.String("minio"),
 "key": pulumi.String("ACCESS_KEY_ID"),
 },
 "secretAccessKey": pulumi.Map{
 "name": pulumi.String("minio"),
 "key": pulumi.String("ACCESS_SECRET_KEY"),
 },
 },
 "wal": pulumi.Map{
 "compression": pulumi.String("gzip"),
 },
 },
 },
 },
 })
 if err != nil {
 return err
 }

 return nil
 })
}

using System.Threading.Tasks;
using Pulumi;
using Pulumi.Kubernetes.Core.V1;
using Pulumi.Kubernetes.Helm.V3;
using Pulumi.Kubernetes.Types.Inputs.Core.V1;
using Pulumi.Kubernetes.Types.Inputs.Helm.V3;
using Pulumi.Kubernetes.Types.Inputs.Meta.V1;
using System.Collections.Generic;
using Pulumi.Kubernetes.ApiExtensions;

class PostGreSQLClusterArgs : CustomResourceArgs
{
 [Input("postgresql.cnpg.io/v1")]
 public Input<string> ApiVersion { get; set; }
 [Input("Cluster")]
 public Input<string> Kind { get; set; }
 public ObjectMetaArgs Metadata { get; set; }
 public Dictionary<string, object> Others { get; set; }
 [Input("spec")]
 public InputMap<object> Spec { get; set; }

 public PostGreSQLClusterArgs(string apiVersion, string kind) : base(apiVersion, kind)
 {
 }
}
class MyStack : Stack
{
 public MyStack()
 {
 var postgresqlCluster = new Pulumi.Kubernetes.ApiExtensions.CustomResource("cluster-example-with-backup", new PostGreSQLClusterArgs("postgresql.cnpg.io/v1", "Cluster")
 {
 ApiVersion = "postgresql.cnpg.io/v1",
 Kind = "Cluster",
 Metadata = new ObjectMetaArgs
 {
 Name = "cluster-example-with-backup",
 },
 Spec = new InputMap<object>
 {
 { "instances", 3 },
 { "primaryUpdateStrategy", "unsupervised" },
 { "storage", new InputMap<object>
 {
 { "storageClass", "standard" },
 { "size", "1Gi" },
 }
 },
 { "backup", new InputMap<object>
 {
 { "barmanObjectStore", new InputMap<object>
 {
 { "destinationPath", "s3://backups/" },
 { "endpointURL", "http://minio:9000" },
 { "s3Credentials", new InputMap<object>
 {
 { "accessKeyId", new InputMap<object>
 {
 { "name", "minio" },
 { "key", "ACCESS_KEY_ID" },
 }
 },
 { "secretAccessKey", new InputMap<object>
 {
 { "name", "minio" },
 { "key", "ACCESS_SECRET_KEY" },
 }
 },
 }
 },
 { "wal", new InputMap<object>
 {
 { "compression", "gzip" },
 }
 },
 }
 },
 }
 },
 }
 });

}

class Program
{
 static Task<int> Main() => Deployment.RunAsync<MyStack>();
}

Summary

CloudNativePG Operator is a great way to deploy and manage PostgreSQL databases on Kubernetes. It simplifies a wide range of tasks, including backups, high availability, and scaling, making it a must-have for PostgreSQL users.

You might also like:

Flux Operator

Flux Operator Credit: fluxcd.control-plane.io/operator

The Flux Operator is a full autopilot solution that provides an alternative to the traditional Flux Bootstrap procedure, removing the operational burden of managing Flux across multiple clusters by automating the installation, configuration, and upgrade of Flux fully.

Some of the key features of Flux Operator are:

GitOps Deployment - Automate the deployment of applications and services using GitOps.
Lifecycle Management - Manage the full lifecycle of Flux, including upgrades and rollbacks.
Deep Insights - Provide deep insights into the state of Flux and the applications deployed with Flux.

Installation

Use the Helm chart to deploy the Flux Operator:

helm upgrade -i flux-operator oci://ghcr.io/controlplaneio-fluxcd/charts/flux-operator --namespace flux-system --create-namespace

Or use Pulumi to deploy the Flux Operator:

import * as k8s from "@pulumi/kubernetes";
import * as k8shelm from "@pulumi/kubernetes/helm/v3";

const namespace = new k8s.core.v1.Namespace("flux-system", {
 metadata: {
 name: "flux-system",
 },
});

new k8s.helm.v3.Release("flux-operator", {
 chart: "oci://ghcr.io/controlplaneio-fluxcd/charts/flux-operator",
 namespace: namespace.metadata.name,
 createNamespace: true,
});

import pulumi_kubernetes as k8s
import pulumi_kubernetes.helm.v3 as k8shelm
import pulumi_kubernetes.meta.v1 as meta

flux_namespace = k8s.core.v1.Namespace(
 "flux-system",
 metadata=meta.ObjectMetaArgs(
 name="flux-system",
 ),
)
flux_operator = k8shelm.Release(
 "flux-operator",
 chart="oci://ghcr.io/controlplaneio-fluxcd/charts/flux-operator",
 namespace=flux_namespace.metadata["name"],
 create_namespace=True,
)

package main

import (
 k8s "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes"
 apiv1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/apiextensions"
 corev1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/core/v1"
 helmv3 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/helm/v3"
 metav1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/meta/v1"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {

 namespace, err := corev1.NewNamespace(ctx, "flux-system", &corev1.NamespaceArgs{
 Metadata: &metav1.ObjectMetaArgs{
 Name: pulumi.String("flux-system"),
 },
 })
 if err != nil {
 return err
 }

 _, err = helmv3.NewRelease(ctx, "flux-operator", &helmv3.ReleaseArgs{
 Chart: pulumi.String("oci://ghcr.io/controlplaneio-fluxcd/charts/flux-operator"),
 Namespace: namespace.Metadata.Name().Elem(),
 CreateNamespace: pulumi.Bool(true),
 })
 if err != nil {
 return err
 }
 return nil
 })
}

using System.Threading.Tasks;
using Pulumi;
using Pulumi.Kubernetes.Core.V1;
using Pulumi.Kubernetes.Helm.V3;
using Pulumi.Kubernetes.Types.Inputs.Core.V1;
using Pulumi.Kubernetes.Types.Inputs.Helm.V3;
using Pulumi.Kubernetes.Types.Inputs.Meta.V1;
using System.Collections.Generic;
using Pulumi.Kubernetes.ApiExtensions;

 var namespaceFluxSystem = new Namespace("flux-system", new NamespaceArgs
 {
 Metadata = new ObjectMetaArgs
 {
 Name = "flux-system",
 },
 });

 var fluxOperator = new Release("flux-operator", new ReleaseArgs
 {
 Chart = "oci://ghcr.io/controlplaneio-fluxcd/charts/flux-operator",
 Namespace = namespaceFluxSystem.Metadata.Apply(metadata => metadata.Name),
 CreateNamespace = true,
 });
}

class Program
{
 static Task<int> Main() => Deployment.RunAsync<MyStack>();
}

Usage

Here is an example of a FluxInstance Custom Resource that defines a Flux instance:

apiVersion: fluxcd.controlplane.io/v1
kind: FluxInstance
metadata:
 name: flux
 namespace: flux-system
 annotations:
 fluxcd.controlplane.io/reconcileEvery: "1h"
 fluxcd.controlplane.io/reconcileTimeout: "5m"
spec:
 distribution:
 version: "2.x"
 registry: "ghcr.io/fluxcd"
 artifact: "oci://ghcr.io/controlplaneio-fluxcd/flux-operator-manifests"
 components:
 - source-controller
 - kustomize-controller
 - helm-controller
 - notification-controller
 - image-reflector-controller
 - image-automation-controller
 cluster:
 type: kubernetes
 multitenant: false
 networkPolicy: true
 domain: "cluster.local"
 kustomize:
 patches:
 - target:
 kind: Deployment
 name: "(kustomize-controller|helm-controller)"
 patch: |
 - op: add
 path: /spec/template/spec/containers/0/args/-
 value: --concurrent=10
 - op: add
 path: /spec/template/spec/containers/0/args/-
 value: --requeue-dependency=5s

Or use Pulumi:

new k8s.apiextensions.CustomResource("flux", {
 apiVersion: "fluxcd.controlplane.io/v1",
 kind: "FluxInstance",
 metadata: {
 name: "flux",
 namespace: "flux-system",
 annotations: {
 "fluxcd.controlplane.io/reconcileEvery": "1h",
 "fluxcd.controlplane.io/reconcileTimeout": "5m",
 },
 },
 spec: {
 distribution: {
 version: "2.x",
 registry: "ghcr.io/fluxcd",
 artifact: "oci://ghcr.io/controlplaneio-fluxcd/flux-operator-manifests",
 },
 components: ["source-controller", "kustomize-controller", "helm-controller", "notification-controller", "image-reflector-controller", "image-automation-controller"],
 cluster: {
 type: "kubernetes",
 multitenant: false,
 networkPolicy: true,
 domain: "cluster.local",
 },
 kustomize: {
 patches: [
 {
 target: {
 kind: "Deployment",
 name: "(kustomize-controller|helm-controller)",
 },
 patch: `
 - op: add
 path: /spec/template/spec/containers/0/args/-
 value: --concurrent=10
 - op: add
 path: /spec/template/spec/containers/0/args/-
 value: --requeue-dependency=5s
 `,
 },
 ],
 },
 },
});

from pulumi_kubernetes import apiextensions

flux_instance = k8s.apiextensions.CustomResource(
 "flux",
 api_version="fluxcd.controlplane.io/v1",
 kind="FluxInstance",
 metadata={
 "name": "flux",
 "namespace": flux_namespace.metadata["name"],
 "annotations": {
 "fluxcd.controlplane.io/reconcileEvery": "1h",
 "fluxcd.controlplane.io/reconcileTimeout": "5m",
 },
 },
 spec={
 "distribution": {
 "version": "2.x",
 "registry": "ghcr.io/fluxcd",
 "artifact": "oci://ghcr.io/controlplaneio-fluxcd/flux-operator-manifests",
 },
 "components": [
 "source-controller",
 "kustomize-controller",
 "helm-controller",
 "notification-controller",
 "image-reflector-controller",
 "image-automation-controller",
 ],
 "cluster": {
 "type": "kubernetes",
 "multitenant": False,
 "networkPolicy": True,
 "domain": "cluster.local",
 },
 "kustomize": {
 "patches": [
 {
 "target": {
 "kind": "Deployment",
 "name": "(kustomize-controller|helm-controller)",
 },
 "patch": [
 {
 "op": "add",
 "path": "/spec/template/spec/containers/0/args/-",
 "value": "--concurrent=10",
 },
 {
 "op": "add",
 "path": "/spec/template/spec/containers/0/args/-",
 "value": "--requeue-dependency=5s",
 },
 ],
 }
 ]
 },
 },
)

package main

import (
 k8s "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes"
 apiv1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/apiextensions"
 corev1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/core/v1"
 helmv3 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/helm/v3"
 metav1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/meta/v1"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {

 _, err = apiv1.NewCustomResource(ctx, "flux", &apiv1.CustomResourceArgs{
 ApiVersion: pulumi.String("fluxcd.controlplane.io/v1"),
 Kind: pulumi.String("FluxInstance"),
 Metadata: &metav1.ObjectMetaArgs{
 Name: pulumi.String("flux"),
 Namespace: pulumi.String("flux-system"),
 Annotations: pulumi.StringMap{
 "fluxcd.controlplane.io/reconcileEvery": pulumi.String("1h"),
 "fluxcd.controlplane.io/reconcileTimeout": pulumi.String("5m"),
 },
 },
 OtherFields: k8s.UntypedArgs{
 "distribution": pulumi.Map{
 "version": pulumi.String("2.x"),
 "registry": pulumi.String("ghcr.io/fluxcd"),
 "artifact": pulumi.String("oci://ghcr.io/controlplaneio-fluxcd/flux-operator-manifests"),
 },
 "components": pulumi.StringArray{
 pulumi.String("source-controller"),
 pulumi.String("kustomize-controller"),
 pulumi.String("helm-controller"),
 pulumi.String("notification-controller"),
 pulumi.String("image-reflector-controller"),
 pulumi.String("image-automation-controller"),
 },
 "cluster": pulumi.Map{
 "type": pulumi.String("kubernetes"),
 "multitenant": pulumi.Bool(false),
 "networkPolicy": pulumi.Bool(true),
 "domain": pulumi.String("cluster.local"),
 },
 "kustomize": pulumi.Map{
 "patches": pulumi.Array{
 pulumi.Map{
 "target": pulumi.Map{
 "kind": pulumi.String("Deployment"),
 "name": pulumi.String("(kustomize-controller|helm-controller)"),
 },
 "patch": pulumi.Array{
 pulumi.Map{
 "op": pulumi.String("add"),
 "path": pulumi.String("/spec/template/spec/containers/0/args/-"),
 "value": pulumi.String("--concurrent=10"),
 },
 pulumi.Map{
 "op": pulumi.String("add"),
 "path": pulumi.String("/spec/template/spec/containers/0/args/-"),
 "value": pulumi.String("--requeue-dependency=5s"),
 },
 },
 },
 },
 },
 },
 })
 if err != nil {
 return err
 }

 return nil
 })
}

using System.Threading.Tasks;
using Pulumi;
using Pulumi.Kubernetes.Core.V1;
using Pulumi.Kubernetes.Helm.V3;
using Pulumi.Kubernetes.Types.Inputs.Core.V1;
using Pulumi.Kubernetes.Types.Inputs.Helm.V3;
using Pulumi.Kubernetes.Types.Inputs.Meta.V1;
using System.Collections.Generic;
using Pulumi.Kubernetes.ApiExtensions;

class FluxInstanceArgs : CustomResourceArgs
{
 public string ApiVersion { get; set; }
 public string Kind { get; set; }
 public ObjectMetaArgs Metadata { get; set; }
 public Dictionary<string, object> Spec { get; set; }

 public FluxInstanceArgs(string apiVersion, string kind) : base(apiVersion, kind)
 {
 }
}
 var flux = new Pulumi.Kubernetes.ApiExtensions.CustomResource("flux", new FluxInstanceArgs("fluxcd.controlplane.io/v1", "FluxInstance")
 {
 ApiVersion = "fluxcd.controlplane.io/v1",
 Kind = "FluxInstance",
 Metadata = new ObjectMetaArgs
 {
 Name = "flux",
 Annotations =
 {
 { "fluxcd.controlplane.io/reconcileEvery", "1h" },
 { "fluxcd.controlplane.io/reconcileTimeout", "5m" },
 }
 },
 Spec = new Dictionary<string, object>
 {
 { "distribution", new Dictionary<string, object>
 {
 { "version", "2.x" },
 { "registry", "ghcr.io/fluxcd" },
 { "artifact", "oci://ghcr.io/controlplaneio-fluxcd/flux-operator-manifests" }
 }
 },
 { "components", new[]
 {
 "source-controller",
 "kustomize-controller",
 "helm-controller",
 "notification-controller",
 "image-reflector-controller",
 "image-automation-controller"
 }
 },
 { "cluster", new Dictionary<string, object>
 {
 { "type", "kubernetes" },
 { "multitenant", false },
 { "networkPolicy", true },
 { "domain", "cluster.local" }
 }
 },
 { "kustomize", new Dictionary<string, object>
 {
 { "patches", new[]
 {
 new Dictionary<string, object>
 {
 { "target", new Dictionary<string, object>
 {
 { "kind", "Deployment" },
 { "name", "(kustomize-controller|helm-controller)" }
 }
 },
 { "patch", new[]
 {
 new Dictionary<string, object>
 {
 { "op", "add" },
 { "path", "/spec/template/spec/containers/0/args/-" },
 { "value", "--concurrent=10" }
 },
 new Dictionary<string, object>
 {
 { "op", "add" },
 { "path", "/spec/template/spec/containers/0/args/-" },
 { "value", "--requeue-dependency=5s" }
 }
 }
 }
 }
 }
 }
 }
 }
 },
 });

}

class Program
{
 static Task<int> Main() => Deployment.RunAsync<MyStack>();
}

Summary

The Flux Operator is another excellent example of an advanced Kubernetes operator, providing full lifecycle management with numerous automation features.

Strimzi Operator

Strimzi Operator Credit: strimzi.io

Last but not least, the Strimzi Operator is a full lifecycle management operator for Apache Kafka on Kubernetes. As event-driven architectures are becoming increasingly popular, Apache Kafka has become the de-facto standard for building scalable and reliable event streaming platforms. The Strimzi Operator makes it easier to deploy, manage, and scale Apache Kafka clusters on Kubernetes.

Some of the key features of Strimzi Operator are:

Cluster Management - Deploy and manage Apache Kafka clusters.
Mirror Clusters - Deploy and manage mirror clusters for disaster recovery.
Streaming Capabilities - With Kafka Connect you can stream data between Kafka and other systems.

Installation

Use the Helm chart to deploy the Strimzi Operator:

helm repo add strimzi https://strimzi.io/charts/
helm repo update
helm install strimzi strimzi/strimzi-kafka-operator -n kafka --create-namespace

Or use Pulumi to deploy the Strimzi Operator:

import * as k8s from "@pulumi/kubernetes";
import * as k8shelm from "@pulumi/kubernetes/helm/v3";

const namespaceKafka = new k8s.core.v1.Namespace("kafka", {
 metadata: {
 name: "kafka",
 },
});

new k8s.helm.v3.Release("strimzi-kafka-operator", {
 chart: "strimzi-kafka-operator",
 namespace: namespaceKafka.metadata.name,
 repositoryOpts: {
 repo: "https://strimzi.io/charts/",
 },
 createNamespace: true,
});

import pulumi_kubernetes as k8s
import pulumi_kubernetes.helm.v3 as k8shelm
import pulumi_kubernetes.meta.v1 as meta

kafka_namespace = k8s.core.v1.Namespace(
 "kafka",
 metadata=meta.ObjectMetaArgs(
 name="kafka",
 ),
)

strimzi_kafka_operator = k8shelm.Release(
 "strimzi-kafka-operator",
 chart="strimzi-kafka-operator",
 namespace=kafka_namespace.metadata["name"],
 repository_opts={
 "repo": "https://strimzi.io/charts/",
 },
 create_namespace=True,
)

package main

import (
 k8s "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes"
 apiv1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/apiextensions"
 corev1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/core/v1"
 helmv3 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/helm/v3"
 metav1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/meta/v1"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 namespaceKafka, err := corev1.NewNamespace(ctx, "kafka", &corev1.NamespaceArgs{
 Metadata: &metav1.ObjectMetaArgs{
 Name: pulumi.String("kafka"),
 },
 })
 if err != nil {
 return err
 }

 _, err = helmv3.NewRelease(ctx, "strimzi-kafka-operator", &helmv3.ReleaseArgs{
 Chart: pulumi.String("strimzi-kafka-operator"),
 Namespace: namespaceKafka.Metadata.Name(),
 RepositoryOpts: helmv3.RepositoryOptsArgs{
 Repo: pulumi.String("https://strimzi.io/charts/"),
 },
 CreateNamespace: pulumi.Bool(true),
 })
 if err != nil {
 return err
 }

 return nil
 })
}

using System.Threading.Tasks;
using Pulumi;
using Pulumi.Kubernetes.Core.V1;
using Pulumi.Kubernetes.Helm.V3;
using Pulumi.Kubernetes.Types.Inputs.Core.V1;
using Pulumi.Kubernetes.Types.Inputs.Helm.V3;
using Pulumi.Kubernetes.Types.Inputs.Meta.V1;
using System.Collections.Generic;
using Pulumi.Kubernetes.ApiExtensions;
class MyStack : Stack
{
 public MyStack()
 {
 var namespaceKafka = new Namespace("kafka", new NamespaceArgs
 {
 Metadata = new ObjectMetaArgs
 {
 Name = "kafka",
 }
 });

 var strimziKafkaOperator = new Release("strimzi-kafka-operator", new ReleaseArgs
 {
 Chart = "strimzi-kafka-operator",
 Namespace = namespaceKafka.Metadata.Apply(ns => ns.Name),
 RepositoryOpts = new RepositoryOptsArgs
 {
 Repo = "https://strimzi.io/charts/",
 },
 CreateNamespace = true,
 });

}

class Program
{
 static Task<int> Main() => Deployment.RunAsync<MyStack>();
}

Usage

Here is an example of a Kafka Custom Resource that defines a Kafka cluster:

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
 name: example-kafka-node-pool
 labels:
 strimzi.io/cluster: example-kafka-cluster
spec:
 replicas: 1
 roles:
 - controller
 - broker
 storage:
 type: ephemeral
---
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
 name: example-kafka-cluster
 annotations:
 strimzi.io/kraft: enabled
 strimzi.io/node-pools: enabled
spec:
 kafka:
 replicas: 1
 version: 3.8.0
 storage:
 type: ephemeral
 metadataVersion: 3.8-IV0
 listeners:
 - name: plain
 port: 9092
 type: internal
 tls: false
 - name: tls
 port: 9093
 type: internal
 tls: true
 config:
 offsets.topic.replication.factor: 1
 transaction.state.log.replication.factor: 1
 transaction.state.log.min.isr: 1
 default.replication.factor: 1
 min.insync.replicas: 1
 entityOperator:
 topicOperator: {}
 userOperator: {}

This example defines a Kafka cluster with one replica and two listeners, one for plain and one for TLS and uses ephemeral storage.

To create a topic, you can use the following KafkaTopic Custom Resource:

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
 name: example-kafka-cluster
 labels:
 strimzi.io/cluster:
spec:
 partitions: 5
 replicas: 1
 config:
 retention.ms: 7200000
 segment.bytes: 1073741824

Or use Pulumi:

new k8s.apiextensions.CustomResource("example-kafka-node-pool", {
 apiVersion: "kafka.strimzi.io/v1beta2",
 kind: "KafkaNodePool",
 metadata: {
 name: "example-kafka-node-pool",
 labels: {
 "strimzi.io/cluster": "example-kafka-cluster",
 },
 namespace: "kafka",
 },
 spec: {
 replicas: 1,
 roles: ["controller", "broker"],
 storage: {
 type: "ephemeral",
 },
 },
});

new k8s.apiextensions.CustomResource("example-kafka-cluster", {
 apiVersion: "kafka.strimzi.io/v1beta2",
 kind: "Kafka",
 metadata: {
 name: "example-kafka-cluster",
 annotations: {
 "strimzi.io/kraft": "enabled",
 "strimzi.io/node-pools": "enabled",
 },
 namespace: "kafka",
 },
 spec: {
 kafka: {
 replicas: 1,
 version: "3.8.0",
 storage: {
 type: "ephemeral",
 },
 metadataVersion: "3.8-IV0",
 listeners: [
 {
 name: "plain",
 port: 9092,
 type: "internal",
 tls: false,
 },
 {
 name: "tls",
 port: 9093,
 type: "internal",
 tls: true,
 },
 ],
 config: {
 "offsets.topic.replication.factor": 1,
 "transaction.state.log.replication.factor": 1,
 "transaction.state.log.min.isr": 1,
 "default.replication.factor": 1,
 "min.insync.replicas": 1,
 },
 },
 entityOperator: {
 topicOperator: {},
 userOperator: {},
 },
 },
});

new k8s.apiextensions.CustomResource("example-kafka-topic", {
 apiVersion: "kafka.strimzi.io/v1beta2",
 kind: "KafkaTopic",
 metadata: {
 name: "example-kafka-topic",
 labels: {
 "strimzi.io/cluster": "example-kafka-cluster",
 },
 namespace: "kafka",
 },
 spec: {
 partitions: 5,
 replicas: 1,
 config: {
 "retention.ms": 7200000,
 "segment.bytes": 1073741824,
 },
 },
});

from pulumi_kubernetes import apiextensions

kafka_node_pool = k8s.apiextensions.CustomResource(
 "example-kafka-node-pool",
 api_version="kafka.strimzi.io/v1beta2",
 kind="KafkaNodePool",
 metadata={
 "name": "example-kafka-node-pool",
 "labels": {
 "strimzi.io/cluster": "example-kafka-cluster",
 },
 "namespace": kafka_namespace.metadata["name"],
 },
 spec={
 "replicas": 1,
 "roles": ["controller", "broker"],
 "storage": {
 "type": "ephemeral",
 },
 },
)

kafka_cluster = k8s.apiextensions.CustomResource(
 "example-kafka-cluster",
 api_version="kafka.strimzi.io/v1beta2",
 kind="Kafka",
 metadata={
 "name": "example-kafka-cluster",
 "annotations": {
 "strimzi.io/kraft": "enabled",
 "strimzi.io/node-pools": "enabled",
 },
 "namespace": kafka_namespace.metadata["name"],
 },
 spec={
 "kafka": {
 "replicas": 1,
 "version": "3.8.0",
 "storage": {
 "type": "ephemeral",
 },
 "metadataVersion": "3.8-IV0",
 "listeners": [
 {
 "name": "plain",
 "port": 9092,
 "type": "internal",
 "tls": False,
 },
 {
 "name": "tls",
 "port": 9093,
 "type": "internal",
 "tls": True,
 },
 ],
 "config": {
 "offsets.topic.replication.factor": 1,
 "transaction.state.log.replication.factor": 1,
 "transaction.state.log.min.isr": 1,
 "default.replication.factor": 1,
 "min.insync.replicas": 1,
 },
 },
 "entityOperator": {
 "topicOperator": {},
 "userOperator": {},
 },
 },
)

kafka_topic = k8s.apiextensions.CustomResource(
 "example-kafka-topic",
 api_version="kafka.strimzi.io/v1beta2",
 kind="KafkaTopic",
 metadata={
 "name": "example-kafka-topic",
 "labels": {
 "strimzi.io/cluster": "example-kafka-cluster",
 },
 "namespace": kafka_namespace.metadata["name"],
 },
 spec={
 "partitions": 5,
 "replicas": 1,
 "config": {
 "retention.ms": 7200000,
 "segment.bytes": 1073741824,
 },
 },
)

package main

import (
 k8s "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes"
 apiv1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/apiextensions"
 corev1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/core/v1"
 helmv3 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/helm/v3"
 metav1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/meta/v1"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {

 _, err = apiv1.NewCustomResource(ctx, "example-kafka-node-pool", &apiv1.CustomResourceArgs{
 ApiVersion: pulumi.String("kafka.strimzi.io/v1beta2"),
 Kind: pulumi.String("KafkaNodePool"),
 Metadata: &metav1.ObjectMetaArgs{
 Name: pulumi.String("example-kafka-node-pool"),
 Namespace: pulumi.String("kafka"),
 Labels: pulumi.StringMap{
 "strimzi.io/cluster": pulumi.String("example-kafka-cluster"),
 },
 },
 OtherFields: k8s.UntypedArgs{
 "replicas": pulumi.Int(1),
 "roles": pulumi.StringArray{
 pulumi.String("controller"),
 pulumi.String("broker"),
 },
 "storage": pulumi.Map{
 "type": pulumi.String("ephemeral"),
 },
 },
 })
 if err != nil {
 return err
 }

 _, err = apiv1.NewCustomResource(ctx, "example-kafka-cluster", &apiv1.CustomResourceArgs{
 ApiVersion: pulumi.String("kafka.strimzi.io/v1beta2"),
 Kind: pulumi.String("Kafka"),
 Metadata: &metav1.ObjectMetaArgs{
 Name: pulumi.String("example-kafka-cluster"),
 Namespace: pulumi.String("kafka"),
 Annotations: pulumi.StringMap{
 "strimzi.io/kraft": pulumi.String("enabled"),
 "strimzi.io/node-pools": pulumi.String("enabled"),
 },
 },
 OtherFields: k8s.UntypedArgs{
 "kafka": pulumi.Map{
 "replicas": pulumi.Int(1),
 "version": pulumi.String("3.8.0"),
 "storage": pulumi.Map{
 "type": pulumi.String("ephemeral"),
 },
 "metadataVersion": pulumi.String("3.8-IV0"),
 "listeners": pulumi.Array{
 pulumi.Map{
 "name": pulumi.String("plain"),
 "port": pulumi.Int(9092),
 "type": pulumi.String("internal"),
 "tls": pulumi.Bool(false),
 },
 pulumi.Map{
 "name": pulumi.String("tls"),
 "port": pulumi.Int(9093),
 "type": pulumi.String("internal"),
 "tls": pulumi.Bool(true),
 },
 },
 "config": pulumi.Map{
 "offsets.topic.replication.factor": pulumi.Int(1),
 "transaction.state.log.replication.factor": pulumi.Int(1),
 "transaction.state.log.min.isr": pulumi.Int(1),
 "default.replication.factor": pulumi.Int(1),
 "min.insync.replicas": pulumi.Int(1),
 },
 },
 "entityOperator": pulumi.Map{
 "topicOperator": pulumi.Map{},
 "userOperator": pulumi.Map{},
 },
 },
 })
 if err != nil {
 return err
 }

 _, err = apiv1.NewCustomResource(ctx, "example-kafka-topic", &apiv1.CustomResourceArgs{
 ApiVersion: pulumi.String("kafka.strimzi.io/v1beta2"),
 Kind: pulumi.String("KafkaTopic"),
 Metadata: &metav1.ObjectMetaArgs{
 Name: pulumi.String("example-kafka-topic"),
 Namespace: pulumi.String("kafka"),
 Labels: pulumi.StringMap{
 "strimzi.io/cluster": pulumi.String("example-kafka-cluster"),
 },
 },
 OtherFields: k8s.UntypedArgs{
 "partitions": pulumi.Int(5),
 "replicas": pulumi.Int(1),
 "config": pulumi.Map{
 "retention.ms": pulumi.Int(7200000),
 "segment.bytes": pulumi.Int(1073741824),
 },
 },
 })
 if err != nil {
 return err
 }

 return nil
 })
}

using System.Threading.Tasks;
using Pulumi;
using Pulumi.Kubernetes.Core.V1;
using Pulumi.Kubernetes.Helm.V3;
using Pulumi.Kubernetes.Types.Inputs.Core.V1;
using Pulumi.Kubernetes.Types.Inputs.Helm.V3;
using Pulumi.Kubernetes.Types.Inputs.Meta.V1;
using System.Collections.Generic;
using Pulumi.Kubernetes.ApiExtensions;

class KafkaNodePoolArgs : CustomResourceArgs
{
 public string ApiVersion { get; set; }
 public string Kind { get; set; }
 public ObjectMetaArgs Metadata { get; set; }
 public Dictionary<string, object> Spec { get; set; }

 public KafkaNodePoolArgs(string apiVersion, string kind) : base(apiVersion, kind)
 {
 }
}

class KafkaClusterArgs : CustomResourceArgs
{
 public string ApiVersion { get; set; }
 public string Kind { get; set; }
 public ObjectMetaArgs Metadata { get; set; }
 public Dictionary<string, object> Spec { get; set; }

 public KafkaClusterArgs(string apiVersion, string kind) : base(apiVersion, kind)
 {
 }
}

class KafkaTopicArgs : CustomResourceArgs
{
 public string ApiVersion { get; set; }
 public string Kind { get; set; }
 public ObjectMetaArgs Metadata { get; set; }
 public Dictionary<string, object> Spec { get; set; }

 public KafkaTopicArgs(string apiVersion, string kind) : base(apiVersion, kind)
 {
 }
}

class MyStack : Stack
{
 public MyStack()
 {
 var kafkaNodePool = new Pulumi.Kubernetes.ApiExtensions.CustomResource("exampleKafkaNodePool", new KafkaNodePoolArgs("kafka.strimzi.io/v1beta2", "KafkaNodePool")
 {
 ApiVersion = "kafka.strimzi.io/v1beta2",
 Kind = "KafkaNodePool",
 Metadata = new ObjectMetaArgs
 {
 Name = "example-kafka-node-pool",
 Labels =
 {
 { "strimzi.io/cluster", "example-kafka-cluster" }
 }
 },
 Spec = new Dictionary<string, object>
 {
 { "replicas", 1 },
 { "roles", new List<string> { "controller", "broker" } },
 { "storage", new Dictionary<string, object> { { "type", "ephemeral" } } }
 }
 });

 var kafkaCluster = new Pulumi.Kubernetes.ApiExtensions.CustomResource("exampleKafkaCluster", new KafkaClusterArgs("kafka.strimzi.io/v1beta2", "Kafka")
 {
 ApiVersion = "kafka.strimzi.io/v1beta2",
 Kind = "Kafka",
 Metadata = new ObjectMetaArgs
 {
 Name = "example-kafka-cluster",
 Annotations =
 {
 { "strimzi.io/kraft", "enabled" },
 { "strimzi.io/node-pools", "enabled" }
 }
 },
 Spec = new Dictionary<string, object>
 {
 { "kafka", new Dictionary<string, object> {
 { "replicas", 1 },
 { "version", "3.8.0" },
 { "storage", new Dictionary<string, object> { { "type", "ephemeral" } } },
 { "metadataVersion", "3.8-IV0" },
 { "listeners", new List<Dictionary<string, object>> {
 new Dictionary<string, object> {
 { "name", "plain" },
 { "port", 9092 },
 { "type", "internal" },
 { "tls", false }
 },
 new Dictionary<string, object> {
 { "name", "tls" },
 { "port", 9093 },
 { "type", "internal" },
 { "tls", true }
 }
 }},
 { "config", new Dictionary<string, object> {
 { "offsets.topic.replication.factor", 1 },
 { "transaction.state.log.replication.factor", 1 },
 { "transaction.state.log.min.isr", 1 },
 { "default.replication.factor", 1 },
 { "min.insync.replicas", 1 }
 }}
 }},
 { "entityOperator", new Dictionary<string, object> {
 { "topicOperator", new Dictionary<string, object>() },
 { "userOperator", new Dictionary<string, object>() }
 }}
 }
 });

 var kafkaTopic = new Pulumi.Kubernetes.ApiExtensions.CustomResource("exampleKafkaTopic", new KafkaTopicArgs("kafka.strimzi.io/v1beta2", "KafkaTopic")
 {
 ApiVersion = "kafka.strimzi.io/v1beta2",
 Kind = "KafkaTopic",
 Metadata = new ObjectMetaArgs
 {
 Name = "example-kafka-topic",
 Labels =
 {
 { "strimzi.io/cluster", "example-kafka-cluster" }
 }
 },
 Spec = new Dictionary<string, object>
 {
 { "partitions", 5 },
 { "replicas", 1 },
 { "config", new Dictionary<string, object> {
 { "retention.ms", 7200000 },
 { "segment.bytes", 1073741824 }
 }}
 }
 });
}

class Program
{
 static Task<int> Main() => Deployment.RunAsync<MyStack>();
}

Summary

The Strimzi Operator demonstrates the power of Kubernetes Operators by providing full lifecycle management for Apache Kafka on Kubernetes. It takes care of the heavy lifting of deploying and managing Kafka clusters, making the Strimzi Operator a valuable tool that should be part of every Kubernetes-powered platform, as it covers a wide range of use cases.

Conclusion

In this blog post, I highlighted the importance of Kubernetes Operators for platform engineers and how they can harness the advanced automation capabilities of operators to simplify deploying, managing, and scaling applications and services on Kubernetes.

I provided some examples of advanced Kubernetes operators that I recommend, but if you want to try using Kubernetes Operators in your Kubernetes-powered platform, here are some great guides to get you started with Pulumi and Kubernetes:

Get Started with Pulumi

Use Pulumi's open-source SDK to create, deploy, and manage infrastructure on any cloud.

DevSecOps Game-Changer: Security Automation That Delivers Business Results

Sara Huddleston — Thu, 21 Nov 2024 07:16:30 +0000

Organizations are under constant pressure to deliver new products and features faster than ever. But speed alone isn’t enough—businesses must also navigate the complex challenges of ensuring security and managing infrastructure costs effectively.

Enter DevSecOps - the strategic integration of security practices into the DevOps workflow. By automating security processes, organizations can achieve improved speed, scalability, and business impact, all while ensuring security remains a priority.

Tivity Health, a leading health and fitness solutions provider, has embraced this DevSecOps approach using Pulumi, a modern infrastructure as code (IaC) platform. During PulumiUP 2024, David Giambruno, Tivity Health’s VP of Engineering and DevOps, shared how, by leveraging Pulumi, he led the transformation that continuously drives remarkable results in speed, cost savings, and security.

On this article:

The Beginning: From Data Center to the Cloud

Tivity Health’s journey began with a strategic decision to transition from a traditional data center environment to a cloud-native architecture. Rather than opting for a “lift and shift” approach, they made the bold choice to go directly to a cloud-native model, embracing the principles of DevSecOps along the way.

The need to automate infrastructure deployment and management was fundamental. Giambruno explained, “If you can’t automate it, we don’t need it.” This philosophy drove the team to seek out a solution that would not only streamline their operations but also empower their developers to focus on building innovative products for their customers.

Embracing Pulumi: The Power of Automation, Productivity, and Security

Tivity Health’s search for the right tool led them to Pulumi, a unified platform for all the infrastructure needs that allows teams to use general programming languages, such as TypeScript, Python, Java, and Go, to define and manage their cloud infrastructure. Giambruno and his team immediately recognized Pulumi’s ability to deliver on their key requirements:

Automation: Pulumi’s infrastructure as code (IaC) approach enabled Tivity Health to automate the deployment and management of its cloud environments, reducing the time and effort required for these tasks.
Productivity: using Pulumi’s general-purpose programming languages allowed developers to define, deploy, and manage infrastructure within their existing tools.
Security: Pulumi’s security features allowed Tivity Health to integrate security practices into its infrastructure deployment processes, reducing the risk of security breaches and ensuring compliance.
Cost Optimization: Pulumi’s ability to automate the spin-up and teardown of cloud environments on demand has led to significant cost reductions for Tivity Health.

Giambruno describes Pulumi as a “three-dimensional” tool, offering a versatile set of capabilities that have been instrumental in transforming Tivity Health’s operations. “The ability to use those dimensions in lots of different ways to do the automation is what really makes a difference to the teams,” he says.

Driving Business Impact Through Security Automation

By adopting Pulumi and DevSecOps automation, Tivity Health realized significant business benefits:

Speed and Agility: By automating its infrastructure deployment and management processes, Tivity Health has dramatically reduced the time required to spin up new environments or change existing ones. “We run it through automation and boom, it’s out, it’s done,” Giambruno says. This newfound speed and agility have empowered Tivity Health’s developers to focus on building products and features rather than getting bogged down in infrastructure-related tasks.
Cost Optimization: Tivity Health’s cloud-native approach and Pulumi’s automation capabilities have resulted in significant cost savings. The company estimates that its annual cloud spend has decreased from $9.5 million in its data center days to just $2 million—a staggering 79% reduction. These cost savings have allowed Tivity Health to redirect resources towards more strategic initiatives that drive business growth.
Improved Security and Compliance: Tivity Health’s DevSecOps strategy, anchored by Pulumi, has strengthened its security posture and compliance efforts. By integrating security directly into its infrastructure workflows, Tivity Health has improved its security posture. Automation ensures that security measures are enforced consistently across their cloud environments, reducing risks and improving compliance.

Fostering DevOps Culture Through Cross-Functional Collaboration

Using Pulumi provided more than technical benefits. It also enabled better collaboration between the development, security, and operations teams. By providing a common language and framework for infrastructure management, Pulumi has helped break down silos and align these traditionally disparate groups towards a shared goal of delivering secure, high-quality products faster.

Lessons Learned: Navigating the Cultural Shift

Transitioning to DevSecOps and cloud-native practices required a cultural shift at Tivity Health. Giambrono acknowledges that this cultural shift was not without its challenges. He emphasizes the importance of addressing the human element of change, offering the following advice for organizations embarking on a similar journey:

Start with a proof of concepts: Giambruno recommends beginning with a small-scale proof of concepts to demonstrate the capabilities and benefits of the new technologies and processes to help alleviate fears and build confidence among team members.
Empower developers and make them feel safe: By involving developers in the process and ensuring they feel comfortable with the new tools and workflows, Tivity Health gained user buy-in and overall support for the new DevSecOps approach.
Secure buy-in from business and financial stakeholders: Address the concerns of business and financial stakeholders early on, such as the impact on costs and the ability to deliver tangible results. This is crucial for securing the necessary support and resources.
Celebrate successes and build momentum: Giambruno highlights the importance of celebrating the team’s achievements along the way, even when there are bumps on the road, as this helps build enthusiasm and keep the momentum going.

The Future of DevSecOps and Pulumi at Tivity Health

As Tivity Health continues to refine its DevSecOps strategy, Giambruno is optimistic about the future. He envisions a world where the company’s ability to deploy new products and features rapidly will give Tivity Health a significant competitive edge, allowing it to better serve its customers and drive business growth.

Looking ahead, Giambruno is particularly enthusiastic about the potential of Pulumi’s AI-powered capabilities, which he believes will further streamline and optimize the company’s infrastructure management processes. “I’m super looking forward to the tests we’re going to do, like when we acquire someone and then taking them in, ‘Borg-ing’ them into our automation and seeing how much we can take out of their operating cost as fast as possible,” he says.

Tivity Health’s journey with Pulumi is a powerful example of how the right tool, DevSecOps strategy, and automation can drive tangible business results. By focusing on automation, security, and collaboration, organizations can achieve faster, cheaper, and better cloud deployments—putting them on the path to long-term success in an increasingly competitive, cloud-native world.

To learn more about Pulumi and how it can transform your software development and infrastructure management:

Get started with Pulumi Tutorials
Attend an upcoming workshop
Try out the Pulumi Neo code assistant to accelerate your infrastructure as code journey

YAML, Terraform, Pulumi: What’s the Smart Choice for Deployment Automation with Kubernetes?

Engin Diri — Mon, 18 Nov 2024 08:00:00 +0100

YAML and Kubernetes go together like peanut butter and jelly. While Kubernetes objects can be defined in JSON, YAML has emerged as the de facto standard.

It’s often the first tool developers encounter when diving into Kubernetes, and for good reason - its human-readable format makes it the preferred choice in most tutorials, documentation, and even production deployments.

But is it the best way to manage your Kubernetes resources? Let’s compare YAML, Terraform, and Pulumi and see which is best for managing your Kubernetes resources.

I also gave a talk before on No YAML! and what alternatives you have if you would only stick with the Go language:

Kubernetes Components and the Kubernetes API

Before we discuss the ways to manage Kubernetes objects, let’s look at the components of a typical Kubernetes cluster and their interactions.

Kubernetes Components. Credit: kubernetes.io

A Kubernetes cluster has two component categories: control plane and node. The control plane components manage the cluster. They consist of:

kube-apiserver - The API server is the front end for the Kubernetes control plane. It exposes the Kubernetes API.
etcd - A consistent, highly available key-value store. It is Kubernetes’ backing store for all API data.
kube-scheduler - Watches for newly created Pods with no assigned node and selects a node for them to run on.
kube-controller-manager - Runs a controller to implement the control loop.
cloud-controller-manager - Runs controllers that interact with the underlying cloud providers.

The node components run on every node in the cluster. They provide the runtime environment for the containers.

kubelet - An agent that runs on each node in the cluster. It ensures that pods are running.
kube-proxy - Maintains network rules on nodes.
Container Runtime - Is responsible for running containers.

The Kubernetes API is the central component in a Kubernetes cluster. It is the interface to the cluster and the only way to work with Kubernetes objects.

A Kubernetes object is a “record of intent”. It represents the desired state of the workload running on the cluster. The whole Kubernetes system will continuously work to ensure that the object exists.

YAML Manifests

If you are long enough exposed to Kubernetes, you will have seen a lot of YAML files. You can define many Kubernetes objects in a YAML file. These include Deployments, Services, ConfigMaps, Secrets, and more.

Let’s have a look at an example of a Deployment object in YAML for an Nginx web server:

Example

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
spec:
 replicas: 1
 selector:
 matchLabels:
 app: nginx
 template:
 metadata:
 labels:
 app: nginx
 spec:
 containers:
 - name: "nginx:latest"
 image: nginx

Pros and Cons of YAML

Pros

Simple: Kubernetes YAML files are easy to read and write.
The standard: YAML is the standard way to define Kubernetes objects. It is a first-class citizen in the kubectl command-line tool.

Cons

Multiple environments: If you have multiple environments, like development, staging, and production, you need to maintain multiple YAML files.
Too manual: You must create and update the YAML files by hand. Also, you must track changes across many files.
Not DRY: You cannot use the DRY principle (Don’t Repeat Yourself) in YAML files. If you have the same configuration in many files, you need to update all of them by hand.
No real abstraction: The advantage of a static configuration file is also its disadvantage. You cannot use dynamic values in the YAML files.
Need for tools from the ecosystem: You need to use tools like helm or kustomize to manage the complexity of many YAML files, environments, and templating.

To sum it up, YAML is a good choice for simple Kubernetes objects and small projects. But, if you have a complex project, and to be honest, most are, you need a better way to manage your Kubernetes resources.

Or to rephrase it: Friends don’t let friends manage Kubernetes resources with YAML.

Why should you avoid YAML? Credit: No YAML!

Terraform Kubernetes Provider

Terraform is an Infrastructure as Code tool. It lets you define and manage your infrastructure in a declarative way. It uses a high-level configuration language called HashiCorp Configuration Language (HCL). To manage Kubernetes objects with Terraform, use the Kubernetes provider. It allows you to define Kubernetes objects in Terraform HCL.

The Kubernetes provider allows you to define Kubernetes objects like kubernetes_deployment, kubernetes_service, kubernetes_config_map, kubernetes_secret, and more in code, leveraging the language features of Terraform. You can use, to a certain extent, loops, conditions, and variables in a way that is not possible with plain YAML files.

Let’s have a look at an example of a Deployment object in Terraform HCL for an Nginx web server:

Example

resource "kubernetes_deployment" "nginx" {
 metadata {
 name = "nginx-deployment"
 }

 spec {
 replicas = 1

 selector {
 match_labels = {
 app = "nginx"
 }
 }

 template {
 metadata {
 labels = {
 app = "nginx"
 }
 }

 spec {
 container {
 image = "nginx:latest"
 name = "nginx"
 }
 }
 }
 }
}

This is a very simple example of a Deployment object in Terraform HCL. Let’s add some complexity to the example by adding variables and loops:

Example with Variables and Loops

variable "namespace" {
 description = "The namespace to deploy the resources"
 type = string
 default = "default"
}

variable "nginx_image" {
 description = "The Nginx image to use"
 type = string
 default = "nginx:latest"
}

variable "replicas" {
 description = "The number of replicas to deploy"
 type = number
 default = 1
}

variable "number_of_deployments" {
 description = "The number of deployments to create"
 type = number
 default = 2
}

locals {
 nginx_image = var.nginx_image
 replicas = var.replicas
 namespace = var.namespace
 number_of_deployments = var.number_of_deployments
}

resource "kubernetes_deployment" "nginx" {
 for_each = {for i in range(local.number_of_deployments) : i => i}

 metadata {
 name = "nginx-deployment-${each.key}"
 namespace = local.namespace
 }

 spec {
 replicas = local.replicas
 selector {
 match_labels = {
 app = "nginx-${each.key}"
 }
 }

 template {
 metadata {
 labels = {
 app = "nginx-${each.key}"
 }
 }

 spec {
 container {
 image = local.nginx_image
 name = "nginx"
 }
 }
 }
 }
}

In this example, we can already see the advantage of Terraform over plain YAML files. We can use variables and loops to define multiple kubernetes_deployment objects in a more dynamic way.

Pros and Cons of Terraform

Pros

Dynamic: You can use variables, loops, and conditions in Terraform HCL. This lets you define your Kubernetes objects in a more dynamic way.
Abstraction: You can apply the DRY principle in Terraform HCL by defining and reusing modules across projects.
Environment management: By defining variables, you can manage multiple environments, like development, staging, and production. This is a more structured way to do it, without needing extra tools.

Cons

Complexity: Terraform is more complex than plain YAML files. You must learn Terraform’s HCL to define your Kubernetes objects.
DSL: Terraform is a Domain-Specific Language (DSL). You need to learn it to define your Kubernetes objects.
Testability: Testing Terraform code is harder. You need tools like Terratest and Kitchen-Terraform for it.
Helm Support: Terraform does not support Helm charts out of the box. You need to use the Helm provider to manage them with Terraform. This can add complexity to your Terraform code, and you need to keep track of the Helm provider dependency.
IDE Support: Terraform lacks the same IDE support as YAML files. You need plugins, like the Terraform Extension for Visual Studio Code, for syntax highlighting and autocompletion.

Terraform is a good choice for managing your Kubernetes resources if you have a complex project and you do not mind the complexity of the Terraform language. It gives you more flexibility and abstraction than plain YAML files, and you can manage multiple environments in a more structured way.

But is there a better way to manage your Kubernetes resources? Let’s have a look at Pulumi.

Pulumi and the Power of General Purpose Languages

Last but not least, let’s have a look at Pulumi. Pulumi is an Infrastructure as Code tool. It lets you define and manage your Kubernetes objects using general-purpose programming languages. Pulumi supports multiple languages like Python, Go, TypeScript, JavaScript, .NET, and JVM-based languages. This gives you all the benefits of a full programming language. It includes native IDE support, code completion, and debugging.

You need to install the Pulumi CLI. Then, create a new Pulumi project. Finally, add the Kubernetes library to it. It depends on the language you choose. You could use a package manager, like npm or pip.

Let’s have a look at an example of what a Deployment object would look like in all the supported languages.

import * as pulumi from "@pulumi/pulumi";
import * as k8s from "@pulumi/kubernetes";

const nginxDeployment = new k8s.apps.v1.Deployment("nginx-deployment", {
 metadata: {
 name: "nginx-deployment",
 },
 spec: {
 replicas: 1,
 selector: {
 matchLabels: {
 app: "nginx",
 },
 },
 template: {
 metadata: {
 labels: {
 app: "nginx",
 },
 },
 spec: {
 containers: [
 {
 name: "nginx",
 image: "nginx:latest",
 },
 ],
 },
 },
 },
});

import pulumi
import pulumi_kubernetes as k8s

nginx_deployment = k8s.apps.v1.Deployment(
 "nginx-deployment",
 metadata=k8s.meta.v1.ObjectMetaArgs(
 name="nginx-deployment",
 ),
 spec=k8s.apps.v1.DeploymentSpecArgs(
 replicas=1,
 selector=k8s.meta.v1.LabelSelectorArgs(
 match_labels={
 "app": "nginx",
 },
 ),
 template=k8s.core.v1.PodTemplateSpecArgs(
 metadata=k8s.meta.v1.ObjectMetaArgs(
 labels={
 "app": "nginx",
 },
 ),
 spec=k8s.core.v1.PodSpecArgs(
 containers=[
 k8s.core.v1.ContainerArgs(
 name="nginx",
 image="nginx:latest",
 ),
 ],
 ),
 ),
 ),
)

package main

import (
 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/apps/v1"
 corev1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/core/v1"
 metav1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/meta/v1"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 _, err := v1.NewDeployment(ctx, "nginxDeployment", &v1.DeploymentArgs{
 Metadata: &metav1.ObjectMetaArgs{
 Name: pulumi.String("nginx-deployment"),
 },
 Spec: &v1.DeploymentSpecArgs{
 Replicas: pulumi.Int(1),
 Selector: &metav1.LabelSelectorArgs{
 MatchLabels: pulumi.StringMap{
 "app": pulumi.String("nginx"),
 },
 },
 Template: &corev1.PodTemplateSpecArgs{
 Metadata: &metav1.ObjectMetaArgs{
 Labels: pulumi.StringMap{
 "app": pulumi.String("nginx"),
 },
 },
 Spec: &corev1.PodSpecArgs{
 Containers: corev1.ContainerArray{
 &corev1.ContainerArgs{
 Name: pulumi.String("nginx"),
 Image: pulumi.String("nginx:latest"),
 },
 },
 },
 },
 },
 })
 if err != nil {
 return err
 }
 return nil
 })
}

using Pulumi;
using Pulumi.Kubernetes.Types.Inputs.Core.V1;
using Pulumi.Kubernetes.Types.Inputs.Apps.V1;
using Pulumi.Kubernetes.Types.Inputs.Meta.V1;
using System.Threading.Tasks;
using Deployment = Pulumi.Deployment;

class MyStack : Stack
{
 public MyStack()
 {
 var nginxDeployment = new Pulumi.Kubernetes.Apps.V1.Deployment("nginxDeployment", new DeploymentArgs
 {
 Metadata = new ObjectMetaArgs
 {
 Name = "nginx-deployment",
 },
 Spec = new DeploymentSpecArgs
 {
 Replicas = 1,
 Selector = new LabelSelectorArgs
 {
 MatchLabels =
 {
 { "app", "nginx" }
 }
 },
 Template = new PodTemplateSpecArgs
 {
 Metadata = new ObjectMetaArgs
 {
 Labels =
 {
 { "app", "nginx" }
 }
 },
 Spec = new PodSpecArgs
 {
 Containers =
 {
 new ContainerArgs
 {
 Name = "nginx",
 Image = "nginx:latest",
 }
 }
 }
 }
 }
 });
 }
}

class Program
{
 static Task<int> Main() => Deployment.RunAsync<MyStack>();
}

package myproject;

import com.pulumi.Pulumi;
import com.pulumi.kubernetes.apps.v1.Deployment;
import com.pulumi.kubernetes.apps.v1.DeploymentArgs;
import com.pulumi.kubernetes.apps.v1.inputs.DeploymentSpecArgs;
import com.pulumi.kubernetes.core.v1.inputs.ContainerArgs;
import com.pulumi.kubernetes.core.v1.inputs.PodSpecArgs;
import com.pulumi.kubernetes.core.v1.inputs.PodTemplateSpecArgs;
import com.pulumi.kubernetes.meta.v1.inputs.LabelSelectorArgs;
import com.pulumi.kubernetes.meta.v1.inputs.ObjectMetaArgs;

import java.util.Map;

public class App {
 public static void main(String[] args) {
 Pulumi.run(ctx -> {
 var nginxDeployment = new Deployment("nginxDeployment", DeploymentArgs.builder()
 .metadata(ObjectMetaArgs.builder()
 .name("nginx-deployment")
 .build())
 .spec(DeploymentSpecArgs.builder()
 .replicas(1)
 .selector(LabelSelectorArgs.builder()
 .matchLabels(Map.of("app", "nginx"))
 .build())
 .template(PodTemplateSpecArgs.builder()
 .metadata(ObjectMetaArgs.builder()
 .labels(Map.of("app", "nginx"))
 .build())
 .spec(PodSpecArgs.builder()
 .containers(ContainerArgs.builder()
 .name("nginx")
 .image("nginx:latest")
 .build())
 .build())
 .build())
 .build())
 .build());
 });
 }

Now have a look into the more complex example with variables and loops in Pulumi. I am using TypeScript as an example, but you can of course use any of the Pulumi supported languages.

Example with Variables and Loops

import * as pulumi from "@pulumi/pulumi";
import * as k8s from "@pulumi/kubernetes";

let config = new pulumi.Config();

const namespace = config.get("namespace") || "namespace";
const nginxImage = config.get("nginxImage") || "nginx:latest";
const replicas = config.getNumber("replicas") || 1;
const numberOfDeployments = config.getNumber("numberOfDeployments") || 1;

for (let i = 0; i < numberOfDeployments; i++) {
 new k8s.apps.v1.Deployment(`nginxDeployment-${i}`, {
 metadata: {
 name: `nginx-deployment-${i}`,
 namespace: namespace,
 },
 spec: {
 replicas: replicas,
 selector: {
 matchLabels: {
 app: `nginx-${i}`,
 },
 },
 template: {
 metadata: {
 labels: {
 app: `nginx-${i}`,
 },
 },
 spec: {
 containers: [
 {
 name: "nginx",
 image: nginxImage,
 },
 ],
 },
 },
 },
 });
}

In this example, you can see how easy it is to define multiple Deployment objects with variables and loops syntax provided by TypeScript. This is a big advantage over plain YAML files and Terraform HCL. Blending the full power of a general-purpose programming language with the Kubernetes API is a natural process. Consider the possibilities of creating reusable functions, classes, and modules. You could share them across multiple projects and teams.

You might also like:

Pros and Cons of Pulumi

Pros

You can use general-purpose languages to define your Kubernetes objects. These include Python, Go, TypeScript, JavaScript, .NET, and JVM-based languages.

Full IDE support: You get full IDE support. It includes syntax highlighting, code completion, and debugging.
Testability: You can use the full power of your programming language to test your Pulumi code.
Abstraction: You can use the DRY principle in Pulumi. Define reusable functions, classes, and modules in your chosen programming language.
Environment management: You can manage multiple environments, like development, staging, and production, by defining config variables. This is a more structured way, without needing extra tools.
Kubernetes Helm Support: Pulumi supports Helm charts out of the box. You can manage Helm charts with Pulumi without needing extra tools or providers.
Programmatic execution of Pulumi: You can further blend Pulumi code into your projects using the Pulumi Automation API.

Cons

Runtime dependency: You must have the runtime of your chosen programming language installed on your machine, or use a containerised version of it in your CI/CD pipeline.
Follow best practices and compliance: Set up a code review process. It should ensure the Pulumi code follows the best practices of your chosen programming language and your organization’s additional best practices.
No possibility to convert one Pulumi language to another: If you start with one language, you can’t convert the Pulumi code to another language. You need to rewrite the Pulumi code in the new language.

YAML vs. Terraform vs. Pulumi - Results

Feature	YAML	Terraform	Pulumi
Readability	✅ Simple and human-readable	⚠️ Requires learning HCL	✅ Uses familiar programming languages
Environment Management	❌ Requires manual management of multiple files	✅ Structured management via variables	✅ Structured management via config variables
DRY Principle	❌ No reusability, requires manual updates	✅ Supports modules and reusable code	✅ Full support via functions, classes, modules
Dynamic Configuration	❌ Static configuration only	✅ Supports loops, conditions, variables	✅ Full programming language capabilities
IDE Support	✅ Good support	⚠️ Limited, requires plugins	✅ Full language-native IDE support
Testing	❌ Limited testing options	⚠️ Requires specialized tools (Terratest)	✅ Native language testing frameworks
Helm Support	✅ Native support	⚠️ Requires additional provider	✅ Built-in support
Learning Curve	✅ Low	⚠️ Medium (new DSL)	⚠️ Varies by language knowledge
Dependencies	✅ Minimal	⚠️ Terraform installation	❌ Language runtime required
Ecosystem Tools	❌ Requires additional tools (Helm, Kustomize)	✅ Integrated tooling	✅ Integrated tooling
Abstraction	❌ Limited	✅ Good	✅ Excellent

Legend:

✅ Good/Supported
⚠️ Partial/With limitations
❌ Poor/Not supported

Time to say Goodbye to YAML?

So, what’s the smart choice for deployment automation with Kubernetes? Is YAML still the best choice for Kubernetes? Or, is there a better way to manage your resources? I understand if you are a YAML fan. Despite complaints, it is still the most popular way to define Kubernetes objects. Many folks feel a sense of accomplishment when their YAML file works on the first try.

If you have a complex project, you will soon hit the limits of YAML. You want to manage your Kubernetes resources in a more structured, dynamic way while following best practices and compliance. Then, you keep adding more complexity to your YAML files. You do this by using tools like helm and kustomize to fix YAML’s flaws. Or, you adopt a hybrid approach with jsonnet, cuelang, or ytt. This makes it even more complex.

Giving up on YAML is not easy, but it does not mean that you have to give up on control. You can still have full control by using Terraform or Pulumi.

Conclusion

Now it’s time to make a decision. What’s the smart choice for deployment automation with Kubernetes? Is it YAML, Terraform, or Pulumi? For me, the smart choice is Pulumi. It gives you all the benefits of a general-purpose programming language. You gain full control, a more streamlined workflow, and the power to define all your infrastructure needs as code beyond Kubernetes. Especially on complex projects, use Pulumi. It’s better than dealing with many YAML files and the complexity of Terraform HCL.

Next time you start a new project, try Pulumi. See for yourself that it’s a smart choice. It’s an upgrade to your productivity and happiness.

But that’s my opinion. What’s your opinion? What’s your smart choice for deployment automation with Kubernetes?

If you want to try out Pulumi or play around to prove me wrong, you can start with:

Get Started with Pulumi

Use Pulumi's open-source SDK to create, deploy, and manage infrastructure on any cloud.

Pulumi Patterns and Practices Platform (P3): Some Assembly Required

Troy Howard — Mon, 11 Nov 2024 00:00:00 +0000

Note: This post discusses Pulumi Copilot, which Pulumi Neo has replaced. Learn about Neo →

Setting up an internal developer platform (IDP) can be a daunting task. There are a lot of tools out there that do some of the work for you, but none of them do all of it. Pulumi P3 is no different. Pulumi Patterns & Practices Platform (P3) is a reference architecture that we will be describing, and providing code for, through this series of articles.

We will never try to sell you on the idea that you can simply download a package, click next a few times, and achieve transformative success. That’s because any effective IDP will require some customization and integration to work within your environment.

Tools that purport to have it all figured out have only figured out how to manipulate you into a false narrative they have constructed in a vacuum, where all your organizational needs fit neatly into a few boxes they’ve decided on for you. And also charge you for. In addition to everything else you’re being charged for. Ultimately you’ll still need to build a lot yourself and these products rarely give guidance on how to do that.

When we first started hearing about our customers using Pulumi as an internal developer platform (IDP), we were frankly surprised, as our goals were primarily for Pulumi to be the best developer experience in infrastructure. But it makes sense. All the parts are there, some assembly required. Our goal with Pulumi Patterns and Practices Platform (P3) is to help with that assembly process.

Starting with our previous blog post on the topic, and continuing here, we are examining this use case, and attempting to formalize that into a collection of reusable components and some guidance on how you can skip the marketing pitches and pricing charts, and get straight to the hard work of building your own highly customized internal developer platform with Pulumi at its core.

Pulumi P3: Bill of Materials

Previously we identified the essential qualities of an effective IDP. Those were consistency, reproducibility, visibility, security and compliance, auditability, developer experience. In the last half of the post we discussed which parts of Pulumi could be used to meet those needs. That looks like:

Consistency: component resources, organization templates, drift detection
Reproducibility: stacks, deployments, versioned data
Visibility: Pulumi Insights, Pulumi Copilot
Security and Compliance: RBAC, GitHub Teams, SAML-SSO, Pulumi ESC, Pulumi Crossguard
Auditability: audit logging
Developer Experience: Python/Go/JavaScript/C#, popular IDE support, command-line tools, deeply hackable

That’s all great, and much of that is already built-into Pulumi without the need for you to do anything at all. So, what parts do you actually need to set up and configure? Here’s the bill of materials (BOM) to set up your own instance of Pulumi P3:

Bill of Materials:

Authentication and Identity Management:
- A GitHub organization that matches your Pulumi Cloud organization
- GitHub Teams users and roles that match your organizational structure and security needs
Secrets, Configuration, and Policy:
- Pulumi ESC environments to manage secrets across clouds
- Pulumi Crossguard policy packs that capture your company policies
Developer Experience:
- A set of reusable multi-language components for cross-cutting concerns/common services
- A set of organization templates that match your common use cases

Let’s go through each of those and briefly discuss what it looks like to set that up.

Authentication and identity management

We highly recommend using GitHub for code management. So much so that we have deeply integrated GitHub into Pulumi Cloud across a number of features. While we support alternatives such as GitLab, this will be the easiest and more feature-rich way to configure your platform.

In Pulumi Cloud, you have the ability to create organizations. A Pulumi Cloud organization can help you manage teams, roles, stacks, settings, and provide a dashboard across the entire organization. Pulumi Cloud also allows you to use a variety of identity providers to log in, including GitHub.

For simplicity’s sake, we suggest that you start with your GitHub organization. Create the GitHub organization, set up teams, and add members to those teams, assigning either admin or user roles to each member.

Next, in Pulumi Cloud, create an organization with exactly the same name as your GitHub organization, and choose GitHub as your identity provider. When a Pulumi organization is backed by a GitHub organization, then only members of that GitHub organization may be added to the Pulumi organization. Similarly, as soon as someone loses access to the GitHub organization, they will no longer have access to the Pulumi organization. You will also be able to import your GitHub teams directly into Pulumi Cloud. Then assign your users to the same roles in Pulumi Cloud teams as they have in the associated GitHub teams.

Figure: Mapping GitHub orgs, teams, and roles to Pulumi

Finally, you can map teams to stacks to grant access at specific permission levels. If you’re not familiar with Pulumi Stacks, a stack is a materialized instance of a specific set of cloud resources, as defined in a Pulumi program.

Pulumi ESC: Managing credentials, configuration, and other secrets

In order to deploy a stack you will need secrets such as cloud credentials and other configuration values that are provided to the deployment engine. Pulumi ESC is a secure system for managing secrets. They are organized by environments.

An example set of environments might look something like this:

Example: AWS login/credentials

# aws-creds ESC environment
values:
 creds:
 fn::open::aws-login:
 oidc:
 roleArn: arn:aws:iam::123456789012:role/pulumi-environments-oidc
 sessionName: pulumi-environments-session
 duration: 1h
 environmentVariables:
 AWS_ACCESS_KEY_ID: ${aws.creds.accessKeyId}
 AWS_SECRET_ACCESS_KEY: ${aws.creds.secretAccessKey}
 AWS_SESSION_TOKEN: ${aws.creds.sessionToken}

Example: Default production environment to use us-east-1 region

# aws-production ESC environment
imports:
 - aws-creds
values:
 aws:
 region: us-east-1
 pulumiConfig:
 aws:region: ${aws.region}

Example: Default staging environment to use us-west-2 region

# aws-staging ESC environment
imports:
 - aws-creds
values:
 aws:
 region: us-west-2
 pulumiConfig:
 aws:region: ${aws.region}

Here we define three environments for AWS:

aws-creds: sets up login via OpenID Connect (OIDC) and provides standard environment variables containing AWS credentials to the Pulumi program
aws-production: imports everything from aws-creds then sets the region to us-east-1
aws-staging: does the same, but sets the region to us-west-2.

Using that in a Pulumi program is as simple as adding the following settings to your stack config:

# Pulumi.staging.yaml
environment:
 - aws-staging

In this manner, you can configure separate environments for staging and production, with a complex set of configuration values and secrets, using different environments for each one. From the developer’s perspective they would only need to change aws-staging to aws-production when they go to deploy their stack.

Another strong benefit of this approach is that all secrets will be encrypted both in-flight and at-rest. Pulumi waits until the last moment to decrypt secrets at runtime. By default, uses automatic, per-stack encryption keys provided by Pulumi Cloud, but you could use a provider of your own choosing instead.

Pulumi Crossguard: Policy-as-Code

Pulumi Crossguard allows you to check and enforce policies on your deployments. Policies are rules, written in code, that run during deployments to check that the resources are conforming to the necessary criteria. You can use off-the-shelf policies like AWSGuard and Pulumi Compliance-Ready Policies or write your own.

Either way you end up with a policy pack that you can apply to your entire Pulumi organization via Pulumi Cloud.

Here’s an example policy that checks for the presence of a tag user:Stack on a S3 bucket:

from pulumi_policy import (
 EnforcementLevel,
 PolicyPack,
 ResourceValidationPolicy,
)

def s3_check_required_tags(args, report_violation):
 if args.resource_type == "aws:s3/bucket:Bucket":
 if ("tags" not in args.props or
 "user:Stack" not in args.props["tags"]):
 report_violation("S3 Bucket is missing required user:Stack tag.")

PolicyPack(
 name="bucket-tags",
 enforcement_level=EnforcementLevel.MANDATORY,
 policies=[
 ResourceValidationPolicy(
 name="s3-tags",
 description="Ensure required tags are present on S3 buckets.",
 validate=s3_check_required_tags,
 ),
 ],
)

If the tag isn’t on the resource, it blocks the deployment with an error message. The error message would look something like this:

Policies:
❌ bucket-tags@v0.0.1
- [mandatory] s3-tags (aws:s3/bucket:Bucket: my-bucket)
Ensure required tags are present on S3 buckets.
S3 Bucket is missing required user:Stack tag.

This allows you to implement company-specific policies that can be as simple or complex as you need them to be.

To apply this across your entire organization, you can publish this policy pack to Pulumi Cloud, with the following commands:

$ pulumi policy publish myorg
$ pulumi policy enable myorg/my-policy-pack latest

Some other great features of Crossguard are the ability to version policies, define multiple policy groups, and create remediation policies that automatically fix policy violations when possible. We will cover these topics in a future post where we go deeper on how to use policies effectively.

Multi-Language Components (MLC)

In Pulumi, a component resource is something that your developers can import in their Pulumi program, instantiate and modify. These are made available via a provider, which is in turn, made available to Pulumi via a provider package. There are many of these already available in the Pulumi Registry. However, in a custom internal developer platform you can define your own components, and bake appropriate settings/configuration directly into the underlying code.

A multi-language component (MLC) is even more useful. You can author your component in your language of choice and then generate a SDK that surfaces that component into all of the languages that Pulumi supports. For example, your platform team might be comfortable writing in Python, but the developers that write your microservices might use Go, and the developers who write the front-end apps might use Node.js. Both teams might need to deploy apps and infrastructure into your Kubernetes cluster. With multi-language components you can write a component in Python that abstracts away all the details of your custom Kubernetes cluster, and make that available to both teams, in both Go, Node.js, and any other language that Pulumi supports.

To build a MLC, you’ll follow these basic steps to create the component, provider, provider package, and generate the multi-language SDK:

Fork one of the component provider boilerplate repos for Python, TypeScript, or Go.
Update the package and code-generator configuration files, which name your component and package, define the inputs and outputs, and declare the dependencies.
Implement the component in your preferred language.
Generate an SDK for the other languages.
Deploy the package.

Here’s a quick example of creating a custom S3 Bucket component in Python, that complies with the tagging policy we built earlier:

from pulumi_aws import s3
import pulumi

class TaggedBucket(pulumi.ComponentResource):

 def __init__(self, name, opts = None):
 super().__init__('mycorp:index:TaggedBucket', name, None, opts)

 # Create a bucket and add a custom tag to it.
 bucket = s3.Bucket(
 f'{name}-bucket',
 tags={
 'user:Stack': pulumi.get_stack()
 },
 opts=ResourceOptions(parent=self))

 self.register_outputs({
 'bucket': bucket,
 'websiteUrl': bucket.website_endpoint,
 'bucketDnsName': bucket.bucketDomainName
 })

This shows the component implementation in isolation from the provider/packaging/SDK boilerplate. In this code sample, we’re creating a component called TaggedBucket that creates a S3 bucket, and adds a tag user:Stack with the current stack name as its value. A developer could now use this in a TypeScript Pulumi program as such, and this resource would automatically have the tags added to it.

import * as mycorp from "mycorp/mycorp-components";

const taggedBucket = new mycorp.TaggedBucket("example");

export const bucket = taggedBucket.bucket;
export const url = taggedBucket.websiteUrl;
export const dnsName = taggedBucket.bucketDnsName;

If you want to see how to create MLCs in more detail, check out this video that walks you through the entire process, and this repo for the code shown in the video. In a follow-up post in this series, we will build some reference MLCs that do things like implement a time-to-live (TTL) for stacks in your staging environment, automate drift detection, and automatically instrument your developer’s deployments with observability tools integrated by default.

Organization templates and the New Project Wizard

The final piece that ties all this together are organization templates. You may have used some of our built-in templates when you learned how to use Pulumi. These are great for basic use cases, but the real magic happens when you bring together your custom components and custom security environments to create personalized templates which represent the internal use cases for your organization.

Pulumi’s New Project Wizard reads these templates and provides an in-browser way to create a new project and deploy it. Running one of these templates will commit and push code to GitHub, and trigger an initial deployment – all in a few clicks and without leaving the browser.

Each template needs the following parts:

A Pulumi.yaml describing the template and its configuration values
A GitHub repo (public or private) containing the code for the templated Pulumi program

Here’s an example of a simple template using the components and environments we described above.

# Pulumi.yaml
name: ${PROJECT}
description: ${DESCRIPTION}
runtime: python
template:
 description: A Python Pulumi program that creates a tagged bucket.

"""__main__.py: A minimal Pulumi program"""

import pulumi
import mycorp

# Create an AWS resource (S3 Bucket)
tagged_bucket = mycorp.TaggedBucket('my-bucket')

# Export the name of the bucket
pulumi.export('bucket_name', tagged_bucket.bucket)

# Pulumi.production.yaml
environment:
 - aws-production

# Pulumi.staging.yaml
environment:
 - aws-staging

The Pulumi.yaml sets up the template and will populate the name and description from the settings provided during the template dialogue. The custom TaggedBucket component will create an S3 bucket, which will be tagged with user:Stack set to the name of the stack. Default stack configurations are provided for the staging and production environments which map to our two ESC environments, aws-production and aws-staging.

How it all works together

With all of that in place, from the developer’s perspective, all they need to do is create a new project from the template, answering three questions: the stack name, the name of the project, and an optional description.

If the developer names the stack staging it will automatically apply the aws-staging ESC environment, which will include the AWS credentials and set the region to us-west-2. However, if the developer names the stack production it will get the aws-production ESC environment setting it to use the us-east-1 region. The name of the stack will be stored in a tag on the resource.

Pulumi Crossguard will apply the bucket-tags policy check to see if the resource has the required user:Stack tag set and will allow the deployment to proceed only if it has that tag. If a developer created a standard S3 Bucket instead of using our internal TaggedBucket component, and failed to add the required tag, they will get an error message from our custom policy when they try to deploy.

Later, we can create additional automation that might do something like delete anything tagged staging after two weeks, or run drift detection on anything tagged production. We will be exploring these concepts in more detail in later posts.

More to Come

While setting up the Pulumi Patterns and Practices Platform (P3) reference architecture is not a simple click-to-deploy, hopefully this high-level tour of the various parts you need to assemble shows that really, it is only a matter of creating a few carefully constructed YAML files and snippets of code, and wiring them together properly. You can start small and build out your platform over time.

The next few posts in this series will go beyond these simple examples, showing much more complicated implementations of all of these pieces, and recommend some best practices for managing your infrastructure with this platform.

And if you are already ready to get your hands on Pulumi after this introduction, feel free to create an account and follow some of our Getting Started guides to see how easy simple use cases are and begin to imagine how that same developer experience will scale up to your entire organization.

To learn more, you can watch the following video which provides a high level overview of how Pulumi works:

*{padding:0;margin:0;overflow:hidden}html,body{height:100%}img{position:absolute;width:100%;top:0;bottom:0;margin:auto}">

Pulumi Cloud

The Pulumi Cloud is a fully managed service that helps you adopt Pulumi’s open source SDK with ease. It provides built-in state and secrets management, integrates with source control and CI/CD, and offers a web console and API that make it easier to visualize and manage infrastructure. It is free for individual use, with features available for teams.

Create an Account

The Guide to Platform Engineering: 7 Steps to Get It Right

Sara Huddleston — Tue, 22 Oct 2024 07:47:03 +0000

In today’s fast-paced digital landscape, organizations are increasingly adopting platform engineering to optimize their software delivery and operations. Gartner predicts that by 2026, 80% of large software engineering organizations will have platform engineering teams to provide reusable services, components, and tools for application delivery. Additionally, by 2027, 80% of large enterprises will leverage platform engineering to scale DevOps initiatives in hybrid cloud environments effectively.

This shift is driven by the rise of cloud adoption, where many enterprises face the challenge of uncoordinated application teams deploying workloads in different ways across various cloud platforms. This siloed approach often results in a lack of standardization, security risks, and operational inefficiencies.

Platform engineering offers a strategic solution to these issues. This guide provides the essential steps to successfully implement platform engineering, from laying the foundation to scaling internal developer platforms (IDPs) for future growth.

On this article:

Step 1: Securing Executive Buy-in

The first step in your platform engineering journey is securing executive buy-in. This high-level support is essential, as platform engineering teams must create an organization-wide strategy that integrates internal developer portals (IDPs) and self-service capabilities. Leadership needs to understand how platform engineering can address inefficiencies caused by siloed application teams and uncoordinated cloud deployments.

To do this, present a clear roadmap with measurable outcomes, such as improved delivery speed and security. Use metrics like DORA (Deployment Frequency, Lead Time, Mean Time to Recovery) to demonstrate how platform engineering enhances security, standardization, and efficiency. Outline the required resources (headcount, budget, tooling) and align the project with business objectives.

Step 2: Staffing the Platform Engineering Team

Once you have executive backing, the next step is to assemble your platform engineering team. This team will develop and maintain your internal developer platform (IDP), ensuring it offers the organization secure, scalable, and self-service solutions.

Successful platform engineering teams are characterized by a strong customer focus, empathy for the needs of application teams, and the ability to act as the “glue” that binds the organization together. Key roles and responsibilities within the platform team include:

Customer-facing roles: Serve as the primary point of contact for application teams, understanding their needs and advocating for their requirements within the platform.
Infrastructure expertise: Possess deep knowledge of the underlying infrastructure, whether on-premises or in the cloud, to ensure the platform is reliable and scalable.
DevOps and automation skills: Leverage infrastructure as code (IaC) tools and techniques to automate the provisioning and management of the platform.
FinOps and cost optimization expertise: Understand the organization’s financial systems and processes to ensure the platform is cost-effective and aligned with budgetary constraints.
Software development capabilities: Develop the platform’s core components, including self-service interfaces and reusable infrastructure modules, using best practices in software engineering.

By assembling a team with this diverse set of skills and a customer-centric mindset, you’ll be well-positioned to build a platform that truly meets the needs of your application teams.

Step 3: Defining the Platform Mandate

Next, clearly define the platform team’s mandate to set expectations. This document should outline the platform’s purpose, the services it provides, and how it supports internal developer portals (IDPs) and self-service capabilities.

The platform mandate should serve as a central reference point for the platform team and its customers, ensuring everyone is aligned on the team’s mission and its value. Key elements to include in the platform mandate include:

Introduction: A high-level overview of the platform team’s purpose and the organizational outcomes it aims to achieve.
Supported systems: A list of the infrastructure, services, and tools that the platform team is responsible for managing and supporting.
Support model: Details on how application teams can access platform services, including any self-service capabilities and the team’s response times for different types of requests.
Team structure: An overview of the platform team’s members and their areas of expertise, making it easy for application teams to identify the right point of contact.

A well-defined mandate aligns the team and its customers with the platform’s value and purpose.

Step 4: Implementing the Pre-Production Pipeline

With a mandate in place, begin building the core capabilities, starting with a pre-production pipeline. This pipeline standardizes how application code moves from development to deployment, emphasizing security and consistency.

Key components of the pre-production pipeline include:

Version control: Implement a centralized version control system to manage application code and infrastructure as code (IaC) configurations.
Continuous integration (CI): Automate the build and testing of application artifacts, such as container images or deployment packages.
Artifact management: Provide a secure and versioned repository for storing and distributing the application artifacts produced by the CI process.
Static analysis: Integrate tools that can scan application code and dependencies for security vulnerabilities and other issues.
Application delivery: Automate the deployment of application artifacts to pre-production environments, such as staging or testing.

By establishing a standardized pre-production pipeline, you’ll ensure that all application teams follow a consistent, secure, and efficient process for getting their code into a production-ready state.

Step 5: Embracing Infrastructure as Code

Leveraging infrastructure as code (IaC) is crucial for managing the platform’s infrastructure. It enables consistent, scalable, and secure operations by automating the provisioning of resources, monitoring, and enforcing security policies.

Key areas where IaC can be applied within the platform include:

Foundational infrastructure: Provision and manage the underlying cloud resources, such as virtual networks, storage, and compute, that form the platform’s foundation.
Runtime platforms: Deploy and configure the runtime environments where application workloads will be executed, such as Kubernetes clusters or serverless functions.
Observability and monitoring: Set up the logging, metrics, and alerting systems that provide visibility into the platform’s health and performance.
Security and compliance: Implement security controls, such as secrets management and access policies, to ensure the platform meets regulatory and organizational requirements.
Pipelines and automation: Use IaC to define and version-control the platform’s own deployment and management pipelines, ensuring consistency and repeatability.

With infrastructure as code, the platform engineering team can ensure reliable, scalable, and secure infrastructure across the organization.

Step 6: Implementing Policy as Code

Alongside your IaC efforts, it’s important to set up a robust policy-as-code framework within your platform. Policy-as-code allows you to enforce security, compliance, and operational policies programmatically. This provides governance at scale, ensuring all teams follow the same rules.

Policy as code can be applied in two key ways:

Preventative controls: Implement policies that proactively validate and reject non-compliant infrastructure changes before they are provisioned, providing fast feedback to application teams.
Detective controls: Establish policies that continuously monitor the deployed infrastructure, triggering alerts or remediation actions when deviations from the desired state are detected.

By combining IaC and policy as code with self-service provisioning, you maintain security and compliance while giving teams autonomy.

Build your internal developer platform

Give developers self-service infrastructure with reusable components, golden paths, and governance built in using Pulumi IDP.

Explore Pulumi IDP

Step 7: Evolving Towards Self-Service

As your platform matures, the ultimate goal is to empower your application teams with self-service capabilities, allowing them to provision the infrastructure and resources they need quickly and autonomously. This self-service model can take various forms, from pre-defined infrastructure modules to fully automated deployment pipelines.

When implementing self-service capabilities, keep the following platform engineering best practices in mind:

Start small and iterate: Don’t try to boil the ocean. Begin with a few well-defined use cases, such as CI/CD pipelines or database provisioning, and gradually expand the self-service offerings as your platform team gains experience and confidence.
Focus on user experience: Ensure that the self-service interfaces, whether web-based or command-line, are intuitive and easy to use. Gather feedback from application teams and continuously refine the user experience.
Maintain stability and reliability: Even with self-service, the platform team is responsible for ensuring the underlying infrastructure and services remain stable and reliable. Implement robust monitoring, alerting, and incident response processes to maintain platform health.
Embrace a product mindset: Treat the platform as a product, with the application teams as your customers. Continuously gather feedback, measure key performance indicators, and iterate on the platform’s capabilities to meet evolving needs.

By gradually transitioning towards a self-service model, you’ll empower your application teams to move faster while maintaining the necessary guardrails and controls to ensure the platform’s long-term success.

Conclusion: Embracing the Platform Engineering Journey

Building a successful platform engineering strategy involves following a clear roadmap. But remember, implementing the platform engineering strategy is a journey, not a destination. By following the steps outlined in this guide, you’ll be well on your way to building a robust, secure, scalable, and customer-centric internal developer platform (IDP) that empowers your organization to deliver software more efficiently and effectively.

With the right approach and mindset, your platform engineering efforts will become a strategic enabler for your organization’s digital transformation.

Build secure, scalable platforms with confidence—register for the Platform Engineering Course

Frequently Asked Questions

What is Platform Engineering?

There are many definitions for platform engineering, one of which is designing, building, and maintaining internal platforms that streamline software delivery by providing reusable tools, services, and workflows for developers. It focuses on scalability, efficiency, and self-service capabilities for internal teams.

For a more in-depth explanation of real-world use cases, see What is platform engineering.

Who are the Platform Customers?

The platform customers are the end users, typically internal teams (e.g., application developers and DevOps engineers), who use the platform’s tools and services to build, deploy, and manage software.

What is an Internal Developer Platform (IDP)?

A centralized platform that offers developers the tools and environments they need to build, test, and deploy applications. It abstracts away the complexity of underlying infrastructure, allowing teams to focus on coding and delivery.

What is a Platform Team?

The platform engineering team is a dedicated group of engineers responsible for managing the internal platform. They ensure the platform meets the needs of the organization, providing reliability, security, and scalability.

What is a Self-Service Infrastructure?

A platform feature that allows development teams to provision, configure, and manage infrastructure resources on demand without relying on other teams, fostering agility.

What is Infrastructure as Code (IaC)?

The process of managing and provisioning infrastructure through code, allowing infrastructure to be versioned, automated, and managed consistently across environments.

For a more in-depth explanation, see the What is Infrastructure as Code? page.

What is Policy as Code (PaC)?

Policy as Code (PaC) defines security, compliance, and operational policies in code to automate their enforcement across infrastructure and application deployments.

What is Developer Experience (DevEx)?

The overall experience developers have with using the platform, tools, and workflows provided by platform engineering. Optimizing DevEx ensures that developers can work more efficiently and effectively.

For a more in-depth explanation, read Beyond Productivity: Developer Experience is Business Critical.

Unified and Programmatic Approach to Infrastructure Management at BMW Using Pulumi

Sara Huddleston — Thu, 03 Oct 2024 09:52:10 +0000

In the ever-evolving world of automotive technology, BMW has been at the forefront of innovation, seamlessly integrating software into the heart of their vehicles. As cars become increasingly complex, with a growing emphasis on connectivity, over-the-air upgrades, and brand-specific user experiences, the need for a robust and scalable software development approach has become paramount.

Enter the BMW Software Factory, a platform that aims to empower the company’s developers and provide them with a superior development experience. At the core of this initiative is the adoption of Pulumi, a modern infrastructure as code (IaC) solution that has transformed the way BMW manages its software ecosystem.

On this article:

The Challenges of a Sprawling Software Landscape

BMW’s software journey has been a testament to the exponential growth of automotive technology. What started with simple engine controllers has evolved into a complex network of electronic control units (ECUs) scattered throughout the vehicle. As the software footprint continues to expand, BMW recognized the need for a unified and efficient approach to software development and deployment.

The company’s initial efforts involved introducing a platform called “Code Craft,” which provided a comprehensive stack of services to support the software development lifecycle. This stack included a GitHub Enterprise application for source code management, a Gerrit system for Android-based developments, a continuous integration (CI) pipeline, artifact stores, build caching, and various other tools and services.

However, as the demand for software-driven features grew, the complexity of managing this sprawling ecosystem became increasingly challenging. BMW found itself grappling with the need to scale its infrastructure, navigate network limitations across multiple data centers, and adapt to the ever-changing landscape of cloud computing.

The Evolution of BMW’s Software Development Toolchain

BMW’s journey to streamline its software development process has been gradual and iterative. The company’s initial approach involved using Ansible for deployment and a custom-built deployment scripting solution for its OpenShift cluster.

As the complexity of the platform increased, BMW turned to Helm and Kubernetes to manage its containerized services. However, as the company ventured into the public cloud, the limitations of these tools became apparent. The team recognized the need for a more comprehensive and scalable solution to manage their infrastructure as code.

At this critical juncture, BMW discovered Pulumi. This modern IaC solution offered a unique advantage – the ability to leverage a full-fledged programming language, Python, to define and manage their infrastructure. This shift proved to be a game-changer, allowing BMW to leverage its expertise in Python and benefit from the rich ecosystem of libraries and tools available in the Python community.

Embracing Pulumi: Streamlining Infrastructure Management

BMW’s adoption of Pulumi was a strategic move that aimed to address the growing complexity of its software ecosystem. By transitioning from a patchwork of tools to a unified IaC solution, the company was able to streamline its infrastructure management and improve developer productivity.

Shared Modules: Promoting Reusability and Best Practices

One of BMW’s key initiatives was developing a shared modules library, which allowed the team to abstract the complexity of various infrastructure components, such as databases, and provide a consistent and user-friendly interface for their developers.

By leveraging Pulumi’s Python bindings, BMW was able to create reusable modules that encapsulated best practices and sensible defaults, making it easier for developers to provision and manage infrastructure resources. BMW used Pydantic, a data validation library, to define schema-based configurations for its infrastructure. These were then integrated into its IDEs, providing developers with auto-completion and validation support.
This approach not only accelerated the development process but also ensured that the infrastructure deployed across the organization adhered to consistent security and compliance standards.

Transformation Features: Protecting Legacy Services

As part of their software factory, BMW also faced the challenge of integrating legacy services that did not natively support modern authentication and authorization mechanisms, such as OpenID Connect (OIDC).
To address this, BMW leveraged Pulumi’s transformation features to seamlessly inject an OAuth2 proxy into their deployments, providing a secure and consistent way to protect these services without requiring extensive modifications to the underlying applications.
By encapsulating this functionality within a shared module, BMW was able to apply the OAuth2 proxy to multiple services, ensuring a consistent and secure access control layer across their software ecosystem.

Policy Enforcement: Ensuring Compliance and Security

One key benefit of Pulumi’s IaC approach is the ability to define and enforce policies across the organization, ensuring that infrastructure deployments adhere to security and compliance standards. BMW has leveraged Pulumi’s policy-as-code capabilities to implement mandatory checks, such as ensuring that all S3 buckets are encrypted at rest, preventing the deployment of non-compliant resources.

By integrating these policy checks into their deployment workflows, BMW has shifted security and compliance concerns to the left, addressing issues early in the development process and reducing the risk of costly post-deployment remediations.

The Benefits of Pulumi: Accelerating Development and Improving Maintainability

BMW’s adoption of Pulumi has yielded significant benefits, transforming the way the company approaches software development and infrastructure management.

Accelerated Development with Shared Modules

The implementation of shared modules has been a game-changer for BMW. It allows developers to leverage pre-built and tested infrastructure components without having to reinvent the wheel. This has resulted in a significant acceleration of the development process, as teams can focus on building their applications rather than grappling with the complexities of infrastructure provisioning.

Improved Maintainability and Consistency

By centralizing infrastructure management within the shared modules, BMW has ensured that best practices and security standards are consistently applied across the organization. This has not only improved the overall maintainability of the software ecosystem but has also reduced the risk of security and compliance violations.

Leveraging Python’s Ecosystem

BMW’s decision to leverage Pulumi’s Python bindings has been a strategic advantage, as the company was able to tap into the rich ecosystem of Python libraries and tools. This has enabled the team to seamlessly integrate Pulumi with their existing Python-based toolchain, including dependency management, testing frameworks, and code quality tools, further enhancing the development experience.

Streamlined Cloud Migration

As BMW continues to expand its use of public cloud services, Pulumi has played a crucial role in simplifying the migration process. By providing a consistent IaC approach across on-premises and cloud environments, Pulumi has enabled BMW to manage its infrastructure in a unified manner, reducing the complexity and overhead associated with multi-cloud deployments.

The Future of BMW’s Software Factory: Embracing the Cloud

Looking ahead, BMW’s Software Factory is poised to take the next step in its evolution, with plans to transition away from the self-hosted backend and embrace cloud-native services. This strategic move aims to further improve developer productivity and reduce the internal effort required to maintain the underlying infrastructure.

By leveraging the expertise and reliability of cloud service providers, BMW can focus on delivering innovative software features to their customers while the cloud providers handle the operational aspects of running the necessary services.

As BMW continues to push the boundaries of automotive software, Pulumi’s role in its Software Factory will only become more crucial. By providing a scalable and flexible IaC solution, Pulumi empowers BMW’s developers to innovate with confidence and be secure in the knowledge that their infrastructure is managed consistently and in alignment with the company’s security and compliance standards.

Conclusion: Unlocking the Future of Automotive Software

BMW’s journey with Pulumi in the Software Factory showcases the power of modern IaC solutions in navigating the complexities of the automotive software landscape. By embracing a unified and programmatic approach to infrastructure management, BMW has accelerated development, improved maintainability, and ensured compliance across its sprawling software ecosystem.

As the automotive industry continues to evolve, with cars becoming increasingly software-driven, the lessons learned by BMW can serve as a blueprint for other organizations looking to streamline their software development and deployment processes. By leveraging the capabilities of Pulumi and other cutting-edge technologies, the future of automotive software is poised to be more efficient, secure, and responsive to the ever-changing needs of both manufacturers and consumers.

To learn more about Pulumi and how it can transform your software development and infrastructure management:

Get started with Pulumi Tutorials
Attend an upcoming workshop
Try out the Pulumi Neo code assistant to accelerate your infrastructure as code journey

Accelerate, Scale and Secure AI Innovation with Pulumi Platform Engineering

Marlowe Fenne — Tue, 01 Oct 2024 00:00:00 +0000

Note: This post discusses Pulumi Copilot, which Pulumi Neo has replaced. Learn about Neo →

As leadership teams continue to bet big on AI, the tradeoffs between how much to invest and when to expect a reasonable return are ever-present. While exploring scenarios for accelerating this return on investment, organizations are discovering some unique ways to accelerate their AI payback with Platform Engineering.

As innovation and ROI pressures mount, how are savvy tech organizations using Platform Engineering to get more competitive advantage - and perhaps a quantum leap - from their AI investments?

Changing the Rules of the AI Game

Platform Engineering is transforming how organizations automate, secure and manage their resources - particularly in AI environments that require substantial compute, memory and cloud infrastructure.

Save Money on Resources

AI’s wide array of disparate technology resources make it an ideal use case for Platform Engineering. Cloud innovators are unifying AI layers, including web frameworks, LLMs, containers, databases, secrets, policies, and configurations, into streamlined Python libraries. Then they leverage these libraries to efficiently manage infrastructure stacks through code.

For example, platform teams can now manage Google Dialogflow, LangChain Llama and other stacks using one platform, and then repurpose these unified resources across projects. Plus, they can author infrastructure as code, using programming languages they know and love, and write statements to define infrastructure using their own IDE’s, with autocomplete, type checking, and documentation. These teams deliver higher quality projects with fewer errors (and better testing), and are frequently happier, more productive, and more innovative.

With this “work smarter, not harder” approach, there’s also less work, as there’s a lot less code required to run infrastructure. In many cases, code can be consolidated by 50% or more, and it can be leveraged across entire organizations without tedious, error-prone copying and pasting.

All these efficiencies combine to reduce cloud, compute and storage costs, so you can re-invest the savings into more AI innovation and/or more scale across your organization.

Accelerate Time to Market

While speed is a byproduct of these efficiencies, it’s also a key reason to leverage platform engineering for AI. The most recognizable names in the AI industry have many attributes in common, including innovation and speed to market. Many of these leaders leverage Pulumi to achieve this decisive advantage.

Snowflake is a great example of this approach. “There’s no question that, if we had gone down the traditional infrastructure automation route, it would have taken us a week or a week and a half to do one deployment of the cluster, end to end,” said Raman Hariharan, Director of Cloud Platform Engineering. “Plus, that deployment wouldn’t be repeatable, testable or scalable. It would have been a mad scramble to meet our deadline. When we demonstrated to people that what used to take a week and a half now, with [platform engineering], took under a day, they were shocked.” Read the full Snowflake case study here.

Pulumi customers regularly rave about their results with platform engineering - many citing 5 to 10X faster time to market. See more case studies here.

Another benefit: more freedom to innovate with more resources

This speed and efficiency also frees up valuable time for engineering staff to work on the creative new projects that drive innovation and new revenue generating applications. By combining generative AI with Pulumi’s insights and knowledge of your entire cloud infrastructure, users are solving a wide array of next-generation cloud development challenges.

Joren McReynolds, VP of Engineering at Panther Labs said, “We are now in the best position to deliver new innovative solutions to our customers and to do so quickly, which is huge for a startup such as ours that needs to accelerate our efforts and to do so efficiently and seamlessly.”

To make this process even more efficient, a new AI-driven conversational chat interface called Pulumi Copilot is now integrated throughout Pulumi Cloud, enabling users to quickly accomplish a variety of cloud infrastructure management tasks by leveraging the power of large language models plus the rich capabilities of Pulumi Cloud.

“At Unity Aura we manage hundreds of infrastructure updates per day,” said Eilon Ashkenazi, DevOps Engineer at Unity Aura. “With Pulumi Copilot we can improve the development process for the team by delivering working reference examples faster and discovery of resources to identify and update infrastructure in production.”

Dramatically Improve AI Security

Whether it’s cloud settings, API keys, database credentials or VM passwords, AI environments hold a wide variety of secrets, increasing risk, outages, errors and operational friction. Now you can centralize and secure your secrets management using platform engineering best practices within Pulumi. Easily access, share, and manage environments, secrets, and configurations securely on any cloud using your favorite programming languages. Pull and sync with any secrets store, and consume in any application, tool, or CI/CD platform.

Many industry-leading AI technology providers such as Snowflake have already based some of their competitive differentiation on Pulumi’s unique value. More waves of large organizations are following this example as they navigate their journeys to AI time to market and return on investment.

Learn more about how Pulumi and Platform Engineering can help your organization in the same way it helped Snowflake speed up its deployment by 10x. Or take a look at how Aptos Labs achieved 10x faster development cycles.

If you are ready to talk to an expert about how platform engineering can help your organization, click here. For practitioners on your team, here are some events and learning assets to get up to speed quickly on platform engineering and infrastructure as code.

Announcing the New Pulumi Partner Program

Isaac Harris — Mon, 16 Sep 2024 00:00:00 +0000

We are excited to announce the launch of the Pulumi Partner Program, a strategic initiative designed to empower our partners and their customers to accelerate cloud projects and achieve faster time-to-market. This program is crafted for cloud and SaaS companies who are building, integrating, and going to market with Pulumi.

Hear from dozens of partners and customers who automate, secure and manage everything in the cloud at PulumiUP on Wednesday, September 18. Register here.

Why the Pulumi Partner Program?

Pulumi has always been committed to the open-source community and the vibrant ecosystem that has grown around our products. With nearly 200 integrations today, our ecosystem is thriving, supported by a network of service partners focused on helping customers succeed. The Pulumi Partner Program is being developed to formalize and strengthen these relationships, allowing us to scale our ability to deliver seamless integrations, co-developed solutions, and collaborative go-to-market activities. By building this program, we aim to empower partners to better support our mutual customers, accelerate cloud adoption, and provide tailored solutions that meet the unique needs of each organization.

Customers are choosing Pulumi because it enables them to manage cloud resources and secrets using familiar general-purpose programming languages like Python, TypeScript, .NET, Java and Go. This approach taps into the existing skills of development teams, reducing the learning curve, and also allows for greater flexibility and reuse of code across projects. By utilizing these widely adopted languages, Pulumi increases team productivity, enables more robust automation, and significantly accelerates the path to production compared to tools that require more restrictive, domain-specific languages. With the introduction of local packages, we’re further simplifying the integration process for partners, facilitating seamless adoption and faster delivery of cloud projects.

Key Benefits of Pulumi Partner Program

Empower Your Customers to deliver cloud initiatives faster using Pulumi’s Infrastructure as Code (IaC) and Secrets Management capabilities. By partnering with Pulumi, your customers gain access to best automation for their cloud projects.
Accelerate Adoption of your solutions through seamless integration with Pulumi. Leverage Pulumi’s support for the world’s most popular programming languages and developer tools to streamline integration, making it easier for your customers to use and adopt your products using familiar languages, tools and process.
Reach More Developers with collaborative documentation, shared examples, and co-marketing initiatives to raise awareness. Participate in joint marketing efforts, including co-branded campaigns and events, to connect with more developers and platform engineers.

With 20 inaugural members, our technology partners join an elite community that benefits from Pulumi’s ongoing investment in technical, marketing, training, and business strategy support. We are excited to welcome new members such as Docker, 1Password, Pinecone, NewRelic, Tailscale, Dagger and many others.

Join the Pulumi Partner Program

We believe that the Pulumi Partner Program will bring together and support the growth of our entire ecosystem, leveraging the strengths of our partners and creating connections for new potential services and technologies. Prospective partners can reach out to us via our website. We look forward to welcoming new partners and driving innovation together.

PulumiUP 2024: Dive Into the Future of Cloud, Platform Engineering, and AI/ML

Sara Huddleston — Wed, 11 Sep 2024 07:04:40 +0000

PulumiUP 2024 is just around the corner! It will be held on September 18th, starting at 8 AM PT | 15:00 UTC +0, and with over 5,500 engineers from all over the world already registered, this is shaping up to be the must-attend event for cloud professionals, platform engineers, and AI/ML enthusiasts alike. From entry-level engineers to tech executives, this event brings together professionals from companies of all sizes to explore the latest innovations and best practices in Cloud and IaC, Platform Engineering & DevOps, and AI/ML.

If you haven’t registered yet, now’s the time! Start building your schedule today, select the talks you want to watch live and on-demand and add them to your schedule.

PulumiUP at Glance

Main Track: Keynote, Cloud Culture Talks, and More

In the Main Track, you’ll hear directly from the Pulumi leadership team about exciting product innovations. Don’t miss the Cloud Culture talks focused on the human side of technology and collaboration.

Keynote and New Product Announcements - Joe Duffy (Co-founder and CEO), Luke Hoban (CTO), and other key Pulumi leaders will unveil new products and innovations shaping the next wave of cloud development. Expect to see live demos showcasing how these tools can revolutionize your workflows, from cloud infrastructure to security automation.
"Why Care About Building a Cloud Center of Excellence?" - Alex Radu (VP Product & Marketing Manager, Public Cloud, J.P. Morgan) discusses why building a Cloud Center of Excellence is essential for long-term cloud strategy success.
"What Is ‘HugOps’ and Why Is It Important?" - Rees Pozzi (Senior Platform Engineer, Kainos) explores the meaning and importance of “HugOps,” a practice promoting empathy and collaboration in the tech world but also by all those impacted by it.

AI/ML Track Highlights

Panel: AI for Cloud Development

AI is transforming how we approach development and infrastructure, and PulumiUP offers an incredible lineup of talks and panels on the topic.

"Data Privacy Challenges with Large Language Models" - Aditi Godbole (Data Science, AI & ML Leader, SAP) will address the critical question of managing data privacy, addressing LLM basics, AI data privacy fundamentals, and specific privacy issues in LLMs.
"Pulumi Powered AI/ML on Kubernetes" - Jason Smith (App Modernization Specialist, Google Cloud) will show you how to serve an open-source LLM with a RAG on Kubernetes and set up a Kubernetes environment for AI/ML workloads with Pulumi.
"AI Tools for Developers" - Jim Clark (Principal Software Engineer, Docker) will explore how Tools can enhance the capabilities of AI assistants and show how the combination of AI, Tools, and containerized runtimes, can enhance interactions between developers and their tools.
"The AI Governance Challenge" - Patty O’Callaghan (Technical Director, Charles River) will explore the complexities of AI governance and how to navigate them.
Panel Discussion: “AI for Cloud Development” - Luke Hoban (CTO, Pulumi), Phillip Carter (Principal Product Manager, Honeycomb), Giri Sreenivas (CPO, Docker), Clare Liguori (Senior Principal Software Engineer, AWS) and Meagan Cojocar (Principal Product Manager, Pulumi) will provide diverse perspectives on how AI is shaping cloud infrastructure.

Platform Engineering and DevOps Track Highlights

Panel: Secrets and Policies—Automating Cybersecurity

The Platform Engineering & DevOps track at PulumiUP is perfect for anyone looking to automate infrastructure, secure their systems, and scale their environments with ease. This track features talks and panels on cutting-edge technologies and practices.

"Moving Mountains: How IaC Unlocks Massive Refactoring Possibilities" - Shaun Verch (Infrastructure Engineer, Oso) will show you how infrastructure as code can transform large-scale refactoring projects.
"Using Pulumi to Empower Kubernetes Fleet Management" - Blake Romano (Senior Software Engineer, Imagine Learning) will show you how Imagine Learning leverages Pulumi to manage a fleet of Kubernetes clusters and other platform resources quickly and reliably, and how it revolutionized their workflow.
"Streamline Your Infrastructure Deployment with GitOps and Pulumi Operator" - Sam Cogan (Solutions Architect & Azure MVP, WTW) will highlight how you can define your infrastructure in Git, and have Pulumi automatically reconcile it into deployed infrastructure.
"Is This a Platform? Platform Engineering Before PMF" - Jk Jensen (Team Lead, Staff Software Engineer, MystenLabs) will share how they built their service platform around Pulumi to help engineers and researchers move from prototypes to deployed environments, enabling their teams to iterate more quickly and develop an increasing number of systems without additional complexity.
"Security Automation—Faster. Cheaper. Better." - David Giambruno (VP of Engineering and DevOps, Tivity Health) and Joe Duffy (Founder/CEO, Pulumi) will discuss security automation and how these efforts impacted speed and agility, cost optimization and improved security and compliance.
"Meet Devs Where They Are: Why IaC Must Be Real Code" - Jeremy Adams (Head of Ecosystems, Dagger) will present why real code (that teams already use for applications) is essential for both IaC and CI/CD pipelines, and to meet modern DevOps best practices.
"Security of IaC Pipelines and Infrastructure Governance With Policies-As-Code" - Marina Novikova (Senior Partner Solutions Architect, AWS) and Andy Taylor (Senior Networking Specialist/ Solutions Architect, AWS) will explore security best practices for IaC pipelines and infrastructure governance using policies-as-code, cover best practices for handling sensitive information like access keys, tokens and encryption keys, and scaling and automating your DevSecOps.
Panel Discussion: “Secrets and Policies—Automating Cybersecurity” - Arun Loganathan (Senior Product Manager, Pulumi), Maya Kaczorowski (PM of Security), Jason Meller (VP, Product, 1Password), and Ofir Cohen (CTO, Container Security, Wiz) will explore the intersection of innovation and security, offering insights into how AI is reshaping the threat landscape and how organizations can stay ahead.

Cloud and IaC Track Highlights

Panel: Infrastructure as Code - Can we do better?

The Cloud and IaC track is ideal for those wanting to deepen their understanding of infrastructure as code and its impact on modern cloud computing. Learn from industry pioneers and see where the future of IaC is headed.

"From CDK to Pulumi: Evolution of SST" - Dax Raad (Founding Engineer, SST) and Jay V (Founder, SST) will share insights into the early development of their product, initially built on AWS Cloud Development Kit (CDK), the challenges they encountered and the groundbreaking decision to transition to Pulumi.
"Unified Software Development at BMW Software Factory with Pulumi" - Jan-Peter Alten (Expert Software Engineer, DevOps, BMW Group) will showcase how BMW uses Pulumi to unify their software development processes, resulting in an increase in developer productivity, streamlined infrastructure management, and enhanced scalability, security, and compliance across their complex software ecosystem.
"Stacking Accounts: Multi-Account Deployments in a Single Stack for Monitoring, Management, and More" - Denis Willett (Software Engineer, North Carolina Institute for Climate Studies) will explain how they use Pulumi for managing 60+PB of environmental data across AWS, GCP, and Azure and leverage multi-account deployments in a single stack via the Pulumi Automation API.
"Industrialize the Configuration of Your GitHub Repositories With IaC" - Alexandre Nédélec (Software Engineer, Avanade) will live code using the GitHub, Azure native, and Azure AD Pulumi providers to create a GitHub repository and configure its pipeline to deploy to Azure using OpenID Connect.
Panel Discussion: “Infrastructure as Code — Can We Do Better?” - Joe Duffy (Co-Founder and CEO, Pulumi), Brian Grant (CTO, Stealth), Elad Ben-Israel (Co-Founder and CEO, Winglang), Adam Jacob (Co-Founder and CEO, System Initiative), and Luke Hoban (CTO, Pulumi) will discuss the past, the present, and the future of Infrastructure as Code and the overall infrastructure technologies.

Workshops and Hands-On Learning

Want to get hands-on experience? Our live workshops are designed to deepen your understanding of trending topics, Pulumi, and its applications.

"Managing Team Secrets with 1Password & Pulumi ESC" on September 25, led by Phil Johnston (1Password) and Diana Esteves (Pulumi).
"Securing IaC Pipelines in Regulated Industries" on September 26, led by Josh Kodroff (Pulumi) and Marina Novikova (AWS).
"Deploy Tailscale infrastructure in AWS with Pulumi" on October 15, led by Diana Esteves (Pulumi) and Lee Briggs (Tailscale).
"Observability as Code for AI Apps with New Relic and Pulumi" on October 30, led by Diana Esteves (Pulumi) and Harry Kimpel (New Relic).

Amazing Partners and Sponsors

Thank you to our amazing customers, sponsors, and partners for supporting PulumiUP!

AWS The world’s most comprehensive and broadly adopted cloud, offering over 200 fully featured services from data centers globally.
Google Cloud Help developers build quickly, securely, and cost effectively with the next generation of modern infrastructure designed to meet specific workload and industry needs.
New Relic Data for engineers to monitor, debug, and improve their entire stack.
Docker Accelerate how you build, share, and run applications.
1Password Streamline how you manage SSH keys, API tokens, and other infrastructure secrets throughout the entire software development life cycle.
Tailscale Make creating software-defined networks easy: securely connecting users, services, and devices.
Pinecone Build remarkable GenAI applications fast, with lower cost, better performance, and greater ease of use at any scale.
Wiz Secure everything you build and run in the cloud.
Honeycomb Observability that helps solve problems you couldn’t before.
Mysten Labs Building critical infrastructure to enable a more decentralized internet.
Imagine Learning Empowering educators to inspire breakthrough moments in every student’s unique learning journey with digital-first, K–12 education solutions.
Dagger Powerful, programmable open source CI/CD engine that runs your pipelines in containers.
Oso Authorization as a service.

Build Your Schedule Now

With so many compelling topics across AI/ML, Platform Engineering, DevOps, and Cloud and IaC, now is the time to build your PulumiUP schedule. Select the sessions that match your goals and interests to maximize your experience. Plus, you’ll receive a link to watch your chosen panel discussions and tech talks on-demand!

Haven’t registered yet? It’s not too late! Join 5,500 engineers worldwide in this groundbreaking event and gain the insights you need to drive innovation at your company. Register now->

We can’t wait to see you there!