Pulumi Blog: Features

New: Versioned CLI and SDK Docs

Cam Soper — Tue, 07 Jul 2026 00:00:00 +0000

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

Enforce ISO 27001 Across Your AWS Infrastructure

Dan Biwer — Tue, 30 Jun 2026 00:00:00 +0000

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 policies keep you clean.

A growing library of pre-built packs

ISO 27001 joins a growing library of pre-built packs for AWS, each authored and maintained by Pulumi and kept current with its source standard:

ISO/IEC 27001:2022
CIS Controls v8.1
NIST SP 800-53 Rev. 5
PCI DSS v4.0
HITRUST CSF v11.5
Pulumi Best Practices

Adopting any pack means you skip the authoring work entirely, inherit framework mappings maintained by Pulumi, and apply a consistent baseline across every stack and account.

Get started today

The ISO 27001 pack is available now to every Pulumi Cloud user:

Browse the pack reference to see all 238 policies and how they map to the standard’s controls.
Explore the full pre-built packs index.
Follow the get-started guide to run your first audit.

Try Pulumi policies

Ready to align your AWS infrastructure to ISO 27001? Sign up for Pulumi Cloud and run the pack against your estate, or read the policy get-started guide to dig in.

Need a compliance pack for a framework that isn’t listed here? Open a request in pulumi/pulumi-cloud-requests or come tell us in the community Slack. We’re listening.

Neo code reviews: AI code review built for infrastructure

Pulumi Neo Team — Mon, 22 Jun 2026 08:00:00 -0700

Today we’re introducing Pulumi Neo code reviews, now in public preview. Neo code reviews analyze pull request changes in conjunction with what Pulumi Cloud knows about your running infrastructure, providing both high-level and code-level feedback.

Normal code review agents can’t reliably anticipate the impact an infrastructure-as-code change will have. This is because they don’t have access to critical aspects of the IaC workflow: the potential impact the update will have, in this case the pulumi preview output; and the current state of the cloud infrastructure. Neo not only has access to both of those, but also to the entirety of your other cloud context, such as stack relationships and dependencies.

Running reviews

Neo can review every pull request automatically, or only when someone mentions @pulumi-neo. Either way, it skips draft pull requests and those opened by bots by default.

A review is a comment, so it informs the person approving the merge and sits alongside the required checks and branch protection you already enforce. Neo code reviews run inside the same governance as every other Neo task, with the RBAC, guardrails, and audit logging your organization has set.

Enable code reviews

Neo code reviews are available on GitHub during public preview. They require Pulumi Neo to be enabled for your organization, the Pulumi GitHub App installed on the repositories you want reviewed, and a one-time grant from each organization user to access their GitHub account under Management > Version control. If Neo currently posts preview summaries on your pull requests, code reviews are already enabled, and they take the place of those summaries.

Neo code reviews are free while in public preview. On July 1, 2026, they’ll be generally available, and reviews will begin counting toward your organization’s Neo token usage, at the same per-token rate as any other Neo task. The pricing page shows that rate and the monthly token allotment included with each plan.

Give it a try

Open a pull request against a stack Pulumi manages and see Neo’s review. We want to hear what it catches and what it misses, so hop into the Pulumi Community Slack and tell us.

Trigger Deployments on Git Tags

Michael Fallihee — Fri, 05 Jun 2026 00:00:00 +0000

A git tag is how many teams mark a release as ready. Pulumi Deployments can now act on that signal directly: configure a tag-based trigger, push a version tag like v1.2.0, and Pulumi automatically runs pulumi up for your stack. No extra pipeline glue, no manual click — your release tag is the deployment.

Why tags?

Push to Deploy has long let you preview changes on a pull request and update a stack when commits merge to a branch. That branch-based model is a great fit for continuous delivery to shared development and QA environments, where every merge should flow straight through.

But promotion to production is often deliberate, not continuous. You merge throughout the day, then decide — separately — that a particular commit is the release. The conventional way to record that decision is a git tag: v1.2.0, 2026.06.0, release-2026-06-04. Tagging is already part of most teams’ release rituals.

Tag-based triggers connect that ritual to your infrastructure. Instead of wiring up a separate CI job to call the Pulumi Deployments REST API on a tag event, you configure the trigger once in your stack’s deployment settings and let Pulumi handle the rest.

How it works

Tag triggers are controlled by two settings on your stack’s deployment configuration:

Run updates for pushed tags — a toggle that enables running pulumi up when a matching tag is pushed.
Tag filters — a list of glob patterns that decide which tag names qualify.

Tag filters use the same model as the path filters you may already know, except the patterns match against the tag name rather than changed file paths. A few examples:

v* — deploy on any tag beginning with v, such as v1.0.0 and v2.3.1.
v* plus !*-rc* — deploy on release tags but skip release candidates like v1.2.0-rc1.
2026.* — deploy on calendar-versioned releases such as 2026.06.0.

Filters prefixed with ! are exclusions, and an exclusion always wins over an include. With no filters configured and the toggle on, every tag push deploys. Deleting a tag never triggers a deployment.

When a tag push kicks off a deployment, Pulumi sets the PULUMI_CI_TAG_NAME environment variable to the tag name. Your pre-run commands or your Pulumi program can read it — for example, to stamp the release version onto a resource tag or an application config value.

Works across every VCS integration

Tag triggers are available across all five version control integrations: GitHub, GitLab, Bitbucket, Azure DevOps, and Custom VCS.

Get started

You can configure tag triggers wherever you manage deployment settings today — the Pulumi Cloud console, the REST API, or as code with the pulumiservice.DeploymentSettings resource.

To try it out:

Open a stack’s Settings > Deploy tab in the Pulumi Cloud console.
Enable Run updates for pushed tags and add a tag filter such as v*.
Push a tag — git tag v1.0.0 && git push origin v1.0.0 — and watch the deployment run.

For the full details, see the deployment triggers and tag filtering documentation. We’d love to hear how you put tag-based deployments to work.

Introducing pulumi do: Direct Resource Operations for Any Cloud

Fraser Waters — Fri, 22 May 2026 00:00:00 +0000

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 pulumi do, agents can now go from zero to deployed infrastructure without requiring a human in the loop — and when that one-off resource needs to grow into a more permanent system, there’s a clear graduation path back to full Pulumi IaC.

What it looks like

As an example, say you wanted to provision an S3 bucket. With the AWS CLI, you’d need to assemble an aws s3api create-bucket invocation with the right set of command-line flags, region constraints, a globally unique name, and so on. With pulumi do, it’s just this:

$ pulumi do aws:s3:Bucket create

That might not look all that different on the surface — but because you’re using the Pulumi engine and resource model, you can provide a minimal set of input properties, take advantage of provider-defined defaults, and use Pulumi’s auto-naming feature to give the bucket a unique name automatically:

$ pulumi do aws:s3:Bucket create

This will create aws:s3/bucket:Bucket with the following inputs:
{
 "bucket": "bucket-279ea56",
 "tagsAll": {}
}

Please confirm that this is what you'd like to do by typing `yes`:

Answer yes (or just pass --yes), and you’re done. To delete the bucket:

$ pulumi do aws:s3:Bucket delete bucket-279ea56 --yes

Need to look up an existing resource? Use a provider function:

$ pulumi do aws:ec2:getVpc --default

{
 "arn": "arn:aws:ec2:us-west-2:663782525873:vpc/vpc-d7b311af",
 "cidrBlock": "172.31.0.0/16",
 "enableDnsHostnames": true,
 "enableDnsSupport": true,
 "enableNetworkAddressUsageMetrics": false,
 "id": "vpc-d7b311af",
 ...
}

Same CLI, same output contract, same provider ecosystem.

The command shape

The do command accepts a Pulumi resource type, or type token, to determine the action to take. Type tokens have the form <package:module:resource>. For example, aws:s3:Bucket refers to the Amazon S3 Bucket resource that belongs to the s3 module of the aws package.

You can also provide a portion of the token to help you find what you’re looking for without ever having to leave the terminal:

$ pulumi do aws:s3

Functions and resources for the s3 module.

Run 'pulumi do <module/resource/function> --help' for more details on usage.

Functions:
 aws:s3:getAccessPoint
 aws:s3:getAccountPublicAccessBlock
 aws:s3:getBucket
 aws:s3:getBucketObject
 ...

Resources:
 aws:s3:AccessPoint
 aws:s3:AccountPublicAccessBlock
 aws:s3:AnalyticsConfiguration
 aws:s3:Bucket
 ...

$ pulumi do aws:s3:Bucket read bucket-d20976f

{
 "arn": "arn:aws:s3:::bucket-d20976f",
 "bucket": "bucket-d20976f",
 "bucketDomainName": "bucket-d20976f.s3.amazonaws.com",
 "bucketNamespace": "global",
 ...
}

The package, module, and resource/function segments all come directly from the Pulumi provider schema, so --help works at every level of the tree. Pass a package name, optional module, and optional function or resource type, and do returns the appropriate level of detail.

You can also provide the input properties of a resource in a YAML or JSON file with the --input option. To create a container service in Google Cloud Run for example:

# service.yaml
location: us-central1
deletionProtection: false
template:
 containers:
 - image: us-docker.pkg.dev/cloudrun/container/hello

$ pulumi do gcp:cloudrunv2:Service create \
 --input yaml \
 --input-file service.yaml

This will create gcp:cloudrunv2/service:Service with the following inputs:
{
 "deletionProtection": false,
 "location": "us-central1",
 "name": "service-b8af752",
 "template": {
 "containers": [
 {
 "image": "us-docker.pkg.dev/cloudrun/container/hello"
 }
 ]
 }
}

The result:

{
 "createTime": "2026-05-22T23:00:22.415839Z",
 ...
 "urls": [
 "https://service-b8af752-921927215178.us-central1.run.app",
 "https://service-b8af752-ctnulmzwoa-uc.a.run.app"
 ]
}

Resource operations

Most resources support the full set of CRUD operations — create, read, update, delete, and list — directly from the CLI. Each operation maps to a provider CRUD method using the same provider logic a full Pulumi program would use, and resources are addressable by their cloud provider IDs:

# Create a resource
$ pulumi do aws:s3:Bucket create --yes | jq -r ".name"
bucket-4f5cb22

# Fetch it
$ pulumi do aws:s3:Bucket read bucket-4f5cb22 | jq -r ".hostedZoneId"
Z3BJ6K6RIION7M

# Update/patch it
$ pulumi do aws:s3:Bucket patch bucket-4f5cb22 --input yaml --input-file tags.yaml

$ pulumi do aws:s3:Bucket read bucket-4f5cb22 | jq ".tags"
{
 "key": "value"
}

# Delete it
$ pulumi do aws:s3:Bucket delete bucket-4f5cb22

Provider configuration

Today, pulumi do resolves provider configuration — for example, applying your AWS credentials — using environment variables or credential files as supported by each individual Pulumi provider. See the Pulumi Registry for provider-specific configuration details.

Designed for humans and agents

We’ve designed pulumi do to serve humans and coding agents equally well, guided by three fundamental ideas:

Consistent command structure across every provider. The do <package:module:type> <operation> pattern is the same for AWS, Azure, Google Cloud, Kubernetes, Cloudflare, Datadog, and every provider, including packages containing higher-level component resources. Once an agent learns that pattern, it applies across the board.
Predictable output contract. JSON on stdout, progress on stderr, consistent exit codes. An agent can parse the result programmatically without scraping human-formatted tables.
A single CLI command that works across every cloud. Many cloud and SaaS providers don’t have a full CLI at all. pulumi do generates commands from the provider schema, so if a Pulumi provider exists for it, the CLI just works. Neither humans nor agents need to install, learn, or even know about cloud provider-specific tooling.

What’s next

Resource operations and provider functions are the foundation. The pulumi do roadmap extends the same direct-operation model with credential management, state tracking, and a path to full IaC.

Unified credentials with Pulumi ESC

One of the hardest parts of multi-cloud operations is credential management. Every provider has its own authentication scheme, environment variables, and session lifecycle. An agent working across AWS, Cloudflare, and Datadog today manages three separate credential mechanisms.

We’re building Pulumi ESC integration into pulumi do so you can manage credentials in one place and resolve them everywhere. ESC handles credential resolution (including OIDC-based dynamic credential generation and short-lived tokens) across all of your providers. Name the credential set, reference it, and ESC does the rest, with rotation, RBAC, and audit built in.

Cross-resource references

Real infrastructure has dependencies — subnets need VPCs, security group rules need their security groups, and so on. When you’re building resources one at a time, those references need to flow between commands somehow.

A future version of pulumi do will let resource inputs reference outputs from previously created resources, allowing the CLI to resolve them automatically and preserve the dependency graph. Later, when the time comes to graduate to a full IaC program, the generated code contains proper resource references rather than hard-coded strings.

Stateful mode and the graduation path

Today, pulumi do is stateless. Each command runs independently. A planned stateful mode will persist resource state across operations, enabling drift detection, lifecycle management, and a graduation path to full infrastructure as code.

Here’s what we’re planning:

Zero setup. Your first pulumi do implicitly creates a project and stack. No manual initialization.
Accumulate resources. Each operation stores resource state. After a few commands, you have a lightweight representation of your infrastructure.
Eject to a full project. When the time comes, generate a Pulumi project in your chosen language with all resources imported and dependency graphs intact.
Connect to Pulumi Cloud. Layer on governance, compliance, team collaboration, and deployment automation through Pulumi Cloud. Resources created via pulumi do can be governed by Pulumi Insights from day one, even before you opt into full IaC.

This path works because pulumi do uses the same providers, resource types, and property schemas as every other pulumi operation. Provisioned cloud resources stay where they are as management capabilities are added as needed.

Get started

pulumi do ships as a research preview in Pulumi CLI v3.242.0 and later. Install or update the CLI, install a provider plugin, and start running commands. The documentation has the full reference.

We can’t wait to hear your feedback. Give it a try today, tell us what works (and what doesn’t), and help shape the CLI that agents and humans both reach for first.

Bringing Neo to GitHub and Slack

Pulumi Neo Team — Thu, 21 May 2026 08:00:00 -0700

This week, Pulumi Neo started working in two more places: GitHub and Slack. The agent that already runs Pulumi tasks from the Cloud console and the terminal now participates in the threads where your team discusses changes.

Mention @pulumi-neo in a pull request or issue and Neo replies in the thread. Mention @Neo in a Slack channel and Neo starts a task, continuing the conversation as you reply.

Neo in GitHub

Mention @pulumi-neo in a pull request description, a top-level or inline review comment, or an issue. Neo sees the diff, the stacks linked to the repository, and their current state. Reviewers can ask Neo to walk through what a proposed change does, including resources that change in stacks the PR doesn’t touch directly. Responses land in the same thread, so the analysis becomes part of the review record and any follow-up stays with it.

Neo in Slack

Mention @Neo in any channel where Neo has been added, and Neo starts a task in the thread. The reply lands in the same thread, and follow-up messages continue the conversation there. The rest of the channel can see what was asked and what Neo found. Neo has the same capabilities here as in the Pulumi Cloud console or the terminal: check stack state, investigate failures, walk through what a change will do, or carry out actions the team has approved.

Integrations in action

A teammate posts in #platform-engineering: “API latency p95 has been climbing for two days, nobody can figure out why.” You reply:

You: @Neo check the production API stack. Anything change in the last 72 hours?

Neo starts a task in the thread, walks the stack history, and finds a configuration change to the load balancer’s idle-timeout setting that landed Friday afternoon. It posts the change, who deployed it, and when. The rest of the channel sees the finding without you having to retell it.

You: @Neo open a PR to revert idle-timeout to the previous value.

Neo edits the stack’s Pulumi program, runs pulumi preview to confirm the change touches only the load balancer, and opens a pull request with the diff and the preview output. A reviewer pulls it up:

Reviewer: @pulumi-neo what else does this change affect downstream?

Neo replies in the same review thread with the resources that change: the listener config and the target group health check. The reviewer reads, approves, and the change ships.

The investigation moved from Slack to GitHub, and both threads keep the record.

Permissions and governance

Whether the conversation starts in GitHub or Slack, Neo runs with the RBAC permissions of your Pulumi Cloud user. Stack-level controls, organization-level guardrails, and audit logging apply the same way they do for a task started from the console. Starting a conversation in a new place doesn’t grant Neo new permissions; it just changes where the conversation happens.

Try it out

Both integrations are available now for Neo-enabled organizations. The Code Reviews docs and Slack integration docs cover the one-time setup. From there, every engineer with a linked Pulumi Cloud identity can mention Neo from the threads they already work in.

Today’s launch is part of a bigger story. Read our launch-day piece on the agentic infrastructure era for the broader vision, the Neo CLI launch post for Neo’s new home in the terminal, and the Neo Integrations post for the MCP servers and cloud CLIs that ship with this release.

As always, we’d love to hear what you think — and if you have any suggestions for places we should put Neo next, file an issue in pulumi-cloud-requests.

Neo Automations: Scheduled Tasks Shipped as Pull Requests

Pulumi Neo Team — Thu, 21 May 2026 07:00:00 -0700

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 architecture rules your team has written down.

MCP integrations and CLI integrations work in scheduled tasks the same way they work in interactive ones, so a weekly drift check can query AWS through the aws CLI, file Linear issues, and link related PagerDuty incidents. Scheduled tasks also run with the RBAC permissions of the user who scheduled them, checked at run time; if permissions change between scheduling and execution, the new permissions apply.

Try it out

Open Neo in Pulumi Cloud, switch to the Automations tab, and pick a template or write your own prompt. The automations docs cover the form, scheduling options, and per-automation overrides.

Today’s launch is part of a bigger story. Read our launch-day piece on the agentic infrastructure era for the broader vision, and the Neo Integrations post for the third-party tools and CLIs your automations can use.

As always, we’d love to hear what you think — and if you have any suggestions for automations that’d make Neo even better, file an issue in pulumi-cloud-requests.

Neo, Now in the Terminal

Pulumi Neo Team — Wed, 20 May 2026 00:00:00 +0000

Since launching Pulumi Neo, over 4,500 organizations have used it to delegate real infrastructure work: scaffolding, migrating, investigating, operationalizing, and more. Though that usage has come entirely through Pulumi Cloud, we know a large portion of Pulumi users live in the terminal, and increasingly that’s where AI tools run too. Now we’re bringing Neo there.

pulumi neo brings the same Neo experience you’ve had in Pulumi Cloud to your terminal. Running locally means there’s no separate branch to push, no credentials to provision, and no context to paste: Neo picks up the setup you already have.

What local execution unlocks

Neo inherits your setup when it runs locally. The CLIs you’ve authenticated, the environment variables and kubeconfigs you’ve configured, and the project you’re editing right now are all available without any setup on your part. That means Neo can run the same commands you would, against the same systems you have access to.

That makes pulumi neo a fit for paired, interactive sessions where you and Neo work through a problem together. For asynchronous, autonomous tasks you set up and come back to, Pulumi Cloud Neo is still the surface to reach for. Both reach the same Neo.

You can also hand tasks to Neo from other agent sessions. Simply ask your agent, such as Claude Code or Codex, to hand the task off to Neo, and the Neo handoff skill packages the current thread (goal, repo pointers, conversation summary) and starts a Neo task using pulumi neo under the hood. This works anywhere skills are supported, without leaving your current session.

What carries over

Local tools and context are what’s new. The full set of controls you have in Pulumi Cloud Neo applies in the terminal: approval modes (manual, balanced, auto) for tool calls, permission modes (default, read-only) for what Neo can change, and Plan Mode for research and planning before execution.

Integrations carry over too. The integration catalog (connectors to Atlassian, Datadog, Linear, PagerDuty, and others) works the same way from the terminal. Identity, RBAC, and audit all run through your pulumi login, the same way they do in the console. See the Pulumi Neo docs for details.

Get started

pulumi neo ships with the latest Pulumi CLI. To start a session:

Authenticate to Pulumi Cloud with pulumi login.
Run pulumi neo, or pass an initial prompt: pulumi neo "what's in this stack?".

pulumi neo is part of a broader launch on agentic infrastructure. See the pulumi neo command reference and the Pulumi Neo docs for details. 10 things you can do with Neo is a good starting point for tasks to try. The Pulumi Community Slack is the place for questions and feedback.

Neo Integrations: MCP Servers and Cloud CLIs

Pulumi Neo Team — Wed, 20 May 2026 00:00:00 +0000

Pulumi Neo already understands your infrastructure: your code, your stacks, your state. Today we’re launching new capabilities that extend Neo’s reach in two directions: into the third-party systems your team uses to plan and observe, and out to the cloud CLIs that actually drive your infrastructure.

The first half is MCP integrations: connections to Atlassian, Datadog, Honeycomb, Linear, PagerDuty, and Supabase that show up as tools Neo can call during a task. The second half is CLI integrations: scopable access to aws, gcloud, az, and kubectl. Both are configured once at the org level and available to every Neo task in the organization.

Integrations in action

A PagerDuty alert just fired: RDS storage on payments-prod is at 90% and climbing. You want to know how fast, and whether you can buy yourself any runway before it fills.

You: Neo, RDS storage on payments-prod just paged at 90%. How fast is it growing, and what do we have configured?

Neo pulls the active incident from PagerDuty, decides on its own to check Datadog for the storage-utilization curve over the last 30 days, and runs aws rds describe-db-instances --db-instance-identifier payments-prod through your production-aws CLI integration (the name your org gave its production AWS credentials). The database has been growing about 5 GB a day. The instance has AllocatedStorage at 200 GB and MaxAllocatedStorage also at 200, so storage autoscaling is effectively disabled. At current growth, the disk fills in three days.

You: Bump max allocated storage to 500. Open a PR.

Neo edits the payments stack’s Pulumi program to raise maxAllocatedStorage from 200 to 500 on the RDS instance, runs pulumi preview to confirm the change is scoped to that one resource, and opens a pull request with the diff, the preview output, and links to the PagerDuty incident and the Datadog graph. You review the PR and merge it. Pulumi applies the change, and Neo posts the resolution back to PagerDuty.

With three integrations and one conversation, the change is reviewed, shipped, and the alert resolved a few minutes later.

MCP integrations: context from your existing tools

The launch catalog covers six services that show up most often in infrastructure investigations: Atlassian for Jira issues and Confluence runbooks, Datadog for metrics and logs, Honeycomb for traces, Linear for issue tracking, PagerDuty for incidents and on-call schedules, and Supabase for managed database changes. Each connects Neo to a remote MCP server hosted by the provider, so the agent has access to the full set of tools the vendor chooses to expose.

Integrations can be enabled by organization administrators on the Neo Settings page. Once configured, they’re available to every Neo task in your organization.

CLI integrations: live cloud insights

CLI integrations cover what MCP doesn’t reach: live cloud insights. With AWS, GCP, Azure, or Kubernetes connected, Neo can check live database utilization, look up the current state of a running service, verify a service quota before scaling, or reach into resources that aren’t managed by any Pulumi stack.

An admin enables a CLI integration the same way as an MCP one, from your org’s Neo settings. Each integration gets a name your team chooses, like production-aws or staging-gcloud, and tasks reference that name to tell Neo which environment to reach into. You can connect multiple instances of the same CLI (for example, production-aws and staging-aws) so Neo can investigate staging without touching production. Credentials are backed by Pulumi ESC environments your org owns; the CLI integrations docs walk through setup.

Per-task control and failure handling

Both surfaces default to org-wide availability, with per-task overrides. Before starting a task, you can toggle individual MCP integrations off. The toggles only affect that task; the org-level configuration is unchanged.

Failures behave the same way for both. If an integration can’t be reached, Neo logs a warning, skips it, and continues with the rest. A single broken integration doesn’t stop a task. CLI integration connect and disconnect events go to your organization’s audit log, and Neo’s individual CLI calls appear in the task transcript alongside its other tool calls.

Try it out

Both MCP and CLI integrations are available now for Neo-enabled organizations. Open your org’s Neo settings, connect the MCP server or CLI of your choice, and let Neo do the next investigation against the tools you already use. The MCP integrations docs and CLI integrations docs walk through credential setup for each one, and the Neo integrations hub ties it all together.

Today’s launch is part of a bigger story. Read our launch-day piece on the agentic infrastructure era for the broader vision, and the Neo CLI launch post for Neo’s new home in the terminal.

As always, we’d love to hear what you think — and if you have any suggestions for integrations that’d make Neo even better, file an issue in pulumi-cloud-requests.

Better CLI Interactions for Agents and Humans

Michael Fallihee — Tue, 19 May 2026 04:00:00 -0700

AI agents do a lot of their work through CLIs. They’re easier to call than HTTP APIs and they produce predictable output. Over the last few months our own CLI traffic has shifted from mostly people typing commands to people and agents running commands together, often in the same session.

Today we’re shipping a release built for both. The Pulumi CLI is reorganized around three ideas: the right command should be the one you can guess, anything you can do in Pulumi Cloud should also be doable from the terminal, and what comes back should be just as readable to an agent as it is to a person.

Designing for guessability

The bar we set was that both developers and coding agents should be able to guess at the right command for a particular task: pulumi env edit to modify an environment, pulumi stack get to see what’s going on with a stack, pulumi org member list to see who’s on the team. If we had to explain which command did what, the usability bar hadn’t been met.

Branches in the tree are now singular nouns like stack, env, org, and deployment. Leaves are now verbs from a canonical vocabulary — list, get, set, new, edit, remove — and they mean the same thing wherever they’re used. edit always means modify an existing thing. Wherever the old vocabulary differed, though, the old name still works: ls, rm, update, and open are all aliased to preserve backward compatibility.

For the most part, product names have also been replaced with familiar nouns. Users (human or otherwise) don’t think in product names; they think in terms of resources, stacks, environments. For example, take Pulumi ESC: the product may be named ESC (and for a while the command was too), but nobody thinks I need to initialize a new ESC — they think I need to create a new environment. The command is therefore pulumi env new, with esc init preserved as an alias to avoid disrupting anyone’s existing workflows.

$ pulumi env new my-project my-env
Environment created.

All of Pulumi Cloud in the terminal

Up to now, most of what you could do with Pulumi Cloud had to be done either in the browser or through direct API calls. Things like reviewing deployments, setting up webhooks, finding non-compliant resources, or managing deployment settings all required you to break out curl and hit the API docs or open a browser and navigate the Pulumi Cloud console.

That changes today. Pulumi Cloud is now fully accessible from the command line through the pulumi CLI, with consistently named nouns and verbs aligned to what you’d expect:

pulumi stack get returns a complete stack overview, metadata, resource list, and more:

$ pulumi stack get \
 --stack cnunciato/chris.nunciato.org/production \
 --output json | jq -r ".resources[].type" | grep "aws:s3"

aws:s3:BucketEventSubscription
aws:s3/bucket:Bucket
aws:s3/bucket:Bucket
aws:s3/bucketPublicAccessBlock:BucketPublicAccessBlock
aws:s3/bucketWebsiteConfiguration:BucketWebsiteConfiguration
aws:s3/bucketOwnershipControls:BucketOwnershipControls
aws:s3/bucketNotification:BucketNotification

… with other stack-related commands like pulumi stack history get events, pulumi stack drift list, pulumi stack schedule new, and pulumi stack webhook new alongside it.

Organizational commands like pulumi org member list, pulumi org role list, pulumi org usage get, and pulumi org audit-log export can help you dig into the details when you need to as well.

Deployment-related commands like pulumi deployment list, get, log, and cancel let you see what’s running, dive into what happened, and take action without having to leave the terminal.

$ pulumi deployment list \
 --stack cnunciato/chris.nunciato.org/production \
 --output table

┌──────────────────────────────────────┬───────────┬─────────┬───────────┬──────────────┬─────────────────────────┐
│ ID │ OPERATION │ VERSION │ STATUS │ INITIATED BY │ MODIFIED │
├──────────────────────────────────────┼───────────┼─────────┼───────────┼──────────────┼─────────────────────────┤
│ 83e44b8c-643c-4e9f-9f36-0c6a81d9db2e │ update │ 140 │ running │ cnunciato │ 2026-05-17 21:26:37.340 │
│ 52a37cbe-b7fd-4027-8e0f-7b4785ab12e8 │ update │ 139 │ succeeded │ cnunciato │ 2026-05-16 23:36:07.999 │
│ 94e04525-b3a4-42b5-9987-e344018a3324 │ preview │ 138 │ succeeded │ cnunciato │ 2026-05-16 23:29:19.709 │
└──────────────────────────────────────┴───────────┴─────────┴───────────┴──────────────┴─────────────────────────┘

And when you need to query across managed (and even unmanaged) resources, pulumi insights resource search and get can help you find what you’re looking for quickly:

$ pulumi insights resource search \
 --query 'type:aws:s3/bucket:Bucket org:cnunciato project:photomap stack:dev' \
 --output table

┌──────────────────────────────────────────────────────────────────────────┬──────────────────────┬───────┬──────────────────────────┐
│ URN │ TYPE │ STACK │ MODIFIED │
├──────────────────────────────────────────────────────────────────────────┼──────────────────────┼───────┼──────────────────────────┤
│ urn:pulumi:dev::photomap::aws:apigateway:x:API$aws:s3/bucket:Bucket::api │ aws:s3/bucket:Bucket │ dev │ 2020-10-31T00:39:47.926Z │
│ urn:pulumi:dev::photomap::aws:s3/bucket:Bucket::images │ aws:s3/bucket:Bucket │ dev │ 2020-10-31T00:39:47.926Z │
└──────────────────────────────────────────────────────────────────────────┴──────────────────────┴───────┴──────────────────────────┘

Showing 2 of 2 resources.

Flags and output formats are consistent across commands (--output table, json), as are the shapes of cross-cutting features like webhooks. If you’ve used pulumi stack webhook, for example, you already know how to use pulumi env webhook and pulumi org webhook, and so on.

Direct access to the Pulumi Cloud API

For any features of Pulumi Cloud that don’t yet have their own commands, you’ve also got pulumi api. It’s a gh api-inspired command designed to give you direct access to the full REST API, without having to manage separate access tokens, auth settings, or request/response payloads. Everything is handled for you through your authenticated pulumi CLI.

There’s even pulumi api list, which enumerates every single endpoint that’s exposed:

$ pulumi api list

┌───────────────┬────────┬───────────────────────────────────────┬──────────────────────────────┐
│ TAG │ METHOD │ PATH │ SUMMARY │
├───────────────┼────────┼───────────────────────────────────────┼──────────────────────────────┤
│ AccessTokens │ GET │ /api/orgs/{orgName}/tokens │ ListOrgTokens │
│ AccessTokens │ POST │ /api/orgs/{orgName}/tokens │ CreateOrgToken │
│ AccessTokens │ DELETE │ /api/orgs/{orgName}/tokens/{tokenId} │ DeleteOrgToken │
│ AccessTokens │ GET │ /api/user/tokens │ ListPersonalTokens │
│ AccessTokens │ POST │ /api/user/tokens │ CreatePersonalToken │
│ AccessTokens │ DELETE │ /api/user/tokens/{tokenId} │ DeletePersonalToken │
...

537 operations. Pass --output=json for a stable, scriptable contract.

To get the details about a particular API, use pulumi api describe:

$ pulumi api describe 'DELETE /api/user/tokens/{tokenId}' # or DeletePersonalToken

DELETE /api/user/tokens/{tokenId}
Tag: AccessTokens
Operation: DeletePersonalToken

DeletePersonalToken

Permanently deletes a personal access token by its identifier. The token is immediately
invalidated and can no longer be used for authentication. Returns 204 on success or 404
if the token does not exist.

Parameters:
 [path] tokenId* (string) — The access token identifier

All requests are made through your authenticated pulumi CLI:

$ pulumi login
Logged in to pulumi.com as cnunciato.

$ pulumi whoami
cnunciato

$ pulumi api /api/user/tokens/2cf15c7d-afad-458f-ace0-fc7ff0512b10 \
 --method DELETE && echo "Token deleted."
Token deleted.

Newly published endpoints are available through pulumi api immediately, so you don’t have to wait for a new CLI release before you can start using them. See the Pulumi Cloud REST API documentation to learn more.

Finding templates in the Pulumi Cloud Registry

Finding out which templates are available to you through your Pulumi organization used to mean having to navigate to the Pulumi Cloud Registry and start searching. The new pulumi template commands make this easier by letting you ask for what’s available right from the shell, either by fetching the full list or filtering with the --name or --search params:

$ pulumi template list --search "container typescript" --org cnunciato

┌─────────────────────────────────────────────┬────────┬────────────┬────────────┐
│ Name │ Source │ Language │ Visibility │
├─────────────────────────────────────────────┼────────┼────────────┼────────────┤
│ pulumi/templates/container-aws-typescript │ github │ typescript │ public │
│ pulumi/templates/container-azure-typescript │ github │ typescript │ public │
│ pulumi/templates/container-gcp-typescript │ github │ typescript │ public │
└─────────────────────────────────────────────┴────────┴────────────┴────────────┘

This is especially useful when you’re working with an agent because it helps the agent discover your org’s approved templates without having to name them. Start with a prompt that tells the agent what you want to build, and let the agent find the right template for you.

Agent-friendly Markdown docs for providers and components

Both humans and agents need to be able to understand what’s inside a Pulumi package before they can use it. And while the Registry is an excellent resource for that, it was mainly designed to deliver HTML — a human-friendly format that agents can certainly use, but that’s much more verbose than they actually need.

With pulumi api, agents can fetch the details about a package from the Registry directly and get back those details either in markdown or json, whichever works best, filtering on properties like language where applicable:

$ pulumi api "/api/registry/packages/pulumi/pulumi/random/versions/4.19.1"

{
 "name": "random",
 "publisher": "pulumi",
 "publisherDisplayName": "Pulumi",
 "source": "pulumi",
 "version": "4.19.1",
 "description": "A Pulumi package to safely use randomness in Pulumi programs.",
 "repoUrl": "https://github.com/pulumi/pulumi-random",
 ...
}

$ pulumi api "/api/registry/packages/pulumi/pulumi/random/versions/4.19.1/docs/random%3Aindex%2FrandomPassword%3ARandomPassword" \
 --output markdown

# RandomPassword

resource `random:index/randomPassword:RandomPassword`

## Example Usage

package main
...

Resources are individually addressable using their URL-encoded Pulumi type tokens — e.g., random:index/randomPassword:RandomPassword — and API endpoints are configured to deliver Markdown when agents ask for it:

$ curl "https://api.pulumi.com/api/registry/packages/pulumi/pulumi/random/versions/latest/readme?lang=python" \
 -H "Accept: text/markdown"

# Installation

The Random provider is available as a package in all Pulumi languages:
...

Even compared to JSON (which is itself a significant improvement over HTML), Markdown is a much more token-efficient format for agents to work with:

Package	Endpoint	JSON	Markdown	Tokens saved
random	`/readme`	10.68 KB	6.04 KB	43%
aws	`/readme`	4.22 KB	2.54 KB	40%
aws	`/nav?depth=full`	204 KB	170 KB	17%
aws	`/docs/{resource type token}`	15.24 KB	11.28 KB	26%
azure-native	`/docs/{resource type token}`	48.13 KB	30.37 KB	37%
aws	`/docs/{function type token}`	2.40 KB	1.46 KB	39%

Learn more about our Registry endpoints in the REST API docs. (Or just ask your agent!)

New to the CLI: Pulumi Neo

When we launched Pulumi Neo last year, the only way to use it was in the Pulumi Cloud Console. But while there’s a ton you can do with Neo in the browser, if you’re an engineer already living in the terminal, chances are that eventually you’re going to wish you had Neo right in the CLI along with you.

Now you do. Running pulumi neo with or without a prompt launches a Pulumi Cloud-connected session that gives Neo access to your local environment just like any other coding agent. Use it on its own to scaffold a new project, understand an existing codebase, or debug a failing deployment — or pull it into an active session with the coding agent you’re already using. Either way, it stays in the shell you’re already working in.

We’ll cover Neo in the CLI in more detail later this week. In the meantime, here’s a peek:

Smaller changes that add up

A long list of smaller changes also runs through this release:

The core loop now speaks JSON end to end, with pulumi up, pulumi destroy, and pulumi import all emitting structured JSON output when called with --output json.
Streams now behave the way scripts expect them to, with data on stdout, progress and diagnostics on stderr.
Exit codes are more consistent across the board. Every failure mode — auth, resource, policy, missing stack, cancellation, timeout, and others — has its own exit code, so agents can branch on the actual cause instead of having to interpret output. The full table is in the docs.
Help text explains why a command exists, not just what it does, and includes at least one concrete example. Examples in --help are one of the most effective ways to improve LLM accuracy on first-try invocations — and it turns out they’re pretty handy for humans, too.

A sneak peek at a new command

Later this week, you’ll get a closer look at pulumi do, a new top-level command that enables direct resource operations like create, read, update, delete, and list across every Pulumi-supported cloud provider and resource, all in one command. A simple example:

$ pulumi do aws getAvailabilityZones

{
 "groupNames": [
 "us-west-2-zg-1"
 ],
 "id": "us-west-2",
 "names": [
 "us-west-2a",
 "us-west-2b",
 "us-west-2c",
 "us-west-2d"
 ],
 "region": "us-west-2",
 "zoneIds": [
 "usw2-az2",
 "usw2-az1",
 "usw2-az3",
 "usw2-az4"
 ]
}

It might look like that’s calling the AWS CLI, but it’s not — it’s using the same AWS provider function a full Pulumi program would use, only without the program, and invoked directly from the CLI.

More on how it works, and what you can do with it, in the days ahead.

Try it yourself

A lot of what makes a developer tool worth using is in the details, and most of what’s in this release is exactly that, across the whole CLI, with humans and agents in mind.

We’d love for you to grab the latest release and give it a try. Tell us what’s now easy, what’s still hard, and what to fix next on GitHub or in the community Slack. The fastest way the CLI gets better is feedback from the humans and agents who live in it.

The Agentic Infrastructure Era

Joe Duffy — Tue, 19 May 2026 03:00:00 -0700

The first frontier agents excelled at was coding. The reason is evident: we have billions of lines of self-documenting code available on the internet for the LLMs to learn from. We can measure their performance on coding thanks to linters, type checkers, compilers, and test suites. The most advanced agentic systems to hit product/market fit have been coding-oriented, and it has resulted in an intense velocity increase in how much and how fast code we can write.

But as the AI tsunami whips up reams of code, what happens to it becomes just as critical. As an industry, we’ve moved beyond just coding to engineering, which includes documentation, tests, automation, and, yes, managing the very infrastructure our applications need to run. The deeper into production you go, however, the less good agents naturally are at helping. At Pulumi, we live and breathe infrastructure, and have seen this firsthand. But we’ve also been hard at work building the platform this new era runs on. In this post, I’ll share our point of view, what we’ve built, what we’re launching today, and why all infrastructure is about to be agentic.

LLMs are natural coders

It is remarkable to look back and note that frontier models, less than two years ago, in August 2024, scored just 33% on SWE-bench Verified. Present-day models score 86%, which represents a 4x reduction in the errors models will make when coding. This enables models to solve increasingly difficult coding problems, and humans can lean more heavily on them to offload tasks. Anthropic’s new Mythos model scores 94% and, although it isn’t generally available at the time of this article, there’s no question we’ll close in on 95% by the end of 2026. That is another 2.3x reduction in error rates. This very naturally puts us onto the last mile of fully agentic coding.

This has been the result of code being highly in-distribution combined with the relentless pursuit of solving coding problems from the frontier labs, especially with Anthropic’s Claude Code, but now with OpenAI’s Codex, driving a tight feedback loop that turns into an improvement flywheel.

Given that LLMs are natural coders, most of us simply assumed that the breakout success we’ve seen with agents for coding would automatically translate into new problem domains. And for sure, we have seen some success. But perhaps not as much as we’d like. Not all problem domains are documented equally well so that the models can naturally learn about them.

Andrej Karpathy noted nearly a year ago that, “Building a modern app is a bit like assembling IKEA furniture,” observing that, though writing the code was easy, fun, and fast, the next mile of actually getting the application running in production entailed many things the LLM wasn’t naturally good at, including “services, API keys, configurations, dev/prod deployments.”

At the same time, we’re seeing something magical happen here at Pulumi: LLMs are now doing over 20% of the infrastructure deployments, up from virtually zero a year ago. We expect this to grow to over 50% before the end of this year and well beyond afterwards.

The agentic infrastructure era is here. Today we’re announcing several new platform capabilities to accelerate it further.

Before getting to what’s new, however, why are we seeing this happening in reality?

Turning infrastructure problems into coding problems

We began our journey with our open-source infrastructure-as-code project nearly ten years ago. Having spent much of my career working on programming languages and compilers, I had a strong conviction that the right substrate for infrastructure was the languages developers already knew and loved, not yet another DSL and certainly not piles of YAML. So we focused first on great ergonomics for humans, and for us, that meant letting you use programming languages, tools, and ecosystems that humans already know and love. Languages like Python, TypeScript, Go, C#, Java, and more. Infrastructure as code also, importantly, comes with guardrails to make infrastructure deployments dependable, reviewable, and auditable. Over time we’ve built out an entire platform with security, compliance, and governance capabilities.

One way of thinking about this is we modeled the realm of cloud infrastructure inside the realm of programming languages: cloud resources become objects, configurations are just variables, dependencies between resources are just references, standard blueprints become classes. Doing so turns the cloud into something that is suddenly programmable, and allows us to apply real software engineering patterns and practices to infrastructure.

Here’s the twist we’ve realized this past year. It is a happy accident that the combination of this plus the verifiability of every change is the exact combination that empowers agents to do infrastructure. LLMs are natural coders. By mapping infrastructure space in code space, agents can do what they’re great at – code – and the infrastructure as code engine is the link that maps those code edits back down into infrastructure space. And as the SWE-bench curve plays out, every domain expressed in code rides it. Infrastructure, thanks to the bet we made nine years ago, is now one of them.

This isn’t just about volume of in-distribution code. Most production infrastructure code lives in private repositories. In contrast, public Python and TypeScript include vast amounts of genuinely production-grade open source, demonstrating real patterns at scale. Public infrastructure DSL corpora skew heavily toward tutorial-grade content that doesn’t scale. By modeling infrastructure in real languages, Pulumi inherits at-scale in-distribution directly. Patterns in Python or TypeScript generalize from what the model has practiced, while DSL patterns are idiosyncratic by definition and don’t compound the same way. Code can express everything an engineer can do, which is exactly why models trained on it have become prolific engineers.

What does this look like in practice? For example, an agent can define reusable infrastructure:

import pulumi
import pulumi_coreweave as coreweave
import pulumi_nvidia_aicr as aicr

class TrainingCluster(pulumi.ComponentResource):
 """A reusable training cluster resource."""
 kubeconfig: pulumi.Output[str]
 def __init__(self, name: str, *, nodes: int, accelerator: str):
 super().__init__("training:Cluster", name)
 self.cluster = coreweave.KubernetesCluster(f"{name}-k8s",
 accelerator=accelerator, # gb200/b200/h100
 count=nodes)
 self.stack = aicr.ClusterStack(f"{name}-aicr",
 kubeconfig=self.cluster.kubeconfig,
 accelerator=accelerator,
 intent="training",
 platform="kubeflow")

And then flexibly consume it – all using languages, like Python, it is already fluent in:

import pulumi
from infra import TrainingCluster
from orchestration import RLFleet

# Spin up an RL stack with 1 learner and 8 rollout workers.
learner = TrainingCluster("learner",
 nodes=4, accelerator="gb200")
rollouts = [
 TrainingCluster(f"rollout-{i}",
 nodes=2, accelerator="b200")
 for i in range(8)
]

fleet = RLFleet("ppo",
 learner=learner, workers=rollouts)

pulumi.export("login", fleet.head_node)

Beyond just being in-distribution, infrastructure as code also gives us a critical piece: the ability to diff changes at the infrastructure layer. Just as we wouldn’t vibe code without git showing us the source changes, we shouldn’t vibe infrastructure without a tool that shows what it will do before it does it, and what it has already done in the past. It’s like git diff for your infrastructure.

The combination of languages, type systems, linting, testing, and infrastructure diffs gives agents enough of what they need to create a fully closed, verifiable, self-correcting loop. Verifiability is the thing that ultimately matters. Every action an agent takes can be previewed, policy-checked, reviewed, and audited. By humans, by other agents, by CI/CD automation. Guardrails guide the agent and verifiability proves the end result.

When I say “infrastructure” by the way, I mean something quite broad. It includes public cloud hyperscalers, of course, like AWS, Azure, Google Cloud, and CoreWeave. It includes cloud native technologies like Kubernetes and Helm. It also includes private clouds powered by VMware and other data center technologies. It includes broad cloud platforms like Cloudflare. But, subtly, also any hosted managed infrastructure service, such as Snowflake, MongoDB, Databricks, and more. And increasingly, the observability, security, and operational tooling that wraps everything else, like Datadog, Sentry, PagerDuty, and other systems that give agents the context to reason about what’s actually happening in production. We support thousands of providers with a consistent programming model and agents are increasingly writing those too.

What we’re shipping today

The foundation of expressing infrastructure as code, combined with verifiable changes, makes a 100% agentic infrastructure future even conceivable. But we still have work to realize this vision.

Meeting agents where they work (the CLI)

We know real code is the right substrate for agentic infrastructure – but we also know agents want to start with the smallest possible commitment and progressively level up. So we’ve designed the Pulumi experience as a progression: an agent should be able to sign up, run its first command, and grow into a full infrastructure as code workflow without ever hitting a wall or manual intervention. Here’s what we’re launching today to make that journey work end-to-end:

Agent accounts. Now agents can use free, ephemeral Pulumi Cloud accounts straight from Claude Code, Codex, OpenCode, Copilot, Cursor, and others. This lets an agent do anything a human could with the Pulumi product without a manual signup step, removing friction while letting agents benefit from robust infrastructure management. A human can claim that account at any time to make it permanent and to share with their team.

One-command execution. Today an agent needs to know how to find, download, and install Pulumi, and manage subsequent versioning and upgrades. Anything that adds friction is discouraging to an agent. We now have an npm package that enables npx pulumi <anything>-style commands so agents can run any Pulumi command anywhere without needing to worry about installation or version pinning.

Imperative infrastructure operations. The new pulumi do command enables direct create, read, update, delete, list, and API operations with a single command. For example, pulumi do create eks:Cluster spins up an AWS EKS cluster with built-in best practices, and pulumi do update cloudflare:r2:Bucket --tags '{ "Foo": "Bar" }' updates a bucket’s tags. All thousands of providers and hundreds of thousands of resource types in the Pulumi ecosystem are supported across clouds. As the complexity of your scenario outgrows singular commands, it is easy to eject out into a full-blown infrastructure-as-code project.

Pulumi Cloud in the CLI. Over the years, we’ve added tons of great capabilities to Pulumi Cloud – things like change history, time-to-live stacks, drift detection, resource discovery and search, private registries, IDP, audit logs, secrets management, team-wide policy enforcement – but didn’t add the respective ergonomic commands to the CLI. These are the sort of features that matter at scale. Now it’s all there in your terminal where agents can use them. Over 30 new commands, you can think of this as the equivalent of the gh CLI which agents really like.

Read the blog: Better CLI Interactions for Agents and Humans →

Neo, everywhere you work

Once an agent (or a team) has graduated through these capabilities, what comes next is asynchronous infrastructure work and, increasingly, autonomy. That’s where Neo comes in: Pulumi’s own infrastructure agent, now upgraded with the surfaces, integrations, and cadences teams actually need to run agentic infrastructure in production. We are shipping:

Neo in the CLI. The new pulumi neo command lets you run the same agent that is already in Pulumi Cloud. It even shares the same agentic loop and uses a sophisticated architecture where the agent workstation is your local computer, allowing it to more seamlessly access source context and tools. This allows you to do agentic infrastructure wherever you prefer: Neo in the cloud for asynchronous, autonomous tasks, or your workstation for more intensive deep-dive paired sessions.

Neo GitHub and Slack Apps. Now you can @-mention Neo from GitHub pull requests, and/or straight from Slack, to kick off agentic infrastructure workflows wherever it is most convenient, complete with whatever guardrails you’ve configured already.

Neo Integration Catalog. A new integration catalog lets you configure connectors to other systems that bring valuable infrastructure management context, including Atlassian, Datadog, Honeycomb, Linear, PagerDuty, and Supabase. This lets you tap into additional planning, specification, observability, and live site incident data, expanding what agents can do on Days 0, 1, and especially 2.

Scheduled Tasks and Read-Only Sessions. Now you can automate recurring infrastructure tasks, including confining Neo to read-only operations for extra safety. This opens up scenarios like reporting on infrastructure patterns weekly, automatically cleaning up waste in your dev accounts daily, or scheduled maintenance and upgrades.

Read the blog: 10 More Things You Can Do with Pulumi Neo →

Partnering with the frontier of AI infrastructure

We’re investing in deep partnerships with the companies building the frontier of AI infrastructure, and are shipping two new partner providers in close collaboration with the teams behind them:

CoreWeave provider. This new provider brings the full power of the CoreWeave platform, the leader in GPU infrastructure, to help teams provision AI workloads with ease. This includes support for all of the CoreWeave services including CoreWeave Kubernetes Service (CKS) and includes several examples and templates out of the box for training and inference architectures written in AI-native languages.

NVIDIA AI Cluster Runtime (AICR) provider. This new provider delivers fully functional NVIDIA software stacks atop the underlying cloud provider’s GPU infrastructure. This packages out-of-the-box components like NVIDIA GPU Operator, Kubeflow, NIM Operator, and dozens more otherwise tricky-to-configure cluster components. We’re excited to showcase the new AICR provider in tandem with our new CoreWeave provider: you can now spin up a CKS cluster and configure it with AICR in one program.

Educating and measuring agentic infrastructure intelligence

We’ve also invested in making Pulumi maximally legible to agents, because the best tools only matter if agents can find them, read them, and know which one to reach for and when:

Agent-friendly docs. We now serve our docs website in markdown to agents and did a pass over our documentation and CLI text to ensure it’s maximally useful to agents.

Agent-friendly CLI ergonomics. We have added --json and structured errors across the CLI to help agents parse and react to outputs appropriately.

New skills. We’ve done a pass over our skills and added a new uber-skill that describes how an agent should leverage the full suite of capabilities we now offer, from Level 0 (agent accounts), to Level 1 (pulumi do), to Level 2 (full IaC and pulumi up), to Level 3 (Pulumi Cloud governance and full autonomy with Neo), and beyond. It’s handy for humans too.

InfraBench. We have created a new benchmark to measure how well an agent performs on a wide array of representative infrastructure tasks. This is the infrastructure equivalent to SWE-bench and lets us measure stock agents, agents plus the new tools and skills, and Neo, and how they’re improving over time. Although we are still hard at work on building out the comprehensive suite, and will keep it internally for now, we will begin publishing our progress against InfraBench as we continue tackling new problems and improving agent performance.

What comes next

We’re primarily focused on two pillars as we go forward:

First, we are making agentic infrastructure a reality with increasingly autonomous workflows. The pace and scale of infrastructure in an AI era are beyond anything we’ve seen before, and we need to ensure infrastructure doesn’t become the bottleneck to velocity. We will be shipping steady improvements that help agents score better on InfraBench as a measure of their abilities. This will begin with new building blocks and in-context improvements, but we’re really excited that every improvement the frontier labs ship in general-purpose coding ability is automatically an improvement in agentic infrastructure on Pulumi, at zero cost to us or to our users. The result is that Pulumi-equipped agents will consistently and measurably outperform raw agents on real infrastructure work, and that gap will compound as the substrate and the models both improve.

Next, a world in which agents are provisioning, updating, monitoring, and managing all of our infrastructure changes the human/agent/infrastructure interface greatly. We need better change management, policy enforcement, and observability tools. Going from a single human doing a single infrastructure task at a time, to a single agent doing that task, to teams of agents doing lots of autonomous infrastructure tasks at once, will reveal new bottlenecks needed to fully govern your infrastructure. We have a lot of those facilities in Pulumi Cloud already but we will continue pushing here to improve them and ensure they scale up as fast as they need to. This is the layer that matters even as agents themselves get great at infrastructure. The smartest agent in the world still needs guardrails, audit trails, and policy enforcement to be trusted with production systems at scale, and that layer gets more valuable as agents get more capable, not less.

The combination of these two things will lead to a world where agents are able to manage more infrastructure, and to do so with increasing autonomy, while human operators retain full visibility, understanding, and control over what their teams of agents are doing at all times. This is the full engineering loop applied to infrastructure. Not just code generation, but design, review, deployment, and operation, with agents and humans collaborating across every step.

It’s a new era, and we’re just getting started

It was remarkable to see in practice and at scale that what’s good for humans is good for agents: ergonomic infrastructure as code. We’ve seen every point along the spectrum, ranging from Wiz managing 1 million resources and doing 100k daily deployments, to Compostable.ai already living the 100% agentic infrastructure dream, to a frontier lab who grew their infrastructure footprint by 982% in a year, all using infrastructure modeled in true code. All very different scales and teams, but with one thing in common: it was code all the way down.

Languages and verifiability already provide strong foundations, however, there are still clear areas we need to improve, beginning with making the full suite of infrastructure automation, security, and governance tools more accessible to agents. That’s what today is all about. To deep dive on details of the launches, check out the companion blog posts released today.

Agentic infrastructure is a super exciting one-way door for our industry. We’re pushing hard to take this beyond 20% and toward 100% in the years ahead. This is uniquely enabled by infrastructure as code in languages the models already speak combined with built-in verifiability that makes agentic work automatically safe. There’s more to be done, however, today’s launch will bend the curve even further upwards. We’re still only just getting started.

Happy clouding,

-Joe

Connect Any Git or Mercurial Repo to Pulumi with Custom VCS

Michael Fallihee — Mon, 04 May 2026 00:00:00 +0000

Custom VCS is a new Pulumi Cloud integration that connects any Git or Mercurial version control system to Pulumi Deployments using webhooks and centrally managed credentials. Pulumi Cloud already has native integrations with GitHub, GitLab, and Azure DevOps, but if your team uses a self-hosted or third-party VCS, you’ve been limited to manually configuring credentials per stack with no webhook-driven automation. Custom VCS closes that gap.

The problem

Many teams run self-hosted or third-party Git servers that Pulumi Cloud doesn’t have a native integration for, and some teams still use Mercurial. Until now, their only option was the raw git source approach: embedding credentials directly in each stack’s deployment settings, with no way to trigger deployments automatically on push, and no support for Mercurial at all.

This meant:

No push-to-deploy: Every deployment had to be triggered manually or through a separate CI pipeline.
Scattered credentials: Each stack configured its own credentials independently, with no centralized management.
No org-level integration: There was no shared configuration that multiple stacks could reference.

How Custom VCS works

Custom VCS integrations introduce an org-level integration type that works with any Git or Mercurial server. The setup has three parts:

Credentials through ESC: Instead of OAuth flows, you store your VCS credentials (a personal access token, SSH key, or username/password) in a Pulumi ESC environment. The same credential structure works for both Git and Mercurial. The integration references this environment by name and resolves credentials at deployment time. Multiple stacks can share the same credentials without duplicating secrets.

Manual repository registration: You add repositories to the integration by name. Pulumi joins the repository name with the integration’s base URL to form clone URLs. There’s no auto-discovery, so you control exactly which repositories are available.

Webhook-driven deployments: Pulumi provides a webhook endpoint and an HMAC shared secret. You configure your VCS server to POST a JSON payload on push events, and Pulumi automatically triggers deployments for matching stacks. The webhook supports branch filtering and optional path filtering.

What’s supported

Custom VCS focuses on the deployment automation use case. Here’s how it compares to native integrations:

Capability	Native integrations	Custom VCS
Push-to-deploy	Yes	Yes
Path filtering	Yes	Yes
PR/MR previews	Yes	No
Commit status checks	Yes	No
PR comments	Yes	No
Review stacks	Yes	No

Features like PR comments, commit statuses, and review stacks require deep API integration with each VCS platform, so they aren’t available with Custom VCS. If your VCS provider is GitHub, GitLab, or Azure DevOps, we recommend using the native integration for the full feature set.

Neo support

Neo, Pulumi’s AI assistant, works with Custom VCS integrations for repository operations that don’t depend on VCS-specific APIs. Neo can clone and push to Git and Mercurial repositories registered with your Custom VCS integration using the credentials from the integration’s ESC environment. Neo cannot open pull requests or create new repositories on Custom VCS servers at this time. Those operations require APIs unique to each VCS platform and are only available through native integrations.

Get started

To set up a Custom VCS integration:

Navigate to Management > Version control in Pulumi Cloud.
Select Add integration and choose Custom VCS.
Provide a name, base URL, and ESC environment containing your credentials.
Add your repositories.
Configure your VCS server to send webhooks to the provided URL.

For the full setup guide including webhook payload format, HMAC signing, and credential configuration, see the Custom VCS documentation.

Learn more

Policy Packs Can Now Access Pulumi ESC Environments

Dan Biwer — Thu, 23 Apr 2026 00:00:00 +0000

Policy authors who need external credentials or environment-specific configuration have had to hardcode values or manage them outside of Pulumi. Policy packs can now reference Pulumi ESC environments, bringing centralized secrets and configuration management to your policies.

The problem

Pulumi policy packs let you enforce rules across your infrastructure, but some policies need more than just the resource inputs they evaluate. A policy that validates resources against an external compliance API needs an API token. A cost-enforcement policy might need different spending thresholds for development and production environments. An access-control policy might need to reference an internal service registry.

Until now, these values had to be hardcoded in your policy group configuration or managed through a separate process entirely. This created several problems:

Security risk: Credentials stored in plain text in policy group config
Operational burden: Updating a credential meant touching every policy group that used it
No environment separation: The same values applied everywhere, with no way to vary configuration across environments

What’s new

Policy packs can now reference ESC environments, just like stacks already do. When you attach an ESC environment to a policy pack in a policy group, the values from that environment are available to your policies at runtime — whether you’re running preventative or audit policies.

This means your policy packs can use ESC for:

Secrets: API tokens, service credentials, and other sensitive values managed through ESC’s secrets management, including dynamic credentials from providers like AWS, Azure, and GCP
Configuration: Environment-specific thresholds, allowed regions, service allowlists, and other policy parameters that vary across environments

How it works

You configure ESC environment references on a policy pack within a policy group. At runtime, the values from those environments are resolved and made available to your policies through the policy pack’s configuration.

Here’s an example ESC environment that provides configuration to a compliance policy pack:

values:
 compliance:
 apiToken:
 fn::secret: xxxxxxxxxxxxxxxx
 costThreshold: 5000

 policyConfig:
 cost-compliance:
 maxMonthlyCost: ${compliance.costThreshold}
 apiEndpoint: https://compliance.example.com
 apiToken: ${compliance.apiToken}

The policyConfig property works just like pulumiConfig does for stacks. Values nested under each policy name are made available as configuration to that policy at runtime. Secrets remain encrypted and are only decrypted when the environment is resolved.

You can also use the environmentVariables property to inject values as environment variables into the policy runtime, following the same pattern as stack environment variables.

Example: compliance API validation

Consider a policy that validates every new resource against an external compliance API before it can be provisioned. The API requires an authentication token and returns whether the resource configuration meets your organization’s compliance standards.

Before, the API token lived in the policy group configuration in plain text. Rotating the token meant updating every policy group. There was no audit trail for who accessed the credential, and no way to use different API endpoints for staging and production compliance checks.

After, the API token lives in an ESC environment. You get:

Centralized rotation: Update the token in one place and every policy group that references the environment picks up the change
Access controls: ESC’s role-based access controls govern who can view or modify the credential
Audit trail: Every access to the environment is logged
Environment separation: Use different ESC environments for different policy groups, so staging policies validate against a staging compliance endpoint while production policies use the production endpoint

Get started

To start using ESC environments with your policy packs:

Create an ESC environment with your policy configuration and secrets
Attach the environment to a policy pack in your policy group through the Pulumi Cloud console
Update your policies to read from the configuration values provided by the environment

To learn more:

Pulumi Cloud REST API Docs, Now Generated from OpenAPI

Devon Grove — Mon, 20 Apr 2026 00:00:00 +0000

The Pulumi Cloud REST API reference is now generated directly from the live OpenAPI spec at build time. Every endpoint, parameter, request body, and response schema you see on the page comes from the same spec the API itself publishes. The docs now stay in sync with the API automatically!

Why this matters

The previous REST API reference was a set of handwritten pages. That meant every new endpoint, renamed parameter, or revised response shape needed a matching docs PR, and in practice the pages drifted. Small inconsistencies added up: missing parameters, outdated request shapes, schemas that no longer matched what the API returned. We wanted a durable fix that keeps the docs in sync as the API grows.

Generating the reference from the OpenAPI spec closes that gap. When the API ships a change, the docs pick it up automatically the next time our docs are built.

What’s new

The reference at /docs/reference/cloud-rest-api/ now includes:

Find what you need faster
- Endpoints are grouped by product area — Stacks, Deployments, Environments, Organizations, Registry, Insights, AI, Workflows, and more — so you can jump straight to the part of the API you’re working with.
Complete request and response details
- Every endpoint documents its parameters, request body, and the exact shape of what it returns, so you know what to send and what to expect back without guessing.
One-click navigation between related types
- When a response references another object, the type name is a link. Click through to drill into its full definition if desired instead of scrolling a lengthy API reference page.

What this unlocks for agents

Keeping the reference in sync with the spec isn’t just a human convenience. It changes what’s reliable for AI agents that read the docs and call the API on your behalf. An agent reading a handwritten reference might see a parameter that was renamed six months ago, or miss a field the API now returns, and the call fails silently or in ways that are hard to debug. When the reference is generated from the spec, the agent is working from what the API actually accepts today.

Say you’re onboarding a new team and need to stand up their access in Pulumi Cloud. Point an agent at the REST API reference and ask it to create an sre-oncall team, add four members, and grant admin on three stacks. The agent walks the teams, memberships, and stack-permissions endpoints, builds the right sequence of calls, and executes.

The same pattern holds for bulk audits and cleanup. Ask an agent to find every stack in your org with no recent updates and tag them stale, and it can paginate correctly because the response schema matches reality. While workflows like these were technically possible before, they’re much more reliable now.

Same URL, existing links keep working

The generated docs live at the same URL as the previous reference: /docs/reference/cloud-rest-api/. Bookmarks, blog links, and inbound search traffic still land on the right page. Redirects are in place for any API reference docs page that has been tweaked, renamed, or moved.

Try it out

Start at the new REST API reference and browse by category. Each page links through to the request and response object schemas it uses.

If you spot anything that looks wrong, the most likely culprit is the OpenAPI spec itself — file an issue in pulumi/docs and we’ll trace it back to the source. For tag intros and structural improvements, PRs to pulumi/docs are welcome. Questions and feedback are always welcome in the Pulumi Community Slack.

Explore the REST API

Bitbucket Cloud Meets Pulumi Cloud

Luke Ward — Mon, 20 Apr 2026 00:00:00 +0000

Pulumi Cloud now supports Bitbucket Cloud as a first-class VCS integration, joining GitHub, GitLab, and Azure DevOps. Connect your Bitbucket workspace to deploy infrastructure on every push, preview changes on pull requests, spin up ephemeral review stacks, and get AI-powered change summaries — all without an external CI/CD pipeline.

Deploy infrastructure from Bitbucket

Connect a Bitbucket repository to a stack and infrastructure deploys automatically when you push to your configured branch. Configure path filters so only relevant file changes trigger deployments, and manage environment variables and secrets directly in Pulumi Cloud. No external CI/CD pipeline required.

Every pull request gets an infrastructure preview showing exactly what will change before merging. Neo posts AI-generated summaries explaining what the changes mean in plain language, so reviewers can understand the impact without reading resource diffs.

Two ways to connect

The integration supports two authentication methods depending on your Bitbucket plan:

Personal OAuth works with every workspace, including free plans. Authorize through the standard OAuth flow and you’re connected.
Workspace tokens are available for Premium workspaces. Generate a token with the required scopes (repository:admin, repository:write, pullrequest:write, webhook) and paste it into Pulumi Cloud for a service-account-style connection that isn’t tied to an individual user.

Both methods register webhooks automatically — no manual configuration required.

Scaffold new projects from your repositories

The new project wizard discovers your Bitbucket workspace, repositories, and branches so you can scaffold and deploy a new stack without leaving Pulumi Cloud. Create a new repository directly from the wizard or select an existing one and configure VCS-backed deployments in a few clicks.

Getting started

An org admin configures the integration under Management > Version control.
Authorize with Bitbucket using personal OAuth or a workspace token.
Deploy infrastructure with first-class workflows.

For full setup details, see the Bitbucket integration docs.

Connect your Bitbucket workspace

Scan AWS GovCloud and more partitions with Pulumi Insights

Alejandro Cotroneo — Tue, 14 Apr 2026 09:00:00 +0000

Pulumi Insights account scanning now supports every AWS partition. If your workloads run in GovCloud, China, the European Sovereign Cloud, or one of the ISO intelligence-community clouds, you can get the same resource discovery, cross-account search, and AI-assisted insights that commercial accounts already have.

Supported partitions

AWS Standard (Commercial)
AWS GovCloud (US)
AWS ISO (US)
AWS ISOB (US)
AWS ISOF (US)
AWS ISOE (Europe)
AWS European Sovereign Cloud
AWS China

You can also exclude specific regions from discovery — useful when regions are disabled by SCPs or fall outside an audit’s scope.

Set it up

In the Pulumi Cloud console:

Go to Accounts → Create account.
Select AWS as the provider.
Under Add your configuration, pick the target partition.
Supply credentials via a Pulumi ESC environment. The OIDC trust policy uses the partition-appropriate ARN prefix (arn:aws-us-gov:, arn:aws-cn:, etc.).

For IAM and ESC setup, see the Insights accounts docs. Log in to Pulumi Cloud to get started.

Introducing Bun as a Runtime for Pulumi

Julien Poissonnier — Wed, 08 Apr 2026 00:00:00 +0000

Last year we added support for Bun as a package manager for Pulumi TypeScript projects. Today we’re taking the next step: Bun is now a fully supported runtime for Pulumi programs. Set runtime: bun in your Pulumi.yaml and Bun will execute your entire Pulumi program, with no Node.js required. Since Bun’s 1.0 release, this has been one of our most requested features.

Why Bun?

Bun is a JavaScript runtime designed as an all-in-one toolkit: runtime, package manager, bundler, and test runner. For Pulumi users, the most relevant advantages are:

Native TypeScript support: Bun runs TypeScript directly without requiring ts-node or a separate compile step.
Fast package management: Bun’s built-in package manager can install dependencies significantly faster than npm.
Node.js compatibility: Bun aims for 100% Node.js compatibility, so the npm packages you already use with Pulumi should work out of the box.

With runtime: bun, Pulumi uses Bun for both running your program and managing your packages, giving you a streamlined single-tool experience.

Getting started

To create a new Pulumi project with the Bun runtime, run:

pulumi new bun

This creates a TypeScript project configured to use Bun. The generated Pulumi.yaml looks like this:

name: my-bun-project
runtime: bun

From here, write your Pulumi program as usual. For example, to create a random password using the @pulumi/random package:

bun add @pulumi/random

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

const password = new random.RandomPassword("password", {
 length: 20,
});

export const pw = password.result;

Then deploy with:

pulumi up

Prerequisites:

Bun 1.3 or later
Pulumi 3.227.0 or later

Converting existing Node.js projects

If you have an existing Pulumi TypeScript project running on Node.js, you can convert it to use the Bun runtime in a few steps.

1. Update `Pulumi.yaml`

Change the runtime field from nodejs to bun:

Before:

runtime:
 name: nodejs
 options:
 packagemanager: npm

After:

runtime: bun

When the runtime is set to bun, Bun is also used as the package manager — there’s no need to configure a separate packagemanager option.

2. Update `tsconfig.json`

Bun handles TypeScript differently from Node.js with ts-node. Update your tsconfig.json to use Bun’s recommended compiler options:

{
 "compilerOptions": {
 "lib": ["ESNext"],
 "target": "ESNext",
 "module": "Preserve",
 "moduleDetection": "force",
 "moduleResolution": "bundler",
 "allowJs": true,
 "allowImportingTsExtensions": true,
 "verbatimModuleSyntax": true,
 "strict": true,
 "skipLibCheck": true,
 "noFallthroughCasesInSwitch": true,
 "noUncheckedIndexedAccess": true,
 "noImplicitOverride": true
 }
}

Key differences from a typical Node.js tsconfig.json:

module: "Preserve" and moduleResolution: "bundler": Let Bun handle module resolution instead of compiling to CommonJS. The bundler resolution strategy allows extensionless imports while still respecting package.json exports, matching how Bun resolves modules in practice.
verbatimModuleSyntax: true: Enforces consistent use of ESM import/export syntax. TypeScript will flag any remaining CommonJS patterns like require() at compile time.

3. Switch to ESM

Bun makes it easy to go full ESM and it’s the recommended module format for Bun projects. Add "type": "module" to your package.json:

{
 "type": "module"
}

With ECMAScript module (ESM) syntax, one thing that gets easier is working with async code. In a CommonJS Pulumi program, if you need to await a data source or other async call before declaring resources, the program must be wrapped in an async entrypoint function. With ESM and Bun, top-level await just works, so you can skip the wrapper function entirely and await directly at the module level:

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

const azs = await aws.getAvailabilityZones({ state: "available" });

const buckets = azs.names.map(az => new aws.s3.BucketV2(`my-bucket-${az}`));

export const bucketNames = buckets.map(b => b.id);

If your existing program does use an async entrypoint with export =, just replace it with the ESM-standard export default:

// CommonJS (Node.js default)
export = async () => {
 const bucket = new aws.s3.BucketV2("my-bucket");
 return { bucketName: bucket.id };
};

// ESM (used with Bun)
export default async () => {
 const bucket = new aws.s3.BucketV2("my-bucket");
 return { bucketName: bucket.id };
};

4. Update the Pulumi SDK

Make sure you’re running @pulumi/pulumi version 3.226.0 or later:

bun add @pulumi/pulumi@latest

5. Install dependencies and deploy

pulumi install
pulumi up

Bun as runtime vs. Bun as package manager

With this release, there are now two ways to use Bun with Pulumi:

Configuration	Bun’s role	Node.js required?
`runtime: bun`	Runs your program and manages packages	No
`runtime: { name: nodejs, options: { packagemanager: bun } }`	Manages packages only	Yes

Use runtime: bun for the full Bun experience. The package-manager-only mode is still available for projects that need Node.js-specific features like function serialization.

Known limitations

The following Pulumi features are not currently supported when using the Bun runtime:

Callback functions (magic lambdas) are not supported. APIs like aws.lambda.CallbackFunction and event handler shortcuts (e.g., bucket.onObjectCreated) use function serialization which requires Node.js v8 and inspector modules that are only partially supported in Bun.
Dynamic providers are not supported. Dynamic providers (pulumi.dynamic.Resource) similarly rely on function serialization.

If your project uses any of these features, continue using runtime: nodejs. You can still benefit from Bun’s fast package management by setting packagemanager: bun in your runtime options.

Start using Bun with Pulumi

Bun runtime support is available now in Pulumi 3.227.0. To get started:

Create a new project: pulumi new bun
Read the docs: TypeScript (Node.js) SDK
Report issues or share feedback on GitHub or in the Pulumi Community Slack

Thank you to everyone who upvoted, commented on, and contributed to the original feature request. Your feedback helped shape this feature, and we’d love to hear how it works for you.

Introducing the pulumi policy analyze Command for Existing Stacks

Fraser Waters — Fri, 03 Apr 2026 00:00:00 +0000

You can now run policy packs against your existing stack state without running your Pulumi program or making provider calls. The new pulumi policy analyze command evaluates your current infrastructure against local policy packs directly, turning policy validation into a fast, repeatable check.

Why this command matters

Policy authoring and policy updates usually involve an iteration loop:

Make a policy change.
Run a policy check.
Inspect violations or remediations.
Repeat until the policy behavior matches intent.

Before this command, that loop often depended on pulumi preview or pulumi up, which can be heavier than you need when your goal is validating policy logic against known state.

With pulumi policy analyze, you can evaluate your current stack state directly and quickly.

Basic usage

At minimum, provide a policy pack path and optionally a stack:

pulumi policy analyze \
 --policy-pack ./policy-pack \
 --stack dev

You can also pass a config file for each policy pack:

pulumi policy analyze \
 --policy-pack ./policy-pack \
 --policy-pack-config ./policy-config.dev.json \
 --stack dev

If any mandatory policy violations are found, the command exits non-zero.

If remediation policies fire, those changes are reported in output, but stack state is not modified.

Testing new policy packs as a developer

For policy pack development, this command is useful as a tight local feedback loop:

Pick a representative stack (dev, staging, or a fixture stack).
Run pulumi policy analyze against that stack after each policy change.
Use the output to verify mandatory, advisory, and remediation behavior.
Repeat before publishing the policy pack or attaching it to broader policy groups.

Two output modes are especially useful:

--diff for a concise, human-readable view while iterating locally.
--json for structured output that can be consumed in scripts and CI.

Using it in AI and agent workflows

This command is also a good primitive for AI-assisted policy workflows.

Because pulumi policy analyze can emit JSON and a clear process exit code, agents can use it for deterministic policy evaluation steps:

Propose or edit policy rules.
Run pulumi policy analyze --json against target stacks.
Parse violations and remediation signals.
Suggest policy fixes, config adjustments, or targeted infrastructure changes.
Re-run analysis until mandatory violations are resolved.

For example, an agent tasked with fixing a policy violation can run pulumi policy analyze --json to get a structured list of violations, identify which resources are non-compliant, generate targeted infrastructure changes, then re-run analysis to confirm the violations are resolved, all without triggering a full preview on each iteration. The same loop works for policy authoring: an agent can propose a new policy rule, test it against several representative stacks, and surface unintended violations before the rule is published.

This works well for automation because the command doesn’t execute your Pulumi program or make provider calls, so there are no side effects or runtime variance between runs. The JSON output and non-zero exit code on failure give agents a clear pass/fail contract to build on.

Try it out

pulumi policy analyze is available in Pulumi v3.229.0.

If you are authoring or tuning policy packs, start by running this command against a known stack in your environment. It is a quick way to validate policy behavior before rollout.

For implementation details, see the merged PR: pulumi/pulumi#22250.

Get started with policy as code

Neo Plan Mode: Iterate Before You Execute

Pulumi Neo Team — Wed, 01 Apr 2026 00:00:00 +0000

Infrastructure work ranges from simple updates to complex multi-stack operations. For straightforward tasks, jumping straight to execution is often fine. But complex tasks benefit from deliberate upfront thinking: understanding what exists, identifying dependencies, and agreeing on an approach before anything changes. Today we’re launching Plan Mode, a dedicated experience for collaborating with Neo on a detailed plan before execution begins.

Plan Mode

Without dedicated planning, Neo balances planning with progress toward execution. That works well for many tasks, but complex operations benefit from more thorough upfront discovery. Plan Mode now makes upfront deliberation a first-class workflow, where instead of focusing on getting to execution, Neo focuses entirely on discovery and synthesis until you explicitly approve the plan.

How it works

Enter Plan Mode by selecting the plan button when starting a task. Neo shifts its behavior:

Discovery: Neo investigates your environment — examining existing infrastructure, reading relevant code, checking dependencies, and researching patterns.
Synthesis: From that research, Neo produces a plan explaining what it will do and why. The plan references specific things Neo discovered, like a particular stack configuration or dependency.
Refinement: You refine the plan through normal conversation, challenging assumptions, asking for an alternative approach, or requesting more detail on a specific area.
Approval: Once you’re satisfied, you approve the plan and execution begins. Neo carries forward everything it learned during discovery, so the transition from planning to execution is seamless.

When to use it

Plan Mode is opt-in. You choose it when you want to work through an approach before committing:

Complex multi-stack operations where understanding dependencies matters
Unfamiliar infrastructure where discovery reduces churn
Autonomous execution where plan approval is your key control point before Neo runs without step-by-step oversight

Get started

Plan Mode is available now for all Pulumi Cloud organizations. It works with any task mode, so you can pair thorough upfront planning with whatever level of execution autonomy fits the situation.

To try it, open Neo in Pulumi Cloud. For more details, see the Plan Mode documentation.

Introducing Read-Only Mode for Pulumi Neo

Florian Stadler — Wed, 01 Apr 2026 00:00:00 +0000

A platform engineer with broad access might want Neo to analyze infrastructure and suggest changes, but include guarantees it won’t actually apply them. Read-only mode makes that possible: Neo does the heavy lifting and hands off a pull request for your existing deployment process to pick up.

Control what Neo can change

Neo runs with the permissions of the user who creates a task, but you often want a tighter boundary. Read-only mode solves this by letting you cap Neo’s permissions at task creation time. Neo can still read your infrastructure, run previews, and open pull requests, but it cannot deploy, update, or destroy resources.

How it works

When you create a Neo task, you now choose between two permission levels:

Option	What Neo can do	Availability
Use my permissions	Full access (current default behavior)	All tiers
Read-only	Read, preview, and create PRs. No infrastructure mutations.	All tiers

Read-only mode takes your existing permissions and removes the ability to make changes. Neo remains fully active, meaning it can still read your infrastructure state, run previews, write and refactor code, create branches, and open pull requests. If Neo encounters an operation it can’t perform in read-only mode, the operation fails and Neo reports what it would have done. The only difference is that Neo cannot trigger deployments or other write operations in Pulumi Cloud directly.

Read-only mode and auto-approve

Neo’s operating modes let you choose how much oversight you want: review mode for full approval at each step, balanced mode for approving only mutating operations, and auto mode for hands-off execution.

Read-only mode pairs well with auto-approve. Because Neo cannot perform write operations like deployments or destroys, you can let it run autonomously and trust that the output is a pull request, not a production change. Kick off a task, let Neo work in the background, and come back to a ready-to-review PR.

Getting started

Read-only mode is available today for all Pulumi Cloud users.

Sign in to Pulumi Cloud and select Read-only when creating your next Neo task
Read the Neo documentation for detailed guides on permission levels
Join the Community Slack to share your feedback

Introducing OTel Tracing in the Pulumi CLI

Thomas Gummerer — Wed, 01 Apr 2026 00:00:00 +0000

Tracing is an important part of our CLI observability story. So far we’ve relied on (the now deprecated) OpenTracing for this. We have now added OTel tracing to the CLI, which is more future-proof, and should in most cases give you a better view over what the CLI is doing.

Background

We introduced tracing using OpenTracing all the way back in 2017, before OpenTelemetry was a thing. This served us well over the years, but as OpenTracing was deprecated, and OTel emerged as the new and maintained thing, it got harder and harder to justify further investment in a tracing infrastructure that was deprecated. Last year we started focusing more on performance, and it became more and more clear that we’d either have to enhance our current OpenTracing setup, or do the work to switch to OTel.

In the end it was a relatively easy decision to move to the more modern and fully supported OTel, especially as more and more tooling around it starts emerging.

Enter OTel

With the decision to move to OTel made, the only thing left to decide was how to implement it. There were a couple of constraints we faced here. First, we wanted to make sure that traces are easily shareable. This means ideally a text file in whatever format, that can be shared easily. Second, pulumi’s plugin system works by spawning a new process per plugin. We want to get traces from each of these plugins to make sure we have as much coverage as possible. And third, ideally we also want to get traces from plugins that only implement OpenTracing, but not OTel yet, since someone can upgrade the CLI, but not the plugins for example.

Given these constraints, we decided to implement an OTel collector in the CLI, that could then forward the traces to whatever output format we want. This means that plugins only ever need to send traces back to the CLI over gRPC, and the CLI will do any further processing. This means only one process will write to the file, if requested.

For plugins we always request both OpenTracing and OTel traces. If both are requested and OTel is supported by the plugin, the plugin is expected to only send the OTel version of the traces. For OpenTracing traces, we collect them in the collector in the CLI, and then translate them internally to OTel traces. This way we can still get the traces from older plugins, without them needing to change anything.

Try it out

Currently the OTel exporter supports both exporting the traces directly via gRPC to a collector, or to a file, where the traces are JSON encoded. This file can then be shared and imported into a trace viewer at a later time. To do this, you can use the --otel-traces <file://<filename>|grpc://<exporter-address>> flag, using pulumi version v3.226 or newer. For further documentation see our performance tracing docs.

To view the traces, you can use one of the various exporters that exist. Popular options include Jaeger, OTel Desktop Viewer, or OTel TUI if you prefer not leaving your terminal. Once you’ve ingested the logs there either by uploading the trace file, or sending them directly by giving pulumi the exporter address, look for the pulumi-cli: pulumi root span.

All further spans will be parented to that root span, and you should thus be able to see a nice flow diagram in the viewer of your choice.

As always, we would love any feedback either in the Community Slack, or through a GitHub issue.

Pulumi IAM Expands: Manage Access at Scale with Tags, Roles, and Teams

Devon Grove — Thu, 19 Mar 2026 10:30:00 -0700

Since the launch of Pulumi IAM with custom roles and scoped access tokens, organizations have been using fine-grained permissions to secure their automation and CI/CD pipelines. As teams scale to hundreds or thousands of stacks, environments, and accounts, the next challenge is applying those permissions efficiently.

Today, we’re introducing three new capabilities to help you manage permissions more dynamically at scale: tag-based access control, team role assignments, and user role assignments.

Why tag-based access control?

With custom roles, you can define granular permissions using fine-grained scopes. However, applying those roles still requires selecting individual stacks, environments, or accounts one by one. For organizations managing a large number of Pulumi entities, this means either granting overly broad access or spending significant time on manual configuration. Tag-based access control solves this problem.

What’s new?

Tag-based access control

You can now create rules within a custom role that dynamically grant permissions based on entity tags. This works across IaC stacks, ESC environments, and Insights accounts. For example, when a new stack is created and tagged env:prod, anyone with a role containing a matching tag-based rule automatically gets the right permissions. No manual assignment required.

A single role can include multiple tag-based rules, and they are evaluated with OR logic. If an entity matches any of the rules, the permissions are granted. Within a single rule, you can combine multiple key-value conditions with implicit AND logic for precise targeting. For example, a rule with conditions env:prod and team:payments ensures access is granted only to production resources owned by the payments team.

Team role assignments

Custom roles can now be assigned directly to teams within your Pulumi organization. When an engineer joins a team, whether manually or via SCIM provisioning, they automatically inherit the permissions defined in the team’s assigned roles.

Teams support both inline permissions (ad-hoc access to specific stacks, environments, or accounts) and role-based permissions simultaneously. You can assign multiple roles to a single team, giving you full flexibility to compose access from reusable building blocks while retaining the ability to grant one-off access where needed. If you have existing workflows built around ad-hoc assignments to teams, those continue to work exactly as before. You can adopt roles incrementally or mix both approaches on the same team.

Team admins (or users with the team:update scope) can continue to manage their team’s inline permissions as they do today. However, assigning organization-level custom roles to a team requires additional permissions: role:read and role:update.

User role assignments

Custom roles can also be assigned directly to individual organization members. This is useful for users whose responsibilities span multiple teams or require permissions beyond the existing org-level Admin, Member, and Billing Manager roles.

How permissions work together

Permissions in Pulumi IAM are additive. A user receives the union of all permissions granted to them, including permissions from roles assigned directly to them as a user and permissions from roles assigned to any team they belong to. A user on both the “SRE” and “Security” teams inherits permissions from both team roles, plus any role assigned to them individually.

How to get started

Configuring tag-based access control and role assignments is done through the Pulumi Cloud console and REST API.

1. Create a custom role with tag-based rules

In Pulumi Cloud, navigate to Settings > Access Management > Roles and create a new custom role. In the role configuration, add tag-based rules that define which entities the role should apply to.

For example, to create a role that grants write access to all production stacks:

Click Create custom role and give it a descriptive name (e.g., “Production Deployer”)
Add a permission set (e.g., Stack Write) to the role
Under entity selection, choose Tag-based rule
Set the condition: tag key env equals prod
Save the role

2. Assign the role to a team

Go to Settings > Access Management > Teams, select a team, and assign your custom role. All team members immediately inherit the defined permissions.

3. Assign a role to an individual user

For users with unique access requirements, go to Settings > Access Management > Members, select a user, and assign a custom role directly.

Enforce tagging standards with Pulumi Policy

Tag-based access control relies on consistent tagging. If a stack is missing a tag or has an incorrect value, permissions won’t be applied as expected. Pulumi Policy closes this gap by letting you enforce tagging standards as a preventative policy group, so any pulumi up on a stack with missing or invalid tags is blocked before deployment. This ensures your tag-based RBAC rules always grant the correct permissions. Policy enforces the standard, RBAC enforces the access.

To learn how to write policies that validate stack tags, see Using stack tags in policies.

Pulumi Policy currently supports tag enforcement for IaC stacks. For ESC environments and Insights accounts, tags are managed through the Pulumi Cloud console or REST API.

Availability

Tag-based access control, team role assignments, and user role assignments are available today for customers on the Pulumi Enterprise and Pulumi Business Critical plans. Check out our pricing page for more details on editions and what’s included.

Conclusion

With custom roles providing fine-grained permissions, tag-based rules enabling dynamic access policies, and the ability to assign roles directly to teams and users, Pulumi IAM now provides everything you need to implement automated, least-privilege access control at scale. We’re excited to see how you leverage these new capabilities to secure and streamline your cloud operations.

Explore the IAM documentation to get started, and share your feedback in our GitHub repository.

Learn more

From Kubernetes Gatekeeper to Full-Stack Governance with OPA

Levi Blackstone — Thu, 19 Mar 2026 00:00:00 +0000

Pulumi’s OPA (Open Policy Agent) support is now stable. The v1.1.0 release of pulumi-policy-opa makes OPA/Rego a first-class policy language for Pulumi with full feature parity alongside the native TypeScript and Python policy SDKs. Write Rego policies that validate any resource Pulumi manages, across AWS, Azure, GCP, Kubernetes, and the rest of the provider ecosystem. If you already have Kubernetes Gatekeeper constraint templates, a new compatibility mode lets you drop those .rego files directly into a Pulumi policy pack and enforce them against your Kubernetes resources without modification.

What’s in the stable release

OPA/Rego is now fully supported as a policy language for Pulumi Insights, with the same capabilities as the TypeScript and Python SDKs:

Resource and stack-level policies: Validate individual resources with deny and warn rules, or evaluate your entire stack at once with stack_deny and stack_warn for cross-resource checks like relationship validation and resource count limits.
Enforcement levels: Control how violations are handled. mandatory blocks deployments, advisory surfaces warnings, and disabled turns rules off without removing them. Enforcement levels can be overridden per policy without modifying Rego source.
Policy configuration: Pass custom parameters to policies via configuration files, with optional JSON schema validation. Configuration values are accessible in Rego as data.config.<policy_name>.<key>.
OPA metadata annotations: Use standard OPA # METADATA comments to provide titles, descriptions, and messages for your policies. These populate the policy metadata displayed in Pulumi Cloud.
Preventative and audit evaluation: OPA policies work with both preventative enforcement during pulumi up and audit policy scans for continuous compliance monitoring.

You can choose whichever language best fits your team. Organizations already using OPA across their toolchain can standardize on Rego for Pulumi policies, while teams preferring TypeScript or Python can continue to use those. All three languages work side by side in the same policy groups.

Kubernetes Gatekeeper compatibility

The headline feature of this release is native support for Kubernetes Gatekeeper constraint template rules. If you’re running Gatekeeper as an admission controller in your clusters, you likely have a library of .rego policies that enforce security and operational standards at admission time. With v1.1.0, those same rules can now run as Pulumi policies, catching violations during pulumi preview before resources ever reach the cluster.

To enable Gatekeeper compatibility, set inputFormat: kubernetes-admission in your PulumiPolicy.yaml:

description: Kubernetes Gatekeeper Policy Pack
runtime: opa
inputFormat: kubernetes-admission

With this setting, Pulumi automatically wraps Kubernetes resources in the Gatekeeper AdmissionReview structure (input.review.object, input.review.kind, etc.), so your existing rules work without modification. Non-Kubernetes resources are silently skipped.

Here’s an example that reuses standard Gatekeeper-style rules, requiring an app label and prohibiting the latest image tag:

package gatekeeper

import rego.v1

# METADATA
# title: Require App Label
# description: All Kubernetes resources must have an "app" label.
violation contains {"msg": msg} if {
 not input.review.object.metadata.labels["app"]
 msg := sprintf("%s '%s' is missing required label: app",
 [input.review.kind.kind, input.review.name])
}

# METADATA
# title: Disallow Latest Tag
# description: Container images must not use the "latest" tag.
deny contains msg if {
 container := input.review.object.spec.template.spec.containers[_]
 endswith(container.image, ":latest")
 msg := sprintf("container '%s' uses the 'latest' tag -- pin to a specific version",
 [container.name])
}

These rules are identical to what you’d write for Gatekeeper. Both rule head formats are supported and can coexist: the violation[{"msg": msg}] map format and the deny[msg] string format. Per-policy configuration via input.parameters also works as expected. You can take a .rego file from your Gatekeeper constraint templates, drop it into a Pulumi policy pack, and publish it to Pulumi Cloud to enforce automatically across your stacks.

This shifts policy enforcement left. Instead of waiting for the Kubernetes API server to reject a resource at admission time, you catch the violation during pulumi preview, before anything is deployed.

Walkthrough: Reusing policies from the gatekeeper-library

The OPA Gatekeeper Library is a community-maintained collection of constraint templates covering common Kubernetes guardrails like pod security, image provenance, and resource limits. You can use these policies directly with Pulumi. Here’s an end-to-end example using the allowedrepos policy to restrict which container image registries your deployments can use.

Create a new Kubernetes OPA policy pack:
```
pulumi policy new kubernetes-opa
```

Copy the Rego source from gatekeeper-library into your policy pack as allowedrepos.rego. No modifications are needed:

package k8sallowedrepos

violation[{"msg": msg}] {
 container := input.review.object.spec.containers[_]
 not strings.any_prefix_match(container.image, input.parameters.repos)
 msg := sprintf("container <%v> has an invalid image repo <%v>, allowed repos are %v",
 [container.name, container.image, input.parameters.repos])
}

violation[{"msg": msg}] {
 container := input.review.object.spec.initContainers[_]
 not strings.any_prefix_match(container.image, input.parameters.repos)
 msg := sprintf("initContainer <%v> has an invalid image repo <%v>, allowed repos are %v",
 [container.name, container.image, input.parameters.repos])
}

violation[{"msg": msg}] {
 container := input.review.object.spec.ephemeralContainers[_]
 not strings.any_prefix_match(container.image, input.parameters.repos)
 msg := sprintf("ephemeralContainer <%v> has an invalid image repo <%v>, allowed repos are %v",
 [container.name, container.image, input.parameters.repos])
}

Verify that your PulumiPolicy.yaml has Gatekeeper compatibility enabled:

description: Kubernetes Gatekeeper Policy Pack
runtime: opa
inputFormat: kubernetes-admission

Configure the allowed registries. Create a policy-config.json file to pass the repos parameter:

{
 "k8sallowedrepos": {
 "repos": ["gcr.io/my-company/", "docker.io/library/"]
 }
}

Test the policy locally against a stack:
```
pulumi preview --policy-pack . --policy-pack-config policy-config.json
```
Any Kubernetes deployment using an image outside the allowed registries will produce a violation at preview time, before it reaches the cluster.
Publish the pack and add it to a policy group to enforce it across your organization:
```
pulumi policy publish
```

The same approach works for any policy in the gatekeeper-library: containerlimits, requiredlabels, disallowedtags, and others. Copy the Rego, configure parameters, and publish.

Part of the Pulumi Insights governance story

OPA policy support is part of the broader Pulumi Insights governance platform. Insights gives you visibility and compliance across your entire cloud footprint, and OPA policies plug directly into that:

Audit policy scans continuously evaluate OPA policies against your Pulumi stacks and discovered cloud resources, providing a compliance baseline without redeploying anything.
Self-hosted execution lets you run policy evaluations on your own infrastructure using customer-managed workflow runners, keeping credentials and data within your network.
Pre-built compliance packs for CIS, NIST, PCI DSS, and other frameworks are available alongside your custom OPA policies in the same policy groups.

Whether you’re enforcing policy at deployment time, scanning existing infrastructure for drift, or running continuous compliance checks, OPA policies are a native participant.

Frequently asked questions

Do I need to modify my existing Gatekeeper `.rego` files?

No. Set inputFormat: kubernetes-admission in your PulumiPolicy.yaml and your existing Gatekeeper constraint template rules work as-is. Pulumi handles the AdmissionReview wrapping automatically.

What happens with non-Kubernetes resources?

When using inputFormat: kubernetes-admission, non-Kubernetes resources are silently skipped during evaluation. Your Gatekeeper rules only run against Kubernetes resources.

Do I need OPA installed locally?

No. The pulumi-policy-opa analyzer plugin embeds the OPA evaluation engine and is installed automatically by the Pulumi CLI (v3.227.0+). The standalone OPA CLI is only needed if you want to run opa test against your policies independently.

When should I use OPA vs. TypeScript or Python for policies?

If your team already writes Rego for other tools like Gatekeeper, writing Pulumi policies in Rego keeps your policy language consistent. If your team is more comfortable with general-purpose languages or needs auto-remediation, use the TypeScript or Python SDKs.

Gatekeeper constraint templates can be reused directly via the kubernetes-admission input format, but other OPA integrations use different input structures, so those policies would need to be adapted to Pulumi’s resource model. All three languages work together in the same policy groups.

Get started

Templates are available for kubernetes-opa, aws-opa, azure-opa, and gcp-opa via pulumi policy new. For more details, see the policy authoring guide and the Policy as Code overview.

Get started with OPA policies

github.com/pulumi/pulumi-policy-opa

Lock Down Values in Pulumi ESC with fn::final

Pablo Terradillos — Tue, 17 Mar 2026 11:00:00 -0700

Pulumi ESC (Environments, Secrets, and Configuration) allows you to compose environments by importing configuration and secrets from other environments, but this also means a child environment can silently override a value set by a parent. When that value is a security policy or a compliance setting, an accidental override can cause real problems. With the new fn::final built-in function, you can mark values as final, preventing child environments from overriding them. If a child environment tries to override a final value, ESC raises a warning and preserves the original value.

How it works

Let’s say you have a parent environment that sets the AWS region for all deployments. You can use fn::final to ensure no child environment can change it:

# project/parent-env
values:
 aws-region:
 fn::final: us-east-1

If a child environment tries to override the final value, ESC raises a cannot override final value warning.

# project/child-env
imports:
 - project/parent-env
values:
 aws-region: eu-west-1 # raises a warning

This evaluates to:

{
 "aws-region": "us-east-1"
}

In this scenario, the ESC environment is still valid, but the final value remains unchanged.

When to use fn::final

Use fn::final for:

Security-sensitive values that shouldn’t be changed
Compliance or policy settings enforced by a platform team
Shared base environments where certain values must remain consistent

Getting started

The fn::final function is available now in all Pulumi ESC environments. For more information, check out the fn::final documentation!

New: Previous Provider Version Docs in Pulumi Registry

Cam Soper — Wed, 11 Mar 2026 00:00:00 +0000

The Pulumi Registry now supports browsing documentation for previous versions of first-party Pulumi providers. If you’ve ever needed to look up the API docs for an older provider version, you no longer have to dig through Git history or guess at changes — the docs are right there in the Registry. These docs also help Pulumi Neo and other agents more accurately assist you with your Pulumi code and operations.

How it works

When you visit a first-party provider’s page in the Pulumi Registry, you’ll now see a version dropdown selector that lets you switch between the current version and previous versions.

Select a previous version from the dropdown, and the Registry loads the full API documentation for that version.

What’s available

This feature currently includes documentation for the latest release of each previous major version, going back two major versions. For example, if a provider is on v7.x, you’ll be able to view docs for the latest v6.x and v5.x releases in addition to the current version.

Get started

Head over to the Pulumi Registry and try it out. Pick any first-party provider with multiple major versions and use the version dropdown to browse its history.

We’d love to hear your feedback — let us know what you think in the Pulumi Community Slack or by opening an issue on GitHub.

Explore the Pulumi Registry

Pulumi Cloud Now Supports Google Sign-In

Pablo Seibelt — Tue, 10 Mar 2026 00:00:00 +0000

Many developers and platform engineers already use Google accounts daily for email, cloud console access, and collaboration. Until now, signing in to Pulumi Cloud required a GitHub, GitLab, or Atlassian account, or an email/password combination. Today, we’re adding Google as a first-class identity provider, so you can sign in to Pulumi Cloud with the same Google account you already use for everything else.

Adding Google as an identity provider brings several benefits:

Use the account you already have. If your team already lives in Google Workspace, you can sign in to Pulumi Cloud with a single click, no new credentials required.
Inherit your existing security policies. If you’ve already configured two-factor authentication, device management, and other protections in a Google Workspace, you can carry them over to Pulumi Cloud automatically.

How it works

Signing up or signing in

On the Pulumi Cloud sign-in page, you’ll see a new Sign in with Google button alongside the existing GitHub, GitLab, and Atlassian options. If you are a new user, select it, authenticate with your Google account, and you’re in.

If you already have an existing Pulumi Cloud account, make sure to associate to your existing account as described in the next section.

Connecting Google to an existing account

If you already have a Pulumi Cloud account, you can link your Google identity from your account settings:

Navigate to your Account Settings.
Scroll to the Identity providers section.
Under Available identities, select Connect Google.

Once connected, you can use Google to sign in to your existing Pulumi Cloud account.

Google sign-in lets you authenticate with Pulumi Cloud using your individual Google account. It does not enable Google as a single sign-on (SSO) identity provider for your Pulumi Cloud organization.

If your team uses Google Workspace and needs centralized membership governance for Pulumi Cloud, configure SAML SSO with Google Workspace instead. SAML SSO is available on Pulumi Enterprise and Business Critical editions.

Get started

Google sign-in is available now for all new and existing Pulumi Cloud users:

New users: Sign up with Google on the Pulumi Cloud sign-up page.
Existing users: Connect your Google account in your account settings.

For more details, see the Pulumi Cloud accounts documentation.

We’d love to hear your feedback. Join the conversation in the Pulumi Community Slack or open an issue on GitHub.

Expanded Version Control Support in Pulumi Cloud

Luke Ward — Mon, 09 Mar 2026 00:00:00 +0000

Your version control provider shouldn’t limit your infrastructure workflows. Pulumi Cloud now works with GitHub, GitHub Enterprise Server, Azure DevOps, and GitLab. Every team gets the same deployment pipelines, PR previews, and AI-powered change summaries regardless of where their code lives.

Connect multiple providers and accounts

You can connect multiple VCS providers to a single Pulumi organization simultaneously, like GitHub, GitLab, and Azure DevOps all at once. You can also connect multiple accounts of the same provider, such as two separate GitHub organizations or two GitLab groups. This means teams that work across different repositories, providers, or organizational boundaries can manage everything from one place.

GitHub Enterprise Server is currently limited to one connection per Pulumi organization.

What your team can do

Deploy on every push

Connect a repository to a stack, and infrastructure deploys automatically when you push. Configure path filters to trigger only when relevant files change, and manage environment variables and secrets directly in Pulumi Cloud. No external CI/CD pipeline required.

Preview changes on pull requests

Every pull request gets an infrastructure preview so reviewers can see exactly what will change before merging. The preview runs the same Pulumi operations your deployment would, giving your team confidence that a merge won’t break anything.

Neo explains your changes

Neo posts AI-generated summaries on your pull requests explaining what infrastructure changes mean in plain language. Reviewers who aren’t Pulumi experts can still understand the impact of a change without reading resource diffs.

Let Neo open pull requests for you

Ask Neo to make infrastructure changes and it opens pull requests directly against your connected repositories. Describe what you want in natural language, and Neo writes the code, opens the PR, and kicks off a preview, all without leaving Pulumi Cloud.

Detect and fix drift

Schedule drift detection to catch out-of-band changes automatically. When someone modifies infrastructure outside of your Pulumi programs, drift detection flags the difference so your team can remediate before it causes issues.

Secure authentication

Pulumi Cloud authenticates with your VCS provider using OIDC or OAuth so no long-lived credentials need to be stored. Short-lived tokens keep your deployment pipelines secure without manual secret rotation.

Set up new projects from your VCS

The new project wizard discovers your organizations, repositories, and branches so you can scaffold and deploy a new stack without leaving Pulumi Cloud. Pick your repo, choose a branch, and you’re ready to deploy.

Getting started

An org admin configures the integration under Settings > Version Control.
Authorize with your VCS provider.
Deploy infrastructure with first-class workflows.

For setup details, see the docs for GitHub, GitHub Enterprise Server, Azure DevOps, and GitLab.

Connect your VCS

Now in Public Preview: Store Terraform State in Pulumi Cloud

Claire Gaestel — Thu, 05 Mar 2026 00:00:00 +0000

Platform engineering teams managing infrastructure across Terraform and Pulumi now have a way to unify state management without rewriting a single line of HCL. Starting today, Pulumi Cloud can serve as a Terraform state backend, letting you store and manage Terraform state alongside your Pulumi stacks. Your team continues using the Terraform or OpenTofu CLI for day-to-day operations while gaining the benefits of Pulumi Cloud: AI-powered infrastructure management with Pulumi Neo — our infrastructure agent — encrypted state storage, update history, state locking, role-based access control, audit policies, and unified resource visibility through Insights.

This feature is now available in public preview.

Why this matters

Most organizations adopting Pulumi are not starting from scratch. They have years of Terraform deployments spread across teams, and migrating everything to a new IaC tool overnight is not realistic. We have heard from customers who are excited about the power of Pulumi Cloud but have had to manage migration projects before they can fully benefit from centralized visibility and governance.

The Terraform state backend in Pulumi Cloud changes that equation. Instead of requiring a full code conversion before teams see value, you can migrate your state in minutes and immediately unlock Pulumi Cloud capabilities for your existing Terraform infrastructure — including Neo, Pulumi’s AI infrastructure agent. Once your Terraform state is in Pulumi Cloud, Neo can reason about those resources the same way it does for Pulumi IaC stacks: finding resources, troubleshooting issues, understanding dependencies, and writing infrastructure code PRs. Teams that prefer Terraform can keep using it, while platform engineers get a single AI-powered control plane across the entire infrastructure estate.

What you get

When you store Terraform state in Pulumi Cloud, your Terraform-managed resources get the following added functionality:

Agentic infrastructure with Neo. Neo, Pulumi’s AI infrastructure agent, works across your entire cloud footprint — Terraform and Pulumi IaC alike. Once your Terraform state is in Pulumi Cloud, you can ask Neo to find resources across both tools, trace dependencies that span Terraform and Pulumi stacks, troubleshoot configuration issues, and generate new infrastructure code informed by your existing resources. This means platform teams get a single AI-powered interface regardless of which IaC tool manages each piece of infrastructure.

Encrypted state with update history. State is encrypted in transit and at rest. Every change is tracked as a versioned checkpoint visible in the stack activity tab, giving you full rollback capability. This is a common concern for teams currently storing state in S3 buckets.

Automatic state locking. Pulumi Cloud prevents concurrent Terraform operations from corrupting state, without requiring you to configure DynamoDB tables or other external locking mechanisms.

Role-based access control. Control who can read or modify each stack using teams and RBAC, applying the same access policies you use for Pulumi stacks.

Unified resource visibility. View Terraform-managed resources alongside Pulumi-managed resources in Resource Search. Each Terraform resource appears in the console using a pulumi:terraform:<tf-type> naming convention, so you can search and filter using the attribute names you already know.

Audit policies. Run audit (detective) policy packs against your Terraform-managed stacks, including Pulumi’s pre-built compliance packs for CIS, PCI, and more. Pulumi Cloud performs a best-effort schema mapping from Terraform resource shapes to Pulumi provider equivalents, so existing policy packs work without modification in most cases.

Stack outputs and references. Terraform root module outputs are automatically mapped to Pulumi stack outputs, making them available via stack references and the pulumi-stacks ESC provider. This is useful for sharing foundational infrastructure like VPC IDs or DNS zones between Terraform and Pulumi stacks, and for incremental migrations where legacy infrastructure stays in Terraform while new stacks are written in Pulumi.

How it works

Pulumi Cloud implements the Terraform remote backend API. You point the Terraform CLI at Pulumi Cloud using the standard backend "remote" configuration block, and no changes to your Terraform code or workflow are required.

Each Terraform workspace maps to a Pulumi stack. The workspace name follows the convention <project>_<stack>. For example, networking_prod creates a stack named prod in the networking project.

Get started

Migration from S3, Azure Blob, GCS, local backends, or HCP Terraform (Terraform Cloud) takes minutes and is documented in the Terraform state backend guide. From S3, Azure Blob, GCS, or local state, back up your state, update your backend block to point to Pulumi Cloud, set TF_TOKEN_api_pulumi_com, and run terraform init -migrate-state. From HCP Terraform, export state manually and push it to Pulumi Cloud.

Each Terraform resource stored in Pulumi Cloud counts as a resource under management, the same as a Pulumi-managed resource. See the pricing page for details.

Store Terraform State in Pulumi Cloud

If you have questions or feedback, join us in the Pulumi Community Slack or open an issue on GitHub.

Now GA: Up to 20x Faster Pulumi Operations for Everyone

Thomas Gummerer — Thu, 05 Mar 2026 00:00:00 +0000

In January, we introduced a major performance enhancement for Pulumi Cloud through a fundamental change to how Pulumi manages state that speeds up operations by up to 20x. After a staged rollout across many organizations, it is now enabled by default for every Pulumi Cloud operation. No opt-in required—just use Pulumi CLI v3.225.0+ with Pulumi Cloud. The improvement applies to pulumi up, pulumi destroy, and pulumi refresh; pulumi preview does not modify state, so it is unchanged.

What this means for you

First and foremost, nothing about how you work with pulumi needs to change. Your updates now benefit from better parallelism and should thus complete faster. Before this change, pulumi always saved a full snapshot to the cloud, so the current state could always be recovered if something goes wrong. With journaling, we now only send the state of each operation, which allows us to send these updates in parallel, as long as resources are not related to each other. For the full deep dive, see the blog post linked above.

Production results

Since January, we’ve had many early adopters of journaling. This helped us shake out one final bug on the server side, and journaling has been stable since then. With that we feel confident in rolling this out to all our users.

We’ve also gathered some real-world data on how journaling is performing. The data from the preview period shows some significant improvements for update times. For stacks with fewer than 100 resources, the median improvement is 25.3%, while the p90 improvement is 75.2%, and we’ve seen a p99 improvement of up to 92.6% Meanwhile, for larger stacks, the median improvement is 60.2%. We need more data for stacks with more than 100 resources, we will update this blog once that comes in.

This data already shows the expected significant improvement in update times, especially for larger stacks, though the improvements strongly depend on the shape and type of resources that are being set up. Stacks with many resources, that are quick to update benefit more than smaller stacks with slower to set up resources. For more numbers see also the Benchmarks section in the previous blog post

What you need to do

While this was an opt-in process using the PULUMI_ENABLE_JOURNALING environment variable, this opt-in is no longer required. Just upgrade your Pulumi CLI to v3.225.0+ and use the Pulumi Cloud backend, and journaling will automatically speed up your updates.

If you encounter any issues, reach out on the Pulumi Community Slack or through Pulumi Support. You can also set the PULUMI_DISABLE_JOURNALING=true env variable to opt out of journaling.

Run Pulumi Insights on Your Own Infrastructure

Levi Blackstone — Mon, 02 Mar 2026 00:06:00 -0700

Pulumi Insights gives you visibility and governance across your entire cloud footprint: discovery scans catalog every resource in your cloud accounts, and policy evaluations continuously enforce compliance against those resources. Until now, Insights workflows ran exclusively on Pulumi-hosted infrastructure. That works well for many teams, but enterprises with strict data residency requirements, private network constraints, or regulatory obligations need to run this work in their own environments. Today, Pulumi Insights supports customer-managed workflow runners for both SaaS Pulumi Cloud and self-hosted Pulumi Cloud installations.

Insights at a glance

Insights provides two complementary capabilities that together form a governance lifecycle for your cloud infrastructure.

Discovery scans cloud accounts across AWS, Azure, GCP, and more to catalog every resource regardless of how it was provisioned: Pulumi, Terraform, CloudFormation, or manual creation. Once cataloged, you can search, filter, group, and export your resource data. You can also import unmanaged resources into Pulumi to bring them under IaC management.

Policy enforces compliance with policy-as-code written in TypeScript or Python. Pulumi ships pre-built compliance packs for CIS, NIST, PCI DSS, HITRUST, and other frameworks so you can start evaluating without writing any code. Audit policy groups continuously evaluate all discovered resources and IaC stacks, while preventative policies block non-compliant deployments before they reach production.

This enables you to map out your cloud estate, evaluate compliance, and then remediate any issues uncovered by policy.

Why self-hosted?

Running Insights on your own infrastructure with customer-managed workflow runners gives you:

Data residency: Scan execution and policy evaluation run entirely within your private network.
Private infrastructure access: Scan resources in VPCs and environments that are not accessible from the public internet.
Compliance: Cloud provider credentials can stay internal to your network, meeting regulatory requirements for credential handling.
Flexible hosting: Run workflow runners on any environment that meets your needs, including Linux, macOS, Docker, and Kubernetes.

How it works

Customer-managed workflow runners are lightweight agents that poll Pulumi Cloud for pending work, execute it locally, and report results back. You can configure runners to handle specific workflow types: discovery scans, policy evaluations, deployments, or all three.

This works identically whether you use SaaS Pulumi Cloud or a self-hosted installation. The runner communicates with the Pulumi Cloud API over HTTPS, so no inbound connectivity is required, making it well suited to run in restricted network environments.

Under the hood, this is powered by a distributed work scheduling system that routes activities to the right runner pool, handles lease-based execution, and recovers automatically from failures. For a deep dive on the architecture, see How We Built a Distributed Work Scheduling System for Pulumi Cloud.

If your team already uses customer-managed workflow runners for Pulumi Deployments, your existing runner pools can handle Insights workflows with no additional infrastructure.

Get started

Self-hosted Insights is available on the Business Critical edition of Pulumi Cloud. To learn more or get set up:

Self-hosted Insights documentation — configuration and setup for discovery scans and audit policy evaluations on your own infrastructure
Customer-managed workflow runners — runner installation, configuration reference, and pool management
Insights & Governance overview — full documentation for discovery and policy capabilities
Contact sales to enable self-hosted Insights for your organization

How We Built a Distributed Work Scheduling System for Pulumi Cloud

Levi Blackstone — Thu, 26 Feb 2026 00:00:00 +0000

Pulumi Cloud orchestrates a growing number of workflow types: Deployments, Insights discovery scans, and policy evaluations. Some of that work runs on Pulumi’s infrastructure, and some of it runs on yours via customer-managed workflow runners. We needed a scheduling system that could handle all of these workflow types reliably across both environments. In this post, we’ll take a look at the system we built.

Where we started

For our first workflow integration, Deployments, scheduling wasn’t too complicated. A deployment was queued, a worker picked it up, and it ran. The queue was purpose-built for deployments, and it worked well for that single use case. Over time, we added more sophisticated logic to handle retries, ordering, rate limiting, observability, and more.

With the launch of Insights, the number of workflow types grew. Now Pulumi Cloud manages discovery scans to catalog cloud resources and runs audit policy evaluations to continuously verify compliance. While these workflows share similarities, each type needed its own scheduling, retry logic, and failure handling.

Later we added the option for customers to run workflows on their own infrastructure using customer-managed workflow runners. As the complexity of these requirements grew, we knew that our initial approach for Deployments wasn’t going to scale. We needed a single system that could schedule any type of work, route it to the right place, and handle the messy reality of distributed execution: crashes, network failures, rate limits, and retries.

We call this the background activity system.

Why not use an off-the-shelf queue?

Why build this instead of using Amazon SQS, RabbitMQ, or one of the many existing queue libraries? We considered these options but chose to build our own for a few reasons.

Pulumi Cloud supports self-hosted installations, including air-gapped environments. We intentionally minimize external dependencies so that self-hosted customers don’t have to stand up additional infrastructure. A system built on an external queue works fine for our hosted service, but it means self-hosted customers would need to provide a compatible backend. By building on top of the database we already require, we avoid adding another system to maintain.

More importantly, queueing is only part of the problem. What we actually need is scheduling with durability. This means ensuring that remote workers don’t lose activities on restart, priority so that urgent work gets compute resources first, constraints like “only so many scans per org at a time,” structured logging for observability, and checkpointing so that long-running operations can resume after a failure.

These features can be layered onto a generic queue library but can require more code than implementing them directly. For example, priority queues are often implemented with multiple ranked queues, but this breaks single-activity-at-a-time constraints. A second queue wouldn’t see a job already running in the first one. There’s no way for producers in a distributed system to coordinate across the queues without support in the queuing system itself.

Capacity management is another area where generic queues fall short. Distributed systems need to respond dynamically to slowdowns, network interruptions, and rate limits from downstream services. These are common low-level details that every workflow type needs, and building them into the scheduling layer means individual handlers don’t have to solve them independently.

We also need structured logging that works everywhere, including on customer-managed runners behind firewalls where centralized logging services aren’t accessible.

Building this ourselves gave us a system that works with existing infrastructure and handles these requirements natively.

Design constraints

With that context, here are some of the constraints that shaped the design:

Pull-only agents. Customer-managed workflow runners live behind NATs, corporate proxies, and air-gapped networks. They can’t accept inbound connections, so all communication has to be agent-initiated.
Mixed execution environments. The same system needs to work for Pulumi-hosted workers (with direct access to internal systems) and customer-managed runners (communicating entirely over REST). We didn’t want to maintain two separate code paths.
Different workflow types. Deployments, Insights scans, and audit policy evaluations have different payloads and execution semantics, but they all need the same scheduling guarantees: exactly-once execution, automatic retries, failure recovery, and observability.
Automatic fault tolerance. Agents crash, networks drop, and machines get recycled by autoscalers. The system needs to detect these failures and recover without needing a person to step in.
Extensibility. We knew we’d keep adding workflow types. Adding a new one should mean writing a handler and registering it, not building new infrastructure.

The background activity

At the center of the system is the background activity, a persistent, typed work unit. Each activity includes:

A type discriminator that identifies what kind of work it represents (e.g., “insights-discovery” or “policy-evaluation”)
A payload specific to that type, containing whatever data the handler needs
A routing context that determines which runner pool should execute it
Scheduling metadata like priority, activation time, and retry configuration
A status tracking where the activity is in its lifecycle

The type discriminator makes this system polymorphic. The scheduling engine doesn’t need to know what’s inside the payload. It moves activities through their lifecycle and delegates the actual work to a type-specific handler.

The state machine

Every activity follows the same lifecycle regardless of type:

---
config:
flowchart:
curve: linear
---
graph LR
Start(( )) -->|Created| Ready
Ready -->|Leased| Pending
Pending -->|Started| Executing
Executing -->|Success| Completed
Completed --> End(( ))
Executing -->|Error| Failed
Failed --> End
Executing -->|Canceled| Canceled
Canceled --> End
Executing -->|Dependencies| Waiting
Waiting -->|Unblocked| Ready
Pending -->|Lease expired| Restarting
Executing -->|Lease expired| Restarting
Restarting -->|Re-lease| Ready
style Start fill:#000,stroke:#000,color:#000
style End fill:#000,stroke:#000,color:#000

The states fall into two groups:

Running states (work is in flight or can be resumed):

Ready: queued and eligible to be claimed by a worker
Pending: claimed by a worker, execution about to start
Executing: actively running on a worker
Waiting: parked, blocked on one or more dependency activities
Restarting: recovered after a worker failure, ready to be re-claimed

Terminal states (work is done):

Completed, Failed, Canceled

New workflow types get these features automatically: scheduling, retries, dependency management, and observability.

Leases: distributed execution without coordination

A central challenge of any distributed work queue is preventing double-execution. If two agents try to execute the same activity simultaneously, you get duplicate work and data corruption. A central coordinator can solve this, but it becomes a single point of failure.

We use lease-based optimistic concurrency instead. This is a well-known pattern, adapted here for long-running, stateful workflows.

How it works

When an agent is ready for new work, it asks the service to lease an activity. The service atomically selects the highest-priority ready activity, assigns a lease token with an expiration time, and transitions the activity to Pending. No other agent can claim the same activity.

sequenceDiagram
participant Agent
participant Service
Agent->>Service: Poll for work
Note right of Service: Select highest-priority<br/>Ready activity
Note right of Service: Atomically set lease<br/>token + expiration
Service->>Agent: Lease (token, expiration)
Agent->>Service: Begin execution
Note right of Service: Transition to Executing
Note over Agent: Work in progress...
Agent->>Service: Renew lease
Service->>Agent: New expiration
Note over Agent: Work continues...
Agent->>Service: Complete (token, result)
Note right of Service: Transition to Completed<br/>Archive activity
Service->>Agent: Acknowledged

While executing, the agent periodically renews its lease to signal that it’s still working. If the agent crashes, loses network connectivity, or is terminated, it stops renewing. Once the lease expires, the service transitions the activity to Restarting, making it available for another agent to claim.

sequenceDiagram
participant A as Agent A
participant S as Service
participant B as Agent B
A->>S: Lease activity
S->>A: Token + expiration
Note over A: Executing...
A--xS: Agent A crashes
Note right of S: Lease expires
Note right of S: Transition → Restarting
B->>S: Poll for work
Note right of S: Lease to Agent B<br/>Transition → Pending
S->>B: Token + expiration
Note over B: Agent B continues execution

The service doesn’t need to explicitly coordinate between workers because leases are acquired using atomic database operations. The lease expiration is the failure detector; if a lease expires, then the work needs to be rescheduled.

Routing work to the right runner pool

Pulumi Cloud supports multiple workflow runner pools. An organization might have one pool for production in us-east-1, another for staging in eu-west-1, and use Pulumi-hosted runners for development. Work needs to reach the right pool.

Each activity carries a routing context that identifies which runner pool should execute it. When a runner polls for work, it filters by its own pool identifier so that it only sees activities meant for it.

We use prefix matching for this filtering. A runner matches activities whose context starts with its pool’s identifier. This means the service can use hierarchical contexts (e.g., pool-abc/insights/scan-123) and runners will still match on the pool prefix. Cleanup is also straightforward; when a runner pool is deleted, all activities with that context prefix are bulk-canceled.

This routing mechanism works the same way regardless of workflow type, and adding a new workflow type doesn’t require changes to the routing layer.

Dependencies and multi-step workflows

Some workflows are naturally multi-step. An Insights discovery scan might discover resources that then need policy evaluation. Rather than building a separate orchestration engine, we built dependency management into the activity system.

An activity can declare a dependency set: a list of other activities that must complete before it can run. A dependent activity enters the Waiting state when created. As its dependencies complete, the system checks whether all prerequisites are satisfied. When the last one finishes, the waiting activity transitions to Ready and enters the scheduling queue.

graph TD
A["Insights Discovery<br/><b>Executing</b>"] -->|depends on| B["Policy Evaluation<br/><b>Waiting</b>"]
A -->|completes| C["Insights Discovery<br/><b>Completed</b>"]
C -->|triggers| D["Policy Evaluation<br/><b>Ready</b><br/>(auto-scheduled)"]

This gives us a lightweight DAG of work without requiring a separate workflow engine. Dependent activities get the same guarantees as any other activity: lease-based execution, automatic recovery, and observability.

Two execution modes, one interface

This is where the design really pays off for customer-managed runners. The system supports two execution modes:

Direct mode runs in-process alongside the Pulumi Cloud service. Workers have low-latency access to internal systems and can process activities with minimal overhead. This is what Pulumi-hosted runners use.
Remote mode communicates over REST APIs. The runner polls for activities, leases them, executes work locally, and reports results back over HTTP. This is what customer-managed runners use. No database access, no internal network access, no inbound connectivity required.

Both modes share the same handler interface so that a workflow handler doesn’t need to know where it’s running. Whether it’s running on Pulumi’s hosted infrastructure or on a customer’s Kubernetes cluster, the handler simply processes the payload and reports a result.

Putting it all together

Let’s walk through a concrete example. A user wants to run an Insights discovery scan on an AWS account using a customer-managed workflow runner.

sequenceDiagram
participant User
participant PC as Pulumi Cloud
participant Runner as Workflow Runner<br/>(Customer Infrastructure)
User->>PC: 1. Configure Insights scan<br/>for runner pool
Note right of PC: 2. Create background activity<br/>type: insights-discovery<br/>context: runner-pool-xyz<br/>status: Ready
Runner->>PC: 3. Poll for work (filtered by pool)
PC->>Runner: 4. Lease activity (token + expiration)
Runner->>PC: 5. Initialize workflow
PC->>Runner: Return cloud credentials + job token
Note over Runner: 6. Execute scan locally<br/>(talks directly to cloud APIs —<br/>credentials are used only on<br/>the runner)
Runner->>PC: 7. Renew lease
Note right of PC: Extend expiration
Runner->>PC: 8. Report completion
Note right of PC: 9. Mark completed<br/>Archive activity
Note right of PC: 10. Unblock dependent activities<br/>(e.g., policy evaluation)

A user configures an AWS account for Insights scanning in Pulumi Cloud and assigns it to a workflow runner pool.
Pulumi Cloud creates a background activity with the type set to insights discovery, the routing context set to the runner pool, and the payload containing the account configuration.
A customer-managed workflow runner polling that pool detects new work.
The runner leases the activity, acquiring an exclusive lock via the lease token.
The runner initializes the workflow, receiving any required cloud provider credentials (e.g., resolved from Pulumi ESC (Environments, Secrets, and Configuration)) and a job token from Pulumi Cloud.
The runner executes the scan locally on the customer’s infrastructure, talking directly to the cloud provider APIs.
During execution, the runner periodically renews its lease to signal liveness.
The scan completes, and the runner reports the result back to Pulumi Cloud.
The service marks the activity as completed and archives it.
If a dependent policy evaluation activity was waiting on this scan, it automatically transitions to Ready and enters the scheduling queue, where another runner in the pool can pick it up.

This flow works the same way whether the runner is hosted by Pulumi or by the customer. The only difference is whether the execution mode is direct or remote.

Retries and scheduling

Failures are expected in distributed systems. The background activity system handles them at several levels:

Lease expiration covers hard failures like agent crashes, network partitions, and machine terminations. If a lease expires, the activity moves to Restarting, and is available for another agent to pick up.
Handler-controlled retries cover soft failures like transient API errors and rate limits. A handler can request a reschedule with a delay, putting the activity back in Ready with a future activation time.
Automatic retries provide a configurable retry budget per activity. Each activity can specify how many times it should be retried and the delay between attempts, preventing runaway retry loops.
Priority scheduling ensures urgent work gets processed first. Higher-priority activities are leased before lower-priority ones, even if the lower-priority activity has been waiting longer.
Lease renewal during slowdowns keeps the activity alive without blocking other work, even if a downstream service is slow. The agent continues renewing its lease while it waits, and the scheduler remains free to assign other activities to other agents.

Observability

Every activity generates a structured log of its execution, including timestamps, severity levels, and code context. Logs are stored with the activity record and are accessible via an API and admin tooling.

This is especially useful for customer-managed runners, where the service can’t directly observe the execution environment. The structured log gives operators visibility into the execution context, even when the runner is behind a firewall. Handlers can also use these logs as a progress journal, encoding checkpoints that allow a restarted activity to pick up where it left off rather than starting from scratch.

Retention policies are configurable per organization and per workflow type. Completed activities can be retained for auditing or purged to manage storage, and failed activities are typically retained longer for debugging.

What we learned

A generic system pays off quickly. Our initial instinct was to build targeted solutions for each workflow type. Investing in a generic activity system required more upfront design work, but now adding a new workflow type requires a fraction of the effort it would take otherwise. New workflows ship with full scheduling, retry, and observability support from day one.

Leases handle many failure modes. We evaluated several approaches for distributed work coordination, including message queues with explicit acknowledgment and coordinator-based assignment. The lease model works well because all failure modes are handled through timeouts. If an agent is running as expected, it renews. If it isn’t, the lease expires.

Keeping the execution paths symmetric requires discipline. Making the hosted and self-hosted paths share the same handler interface was a deliberate choice. It would be easy to add shortcuts for the hosted path that bypass the remote API, but resisting that temptation means that features work for both cases automatically.

The hard part isn’t running the work. Running a scan or a deployment is straightforward once you have the right credentials. The real complexity is in everything around the execution: scheduling, routing, leasing, retrying, resolving dependencies, and cleaning up. These operational concerns aren’t visible to users, but they are essential to providing a reliable experience.

Wrapping it up

Today this system powers deployments, Insights discovery scans, and policy evaluations across both Pulumi Cloud and customer-managed infrastructure. The architecture is general enough that every new workflow type we add inherits the full scheduling, routing, retry, and observability stack without additional plumbing.

If you’re interested in running workflows on your own infrastructure, check out customer-managed workflow runners. To see how Insights can help you understand and manage your cloud infrastructure, get started with Pulumi Insights.

New in Pulumi IaC: `onError` Resource Hook

Tom Harding — Mon, 23 Feb 2026 00:00:00 +0000

You can now control what happens when a resource fails during create, update, or delete—retry with backoff, fail fast, or handle errors in custom code. Last year, Pulumi IaC introduced the resource hooks feature, allowing you to run custom code at different points in the lifecycle of resources. Today we’re adding the onError hook so you can react when operations fail.

Recovering from errors

When a Pulumi program encounters an error while creating, updating, or deleting a resource, the operation halts and the error is reported back. Sometimes that’s not what we want—errors can be intermittent or temporary. If you’ve hit transient failures or resource-not-ready errors, the onError hook can help.

A common case is resource readiness: creating resources that depend on DNS propagation or the readiness of other servers. The program can fail simply because it ran too soon. Instead of failing, we can wait and retry. The example below shows how:

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

const notStartedRetryHook = new pulumi.ErrorHook(
 "retry-when-not-started",
 async (args) => {
 const latestError = args.errors[0] ?? "";

 if (!latestError.includes("resource has not yet started")) {
 return false; // do not retry, this is another type of error
 }

 await new Promise((resolve) => setTimeout(resolve, 5000));
 return true; // retry
 },
);

const res = new MyResource("res", {}, {
 hooks: {
 onError: [notStartedRetryHook],
 },
});

import time

import pulumi


def retry_when_not_started(args: pulumi.ErrorHookArgs) -> bool:
 latest_error = args.errors[0] if args.errors else ""

 if "resource has not yet started" not in latest_error:
 return False # do not retry, this is another type of error

 time.sleep(5)
 return True # retry


not_started_retry_hook = pulumi.ErrorHook(
 "retry-when-not-started",
 retry_when_not_started,
)

res = MyResource(
 "res",
 opts=pulumi.ResourceOptions(
 hooks=pulumi.ResourceHookBinding(
 on_error=[not_started_retry_hook],
 ),
 ),
)

package main

import (
 "strings"
 "time"

 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 hook, err := ctx.RegisterErrorHook(
 "retry-when-not-started",
 func(args *pulumi.ErrorHookArgs) (bool, error) {
 latest := ""
 if len(args.Errors) > 0 {
 latest = args.Errors[0]
 }

 if !strings.Contains(latest, "resource has not yet started") {
 return false, nil // do not retry, this is another type of error
 }

 time.Sleep(5 * time.Second)
 return true, nil // retry
 },
 )
 if err != nil {
 return err
 }

 _, err = NewMyResource(ctx, "res", &MyResourceArgs{}, pulumi.ResourceHooks(&pulumi.ResourceHookBinding{
 OnError: []*pulumi.ErrorHook{hook},
 }))
 if err != nil {
 return err
 }

 return nil
 })
}

using System;
using System.Threading;
using System.Threading.Tasks;
using Pulumi;

class ErrorHookStack : Stack
{
 public ErrorHookStack()
 {
 var retryHook = new ErrorHook(
 "retry-when-not-started",
 async (args, cancellationToken) =>
 {
 var latestError = args.Errors.Count > 0 ? args.Errors[0] : "";

 if (!latestError.Contains("resource has not yet started"))
 {
 return false; // do not retry, this is another type of error
 }

 await Task.Delay(TimeSpan.FromSeconds(5), cancellationToken);
 return true; // retry
 });

 var res = new MyResource("res", new MyResourceArgs(), new CustomResourceOptions
 {
 Hooks = new ResourceHookBinding
 {
 OnError = { retryHook },
 },
 });
 }
}

Each time the operation fails, the hook receives the new error plus all previous attempts’ errors (newest first). The hook returns true or false to tell Pulumi whether to retry. If you return false, the program fails as normal with the most recent error. With that information, you can implement many failure models:

Use the number of errors to implement backoff—for example, wait one second on the first failure, two seconds on the second, and so on.
For known-intermittent resources, always retry once before failing.
Inspect error text to retry only for specific conditions (as in the example) and fail fast for others.

The callback runs in your language of choice, so you have full control over how failures are handled.

Next steps

This feature is fully supported in our Node, Python, Go, and .NET SDKs as of v3.219.0. For more information, see the hooks documentation.

Java and YAML do not support resource hooks.

Thanks for reading, and feel free to reach out with any questions via GitHub, X, or our Community Slack.

Introducing the Terraform State Provider for Pulumi ESC

Claire Gaestel — Fri, 13 Feb 2026 00:00:00 +0000

Many organizations have years of infrastructure built and managed with Terraform. Outputs such as VPC IDs, subnet lists, database endpoints, and cluster names are the connective tissue between infrastructure layers. Getting those values into other tools and workflows often means manual copy-paste, wrapper scripts, or brittle glue code.

The terraform-state provider for Pulumi ESC helps bridge that gap. It reads outputs directly from your Terraform state files and makes them available as first-class values in your ESC environments — no scripts, no duplication, no drift. Any output marked as sensitive in your Terraform state is automatically treated as a secret in ESC. If you’ve used pulumi-stacks to read outputs from Pulumi stacks, this is the same idea for Terraform.

How it works

The terraform-state provider uses fn::open::terraform-state to read from a Terraform state file and surface its outputs as ESC values. Here’s an example that reads from an S3 backend, using the aws-login provider for credentials, and exports a KUBECONFIG for an EKS cluster managed by Terraform:

values:
 terraform:
 fn::open::terraform-state:
 backend:
 s3:
 login:
 fn::open::aws-login:
 oidc:
 roleArn: arn:aws:iam::123456789012:role/esc-oidc
 sessionName: pulumi-environments-session
 bucket: my-terraform-state-bucket
 key: path/to/terraform.tfstate
 region: us-west-2
 files:
 KUBECONFIG: ${terraform.outputs.kubeconfig}

Once the environment is opened, terraform.outputs contains every output from the Terraform state. In this example we take the kubeconfig output from a Terraform-managed EKS cluster and project it as a file, so any tool that reads KUBECONFIG - kubectl, helm, Pulumi - just works. You can also reference outputs in pulumiConfig to pass values like VPC IDs and subnet lists directly into Pulumi stacks.¹

Terraform Cloud support

If your state lives in Terraform Cloud (or any compatible remote backend), the provider supports that too:

values:
 terraform:
 fn::open::terraform-state:
 backend:
 remote:
 organization: my-terraform-org
 workspace: my-workspace
 token:
 fn::secret: tfc-token-value
 pulumiConfig:
 vpcId: ${terraform.outputs.vpc_id}
 subnetIds: ${terraform.outputs.subnet_ids}

You can point it at any Terraform Cloud-compatible backend by setting the optional hostname property.

Get started

Check out the full terraform-state provider documentation for the complete reference.

You can also consume Terraform outputs directly in a Pulumi program with the Pulumi Terraform provider. ↩︎

Schema Validation Comes to Pulumi ESC with fn::validate

Pablo Terradillos — Thu, 12 Feb 2026 11:00:00 -0300

Pulumi ESC environments can now validate configuration values against JSON Schema with the new fn::validate built-in function. Invalid configurations are caught immediately when you save, preventing misconfigurations from reaching your deployments.

Configuration errors are often discovered too late during deployment or, worse, in production. With fn::validate, you define validation rules directly in your environment, and ESC enforces them at save time. If a value doesn’t match its schema, the environment cannot be saved until the issue is resolved.

How it works

The fn::validate function takes a JSON Schema and a value. If the value conforms to the schema, it passes through unchanged. If not, ESC raises a validation error.

values:
 port:
 fn::validate:
 schema: { type: number, minimum: 1, maximum: 65535 }
 value: 8080

This validates that port is a number between 1 and 65535. The evaluated result is simply 8080.

Validating objects with required fields

For complex configurations, you can enforce structure and required fields:

values:
 database:
 fn::validate:
 schema:
 type: object
 properties:
 host: { type: string }
 port: { type: number }
 name: { type: string }
 required: [host, port, name]
 value:
 host: "db.example.com"
 port: 5432
 name: "myapp"

If any required field is missing or has the wrong type, the environment cannot be saved.

Reusing schemas across environments

Define schemas once and reference them across multiple environments. Using the environments built-in property keeps the schema out of your environment’s output:

Schema environment (my-project/schemas)

values:
 database-schema:
 type: object
 properties:
 host: { type: string }
 port: { type: number }
 required: [host, port]

Environment using the schema

values:
 database:
 fn::validate:
 schema: ${environments.my-project.schemas.database-schema}
 value:
 host: "prod-db.example.com"
 port: 5432

This pattern ensures consistent validation rules across teams and projects.

What happens when validation fails

When a value doesn’t conform to its schema, ESC returns a clear error message:

values:
 port:
 fn::validate:
 schema: { type: string }
 value: 8080

This raises: expected string, got number. The environment cannot be saved until you fix the value or update the schema.

When to use schema validation

Enable fn::validate for:

Values with specific type requirements (numbers, strings, arrays)
Objects that must have certain fields present
Numbers that must fall within a valid range
Configurations shared across multiple environments
Any value where catching errors early prevents downstream issues

Getting started

The fn::validate function is available now in all Pulumi ESC environments. Add schema validation to your existing environments or use it when creating new ones.

For more information, see the fn::validate documentation.

Registry usage insights: know which stacks run which versions

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

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

From Individual to Organizational Visibility

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

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

What You Can See

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

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

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

Find What Matters with Filters

Three filters help you find packages that need attention:

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

Combine filters with search to find specific packages.

Browse All Packages in One Place

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

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

Why This Matters

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

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

Get Started

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

Introducing envVarMappings for Provider Credentials

Guinevere Saenger — Thu, 12 Feb 2026 00:00:00 +0000

Running multiple providers with different credentials in the same Pulumi program has always been tricky. Providers expect fixed environment variable names like AWS_ACCESS_KEY_ID or ARM_CLIENT_SECRET, so if you need two AWS providers targeting different accounts, you couldn’t configure them both via environment variables.

Pulumi v3.220.0 introduces envVarMappings, a new resource option that solves this problem by letting you remap provider environment variables to custom keys.

When configuring a Pulumi provider to authenticate against a cloud provider, there are two main options available. You can set authentication values as secrets in your Pulumi.yaml config:

$ pulumi config set azure-native:clientSecret <clientSecret> --secret

Alternately, you can also use the terminal environment of where you’re running your Pulumi commands:

$ export ARM_CLIENT_SECRET=1234567

Using environment variables in this manner is especially useful in CI environments, or when you’d rather not write that auth token to state, even encrypted. But there’s currently several use cases where this breaks down, due to the hard-coded nature of the environment variables that a given provider expects.

Multiple providers or provider instances that expect different authentication values but have the same variable key

For example, if you are using multiple explicit providers targeting different Azure accounts, you were not able to set these separate configurations via environment variable.

Instead, users would have to set these values in the provider config, which may not be desirable for all use cases. Not only does the provider config write secrets to state (albeit of course encrypted), but it can also result in a noisy diff on an otherwise no-op upgrade when token rotation is used.

Remapping environment variables

For this and similar scenarios, we have a new solution for you: setting mappings of environment variable keys on your provider. The concept is as follows:

“For any environment variable that my Pulumi provider expects, I want to be able to tell the provider to use the value of a custom-defined environment variable instead.”

Example

Let’s say your provider expects ARM_CLIENT_SECRET, but you want it to use a different value than the one set in your shell. First, define a custom environment variable with your desired value:

$ export CUSTOM_ARM_CLIENT_SECRET=7654321

Then, use envVarMappings to tell the provider: “When you look for ARM_CLIENT_SECRET, read from CUSTOM_ARM_CLIENT_SECRET instead.” The mapping format is { "SOURCE_VAR": "TARGET_VAR" }:

const provider = new command.Provider("command-provider", {}, {
 envVarMappings: {
 // If CUSTOM_ARM_CLIENT_SECRET exists, provider sees the value of ARM_CLIENT_SECRET
 "CUSTOM_ARM_CLIENT_SECRET": "ARM_CLIENT_SECRET",
 },
});

provider = command.Provider("command-provider",
 opts=pulumi.ResourceOptions(
 env_var_mappings={
 # If CUSTOM_ARM_CLIENT_SECRET exists, provider sees the value of ARM_CLIENT_SECRET
 "CUSTOM_ARM_CLIENT_SECRET": "ARM_CLIENT_SECRET",
 }
 )
)

provider, err := command.NewProvider(
 ctx,
 "command-provider",
 &command.ProviderArgs{},
 pulumi.EnvVarMappings(map[string]string{
 // If CUSTOM_ARM_CLIENT_SECRET exists, provider sees the value of ARM_CLIENT_SECRET
 "CUSTOM_ARM_CLIENT_SECRET": "ARM_CLIENT_SECRET",
 }),
)

var provider = new Command.Provider("command-provider", new Command.ProviderArgs(), new CustomResourceOptions
{
 EnvVarMappings = new Dictionary<string, string>
 {
 // If CUSTOM_ARM_CLIENT_SECRET exists, provider sees the value of ARM_CLIENT_SECRET
 { "CUSTOM_ARM_CLIENT_SECRET", "ARM_CLIENT_SECRET" }
 }
});

var provider = new Provider("command-provider", ProviderArgs.Empty, CustomResourceOptions.builder()
 .envVarMappings(Map.of(
 // If CUSTOM_ARM_CLIENT_SECRET exists, provider sees the value of ARM_CLIENT_SECRET
 "CUSTOM_ARM_CLIENT_SECRET", "ARM_CLIENT_SECRET"
 ))
 .build());

resources:
 command-provider:
 type: pulumi:providers:command
 options:
 envVarMappings:
 # If CUSTOM_ARM_CLIENT_SECRET exists, provider sees the value of ARM_CLIENT_SECRET
 CUSTOM_ARM_CLIENT_SECRET: ARM_CLIENT_SECRET

You can now customize each environment variable value your provider sees by defining a new environment variable, and then mapping your provider’s defined variable to yours. Try it out with Pulumi v3.220.0 today!

For full details, see the envVarMappings documentation.

Happy coding!

Pulumi Neo Now Supports AGENTS.md

Pulumi Neo Team — Fri, 06 Feb 2026 00:00:00 +0000

Neo now reads AGENTS.md files, the open standard for giving AI coding tools context about your project. If you’re already using AGENTS.md, Neo will pick up those same instructions automatically.

The problem AGENTS.md solves

Every codebase has conventions that aren’t captured in linters or formatters. Maybe your team uses a specific naming pattern for infrastructure resources. Maybe there’s a particular way you structure tests, or commands that need to run in a certain order. These are the things you’d explain to a new team member, and now you can explain them to AI tools too.

Without something like AGENTS.md, you end up repeating yourself. Every conversation starts with “remember to use TypeScript” or “make sure you add the environment tag.” It’s tedious, and things slip through.

AGENTS.md gives these instructions a home. You write them once, commit the file to your repo, and any tool that supports the format picks them up automatically.

What to put in yours

Think about what you’d tell someone on their first day working in the codebase. How do you run tests? Are there naming conventions? Any gotchas they should know about?

Here’s an example for a Pulumi project:

# Infrastructure conventions

Run tests with `make test`. This spins up LocalStack, so Docker must be running.

Stacks are named `{service}-{region}-{env}` (e.g., `payments-us-west-2-prod`).
Only the platform team deploys to prod stacks.

All resources need these tags: `cost-center`, `team`, `environment`.

Reusable components live in `components/`. Check there before writing
something new.

There’s no required structure, just markdown. Some teams write a few lines, others write detailed guides. Start small and add things as you notice yourself repeating instructions.

How Neo handles AGENTS.md

When you point Neo at a repository, it reads any AGENTS.md file it finds and applies those instructions to its work. You don’t need to mention the file or remind Neo about your conventions.

If you have a monorepo, you can put AGENTS.md files in subdirectories too. Neo uses the nearest one to wherever it’s working, so you can have general instructions at the root and more specific ones in subpackages.

Your instructions in conversation always take precedence, so you can override the file when you need to. If you’ve also set up Custom Instructions at the organization level, Neo applies those first, then AGENTS.md on top.

Works with the tools you’re already using

AGENTS.md is an open format supported by most AI coding tools: Cursor, Windsurf, GitHub Copilot, Zed, and now Neo. If your team uses different tools for different tasks, they’ll all follow the same project conventions without any extra configuration.

The format is managed by the Agentic AI Foundation under the Linux Foundation, and it’s already in use in over 60,000 open source projects. See agents.md for the full specification.

Get started

Add an AGENTS.md file to your repository and Neo will start using it on your next task. For more on configuring Neo, including organization-wide Custom Instructions and Slash Commands, see the Settings documentation.

Announcing OpenAPI support for the Pulumi Cloud REST API

Davide Massarenti — Thu, 05 Feb 2026 00:00:00 +0000

We’re thrilled to announce that the Pulumi Cloud REST API is now described by an OpenAPI 3.0 specification, and we’re just getting started.

This is a feature that has been a long time coming. We have heard your requests for OpenAPI support loud and clear, and we’re excited to share that not only do we have a published specification for consumption, but our API code is now built from this specification as well. Moving forward, this single source of truth unlocks better tooling, tighter integration, and a more predictable API experience for everyone.

You can fetch the spec directly from the API at runtime or use it for client generation, validation, and documentation, all from one machine-readable contract.

A single contract for the Pulumi Cloud REST API

The Pulumi Cloud API powers the Pulumi CLI, the Pulumi Console, and third-party integrations. Until now, there was no single, published machine-readable description of that API. We’ve changed that. The API is now defined and served as a standard OpenAPI 3.0.3 document.

Runtime discovery: You can retrieve the spec from the API itself, so your tooling always sees the same surface the service implements.
Client generation: Use your favorite OpenAPI tooling (e.g. OpenAPI Generator, Swagger Codegen) to generate API clients in the language of your choice.
Validation and testing: Validate requests and responses, or build mocks and tests, from the same spec the service uses.
Documentation: The spec is the source of truth, not a separate, hand-maintained API doc that can drift from reality. Load the spec into Swagger UI, Redoc, or another viewer to browse the Pulumi Cloud API interactively.

How to get the spec

Send a GET request to:

https://api.pulumi.com/api/openapi/pulumi-spec.json

No authentication is required. The response is the OpenAPI 3.0 document for the Pulumi Cloud API, describing the supported, documented API surface.

Source of truth and stability

We do not hand-write the OpenAPI spec. We generate it from the same API definition that drives our backend and console code. When we add or change API routes or models, we regenerate the spec so the published document stays in sync with what the service actually implements. That gives you a clear, stable contract for the Pulumi Cloud API.

What we are building next

We are using this spec as the foundation for our own tooling, and have plans to continue leveraging the spec in our toolchain long-term.

CLI: We plan to drive the Pulumi CLI’s API client from the OpenAPI spec so that CLI and API stay in lockstep.
Pulumi Service Provider: We are also building towards day 1 updates to the Pulumi Service Provider so that new and changed API resources are generated from the spec and ship in sync with the service.
Docs Enhancements: Although you can load the spec using Swagger UI for your own browsing, we are intent on shipping enhancements to our public REST API docs that will keep them up-to-date according to the OpenAPI spec.

As we ship those updates, you will get a single source of truth from API to CLI to provider.

If you have questions or feedback about the OpenAPI spec or the Pulumi Cloud API, reach out in our Community Slack or open an issue in the Pulumi repository. We’re excited to see what you build with it.

Neo: Share Tasks for Collaborative AI Infrastructure Operations

Pulumi Neo Team — Wed, 04 Feb 2026 00:00:00 +0000

Neo shows its work, but until now that context was only viewable by the user that initiated the conversation. When you wanted a teammate’s input on a decision Neo made, you had to describe it in Slack or screenshot fragments of the conversation. Today we’re introducing task sharing: share a read-only view of any Neo task with anyone in your organization, full context preserved.

To share a Neo task, click the share button to generate a read-only link, then send it to a teammate. They see the complete picture: the original prompt, Neo’s reasoning process, the actions it took, and the outcome. Instead of writing up what happened and losing detail in the retelling, you share the task itself.

We built this with security as a core constraint. The original task system enforced strict RBAC, ensuring users could only see and act on resources they had permission to access. Task sharing preserves these guarantees. Viewers can see the conversation with Neo, but they cannot trigger any actions, and links within the shared task to stacks or resources still enforce the viewer’s existing permissions.

The feature is available now. The next time you want a second opinion or need to show a colleague how you solved something, share the task. You’re no longer working alone.

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

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

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

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

What are agent skills?

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

Available Pulumi skills

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

Authoring skills

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

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

Migration skills

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

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

How to install

Claude Code plugin marketplace

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

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

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

Universal installation

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

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

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

Using skills

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

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

/pulumi-terraform-to-pulumi

Or describe what you need in natural language:

“Help me migrate this CDK application to Pulumi”

“Review this Pulumi code for best practices issues”

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

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

Get started

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

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

Manage Cloud Visibility and Governance with Infrastructure as Code

Pulumi Insights Team — Mon, 26 Jan 2026 09:00:00 -0800

Do you know what cloud resources are running in your environment right now? Many organizations struggle to maintain visibility across their cloud estate, especially for resources created outside of infrastructure as code. Without complete visibility, you can’t enforce compliance, optimize costs, or identify security risks.

Today, we’re excited to announce new resources in the Pulumi Service Provider that solve this problem by enabling you to discover all cloud resources and enforce governance policies programmatically using infrastructure as code.

With these new resources, you can:

Discover all cloud resources across AWS, Azure, GCP, Kubernetes, or OCI environments, including resources not managed by Pulumi
Import discovered resources into Pulumi management using Visual Import to bring unmanaged infrastructure under IaC control
Enforce compliance at scale by organizing resources into Policy Groups and applying policy packs
Automate governance workflows by managing everything through code, enabling GitOps and CI/CD integration

What’s New

The Pulumi Service Provider now includes three new resources for managing cloud visibility and governance:

Resource	Description
`InsightsAccount`	Configures cloud provider scanning for resource discovery
`PolicyGroup`	Organizes stacks or cloud accounts for policy enforcement
`getPolicyPacks` / `getPolicyPack`	Data sources for querying available policy packs

Let’s explore each of these in detail.

Insights Accounts: Discover Your Cloud Resources

An InsightsAccount connects Pulumi Cloud to your cloud provider, enabling automated scanning and discovery of all resources in your environment. This gives you complete visibility into your cloud estate, including resources that aren’t managed by Pulumi.

Key Features

Multi-cloud support: Scan AWS, Azure, GCP, Kubernetes, and OCI environments
Scheduled scanning: Configure daily automated scans or trigger them on-demand
Resource tagging: Organize your accounts with custom tags

Example: Creating an AWS Insights Account

name: insights-example
runtime: yaml
resources:
 # ESC environment with AWS credentials
 aws-credentials:
 type: pulumiservice:Environment
 properties:
 organization: my-org
 project: insights
 name: aws-credentials
 yaml:
 fn::stringAsset: |
 values:
 aws:
 login:
 fn::open::aws-login:
 oidc:
 roleArn: arn:aws:iam::123456789012:role/PulumiInsightsRole
 sessionName: pulumi-insights
 environmentVariables:
 AWS_REGION: us-west-2

 # Insights account for AWS scanning
 aws-insights:
 type: pulumiservice:InsightsAccount
 properties:
 organizationName: my-org
 accountName: production-aws
 provider: aws
 environment: insights/aws-credentials
 scanSchedule: daily
 providerConfig:
 regions:
 - us-west-2
 - us-east-1
 tags:
 environment: production
 team: platform

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

// ESC environment with AWS credentials
const awsCredentials = new pulumiservice.Environment("aws-credentials", {
 organization: "my-org",
 project: "insights",
 name: "aws-credentials",
 yaml: new pulumi.asset.StringAsset(`
values:
 aws:
 login:
 fn::open::aws-login:
 oidc:
 roleArn: arn:aws:iam::123456789012:role/PulumiInsightsRole
 sessionName: pulumi-insights
 environmentVariables:
 AWS_REGION: us-west-2
`),
});

// Insights account for AWS scanning
const awsInsights = new pulumiservice.InsightsAccount("aws-insights", {
 organizationName: "my-org",
 accountName: "production-aws",
 provider: "aws",
 environment: pulumi.interpolate`${awsCredentials.project}/${awsCredentials.name}`,
 scanSchedule: "daily",
 providerConfig: {
 regions: ["us-west-2", "us-east-1"],
 },
 tags: {
 environment: "production",
 team: "platform",
 },
});

import pulumi
import pulumi_pulumiservice as pulumiservice

# ESC environment with AWS credentials
aws_credentials = pulumiservice.Environment("aws-credentials",
 organization="my-org",
 project="insights",
 name="aws-credentials",
 yaml=pulumi.StringAsset("""
values:
 aws:
 login:
 fn::open::aws-login:
 oidc:
 roleArn: arn:aws:iam::123456789012:role/PulumiInsightsRole
 sessionName: pulumi-insights
 environmentVariables:
 AWS_REGION: us-west-2
"""))

# Insights account for AWS scanning
aws_insights = pulumiservice.InsightsAccount("aws-insights",
 organization_name="my-org",
 account_name="production-aws",
 provider="aws",
 environment=pulumi.Output.concat(aws_credentials.project, "/", aws_credentials.name),
 scan_schedule="daily",
 provider_config={
 "regions": ["us-west-2", "us-east-1"],
 },
 tags={
 "environment": "production",
 "team": "platform",
 })

package main

import (
 "github.com/pulumi/pulumi-pulumiservice/sdk/go/pulumiservice"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 // ESC environment with AWS credentials
 awsCredentials, err := pulumiservice.NewEnvironment(ctx, "aws-credentials", &pulumiservice.EnvironmentArgs{
 Organization: pulumi.String("my-org"),
 Project: pulumi.String("insights"),
 Name: pulumi.String("aws-credentials"),
 Yaml: pulumi.NewStringAsset(`
values:
 aws:
 login:
 fn::open::aws-login:
 oidc:
 roleArn: arn:aws:iam::123456789012:role/PulumiInsightsRole
 sessionName: pulumi-insights
 environmentVariables:
 AWS_REGION: us-west-2
`),
 })
 if err != nil {
 return err
 }

 // Insights account for AWS scanning
 _, err = pulumiservice.NewInsightsAccount(ctx, "aws-insights", &pulumiservice.InsightsAccountArgs{
 OrganizationName: pulumi.String("my-org"),
 AccountName: pulumi.String("production-aws"),
 Provider: pulumi.String("aws"),
 Environment: pulumi.Sprintf("%s/%s", awsCredentials.Project, awsCredentials.Name),
 ScanSchedule: pulumi.String("daily"),
 ProviderConfig: pulumi.Map{
 "regions": pulumi.ToStringArray([]string{"us-west-2", "us-east-1"}),
 },
 Tags: pulumi.StringMap{
 "environment": pulumi.String("production"),
 "team": pulumi.String("platform"),
 },
 })
 if err != nil {
 return err
 }

 return nil
 })
}

Policy Groups: Enforce Compliance at Scale

A PolicyGroup lets you organize resources and apply policy packs for compliance enforcement. Policy Groups support two entity types: Stacks and Accounts.

You can configure policy groups in two modes:

Audit mode: Reports policy violations without blocking operations. This supports both Stacks and Accounts.
Preventative mode: Blocks operations that violate policies. This mode is only available for Stacks.

Example: Stack-Based Policy Group

Apply compliance policies to your Pulumi stacks:

name: policy-group-example
runtime: yaml
resources:
 production-policies:
 type: pulumiservice:PolicyGroup
 properties:
 name: production-compliance
 organizationName: my-org
 entityType: stacks
 mode: preventative
 stacks:
 - name: production
 routingProject: my-app
 - name: staging
 routingProject: my-app
 policyPacks:
 - name: cis-aws
 displayName: CIS AWS Foundations Benchmark
 version: 1
 versionTag: "1.5.0"

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

const productionPolicies = new pulumiservice.PolicyGroup("production-policies", {
 name: "production-compliance",
 organizationName: "my-org",
 entityType: "stacks",
 mode: "preventative",
 stacks: [
 { name: "production", routingProject: "my-app" },
 { name: "staging", routingProject: "my-app" },
 ],
 policyPacks: [
 {
 name: "cis-aws",
 displayName: "CIS AWS Foundations Benchmark",
 version: 1,
 versionTag: "1.5.0",
 },
 ],
});

Example: Account-Based Policy Group

Apply compliance policies to your cloud accounts for resource governance:

name: insights-policy-group
runtime: yaml
resources:
 # Insights account
 aws-insights:
 type: pulumiservice:InsightsAccount
 properties:
 organizationName: my-org
 accountName: production-aws
 provider: aws
 environment: insights/aws-credentials

 # Policy group targeting the Insights account
 cloud-compliance:
 type: pulumiservice:PolicyGroup
 properties:
 name: cloud-resource-compliance
 organizationName: my-org
 entityType: accounts
 mode: audit
 accounts:
 - ${aws-insights.accountName}
 policyPacks:
 - name: aws-security-best-practices
 displayName: AWS Security Best Practices
 version: 2

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

// Insights account
const awsInsights = new pulumiservice.InsightsAccount("aws-insights", {
 organizationName: "my-org",
 accountName: "production-aws",
 provider: "aws",
 environment: "insights/aws-credentials",
});

// Policy group targeting the Insights account
const cloudCompliance = new pulumiservice.PolicyGroup("cloud-compliance", {
 name: "cloud-resource-compliance",
 organizationName: "my-org",
 entityType: "accounts",
 mode: "audit",
 accounts: [awsInsights.accountName],
 policyPacks: [
 {
 name: "aws-security-best-practices",
 displayName: "AWS Security Best Practices",
 version: 2,
 },
 ],
});

Querying Policy Packs

Use the getPolicyPacks and getPolicyPack data sources to discover available policy packs in your organization:

name: policy-packs-query
runtime: yaml
variables:
 # List all available policy packs
 availablePacks:
 fn::invoke:
 function: pulumiservice:getPolicyPacks
 arguments:
 organizationName: my-org
 return: policyPacks

outputs:
 policyPacks: ${availablePacks}

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

// List all available policy packs
const availablePacks = pulumiservice.getPolicyPacksOutput({
 organizationName: "my-org",
});

export const policyPacks = availablePacks.policyPacks;

Getting Started

To start using these new resources:

Update the Pulumi Service Provider to the latest version:

npm install @pulumi/pulumiservice@latest

pip install --upgrade pulumi-pulumiservice

go get github.com/pulumi/pulumi-pulumiservice/sdk/go/pulumiservice@latest

dotnet add package Pulumi.PulumiService

No package installation needed for YAML - just use the resources directly.

Learn More

We’re excited to see how you use these new capabilities to improve visibility and governance across your cloud infrastructure. As always, we welcome your feedback in our Community Slack or on GitHub.

New in Pulumi IaC: `replacementTrigger` Resource Option

Tom Harding — Thu, 22 Jan 2026 00:00:00 +0000

Pulumi IaC gives us a declarative interface to updates. When we perform an update, Pulumi calculates the difference between your currently deployed infrastructure and what is being proposed, then deploys only what is required to migrate from the old state to the new state. Normally, this is exactly what we want: we minimize the amount of work required to perform the update, and don’t recreate anything unnecessarily. However, every now and then, we want to override this behavior.

Recently, we talked about the new replaceWith option, which allows us to tell Pulumi that any replacement of one resource should always trigger a replacement of another (for example, if the database is replaced, we should replace our application server). Today, we’re going to take this idea one step further and talk about another new feature that gives us even more control over this process: replacement triggers.

Forcing replacements

Let’s imagine we have a resource that, upon creation, generates some private keys. If that’s all the resource does, it probably isn’t ever going to change as far as Pulumi’s concerned: we wanted the resource before, and we want it after, so there is no change and no need to replace the resource that is already live. Now, let’s imagine that we want to cycle these private keys every month. How do we tell Pulumi that, if this update happens more than two weeks after the last time this resource was created, we want to recreate it?

As another example, perhaps we want to replace a resource every time some external version number is bumped. Let’s imagine a documentation server may need to be replaced every time a new version of an API is made available. We could use the --replace flag each time, but this process is error-prone to do manually, and would incur a maintenance burden to automate.

Defining replacement triggers

In essence, a replacement trigger is just a value attached to the resource as metadata. However, whenever this value changes between updates, it will trigger a replace operation on the given resource, regardless of whether anything else has changed.

Let’s take our previous example: we want something to be replaced every month. With replacement triggers, we can solve this by representing the current year and month as a string:

...

const today = new Date()

const keyManager = new KeyManagerResource("key-manager", {}, {
 replacementTrigger: today.getMonth() + '-' + today.getFullYear()
});

...

...
from datetime import datetime

today = datetime.now()
trigger = f"{today.month}-{today.year}"

key_manager = KeyManagerResource("key-manager", {},
 opts=pulumi.ResourceOptions(replacement_trigger=trigger))

...

...

today := time.Now()
trigger := fmt.Sprintf("%d-%d", int(today.Month()), today.Year())

keyManager, err := NewKeyManagerResource(ctx, "key-manager", &KeyManagerResourceArgs{},
 pulumi.ReplacementTrigger(pulumi.Any(trigger)))

...

...

var today = LocalDate.now();
var trigger = String.format("%d-%d", today.getMonthValue(), today.getYear())

var keyManager = new KeyManagerResource("key-manager",
 KeyManagerResourceArgs.Empty,
 CustomResourceOptions.builder()
 .replacementTrigger(Output.of(trigger))
 .build());

...

...

var today = DateTime.Now;
var trigger = $"{today.Month}-{today.Year}";

var keyManager = new KeyManagerResource("key-manager", new KeyManagerResourceArgs(),
 new CustomResourceOptions
 {
 ReplacementTrigger = Output.Create(trigger)
 });

...

When we run this update for the first time, the replacement trigger will be persisted to the Pulumi state. Each time we run an update, we’ll re-calculate the date string, and compare it against the current string. Finally, when we run the update again next month, and the date string no longer matches, our key-manager will be replaced and our new keys will be generated!

Next steps

This feature is fully supported across all our SDKs as of v3.215.0. For more information about resource options, see the resource options documentation.

Thanks for reading, and feel free to reach out with any questions via GitHub, X, or our Community Slack.

Neo: Zero-downtime migration from CDK, Terraform & Azure ARM

Pulumi Neo Team — Wed, 21 Jan 2026 00:00:00 +0000

The barrier to migrating to Pulumi has always been the infrastructure you already have. Your existing resources can’t be disrupted, and manually importing them into a new tool is risky and time-consuming. Today, we’re excited to share how Neo removes this barrier entirely with automated, zero-downtime migration to Pulumi from AWS CDK, AWS CloudFormation, Terraform, CDKTF, and Azure ARM templates.

Why IaC migrations are hard

The promise of Infrastructure as Code is that your code perfectly describes your running infrastructure. But switching IaC tools breaks this promise in dangerous ways.

When you rewrite your infrastructure code in a new tool, you have two choices, both problematic. You can destroy and recreate all your resources to match the new code, accepting downtime and risk. Or you can try to import existing resources, which requires perfect knowledge of how every resource maps between the old and new systems. Many teams get stuck here, wanting Pulumi’s modern platform but unable to safely make the switch.

Neo’s insight: State knowledge enables perfect migrations

The key to safe migration isn’t just converting code - it’s understanding the complete relationship between your existing IaC tool’s state and your actual cloud resources. Each IaC tool maintains this relationship differently: CDK through CloudFormation stacks, Terraform/CDKTF through state files, and ARM through Azure deployments. But they all have complete knowledge of what they manage.

Neo leverages this existing state knowledge to orchestrate perfect resource transitions. Instead of asking you to manually find resource IDs and construct migration commands, Neo reads your current tool’s state, discovers every resource’s physical identity, and brings them under Pulumi management. This isn’t just automation - it’s using the source tool’s own knowledge against the migration problem.

In practice, this means Neo can bridge the gap between how tools name resources and where they actually live. A Lambda function that CDK knows as OrderHandler9I0J1K2L actually exists in AWS as my-app-OrderHandler-9I0J1K2L, while a Terraform resource at address aws_instance.web[2] maps to EC2 instance i-0abc123def456. Neo understands these mappings and handles the complex cases like composite IDs (FunctionName|StatementId), resource references, and dependency chains that must be migrated in order.

Because Neo uses the source tool’s own state knowledge, your infrastructure doesn’t change at all during migration. Not a single resource is modified, recreated, or even touched. We’re simply transferring ownership from one IaC tool to another.

This approach delivers three critical guarantees:

Zero downtime: Resources are never deleted or recreated
Zero risk: Since nothing changes, you can abandon the migration at any point without consequence
Zero surprises: Preview confirms no infrastructure changes before you commit

Migration in action: Four tools, one approach

Neo adapts its migration strategy to each tool’s unique characteristics while maintaining the same zero-downtime guarantee. Let’s explore how Neo handles migrations from each major IaC tool.

AWS CDK to Pulumi

For teams using AWS CDK, Neo leverages the CloudFormation layer that underpins CDK deployments. CDK’s architecture actually makes migration straightforward: since CDK synthesizes to CloudFormation templates, Neo can read the deployed stacks directly to understand every resource and its configuration. For detailed migration steps, see our CDK migration guide.

The challenge with CDK migrations isn’t the CloudFormation layer - it’s the cryptic resource naming. CDK generates logical IDs like OrdersTableA7B2C3D4 that map to physical resources with completely different names. These mappings are buried in CloudFormation metadata, and getting them wrong means either orphaning resources or accidentally creating duplicates. Neo navigates this complexity by reading CloudFormation’s own stack outputs and resource metadata, discovering the exact physical ID for every logical resource.

CDK also introduces complexity through its construct hierarchy. A single high-level construct might expand into dozens of CloudFormation resources, each with dependencies and references to others. Neo preserves these relationships during migration, ensuring that IAM roles still reference the right Lambda functions, API Gateway deployments still point to the correct stages, and security groups maintain their exact rules. The migration completes with your infrastructure unchanged and Pulumi’s preview confirming zero modifications.

Start a Neo task Migrate your CDK application

AWS CloudFormation to Pulumi

For teams using CloudFormation directly (rather than through CDK), Neo provides a streamlined migration path. CloudFormation stacks contain complete resource metadata - every resource’s logical ID maps to a physical resource in AWS, and CloudFormation tracks these relationships in its stack state. Neo reads this state directly to build a complete picture of your infrastructure. For detailed migration steps, see our CloudFormation migration guide.

The main challenge with CloudFormation migrations is the template language itself. CloudFormation templates use intrinsic functions like !Ref, !GetAtt, and !Sub that create implicit dependencies between resources. A security group might reference a VPC using !Ref MyVpc, while a Lambda function’s role uses !GetAtt LambdaRole.Arn. Neo evaluates these expressions against the actual deployed stack to resolve every reference to its concrete value.

CloudFormation also supports features like conditionals, mappings, and nested stacks that add layers of indirection. Neo handles these by examining what actually got deployed rather than trying to interpret every possible template path. The result is Pulumi code that manages your exact infrastructure configuration - not a theoretical interpretation of your template. The migration completes with pulumi preview confirming zero changes to your running resources.

Start a Neo task Migrate your CloudFormation stack

Terraform to Pulumi

Terraform and CDKTF migrations require two transformations: converting state to establish Pulumi’s connection to your resources, and transforming HCL configuration into Pulumi code. The state conversion is direct - Neo reads your Terraform state and converts it into Pulumi state, preserving the mappings between resource names and cloud IDs. This ensures Pulumi knows that aws_instance.web[2] corresponds to EC2 instance i-0abc123def456.

The code transformation analyzes your HCL to generate equivalent Pulumi code. Neo handles Terraform patterns like count and for_each loops, module structures, and resource dependencies, recreating them idiomatically in Pulumi. The generated code manages your existing infrastructure without modifications - pulumi preview confirms zero changes. For complete migration instructions, see our Terraform migration guide.

Start a Neo task Migrate your Terraform application

Azure ARM to Pulumi

ARM templates present unique migration challenges. Unlike CDK and Terraform, which maintain clear separation between code and state, ARM templates blur this line. The template is both the definition and, through deployment history, part of the state tracking. ARM’s template expression language, with its concat functions and resource ID constructors, makes it difficult to determine what resources actually exist until deployment time. For step-by-step migration guidance, see our ARM migration guide.

Neo orchestrates ARM migrations through intelligent AI-driven conversion. When an ARM template uses functions like concat(parameters('appName'), '-plan'), the conversion process evaluates these expressions using the actual parameter values to generate the correct resource names. Azure resource IDs follow predictable patterns - subscription IDs, resource groups, providers, and resource names - and Neo ensures these are correctly brought under Pulumi management using inline resource specifications directly in the generated code.

The biggest challenge with ARM migrations is handling the implicit dependencies and resource provider quirks. An App Service might implicitly create a service plan, a SQL database requires a server that might be defined in a linked template, and child resources like application settings need separate migration steps. Neo understands these Azure-specific patterns and generates the appropriate Pulumi code to manage every resource. The migration completes with a zero-diff preview, confirming your exact Azure configuration is preserved while giving you a more maintainable, type-safe way to manage it going forward.

Start a Neo task Migrate your ARM template

The architecture powering it all

While each tool requires specific handling, Neo’s core architecture remains consistent:

Universal orchestration layer

Neo acts as the intelligent migration coordinator, regardless of source tool:

Credential verification: Ensures proper cloud credentials are configured in Pulumi ESC
Resource inventory: Builds a complete catalog of existing resources
Conversion orchestration: Manages the code transformation
State migration: Brings existing resources under Pulumi management
Audit trail generation: Creates comprehensive migration reports

Unified state management engine

The state management engine works consistently across all tools:

Maps source resource IDs to Pulumi’s state management
Handles complex and composite resource identifiers
Provides fallback strategies for edge cases
Ensures idempotent operations

Human oversight

While Neo automates the heavy lifting, we maintain human checkpoints:

Review generated code before migrating resources
Verify preview shows zero changes
Approve the resulting pull request

What this means for your team

Migration friction no longer locks you into your current IaC tool. If you want Pulumi’s programming model, policy engine, and multi-cloud support, Neo gets you there without disrupting your infrastructure.

Ready to migrate? Check out our migration guides for CDK, CloudFormation, Terraform, or Azure ARM. Join us in the Pulumi Community Slack or reach out to your account team for a guided migration session.

Introducing the new and improved ESC Editor

Sean Yeh — Thu, 15 Jan 2026 08:00:00 -0500

Pulumi ESC is Pulumi Cloud’s centralized solution for managing secrets and configuration across every vault and cloud provider you use. It helps teams secure their configuration while adopting modern best practices like short-lived credentials with OIDC and automated secret rotation.

Whether you’re configuring Pulumi programs, powering applications and services, or managing credentials for tools like the AWS CLI, ESC provides a single, consistent way to do it safely and at scale.

Behind the scenes, ESC integrates with multiple cloud providers and secret managers, supports composable environments, and offers rich built-in functions, from simple value transformations to encoding files as Base64.

With this level of power, usability matters more than ever. That’s why today we’re introducing the new and improved Pulumi ESC Web Editor, designed to make managing secrets and configuration easier, faster, and more intuitive.

Today, you can create and manage your Pulumi ESC configuration in multiple ways, such as using the CLI set and edit commands, or through our VS Code extension. For many users, however, their first experience with ESC happens in the Pulumi Cloud Console.

Based on feedback from users of both our YAML Document view and Table view in the Console, we’ve been working hard to create a new and improved unified editor experience that makes ESC even easier to work with. One of the most notable improvements is a brand new Inspect tab that lets you easily edit secrets and gain deeper insights into your configuration. With this new UI, you can now freely switch between writing YAML and using rich UI elements to manipulate your environment—and the editor keeps everything in sync, with clear, in-context information about what you’re doing and what’s possible at every step.

Let’s explore some of these use cases!

Adding and editing secrets

Adding secrets is now as simple as selecting Secret from the Add new menu.

The Inspect tab lets you view and edit your secret securely, automatically encrypting it as ciphertext in your environment definition. No more worrying about accidentally exposing sensitive values!

Using providers and built-in functions

ESC offers a large library of providers and built-in functions to use in your environment. The new editor makes discovering and using them effortless.

When you add a provider or function, the editor inserts it with example values to get you started quickly. The Inspect tab provides instant access to documentation, so you can more easily configure the integrations.

Exporting configurations

Consuming your configuration where you need it is now easier than ever. The Export menu in the Inspect sidebar lets you quickly expose values as Pulumi config for your stacks, or as environment variables in your shell.

Conclusion

The new Pulumi ESC Editor brings together the best of both worlds: the power of the YAML editor with the ease of UI controls. Try it out today in the Pulumi Cloud Console and let us know what you think!

Pulumi IAM Now Available for Self-Hosted Pulumi Cloud

Davide Massarenti — Wed, 14 Jan 2026 11:18:00 +0000

We’re excited to announce that Pulumi Identity and Access Management (IAM) is now available for self-hosted instances of Pulumi Cloud. This foundational security capability brings the same enterprise-grade access management we launched for Pulumi Cloud SaaS to organizations running Pulumi on their own infrastructure.

Enterprise Security for Self-Hosted Deployments

Self-hosted Pulumi Cloud customers can now leverage the full power of Custom Roles and Granular Access Tokens to implement Zero Trust security principles and least privilege access controls within their own environments. This means you can:

Define Custom Permissions with fine-grained scopes (e.g., stack:delete, environment:read) tailored to your organization’s security requirements.
Create Custom Roles by combining these permissions with specific Pulumi entities (Stacks, Environments, etc.).
Generate Scoped Organization Access Tokens that are precisely limited to the permissions defined in their associated roles, dramatically reducing the blast radius if credentials are compromised.

Secure Automation for On-Premises Infrastructure

This release is powerful for self-hosted Pulumi Cloud deployments where security and compliance requirements are often even more stringent. You can now:

Implement Least Privilege CI/CD: Scope pipeline tokens to only the actions and resources they absolutely need, ensuring your automation follows the same security standards as your infrastructure.
Enhance Compliance Posture: Demonstrate precise, auditable control over programmatic access to auditors and security teams.
Reduce Operational Risk: Limit the potential impact of compromised tokens by restricting them to specific roles and permissions.

Getting Started

Self-hosted customers can access IAM features through the same intuitive interface available in Pulumi Cloud SaaS. Navigate to Settings -> Access Management -> Roles to begin creating Custom Permissions and Custom Roles, then generate scoped Organization Access Tokens from Settings -> Access Management -> Access Tokens.

For detailed information about Pulumi IAM capabilities, including step-by-step guides and best practices, see our comprehensive announcement blog post.

Learn More

Explore the IAM & RBAC documentation to get started:

We’re committed to bringing enterprise-grade security features to all Pulumi deployments, whether in the cloud or on-premises. If you have questions or feedback, please reach out through your account representative or our GitHub repository.

Speeding up Pulumi Operations by up to 20x

Thomas Gummerer — Mon, 12 Jan 2026 18:57:55 +0200

Today we’re introducing an improvement that can speed up operations by up to 20x. At every operation, and at every step within an operation, pulumi saves a snapshot of your cloud infrastructure. This gives pulumi a current view of state even if something fails mid-operation, but it comes with a performance penalty for large stacks. Here’s how we fixed it.

Benchmarks

Before getting into the more technical details, here are a number of benchmarks demonstrating what this new experience looks like. To run the benchmarks we picked a couple of Pulumi projects: one that can be set up massively parallel, which is the worst case scenario for the old snapshot system, and another that looks a little more like a real world example. Note that we conducted all of these benchmarks in Europe, connecting to Pulumi Cloud, which runs in AWS’s us-west-2 region, so exact numbers may vary based on your location and internet connection. This should however give a good indication of the performance improvements.

We’re benchmarking two somewhat large stacks, both of which are or were used at Pulumi. The first program sets up a website using AWS bucket objects. We’re using the aws-ts-static-website example here with a small subset of the fraction from our docs site. This means we’re setting up more than 3000 bucket objects, with 3222 resources in total.

The benchmarks were measured using the time built-in command and using the best time in a best-of-three benchmark. The network traffic was measured using tcpdump, limiting the measured traffic to only the IP addresses for Pulumi Cloud. Finally, tshark was used to process the packet captures and count the bytes sent.

All the benchmarks are run with journaling off (the default experience) and with journaling on (the new experience). To begin with, let’s look at the results when creating our stack from scratch:

	Time	Bytes sent
Without journaling	58m26s	16.5MB
With journaling	02m50s	2.3MB

Now let’s have a look at what this looks like if we only change half the resources, but the remaining ones remain unchanged:

	Time	Bytes sent
Without journaling	34m49s	13.8MB
With journaling	01m45s	2.3MB

The second example is setting up an instance of the Pulumi app and API. Here we’ll have an example that’s a bit more dominated by the cost of setting up the actual infrastructure in the cloud, but we still have a very noticeable improvement in the time it takes to set up the stack.

	Time	Bytes sent
Without journaling	17m52s	18.5MB
With journaling	9m12s	5.9MB

To use this feature, you need a pulumi version newer than v3.211.0, and set the PULUMI_ENABLE_JOURNALING environment variable to true.

If you are interested in the more technical details read on!

Introduction to snapshotting

pulumi keeps track of all resources in a stack in a snapshot. This snapshot is stored in the stack’s configured backend, which is either the Pulumi Cloud or a DIY backend. Future operations on the stack then use this snapshot to figure out which resources need to be created, updated or deleted.

pulumi creates a new snapshot at the beginning and at the end of each resource operation to minimize the possibility of untracked changes even if a deployment is aborted unexpectedly (for example due to network issues, power outages, or bugs).

At the beginning of the operation, pulumi adds a new “pending operation” to the snapshot. Pending operations declare the intent to mutate a resource. If a pending operation is left in the snapshot (in other words the operation started, but pulumi couldn’t record the end of it), the next operation will try to resolve this. If we have an ID for the resource already, for example on partial updates/deletes, pulumi will try to read the resource state from the cloud and resolve it internally. If there is no ID yet, pulumi will ask the user to check the actual state of the resource. Depending on the user’s response, pulumi will either remove the operation from the snapshot or import the resource. This is because it is possible that the resource has been set up correctly or that the resource creation failed. If pulumi aborted midway through the operation, it’s impossible to know which state the resource is in.

Once an operation finishes, the pending operation is removed and the resource’s final state is recorded in the snapshot.

There’s also some additional metadata that is stored in the snapshot that is only updated infrequently.

Here’s how the snapshot looks in code. This snapshot is serialized and sent to the backend. Resources holds the list of known resource states and is updated after each operation finishes, and PendingOperations is the list of pending operations described above.

type Snapshot struct {
 Manifest Manifest // a deployment manifest of versions, checksums, and so on.
 SecretsManager secrets.Manager // the secrets manager to use when serializing this snapshot.
 Resources []*resource.State // all resources and their associated states.
 PendingOperations []resource.Operation // all currently pending resource operations.
 Metadata SnapshotMetadata // metadata associated with the snapshot.
}

Before we dive in deeper, we also need to understand a little bit about how the pulumi engine works internally. Whenever a pulumi operation is run (e.g. pulumi up, pulumi destroy, pulumi refresh etc.), the engine internally generates and executes a series of steps, to create, update, delete etc. resources. To maintain correct relationships between resources, the steps need to be executed in a partial order such that no step is executed until all of the steps it depends on have executed successfully. Steps may otherwise execute concurrently.

As each step is responsible for updating a single resource, we can generate a snapshot of the state before each step starts, and after it completes. Before each step starts, we create a pending operation, and add it to the PendingOperations list. After that step completes, we remove the pending operation from that list, and update the Resources list, either adding a resource, removing it, or updating it, depending on the kind of operation we just executed.

After this introduction, we can dive into what’s slow, how we fixed it, and some benchmarks.

Why is it slow?

To make sure the state is always as up-to-date as possible, even if there are any network hiccups/power outages etc., a step won’t start until the snapshot that includes the pending operation is confirmed to be stored in the backend. Similarly an operation won’t be considered finished until the snapshot with an updated resources list is confirmed to be stored in the backend.

To send the current state to the backend, we simply serialize it as a JSON file, and send it to the backend. However, as mentioned above, steps can be executed in parallel. If we uploaded the snapshot at the beginning and end of every step with no serialization, there would be a risk that we overwrite a new snapshot with an older one, leading to incorrect data.

Our workaround for that is to serialize the snapshot uploads, uploading one snapshot at a time. This gives us the data integrity properties we want, however it can slow step execution down, especially on internet connections with lower bandwidth, and/or high latency.

This impacts performance especially for large stacks, as we upload the whole snapshot every time, which can take some time if the snapshot is getting big. For the Pulumi Cloud backend we improved on this a little at the end of 2022. We implemented a diff based protocol, which is especially helpful for large snapshots, as we only need to send the diff between the old and the new snapshot, and Pulumi Cloud can then reconstruct the full snapshot based on that. This reduces the amount of data that needs to be transferred, thus improving performance.

However, the snapshotting is still a major bottleneck for large pulumi operations. Having to serially upload the snapshot twice for each step does still have a big impact on performance, especially if many resources are modified in parallel. Furthermore, the time spent performing textual diffs between snapshots scales in proportion to the size of the data being processed, which adds additional execution time to each operation.

Fast, but lacking data integrity?

As long as pulumi can complete its operation, there’s no need for the intermediate checkpoints. We could allow pulumi operations to skip uploading the intermittent checkpoints to the backend. This, of course, avoids the single serialization point we have sending the snapshots to the backend, and thus makes the operation much more performant.

However, it also has the serious disadvantage of compromising some of the data integrity guarantees pulumi gives you. If anything goes wrong during the update, pulumi has no notion of what happened until then, potentially leaving orphaned resources in the provider, or leaving resources in the state that no longer exist.

Neither of these solutions is very satisfying, as the tradeoff is either performance or data integrity. We would like to have our cake and eat it too, and that’s exactly what we’re doing with journaling.

Enter journaling

To achieve this, we went back to the drawing board, and asked ourselves, “What would a solution look like that’s both performant and preserves data integrity throughout the update?”.

Making that happen is possible because of three facts:

We always start with the same snapshot on the backend and the CLI.
Every step the engine executes affects only one resource.
We have a service that can reconstruct a snapshot from what is given to it.

(The third point here already hints at it, but this feature is only available and made possible by Pulumi Cloud, not on the DIY backend).

What if instead of sending the whole snapshot, or a diff of the snapshot, we could send the individual changes to the base snapshot to the service, which could then apply it, and reconstruct a full snapshot from it? This is exactly what we are doing here, in the form of what we call journal entries. Each journal entry has the following form:

const (
 JournalEntryKindBegin JournalEntryKind = 0
 JournalEntryKindSuccess JournalEntryKind = 1
 JournalEntryKindFailure JournalEntryKind = 2
 JournalEntryKindRefreshSuccess JournalEntryKind = 3
 JournalEntryKindOutputs JournalEntryKind = 4
 JournalEntryKindWrite JournalEntryKind = 5
 JournalEntryKindSecretsManager JournalEntryKind = 6
 JournalEntryKindRebuiltBaseState JournalEntryKind = 7
)

type JournalEntry struct {
 // Version of the journal entry format.
 Version int `json:"version"`
 // Kind of journal entry.
 Kind JournalEntryKind `json:"kind"`
 // Sequence ID of the operation.
 SequenceID int64 `json:"sequenceID"`
 // ID of the operation this journal entry is associated with.
 OperationID int64 `json:"operationID"`
 // ID for the delete Operation that this journal entry is associated with.
 RemoveOld *int64 `json:"removeOld"`
 // ID for the delete Operation that this journal entry is associated with.
 RemoveNew *int64 `json:"removeNew"`
 // PendingReplacementOld is the index of the resource that's to be marked as pending replacement
 PendingReplacementOld *int64 `json:"pendingReplacementOld,omitempty"`
 // PendingReplacementNew is the operation ID of the new resource to be marked as pending replacement
 PendingReplacementNew *int64 `json:"pendingReplacementNew,omitempty"`
 // DeleteOld is the index of the resource that's to be marked as deleted.
 DeleteOld *int64 `json:"deleteOld,omitempty"`
 // DeleteNew is the operation ID of the new resource to be marked as deleted.
 DeleteNew *int64 `json:"deleteNew,omitempty"`
 // The resource state associated with this journal entry.
 State *ResourceV3 `json:"state,omitempty"`
 // The operation associated with this journal entry, if any.
 Operation *OperationV2 `json:"operation,omitempty"`
 // If true, this journal entry is part of a refresh operation.
 RebuildDependencies bool `json:"isRefresh,omitempty"`
 // The secrets manager associated with this journal entry, if any.
 SecretsProvider *SecretsProvidersV1 `json:"secretsProvider,omitempty"`

 // NewSnapshot is the new snapshot that this journal entry is associated with.
 NewSnapshot *DeploymentV3 `json:"newSnapshot,omitempty"`
}

These journal entries encode all the information needed to reconstruct the snapshot from them. Each journal entry can be sent in parallel from the engine, and the snapshot will still be fully valid. All journal entries have a Sequence ID attached to them, and they need to be replayed in that order on the service side to make sure we get a valid snapshot. It is however okay to replay without journal entries that have not yet been received by the service, and whose sequence ID is thus missing. This is safe because the engine only sends entries in parallel for resources whose parents/dependencies have been fully created and confirmed by the service.

This way we make sure that the resources list is always in the correct partial order that is required by the engine to function correctly, and for the snapshot to be considered valid.

The algorithm looks as follows:

# Apply snapshot writes. This replaces the full snapshot we have on the service.
# We do this if default providers change, because we don't emit steps for that, as
# we do for the rest of the operations.
snapshot = find_write_journal_entry_or_use_base(base, journal)
# Track changes
deletes, snapshot_deletes, mark_deleted, mark_pending = set(), set(), set(), set()
operation_id_to_resource_index = {}
# Process journal entries. This is the main algorithm, that adds new resources
# to the snapshot, removes existing ones, deals with refreshes, and operations
# that update outputs.
incomplete_ops = {}
has_refresh = false
index = 0
for entry in journal:
match entry.type:
case BEGIN:
incomplete_ops[entry.op_id] = entry
case SUCCESS:
del incomplete_ops[entry.op_id]
if entry.state and entry.op_id:
resources.append(entry.state)
operation_id_to_resource_index.add(entry.op_id, index)
index++
if entry.remove_old:
snapshot_deletes.add(entry.remove_old)
if entry.remove_new:
deletes[remove_new] = true
if entry.pending_replacement:
mark_pending(entry.pending_replacement)
if entry.delete:
mark_deleted(entry.delete)
has_refresh |= entry.is_refresh
case REFRESH_SUCCESS:
del incomplete_ops[entry.op_id]
has_refresh = true
if entry.remove_old:
if entry.state:
snapshot_replacements[entry.remove_old] = entry.state
else:
snapshot_deletes.add(entry.remove_old)
if entry.remove_new:
if entry.state:
deletes[entry.remove_new] = true
else:
resources.replace(operation_id_to_resource_index(entry.remove_new), entry.state)
case FAILURE:
del incomplete_ops[entry.op_id]
case OUTPUTS:
if entry.state and entry.remove_old:
snapshot_replacements[entry.remove_old] = entry.state
if entry.state and entry.remove_new:
resources.replace(operation_id_to_resource_index(entry.remove_new), entry.state)
deletes = deletes.map(|i| => operation_id_to_resource_index[i])
# Now that we have marked all the operations, and created a new list of resources, we can
# go through them, and merge the list of new resources and old resources from the snapshot
# that remain together.
for i, res in resources:
if i in deletes:
remove_from_resources(resources, i)
# Merge snapshot resources. These resources have not been touched by the update, and will
# thus be appended to the end of the resource list. We also need to mark existing resources as
# `Delete` and `PendingReplacement` here.
for i, res in enumerate(snapshot.resources):
if i not in snapshot_deletes:
if i in snapshot_replacements:
resources.append(snapshot_replacements[i])
else:
if i in mark_deleted:
res.delete = true
if i in mark_pending:
res.pending_replacement = true
resources.append(res)
# Collect pending operations. These are stored separately from the resources list
# in the snapshot.
pending_ops = [op.operation for op in incomplete_ops.values() if op.operation]
pending_ops.extend([op for op in snapshot.pending_ops if op.type == CREATE])
# Rebuild dependencies if necessary. Refreshes can delete parents or dependencies
# of resources, without affecting the resource itself directly. We need to now remove
# these relationships to make sure the snapshot remains valid.
if has_refresh:
rebuild_dependencies(resources)

The full documentation of the algorithm can be found in our developer docs.

Rollout

pulumi state is a very central part of pulumi, so we wanted to be extra careful with the rollout to make sure we don’t break anything. We did this in a few stages:

We implemented the replay interface inside the pulumi CLI, and ran it in parallel with the current snapshotting implementation in our tests. The snapshots were then compared automatically, and tests made to fail when the result didn’t match.
Since tests can’t cover all possible edge cases, the next step was to run the journaler in parallel with the current snapshotting implementation internally. This was still without sending the results to the service. However we would compare the snapshot, and send an error event to the service if the snapshot didn’t match. In our data warehouse we could then inspect any mismatches, and fix them. Since this does involve the service in a minor way, we would only do this if the user is using the Cloud backend.
Next up was adding a feature flag for the service, so journaling could be turned on selectively for some orgs. At the same time we implemented an opt-in environment variable in the CLI (PULUMI_ENABLE_JOURNALING), so the feature could be selectively turned on by users, if both the feature flag is enabled and the user sets the environment variable. This way we could slowly start enabling this in our repos, e.g. first in the integration tests for pulumi/pulumi, then in the tests for pulumi/examples and pulumi/templates, etc.
Allow users to start opting in. If you want to opt-in with your org, please reach out to us, either on the Community Slack, or through our Support channels, and we’ll opt your org into the feature flag. Then you can begin seeing the performance improvements by setting the PULUMI_ENABLE_JOURNALING env variable to true.
Turn on the feature flag for everyone, but still require the PULUMI_ENABLE_JOURNALING env variable to be set to true. (We are here right now).
Flip the feature on by default, but still allow users to opt out using a PULUMI_DISABLE_JOURNALING env variable.

What’s next

While these performance improvements hopefully make your day to day use of pulumi quicker and more enjoyable, we’re not quite done here. We’re looking at some other performance improvements, that will hopefully speed up your workflows even more.

Introducing the Stash Resource in Pulumi IaC

Fraser Waters — Mon, 12 Jan 2026 00:00:00 +0000

We’re excited to announce the Stash resource, a new built-in Pulumi resource that lets you save arbitrary values directly to your stack’s state. Whether you need to capture a computed result, record who first deployed your infrastructure, or persist configuration that should remain stable across updates, Stash provides a simpler and more ergonomic solution.

Why Stash?

Infrastructure code often produces values that need to persist beyond a single deployment. Maybe you’re generating a random identifier that should stay consistent, tracking which team member initially set up a stack, or recording a timestamp from the first deployment. Previously, you’d need workarounds like external storage, custom resources, or careful state manipulation.

The Stash resource helps with that. It takes an input value, stores it in your stack’s state, and makes it available as an output property. The output property preserves the original value even when the input changes in subsequent deployments, making Stash perfect for “first-run” scenarios where you want to capture and preserve a value from the initial deployment.

Using Stash

Creating a Stash is straightforward. Here’s how you’d capture the username of whoever first deploys the stack (using Node.js):

import * as pulumi from "@pulumi/pulumi";
import * as os from "os"; // Node.js built-in module

const firstDeployer = new pulumi.Stash("firstDeployer", {
 input: os.userInfo().username,
});

export const originalDeployer = firstDeployer.output;

The first time this runs, both input and output will show the current user. On subsequent deployments by different users, input will update to show the new user, but output will continue returning the original deployer’s name.

Stash supports any value type—strings, numbers, objects, arrays, and nested structures. It also respects secret annotations, so if you stash a secret value, it stays encrypted in your state.

When to replace

Since Stash preserves the original value by design, updating the stored value requires a replacement. You have several options:

Use --target-replace during pulumi up:

pulumi up --target-replace urn:pulumi:dev::my-project::pulumi:index:Stash::firstDeployer

Run pulumi state taint to mark the resource for replacement:

pulumi state taint urn:pulumi:dev::my-project::pulumi:index:Stash::firstDeployer

Use the replacementTrigger resource option to automate replacements based on value changes:

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

const remoteConfig = fetch("https://example.com/my-service").then(response => response.json())

const myStash = new pulumi.Stash("myStash",
 {
 input: os.userInfo().username,
 }, {
 replacementTrigger: remoteConfig.someValue,
 }
);

export const stashedValue = myStash.output;

With replacementTrigger, when remoteConfig.someValue changes, the Stash resource will be replaced and the new input value will be captured.

Learn more

The Stash resource is available now in Pulumi v3.208.0 and later across all supported languages. Check out the Stash documentation for detailed examples in TypeScript, Python, Go, C#, and YAML.

We’d love to hear how you’re using Stash and any feedback you have on it! Share your use cases in our Community Slack or open an issue if you see any on pulumi/pulumi.

Happy hacking!

Pulumi 2025: Neo, Next-Gen Policies, and Platform Engineering at Scale

Arun Loganathan — Mon, 22 Dec 2025 00:00:00 +0000

The era of AI-accelerated development has arrived, creating both unprecedented opportunity and unprecedented challenge. Developers ship code faster than ever, but platform teams struggle to keep pace. The velocity gap threatens to become a bottleneck.

As 2025 comes to a close, let’s look back at how we addressed this challenge.

This year, we took a giant leap forward to close that gap with several major innovations, including purpose-built AI for platform engineers, next-generation policy management that transforms governance into an accelerator, and the foundation for building Internal Developer Platforms that enable self-service without sacrificing control.

Pulumi Neo: Your Newest Platform Engineer
- AI-Assisted Development Everywhere
Next-Generation Policy Management: AI-Powered Governance at Scale
Internal Developer Platform: Self-Service Infrastructure at Scale
Secrets Management: Taming Sprawl at Scale
Identity and Access Management
Pulumi IaC
The Year Ahead

Pulumi Neo: Your Newest Platform Engineer

We launched Pulumi Neo, purpose-built AI specifically designed for platform engineering challenges. Neo fundamentally changed how platform engineers work.

The problem Neo solves is critical: while AI coding assistants have accelerated developers substantially, platform teams have struggled to keep pace. Every line of code that ships faster creates new platform needs - monitoring, secrets, pipelines, compliance checks. The velocity gap between development and platform teams was widening, threatening to become a bottleneck that would slow down entire organizations.

Neo levels the playing field by giving platform engineers their own dedicated AI tool. Unlike generic AI coding assistants that lack infrastructure context, Neo deeply understands cloud environments, infrastructure as code, secrets management, and the unique challenges platform teams face. It speaks their language and works within their constraints.

What makes Neo different is how it’s built. Neo operates on top of Pulumi’s existing platform capabilities - the same IaC, ESC, and policy features you already use for governance become Neo’s operational guardrails. It automatically respects your security and policy rules, works within your governance frameworks, and maintains the audit trails and compliance controls your organization requires. This isn’t experimental AI retrofitted with infrastructure plugins - it’s enterprise-ready intelligence built from the ground up on proven foundations.

Throughout the year, we enhanced Neo with capabilities that scale your team’s expertise. Custom Instructions and Slash Commands let you encode organizational standards once and Neo applies them automatically, while turning proven prompts into reusable shortcuts anyone can use. Operating Modes give you flexible control - from full review to autonomous execution. And full Pulumi CLI integration means Neo can handle complete infrastructure workflows, from stack operations to cloud CLI commands.

AI-Assisted Development Everywhere

Beyond Neo, we brought AI assistance directly into development workflows throughout the year. The Pulumi Model Context Protocol (MCP) Server connects AI-powered code assistants with Pulumi’s CLI and registry, enabling real-time resource information without leaving your editor. Use it with GitHub Copilot, Anthropic’s Claude Code, and Cursor to accelerate resource discovery and write infrastructure code faster. We enhanced this with remote MCP server support for centralized management and CLI AI extensions for intelligent command-line assistance.

Next-Generation Policy Management: AI-Powered Governance at Scale

With Neo giving platform teams AI superpowers, we needed to ensure AI-accelerated development remained safe and compliant. The challenge isn’t detecting security issues - it’s fixing them at scale. Most policy tools stop at detection, leaving teams with overwhelming backlogs and no scalable way to remediate violations.

We ended that compromise with the next generation of Pulumi Policies. This comprehensive governance solution moves beyond detection to deliver AI-powered remediation through a two-step lifecycle:

Get Clean: We introduced the Policy Findings Hub that gives every stakeholder their needed view - leadership sees compliance scores, auditors get control-centric compliance views, and platform teams get a collaborative workspace to triage and track remediation. Combined with audit scans, you get instant compliance baselines without blocking developers. Neo integrates directly into the Policy Findings hub to automate the fix itself, generating pull requests with exact code changes needed. For unmanaged resources, Neo even generates code to import the resource into a Pulumi stack and apply the fix.

Stay Clean: We launched pre-built compliance packs for CIS, NIST, PCI, and HITRUST across AWS, Azure, and Google Cloud. These out-of-the-box policy packs let you enforce industry-standard compliance frameworks immediately without writing custom policies. They act as universal guardrails by blocking non-compliant changes during deployment. Neo can even author new custom policies - ask Neo to “create a policy that prevents overly permissive IAM roles,” and it generates the code. This is how we make AI safe to go fast.

Internal Developer Platform: Self-Service Infrastructure at Scale

Platform engineering teams face a persistent challenge: they’re constantly responding to infrastructure requests instead of building the systems that enable self-service at scale. This reactive cycle prevents platform teams from doing their most valuable work - establishing patterns, codifying standards, and creating golden paths that empower developers without sacrificing control.

We delivered the foundation to break this cycle with Pulumi IDP. Pulumi IDP provides everything platform teams need to build world-class internal developer platforms. Codify organizational standards into reusable building blocks. Give developers simple, approachable interfaces that enforce best practices automatically. Transform platform engineering from reactive ticket-taking to strategic enablement.

The key is Pulumi Private Registry, your organization’s source of truth for golden paths and platform building blocks. Private Registry provides streamlined publishing workflows and simplified discovery, making it easy to share infrastructure abstractions across your organization. Combined with our expanded public registry (now over 150 providers and 7,500 resource types), you have comprehensive options for managing infrastructure across your entire cloud estate.

What makes this powerful is next-generation Pulumi Components with true cross-language support. Author infrastructure abstractions once in your preferred language, then consume them in any supported Pulumi language - including YAML for non-programmers, and soon, HCL. Components include built-in input validation, detailed documentation, and improved error messages. This means platform teams can reach every developer in their organization regardless of language preference, scaling their expertise without scaling their team.

Secrets Management: Taming Sprawl at Scale

The proliferation of secrets across modern cloud environments creates massive security risks. Long-lived credentials pose significant vulnerabilities. Secrets scattered across systems make it nearly impossible to track usage or enforce consistent policies. And manual rotation processes are error-prone and rarely done.

2025 saw significant expansion of Pulumi ESC to address these challenges across your entire secrets ecosystem:

Automated Rotation: We launched ESC Rotated Secrets, automatically rotating credentials like AWS IAM access keys on flexible schedules. This eliminates manual rotation effort and significantly reduces vulnerability windows. We expanded this with database credential rotation for PostgreSQL and MySQL, including support for databases in private VPCs via AWS VPC Lambda connectors.

Universal Integration: We integrated ESC with the secrets management platforms you’re already using:

Snowflake - Dynamic OIDC tokens for temporary authentication plus automated RSA keypair rotation
Infisical - Dynamic OIDC login and secret fetching from the open-source secrets platform
Doppler - OIDC access tokens and centralized secret fetching

For systems without native support, we launched ESC Connect, enabling you to build simple HTTPS adapters that integrate any custom or proprietary secret source with ESC.

These integrations let you maintain existing secrets infrastructure while gaining ESC’s centralized management, audit capabilities, and governance controls. You don’t have to rip and replace - ESC works with what you have.

Better Experience: We improved ESC usability throughout the year with streamlined onboarding, approval workflows for sensitive environments, and deletion protection to prevent accidents.

Security & Trust: For organizations with strict compliance needs like HIPAA or GDPR, we launched Customer-Managed Keys (BYOK). This allows you to bring your own encryption keys (via AWS KMS) to encrypt secrets stored in ESC, giving you full control over key lifecycles and revocation.

Identity and Access Management

Modern security demands unwavering trust in your security posture. How do you empower teams to deploy rapidly without opening doors to risk or violating compliance mandates?

We launched Pulumi IAM, embedding robust, granular security directly into your cloud development lifecycle. Pulumi IAM provides the unified framework for fine-grained authorization needed to confidently manage modern cloud infrastructure:

Custom Roles: Define reusable permissions with fine-grained scopes tailored to your organization’s specific needs
Least Privilege Enforcement: Control precisely who can do what on which specific resources, minimizing the impact if credentials are compromised
Secure Automation: Generate scoped access tokens for CI/CD pipelines with only the necessary permissions, eliminating over-privileged service accounts
Zero Trust Foundation: Verify every access request and grant minimum necessary access, implementing true Zero Trust principles

This foundational capability enables true least-privilege for CI/CD pipelines, reduces blast radius if tokens are compromised, and provides the compliance evidence auditors require. Platform and security teams finally have the fine-grained control needed to scale Pulumi usage securely across enterprise organizations without sacrificing velocity.

Pulumi IaC

Platform teams need IaC tools that keep pace with rapidly evolving cloud platforms while providing operational flexibility and reliability. This year we shipped hundreds of enhancements to Pulumi’s core IaC capabilities, from major cloud provider updates to new operational primitives that give teams more control over infrastructure lifecycles.

Cloud Provider Support

Managing multi-cloud infrastructure requires comprehensive provider support that keeps pace with rapidly evolving cloud platforms. This year we shipped major provider updates:

AWS Provider 7.0 brought game-changing improvements: manage resources across multiple AWS regions with a single provider instance, enhanced IAM role chaining with better error handling, and simplified S3 resource management.

Azure Native V3 delivered a 75% reduction in SDK size while maintaining 100% Azure ARM API coverage. Faster downloads, more manageable package sizes, and improved reliability.

Google Cloud Provider 9.0 brought updated API versions, new modules for AI and Google Gemini, and expanded resource support for the latest GCP services.

Direct Terraform Module Support was one of our most requested features. Execute Terraform modules directly in Pulumi without conversion, providing a seamless migration path for module-heavy projects.

Language Support

Java SDK 1.0 GA provides first-class Java support with feature parity to other Pulumi languages, support for all current LTS Java versions, and complete Automation API support.

Infrastructure Operations

Resource Hooks was one of our most requested features. Run custom code at any point in a resource’s lifecycle - before creation, after updates, before deletion. This unlocks scenarios like validation checks before deployment, triggering external systems when infrastructure changes, and custom logging and auditing.

We also shipped dependent resource replacements, excluding specific targets from stack operations, state taint capabilities, improved refresh and destroy experience for short-lived credentials, and CLI control through environment variables.

Kubernetes Operator

The Pulumi Kubernetes Operator 2.0 reached GA with a completely rewritten, faster codebase featuring enhanced reconciliation logic, better error handling, and automatic retry for temporary failures. We continued enhancing it with version 2.3.0 adding preview mode for validating infrastructure changes and structured configuration support for GitOps workflows.

The Year Ahead

2025 was the year we gave platform engineers the tools to thrive in the age of AI-accelerated development. We ended the impossible choice between velocity and control. We transformed governance from a blocker into an accelerator. We enabled self-service without sacrificing governance.

But this is just the beginning. The foundation we built this year sets the stage for even bigger innovations ahead. Neo will get smarter as it learns from infrastructure patterns across the community. Policy management will expand to more compliance frameworks. IDP will enable more sophisticated self-service workflows. ESC will integrate with more platforms.

The future of platform engineering is strategic, proactive, and AI-enabled. Platform teams won’t be bottlenecks - they’ll be the strategic enablers who make sustainable velocity possible.

Thank you for being part of the Pulumi community. Your feedback drives everything we build. We can’t wait to show you what comes next.

Want to try these features? Check out our documentation, join our community Slack, or contact us to discuss how Pulumi can transform your platform engineering practice.

Here’s to an incredible 2025, and an even better 2026!

Native OIDC Token Exchange for Pulumi CLI

Boris Schlosser — Tue, 16 Dec 2025 00:00:00 +0000

Managing credentials in CI/CD pipelines has always involved tradeoffs. Long-lived access tokens are convenient but create security risks when they leak or fall into the wrong hands. Short-lived credentials are more secure but require additional tooling to obtain and manage. Today, we’re eliminating this tradeoff with native OIDC token exchange support in the Pulumi CLI.

The Pulumi CLI now includes built-in support for exchanging OIDC tokens from your identity provider for short-lived Pulumi Cloud access tokens. This means you can authenticate to Pulumi Cloud directly from CI/CD environments like GitHub Actions, GitLab CI, or Kubernetes without storing any long-lived Pulumi credentials as secrets.

Why OIDC token exchange matters

Most CI/CD workflows authenticate to Pulumi Cloud using personal access tokens or organization tokens stored as secrets. While this approach works, it comes with significant security concerns:

Credential exposure: If a token is accidentally committed to a repository or logged in CI output, attackers gain long-term access to your infrastructure
Rotation complexity: Rotating tokens requires updating secrets across multiple CI/CD systems
Over-privileged access: Tokens often have broader permissions than needed for specific workflows
Audit trail gaps: Difficult to trace which workflow run used which credentials

With OIDC token exchange, you eliminate these risks by leveraging short-lived tokens that your CI/CD platform or identity provider already issues. No long-lived secrets to manage, rotate, or secure.

How it works

The pulumi login command now accepts OIDC tokens directly:

pulumi login --oidc-token <token> --oidc-org <org-name>

The CLI exchanges your OIDC token for a short-lived Pulumi Cloud access token, which is then used for all subsequent operations. Tokens expire after 2 hours by default, though you can customize this with the --oidc-expiration flag.

You can scope tokens to specific teams or users:

# Scope to a team
pulumi login --oidc-token <token> --oidc-org my-org --oidc-team platform-team

# Scope to a user
pulumi login --oidc-token <token> --oidc-org my-org --oidc-user alice

The --oidc-token flag accepts either a raw token string or a file path prefixed with file://, making it easy to integrate with various token delivery mechanisms.

Example: Kubernetes (EKS)

For workloads running in Kubernetes, you can use service account tokens and exchange them for Pulumi access tokens. The following example uses a Pulumi program to define a Kubernetes Job resource.

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

const script = new kubernetes.core.v1.ConfigMap("script", {
 data: {
 "entrypoint.sh": `#!/bin/bash
EKS_ID_TOKEN=$(cat /var/run/secrets/eks.amazonaws.com/serviceaccount/token)
pulumi login --oidc-token $EKS_ID_TOKEN --oidc-org MY_ORG_NAME
pulumi whoami
`
 }
});

const job = new kubernetes.batch.v1.Job("runner", {
 metadata: {},
 spec: {
 template: {
 spec: {
 serviceAccountName: "pulumi-service-account",
 containers: [{
 name: "runner",
 image: "pulumi/pulumi:latest",
 command: ["/bin/entrypoint.sh"],
 volumeMounts: [
 {
 name: "script",
 mountPath: "/bin/entrypoint.sh",
 readOnly: true,
 subPath: "entrypoint.sh",
 },
 ],
 }],
 restartPolicy: "Never",
 volumes: [
 {
 name: "script",
 configMap: {
 defaultMode: 0o700,
 name: script.metadata.name,
 },
 },
 ],
 },
 },
 backoffLimit: 0,
 },
});

export const jobName = job.metadata.name;

This approach works with any Kubernetes cluster that supports service account token projection, including EKS, GKE, and AKS. The example uses EKS’s default token location at /var/run/secrets/eks.amazonaws.com/serviceaccount/token, but you can adapt the token path for other Kubernetes distributions.

Prerequisites

Before using OIDC token exchange with the Pulumi CLI, you need to:

Register your OIDC provider as a trusted issuer in your Pulumi organization settings
Configure authorization policies that specify which tokens can be exchanged and what permissions they receive
Ensure your CI/CD system or identity provider is configured to issue OIDC tokens with the appropriate audience claim

Get started

Native OIDC token exchange is available now in the latest version of the Pulumi CLI. To get started:

Update to the latest Pulumi CLI version
Configure your OIDC provider and authorization policies in Pulumi Cloud
Update your CI/CD workflows to use pulumi login --oidc-token

For complete documentation, including setup guides for specific identity providers, see:

We’re excited to see how this feature helps you build more secure infrastructure automation workflows. If you have questions or feedback, join us in the Pulumi Community Slack.

New in Pulumi IaC: `replaceWith` Resource Option

Tom Harding — Tue, 09 Dec 2025 00:00:00 +0000

The magic of Pulumi is that we rarely have to worry about the fine details of how our deployment and infrastructure management works, allowing us to focus instead on what we want. If our program declares an S3 bucket, Pulumi handles creation, updates, and deletion automatically.

Most of the time, this is exactly what we want. However, some use cases require finer-grained control over resource dependencies. Today, we’re introducing the replaceWith resource option, a new feature that gives you explicit control over replacement dependencies between resources.

Custom resource dependencies

When replacing a resource, the Pulumi engine walks the dependency graph to determine what else needs replacement. However, the answer isn’t always obvious:

Some dependencies aren’t obvious at the infrastructure level. For example, restarting a database server may require restarting its consumers to reconnect.
Provider-specific challenges exist. You might not be able to update a subnet’s properties while resources are using it, even without an observable dependency. Any subnet change must be accompanied by changes to all its consumers to avoid errors.
Application-level dependencies may exist beyond infrastructure. If two services maintain open connections in the application layer, replacing one should trigger replacement of the other.

Declaring our own dependencies

The replaceWith resource option makes these dependencies explicit in your code. Similar to deletedWith, passing references to other resources via replaceWith defines a relationship: when any target resource is replaced, the source is also replaced. This has some interesting implications:

We can define a number of resources that all replaceWith each other, and so any change to any member of the group will trigger an update to all the others.
Relationships are transitive: organizing resources hierarchically where children replaceWith their parents means any ancestor change triggers replacement of all descendants.

In code

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

const database = new aws.rds.Instance("app-db", { /* ... */ });

// The database location is provided to this instance
// by other means, so there is not an explicit dependency
// linking the two.
const app = new aws.ec2.Instance("app-service", { /* ... */ }, {
 // Here, we explicitly tie the two together: if the
 // database is upgraded, for example, we will need to
 // restart the application instance to ensure that
 // a connection is re-established.
 replaceWith: [database],
});

import pulumi
import pulumi_aws as aws

database = aws.rds.Instance('app-db', {})

# The database location is provided to this instance
# by other means, so there is not an explicit dependency
# linking the two.
application = aws.ec2.Instance('app-service', {},
 # Here, we explicitly tie the two together: if the
 # database is upgraded, for example, we will need to
 # restart the application instance to ensure that
 # a connection is re-established.
 opts=pulumi.ResourceOptions(replace_with=[database])
)

import (
 "github.com/pulumi/pulumi-aws/sdk/v6/go/aws/ec2"
 "github.com/pulumi/pulumi-aws/sdk/v6/go/aws/rds"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

database, err := rds.NewInstance(ctx, "app-db", &rds.InstanceArgs{ ... })
if err != nil {
 return err
}

// The database location is provided to this instance
// by other means, so there is not an explicit dependency
// linking the two.
application, err := ec2.NewInstance(ctx, "app-service", &ec2.InstanceArgs{ ... },
 // Here, we explicitly tie the two together; if the
 // database is upgraded, for example, we will need to
 // restart the application instance to ensure that
 // a connection is re-established.
 pulumi.ReplaceWith([]pulumi.Resource{database}))
if err != nil {
 return err
}

using Pulumi;
using Aws = Pulumi.Aws;

var database = new Aws.Rds.Instance("app-db", new() { ... });

// The database location is provided to this instance
// by other means, so there is not an explicit dependency
// linking the two.
var application = new Aws.Ec2.Instance("app-service", new() { ... }, new CustomResourceOptions
{
 // Here, we explicitly tie the two together; if the
 // database is upgraded, for example, we will need to
 // restart the application instance to ensure that
 // a connection is re-established.
 ReplaceWith = new[]
 {
 database,
 },
});

import com.pulumi.aws.ec2.Instance;
import com.pulumi.aws.ec2.InstanceArgs;
import com.pulumi.resources.CustomResourceOptions;

var database = new com.pulumi.aws.rds.Instance("app-db",
 com.pulumi.aws.rds.InstanceArgs.builder()
 .build());

// The database location is provided to this instance
// by other means, so there is not an explicit dependency
// linking the two.
var application = new Instance("app-service",
 InstanceArgs.builder()
 .build(),
 // Here, we explicitly tie the two together; if the
 // database is upgraded, for example, we will need to
 // restart the application instance to ensure that
 // a connection is re-established.
 CustomResourceOptions.builder()
 .replaceWith(database)
 .build());

resources:
 database:
 type: aws:rds:Instance
 properties:
 # ...
 # The database location is provided to this instance
 # by other means, so there is not an explicit dependency
 # linking the two.
 application:
 type: aws:ec2:Instance
 properties:
 # ...
 options:
 # Here, we explicitly tie the two together: if the
 # database is upgraded, for example, we will need to
 # restart the application instance to ensure that
 # a connection is re-established.
 replaceWith:
 - ${database}

Of course, this is a simple example, but hopefully it illustrates the point: we now have a way to make implicit dependencies between resources more explicit within our programs, and provide hints to Pulumi as to which services depend on others.

Next steps

This feature is supported as of Pulumi v3.207.0, and is now available within the Go, Python, NodeJS, and Java SDKs, with C# and YAML coming soon. Thanks for reading, and feel free to reach out with any questions via GitHub, X, or our Community Slack.