# Pulumi Infrastructure as Code for AWS, Azure, Google Cloud, including Kubernetes, Serverless, Containers, for Developers and DevOps. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Cloud Sovereignty, Provider Risk, and Migration Options for EU Companies DevFeed: [Cloud Sovereignty, Provider Risk, and Migration Options for EU Companies]() Original publisher: [Read original article]() Author: Adam Gordon Bell Published: 2026-09-16T13:00:00Z Content type: opinion Language: en Sources: [Pulumi]() Topics: [Cloud](), [migration](), [pulumi](), [Security](), [scaleway](), [Tooling]() Tags: [aws](), [azure](), [cloud](), [customers](), [kubernetes](), [migration](), [platform-engineering](), [pulumi](), [scaleway](), [security]() ### AI overview This recorded discussion examines cloud sovereignty, legal and cost concerns for EU companies using major US cloud providers, and the practical tradeoffs of moving to European providers. Three guests discuss provider exposure, encryption and account shutdown risks, migration costs, and whether Pulumi and agentic infrastructure can make future moves easier. ### Source excerpt Recorded September 3, 2026. Quotes are lightly edited for clarity. Maybe this sounds familiar. You run infrastructure at a company that isn't American. Your workloads are on AWS, Azure, or Google Cloud, probably more than one, because that is what everyone picked. Until recently nobody asked you where the data lives or who can reach it. Now you're getting questions. Legal wants to know what NIS2 means for where your systems run. Someone on the leadership team read that the US government locked the cloud accounts of judges at the International Criminal Court and wants to know if that could happen to you. Finance wants to know why the bill went up again. A customer's security review asked, in writing, which country your data sits in. So now you have questions of your own: If a US court or agency wants my data, can they get it from my provider without involving me? Does putting everything in an EU region change that? The big providers now sell "sovereign cloud" in Europe. Is that different, or a rename? If I encrypt everything and hold the keys myself, am I covered? Could my account be switched off one day? What would I do? Are Hetzner, OVH, and Scaleway usable for real workloads? How much cheaper are they once you count the migration? What should I be building on now so I can leave later if I need to? A migration like this used to be a multi-year project. Does Pulumi and agentic infrastructure change that? Is any of this worth the disruption, or should I leave what works alone? I put those questions to three people who have each dealt with this for real. One of them helps EU companies work out their exposure and builds the tooling to leave. Another has spent fifteen years sizing what cloud actually costs, and thinks most people should stay put. The third moved his company off AWS and onto a European provider. They don't agree on how big the risk is. The full hour is below. Don't just default to the hyperscalers Waldemar Kindler co-founded Think Ahead Technologies, whe ## Set Up Cloud OIDC From the Pulumi CLI DevFeed: [Set Up Cloud OIDC From the Pulumi CLI]() Original publisher: [Read original article]() Author: Sean Yeh Published: 2026-09-11T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [OpenID connect (OIDC)](), [Command-line interface](), [AWS IAM](), [Cloud](), [AWS Identity and Access Management (IAM)](), [Azure](), [Google Cloud Platform (GCP)]() Tags: [automated](), [aws](), [azure](), [cli](), [cloud](), [configuration](), [docs](), [esc](), [google-cloud](), [how-to](), [iam](), [identity](), [oidc](), [openid-connect](), [product](), [pulumi](), [pulumi-cli](), [security](), [terminal](), [workflow]() ### AI overview This tutorial explains how to use the Pulumi CLI command pulumi env setup to configure Pulumi ESC as an OIDC provider for AWS, Azure, and Google Cloud. It covers interactive onboarding, non-interactive flags for scripts and agents, cloud credentials, account selection, access policies, and automatic creation of identity providers, IAM roles, policy attachments, and ESC environments. ### Source excerpt Pulumi ESC can act as an OpenID Connect (OIDC) provider for AWS, Azure, and Google Cloud, issuing short-lived, signed tokens that these clouds exchange for temporary credentials. This eliminates hard-coded credentials and improves your security posture. Last year, we introduced an onboarding flow in the Pulumi Cloud console that makes it super easy to configure OIDC for your cloud provider in a few guided steps. We're bringing Pulumi Cloud into the CLI so agents can use its capabilities directly from the terminal, without requiring a human to complete steps in the console. The new pulumi env setup command brings OIDC onboarding to that workflow, with interactive prompts for guided setup and non-interactive flags for scripts and agents. pulumi env setup - how it works Run the command with your desired cloud provider (aws, azure, gcp). For example: pulumi env setup aws The command then asks what it needs to configure your cloud, including your credentials, the accounts to configure, and the level of access. The questions differ per cloud. For AWS, it asks: How to authenticate to AWS. It uses the credentials you already have, or it signs you in with AWS SSO. Which accounts to configure. Which policy to attach to the OIDC role. Choose AdministratorAccess for Pulumi Deployments, ReadOnlyAccess for Pulumi Insights, or any other policy ARN. Then, it will print out the plan: About to configure OIDC for organization my-org: account 111111111111: create role pulumi-esc-oidc-622e86ea-319ba4c675bb3c00-role attach arn:aws:iam::aws:policy/AdministratorAccess create ESC environment my-org/aws-login/sandbox-account-env Proceed? [yes/no] After you confirm, the command creates the identity provider, the IAM role, and the policy attachment in each account. It then creates one ESC Environment per account, with the aws-login provider already configured. Non-interactive setup You can also run the command without interactive prompts by passing in the necessary flags. Each cloud has its ow ## Pulumi Kubernetes v4.34.0: CRDs as provider extensions DevFeed: [Pulumi Kubernetes v4.34.0: CRDs as provider extensions]() Original publisher: [Read original article]() Author: Guinevere Saenger Published: 2026-08-28T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Kubernetes](), [Extension](), [SDKs](), [YAML](), [ingress-nginx]() Tags: [extensions](), [install](), [kubernetes](), [migration](), [product](), [providers](), [release](), [releases](), [sdk](), [sdks](), [yaml]() ### AI overview Pulumi Kubernetes provider v4.34.0 adds support for extending the provider with Kubernetes Custom Resource Definitions through a manifest and the new --extension flag. The release generates SDKs, supports all supported Pulumi languages including YAML, uses a single provider instance, and provides a migration path from crd2pulumi. ### Source excerpt We're really excited to bring you v4.34.0, the newest version of the Pulumi Kubernetes provider, which includes improved support for Kubernetes Custom Resource Definitions (CRDs). As with any release, we've also shipped standard dependency updates and bug fixes. This provider release includes the newest resources for Kubernetes v1.37.0, which was recently cut. So that in itself is very exciting! But the feature we're proudest of is that you can now extend the Kubernetes provider with any Kubernetes Custom Resource Definition of your choice by passing its manifest file to Pulumi, using the new --extension flag. We believe first-class CRD support in Pulumi is becoming more important than ever. For example, since the retirement of the ingress-nginx controller earlier this year, the recommended path for cluster ingress is Gateway API, which is maintained and shipped as CRDs. Generating a Pulumi SDK for CRDs In your Pulumi project root, run: pulumi package add kubernetes --extension "name=gateway-networking crd-manifest=gateway-api-crds.yaml" You will see the custom SDK appear in a new sdks/ folder, as well as a new parameterization reference in Pulumi.yaml. Single provider instance Your new CRD schema exists as an extension to your existing provider and will be managed under the same provider instance, allowing you to use a single provider configuration and kubeconfig. SDKs as dependencies Additionally, your code no longer needs to ship SDK files as part of the project. The provider extension is referenced in your project file and its SDK, like all dependencies, can be regenerated via pulumi install. You can choose to version the extension SDK, or continue to check the files into version control if you so desire. Full language support, including for YAML Kubernetes CRDs can now be provisioned with Pulumi in all supported languages. Unified CLI experience pulumi package add --extension extends your CRD schema into the Pulumi Kubernetes provider, using the same CLI as any ## Neo Security: Securing Infrastructure in the Agentic Era DevFeed: [Neo Security: Securing Infrastructure in the Agentic Era]() Original publisher: [Read original article]() Author: Joe Duffy Published: 2026-08-28T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [pulumi-neo](), [Security](), [cloud-infrastructure](), [Artificial Intelligence](), [Infrastructure as code](), [Static code analysis]() Tags: [agent](), [agentic](), [ai](), [aws](), [azure](), [cloud-infrastructure](), [infrastructure-as-code](), [kubernetes](), [product](), [pulumi](), [pulumi-neo](), [security]() ### AI overview Pulumi is opening a research preview of Neo Security, an agent that analyzes cloud infrastructure for exploitable flaws. It builds a threat model, maps attack paths, and produces an actionable security posture report, including for infrastructure provisioned across AWS, Azure, Google Cloud, and Kubernetes. ### Source excerpt Recently, AI systems have started turning up exploitable flaws in code that survived decades of human review. The frontier labs have released useful tools to help uncover many of these flaws through agent-led static code analysis. This is a huge leap ahead, but cloud infrastructure has many exploitable flaws that code analysis alone cannot find. These flaws are often as severe as the ones in code, or worse, and they await discovery by malicious agents on offense. We realized recently we can uniquely help here. At Pulumi, we have complete visibility into your entire cloud estate: infrastructure resources, their semantics, connections and dependencies between them, runtime logs and information, and more -- and have built an entire context graph out of them that is accessible to agents. Thanks to large language models, the cost of analyzing that full context graph is no longer prohibitive. As a result, today we're opening a research preview of Pulumi Neo Security. Neo Security is an agent that can find exploitable flaws in your cloud infrastructure. It starts with a threat model of your cloud estate, and then works systematically through every potential point of attack. The result is a security posture report that is immediately actionable thanks to Pulumi's infrastructure as code technology. Neo Security works on your existing infrastructure regardless of how it was provisioned, across any of our thousands of cloud providers including AWS, Azure, Google Cloud, and Kubernetes. We're releasing it in research preview to begin, so we can work closely with customers to run and address any findings. If you'd like to give it a try, contact us. How it finds attack paths Neo Security's aim is to provide a high-confidence, actionable security posture report. It gets there in three passes. The first builds a threat model, before it looks for anything. It works out what your crown jewels are, which resources are accessible to outside actors, which accounts hold production data, wh ## Pulumi Context API: query your infrastructure as a graph DevFeed: [Pulumi Context API: query your infrastructure as a graph]() Original publisher: [Read original article]() Author: Levi Blackstone Published: 2026-08-26T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [API](), [Graphs](), [Cloud APIs](), [infrastructure as code (IAC)](), [Command-line interface](), [JSON](), [pulumi-neo]() Tags: [agent](), [ai-agents](), [api](), [cli](), [features](), [graph](), [iac](), [infrastructure-as-code-iac](), [json](), [product](), [pulumi](), [pulumi-cloud](), [pulumi-neo](), [rest-api]() ### AI overview Pulumi is launching the Context API, a read-only API that connects Pulumi-managed and discovered resources, stacks, and their relationships into a graph. Available in public preview for Enterprise and Business Critical organizations, it supports infrastructure-impact, coverage, and cleanup queries through the Pulumi CLI or REST API. Pulumi Neo uses it out of the box, and other authenticated agents can access its schema and query guidance. ### Source excerpt Every platform team fields the same questions: What is running? What breaks if we change this? What can we safely delete? The answers exist, but they're scattered across state files, cloud consoles, and the memories of whoever set things up. Today we're launching the Pulumi Context API, a read-only API that connects Pulumi-managed and discovered resources, stacks, and their relationships into a graph. It's designed agent-first: Pulumi Neo, our infrastructure agent, uses it out of the box, and other agents can fetch the current graph vocabulary and query guidance on demand. It's available in public preview for organizations on the Enterprise and Business Critical editions. Answers that follow infrastructure relationships Pulumi already records the resources your programs manage, their dependencies, how stacks consume each other's outputs, and the resources Pulumi Discovery finds outside infrastructure as code (IaC). The Context API connects this data so you can ask questions that depend on the relationships: Impact: Which stacks are affected if we upgrade this provider? If this stack changes, what consumes its outputs? Coverage: How much of our infrastructure lives outside IaC, and in which accounts? Cleanup: Which stacks have no dependents and are candidates for retirement? A query is a JSON document with a handful of clauses. anchor names the starting nodes, traverse follows relationships from there, and return chooses what comes back. You can run a query through the Pulumi CLI or REST API. Here's a selector that starts from AWS provider instances older than version 7.0.0 and follows incoming provided_by relationships back to the visible resources they manage: { "anchor": { "nodeType": "resource", "match": { "type": "pulumi:providers:aws", "fields": { "provider_version": { "op": "lt", "value": "7.0.0" } } } }, "traverse": [ { "edgeTypes": ["provided_by"], "direction": "in", "alias": "managed" } ], "return": { "select": ["anchor", "managed"] } } A response for one m ## Best Kubernetes Infrastructure as Code Tools in 2026 DevFeed: [Best Kubernetes Infrastructure as Code Tools in 2026]() Original publisher: [Read original article]() Author: Pulumi Content Team Published: 2026-08-14T00:00:00Z Content type: comparison Language: en Sources: [Pulumi]() Topics: [Infrastructure as code](), [Kubernetes](), [Terraform](), [argo-cd](), [Helm charts](), [GitOps](), [flux](), [opentofu](), [Amazon EKS](), [AWS CloudFormation](), [VPC](), [AWS IAM]() Tags: [argo-cd](), [cloudformation](), [code](), [comparisons](), [devops](), [flux](), [general](), [gitops](), [helm](), [helm-charts](), [iam](), [infrastructure](), [infrastructure-as-code](), [kubernetes](), [opentofu](), [platform-engineering](), [terraform](), [vpc]() ### AI overview This comparison explains that Kubernetes infrastructure as code spans cluster and cloud provisioning, in-cluster workload definition, and continuous delivery and reconciliation. It presents Pulumi and Terraform or OpenTofu as general-purpose provisioning options, Helm and Kustomize for workload templating, and Argo CD and Flux for GitOps reconciliation. ### Source excerpt There is no single best Kubernetes infrastructure as code tool, because "Kubernetes IaC" actually spans three different jobs. For provisioning the cluster and its cloud dependencies, Pulumi and Terraform (or OpenTofu) are the strongest general-purpose options. For templating and packaging workloads, Helm and Kustomize dominate. For continuous reconciliation once things are running, Argo CD and Flux lead the GitOps category. The right stack usually combines one tool from each layer, not a single tool that claims to do all three. What counts as infrastructure as code for Kubernetes? Kubernetes infrastructure as code work splits into three layers that get conflated constantly, and the confusion is where most tool comparisons go wrong. The cluster and cloud layer provisions the things Kubernetes itself sits on top of: the managed control plane (EKS, GKE, AKS), node pools, the VPC and subnets, IAM roles, load balancers, and cluster add-ons. Terraform, Pulumi, and cloud-native tools like CloudFormation operate here. The in-cluster workload layer defines what runs on the cluster once it exists: Deployments, Services, ConfigMaps, CustomResourceDefinitions, and the Helm charts or Kustomize overlays that template them. This is where Helm, Kustomize, and Crossplane's custom resources live. The delivery and reconciliation layer keeps what's declared in Git in sync with what's actually running on the cluster, continuously, rather than as a one-shot apply. Argo CD and Flux own this layer, and they consume the output of the other two rather than replacing them. Most real Kubernetes platforms use tools from at least two of these layers together. A team might provision EKS with Terraform, package its application with Helm, and let Argo CD reconcile it continuously. Knowing which layer a tool actually addresses, rather than treating "Kubernetes IaC" as one shopping list, is the first decision that matters. Pulumi provisions the cluster and the workloads on it in the same language Pul ## Compatibility Testing Pulumi HCL DevFeed: [Compatibility Testing Pulumi HCL]() Original publisher: [Read original article]() Author: Ian Wahbe Published: 2026-08-14T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [Testing](), [opentofu](), [Terraform](), [terraform provider](), [Code]() Tags: [code](), [engineering](), [hcl](), [opentofu](), [terraform](), [terraform-provider](), [testing]() ### AI overview The article explains a compatibility-testing approach for Pulumi HCL. It defines correctness as Pulumi HCL and OpenTofu generating the same Terraform provider steps from the same HCL program, then describes tests that compare provider configuration and RPC behavior. ### Source excerpt Pulumi HCL has at its core a simple promise: A program that works for tofu apply will also work for pulumi up. This must be true to allow Terraform modules to be shared between tofu config and Pulumi programs. This property makes testing Pulumi HCL simple. Let me explain. At the end of the day, Pulumi is a system to translate actual state & desired state into a series of imperative actions, so actual state can be reconciled to desired state. Terraform is a system to translate actual state & desired state into a series of imperative actions, so actual state can be reconciled to desired state. How desired state is expressed can be radically different, and the underlying reconciliation engine can be radically different, but at the end of the day, both tools do the same thing: Executing a Terraform program looks like this: flowchart LR tf["*.tf files"] current["current state"] subgraph engine["reconciliation engine"] direction LR desired["desired state"] --> internal["provider steps"] end output["provider steps"] tf --> desired current --> engine engine --> output Executing a Pulumi program is more dynamic, because the reconciliation engine is in more active dialog with the user's program. That said, the diagram is the same shape. To match semantics, Pulumi HCL dynamically bridges any Terraform provider in the registry. This means that, for the subset of Pulumi programs that are valid OpenTofu programs, both programs take the same input (*.tf files) and produce the same step output (Terraform provider steps). Providers are the part of our model that generates user-observable behavior, which means if we match what providers see, we match what users see. This gives us a really nice definition of correctness for Pulumi HCL1: Pulumi HCL correctly interprets an HCL program when it generates the same set of provider steps as tofu does. If you are familiar with property-based testing, you might be thinking this looks like a testable property. You're right. How we compatibility ## Pulumi Introduces Notification Center for Pulumi Cloud DevFeed: [Pulumi Introduces Notification Center for Pulumi Cloud]() Original publisher: [Read original article]() Author: Tom King Published: 2026-08-11T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Cloud]() Tags: [console](), [email](), [esc](), [features](), [github](), [notifications](), [organization](), [product](), [pulumi](), [pulumi-cloud](), [pulumi-neo](), [real-time](), [review](), [slack]() ### AI overview Pulumi introduces Notification Center, an inbox in the Pulumi Cloud console for task completions, approval requests, and billing alerts. Notifications appear in real time, link directly to the required action, and can be delivered in the console or by email with per-type preferences. ### Source excerpt Plenty happens in a Pulumi organization while you're looking somewhere else. Neo finishes a task you kicked off just before taking lunch. A teammate submits an ESC change request that needs your approval before it can land. Until now, catching any of that meant either keeping the right tab open or hoping the right email reached you. Today we're introducing the Notification Center: a single inbox in the Pulumi Cloud console for the things that actually need you. It lives behind the bell in the sidebar, with a dot when something's waiting. Notifications arrive in real time -- no refresh -- and each one carries exactly one action: Review request, View task, Update billing. Click it and you land on the page where you can do the thing, not on a dashboard where you have to go find it. What you'll hear about We've started with the moments where being a few minutes late actually costs you something: a Neo task that's paused waiting on your approval, a Neo task that's finished, an ESC change request waiting on your sign-off, and billing conditions like a locked organization or a trial that's about to end. Relevant people in your organization will be notified when there's a pending approval, or billing alert. Nobody gets paged for someone else's work. Where you'll hear about it Every notification type can be delivered two ways -- in the console and over email -- and you choose per type, per channel. Organization admins set a sensible baseline for everyone; each person can override it for themselves on their account settings page. What's next The Notification Center is available today. We're starting with this set of notifications and expanding from there. If there's an event you'd rather hear about from the bell than from a colleague on Slack, we'd like to know which one. Join our Community Slack to connect with the Pulumi team and other users, or open an issue on our GitHub repository. ## Pulumi v3.254.0 Adds Automatic Encrypted Logging DevFeed: [Pulumi v3.254.0 Adds Automatic Encrypted Logging]() Original publisher: [Read original article]() Author: Thomas Gummerer Published: 2026-08-10T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Logging](), [debugging](), [Encryption]() Tags: [debugging](), [encryption](), [environment-variables](), [features](), [github](), [logging](), [logs](), [observability](), [product]() ### AI overview Pulumi v3.254.0 automatically creates encrypted log files for every operation, allowing users to share existing logs with the Pulumi team for debugging. Logs use AES256-GCM encryption, rotate after seven days or when they reach 500 MB, and can be decrypted locally with pulumi logs decrypt. ### Source excerpt Pulumi v3.254.0 introduces automatic logging: every operation is logged in an encrypted log file that can optionally be shared with the Pulumi team for inspection. No more re-running commands just to get logs to the Pulumi team for debugging; instead you can share existing logs securely. You might have been in a situation where pulumi hit an error for an unexpected reason, or did something that was not quite right. Currently the process for trying to resolve that is to try and reproduce the error, ideally now with logging enabled. Sometimes the error doesn't reproduce, or the state pulumi was in at the time of the error doesn't exist anymore. And even if the issue reproduces it's a bit of a hassle to do all this again, just to get logs to Pulumi employees who can do something with them. There's also no great mechanism to send the potentially sensitive log file. How it works From pulumi v3.254.0 onward, we automatically produce log files for every operation and store them in $PULUMI_HOME/logs. These log files are encrypted on disk, using the relevant stack's secret manager, whenever it is available, as they still contain secrets at this point. The final file consists of gzip'd chunks that are encrypted using AES256-GCM. Log files are gzip'd when no secrets manager is available, as no secrets from property values can be in the log at that point. Note that the logs are rotated out after 7 days, or after the log directory has reached 500 MB, removing the oldest logs first. This way logs will never fill up your disk, but will still be available after running pulumi commands. These defaults can be overridden with the PULUMI_LOG_ROTATION_MAX_AGE_DAYS and PULUMI_LOG_ROTATION_MAX_TOTAL_MB environment variables. Locally these logs can be decrypted using pulumi logs decrypt. For this to work the same stack's secret manager as was used for the command needs to be available. Sharing logs Previously there was no good way to securely share the logs with us. Users were always force ## Terraform and Kubernetes: A Practical Guide for 2026 DevFeed: [Terraform and Kubernetes: A Practical Guide for 2026]() Original publisher: [Read original article]() Author: Pulumi Content Team Published: 2026-08-07T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [Kubernetes](), [Terraform](), [Provisioning](), [Testing](), [Artificial Intelligence]() Tags: [ai](), [ai-agents](), [deployment](), [general](), [guide](), [infrastructure-as-code](), [kubernetes](), [platform-engineering](), [provisioning](), [terraform](), [testing]() ### AI overview A practical guide to using Terraform with Kubernetes, covering the Kubernetes provider, provisioning workflows, testing, policy, deployment, and the role of AI agents. It explains limitations including provider ordering and the need for Kubernetes API access during planning. ### Source excerpt Yes, Terraform can manage Kubernetes: the official hashicorp/kubernetes provider lets you declare Deployments, Services, and other objects as HCL resources, and community providers like kubectl fill in the gaps. It works well for many teams. The friction shows up around two well-documented limits -- provider ordering and plan-time API access -- and around testing, where a general-purpose language changes what's possible. That friction matters more in 2026 than it did a few years ago. Kubernetes infrastructure now sits next to AI-driven engineering workflows: agents that propose changes, run previews, and open pull requests need infrastructure code they can read, test, and reason about with the same tools they use for application code. A cluster definition written in HCL and a workload definition written in YAML are both harder for an agent -- and a person -- to unit test, refactor, or type-check than the equivalent in TypeScript, Python, or Go. This guide is about the operating model for Kubernetes infrastructure: how the cluster, the platform layer, and the workloads on top of it get provisioned, tested, and shipped. It's a different question from "should I write my Kubernetes manifests in YAML, HCL, or a real language," which we cover in detail in YAML, Terraform, or Pulumi: what's the smart choice for deployment automation with Kubernetes? Read that post first if you're deciding how to author manifests; read this one for the wider workflow -- provisioning, testing, policy, and where AI agents fit. How does Terraform manage Kubernetes today? The hashicorp/kubernetes provider (current release v3.2.1, requiring Terraform 1.0.0 or later) is the primary path, and teams typically combine it with one or two others depending on what they're deploying: Approach What it's for Notes Typed resources (kubernetes_deployment_v1, kubernetes_service_v1, etc.) Core, well-known object types Full HCL validation and typed attributes for the objects the provider models explicitly kubernete ## Pulumi Cloud Adds Terraform Backend Support for Agentic Infrastructure DevFeed: [Pulumi Cloud Adds Terraform Backend Support for Agentic Infrastructure]() Original publisher: [Read original article]() Author: Daniel Perlovsky Published: 2026-08-04T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Terraform](), [Infrastructure as code](), [opentofu](), [Cloud](), [Deployment]() Tags: [agentic](), [agents](), [ai-agents](), [cloud](), [deployment](), [enterprise](), [hcl](), [iac](), [infrastructure-as-code](), [opentofu](), [platform](), [product](), [pulumi-cloud](), [terraform]() ### AI overview Pulumi announces general availability of Pulumi Cloud as a backend for Terraform state. The release supports existing Terraform deployment patterns while adding Pulumi Cloud capabilities such as remote runs, visibility, manual approvals, and scalable access management. ### Source excerpt At Pulumi, we are building the platform for agentic infrastructure. Pulumi Cloud provides the guardrails and enterprise readiness needed to safely move fast in this new era. While we are seeing extraordinary adoption -- over 40% of our users now manage infrastructure using AI agents -- we know many organizations are at different phases in their AI journey and have to balance building for the future with maintaining their existing infrastructure as code (IaC) solutions like Terraform. Today, we are launching three ways that Pulumi lets you avoid trading off building for the future against building for today. You don't have to rip out Terraform to enter the agentic era. Pulumi Cloud brings agentic infrastructure to the IaC estate you already have. What we're shipping today Last December, our CEO Joe Duffy laid out his vision to make Pulumi the platform for all of your infrastructure as code. The capabilities we are launching today make that promise a reality. Pulumi is now fully interoperable with Terraform and OpenTofu and enables organizations to build upon their existing IaC estate rather than starting from scratch as they work toward the agentic infrastructure future. Pulumi Cloud as a Terraform backend We are excited to announce the general availability of Pulumi Cloud as the backend to your Terraform state, enabling organizations to seamlessly lift and shift their existing Terraform estates. We recognize there is lots of infrastructure that works as is, and switching over to a new management paradigm may not always be possible. Pulumi Cloud support for the Terraform state backend lets organizations maintain their existing Terraform deployment patterns while also unlocking the power of Pulumi Cloud. The following common patterns for running Terraform are now supported: Plans and applies run remotely by default for new Terraform stacks, following the behavior of HCP Terraform and Terraform Enterprise. When you run a Terraform operation, it executes on a Pulumi-hoste ## Emulating Terraform on Pulumi's Engine DevFeed: [Emulating Terraform on Pulumi's Engine]() Original publisher: [Read original article]() Author: Ian Wahbe Published: 2026-08-04T00:00:00Z Content type: article Language: en Sources: [Pulumi]() Topics: [Terraform](), [opentofu](), [terraform provider](), [configuration]() Tags: [engineering](), [hcl](), [modules](), [opentofu](), [protocol](), [providers](), [pulumi](), [terraform](), [terraform-provider](), [translation]() ### AI overview This article explains how Pulumi's HCL interpreter maps Terraform configuration, resources, providers, and modules onto the Pulumi engine. It reports that the implementation works with 96% of Pulumi's top Terraform modules and describes how Pulumi's terraform-provider relays between Pulumi and Terraform provider protocols. ### Source excerpt The core promise of Pulumi's HCL support is that you can bring your existing Terraform configuration and modules, and pulumi will run them. If it works in OpenTofu and doesn't work in Pulumi, we would like to fix that. Given that goal, our HCL interpreter needs to take HCL as input and emit instructions to the Pulumi engine that semantically match how tofu would interpret the same input. This is made harder by the fact that Pulumi and OpenTofu have fundamentally different engine semantics and provider ecosystems. This blog post will explore how we have implemented that mapping well enough to get 96%1 of our top Terraform modules working on Pulumi. We'll briefly walk through how Pulumi's HCL interpreter handles Terraform's resource semantics, providers, and modules. It will also call out where Pulumi's HCL support lets you do things that Terraform and OpenTofu will not allow. Providers Both Pulumi and Terraform have providers, but they don't have the same providers. While there are providers that Terraform does not have, Pulumi can always resolve a Terraform provider using Pulumi's confusingly named terraform-provider provider.2 This is the same provider that lets you consume Any Terraform Provider in another Pulumi program with pulumi package add terraform-provider .... The terraform-provider provider acts as a relay: it speaks Pulumi's protocol to the Pulumi engine, and speaks Terraform's provider protocol to the Terraform provider it stands up. Because Pulumi HCL needs to work with all Pulumi providers and because terraform-provider lets Pulumi HCL speak to Terraform providers via the Pulumi protocol, Pulumi HCL actually only speaks Pulumi protocols directly: flowchart LR subgraph n2Entry[" "] n2["terraform-provider"] end subgraph providerBox["Pulumi Provider"] direction TD n2Entry n3["Terraform Provider"] end n0["Pulumi HCL"] <--> n1["Pulumi Engine"] n1 <--> n2Entry n2 <--> n3 n2@{ shape: rect} n3@{ shape: rect} n0@{ shape: rect} n1@{ shape: rect} style n2Entry f ## Running YOLO-Mode Coding Agents in a Sandbox for Infrastructure Work DevFeed: [Running YOLO-Mode Coding Agents in a Sandbox for Infrastructure Work]() Original publisher: [Read original article]() Author: Engin Diri Published: 2026-08-04T00:00:00Z Content type: opinion Language: en Sources: [Pulumi]() Topics: [Claude Code](), [Security](), [coding](), [Claude](), [Filesystems](), [codex](), [cursor](), [Amazon Web Services]() Tags: [agent](), [ai](), [ai-agents](), [autonomous](), [aws](), [best-practices](), [claude](), [claude-code](), [codex](), [coding](), [cursor](), [docker](), [files](), [infrastructure](), [infrastructure-as-code](), [permission](), [sandbox](), [security]() ### AI overview This opinion article argues that coding agents should retain autonomous YOLO-mode operation inside a sandbox rather than rely on repeated command approvals. It discusses risks to local files, AWS credentials, Kubernetes configurations, and Pulumi access tokens, and presents sandboxing as a way to limit the blast radius during infrastructure work. ### Source excerpt Claude Code calls the flag --dangerously-skip-permissions, and the community long ago renamed it YOLO mode. It lets your coding agent run any command it wants without ever asking for permission. Every agent has some version of it, Codex and Cursor included, and if you use these tools seriously, you are probably running one of them every day. I am. YOLO mode is also what makes a coding agent worth having. An agent that stops for approval before every command is not autonomous; it's a slow pair programmer. But you cannot let it run wild on your machine without real guardrails either. You have heard the horror stories: wiped databases, deleted home directories, vanished git history. The odds on any given day are low, and it's tempting to conclude it will never happen to you. It only has to happen once. My version of this problem is worse than most, because the code in my working directory is infrastructure code. My laptop holds more than source files. It holds AWS credentials, kubeconfigs that point at real clusters, and Pulumi access tokens. This post walks through what an unsandboxed agent can actually do, why prompt guardrails fail exactly when you need them, and how a sandbox lets you keep full YOLO-mode autonomy anyway. Then I will show you the kit I built for doing infrastructure work this way. Approving every command is not a security model Let me get one thing out of the way first: the answer is not to turn YOLO mode off. A real working session involves hundreds of commands, and nobody reviews the hundredth npm install any better than the first. You are not evaluating at that point; you are pressing enter. Approval fatigue turns the permission prompt into a formality while destroying the one thing you wanted from the agent, which is that it works while you do something else. The goal instead is to run YOLO mode somewhere it cannot hurt you. That somewhere is a sandbox: an isolated environment where the agent has full autonomy and your machine is no longer part ## A guided tour of Terraform state, hosted modules, and HCL in Pulumi DevFeed: [A guided tour of Terraform state, hosted modules, and HCL in Pulumi]() Original publisher: [Read original article]() Author: Christian Nunciato Published: 2026-08-04T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [Terraform](), [opentofu](), [Amazon S3](), [Command-line interface](), [Cloud](), [GitHub](), [Template]() Tags: [amazon-s3](), [aws](), [cli](), [github](), [hcl](), [how-to](), [infrastructure-as-code](), [modules](), [opentofu](), [pulumi-cloud](), [registry](), [s3](), [terraform](), [tutorials]() ### AI overview A hands-on walkthrough shows how to move a Terraform project that provisions an Amazon S3 bucket into Pulumi Cloud. It covers Pulumi Cloud as a Terraform state backend, hosted Terraform modules, and HCL authoring support, with references to OpenTofu and AWS. ### Source excerpt Today's big release contains a whole new set of features designed for seamless interoperability with the Terraform and OpenTofu ecosystems, and there's a lot there -- so much that it can be tough to get your head around all of it. But it generally falls into three major categories: Support for Pulumi Cloud as a Terraform state backend, including remote execution with human approvals A Terraform module registry in Pulumi Cloud that lets you publish, document, and share your modules even across language boundaries First-class support for HCL as an authoring language in the Pulumi engine To make this release a little easier to appreciate holistically, I've put together a quick end-to-end walkthrough that doesn't quite cover everything, but does cover the big stuff, and should give you a sense of how it all comes together. We'll start with a simple Terraform project that you'll deploy to AWS, and then one step at a time, bring it into Pulumi Cloud and kick the tires on each of these new features as we go. It'll take a bit, but all you'll need are a free Pulumi account and the ability to deploy an S3 bucket to AWS. We've got a bunch to cover, so let's jump right in. Start with a Terraform project Our tour begins with a tiny Terraform project that provisions a single Amazon S3 bucket using a locally defined module that we'll publish later. The project is available on GitHub as a template, and the easiest way to use it is with the GitHub CLI: $ gh repo create my-tf-project \ --template cnunciato/simple-tf-template \ --public \ --clone && cd my-tf-project We'll use the local Terraform backend to start. Set your AWS credentials (preferably with environment variables), then deploy the project with Terraform or OpenTofu. (This walkthrough uses the terraform CLI, but you can swap in tofu if that's your preference.) $ terraform init && terraform apply ... Apply complete! Resources: 2 added, 0 changed, 0 destroyed. Outputs: bucket_arn = "arn:aws:s3:::my-tf-project-bucket-14d19ece" ## Discovered Stacks: One Place for All Your Infrastructure DevFeed: [Discovered Stacks: One Place for All Your Infrastructure]() Original publisher: [Read original article]() Author: Alejandro Cotroneo Published: 2026-07-30T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Infrastructure as code](), [migration](), [AWS CloudFormation](), [Azure](), [Terraform](), [Cloud]() Tags: [aws-cloudformation](), [azure](), [cloud](), [deployment](), [features](), [fragmentation](), [governance](), [infrastructure](), [insights](), [migration](), [product](), [pulumi-cloud](), [terraform]() ### AI overview Pulumi launches Discovered Stacks, a Pulumi Cloud capability that models AWS CloudFormation stacks and Azure Resource Manager deployments alongside Pulumi stacks. It tracks resource migration status from live state and supports migration into Pulumi management with verification before changes are made. ### Source excerpt Today we're launching Discovered Stacks: Pulumi Cloud now models your AWS CloudFormation stacks and Azure Resource Manager deployments as stacks, right alongside your Pulumi IaC stacks. And when you're ready to bring them under Pulumi management, migration is built in, with every resource tracked until the code provably matches the cloud. Why: your infrastructure doesn't live in one tool Almost nobody's cloud estate is a single technology. There's the CloudFormation that came with the AWS account, the ARM templates from the Azure team, the Terraform from an acquisition, and the Pulumi you're standardizing on. Each tool has its own console, its own grouping, its own idea of state, and no single place shows you everything you run. That fragmentation is also why migrations stall. Moving a stack to Pulumi has never been the hard part; knowing where you stand is. The tracking lives in a spreadsheet, the spreadsheet goes stale the day it's written, and six months later nobody can say which of the 800 resources made it across and which were quietly forgotten. Nothing gets lost Discovered Stacks gives you confidence that your migration plan or governance efforts will include all resources. This catches a common failure mode where resources are missed by your existing migration scripts or automations. When Pulumi Insights scans your accounts, every CloudFormation stack and ARM deployment becomes a discovered stack, and every resource in it appears as a row with an explicit migration status: ready to migrate, requiring review before migration, or already migrated. Every status is computed from live state on both ends -- what Pulumi manages and what the source tool reports -- so it's never a stale annotation someone forgot to update. Each resource shows its origin type (AWS::S3::Bucket) next to its Pulumi type (aws:s3/bucket:Bucket), with the origin properties side by side with Pulumi's view, so you can verify that Pulumi sees exactly what your source tool sees before you change ## Migrate CloudFormation to Pulumi with Discovered Stacks DevFeed: [Migrate CloudFormation to Pulumi with Discovered Stacks]() Original publisher: [Read original article]() Author: Alejandro Cotroneo Published: 2026-07-30T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [Infrastructure as code](), [AWS CloudFormation](), [migration](), [Amazon Web Services](), [VPC](), [Amazon S3](), [DynamoDB](), [AWS IAM]() Tags: [aws](), [cloudformation](), [dynamodb](), [git](), [iac](), [iam](), [import](), [insights](), [kms](), [migration](), [pulumi](), [pulumi-cloud](), [pulumi-neo](), [s3](), [tutorials](), [vpc]() ### AI overview A tutorial shows how to migrate a 61-resource AWS CloudFormation stack to Pulumi using Discovered Stacks in Pulumi Cloud. It explains how to find the stack, review migration status, start the migration, resolve unmatched resources, and verify the result with a zero-diff pulumi preview. ### Source excerpt With Discovered Stacks, Pulumi Cloud does the bookkeeping for a CloudFormation migration: every resource in the stack gets an explicit migration status, and the migration is done when the code provably matches the cloud. In this tutorial, we take one real CloudFormation stack from discovered to migrated and managed by Pulumi IaC, end to end. What we're migrating Our example is payments-api, a CloudFormation stack with 61 resources: a VPC, an Aurora ledger database behind an RDS Proxy, an assets S3 bucket, a DynamoDB ledger table, a Kinesis payment-events pipeline, and the IAM roles, KMS keys, and secrets that wire them together. The plan has five steps: Find the stack in Pulumi Cloud. Review the migration breakdown at a glance. Start the migration. Resolve the stragglers, so every resource is accounted for. Confirm the quality gate: a zero-diff pulumi preview. We'll use Pulumi Neo to do the heavy lifting, but nothing here depends on it. The same flow works with your own coding agent or entirely by hand, because migration status is derived from actual stack state -- however the work gets done, the console shows the same progress. Step 1: Find your stack in Pulumi Cloud Discovered Stacks builds on Discovery, so the only prerequisite is a scanned cloud account -- the AWS account holding your CloudFormation stacks. Once a scan has run, open the Stacks page and turn on Show Discovered Stacks. Your CloudFormation stacks appear alongside your Pulumi stacks. The project name comes from the CloudFormation stack (payments-api), and the stack name encodes the account and region it came from, so the same template deployed to two regions shows up as two distinct discovered stacks. Step 2: Plan the migration at a glance Open the discovered stack's Migration tab. It lays out all 61 resources of payments-api by status, so you can visualize the migration before touching anything: 54 Ready: mapped to a Pulumi type and confirmed to exist -- importable right now. 2 Not found: mapped, but ## How to Run AI Agents on Kubernetes with Pulumi DevFeed: [How to Run AI Agents on Kubernetes with Pulumi]() Original publisher: [Read original article]() Author: Joe Duffy Published: 2026-07-28T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [Kubernetes](), [AI Agent](), [Artificial Intelligence](), [GPU](), [Python](), [TypeScript]() Tags: [agents](), [ai](), [ai-agents](), [deployment](), [general](), [gpu](), [inference](), [infrastructure](), [infrastructure-as-code](), [kubernetes](), [mcp](), [platform-engineering](), [pulumi](), [pulumi-neo](), [python](), [typescript]() ### AI overview This tutorial examines how Kubernetes infrastructure must be designed differently for AI agents, focusing on GPU scheduling, long-lived state, secrets, external tool access, and governance. It covers the agentic-Kubernetes ecosystem and provisioning with Pulumi using TypeScript and Python, including the role of Pulumi Neo. ### Source excerpt Kubernetes has become the default place teams run agentic AI workloads: CNCF's 2026 annual survey found that 66% of organizations hosting generative AI models use Kubernetes to manage some or all of their inference workloads.1 An entire ecosystem has grown up around that fact -- agent runtimes, model servers, GPU schedulers -- and most of it assumes the infrastructure underneath is already handled. It usually isn't. An AI agent is not a stateless web service, and provisioning for one takes more than copying a Deployment YAML and swapping the image. I spend a lot of my time these days thinking about what changes when the thing consuming your infrastructure isn't a person or a fixed pipeline, but an agent making its own calls about what to do next -- and Kubernetes is where I keep seeing that question show up first, because it's already where most teams run everything else. This post is about that gap: what changes about Kubernetes infrastructure when the workload is an agent, what the current agentic-Kubernetes ecosystem actually looks like, and how to provision and govern that infrastructure with Pulumi using TypeScript and Python -- plus where Pulumi Neo fits once the infrastructure itself has to answer to an agent. If you haven't read our take on the broader shift toward agentic infrastructure, What Is Agentic Infrastructure? is a good companion piece; this post stays specific to the Kubernetes layer. What makes agentic AI workloads different from ordinary Kubernetes workloads? An agent's resource and governance profile looks nothing like a typical web service, largely because it schedules accelerators, holds state across long sessions, and reaches out to systems a normal Deployment never touches. Dimension Typical web service Agent workload Compute CPU, predictable Often GPU/accelerator, bursty Session shape Short-lived, stateless requests Long-lived sessions, conversational state Egress Internal services, one database Model provider APIs, arbitrary tools, other agen ## Enforce Access Token Expiry Policies in Pulumi Cloud DevFeed: [Enforce Access Token Expiry Policies in Pulumi Cloud]() Original publisher: [Read original article]() Author: Devon Grove Published: 2026-07-27T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Cloud](), [API]() Tags: [api](), [cloud](), [compliance](), [features](), [organization](), [policy](), [product](), [rotation](), [security](), [tokens]() ### AI overview Pulumi Cloud organizations can enforce maximum expiry periods for access tokens. Administrators set a cap, and tokens without an expiration or with too much remaining lifetime are rejected when used against the organization. ### Source excerpt Pulumi Cloud organizations can now enforce a maximum expiry on the access tokens used against them. Organization admins can set a cap in days, and from that point on, personal, organization, and team tokens operating on resources in the org must carry an expiration within the cap for requests to succeed. Tokens that never expire, or that have too much lifetime remaining, get rejected with an error that tells the user exactly how to regain access. Why cap token lifetimes Many organizations already have a credential rotation policy that says tokens must expire, but until now, Pulumi Cloud could only recommend an expiry at creation time. Nothing stopped a member from creating a never-expiring personal token, and nothing aged out the long-lived tokens created before your policy existed. That gap matters because a leaked token is only as dangerous as its remaining lifetime. A token that never expires is a standing liability. By adding support for access token expiry policies, Pulumi Cloud now closes the gap at the platform level. Once you've set the cap, Pulumi Cloud enforces it immediately for your organization, including for tokens that already exist. How it works In your organization's settings, navigate to Settings > Access Management > Other and scroll to Access token expiry policy: You can also get there from the Access Tokens tab, where a banner shows whether a policy is in effect -- select Edit policy: The policy is a single number: the maximum expiry, in days, for tokens used against your organization. Compliance is checked on every request, and a token complies when both of these are true: It has an expiration date. Never-expiring tokens violate any policy. Its remaining lifetime -- the time between now and its expiration -- is within the cap. Because compliance is based on remaining lifetime rather than the expiry chosen at creation, the policy is pragmatic about existing credentials: a token created a year ago with a two-year expiry becomes compliant once it has ## Preview ESC Changes with Environment Overrides DevFeed: [Preview ESC Changes with Environment Overrides]() Original publisher: [Read original article]() Author: Sean Yeh Published: 2026-07-23T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Command-line interface](), [configuration](), [Testing]() Tags: [cli](), [configuration](), [configuration-management](), [critical-infrastructure](), [esc](), [features](), [product](), [production](), [pulumi-cli](), [pulumi-esc](), [release](), [secrets](), [upgrade]() ### AI overview Pulumi introduces the --override-env flag for the Pulumi CLI, allowing teams to preview draft or alternate ESC environments during operations such as preview, up, refresh, and destroy. The feature helps reviewers validate configuration changes before approval and supports overrides through imported environment chains. ### Source excerpt Pulumi ESC makes it easy to store configuration and secrets for your Pulumi programs, and with Approvals for ESC you can review and approve changes before they go live. The new --override-env flag lets you preview any environment change, including an unapproved draft, to see exactly how it would affect your stack before it becomes the latest version. Example scenario Your team stores production app configuration in ESC and has enabled Approvals to keep bad values out of critical infrastructure. But one important question remains: how can reviewers properly validate a configuration change before approving it? Introducing: draft references and the -override-env flag We are introducing a new --override-env flag to the Pulumi CLI that works with every Pulumi operation that can consume ESC environments: preview, up, refresh, and destroy. This makes it easy to test configuration changes on the fly, giving your team the confidence to validate them as part of the review process. Example usages The basic usage is --override-env =, and you can override multiple environments at once! In this example, we are running a pulumi preview with environments app/myenv and app/myenv2 replaced by their draft versions (denoted by @draft:). pulumi preview \ --override-env "app/myenv=app/myenv@draft:123e4567-e89b-12d3-a456-426614174000" \ --override-env "app/myenv2=app/myenv2@draft:123e4567-e89b-12d3-a456-426614174000" The --override-env flag not only works with draft references, but for any environment too! Here is an example of deploying your stack with your AWS test environment: pulumi up --override-env "aws-login/prod=aws-login/testing" Note: --override-env can also override environments that are imported (directly or indirectly) from the ESC environment in your stack config. This allows you to override any environment in the import chain for full flexibility. Ways to use it Validate a draft ESC environment with your stack before approving One-off debugging w ## The Standalone ESC CLI Retired: Use pulumi env DevFeed: [The Standalone ESC CLI Retired: Use pulumi env]() Original publisher: [Read original article]() Author: Boris Schlosser Published: 2026-07-22T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Command-line interface](), [configuration](), [Loop Engineering]() Tags: [cli](), [configuration](), [esc](), [features](), [migration](), [platform](), [product](), [release](), [secrets](), [with]() ### AI overview Pulumi is retiring the standalone Pulumi ESC CLI and recommends using the Pulumi CLI's pulumi env commands instead. The ESC repository has been archived, while the command implementation remains in the Pulumi CLI. Users of the standalone CLI should migrate because it will not receive the latest features. ### Source excerpt Pulumi ESC CLI v0.26.0 is the latest standalone release. We encourage users to use the Pulumi CLI instead. The ESC repository has been archived and the code now lives under pulumi. Why are we making this change Pulumi ESC is the best way to store and manage configuration and secrets in your Pulumi programs and while you can certainly use ESC to store secrets and configurations for your applications or to manage your AI agents' credentials, it's still a core feature of Pulumi Cloud, and we want to make sure we deliver a consistent experience across our entire suite. In addition to consistency, ESC and the Pulumi CLI share a lot of capabilities to interface to Pulumi Cloud and we want to make it easier and simpler for our customers: it's now easier to understand which Pulumi organization you are working with, which user is logged in, etc. Playing nicer with humans and AI agents A single CLI means one binary to install, one login to manage, and one place to look things up. This simplicity is beneficial whether the operator is a person or an agent. AI agents love code, and they love CLIs. By unifying the Pulumi CLI and ESC we offer a single place to look up operations around your Pulumi programs. Agents can now reason better about where to store configuration and secrets, without being confused by multiple CLI options that interface against the same service. Faster improvements With a shared CLI, any improvement to account management is automatically delivered to both: Pulumi and ESC users. At the same time, both benefit from ESC improvements and new features from day 1. ESC is a core component of our platform; a separate interface no longer makes sense. The same code all along If you're wondering what actually changes under the hood: nothing about how the commands work. The pulumi env commands were never a reimplementation -- the Pulumi CLI has built them from the ESC CLI's own code since ESC's first release, which is why the same command surface has always been availab ## Kubernetes Agent Sandbox: What It Is and How to Deploy It with Pulumi DevFeed: [Kubernetes Agent Sandbox: What It Is and How to Deploy It with Pulumi]() Original publisher: [Read original article]() Author: Adam Gordon Bell Published: 2026-07-21T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [Kubernetes](), [AI Agent](), [Docker](), [Containers](), [Security]() Tags: [agent](), [agents](), [ai](), [gcp](), [gke](), [how-to](), [kubernetes](), [pulumi](), [security](), [tutorials]() ### AI overview This tutorial explains Kubernetes Agent Sandbox, a Kubernetes resource for running coding agents in disposable, kernel-isolated environments using gVisor or Kata Containers. It describes common deployment patterns and shows how to deploy the sandbox on GKE with Pulumi. ### Source excerpt When you use a coding agent, it can seem like there's a trade-off between autonomy and permissions. If you approve every command, it's safe but slow. Let it do whatever it likes and it works more autonomously, but as the nx supply-chain attack showed, that can go badly. The fix is to give the agent a sandbox: a box it's allowed to wreck, with limited permissions and scoped network access. The only files are the checkout you handed it, the only credentials are the task's own, and trashing the machine just means a disposable pod gets garbage-collected early. Pulumi Neo works this way, and if you want to scale that pattern up inside your own organization, the Kubernetes project Agent Sandbox is a great path to building your own. This post is what it is and how to deploy it on GKE with Pulumi. What is Agent Sandbox? Agent Sandbox is a Kubernetes SIGs project that gives AI agents isolated, disposable environments as Kubernetes resources: a Sandbox custom resource, backed by gVisor or Kata Containers for kernel-level isolation. You could build Agent Sandbox yourself. You'd need gVisor support, a userspace kernel that sits between the agent's code and your host. With that in place, you could approximate a sandbox for every agent by stringing together a StatefulSet of size one, a headless Service, and a PersistentVolumeClaim, plus some lifecycle machinery to keep warm pools of nodes around. Agent Sandbox wraps all of that up as a CRD, so you can run a Kubernetes cluster where each sandbox is a disposable, kernel-isolated environment a coding agent runs in. apiVersion: agents.x-k8s.io/v1beta1 kind: Sandbox metadata: name: demo-sandbox spec: podTemplate: spec: runtimeClassName: gvisor containers: - name: agent image: ubuntu:24.04 # swap in your coding-agent image command: ["sleep", "infinity"] The Sandbox CRD, the whole idea in one manifest. There are two common patterns for using it. In the first, every coding agent session in the organization maps to its own pod with a pers ## Incident Response as Code: Managing PagerDuty with Pulumi DevFeed: [Incident Response as Code: Managing PagerDuty with Pulumi]() Original publisher: [Read original article]() Author: Engin Diri Published: 2026-07-20T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [pulumi](), [Incident response](), [Amazon Web Services](), [TypeScript](), [Amazon Simple Queue Service (SQS)]() Tags: [aws](), [devops](), [incident](), [incident-response](), [infrastructure-as-code](), [pagerduty](), [pulumi](), [sqs](), [tutorials](), [typescript]() ### AI overview A tutorial for managing PagerDuty incident-response resources and AWS alarm wiring together in a Pulumi program. The demo uses TypeScript to define an on-call team, escalation policy, PagerDuty service, SQS dead-letter queue, CloudWatch alarm, and SNS forwarding. ### Source excerpt You usually find out in the postmortem: the alarm fired, but it paged a schedule nobody was on anymore. Or the service had been running in production for three months before anyone created the matching PagerDuty service, so the first person to notice the outage was a customer. The infrastructure was code, reviewed and versioned. The incident response setup was forty clicks in a web UI, done once, by someone who has since changed teams. PagerDuty's own engineering team has been making the case for managing PagerDuty as code for years, and the OneUptime folks recently published a hands-on guide to the PagerDuty Terraform provider that walks the whole resource catalog. I liked both posts, and you probably know where this is going: I want the same thing in TypeScript, with the on-call setup and the infrastructure it protects living in the same Pulumi program. Teams, schedules, escalation policies, services, and the CloudWatch alarm that pages you: one pulumi up. What you are building The demo models a small platform team that owns a checkout service on AWS. On the PagerDuty side: a team with three members, a weekly on-call rotation, an escalation policy with two levels, and a service with a CloudWatch integration. On the AWS side: a dead-letter queue, an alarm that fires when a message lands in it, and an SNS topic that forwards the alarm to PagerDuty. The interesting part is where the two meet: the integration key PagerDuty mints flows straight into the SNS subscription without ever touching a clipboard. flowchart LR DLQ["SQS dead-letter queue"] --> Alarm["CloudWatch alarm"] Alarm --> SNS["SNS topic"] SNS -->|"HTTPS subscription with integration key"| Int["CloudWatch integration"] Int --> Svc["PagerDuty service Checkout API"] Svc --> EP["Escalation policy"] EP -->|"level 1"| Sched["Weekly rotation Lena, Jonas, Mia"] EP -->|"level 2, after 15 min"| Lead["Team lead"] Everything on both sides of that diagram is one TypeScript program. If you would rather write ## Best Terraform Alternatives in 2026 DevFeed: [Best Terraform Alternatives in 2026]() Original publisher: [Read original article]() Author: Pulumi Content Team Published: 2026-07-18T00:00:00Z Content type: comparison Language: en Sources: [Pulumi]() Topics: [Terraform](), [Infrastructure as code](), [opentofu](), [AWS CloudFormation](), [Platform Engineering](), [Artificial Intelligence](), [AI-assisted coding]() Tags: [2026](), [ai](), [ai-coding-agents](), [alternatives](), [devops](), [general](), [infrastructure-as-code](), [opentofu](), [platform-engineering](), [terraform]() ### AI overview A comparison of Terraform alternatives in 2026, including general-purpose-language platforms, HCL-compatible forks such as OpenTofu, and cloud-specific tools. It explains how licensing changes, HCL's limits for abstraction and testing, and AI coding agents are influencing infrastructure decisions. ### Source excerpt The strongest Terraform alternatives in 2026 fall into three groups: general-purpose-language platforms like Pulumi and AWS CDK, HCL-compatible forks like OpenTofu, and cloud-specific tools like AWS CloudFormation, Azure Bicep, and Crossplane. Which one fits depends less on syntax preference than on how well it lets your team, and your AI coding agents, read, test, and change infrastructure safely. What's changed since this list was last useful: HashiCorp archived CDK for Terraform in December 2025, OpenTofu shipped its 1.12 release in May 2026, and Pulumi now runs the same HCL files Terraform does, so authoring format and deployment engine are separate decisions. 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 wh ## Connect Your Cloud Accounts to Pulumi in Minutes DevFeed: [Connect Your Cloud Accounts to Pulumi in Minutes]() Original publisher: [Read original article]() Author: Levi Blackstone Published: 2026-07-15T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Cloud](), [Amazon Web Services](), [Azure](), [OpenID connect (OIDC)](), [Google Cloud Platform (GCP)](), [configuration](), [Authentication]() Tags: [aws](), [azure](), [cloud](), [configuration](), [esc](), [google-cloud](), [governance](), [identity](), [insights](), [openid-connect](), [policy](), [product](), [pulumi-cloud]() ### AI overview Pulumi introduces a Connect cloud accounts wizard for discovering and onboarding AWS accounts, Azure subscriptions, and Google Cloud projects in a single guided flow. It automates OIDC setup, creates Pulumi ESC environments, and applies discovery scans and policy packs. ### Source excerpt Pulumi Insights gives you visibility and governance across your entire cloud footprint, but that visibility is only as complete as the set of accounts you've connected. Until now, connecting an account meant repeating a manual setup for each one: OIDC configuration, hand-written Pulumi ESC environments, and per-account scan and policy setup. For an organization with dozens or hundreds of AWS accounts, Azure subscriptions, or Google Cloud projects, that per-account friction was the biggest obstacle to getting a complete picture. Today, the new Connect cloud accounts wizard removes it: discover every account in your cloud organization, select the ones you want, and onboard them all in a single guided flow. From hours of setup to a single flow The time savings are real: connecting a batch of accounts across AWS, Azure, and Google Cloud takes about three minutes end to end. Setting up those same accounts with the manual per-account workflow would take hours to days. The wizard handles the entire onboarding lifecycle for AWS, Microsoft Azure, and Google Cloud: Bulk discovery: Authenticate once with your cloud organization and the wizard lists every account, subscription, or project you can access. Accounts that are already connected are recognized and skipped. Automatic OIDC setup: The recommended flows configure each account with short-lived credentials based on OpenID Connect (OIDC) and workload identity federation. No long-lived cloud secrets are stored in Pulumi Cloud. ESC environments, created for you: The wizard generates Pulumi ESC environments that follow the best practices from the manual OIDC guides -- environments that previously had to be authored one by one. Scans and policies from day one: By default, scheduled discovery scans and a pre-built policy pack are applied to every account as part of setup: the Pulumi Best Practices pack on the Team and Enterprise editions, or a compliance pack (CIS, or NIST 800-53 for AWS and Google Cloud) on Business Critical. Ho [Next page]()