Pulumi Release Notes

At Pulumi, we are building the platform for agentic infrastructure. Pulumi Cloud provides the guardrails and enterprise readiness needed to safely move fast in this new era. While we are seeing extraordinary adoption — over 40% of our users now manage infrastructure using AI agents — we know many organizations are at different phases in their AI journey and have to balance building for the future with maintaining their existing infrastructure as code (IaC) solutions like Terraform. Today, we are launching three ways that Pulumi lets you avoid trading off building for the future against building for today. You don’t have to rip out Terraform to enter the agentic era. Pulumi Cloud brings agentic infrastructure to the IaC estate you already have.

What we’re shipping today

Last December, our CEO Joe Duffy laid out his vision to make Pulumi the platform for all of your infrastructure as code. The capabilities we are launching today make that promise a reality. Pulumi is now fully interoperable with Terraform and OpenTofu and enables organizations to build upon their existing IaC estate rather than starting from scratch as they work toward the agentic infrastructure future.

Pulumi Cloud as a Terraform backend

We are excited to announce the general availability of Pulumi Cloud as the backend to your Terraform state, enabling organizations to seamlessly lift and shift their existing Terraform estates.

We recognize there is lots of infrastructure that works as is, and switching over to a new management paradigm may not always be possible. Pulumi Cloud support for the Terraform state backend lets organizations maintain their existing Terraform deployment patterns while also unlocking the power of Pulumi Cloud. The following common patterns for running Terraform are now supported:

• Plans and applies run remotely by default for new Terraform stacks, following the behavior of HCP Terraform and Terraform Enterprise. When you run a Terraform operation, it executes on a Pulumi-hosted runner rather than your local machine. You get full visibility into these operations both on your local CLI and in the Pulumi Cloud console.
• Production deployments may be gated with manual approvals before applying a Terraform plan.

With this release, stacks with Terraform state are first-class entities in Pulumi Cloud. They get access to all of the capabilities that organizations need to scale in this new AI-first era.

• Manage access to your Terraform stacks at scale using tag-based access control, team role assignments, and user role assignments.
• Take advantage of Neo code reviews. On every pull request, leverage what Pulumi Cloud knows about your running infrastructure and get clear feedback on whether it’s safe to merge changes to your Terraform and OpenTofu projects.
• Run preventive policies after a Terraform plan to block non-compliant resources before deployment.
• Configure your Terraform deployments with Pulumi ESC, which is natively available to Pulumi Cloud-backed Terraform projects, to securely inject OIDC credentials at apply time and expose outputs to downstream stacks and services.

Learn more in Using Pulumi Cloud as a Terraform state backend.

Reuse your Terraform modules

Pulumi programs, regardless of language, now support importing Terraform modules natively. Organizations can leverage their existing reusable artifacts as is, without having to make a single change. This enables organizations to focus on new infrastructure projects and lets them build those projects in the language of their choice, regardless of what their existing IaC estate is.

In addition, Pulumi Cloud’s private registry can now host Terraform modules alongside Pulumi packages. This enables you to consolidate all of your IaC building blocks in a single source of truth rather than managing disparate solutions and making sure your teams know where to look. Terraform modules hosted in Pulumi Cloud provide maximum interoperability and can be used in both Pulumi and Terraform programs.

Learn more in Using Terraform modules in Pulumi.

Build in HCL natively

HashiCorp Configuration Language (HCL) is now generally available as a first-class language in Pulumi IaC. Like any other Pulumi language, it has full access to the entirety of the Pulumi ecosystem, including thousands of providers. Thanks to our Terraform bridge, if there’s a Terraform provider out there, it just works. Best of all, HCL in Pulumi is 100% OpenTofu compatible with no syntactical differences.

We recognize there are many teams out there that prefer to work in HCL over general-purpose languages but want to leverage the modern Pulumi IaC engine, or want to be able to use the reusable components their partner teams rely on — regardless of whether those teams work in Terraform or Pulumi.

Learn more in the HCL language reference.

You are still covered until your HashiCorp renewal

We stand by the promise we made last December, and the last thing we want is for you to pay for two IaC solutions. To set your team up for long-term success and ensure your transition to Pulumi is as smooth as possible, we are continuing to offer three things:

• An escape hatch for your current contract. We know paying for two IaC solutions at once is a non-starter, so we’re letting you apply credits purchased from HashiCorp toward your Pulumi usage until your next renewal, avoiding double pay.
• A free IaC modernization workshop. Our professional services cloud architects host a free IaC modernization workshop to review where you’re at with your IaC already and share best practices for adopting the Pulumi platform at scale, learned from working with world-class organizations like BMW and Supabase. You will leave this session trained up and equipped to succeed with the next phase of your IaC journey.
• A return on investment (ROI) calculation. We will show you how the move to Pulumi will not only be spend-neutral thanks to the escape hatch, but how much value and savings you should expect to see, given our experience helping innovators like Snowflake accelerate their time to market — going from code to cloud in weeks to hours.

These ensure there’s no financial penalty for switching, a clear ROI, and no learning curve. We have always been proud to work with customers of all sizes in all industries, so these offers are available to you whether you’re a Global 2000, a startup, or somewhere in between.

Get started today

The agentic infrastructure era is already here, and we want you to bring your IaC to it. Get started with Pulumi free and provision your first stack in minutes.

If you’d like to get started with the new Terraform/OpenTofu and HCL capabilities, or take advantage of the financial flexibility options, please get in touch.

3.256.0 (2026-08-04)

Features

• [cli] Add --ignore-protect flag to pulumi up, pulumi preview and pulumi destroy to allow deleting protected resources without unprotecting them in the state first #24053
• [cli/env] Add an optional --export-env-vars flag to the env provider {aws,azure,gcp}-login commands to also set the standard SDK environment variables referencing the login outputs #24055
• [cli] Add a --server flag to pulumi package add, publish, get-schema, get-mapping, gen-sdk, info and pulumi schema check that skips package resolution and uses the given URL as the plugin download URL #24107

Bug Fixes

• [backend/service] Fix pulumi login --insecure not being reflected in the stack's service secrets manager state, which caused TLS verification failures against self-hosted backends using self-signed certificates #24134
• [cli] Scope current stack selection to the active backend so switching backends no longer surfaces stale stack errors #23974
• [programgen/go] Parent an invoke written inside a component to that component, lower a component's outputs, and only import fmt when a component needs it #24019
• [programgen/python] Parent an invoke written inside a component to that component, so it resolves the component's providers #24018
• [sdk/nodejs] Defer output-form invokes that depend on a remote component whose resources are pending creation, by declaring invoke dependencies to the engine #24042
• [engine] Gate invokes on the created-ness of their declared dependencies, including the children of remote components, resolving them as unknown during previews that still have to create them #24040
• [sdk/go] Defer output-form invokes that depend on a remote component whose resources are pending creation, by declaring invoke dependencies to the engine #24044
• [pcl] Declare invoke dependencies to the engine so invokes that depend on pending resources, including remote components, resolve as unknown during previews #24041
• [sdk/python] Defer output-form invokes that depend on a remote component whose resources are pending creation, by declaring invoke dependencies to the engine #24043
• [cli/env] env provider no longer writes a new environment revision when the resulting definition is unchanged #24055
• [sdk/go] Output-form invokes now infer their resource dependencies from their arguments, so they are skipped during preview while a dependent resource is pending creation and their results carry those dependencies #24054
• [sdkgen/go] Fixes nested optional output conversions #24096
• [engine] Fix a plugin process leak in NewPolicyAnalyzer when ConfigureStack fails after the plugin has booted #24106
• [programgen/go] Avoid redundant applies when projecting properties from generated Go object outputs #24112
• [backend/diy] Fix 403 errors writing to third-party S3-compatible backends (e.g. IBM COS, MinIO) by defaulting request_checksum_calculation to when_required when the s3:// backend URL sets a custom endpoint #24109
• [programgen/nodejs] Avoid redundant applies when projecting properties from Node.js outputs #24119
• [programgen/python] Avoid redundant applies when projecting properties from Python outputs #24120
• [sdk] Fix apply erroring for skipped resources #24108
• [cli] Retry rate-limited (HTTP 429) API requests when they are safe to retry, honoring the server's Retry-After header #24131
• [cli] Exit non-zero from remote operations (pulumi up --remote, pulumi deployment run) when the deployment fails #24155
• [cli/new] Resolve and install packages required by the program during pulumi new, as pulumi install does #24126
• [cli] Make --remote not require a Pulumi.yaml file to be present #24128
• [cli/import] Generate explicit providers in the import file resources #24135
• [sdk/nodejs] Fix trustedDependencies parsing for bun #24145
• [auto/go] ImportResources no longer leaks --stack into the converter's arguments when converter args are passed #24146
• [auto/go] Fix ImportResources when GenerateCode(false) is set #24147
• [sdk/go] Fix hooks and transforms causing panics with mocks #24161
• [programgen/go] Fix plain invokes emitting nonexistent ...ArgsArgs argument types #24172

Improvements

• [cli/import] Error when running pulumi import --from terraform in a Pulumi HCL project #23744
• [programgen] Add ID type to PCL #22702
• [engine] Give the resource monitor's Invoke its own response message, separating it from the one a provider returns #24100
• [cli/do] Allow stateful resources to register their own provider resources based on provider inputs on the command line #24098
• [cli] Refresh the first-login welcome message to link your Pulumi Cloud console and the Pulumi changelog #24122
• [cli/do] Add support for the --provider argument for stateful operations #24132
• [programgen/go] Better typing for maps, using known types rather than map[string]interface{} #24142
• [cli/import] Serve the package-resolver service to state converters via resolver_target on ConvertStateRequest, so converters can resolve package specifications the same way the CLI does #24174

Miscellaneous

• [cli] Retire the Pulumi AI mode of pulumi new (interactive choice and --ai/--language flags). The backing service has been shut down; use pulumi neo instead. #24116
• [sdk/dotnet] Upgrade dotnet to v3.110.0 #24175
• [yaml] Upgrade yaml to v1.38.1 #24175

Why: your infrastructure doesn’t live in one tool

Today we’re launching Discovered Stacks: Pulumi Cloud now models your AWS CloudFormation stacks and Azure Resource Manager deployments as stacks, right alongside your Pulumi IaC stacks. And when you’re ready to bring them under Pulumi management, migration is built in, with every resource tracked until the code provably matches the cloud.

Almost nobody’s cloud estate is a single technology. There’s the CloudFormation that came with the AWS account, the ARM templates from the Azure team, the Terraform from an acquisition, and the Pulumi you’re standardizing on. Each tool has its own console, its own grouping, its own idea of state, and no single place shows you everything you run.

That fragmentation is also why migrations stall. Moving a stack to Pulumi has never been the hard part; knowing where you stand is. The tracking lives in a spreadsheet, the spreadsheet goes stale the day it’s written, and six months later nobody can say which of the 800 resources made it across and which were quietly forgotten.

Nothing gets lost

Discovered Stacks gives you confidence that your migration plan or governance efforts will include all resources. This catches a common failure mode where resources are missed by your existing migration scripts or automations. When Pulumi Insights scans your accounts, every CloudFormation stack and ARM deployment becomes a discovered stack, and every resource in it appears as a row with an explicit migration status: ready to migrate, requiring review before migration, or already migrated. Every status is computed from live state on both ends — what Pulumi manages and what the source tool reports — so it’s never a stale annotation someone forgot to update.

Each resource shows its origin type (AWS::S3::Bucket) next to its Pulumi type (aws:s3/bucket:Bucket), with the origin properties side by side with Pulumi’s view, so you can verify that Pulumi sees exactly what your source tool sees before you change anything. Decisions you make along the way (this resource was deleted, that policy is covered by its parent role) are recorded by marking the resource resolved: it stays visible to your whole team, deliberately handled rather than quietly forgotten. The spreadsheet is retired.

Migration on your terms

When you’re ready to migrate, the console is where you plan and build confidence. Migrate with Neo hands the job to Pulumi Neo, which imports the resources, reconciles the generated program, and opens a pull request for review. If you prefer local development, Generate Import Commands gives you the raw materials, and the same API lets your own agents drive the flow.

Two things hold regardless of the path. Progress is derived: a resource shows as migrated when it actually exists in the target Pulumi stack, not when someone checks a box. And the quality gate is a zero-diff pulumi preview — the migration is done when the code demonstrably matches your cloud.

Terraform stacks whose state you store in Pulumi Cloud get the same treatment through a new Migration tab, with statuses derived from the Terraform state.

Try it

Open the Stacks page in Pulumi Cloud, turn on Show Discovered Stacks, and your CloudFormation and ARM estates appear next to your IaC. From there:

• Read the Discovered Stacks documentation.
• Follow the step-by-step migration tutorial to take a CloudFormation stack all the way to Pulumi.

We’d love to hear how it works on your estate — reach out through Pulumi feedback or your customer success team.

3.255.0 (2026-07-28)

Features

• [cli] Add an --extension flag to package commands for extension-parameterized packages, reinstalled from Pulumi.yaml on pulumi install
• [cli] Project files to disk and surface their paths as environment variables for all output formats when opening an ESC environment #23993
• [engine] Resolve an invoke's provider from the providers option of the parent named on the request, matching the resolution applied to resource registrations #24016
• [cli/do] Add --resources to refer to existing resources in state in do input expressions #24037

Bug Fixes

• [programgen/nodejs] Parent an invoke written inside a component to that component, so it resolves the component's providers #24017
• [pcl] Apply the providers option of a component block to the resources and invokes it declares #24016
• [cli/import] Fix import file generation when parent resources share names #24069
• [cli] Fix parallel pulumi install processes sharing a PULUMI_HOME intermittently failing with a missing provider executable error #24080
• [sdk/python] Allow Construct and Call methods to run concurrently in provider servers #24081

Improvements

• [engine] Support strings containing non-UTF8 bytes flowing between providers, the engine, state, and languages that opt in (Go and PCL initially) #23856
• [cli] Add a --summary flag to pulumi stack history events that reduces a past update's events to the same summary shape as a live pulumi up --output json, extended with error diagnostics and failed-resource markers #23960
• [protobuf] Allow state converters to supply resource inputs and outputs in ConvertState responses #23987
• [engine] Allow policy packs to point to executable binaries, not just script folders #24052
• [cli/display] The Neo diagnostics link now suggests pulumi neo --debug-update or pulumi neo --debug-preview to investigate the failed operation #24075
• [sdk/python] Allow UV_PROJECT_ENVIRONMENT to override the virtualenv path if uv is used #24077
• [cli] Allow otel traces to be sent over https #24078

Change pulumi.NewContexts feature discovery mechanism to first probe for new features via the newer GetDeploymentInfo instead of probing each known feature ahead of time and then calling GetDeploymentInfo at the end. On more modern engines this saves us 10 blocking gRPC calls, and the code is cleaner besides.

supportedMonitorFeatures already has all features that supportsFeatureID has:
https://github.com/pulumi/pulumi/blob/e71b833c2b259249605e08ce1052bfcfefbd6c61/pkg/resource/deploy/source_eval.go#L931
https://github.com/pulumi/pulumi/blob/e71b833c2b259249605e08ce1052bfcfefbd6c61/pkg/resource/deploy/source_eval.go#L888

Pulumi Cloud organizations can now enforce a maximum expiry on the access tokens used against them.

Organization admins can set a cap in days, and from that point on, personal, organization, and team tokens operating on resources in the org must carry an expiration within the cap for requests to succeed. Tokens that never expire, or that have too much lifetime remaining, get rejected with an error that tells the user exactly how to regain access.

Why cap token lifetimes

Many organizations already have a credential rotation policy that says tokens must expire, but until now, Pulumi Cloud could only recommend an expiry at creation time. Nothing stopped a member from creating a never-expiring personal token, and nothing aged out the long-lived tokens created before your policy existed.

That gap matters because a leaked token is only as dangerous as its remaining lifetime. A token that never expires is a standing liability.

By adding support for access token expiry policies, Pulumi Cloud now closes the gap at the platform level. Once you’ve set the cap, Pulumi Cloud enforces it immediately for your organization, including for tokens that already exist.

How it works

In your organization’s settings, navigate to Settings > Access Management > Other and scroll to Access token expiry policy:

You can also get there from the Access Tokens tab, where a banner shows whether a policy is in effect — select Edit policy:

The policy is a single number: the maximum expiry, in days, for tokens used against your organization. Compliance is checked on every request, and a token complies when both of these are true:

1. It has an expiration date. Never-expiring tokens violate any policy.
2. Its remaining lifetime — the time between now and its expiration — is within the cap.

Because compliance is based on remaining lifetime rather than the expiry chosen at creation, the policy is pragmatic about existing credentials: a token created a year ago with a two-year expiry becomes compliant once it has less than the cap remaining. You’re enforcing exposure going forward, not retroactively punishing old tokens that are already near the end of their life.

Enforcement is tailored to each token type:

• Organization and team tokens can’t be created out of compliance: the creation dialog caps the expiry picker at your policy maximum, and the API rejects requests that exceed it. Existing machine tokens that violate the policy stop authenticating and need to be recreated with a compliant expiry.
• Personal tokens span all of a user’s organizations, so they can’t be blocked at creation. Instead, a non-compliant personal token is rejected when it’s used against your organization, and the member sees an error explaining the policy and how to fix it. The personal token creation dialog also warns members when a chosen expiry doesn’t meet a policy in one of their organizations, steering them toward a compliant choice up front.
• Web console sessions are unaffected, as are the short-lived tokens issued through OIDC token exchange — those are already bounded by their issuer.

Once a policy is active, the creation dialog does the steering for you — the expiry picker tops out at the policy maximum:

Rolling it out without breaking CI

The riskiest moment for any new enforcement policy is the moment you turn it on. Two things make that safe here.

First, Preview affected tokens shows you the blast radius before you save: the organization and team tokens that would stop authenticating under the proposed cap, by name and creator. Recreate those credentials with compliant expiries first, then save the policy.

Second, rejections are designed to be self-explanatory. A blocked request fails with a 403 Forbidden that names your organization and its policy maximum, so a member whose personal token no longer complies knows immediately what happened and what to do: generate a new token that meets the policy. Policy changes are also recorded in your organization’s audit logs.

A reasonable rollout looks like:

1. Decide on a cap that matches your rotation policy. 90 days is a common choice for CI credentials.
2. Use Preview affected tokens and recreate any non-compliant machine tokens.
3. Socialize the change in your organization: personal tokens without a compliant expiry will stop working against the organization.
4. Save the policy. From here on, the platform enforces it for you.

Get started

The access token expiry policy is available now in your organization’s access settings. For the full reference — compliance rules, per-token-type behavior, and exemptions — see the access tokens documentation.

If you have feedback, we’d love to hear it in the Pulumi Community Slack or on GitHub.

Pulumi ESC makes it easy to store configuration and secrets for your Pulumi programs, and with Approvals for ESC you can review and approve changes before they go live. The new --override-env flag lets you preview any environment change, including an unapproved draft, to see exactly how it would affect your stack before it becomes the latest version.

Example scenario

Your team stores production app configuration in ESC and has enabled Approvals to keep bad values out of critical infrastructure. But one important question remains: how can reviewers properly validate a configuration change before approving it?

Introducing: draft references and the –override-env flag

We are introducing a new --override-env flag to the Pulumi CLI that works with every Pulumi operation that can consume ESC environments: preview, up, refresh, and destroy. This makes it easy to test configuration changes on the fly, giving your team the confidence to validate them as part of the review process.

Example usages

The basic usage is --override-env =, and you can override multiple environments at once! In this example, we are running a pulumi preview with environments app/myenv and app/myenv2 replaced by their draft versions (denoted by @draft:).

pulumi preview \
  --override-env "app/myenv=app/myenv@draft:123e4567-e89b-12d3-a456-426614174000" \
  --override-env "app/myenv2=app/myenv2@draft:123e4567-e89b-12d3-a456-426614174000"

The --override-env flag not only works with draft references, but for any environment too! Here is an example of deploying your stack with your AWS test environment:

pulumi up --override-env "aws-login/prod=aws-login/testing"

Note: --override-env can also override environments that are imported (directly or indirectly) from the ESC environment in your stack config. This allows you to override any environment in the import chain for full flexibility.

Ways to use it

• Validate a draft ESC environment with your stack before approving
• One-off debugging without editing stack config

Get started

Draft references and --override-env are available today in the Pulumi CLI. Upgrade to the latest release and try it out! To learn more:

• Pulumi ESC documentation
• Approvals for ESC
• Get started with Pulumi ESC

Features

[cli] Add pulumi logs share command for sharing logs with Pulumi #22546

[cli] Add pulumi stack migrate to migrate a stack from another backend to the currently logged-in backend, including re-encrypting config secrets and stack state under the target secrets provider #22902

[cli/config] Add an --override-env flag to up, preview, destroy, and refresh to substitute imported environments for a single run without editing the stack config #23562

[cli] Add pulumi neo acp to run Neo as an Agent Client Protocol agent over stdio for ACP-capable editors, with read-only and plan mode exposed as session config options #23886

[cli/neo] Retry transient pulumi neo stream and message-send failures, and add pulumi neo resume with chat history #23835

[cli/neo] Make Ctrl+C clear typed text and preserve Ctrl+A/Ctrl+E line navigation in pulumi neo #23932

[cli/do] Add upsert to do, allowing resources to be statefully created or updated in a stack #23813

[sdk/python] Add pulumi.run for natively awaited Python program entrypoints that can return stack outputs #23945

[cli/do] Allow expressions for number inputs #23954

[cli/do] Allow expressions for boolean inputs #23967

[cli/policy] Add --runtime-options to pulumi policy new #23992

[cli/do] Add support for stateful create #23996

[cli/do] Add support for stateful delete #24000

Bug Fixes

[sdkgen/go] Fix Go codegen for plain properties nested inside non-plain objects #22524

[cli/neo] Keep pulumi neo connected during quiet periods when the event stream only receives keep-alive heartbeats #23935

[engine] Validate snippets before persisting them #23920

[backend] Fix dangling ReplaceWith references in the journal replayer #23927

[cli/do] Fix the converter plugin not being called if just attributes needed converting #23948

[programgen/go] Generate compilable Go for programs that use discriminated union members as array/list elements #23980

Improvements

[cli] Align commands with the CLI naming guidelines, adding ls, rm, delete, mv, update, modify, create and setup aliases to list/remove/move/edit/new commands and making state remove and package remove the canonical names with delete kept as an alias #23903

[cli] Suggest closely-matching commands from the whole command tree when an unknown command is entered #23848

[cli] Print help but exit with a non-zero code when pulumi is run without a command, matching the behavior of other group commands #23848

[programgen] Support onError resource hooks in generated Go, NodeJS, and Python programs and in the PCL runtime, retrying the failed operation when the hook command exits successfully #23839

[protobuf] Add parent and properties fields to ResourceImport so state converters can express resource hierarchy and property filters #23929

[protobuf] Allow state converters to declare explicit providers as resources in ConvertState responses and attach imported resources to them via the new provider field #23975

[cli] Redact secrets in property values in logs #23931

[cli] Make -v<n> --logflow no longer produce separate log files for plugins #23938

[protobuf] Pass a schema loader target to state converters in ConvertStateRequest #23944

[cli/import] Allow explicit providers to be declared in the resources section of an import file and referenced by name #23972

[cli] Remove the template count from pulumi new --help, which required a slow template listing before help could display #23973

[cli/import] Support inputs and outputs on resources in import files, importing supplied state directly and skipping the provider read when outputs are given #23984

Miscellaneous

[sdk] Move RetrieveGitFolder to the gitutil package #23955

[sdk] Move template helpers from workspace to pkg/cmd/pulumi/templates #23963

Pulumi ESC CLI v0.26.0 is the latest standalone release. We encourage users to use the Pulumi CLI instead.

The ESC repository has been archived and the code now lives under pulumi.

Why are we making this change

Pulumi ESC is the best way to store and manage configuration and secrets in your Pulumi programs and while you can certainly use ESC to store secrets and configurations for your applications or to manage your AI agents’ credentials, it’s still a core feature of Pulumi Cloud, and we want to make sure we deliver a consistent experience across our entire suite.

In addition to consistency, ESC and the Pulumi CLI share a lot of capabilities to interface to Pulumi Cloud and we want to make it easier and simpler for our customers: it’s now easier to understand which Pulumi organization you are working with, which user is logged in, etc.

Playing nicer with humans and AI agents

A single CLI means one binary to install, one login to manage, and one place to look things up. This simplicity is beneficial whether the operator is a person or an agent.

AI agents love code, and they love CLIs. By unifying the Pulumi CLI and ESC we offer a single place to look up operations around your Pulumi programs. Agents can now reason better about where to store configuration and secrets, without being confused by multiple CLI options that interface against the same service.

Faster improvements

With a shared CLI, any improvement to account management is automatically delivered to both: Pulumi and ESC users. At the same time, both benefit from ESC improvements and new features from day 1.

ESC is a core component of our platform; a separate interface no longer makes sense.

The same code all along

If you’re wondering what actually changes under the hood: nothing about how the commands work. The pulumi env commands were never a reimplementation — the Pulumi CLI has built them from the ESC CLI’s own code since ESC’s first release, which is why the same command surface has always been available under pulumi env. What we’re retiring is a second way to ship and install that code, not the code itself.

Do I need to update?

If you are using the ESC CLI, you should switch as soon as possible, as the standalone binary will not get the latest features. Don’t worry — the mapping is mechanical, and the migration guide covers it command by command:

• esc env becomes pulumi env . For example, esc env ls becomes pulumi env ls.
• The esc open and esc run shortcuts become pulumi env open and pulumi env run.
• esc login, esc logout, and esc version become pulumi login, pulumi logout, and pulumi version.

If you are already using the Pulumi CLI, you have nothing to worry about; this has no effect since ESC commands were already available under the pulumi env sub-command.

Ready to switch? Install the Pulumi CLI if you don’t have it yet, then run pulumi env ls to see your environments. Every command is documented in the pulumi env reference.

Pulumi Insights gives you visibility and governance across your entire cloud footprint, but that visibility is only as complete as the set of accounts you’ve connected. Until now, connecting an account meant repeating a manual setup for each one: OIDC configuration, hand-written Pulumi ESC environments, and per-account scan and policy setup. For an organization with dozens or hundreds of AWS accounts, Azure subscriptions, or Google Cloud projects, that per-account friction was the biggest obstacle to getting a complete picture. Today, the new Connect cloud accounts wizard removes it: discover every account in your cloud organization, select the ones you want, and onboard them all in a single guided flow.

From hours of setup to a single flow

The time savings are real: connecting a batch of accounts across AWS, Azure, and Google Cloud takes about three minutes end to end. Setting up those same accounts with the manual per-account workflow would take hours to days.

The wizard handles the entire onboarding lifecycle for AWS, Microsoft Azure, and Google Cloud:

• Bulk discovery: Authenticate once with your cloud organization and the wizard lists every account, subscription, or project you can access. Accounts that are already connected are recognized and skipped.
• Automatic OIDC setup: The recommended flows configure each account with short-lived credentials based on OpenID Connect (OIDC) and workload identity federation. No long-lived cloud secrets are stored in Pulumi Cloud.
• ESC environments, created for you: The wizard generates Pulumi ESC environments that follow the best practices from the manual OIDC guides — environments that previously had to be authored one by one.
• Scans and policies from day one: By default, scheduled discovery scans and a pre-built policy pack are applied to every account as part of setup: the Pulumi Best Practices pack on the Team and Enterprise editions, or a compliance pack (CIS, or NIST 800-53 for AWS and Google Cloud) on Business Critical.

How it works

The wizard walks you through five steps: choose a provider, authenticate, select accounts, configure discovery and policy, and review the results. You can open it from Management > Accounts in the Pulumi Cloud console, or from the Get to know Pulumi card on the home dashboard.

Authentication uses each provider’s native federation mechanism: IAM Identity Center (SSO) for AWS, Microsoft Entra ID workload identity federation for Azure, and Workload Identity Federation for Google Cloud. After you sign in, the wizard discovers the accounts in your organization and pre-selects everything that isn’t already connected. You can search, select all, or toggle individual accounts.

Choose the right access level for your security posture

Not every team wants to grant write access on day one. The wizard offers two access levels, and you can set them per account:

• Build & Manage (read and write): Enables the full platform: Pulumi Neo, infrastructure as code, deployments, and policies that remediate issues automatically (Business Critical).
• Discovery & Policy (read-only): Limited to discovery scanning and inventory. Pulumi can’t modify your infrastructure.

If your security review requires it, start everything read-only and raise access for specific accounts later.

Everything set up, nothing hidden

When setup completes, the summary shows exactly what was created: the ESC environments grouped by access level, the state of discovery scanning, and the policy pack applied. If any account fails to connect, the summary lists it with the specific error so you can fix the cause and re-run the wizard. Accounts that connected successfully are skipped on retry.

For security reviewers, the docs include a full accounting of what the wizard creates in your cloud provider and in Pulumi Cloud: the IAM roles, app registrations, and service accounts on the cloud side, and the ESC environments and Insights accounts on the Pulumi side.

Get started

The Connect cloud accounts wizard is available now for all Pulumi Cloud organizations. To connect your first accounts:

1. Navigate to Management > Accounts in the Pulumi Cloud console and select Connect cloud accounts.
2. Follow the guided flow for AWS, Azure, or Google Cloud.
3. Explore your discovered resources and policy findings.

To learn more:

• Connect cloud accounts documentation — prerequisites, each wizard step in detail, and troubleshooting
• Insights & Governance overview — full documentation for discovery and policy capabilities
• Pulumi ESC — how the generated environments manage cloud credentials with OIDC

How usage limits work

Pulumi Neo is an AI agent that takes on real infrastructure work, and it’s natural to want to hand it more and more. Usage limits give you control so you can do exactly that: set a monthly dollar limit, and Neo pauses when your organization reaches it.

Your organization limit is a single monthly dollar amount covering all Neo usage across the org. To set one:

1. In the Pulumi Cloud console, navigate to Settings → Billing & usage → Neo token usage.
2. In the Manage token usage panel, enter an organization limit.
3. Save your changes.

When usage reaches the limit, Neo pauses for the rest of the billing period and resumes automatically at the start of the next one. An Admin or Billing Manager can raise the limit to resume before then.

Enforcement happens at a natural boundary in Neo’s work, so a task already in progress finishes its current step before pausing. As a result, usage can go a few dollars over the set limit.

Per-member limits and alerts

You can also set a separate limit for each member. A member is paused at whichever limit is smaller: their own or the organization’s. For example, a member with a $200 limit under a $150 organization limit pauses at $150, because the organization limit is smaller.

Turn on Enable email notifications to get a heads-up before you reach the limit. Billing admins are alerted at 50%, 80%, and 95% of the organization limit, with a final notice at 100% when Neo pauses.

Get started

Set your usage limits and stay in control as your organization hands Neo more and more work. Usage limits are available today for organizations on a paid plan, and an Admin or Billing Manager can set them.

• Sign in to Pulumi Cloud and set your first organization limit
• Read the Neo usage limits documentation for per-member limits, alerts, and enforcement details
• Join the Community Slack to share your feedback

3.253.0 (2026-07-14)

Features

• [auto/go] Support --import-pending-creates for refresh command in Go Automation API for preview refresh and refresh operations #23833

Bug Fixes

• [sdk] Precompose filenames to NFC on macOS when matching ignore patterns during archive creation, mirroring git's core.precomposeunicode so composed patterns match decomposed filenames #23566
• [cli] Respect the -v log level again so that without -v only warnings and errors are written to stderr #23910
• [codegen] Correctly generate provider resources declared inside PCL components for Node.js, Python and Go #23904

Improvements

• [cli] Add a --version flag to the pulumi command that prints the version, same as pulumi version #23898
• [cli] Align env commands with the CLI naming guidelines, making list, remove and move the canonical names with ls, rm, delete and mv kept as aliases #23901

Pulumi Cloud now supports passkeys for users who sign in with email and password. Select a button, approve with Touch ID, Face ID, Windows Hello, or your hardware key, and you’re signed in.

A passkey is a public-key credential stored on your device: your phone, your laptop, a hardware key (YubiKey, Google Titan, etc.), or your password manager can all function as the authenticator. When you sign in, your device authenticates you locally and signs a challenge from Pulumi Cloud with the private key.

The private key stays on your device — Pulumi Cloud never sees or stores it. Passkeys are built on the WebAuthn standard, so they’re already supported on every major browser and operating system.

Who this is for

This release applies to users who sign in to Pulumi Cloud with an email address and password. If you sign in through an identity provider (IdP), such as GitHub OAuth, GitLab, Bitbucket, Google, or your organization’s SAML SSO, your existing flow is unchanged.

Why passkeys

Passwords have always been the weakest link in account security. Since they are shared secrets, they are vulnerable to phishing attacks, and every place you type one is a place that can be impersonated or a data store that can be leaked. Passkeys swap that out for a per-site key pair that lives on your device:

• Phishing-resistant by design. A passkey is bound to the exact origin it was registered for. A look-alike domain can’t trigger your authenticator.
• Synced across your devices. Apple iCloud Keychain, Google Password Manager, 1Password, Dashlane, Bitwarden: most credential managers now sync passkeys end-to-end-encrypted to every device you’ve signed in on.
• Discoverable. Pulumi Cloud doesn’t need to know which user you are before you authenticate. Just select “Sign in with a passkey” and your device offers the right credential.
• Nothing to remember. A passkey lives on your device. There’s no string to memorize, and no sensitive credential stored by us.

Setting up a passkey

The next time you sign in with a password, Pulumi Cloud will ask if you’d like to configure a passkey. It’s a single-step prompt, so you can enroll once and take advantage of passkeys on every subsequent sign-in.

If you dismiss the prompt and would like to add one later, or want to add multiple passkeys, navigate to Account Settings → Passkeys under your user profile. Select Register a passkey, complete the OS-level prompt (Touch ID, Face ID, Windows Hello, or your hardware key), and you’re done. Pulumi Cloud will pick a sensible default name like "iCloud Keychain" or "Chrome on macOS" based on the authenticator, but you can rename it inline anytime under Account Settings → Passkeys.

You can register as many passkeys as you want. Typical setups are one per personal device, or one synced credential plus a hardware key as backup. Removing a passkey takes effect immediately; deleted credentials cannot be used to sign in.

Signing in

Depending on how you arrive:

• Explicit sign-in. On the sign-in page, select Sign in with a passkey. Your browser opens the passkey picker, and you authenticate from there.
• Autofill. If your browser supports conditional mediation (Chrome, Safari, Edge, recent Firefox), the email field on the sign-in page proactively offers your registered passkeys as autofill suggestions. Pick one and you’re signed in.

What about my existing password and MFA?

Your existing password still works. Passkeys are an additional sign-in option, not a replacement, and they don’t disable password sign-in on your account. If you lose access to every registered passkey, you can still sign in with your email and password as you always have, then register a new passkey from settings.

Other 2FA still applies. If you have TOTP-based MFA enabled on your Pulumi account, a passkey sign-in will still prompt for your second factor. WebAuthn doesn’t reliably tell us how you unlocked the passkey on your device (biometric, PIN, or something weaker), so we can’t safely treat the passkey itself as proof of two factors. Your existing MFA configuration remains the boundary it always was.

Try it out

Passkey support is generally available today for every Pulumi Cloud user who signs in with email and password, at no additional cost and with no configuration. Visit your account settings to register your first passkey, and let us know what you think on our community Slack or GitHub.