# pulumi-cloud Published articles for pulumi-cloud. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Pulumi Context API: query your infrastructure as a graph DevFeed: [Pulumi Context API: query your infrastructure as a graph]() Original publisher: [Read original article]() Author: Levi Blackstone Published: 2026-08-26T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [API](), [Graphs](), [Cloud APIs](), [infrastructure as code (IAC)](), [Command-line interface](), [JSON](), [pulumi-neo]() Tags: [agent](), [ai-agents](), [api](), [cli](), [features](), [graph](), [iac](), [infrastructure-as-code-iac](), [json](), [product](), [pulumi](), [pulumi-cloud](), [pulumi-neo](), [rest-api]() ### AI overview Pulumi is launching the Context API, a read-only API that connects Pulumi-managed and discovered resources, stacks, and their relationships into a graph. Available in public preview for Enterprise and Business Critical organizations, it supports infrastructure-impact, coverage, and cleanup queries through the Pulumi CLI or REST API. Pulumi Neo uses it out of the box, and other authenticated agents can access its schema and query guidance. ### Source excerpt Every platform team fields the same questions: What is running? What breaks if we change this? What can we safely delete? The answers exist, but they're scattered across state files, cloud consoles, and the memories of whoever set things up. Today we're launching the Pulumi Context API, a read-only API that connects Pulumi-managed and discovered resources, stacks, and their relationships into a graph. It's designed agent-first: Pulumi Neo, our infrastructure agent, uses it out of the box, and other agents can fetch the current graph vocabulary and query guidance on demand. It's available in public preview for organizations on the Enterprise and Business Critical editions. Answers that follow infrastructure relationships Pulumi already records the resources your programs manage, their dependencies, how stacks consume each other's outputs, and the resources Pulumi Discovery finds outside infrastructure as code (IaC). The Context API connects this data so you can ask questions that depend on the relationships: Impact: Which stacks are affected if we upgrade this provider? If this stack changes, what consumes its outputs? Coverage: How much of our infrastructure lives outside IaC, and in which accounts? Cleanup: Which stacks have no dependents and are candidates for retirement? A query is a JSON document with a handful of clauses. anchor names the starting nodes, traverse follows relationships from there, and return chooses what comes back. You can run a query through the Pulumi CLI or REST API. Here's a selector that starts from AWS provider instances older than version 7.0.0 and follows incoming provided_by relationships back to the visible resources they manage: { "anchor": { "nodeType": "resource", "match": { "type": "pulumi:providers:aws", "fields": { "provider_version": { "op": "lt", "value": "7.0.0" } } } }, "traverse": [ { "edgeTypes": ["provided_by"], "direction": "in", "alias": "managed" } ], "return": { "select": ["anchor", "managed"] } } A response for one m ## Pulumi Introduces Notification Center for Pulumi Cloud DevFeed: [Pulumi Introduces Notification Center for Pulumi Cloud]() Original publisher: [Read original article]() Author: Tom King Published: 2026-08-11T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Cloud]() Tags: [console](), [email](), [esc](), [features](), [github](), [notifications](), [organization](), [product](), [pulumi](), [pulumi-cloud](), [pulumi-neo](), [real-time](), [review](), [slack]() ### AI overview Pulumi introduces Notification Center, an inbox in the Pulumi Cloud console for task completions, approval requests, and billing alerts. Notifications appear in real time, link directly to the required action, and can be delivered in the console or by email with per-type preferences. ### Source excerpt Plenty happens in a Pulumi organization while you're looking somewhere else. Neo finishes a task you kicked off just before taking lunch. A teammate submits an ESC change request that needs your approval before it can land. Until now, catching any of that meant either keeping the right tab open or hoping the right email reached you. Today we're introducing the Notification Center: a single inbox in the Pulumi Cloud console for the things that actually need you. It lives behind the bell in the sidebar, with a dot when something's waiting. Notifications arrive in real time -- no refresh -- and each one carries exactly one action: Review request, View task, Update billing. Click it and you land on the page where you can do the thing, not on a dashboard where you have to go find it. What you'll hear about We've started with the moments where being a few minutes late actually costs you something: a Neo task that's paused waiting on your approval, a Neo task that's finished, an ESC change request waiting on your sign-off, and billing conditions like a locked organization or a trial that's about to end. Relevant people in your organization will be notified when there's a pending approval, or billing alert. Nobody gets paged for someone else's work. Where you'll hear about it Every notification type can be delivered two ways -- in the console and over email -- and you choose per type, per channel. Organization admins set a sensible baseline for everyone; each person can override it for themselves on their account settings page. What's next The Notification Center is available today. We're starting with this set of notifications and expanding from there. If there's an event you'd rather hear about from the bell than from a colleague on Slack, we'd like to know which one. Join our Community Slack to connect with the Pulumi team and other users, or open an issue on our GitHub repository. ## Pulumi Cloud Adds Terraform Backend Support for Agentic Infrastructure DevFeed: [Pulumi Cloud Adds Terraform Backend Support for Agentic Infrastructure]() Original publisher: [Read original article]() Author: Daniel Perlovsky Published: 2026-08-04T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Terraform](), [Infrastructure as code](), [opentofu](), [Cloud](), [Deployment]() Tags: [agentic](), [agents](), [ai-agents](), [cloud](), [deployment](), [enterprise](), [hcl](), [iac](), [infrastructure-as-code](), [opentofu](), [platform](), [product](), [pulumi-cloud](), [terraform]() ### AI overview Pulumi announces general availability of Pulumi Cloud as a backend for Terraform state. The release supports existing Terraform deployment patterns while adding Pulumi Cloud capabilities such as remote runs, visibility, manual approvals, and scalable access management. ### Source excerpt At Pulumi, we are building the platform for agentic infrastructure. Pulumi Cloud provides the guardrails and enterprise readiness needed to safely move fast in this new era. While we are seeing extraordinary adoption -- over 40% of our users now manage infrastructure using AI agents -- we know many organizations are at different phases in their AI journey and have to balance building for the future with maintaining their existing infrastructure as code (IaC) solutions like Terraform. Today, we are launching three ways that Pulumi lets you avoid trading off building for the future against building for today. You don't have to rip out Terraform to enter the agentic era. Pulumi Cloud brings agentic infrastructure to the IaC estate you already have. What we're shipping today Last December, our CEO Joe Duffy laid out his vision to make Pulumi the platform for all of your infrastructure as code. The capabilities we are launching today make that promise a reality. Pulumi is now fully interoperable with Terraform and OpenTofu and enables organizations to build upon their existing IaC estate rather than starting from scratch as they work toward the agentic infrastructure future. Pulumi Cloud as a Terraform backend We are excited to announce the general availability of Pulumi Cloud as the backend to your Terraform state, enabling organizations to seamlessly lift and shift their existing Terraform estates. We recognize there is lots of infrastructure that works as is, and switching over to a new management paradigm may not always be possible. Pulumi Cloud support for the Terraform state backend lets organizations maintain their existing Terraform deployment patterns while also unlocking the power of Pulumi Cloud. The following common patterns for running Terraform are now supported: Plans and applies run remotely by default for new Terraform stacks, following the behavior of HCP Terraform and Terraform Enterprise. When you run a Terraform operation, it executes on a Pulumi-hoste ## A guided tour of Terraform state, hosted modules, and HCL in Pulumi DevFeed: [A guided tour of Terraform state, hosted modules, and HCL in Pulumi]() Original publisher: [Read original article]() Author: Christian Nunciato Published: 2026-08-04T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [Terraform](), [opentofu](), [Amazon S3](), [Command-line interface](), [Cloud](), [GitHub](), [Template]() Tags: [amazon-s3](), [aws](), [cli](), [github](), [hcl](), [how-to](), [infrastructure-as-code](), [modules](), [opentofu](), [pulumi-cloud](), [registry](), [s3](), [terraform](), [tutorials]() ### AI overview A hands-on walkthrough shows how to move a Terraform project that provisions an Amazon S3 bucket into Pulumi Cloud. It covers Pulumi Cloud as a Terraform state backend, hosted Terraform modules, and HCL authoring support, with references to OpenTofu and AWS. ### Source excerpt Today's big release contains a whole new set of features designed for seamless interoperability with the Terraform and OpenTofu ecosystems, and there's a lot there -- so much that it can be tough to get your head around all of it. But it generally falls into three major categories: Support for Pulumi Cloud as a Terraform state backend, including remote execution with human approvals A Terraform module registry in Pulumi Cloud that lets you publish, document, and share your modules even across language boundaries First-class support for HCL as an authoring language in the Pulumi engine To make this release a little easier to appreciate holistically, I've put together a quick end-to-end walkthrough that doesn't quite cover everything, but does cover the big stuff, and should give you a sense of how it all comes together. We'll start with a simple Terraform project that you'll deploy to AWS, and then one step at a time, bring it into Pulumi Cloud and kick the tires on each of these new features as we go. It'll take a bit, but all you'll need are a free Pulumi account and the ability to deploy an S3 bucket to AWS. We've got a bunch to cover, so let's jump right in. Start with a Terraform project Our tour begins with a tiny Terraform project that provisions a single Amazon S3 bucket using a locally defined module that we'll publish later. The project is available on GitHub as a template, and the easiest way to use it is with the GitHub CLI: $ gh repo create my-tf-project \ --template cnunciato/simple-tf-template \ --public \ --clone && cd my-tf-project We'll use the local Terraform backend to start. Set your AWS credentials (preferably with environment variables), then deploy the project with Terraform or OpenTofu. (This walkthrough uses the terraform CLI, but you can swap in tofu if that's your preference.) $ terraform init && terraform apply ... Apply complete! Resources: 2 added, 0 changed, 0 destroyed. Outputs: bucket_arn = "arn:aws:s3:::my-tf-project-bucket-14d19ece" ## Discovered Stacks: One Place for All Your Infrastructure DevFeed: [Discovered Stacks: One Place for All Your Infrastructure]() Original publisher: [Read original article]() Author: Alejandro Cotroneo Published: 2026-07-30T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Infrastructure as code](), [migration](), [AWS CloudFormation](), [Azure](), [Terraform](), [Cloud]() Tags: [aws-cloudformation](), [azure](), [cloud](), [deployment](), [features](), [fragmentation](), [governance](), [infrastructure](), [insights](), [migration](), [product](), [pulumi-cloud](), [terraform]() ### AI overview Pulumi launches Discovered Stacks, a Pulumi Cloud capability that models AWS CloudFormation stacks and Azure Resource Manager deployments alongside Pulumi stacks. It tracks resource migration status from live state and supports migration into Pulumi management with verification before changes are made. ### Source excerpt Today we're launching Discovered Stacks: Pulumi Cloud now models your AWS CloudFormation stacks and Azure Resource Manager deployments as stacks, right alongside your Pulumi IaC stacks. And when you're ready to bring them under Pulumi management, migration is built in, with every resource tracked until the code provably matches the cloud. Why: your infrastructure doesn't live in one tool Almost nobody's cloud estate is a single technology. There's the CloudFormation that came with the AWS account, the ARM templates from the Azure team, the Terraform from an acquisition, and the Pulumi you're standardizing on. Each tool has its own console, its own grouping, its own idea of state, and no single place shows you everything you run. That fragmentation is also why migrations stall. Moving a stack to Pulumi has never been the hard part; knowing where you stand is. The tracking lives in a spreadsheet, the spreadsheet goes stale the day it's written, and six months later nobody can say which of the 800 resources made it across and which were quietly forgotten. Nothing gets lost Discovered Stacks gives you confidence that your migration plan or governance efforts will include all resources. This catches a common failure mode where resources are missed by your existing migration scripts or automations. When Pulumi Insights scans your accounts, every CloudFormation stack and ARM deployment becomes a discovered stack, and every resource in it appears as a row with an explicit migration status: ready to migrate, requiring review before migration, or already migrated. Every status is computed from live state on both ends -- what Pulumi manages and what the source tool reports -- so it's never a stale annotation someone forgot to update. Each resource shows its origin type (AWS::S3::Bucket) next to its Pulumi type (aws:s3/bucket:Bucket), with the origin properties side by side with Pulumi's view, so you can verify that Pulumi sees exactly what your source tool sees before you change ## Migrate CloudFormation to Pulumi with Discovered Stacks DevFeed: [Migrate CloudFormation to Pulumi with Discovered Stacks]() Original publisher: [Read original article]() Author: Alejandro Cotroneo Published: 2026-07-30T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [Infrastructure as code](), [AWS CloudFormation](), [migration](), [Amazon Web Services](), [VPC](), [Amazon S3](), [DynamoDB](), [AWS IAM]() Tags: [aws](), [cloudformation](), [dynamodb](), [git](), [iac](), [iam](), [import](), [insights](), [kms](), [migration](), [pulumi](), [pulumi-cloud](), [pulumi-neo](), [s3](), [tutorials](), [vpc]() ### AI overview A tutorial shows how to migrate a 61-resource AWS CloudFormation stack to Pulumi using Discovered Stacks in Pulumi Cloud. It explains how to find the stack, review migration status, start the migration, resolve unmatched resources, and verify the result with a zero-diff pulumi preview. ### Source excerpt With Discovered Stacks, Pulumi Cloud does the bookkeeping for a CloudFormation migration: every resource in the stack gets an explicit migration status, and the migration is done when the code provably matches the cloud. In this tutorial, we take one real CloudFormation stack from discovered to migrated and managed by Pulumi IaC, end to end. What we're migrating Our example is payments-api, a CloudFormation stack with 61 resources: a VPC, an Aurora ledger database behind an RDS Proxy, an assets S3 bucket, a DynamoDB ledger table, a Kinesis payment-events pipeline, and the IAM roles, KMS keys, and secrets that wire them together. The plan has five steps: Find the stack in Pulumi Cloud. Review the migration breakdown at a glance. Start the migration. Resolve the stragglers, so every resource is accounted for. Confirm the quality gate: a zero-diff pulumi preview. We'll use Pulumi Neo to do the heavy lifting, but nothing here depends on it. The same flow works with your own coding agent or entirely by hand, because migration status is derived from actual stack state -- however the work gets done, the console shows the same progress. Step 1: Find your stack in Pulumi Cloud Discovered Stacks builds on Discovery, so the only prerequisite is a scanned cloud account -- the AWS account holding your CloudFormation stacks. Once a scan has run, open the Stacks page and turn on Show Discovered Stacks. Your CloudFormation stacks appear alongside your Pulumi stacks. The project name comes from the CloudFormation stack (payments-api), and the stack name encodes the account and region it came from, so the same template deployed to two regions shows up as two distinct discovered stacks. Step 2: Plan the migration at a glance Open the discovered stack's Migration tab. It lays out all 61 resources of payments-api by status, so you can visualize the migration before touching anything: 54 Ready: mapped to a Pulumi type and confirmed to exist -- importable right now. 2 Not found: mapped, but ## 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 Usage Limits for Pulumi Neo DevFeed: [Introducing Usage Limits for Pulumi Neo]() Original publisher: [Read original article]() Author: John Keiser Published: 2026-07-14T15:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [pulumi-neo](), [AI Agent](), [Artificial Intelligence](), [Cloud]() Tags: [agent](), [ai](), [ai-agent](), [ai-agents](), [billing](), [cloud](), [features](), [notifications](), [organization](), [product](), [pulumi](), [pulumi-cloud](), [pulumi-neo](), [token]() ### AI overview Pulumi introduces usage limits for Pulumi Neo, allowing paid-plan organizations to set monthly organization and per-member dollar limits. Neo pauses when a limit is reached, resumes in the next billing period, and supports email alerts at specified thresholds. ### Source excerpt Pulumi Neo is an AI agent that takes on real infrastructure work, and it's natural to want to hand it more and more. Usage limits give you control so you can do exactly that: set a monthly dollar limit, and Neo pauses when your organization reaches it. How usage limits work Your organization limit is a single monthly dollar amount covering all Neo usage across the org. To set one: In the Pulumi Cloud console, navigate to Settings -> Billing & usage -> Neo token usage. In the Manage token usage panel, enter an organization limit. Save your changes. When usage reaches the limit, Neo pauses for the rest of the billing period and resumes automatically at the start of the next one. An Admin or Billing Manager can raise the limit to resume before then. Enforcement happens at a natural boundary in Neo's work, so a task already in progress finishes its current step before pausing. As a result, usage can go a few dollars over the set limit. Per-member limits and alerts You can also set a separate limit for each member. A member is paused at whichever limit is smaller: their own or the organization's. For example, a member with a $200 limit under a $150 organization limit pauses at $150, because the organization limit is smaller. Turn on Enable email notifications to get a heads-up before you reach the limit. Billing admins are alerted at 50%, 80%, and 95% of the organization limit, with a final notice at 100% when Neo pauses. Get started Set your usage limits and stay in control as your organization hands Neo more and more work. Usage limits are available today for organizations on a paid plan, and an Admin or Billing Manager can set them. Sign in to Pulumi Cloud and set your first organization limit Read the Neo usage limits documentation for per-member limits, alerts, and enforcement details Join the Community Slack to share your feedback ## Pulumi ships a 238-policy ISO/IEC 27001:2022 pack for AWS DevFeed: [Pulumi ships a 238-policy ISO/IEC 27001:2022 pack for AWS]() Original publisher: [Read original article]() Author: Dan Biwer Published: 2026-06-30T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Amazon Web Services](), [Security](), [Cloud](), [configuration]() Tags: [audit](), [aws](), [compliance](), [crossguard](), [features](), [governance](), [infrastructure](), [iso](), [iso-27001](), [policy](), [policy-as-code](), [product](), [pulumi](), [pulumi-cloud](), [security](), [standard]() ### AI overview Pulumi announces a pre-built ISO/IEC 27001:2022 policy pack for AWS, available in Pulumi Cloud as iso-27001-aws. The pack contains 238 policies mapped to relevant ISO 27001 controls and supports auditing existing AWS resources and preventing non-compliant resources during pulumi up. ### Source excerpt ISO/IEC 27001 is the international standard for information security management. Proving you meet it usually means months of mapping abstract security controls to concrete cloud configuration, then authoring custom checks one resource at a time. We're changing that. Today we're shipping a pre-built ISO/IEC 27001:2022 policy pack for AWS, live now in Pulumi Cloud as iso-27001-aws. It encodes the standard's security expectations as 238 ready-to-run policies, so you can align your AWS estate to ISO 27001 in minutes, not months. Why ISO 27001 matters For many companies, ISO 27001 is what stands between them and a customer or a market. The sooner you can reach a certifiable state and prove you stay there, the less compliance slows the business down. The pack collapses months of policy work into something you run continuously, so security keeps pace with growth instead of blocking it. How the pack maps to ISO 27001 The hard part of ISO 27001 has always been translation: its controls are written in the language of governance and risk management, not in the language of AWS resources. Every team has had to interpret each control and decide what it means for an S3 bucket or an RDS instance. The pack does that interpretation for you. Its 238 policies are aligned to the relevant ISO 27001 controls, so each result connects back to the standard instead of leaving you to map it yourself. You can browse the full pack in the pack reference. Audit and prevent The same pack works two ways, so you can both reach compliance and stay there: Audit. Scan your existing AWS estate against the pack, including resources that Pulumi doesn't manage. You get an honest baseline of where you stand against ISO 27001 today, with every finding tied back to the control it affects. Prevent. Run the same pack as a preventative policy during pulumi up to block non-compliant resources before they're ever created. New infrastructure is born aligned to the standard. Audit gets you clean. Preventative policie ## Introducing ESC Secret Rotation Webhooks DevFeed: [Introducing ESC Secret Rotation Webhooks]() Original publisher: [Read original article]() Author: Sean Yeh Published: 2026-06-26T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [pulumi-esc](), [secret rotation](), [notifications](), [pulumi-cloud](), [pulumi-cli](), [TypeScript](), [GitHub]() Tags: [cli](), [esc](), [github](), [notifications](), [product](), [pulumi](), [pulumi-cli](), [pulumi-cloud](), [rotation](), [secret-rotation](), [secrets](), [slack](), [typescript](), [webhooks]() ### AI overview Pulumi introduces ESC secret rotation webhooks, which trigger on successful or failed environment secret rotations. They can notify teams in Slack, refresh services using old credentials, and help detect failed rotations before outages. ### Source excerpt Pulumi ESC centralizes your secrets and configuration, and it can automatically rotate secrets on a schedule so credentials never go stale. But a rotation is only useful if the systems that depend on it know it happened. ESC secret rotation webhooks close that gap by notifying you the moment a secret rotates. Introducing secret rotation webhooks With ESC webhooks, you can react to rotations automatically. When ESC rotates an environment's secrets, a webhook can be configured to trigger on either success or failure. Use it to notify your team in Slack, refresh services that hold the old credential, or catch a failed rotation before it causes an outage. How to configure Pulumi Cloud Console Using the Pulumi Cloud Console, you can now configure webhooks for "Environment rotation succeeded" and "Environment rotation failed" in your ESC Environment's Settings page (under Settings -> Notifications). Pulumi Service Provider You can use the Pulumi Service Provider in your Pulumi program to configure webhooks. Here is an example in TypeScript: const environmentWebhook = new service.Webhook("env-webhook", { active: true, displayName: "env-webhook", organizationName: "my-org", projectName: environment.project, environmentName: environment.name, payloadUrl: "https://example.com", filters: [WebhookFilters.EnvironmentRotationSucceeded, WebhookFilters.EnvironmentRotationFailed], }) Pulumi CLI You can also use the Pulumi CLI to configure the webhook: pulumi env webhook new my-org/project/env env-webhook \ --url https://example.com \ --event environment_rotation_succeeded \ --event environment_rotation_failed Get started Secret rotation webhooks are available now for all Pulumi ESC environments. See the webhooks documentation to get started, and share your feedback on our GitHub repository. ## Trigger Deployments on Git Tags DevFeed: [Trigger Deployments on Git Tags]() Original publisher: [Read original article]() Author: Michael Fallihee Published: 2026-06-05T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Deployment](), [Git](), [releases](), [ci](), [REST API](), [GitHub]() Tags: [announcements](), [azure](), [bitbucket](), [deployment](), [devops](), [features](), [git](), [git-tags](), [github](), [gitlab](), [product](), [pulumi-cloud](), [rest](), [rest-api](), [version-control]() ### AI overview Pulumi Deployments can now trigger stack deployments when matching Git tags are pushed. Teams can enable tag-based triggers, configure glob filters, and use the tag name in deployment commands or Pulumi programs. The feature works with GitHub, GitLab, Bitbucket, Azure DevOps, and Custom VCS integrations. ### Source excerpt 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 ## Generating a Pulumi Provider from an OpenAPI Spec DevFeed: [Generating a Pulumi Provider from an OpenAPI Spec]() Original publisher: [Read original article]() Author: Luke Ward Published: 2026-05-28T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [OpenAPI Specification](), [Infrastructure as code](), [API](), [SDKs]() Tags: [api](), [iac](), [infrastructure-as-code](), [openapi](), [product](), [pulumi](), [pulumi-cloud](), [release]() ### AI overview Pulumi announces version 1.0 of the Pulumi Service Provider, generated from the Pulumi Cloud OpenAPI specification. The release expands the provider's resource surface and adds infrastructure-as-code support for fine-grained RBAC, Pulumi IDP catalogs, and audit-log export. ### Source excerpt Today, we are announcing v1.0 of the Pulumi Service Provider: a major milestone in managing Pulumi Cloud with Pulumi itself. The provider is now generated directly from the Pulumi Cloud OpenAPI specification, unlocking a dramatically expanded pulumiservice:api/* resource surface and enabling Pulumi Cloud capabilities to become available in the provider faster than ever before. This release also brings several major new capabilities to infrastructure as code, including fine-grained RBAC as code, Pulumi IDP as code, and audit log export as IaC. Together, these changes make the Pulumi Service Provider the most powerful and extensible way yet to manage and automate your Pulumi Cloud infrastructure. Why this matters for users Historically, every new Pulumi Cloud feature implied a follow-up PR in the provider before that feature could be used from a Pulumi program. The provider was always slightly behind the API it wrapped, and entirely new capability areas could take months to land. The api/* surface changes both timelines. Because the schema is derived from the OpenAPI spec at runtime: Whole new resource families land in the provider the same release they reach Pulumi Cloud. New fields, features, and enum values on existing resources show up across all five language SDKs the soon after they appear in the spec. What's new in v1.0 v1.0 lifts whole capability areas of Pulumi Cloud into the api/* surface, not just incremental field additions. None of it required bespoke provider code. Fine-grained RBAC as code. Custom roles, organization membership, and team role assignments are now managed resources. For example, defining a read-only role and assigning it to a team: const readOnly = new ps.api.Role("readOnly", { orgName: "acme", name: "stack-reader", description: "Read-only access to stacks across the org.", uxPurpose: "role", details: { __type: "PermissionDescriptorAllow", permissions: ["stack:read", "stack:list"], }, }); new ps.api.teams.Role("readOnlyForPlatform", { org ## Bringing Neo to GitHub and Slack DevFeed: [Bringing Neo to GitHub and Slack]() Original publisher: [Read original article]() Author: Pulumi Neo Team Published: 2026-05-21T15:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [pulumi-neo](), [GitHub](), [Slack](), [Pull Request](), [configuration](), [Cloud]() Tags: [agent](), [ai](), [ai-agents](), [configuration](), [features](), [github](), [product](), [pull-request](), [pulumi-cloud](), [pulumi-neo](), [slack]() ### AI overview Pulumi Neo is now available in GitHub and Slack, extending its existing Pulumi Cloud console and terminal capabilities into team discussion threads. Users can ask Neo to inspect stack state, explain changes, investigate failures, and perform approved actions, with responses and follow-up work recorded in the relevant thread. ### Source excerpt 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