# pulumi Published articles for pulumi. 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 ## 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 ## 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. ## 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 ## 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 ## ITIL vs SRE: why the big clouds went their own way DevFeed: [ITIL vs SRE: why the big clouds went their own way]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-07-26T00:00:00Z Content type: opinion Language: en Sources: [Sridhar Rajarao]() Topics: [SRE](), [site-reliability-engineering](), [Development](), [Terraform](), [pulumi](), [Availability](), [feature flags](), [incident]() Tags: [automated](), [aws](), [azure](), [cloud](), [feature-flags](), [gcp](), [human-review](), [hyperscaler](), [incident](), [incident-management](), [infrastructure-as-code](), [itil](), [on-call](), [postmortems](), [pulumi](), [release](), [reliability](), [service-catalog](), [sre](), [terraform]() ### AI overview This opinion article compares ITIL practices with SRE operations at hyperscaler scale. It argues that human change boards, single production instances, developer-to-operations handoffs, documentation-first configuration management, and weekly release windows do not fit environments serving millions of external customers. It describes automated approvals, gradual deployments, service-team ownership, infrastructure as code, continuous release, error budgets, SLOs, and blameless postmortems as alternatives. ### Source excerpt The big clouds don't run ITIL. Five assumptions ITIL makes that break at hyperscaler scale, and what AWS, Azure, GCP, and OCI use instead. ## 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 ## Introducing Usage Limits for Pulumi Neo DevFeed: [Introducing Usage Limits for Pulumi Neo]() Original publisher: [Read original article]() Author: John Keiser Published: 2026-07-14T15:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [pulumi-neo](), [AI Agent](), [Artificial Intelligence](), [Cloud]() Tags: [agent](), [ai](), [ai-agent](), [ai-agents](), [billing](), [cloud](), [features](), [notifications](), [organization](), [product](), [pulumi](), [pulumi-cloud](), [pulumi-neo](), [token]() ### AI overview Pulumi introduces usage limits for Pulumi Neo, allowing paid-plan organizations to set monthly organization and per-member dollar limits. Neo pauses when a limit is reached, resumes in the next billing period, and supports email alerts at specified thresholds. ### Source excerpt Pulumi Neo is an AI agent that takes on real infrastructure work, and it's natural to want to hand it more and more. Usage limits give you control so you can do exactly that: set a monthly dollar limit, and Neo pauses when your organization reaches it. How usage limits work Your organization limit is a single monthly dollar amount covering all Neo usage across the org. To set one: In the Pulumi Cloud console, navigate to Settings -> Billing & usage -> Neo token usage. In the Manage token usage panel, enter an organization limit. Save your changes. When usage reaches the limit, Neo pauses for the rest of the billing period and resumes automatically at the start of the next one. An Admin or Billing Manager can raise the limit to resume before then. Enforcement happens at a natural boundary in Neo's work, so a task already in progress finishes its current step before pausing. As a result, usage can go a few dollars over the set limit. Per-member limits and alerts You can also set a separate limit for each member. A member is paused at whichever limit is smaller: their own or the organization's. For example, a member with a $200 limit under a $150 organization limit pauses at $150, because the organization limit is smaller. Turn on Enable email notifications to get a heads-up before you reach the limit. Billing admins are alerted at 50%, 80%, and 95% of the organization limit, with a final notice at 100% when Neo pauses. Get started Set your usage limits and stay in control as your organization hands Neo more and more work. Usage limits are available today for organizations on a paid plan, and an Admin or Billing Manager can set them. Sign in to Pulumi Cloud and set your first organization limit Read the Neo usage limits documentation for per-member limits, alerts, and enforcement details Join the Community Slack to share your feedback ## New: Versioned CLI and SDK Docs DevFeed: [New: Versioned CLI and SDK Docs]() Original publisher: [Read original article]() Author: Cam Soper Published: 2026-07-07T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Documentation](), [SDKs](), [Command-line interface]() Tags: [announcements](), [api](), [cli](), [community](), [docs](), [features](), [github](), [issue](), [java](), [net](), [node-js](), [product](), [pulumi](), [pulumi-cli](), [python](), [release](), [sdk](), [snapshots]() ### AI overview Pulumi has added version selectors to its CLI command reference and SDK API documentation. Users can choose documentation matching the Pulumi release they are running, with immutable snapshots available from v3.150.0 onward for the CLI and Node.js, Python, .NET, and Java SDKs. ### Source excerpt Pinned to an older Pulumi CLI or SDK version and finding that the docs describe a newer release? The Pulumi CLI command reference and the SDK API docs now include a version selector, so the documentation you're reading matches the version you're actually running. How it works When you open the CLI command reference, you'll see a version dropdown near the top of the page, below the title. The SDK API docs carry the same dropdown in the upper-right corner. Choose a release, and the page loads the documentation generated for that exact version. What's available Alongside the latest release, we keep immutable snapshots of previous versions going back to v3.150.0 (early 2025). The CLI command reference and the Node.js, Python, .NET, and Java SDK API docs are all covered, so the docs you need are only a dropdown away. (The Go SDK is versioned on pkg.go.dev, so its documentation lives there rather than in the Pulumi docs.) Get started Head to the CLI command reference or the SDK API docs and try the version dropdown. Selections are sticky, so when you navigate into a version, you'll be able to click around within that same version without having to choose it again. Have feedback? Let us know in the Pulumi Community Slack or by opening an issue on GitHub. Browse the CLI command reference ## Best Infrastructure as Code (IaC) Tools for 2026 DevFeed: [Best Infrastructure as Code (IaC) Tools for 2026]() Original publisher: [Read original article]() Author: Isaac Harris Published: 2026-07-05T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [Infrastructure as code](), [Provisioning](), [Terraform](), [opentofu](), [Software Engineering](), [Programming](), [AWS CloudFormation](), [Development]() Tags: [2026](), [aws](), [aws-cloudformation](), [azure](), [devops](), [general](), [google-cloud](), [iac](), [infrastructure-as-code](), [kubernetes](), [opentofu](), [programming](), [provisioning](), [pulumi](), [software-engineering](), [terraform]() ### AI overview A 2026 guide compares infrastructure as code tools including Pulumi, Terraform, OpenTofu, AWS CDK, AWS CloudFormation, Azure tools, Google Cloud Infrastructure Manager, Kubernetes YAML, and Crossplane. It discusses their approaches, licensing, pricing, AI-agent readiness, and tradeoffs, while explaining how IaC applies software engineering practices such as version control, testing, code review, and CI/CD to infrastructure management. ### Source excerpt The best infrastructure as code (IaC) tools in 2026 are Pulumi, Terraform, OpenTofu, AWS CDK, AWS CloudFormation, Azure ARM, Azure Bicep, Google Cloud Infrastructure Manager, Kubernetes YAML, and Crossplane. Each takes a different approach to defining and provisioning infrastructure, from general-purpose programming languages to declarative templates, and each carries distinct licensing, pricing, and AI-agent readiness tradeoffs worth weighing before you commit. Pulumi's own package registry lists hundreds of packages -- first-party providers, bridged Terraform providers, and community components -- illustrating how far multi-cloud coverage has expanded across the ecosystem. Since this post was published, Pulumi has added first-class support for HashiCorp Configuration Language (HCL). You can now write Pulumi programs in HCL directly, alongside general-purpose languages like TypeScript, Python, Go, and C#. To see how it works, see Pulumi HCL. As infrastructure complexity grows, teams increasingly seek approaches that provide the same developer productivity tools they use for application development. While template-based and domain-specific language approaches serve many use cases effectively, teams with complex requirements or programming backgrounds often find that general-purpose programming languages offer advantages in testing, abstraction, and collaboration. This comprehensive guide examines the most effective infrastructure as code tools available today, providing detailed analysis of core IaC platforms, complementary tools, and related technologies through the lens of software engineering best practices. Whether you're starting fresh with IaC or evaluating alternatives to overcome limitations in your current toolchain, we'll help you navigate this complex landscape and choose solutions that truly bring software engineering to infrastructure. Ready to try one of these approaches yourself? Get started with Pulumi for free and provision your first resource in minu ## Pulumi ships a 238-policy ISO/IEC 27001:2022 pack for AWS DevFeed: [Pulumi ships a 238-policy ISO/IEC 27001:2022 pack for AWS]() Original publisher: [Read original article]() Author: Dan Biwer Published: 2026-06-30T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Amazon Web Services](), [Security](), [Cloud](), [configuration]() Tags: [audit](), [aws](), [compliance](), [crossguard](), [features](), [governance](), [infrastructure](), [iso](), [iso-27001](), [policy](), [policy-as-code](), [product](), [pulumi](), [pulumi-cloud](), [security](), [standard]() ### AI overview Pulumi announces a pre-built ISO/IEC 27001:2022 policy pack for AWS, available in Pulumi Cloud as iso-27001-aws. The pack contains 238 policies mapped to relevant ISO 27001 controls and supports auditing existing AWS resources and preventing non-compliant resources during pulumi up. ### Source excerpt ISO/IEC 27001 is the international standard for information security management. Proving you meet it usually means months of mapping abstract security controls to concrete cloud configuration, then authoring custom checks one resource at a time. We're changing that. Today we're shipping a pre-built ISO/IEC 27001:2022 policy pack for AWS, live now in Pulumi Cloud as iso-27001-aws. It encodes the standard's security expectations as 238 ready-to-run policies, so you can align your AWS estate to ISO 27001 in minutes, not months. Why ISO 27001 matters For many companies, ISO 27001 is what stands between them and a customer or a market. The sooner you can reach a certifiable state and prove you stay there, the less compliance slows the business down. The pack collapses months of policy work into something you run continuously, so security keeps pace with growth instead of blocking it. How the pack maps to ISO 27001 The hard part of ISO 27001 has always been translation: its controls are written in the language of governance and risk management, not in the language of AWS resources. Every team has had to interpret each control and decide what it means for an S3 bucket or an RDS instance. The pack does that interpretation for you. Its 238 policies are aligned to the relevant ISO 27001 controls, so each result connects back to the standard instead of leaving you to map it yourself. You can browse the full pack in the pack reference. Audit and prevent The same pack works two ways, so you can both reach compliance and stay there: Audit. Scan your existing AWS estate against the pack, including resources that Pulumi doesn't manage. You get an honest baseline of where you stand against ISO 27001 today, with every finding tied back to the control it affects. Prevent. Run the same pack as a preventative policy during pulumi up to block non-compliant resources before they're ever created. New infrastructure is born aligned to the standard. Audit gets you clean. Preventative policie ## Introducing ESC Secret Rotation Webhooks DevFeed: [Introducing ESC Secret Rotation Webhooks]() Original publisher: [Read original article]() Author: Sean Yeh Published: 2026-06-26T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [pulumi-esc](), [secret rotation](), [notifications](), [pulumi-cloud](), [pulumi-cli](), [TypeScript](), [GitHub]() Tags: [cli](), [esc](), [github](), [notifications](), [product](), [pulumi](), [pulumi-cli](), [pulumi-cloud](), [rotation](), [secret-rotation](), [secrets](), [slack](), [typescript](), [webhooks]() ### AI overview Pulumi introduces ESC secret rotation webhooks, which trigger on successful or failed environment secret rotations. They can notify teams in Slack, refresh services using old credentials, and help detect failed rotations before outages. ### Source excerpt Pulumi ESC centralizes your secrets and configuration, and it can automatically rotate secrets on a schedule so credentials never go stale. But a rotation is only useful if the systems that depend on it know it happened. ESC secret rotation webhooks close that gap by notifying you the moment a secret rotates. Introducing secret rotation webhooks With ESC webhooks, you can react to rotations automatically. When ESC rotates an environment's secrets, a webhook can be configured to trigger on either success or failure. Use it to notify your team in Slack, refresh services that hold the old credential, or catch a failed rotation before it causes an outage. How to configure Pulumi Cloud Console Using the Pulumi Cloud Console, you can now configure webhooks for "Environment rotation succeeded" and "Environment rotation failed" in your ESC Environment's Settings page (under Settings -> Notifications). Pulumi Service Provider You can use the Pulumi Service Provider in your Pulumi program to configure webhooks. Here is an example in TypeScript: const environmentWebhook = new service.Webhook("env-webhook", { active: true, displayName: "env-webhook", organizationName: "my-org", projectName: environment.project, environmentName: environment.name, payloadUrl: "https://example.com", filters: [WebhookFilters.EnvironmentRotationSucceeded, WebhookFilters.EnvironmentRotationFailed], }) Pulumi CLI You can also use the Pulumi CLI to configure the webhook: pulumi env webhook new my-org/project/env env-webhook \ --url https://example.com \ --event environment_rotation_succeeded \ --event environment_rotation_failed Get started Secret rotation webhooks are available now for all Pulumi ESC environments. See the webhooks documentation to get started, and share your feedback on our GitHub repository. ## Build a Governed Databricks Workspace with Pulumi DevFeed: [Build a Governed Databricks Workspace with Pulumi]() Original publisher: [Read original article]() Author: Pablo Seibelt Published: 2026-06-25T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [databricks](), [data-platforms](), [Tutorial](), [configuration](), [Security](), [Cloud]() Tags: [apis](), [cloud](), [configuration](), [data-engineering](), [databricks](), [governance](), [infrastructure-as-code](), [pulumi](), [security](), [tutorial](), [tutorials]() ### AI overview A tutorial on using Pulumi to establish a governed Databricks workspace baseline. It covers cluster policies, notebooks, secret scopes, permissions, and automated jobs, while distinguishing account-level from workspace-level resources and showing credential management with Pulumi ESC. ### Source excerpt Platform teams responsible for Databricks often find themselves manually configuring clusters and notebooks for every new data science team. This manual overhead leads to inconsistent cluster policies, runaway costs from oversized instances, and security gaps in workspace operations. Without a standardized way to provision workspace-local resources, data platforms become a fragmented collection of bespoke environments that are impossible to govern at scale. As Databricks usage grows across the enterprise, the lack of a governed workspace baseline becomes a major operational risk. Inconsistent policies lead to unpredictable billing and audit failures. Standardizing your Databricks environment with Pulumi ensures that every workspace starts with the correct cost controls, cluster policies, notebooks, and automated jobs, allowing your data teams to move faster without compromising governance. What you'll build In this post, you will learn how to provision a governed Databricks workspace baseline using Pulumi. You will build: Cluster policies to enforce instance types and cost controls. Workspace notebooks to standardize workload locations. Secret scopes and permissions to make access reviewable. Automated jobs that run on policy-constrained compute. By the end, you will have a reproducible workspace configuration that you can deploy to any new Databricks environment. The Databricks management boundary When managing Databricks with Pulumi, understand the boundary between account-level and workspace-level resources. Account-level: Creating cloud prerequisites such as VPCs, subnets, IAM roles, and Azure resource groups uses the cloud provider for your target platform. On AWS and GCP, Databricks workspace creation and account-level identity use the Databricks provider's account APIs, such as databricks.MwsWorkspaces; on Azure, the workspace itself is commonly managed with azure-native. Workspace-level: Managing clusters, jobs, notebooks, permissions, and secret scopes with ## Deploy a Private Hermes Agent on Render Securely with Pulumi, Modal, and Tailscale DevFeed: [Deploy a Private Hermes Agent on Render Securely with Pulumi, Modal, and Tailscale]() Original publisher: [Read original article]() Author: Engin Diri Published: 2026-06-24T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [Artificial Intelligence](), [Deployment](), [Self-hosted](), [Open Source](), [hosting](), [cloud-infrastructure](), [Code](), [ui](), [Messaging]() Tags: [agent](), [ai](), [ai-agents](), [building](), [code](), [hosting](), [how-to](), [modal](), [open-source](), [pulumi](), [pulumi-esc](), [python](), [render](), [security](), [self-hosting](), [server](), [services](), [tailscale](), [tutorials](), [typescript](), [ui]() ### AI overview A tutorial for deploying a private Hermes AI agent with Pulumi across Render, Modal, and Tailscale. Render hosts private services, Tailscale provides tailnet access, and Modal runs agent-generated code in temporary sandboxes. ### Source excerpt Personal AI agents had their breakout this year. OpenClaw crossed 100,000 GitHub stars within months of launching, and self-hosting your own assistant went from a hobbyist trick to something a lot of developers actually do. I wrote up how to deploy that lobster to AWS or Hetzner back when it was everywhere. The one people are switching to now is Hermes, the open-source runtime from Nous Research, and it caught on just as quickly. The reason shows up in every "I ditched OpenClaw for Hermes" thread: it actually learns, building up memory and writing its own skills as it goes instead of running off a static, human-written list. Here is the part the launch videos skip. Hermes writes and runs its own code, with no human approving the commands. A model that can write code will eventually write a bad one, and the only thing between that command and your credentials is the sandbox it runs in. That is the box you do not want on the public internet. Researchers found 175,000 exposed Ollama servers sitting open in early 2026, and attackers hijack the ones they find for compute. The fix is not a better lock on the front door. It is to have no front door at all. So this post deploys a private Hermes agent as one Pulumi program across Render, Modal, and Tailscale. The agent and its chat UI run as Render private services with no public URL, Tailscale puts the UI on your tailnet, and Modal runs the agent's code in throwaway sandboxes. One pulumi up to stand it up, one pulumi destroy to tear it down, around $50 a month. No Makefile, no CLI escape hatches, and an honest look at the few places "nothing on the public internet" still leaks. What is Hermes? Hermes is the open-source, MIT-licensed agent runtime from Nous Research. It runs continuously on a server rather than living in a browser tab, and you talk to it through a chat UI or a messaging platform like Telegram, Discord, Slack, or Signal. A few things make it more than a chatbot: It is model-agnostic. You point it at any provi ## Cloudflare-First Networking as Code with Pulumi DevFeed: [Cloudflare-First Networking as Code with Pulumi]() Original publisher: [Read original article]() Author: Pablo Seibelt Published: 2026-06-23T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [Cloudflare](), [networking](), [Security](), [configuration](), [Provisioning](), [Cloudflare Access]() Tags: [ci-cd](), [cloudflare](), [cloudflare-access](), [configuration](), [infrastructure](), [networking](), [pulumi](), [routing](), [security](), [tutorials](), [typescript](), [zero-trust]() ### AI overview This tutorial shows how to define a standardized Cloudflare edge baseline with Pulumi and TypeScript for multi-cloud applications. It covers DNS records, WAF custom rules, a Worker canary, and Cloudflare Access policies, followed by validation steps for the deployed configuration. ### Source excerpt Platform teams managing multi-cloud applications face a dangerous visibility gap. While origin infrastructure is tightly controlled, the edge configuration often drifts through manual console tweaks. DNS records point to stale origins, WAF rules are inconsistent across environments, and Zero Trust policies fail to keep pace with team changes. This edge drift leads to application exposure or routing failures that origin teams only notice after users report them. As applications span multiple clouds, the edge often becomes the most consistent layer for enforcing security and traffic policies. The cost of waiting for a unified edge strategy is high. Every manual change is a potential security hole or a performance bottleneck that bypasses your standard CI/CD rigor. What you'll build In this post, you will build a standardized Cloudflare edge baseline. You'll use Pulumi to define: DNS records to point to your multi-cloud origins. WAF custom rules to block malicious traffic before it hits your network. A Worker canary to handle edge logic and header validation. Zero Trust Access policies to secure internal tools and origin access. By the end, you will have a version-controlled edge that you can validate and deploy across any environment. The Pulumi program We'll build a Pulumi program that sets up a complete edge environment. This approach ensures that your edge security and routing are always in sync with your application code. Setting up the provider First, ensure you have the @pulumi/cloudflare package installed and your credentials configured. The examples below are checked against @pulumi/cloudflare@6.15.0, the current v6 Pulumi Registry API at the time of writing. npm install @pulumi/cloudflare@6.15.0 pulumi config set --secret cloudflare:apiToken "$CLOUDFLARE_API_TOKEN" Defining the infrastructure Here is the complete Pulumi program in TypeScript. If your zone already has a custom WAF ruleset for the same phase, import that ruleset or add the rule to your existing ## Build an EKS Environment Factory with Pulumi and vCluster DevFeed: [Build an EKS Environment Factory with Pulumi and vCluster]() Original publisher: [Read original article]() Author: Pablo Seibelt Published: 2026-06-04T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [Amazon EKS](), [Multitenancy](), [Kubernetes](), [Provisioning](), [Architecture & Design](), [Amazon Web Services](), [CI/CD]() Tags: [amazon-eks](), [architecture](), [aws](), [ci-cd](), [infrastructure](), [kubernetes](), [multi-tenancy](), [platform-engineering](), [provisioning](), [pulumi](), [tutorials]() ### AI overview A tutorial shows how to build an ephemeral Kubernetes environment factory with Pulumi, Amazon EKS Auto Mode, and vCluster. It uses a shared host cluster with virtual tenant clusters to reduce environment sprawl, provisioning delays, and operational overhead while preserving tenant isolation controls. ### Source excerpt 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 ## Why Choose Pulumi Over Terraform? DevFeed: [Why Choose Pulumi Over Terraform?]() Original publisher: [Read original article]() Author: Pablo Seibelt Published: 2026-06-02T00:00:00Z Content type: comparison Language: en Sources: [Pulumi]() Topics: [Infrastructure as code](), [Terraform](), [cloud-infrastructure](), [Programming](), [Software Engineering](), [Refactoring](), [Tooling](), [migration]() Tags: [cloud-infrastructure](), [general](), [infrastructure-as-code](), [migration](), [platform-engineering](), [programming](), [programming-languages](), [pulumi](), [refactoring](), [software-engineering](), [terraform](), [tooling]() ### AI overview This comparison explains why teams may choose Pulumi over Terraform for infrastructure as code. It highlights Pulumi's use of general-purpose programming languages, package managers, IDEs, testing, refactoring workflows, encrypted secrets, reusable components, and safeguards for destructive changes, while noting that provider bugs, drift, eventual consistency, unknown values, and poor abstractions still require engineering discipline. ### Source excerpt 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, JavaScript, Python, Go, .NET, or Java -- with YAML and HCL also supported as authoring languages -- 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 re ## Generating a Pulumi Provider from an OpenAPI Spec DevFeed: [Generating a Pulumi Provider from an OpenAPI Spec]() Original publisher: [Read original article]() Author: Luke Ward Published: 2026-05-28T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [OpenAPI Specification](), [Infrastructure as code](), [API](), [SDKs]() Tags: [api](), [iac](), [infrastructure-as-code](), [openapi](), [product](), [pulumi](), [pulumi-cloud](), [release]() ### AI overview Pulumi announces version 1.0 of the Pulumi Service Provider, generated from the Pulumi Cloud OpenAPI specification. The release expands the provider's resource surface and adds infrastructure-as-code support for fine-grained RBAC, Pulumi IDP catalogs, and audit-log export. ### Source excerpt Today, we are announcing v1.0 of the Pulumi Service Provider: a major milestone in managing Pulumi Cloud with Pulumi itself. The provider is now generated directly from the Pulumi Cloud OpenAPI specification, unlocking a dramatically expanded pulumiservice:api/* resource surface and enabling Pulumi Cloud capabilities to become available in the provider faster than ever before. This release also brings several major new capabilities to infrastructure as code, including fine-grained RBAC as code, Pulumi IDP as code, and audit log export as IaC. Together, these changes make the Pulumi Service Provider the most powerful and extensible way yet to manage and automate your Pulumi Cloud infrastructure. Why this matters for users Historically, every new Pulumi Cloud feature implied a follow-up PR in the provider before that feature could be used from a Pulumi program. The provider was always slightly behind the API it wrapped, and entirely new capability areas could take months to land. The api/* surface changes both timelines. Because the schema is derived from the OpenAPI spec at runtime: Whole new resource families land in the provider the same release they reach Pulumi Cloud. New fields, features, and enum values on existing resources show up across all five language SDKs the soon after they appear in the spec. What's new in v1.0 v1.0 lifts whole capability areas of Pulumi Cloud into the api/* surface, not just incremental field additions. None of it required bespoke provider code. Fine-grained RBAC as code. Custom roles, organization membership, and team role assignments are now managed resources. For example, defining a read-only role and assigning it to a team: const readOnly = new ps.api.Role("readOnly", { orgName: "acme", name: "stack-reader", description: "Read-only access to stacks across the org.", uxPurpose: "role", details: { __type: "PermissionDescriptorAllow", permissions: ["stack:read", "stack:list"], }, }); new ps.api.teams.Role("readOnlyForPlatform", { org ## Introducing pulumi do: Direct Resource Operations for Any Cloud DevFeed: [Introducing pulumi do: Direct Resource Operations for Any Cloud]() Original publisher: [Read original article]() Author: Christian Nunciato Published: 2026-05-22T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Infrastructure as code](), [Command-line interface](), [Cloud](), [Provisioning](), [Amazon S3](), [Amazon Web Services]() Tags: [ai-agents](), [aws](), [cli](), [command-line](), [features](), [iac](), [infrastructure](), [infrastructure-as-code](), [product](), [product-launches](), [pulumi](), [pulumi-cli](), [s3]() ### AI overview Pulumi introduces pulumi do, a terminal command for direct cloud resource operations. It can create, read, update, delete, and query resources across Pulumi-supported providers without requiring a project, code, or state. The article also describes how pulumi do, Agent accounts, and Pulumi ESC can support ad-hoc infrastructure work and AI agent workflows. ### Source excerpt Infrastructure as code is the right model for production systems. State tracking, drift detection, and repeatable deployments all matter when you're managing real workloads. But sometimes, you also need a quick, one-off interaction with the cloud: create a bucket or a database, look up a VPC, delete a stray resource. Today we're introducing pulumi do, a new command for direct resource operations. With pulumi do, you can create, read, update, delete, and query any cloud resource from the terminal with a single command, across thousands of Pulumi-supported providers -- no project, code, or state required. The problem: Sometimes IaC is more than you need When you're managing production workloads, IaC is the proven solution. Code lets you declare complex systems, state tracking catches drift before it becomes a problem, dependency graphs sequence changes safely, and policy keeps everything in bounds. That full lifecycle, especially with the backing of a platform like Pulumi Cloud, is exactly what you want to build systems that scale. But when you (or your coding agent) need an ad-hoc Postgres database, the simplest path with IaC still takes several steps: make a directory, create a project, configure your credentials, write the code, preview, deploy. It works, but it's not always necessary for what should be a simple operation. pulumi do collapses all of those steps into one, using the same Pulumi providers, resource model, and ecosystem that powers the core Pulumi platform. Resource creation is also only part of the problem. As Joe laid out in The Agentic Infrastructure Era, the real challenge for AI agents isn't with code or CLI commands, it's with everything else: getting a cloud account, resolving credentials, wiring configuration across multiple services. Agent accounts, also released this week, simplify this by letting an agent provision its own ephemeral Pulumi Cloud account, and Pulumi ESC takes care of consolidating credentials across providers. Together, with p ## Neo Automations: Scheduled Tasks Shipped as Pull Requests DevFeed: [Neo Automations: Scheduled Tasks Shipped as Pull Requests]() Original publisher: [Read original article]() Author: Pulumi Neo Team Published: 2026-05-21T14:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [pulumi-neo](), [Automation](), [pull-requests](), [pulumi](), [Amazon Web Services](), [Kubernetes]() Tags: [ai](), [ai-agents](), [automation](), [aws](), [features](), [kubernetes](), [product](), [pull-requests](), [pulumi](), [pulumi-neo]() ### AI overview Pulumi Neo now supports scheduled automations that run tasks on hourly, daily, weekday, or weekly cadences and open pull requests for proposed changes. The launch includes templates for provider freshness, encryption, backup, and activity audits, along with configurable prompts, permissions, and integrations. ### Source excerpt Recurring platform work slips: provider versions fall behind, drift accumulates between checks, and the quarterly audit keeps getting pushed back another month. Pulumi Neo can now run any task on a cadence you set, opening a pull request for each run. Automations in action Your platform team runs stacks across staging and production, and the AWS, GCP, and Kubernetes providers keep shipping new versions. Nobody has time to bump them stack by stack. You write one automation: Every Monday at 8 AM, check the infra/ project for stacks where the AWS, GCP, or Kubernetes provider is more than two minor versions behind. For each one, bump the out-of-date provider, run pulumi preview, and open a PR if the preview is clean. Monday morning, Neo runs the prompt. It finds three stacks behind on the AWS provider, edits each program, runs preview, and opens a PR for each clean run. You review the PRs like you would any other dependency bump, merge them, and Neo runs again next Monday. What automations are for The launch includes four built-in templates: a provider freshness check, an encryption audit, a backup audit, and an activity digest. You can also skip the templates and write your own prompt. Pick from hourly, daily, weekdays, or weekly cadences. Each automation gets its own page in the Automations tab, where you can edit the prompt, change the schedule, run it once on demand, or pause it. Safe by default Automations default to two settings that fit recurring work. Approval mode is auto, so a run doesn't wait for human confirmation between steps. Permission mode is read-only, so a run can read state and propose changes through pull requests but can't apply changes directly. You can override either default per automation. How automations fit with the rest of Neo A scheduled task uses the same context as an interactive Neo task. Custom Instructions at the organization and project level apply, so a scheduled run respects the same naming conventions, tagging policies, and archite [Next page]()