# esc Published articles for esc. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Set Up Cloud OIDC From the Pulumi CLI DevFeed: [Set Up Cloud OIDC From the Pulumi CLI]() Original publisher: [Read original article]() Author: Sean Yeh Published: 2026-09-11T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [OpenID connect (OIDC)](), [Command-line interface](), [AWS IAM](), [Cloud](), [AWS Identity and Access Management (IAM)](), [Azure](), [Google Cloud Platform (GCP)]() Tags: [automated](), [aws](), [azure](), [cli](), [cloud](), [configuration](), [docs](), [esc](), [google-cloud](), [how-to](), [iam](), [identity](), [oidc](), [openid-connect](), [product](), [pulumi](), [pulumi-cli](), [security](), [terminal](), [workflow]() ### AI overview This tutorial explains how to use the Pulumi CLI command pulumi env setup to configure Pulumi ESC as an OIDC provider for AWS, Azure, and Google Cloud. It covers interactive onboarding, non-interactive flags for scripts and agents, cloud credentials, account selection, access policies, and automatic creation of identity providers, IAM roles, policy attachments, and ESC environments. ### Source excerpt Pulumi ESC can act as an OpenID Connect (OIDC) provider for AWS, Azure, and Google Cloud, issuing short-lived, signed tokens that these clouds exchange for temporary credentials. This eliminates hard-coded credentials and improves your security posture. Last year, we introduced an onboarding flow in the Pulumi Cloud console that makes it super easy to configure OIDC for your cloud provider in a few guided steps. We're bringing Pulumi Cloud into the CLI so agents can use its capabilities directly from the terminal, without requiring a human to complete steps in the console. The new pulumi env setup command brings OIDC onboarding to that workflow, with interactive prompts for guided setup and non-interactive flags for scripts and agents. pulumi env setup - how it works Run the command with your desired cloud provider (aws, azure, gcp). For example: pulumi env setup aws The command then asks what it needs to configure your cloud, including your credentials, the accounts to configure, and the level of access. The questions differ per cloud. For AWS, it asks: How to authenticate to AWS. It uses the credentials you already have, or it signs you in with AWS SSO. Which accounts to configure. Which policy to attach to the OIDC role. Choose AdministratorAccess for Pulumi Deployments, ReadOnlyAccess for Pulumi Insights, or any other policy ARN. Then, it will print out the plan: About to configure OIDC for organization my-org: account 111111111111: create role pulumi-esc-oidc-622e86ea-319ba4c675bb3c00-role attach arn:aws:iam::aws:policy/AdministratorAccess create ESC environment my-org/aws-login/sandbox-account-env Proceed? [yes/no] After you confirm, the command creates the identity provider, the IAM role, and the policy attachment in each account. It then creates one ESC Environment per account, with the aws-login provider already configured. Non-interactive setup You can also run the command without interactive prompts by passing in the necessary flags. Each cloud has its ow ## Pulumi Introduces Notification Center for Pulumi Cloud DevFeed: [Pulumi Introduces Notification Center for Pulumi Cloud]() Original publisher: [Read original article]() Author: Tom King Published: 2026-08-11T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Cloud]() Tags: [console](), [email](), [esc](), [features](), [github](), [notifications](), [organization](), [product](), [pulumi](), [pulumi-cloud](), [pulumi-neo](), [real-time](), [review](), [slack]() ### AI overview Pulumi introduces Notification Center, an inbox in the Pulumi Cloud console for task completions, approval requests, and billing alerts. Notifications appear in real time, link directly to the required action, and can be delivered in the console or by email with per-type preferences. ### Source excerpt Plenty happens in a Pulumi organization while you're looking somewhere else. Neo finishes a task you kicked off just before taking lunch. A teammate submits an ESC change request that needs your approval before it can land. Until now, catching any of that meant either keeping the right tab open or hoping the right email reached you. Today we're introducing the Notification Center: a single inbox in the Pulumi Cloud console for the things that actually need you. It lives behind the bell in the sidebar, with a dot when something's waiting. Notifications arrive in real time -- no refresh -- and each one carries exactly one action: Review request, View task, Update billing. Click it and you land on the page where you can do the thing, not on a dashboard where you have to go find it. What you'll hear about We've started with the moments where being a few minutes late actually costs you something: a Neo task that's paused waiting on your approval, a Neo task that's finished, an ESC change request waiting on your sign-off, and billing conditions like a locked organization or a trial that's about to end. Relevant people in your organization will be notified when there's a pending approval, or billing alert. Nobody gets paged for someone else's work. Where you'll hear about it Every notification type can be delivered two ways -- in the console and over email -- and you choose per type, per channel. Organization admins set a sensible baseline for everyone; each person can override it for themselves on their account settings page. What's next The Notification Center is available today. We're starting with this set of notifications and expanding from there. If there's an event you'd rather hear about from the bell than from a colleague on Slack, we'd like to know which one. Join our Community Slack to connect with the Pulumi team and other users, or open an issue on our GitHub repository. ## Preview ESC Changes with Environment Overrides DevFeed: [Preview ESC Changes with Environment Overrides]() Original publisher: [Read original article]() Author: Sean Yeh Published: 2026-07-23T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Command-line interface](), [configuration](), [Testing]() Tags: [cli](), [configuration](), [configuration-management](), [critical-infrastructure](), [esc](), [features](), [product](), [production](), [pulumi-cli](), [pulumi-esc](), [release](), [secrets](), [upgrade]() ### AI overview Pulumi introduces the --override-env flag for the Pulumi CLI, allowing teams to preview draft or alternate ESC environments during operations such as preview, up, refresh, and destroy. The feature helps reviewers validate configuration changes before approval and supports overrides through imported environment chains. ### Source excerpt Pulumi ESC makes it easy to store configuration and secrets for your Pulumi programs, and with Approvals for ESC you can review and approve changes before they go live. The new --override-env flag lets you preview any environment change, including an unapproved draft, to see exactly how it would affect your stack before it becomes the latest version. Example scenario Your team stores production app configuration in ESC and has enabled Approvals to keep bad values out of critical infrastructure. But one important question remains: how can reviewers properly validate a configuration change before approving it? Introducing: draft references and the -override-env flag We are introducing a new --override-env flag to the Pulumi CLI that works with every Pulumi operation that can consume ESC environments: preview, up, refresh, and destroy. This makes it easy to test configuration changes on the fly, giving your team the confidence to validate them as part of the review process. Example usages The basic usage is --override-env =, and you can override multiple environments at once! In this example, we are running a pulumi preview with environments app/myenv and app/myenv2 replaced by their draft versions (denoted by @draft:). pulumi preview \ --override-env "app/myenv=app/myenv@draft:123e4567-e89b-12d3-a456-426614174000" \ --override-env "app/myenv2=app/myenv2@draft:123e4567-e89b-12d3-a456-426614174000" The --override-env flag not only works with draft references, but for any environment too! Here is an example of deploying your stack with your AWS test environment: pulumi up --override-env "aws-login/prod=aws-login/testing" Note: --override-env can also override environments that are imported (directly or indirectly) from the ESC environment in your stack config. This allows you to override any environment in the import chain for full flexibility. Ways to use it Validate a draft ESC environment with your stack before approving One-off debugging w ## The Standalone ESC CLI Retired: Use pulumi env DevFeed: [The Standalone ESC CLI Retired: Use pulumi env]() Original publisher: [Read original article]() Author: Boris Schlosser Published: 2026-07-22T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Command-line interface](), [configuration](), [Loop Engineering]() Tags: [cli](), [configuration](), [esc](), [features](), [migration](), [platform](), [product](), [release](), [secrets](), [with]() ### AI overview Pulumi is retiring the standalone Pulumi ESC CLI and recommends using the Pulumi CLI's pulumi env commands instead. The ESC repository has been archived, while the command implementation remains in the Pulumi CLI. Users of the standalone CLI should migrate because it will not receive the latest features. ### Source excerpt Pulumi ESC CLI v0.26.0 is the latest standalone release. We encourage users to use the Pulumi CLI instead. The ESC repository has been archived and the code now lives under pulumi. Why are we making this change Pulumi ESC is the best way to store and manage configuration and secrets in your Pulumi programs and while you can certainly use ESC to store secrets and configurations for your applications or to manage your AI agents' credentials, it's still a core feature of Pulumi Cloud, and we want to make sure we deliver a consistent experience across our entire suite. In addition to consistency, ESC and the Pulumi CLI share a lot of capabilities to interface to Pulumi Cloud and we want to make it easier and simpler for our customers: it's now easier to understand which Pulumi organization you are working with, which user is logged in, etc. Playing nicer with humans and AI agents A single CLI means one binary to install, one login to manage, and one place to look things up. This simplicity is beneficial whether the operator is a person or an agent. AI agents love code, and they love CLIs. By unifying the Pulumi CLI and ESC we offer a single place to look up operations around your Pulumi programs. Agents can now reason better about where to store configuration and secrets, without being confused by multiple CLI options that interface against the same service. Faster improvements With a shared CLI, any improvement to account management is automatically delivered to both: Pulumi and ESC users. At the same time, both benefit from ESC improvements and new features from day 1. ESC is a core component of our platform; a separate interface no longer makes sense. The same code all along If you're wondering what actually changes under the hood: nothing about how the commands work. The pulumi env commands were never a reimplementation -- the Pulumi CLI has built them from the ESC CLI's own code since ESC's first release, which is why the same command surface has always been availab ## Connect Your Cloud Accounts to Pulumi in Minutes DevFeed: [Connect Your Cloud Accounts to Pulumi in Minutes]() Original publisher: [Read original article]() Author: Levi Blackstone Published: 2026-07-15T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Cloud](), [Amazon Web Services](), [Azure](), [OpenID connect (OIDC)](), [Google Cloud Platform (GCP)](), [configuration](), [Authentication]() Tags: [aws](), [azure](), [cloud](), [configuration](), [esc](), [google-cloud](), [governance](), [identity](), [insights](), [openid-connect](), [policy](), [product](), [pulumi-cloud]() ### AI overview Pulumi introduces a Connect cloud accounts wizard for discovering and onboarding AWS accounts, Azure subscriptions, and Google Cloud projects in a single guided flow. It automates OIDC setup, creates Pulumi ESC environments, and applies discovery scans and policy packs. ### Source excerpt Pulumi Insights gives you visibility and governance across your entire cloud footprint, but that visibility is only as complete as the set of accounts you've connected. Until now, connecting an account meant repeating a manual setup for each one: OIDC configuration, hand-written Pulumi ESC environments, and per-account scan and policy setup. For an organization with dozens or hundreds of AWS accounts, Azure subscriptions, or Google Cloud projects, that per-account friction was the biggest obstacle to getting a complete picture. Today, the new Connect cloud accounts wizard removes it: discover every account in your cloud organization, select the ones you want, and onboard them all in a single guided flow. From hours of setup to a single flow The time savings are real: connecting a batch of accounts across AWS, Azure, and Google Cloud takes about three minutes end to end. Setting up those same accounts with the manual per-account workflow would take hours to days. The wizard handles the entire onboarding lifecycle for AWS, Microsoft Azure, and Google Cloud: Bulk discovery: Authenticate once with your cloud organization and the wizard lists every account, subscription, or project you can access. Accounts that are already connected are recognized and skipped. Automatic OIDC setup: The recommended flows configure each account with short-lived credentials based on OpenID Connect (OIDC) and workload identity federation. No long-lived cloud secrets are stored in Pulumi Cloud. ESC environments, created for you: The wizard generates Pulumi ESC environments that follow the best practices from the manual OIDC guides -- environments that previously had to be authored one by one. Scans and policies from day one: By default, scheduled discovery scans and a pre-built policy pack are applied to every account as part of setup: the Pulumi Best Practices pack on the Team and Enterprise editions, or a compliance pack (CIS, or NIST 800-53 for AWS and Google Cloud) on Business Critical. Ho ## Introducing ESC Secret Rotation Webhooks DevFeed: [Introducing ESC Secret Rotation Webhooks]() Original publisher: [Read original article]() Author: Sean Yeh Published: 2026-06-26T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [pulumi-esc](), [secret rotation](), [notifications](), [pulumi-cloud](), [pulumi-cli](), [TypeScript](), [GitHub]() Tags: [cli](), [esc](), [github](), [notifications](), [product](), [pulumi](), [pulumi-cli](), [pulumi-cloud](), [rotation](), [secret-rotation](), [secrets](), [slack](), [typescript](), [webhooks]() ### AI overview Pulumi introduces ESC secret rotation webhooks, which trigger on successful or failed environment secret rotations. They can notify teams in Slack, refresh services using old credentials, and help detect failed rotations before outages. ### Source excerpt Pulumi ESC centralizes your secrets and configuration, and it can automatically rotate secrets on a schedule so credentials never go stale. But a rotation is only useful if the systems that depend on it know it happened. ESC secret rotation webhooks close that gap by notifying you the moment a secret rotates. Introducing secret rotation webhooks With ESC webhooks, you can react to rotations automatically. When ESC rotates an environment's secrets, a webhook can be configured to trigger on either success or failure. Use it to notify your team in Slack, refresh services that hold the old credential, or catch a failed rotation before it causes an outage. How to configure Pulumi Cloud Console Using the Pulumi Cloud Console, you can now configure webhooks for "Environment rotation succeeded" and "Environment rotation failed" in your ESC Environment's Settings page (under Settings -> Notifications). Pulumi Service Provider You can use the Pulumi Service Provider in your Pulumi program to configure webhooks. Here is an example in TypeScript: const environmentWebhook = new service.Webhook("env-webhook", { active: true, displayName: "env-webhook", organizationName: "my-org", projectName: environment.project, environmentName: environment.name, payloadUrl: "https://example.com", filters: [WebhookFilters.EnvironmentRotationSucceeded, WebhookFilters.EnvironmentRotationFailed], }) Pulumi CLI You can also use the Pulumi CLI to configure the webhook: pulumi env webhook new my-org/project/env env-webhook \ --url https://example.com \ --event environment_rotation_succeeded \ --event environment_rotation_failed Get started Secret rotation webhooks are available now for all Pulumi ESC environments. See the webhooks documentation to get started, and share your feedback on our GitHub repository. ## Seven Rules for Building an AI-Native Software Factory DevFeed: [Seven Rules for Building an AI-Native Software Factory]() Original publisher: [Read original article]() Author: Adam Gordon Bell Published: 2026-05-21T13:00:00Z Content type: opinion Language: en Sources: [Pulumi]() Topics: [Artificial Intelligence](), [AI Development](), [Development](), [Software Engineering](), [Amazon Web Services]() Tags: [agentic-ai](), [agents](), [ai](), [ai-agents](), [aws](), [building](), [customers](), [engineering](), [esc](), [governance](), [infrastructure-as-code](), [pulumi-neo](), [software-development]() ### AI overview Ewan Dawson describes seven rules for building and operating an AI-native software factory, based on Compostable AI's experience. The article argues that organizations should redesign software workflows around autonomous agents, start with a focused team, involve governance and compliance early, and remove risks by changing the problem rather than adding controls. ### Source excerpt Ewan Dawson is CTO of Compostable AI, where five engineers run an AI-native software factory: nineteen clients, custom AWS deployments, most of them shipped within a day of contract signing. This article is adapted from his recent Pulumi webinar, and covers rules in more depth than we had time for on stage. For the past twenty years, I've viewed software development as a craft. The best engineers drew on decades of experience to get every function right. But two years into the agentic AI revolution, I realised software is going to look more like a factory than a craft. The economics have changed. We can't treat code as bespoke anymore. To scale, we have to think industrial -- use the tools to ship more value with fewer engineers. I joined Compostable AI soon after it was founded 2.5 years ago, and I built the engineering org AI-native from day one. The technology has come a long way since then, and so has my understanding of what AI-native actually means. Here are seven rules I keep coming back to. An AI software factory is a software operation where autonomous agents write and ship most of the code. The engineers stop writing it by hand and spend their time deciding what gets built and talking to customers. The rules below are our rules for building and running an AI-native software factory. 1. Transform, don't enhance Going AI-native isn't an upgrade to your existing process. If you treat AI as a way to hand your developers smarter tools, you leave most of the value on the table. You get the leverage by rebuilding how you write software -- and the culture and processes around it. I know that's a tall order for a large, mature engineering org. My advice: start small. Pick one team or one business area and run it as a fully AI-native function. Take what you learn and roll it out from there. And do the political work early, especially with your Governance, Risk, and Compliance function. Get GRC on your side early. Otherwise AI becomes a compliance fight instead of a st