Pulumi Blog: Pulumi cloud

Connect Your Cloud Accounts to Pulumi in Minutes

Levi Blackstone — Wed, 15 Jul 2026 00:00:00 +0000

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:

Navigate to Management > Accounts in the Pulumi Cloud console and select Connect cloud accounts.
Follow the guided flow for AWS, Azure, or Google Cloud.
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

Enforce ISO 27001 Across Your AWS Infrastructure

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

ISO/IEC 27001 is the international standard for information security management. Proving you meet it usually means months of mapping abstract security controls to concrete cloud configuration, then authoring custom checks one resource at a time. We’re changing that.

Today we’re shipping a pre-built ISO/IEC 27001:2022 policy pack for AWS, live now in Pulumi Cloud as iso-27001-aws. It encodes the standard’s security expectations as 238 ready-to-run policies, so you can align your AWS estate to ISO 27001 in minutes, not months.

Why ISO 27001 matters

For many companies, ISO 27001 is what stands between them and a customer or a market. The sooner you can reach a certifiable state and prove you stay there, the less compliance slows the business down. The pack collapses months of policy work into something you run continuously, so security keeps pace with growth instead of blocking it.

How the pack maps to ISO 27001

The hard part of ISO 27001 has always been translation: its controls are written in the language of governance and risk management, not in the language of AWS resources. Every team has had to interpret each control and decide what it means for an S3 bucket or an RDS instance.

The pack does that interpretation for you. Its 238 policies are aligned to the relevant ISO 27001 controls, so each result connects back to the standard instead of leaving you to map it yourself. You can browse the full pack in the pack reference.

Audit and prevent

The same pack works two ways, so you can both reach compliance and stay there:

Audit. Scan your existing AWS estate against the pack, including resources that Pulumi doesn’t manage. You get an honest baseline of where you stand against ISO 27001 today, with every finding tied back to the control it affects.
Prevent. Run the same pack as a preventative policy during pulumi up to block non-compliant resources before they’re ever created. New infrastructure is born aligned to the standard.

Audit gets you clean. Preventative policies keep you clean.

A growing library of pre-built packs

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

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

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

Get started today

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

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

Try Pulumi policies

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

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

Trigger Deployments on Git Tags

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

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

Why tags?

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

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

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

How it works

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

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

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

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

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

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

Works across every VCS integration

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

Get started

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

To try it out:

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

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

Generating a Pulumi Provider from an OpenAPI Spec

Luke Ward — Thu, 28 May 2026 00:00:00 +0000

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", {
 orgName: "acme",
 teamName: "platform",
 roleID: readOnly.roleID,
});

read_only = pulumiservice.api.Role("readOnly",
 org_name="acme",
 name="stack-reader",
 description="Read-only access to stacks across the org.",
 ux_purpose="role",
 details={
 "__type": "PermissionDescriptorAllow",
 "permissions": ["stack:read", "stack:list"],
 })

pulumiservice.api.teams.Role("readOnlyForPlatform",
 org_name="acme",
 team_name="platform",
 role_id=read_only.role_id)

readOnly, _ := api.NewRole(ctx, "readOnly", &api.RoleArgs{
 OrgName: pulumi.String("acme"),
 Name: pulumi.String("stack-reader"),
 Description: pulumi.String("Read-only access to stacks across the org."),
 UxPurpose: pulumi.String("role"),
 Details: pulumi.Map{
 "__type": pulumi.String("PermissionDescriptorAllow"),
 "permissions": pulumi.StringArray{pulumi.String("stack:read"), pulumi.String("stack:list")},
 },
})

teams.NewRole(ctx, "readOnlyForPlatform", &teams.RoleArgs{
 OrgName: pulumi.String("acme"),
 TeamName: pulumi.String("platform"),
 RoleID: readOnly.RoleID,
})

var readOnly = new Ps.Api.Role("readOnly", new()
{
 OrgName = "acme",
 Name = "stack-reader",
 Description = "Read-only access to stacks across the org.",
 UxPurpose = "role",
 Details = ImmutableDictionary.CreateRange(new[]
 {
 new KeyValuePair<string, object>("__type", "PermissionDescriptorAllow"),
 new KeyValuePair<string, object>("permissions", new[] { "stack:read", "stack:list" }),
 }),
});

new Ps.Api.Teams.Role("readOnlyForPlatform", new()
{
 OrgName = "acme",
 TeamName = "platform",
 RoleID = readOnly.RoleID,
});

var readOnly = new Role("readOnly", RoleArgs.builder()
 .orgName("acme")
 .name("stack-reader")
 .description("Read-only access to stacks across the org.")
 .uxPurpose("role")
 .details(Map.of(
 "__type", "PermissionDescriptorAllow",
 "permissions", List.of("stack:read", "stack:list")))
 .build());

new com.pulumi.pulumiservice.api_teams.Role("readOnlyForPlatform",
 com.pulumi.pulumiservice.api_teams.RoleArgs.builder()
 .orgName("acme")
 .teamName("platform")
 .roleID(readOnly.roleID())
 .build());

resources:
 readOnly:
 type: pulumiservice:api:Role
 properties:
 orgName: acme
 name: stack-reader
 description: Read-only access to stacks across the org.
 uxPurpose: role
 details:
 __type: PermissionDescriptorAllow
 permissions:
 - stack:read
 - stack:list
 readOnlyForPlatform:
 type: pulumiservice:api/teams:Role
 properties:
 orgName: acme
 teamName: platform
 roleID: ${readOnly.roleID}

Pulumi IDP as code. services:Service makes the Pulumi IDP catalog manageable from your Pulumi programs, surfaced the same release IDP ships in Pulumi Cloud. Platform teams can publish service definitions as code rather than only through the IDP console.
Audit-log export as IaC. AuditLogExportConfiguration brings audit-log export sinks under Pulumi management with a real destroy path.

How it works

Pulumi Cloud’s OpenAPI document (published at https://api.pulumi.com/api/openapi/pulumi-spec.json) is embedded in the provider binary at build time, so the provider version you pin is the API surface you get. Preview and update are deterministic, and a version released today will still behave the same way years from now. Alongside the spec, the runtime loads a small companion metadata file that captures the Pulumi-specific semantics OpenAPI can’t express: which endpoints pair into a single resource, what a resource’s ID looks like, and which response fields are secrets that arrive exactly once at create time. That metadata is what lets api/* resources behave as expected.

Most of that metadata is auto-derived by a scaffolder, but the editorial layer, including resource descriptions, examples, and the v0 aliases that make migration safe, stays handmade. Any human override is pinned across regeneration so a future spec change can’t quietly override it. The language SDKs are still generated against the runtime schema, so new fields and enum values reach typed SDKs in all five languages the moment the spec ships.

What the api namespace covers

The api namespace already spans most of Pulumi Cloud’s resource model.

For resources that have an ancestor under pulumiservice:index:*, the mapping lives in docs/v0-api-coverage.md. That file is auto-generated, so it stays in sync. Each api/* resource ships hand-maintained per-language examples in TypeScript, Python, Go, C#, Java, and YAML.

What to know before adopting the preview

The pulumiservice:api:* resource surface is in preview. Resource shape and module layout may change before GA.

The existing pulumiservice:index:* resources remain supported. They are not being deprecated as part of v1.0 and continue to be supported. Migration to api/* is opt-in via Pulumi aliases.

Try it

If you want to take the expanded provider for a spin:

The Pulumi Registry page for pulumiservice has install instructions for every language.
The examples/api/ directory has runnable programs for each resource, in every supported language.
The pulumi-pulumiservice repo is open source if you want to read the runtime, the embedded spec, or the metadata file directly.

Feedback during preview is very beneficial. Please open an issue here if you run into any problems.

Connect Any Git or Mercurial Repo to Pulumi with Custom VCS

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

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

The problem

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

This meant:

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

How Custom VCS works

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

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

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

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

What’s supported

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

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

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

Neo support

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

Get started

To set up a Custom VCS integration:

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

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

Learn more

Pulumi Cloud REST API Docs, Now Generated from OpenAPI

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

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

Why this matters

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

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

What’s new

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

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

What this unlocks for agents

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

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

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

Same URL, existing links keep working

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

Try it out

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

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

Explore the REST API

Bitbucket Cloud Meets Pulumi Cloud

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

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

Deploy infrastructure from Bitbucket

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

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

Two ways to connect

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

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

Both methods register webhooks automatically — no manual configuration required.

Scaffold new projects from your repositories

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

Getting started

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

For full setup details, see the Bitbucket integration docs.

Connect your Bitbucket workspace

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

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

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

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

Why tag-based access control?

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

What’s new?

Tag-based access control

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

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

Team role assignments

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

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

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

User role assignments

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

How permissions work together

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

How to get started

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

1. Create a custom role with tag-based rules

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

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

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

2. Assign the role to a team

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

3. Assign a role to an individual user

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

Enforce tagging standards with Pulumi Policy

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

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

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

Availability

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

Conclusion

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

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

Learn more

Pulumi Cloud Now Supports Google Sign-In

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

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

Adding Google as an identity provider brings several benefits:

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

How it works

Signing up or signing in

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

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

Connecting Google to an existing account

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

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

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

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

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

Get started

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

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

For more details, see the Pulumi Cloud accounts documentation.

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

Expanded Version Control Support in Pulumi Cloud

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

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

Connect multiple providers and accounts

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

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

What your team can do

Deploy on every push

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

Preview changes on pull requests

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

Neo explains your changes

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

Let Neo open pull requests for you

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

Detect and fix drift

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

Secure authentication

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

Set up new projects from your VCS

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

Getting started

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

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

Connect your VCS

Now in Public Preview: Store Terraform State in Pulumi Cloud

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

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

This feature is now available in public preview.

Why this matters

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

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

What you get

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

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

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

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

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

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

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

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

How it works

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

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

Get started

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

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

Store Terraform State in Pulumi Cloud

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

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

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

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

What this means for you

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

Production results

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

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

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

What you need to do

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

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

Run Pulumi Insights on Your Own Infrastructure

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

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

Insights at a glance

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

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

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

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

Why self-hosted?

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

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

How it works

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

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

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

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

Get started

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

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

How We Built a Distributed Work Scheduling System for Pulumi Cloud

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

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

Where we started

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

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

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

We call this the background activity system.

Why not use an off-the-shelf queue?

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

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

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

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

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

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

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

Design constraints

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

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

The background activity

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

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

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

The state machine

Every activity follows the same lifecycle regardless of type:

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

The states fall into two groups:

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

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

Terminal states (work is done):

Completed, Failed, Canceled

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

Leases: distributed execution without coordination

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

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

How it works

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

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

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

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

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

Routing work to the right runner pool

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

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

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

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

Dependencies and multi-step workflows

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

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

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

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

Two execution modes, one interface

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

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

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

Putting it all together

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

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

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

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

Retries and scheduling

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

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

Observability

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

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

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

What we learned

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

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

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

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

Wrapping it up

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

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

Registry usage insights: know which stacks run which versions

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

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

From Individual to Organizational Visibility

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

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

What You Can See

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

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

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

Find What Matters with Filters

Three filters help you find packages that need attention:

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

Combine filters with search to find specific packages.

Browse All Packages in One Place

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

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

Why This Matters

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

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

Get Started

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

Announcing OpenAPI support for the Pulumi Cloud REST API

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

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

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

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

A single contract for the Pulumi Cloud REST API

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

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

How to get the spec

Send a GET request to:

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

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

Source of truth and stability

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

What we are building next

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

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

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

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

Manage Cloud Visibility and Governance with Infrastructure as Code

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

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

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

With these new resources, you can:

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

What’s New

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

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

Let’s explore each of these in detail.

Insights Accounts: Discover Your Cloud Resources

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

Key Features

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

Example: Creating an AWS Insights Account

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

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

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

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

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

import pulumi
import pulumi_pulumiservice as pulumiservice

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

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

package main

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

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

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

 return nil
 })
}

Policy Groups: Enforce Compliance at Scale

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

You can configure policy groups in two modes:

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

Example: Stack-Based Policy Group

Apply compliance policies to your Pulumi stacks:

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

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

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

Example: Account-Based Policy Group

Apply compliance policies to your cloud accounts for resource governance:

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

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

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

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

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

Querying Policy Packs

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

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

outputs:
 policyPacks: ${availablePacks}

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

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

export const policyPacks = availablePacks.policyPacks;

Getting Started

To start using these new resources:

Update the Pulumi Service Provider to the latest version:

npm install @pulumi/pulumiservice@latest

pip install --upgrade pulumi-pulumiservice

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

dotnet add package Pulumi.PulumiService

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

Learn More

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

Pulumi IAM Now Available for Self-Hosted Pulumi Cloud

Davide Massarenti — Wed, 14 Jan 2026 11:18:00 +0000

We’re excited to announce that Pulumi Identity and Access Management (IAM) is now available for self-hosted instances of Pulumi Cloud. This foundational security capability brings the same enterprise-grade access management we launched for Pulumi Cloud SaaS to organizations running Pulumi on their own infrastructure.

Enterprise Security for Self-Hosted Deployments

Self-hosted Pulumi Cloud customers can now leverage the full power of Custom Roles and Granular Access Tokens to implement Zero Trust security principles and least privilege access controls within their own environments. This means you can:

Define Custom Permissions with fine-grained scopes (e.g., stack:delete, environment:read) tailored to your organization’s security requirements.
Create Custom Roles by combining these permissions with specific Pulumi entities (Stacks, Environments, etc.).
Generate Scoped Organization Access Tokens that are precisely limited to the permissions defined in their associated roles, dramatically reducing the blast radius if credentials are compromised.

Secure Automation for On-Premises Infrastructure

This release is powerful for self-hosted Pulumi Cloud deployments where security and compliance requirements are often even more stringent. You can now:

Implement Least Privilege CI/CD: Scope pipeline tokens to only the actions and resources they absolutely need, ensuring your automation follows the same security standards as your infrastructure.
Enhance Compliance Posture: Demonstrate precise, auditable control over programmatic access to auditors and security teams.
Reduce Operational Risk: Limit the potential impact of compromised tokens by restricting them to specific roles and permissions.

Getting Started

Self-hosted customers can access IAM features through the same intuitive interface available in Pulumi Cloud SaaS. Navigate to Settings -> Access Management -> Roles to begin creating Custom Permissions and Custom Roles, then generate scoped Organization Access Tokens from Settings -> Access Management -> Access Tokens.

For detailed information about Pulumi IAM capabilities, including step-by-step guides and best practices, see our comprehensive announcement blog post.

Learn More

Explore the IAM & RBAC documentation to get started:

We’re committed to bringing enterprise-grade security features to all Pulumi deployments, whether in the cloud or on-premises. If you have questions or feedback, please reach out through your account representative or our GitHub repository.

Pulumi 2025: Neo, Next-Gen Policies, and Platform Engineering at Scale

Arun Loganathan — Mon, 22 Dec 2025 00:00:00 +0000

The era of AI-accelerated development has arrived, creating both unprecedented opportunity and unprecedented challenge. Developers ship code faster than ever, but platform teams struggle to keep pace. The velocity gap threatens to become a bottleneck.

As 2025 comes to a close, let’s look back at how we addressed this challenge.

This year, we took a giant leap forward to close that gap with several major innovations, including purpose-built AI for platform engineers, next-generation policy management that transforms governance into an accelerator, and the foundation for building Internal Developer Platforms that enable self-service without sacrificing control.

Pulumi Neo: Your Newest Platform Engineer
- AI-Assisted Development Everywhere
Next-Generation Policy Management: AI-Powered Governance at Scale
Internal Developer Platform: Self-Service Infrastructure at Scale
Secrets Management: Taming Sprawl at Scale
Identity and Access Management
Pulumi IaC
The Year Ahead

Pulumi Neo: Your Newest Platform Engineer

We launched Pulumi Neo, purpose-built AI specifically designed for platform engineering challenges. Neo fundamentally changed how platform engineers work.

The problem Neo solves is critical: while AI coding assistants have accelerated developers substantially, platform teams have struggled to keep pace. Every line of code that ships faster creates new platform needs - monitoring, secrets, pipelines, compliance checks. The velocity gap between development and platform teams was widening, threatening to become a bottleneck that would slow down entire organizations.

Neo levels the playing field by giving platform engineers their own dedicated AI tool. Unlike generic AI coding assistants that lack infrastructure context, Neo deeply understands cloud environments, infrastructure as code, secrets management, and the unique challenges platform teams face. It speaks their language and works within their constraints.

What makes Neo different is how it’s built. Neo operates on top of Pulumi’s existing platform capabilities - the same IaC, ESC, and policy features you already use for governance become Neo’s operational guardrails. It automatically respects your security and policy rules, works within your governance frameworks, and maintains the audit trails and compliance controls your organization requires. This isn’t experimental AI retrofitted with infrastructure plugins - it’s enterprise-ready intelligence built from the ground up on proven foundations.

Throughout the year, we enhanced Neo with capabilities that scale your team’s expertise. Custom Instructions and Slash Commands let you encode organizational standards once and Neo applies them automatically, while turning proven prompts into reusable shortcuts anyone can use. Operating Modes give you flexible control - from full review to autonomous execution. And full Pulumi CLI integration means Neo can handle complete infrastructure workflows, from stack operations to cloud CLI commands.

AI-Assisted Development Everywhere

Beyond Neo, we brought AI assistance directly into development workflows throughout the year. The Pulumi Model Context Protocol (MCP) Server connects AI-powered code assistants with Pulumi’s CLI and registry, enabling real-time resource information without leaving your editor. Use it with GitHub Copilot, Anthropic’s Claude Code, and Cursor to accelerate resource discovery and write infrastructure code faster. We enhanced this with remote MCP server support for centralized management and CLI AI extensions for intelligent command-line assistance.

Next-Generation Policy Management: AI-Powered Governance at Scale

With Neo giving platform teams AI superpowers, we needed to ensure AI-accelerated development remained safe and compliant. The challenge isn’t detecting security issues - it’s fixing them at scale. Most policy tools stop at detection, leaving teams with overwhelming backlogs and no scalable way to remediate violations.

We ended that compromise with the next generation of Pulumi Policies. This comprehensive governance solution moves beyond detection to deliver AI-powered remediation through a two-step lifecycle:

Get Clean: We introduced the Policy Findings Hub that gives every stakeholder their needed view - leadership sees compliance scores, auditors get control-centric compliance views, and platform teams get a collaborative workspace to triage and track remediation. Combined with audit scans, you get instant compliance baselines without blocking developers. Neo integrates directly into the Policy Findings hub to automate the fix itself, generating pull requests with exact code changes needed. For unmanaged resources, Neo even generates code to import the resource into a Pulumi stack and apply the fix.

Stay Clean: We launched pre-built compliance packs for CIS, NIST, PCI, and HITRUST across AWS, Azure, and Google Cloud. These out-of-the-box policy packs let you enforce industry-standard compliance frameworks immediately without writing custom policies. They act as universal guardrails by blocking non-compliant changes during deployment. Neo can even author new custom policies - ask Neo to “create a policy that prevents overly permissive IAM roles,” and it generates the code. This is how we make AI safe to go fast.

Internal Developer Platform: Self-Service Infrastructure at Scale

Platform engineering teams face a persistent challenge: they’re constantly responding to infrastructure requests instead of building the systems that enable self-service at scale. This reactive cycle prevents platform teams from doing their most valuable work - establishing patterns, codifying standards, and creating golden paths that empower developers without sacrificing control.

We delivered the foundation to break this cycle with Pulumi IDP. Pulumi IDP provides everything platform teams need to build world-class internal developer platforms. Codify organizational standards into reusable building blocks. Give developers simple, approachable interfaces that enforce best practices automatically. Transform platform engineering from reactive ticket-taking to strategic enablement.

The key is Pulumi Private Registry, your organization’s source of truth for golden paths and platform building blocks. Private Registry provides streamlined publishing workflows and simplified discovery, making it easy to share infrastructure abstractions across your organization. Combined with our expanded public registry (now over 150 providers and 7,500 resource types), you have comprehensive options for managing infrastructure across your entire cloud estate.

What makes this powerful is next-generation Pulumi Components with true cross-language support. Author infrastructure abstractions once in your preferred language, then consume them in any supported Pulumi language - including YAML for non-programmers, and soon, HCL. Components include built-in input validation, detailed documentation, and improved error messages. This means platform teams can reach every developer in their organization regardless of language preference, scaling their expertise without scaling their team.

Secrets Management: Taming Sprawl at Scale

The proliferation of secrets across modern cloud environments creates massive security risks. Long-lived credentials pose significant vulnerabilities. Secrets scattered across systems make it nearly impossible to track usage or enforce consistent policies. And manual rotation processes are error-prone and rarely done.

2025 saw significant expansion of Pulumi ESC to address these challenges across your entire secrets ecosystem:

Automated Rotation: We launched ESC Rotated Secrets, automatically rotating credentials like AWS IAM access keys on flexible schedules. This eliminates manual rotation effort and significantly reduces vulnerability windows. We expanded this with database credential rotation for PostgreSQL and MySQL, including support for databases in private VPCs via AWS VPC Lambda connectors.

Universal Integration: We integrated ESC with the secrets management platforms you’re already using:

Snowflake - Dynamic OIDC tokens for temporary authentication plus automated RSA keypair rotation
Infisical - Dynamic OIDC login and secret fetching from the open-source secrets platform
Doppler - OIDC access tokens and centralized secret fetching

For systems without native support, we launched ESC Connect, enabling you to build simple HTTPS adapters that integrate any custom or proprietary secret source with ESC.

These integrations let you maintain existing secrets infrastructure while gaining ESC’s centralized management, audit capabilities, and governance controls. You don’t have to rip and replace - ESC works with what you have.

Better Experience: We improved ESC usability throughout the year with streamlined onboarding, approval workflows for sensitive environments, and deletion protection to prevent accidents.

Security & Trust: For organizations with strict compliance needs like HIPAA or GDPR, we launched Customer-Managed Keys (BYOK). This allows you to bring your own encryption keys (via AWS KMS) to encrypt secrets stored in ESC, giving you full control over key lifecycles and revocation.

Identity and Access Management

Modern security demands unwavering trust in your security posture. How do you empower teams to deploy rapidly without opening doors to risk or violating compliance mandates?

We launched Pulumi IAM, embedding robust, granular security directly into your cloud development lifecycle. Pulumi IAM provides the unified framework for fine-grained authorization needed to confidently manage modern cloud infrastructure:

Custom Roles: Define reusable permissions with fine-grained scopes tailored to your organization’s specific needs
Least Privilege Enforcement: Control precisely who can do what on which specific resources, minimizing the impact if credentials are compromised
Secure Automation: Generate scoped access tokens for CI/CD pipelines with only the necessary permissions, eliminating over-privileged service accounts
Zero Trust Foundation: Verify every access request and grant minimum necessary access, implementing true Zero Trust principles

This foundational capability enables true least-privilege for CI/CD pipelines, reduces blast radius if tokens are compromised, and provides the compliance evidence auditors require. Platform and security teams finally have the fine-grained control needed to scale Pulumi usage securely across enterprise organizations without sacrificing velocity.

Pulumi IaC

Platform teams need IaC tools that keep pace with rapidly evolving cloud platforms while providing operational flexibility and reliability. This year we shipped hundreds of enhancements to Pulumi’s core IaC capabilities, from major cloud provider updates to new operational primitives that give teams more control over infrastructure lifecycles.

Cloud Provider Support

Managing multi-cloud infrastructure requires comprehensive provider support that keeps pace with rapidly evolving cloud platforms. This year we shipped major provider updates:

AWS Provider 7.0 brought game-changing improvements: manage resources across multiple AWS regions with a single provider instance, enhanced IAM role chaining with better error handling, and simplified S3 resource management.

Azure Native V3 delivered a 75% reduction in SDK size while maintaining 100% Azure ARM API coverage. Faster downloads, more manageable package sizes, and improved reliability.

Google Cloud Provider 9.0 brought updated API versions, new modules for AI and Google Gemini, and expanded resource support for the latest GCP services.

Direct Terraform Module Support was one of our most requested features. Execute Terraform modules directly in Pulumi without conversion, providing a seamless migration path for module-heavy projects.

Language Support

Java SDK 1.0 GA provides first-class Java support with feature parity to other Pulumi languages, support for all current LTS Java versions, and complete Automation API support.

Infrastructure Operations

Resource Hooks was one of our most requested features. Run custom code at any point in a resource’s lifecycle - before creation, after updates, before deletion. This unlocks scenarios like validation checks before deployment, triggering external systems when infrastructure changes, and custom logging and auditing.

We also shipped dependent resource replacements, excluding specific targets from stack operations, state taint capabilities, improved refresh and destroy experience for short-lived credentials, and CLI control through environment variables.

Kubernetes Operator

The Pulumi Kubernetes Operator 2.0 reached GA with a completely rewritten, faster codebase featuring enhanced reconciliation logic, better error handling, and automatic retry for temporary failures. We continued enhancing it with version 2.3.0 adding preview mode for validating infrastructure changes and structured configuration support for GitOps workflows.

The Year Ahead

2025 was the year we gave platform engineers the tools to thrive in the age of AI-accelerated development. We ended the impossible choice between velocity and control. We transformed governance from a blocker into an accelerator. We enabled self-service without sacrificing governance.

But this is just the beginning. The foundation we built this year sets the stage for even bigger innovations ahead. Neo will get smarter as it learns from infrastructure patterns across the community. Policy management will expand to more compliance frameworks. IDP will enable more sophisticated self-service workflows. ESC will integrate with more platforms.

The future of platform engineering is strategic, proactive, and AI-enabled. Platform teams won’t be bottlenecks - they’ll be the strategic enablers who make sustainable velocity possible.

Thank you for being part of the Pulumi community. Your feedback drives everything we build. We can’t wait to show you what comes next.

Want to try these features? Check out our documentation, join our community Slack, or contact us to discuss how Pulumi can transform your platform engineering practice.

Here’s to an incredible 2025, and an even better 2026!

Introducing Dark Mode for Pulumi Cloud

Kimberley Mackenzie — Wed, 17 Dec 2025 00:00:00 +0000

Pulumi Cloud helps teams manage and operate their cloud infrastructure in one place, from state and secrets to deployments, visibility, and policy enforcement.

For a long time, one request has consistently come up from the Pulumi community: dark mode. Today, we’re announcing that this request is now available in Pulumi Cloud.

Light mode and dark mode

Pulumi Cloud supports light mode and dark mode. You can switch themes at any time from the utility bar.

Below: Pulumi Cloud dashboard in light mode and dark mode

Light mode remains the default experience. Dark mode uses lighter text and UI elements on a darker background, which many users prefer for extended sessions or low-light environments.

This update is enabled by recent work from our User Experience team to introduce a shared design system across Pulumi Cloud. With that foundation in place, theming can now be applied consistently across pages and features.

Below: Pulumi Cloud resources page in light mode and dark mode

Dark mode allows you to opt into a theme that uses lighter text and graphics on a darker background. You can also choose to keep the current theme, now known as light mode.

How to enable dark mode

You can update your theme from the utility bar at any time.

Try out dark mode today

Want to try dark mode out for yourself? Sign in to your Pulumi Cloud account, or if you are new to Pulumi, create a free account.

We would love to hear your feedback. You can reach us in the Pulumi Community Slack or share requests in the public GitHub repo.

We look forward to hearing what you think of these changes!

Enforce AWS Organizations Tag Policies with Pulumi

Alejandro Cotroneo — Thu, 20 Nov 2025 10:00:00 -0800

Tags are the foundation of cloud governance, enabling cost allocation, ownership tracking, compliance reporting, and automation across your AWS infrastructure. Yet missing or inconsistent tags remain one of the most common governance challenges. Manual tag enforcement is error-prone, and discovering missing tags after deployment means your cost reports and compliance audits are already operating with incomplete data.

Today, we’re excited to announce a new pre-built policy pack created in partnership with AWS: AWS Organizations Tag Policies. This pack validates your infrastructure as code against tag policies configured in AWS Organizations, blocking deployments when required tags are missing and shifting tag governance left into your development workflow. Define your tag requirements once in AWS Organizations and enforce them consistently across all your Pulumi deployments.

How it works

The new policy pack integrates directly with your AWS Organizations Tag Policies as the single source of truth. No separate policy configuration or custom code required. When you run pulumi up, the pack retrieves your tag requirements from your AWS organization and validates that every resource has the required tags.

Start by enabling the pack in advisory mode to surface tagging violations in Pulumi Cloud’s Policy Findings hub without blocking deployments. This collaborative workspace allows your team to triage, prioritize, and systematically remediate missing tags. Once your infrastructure is compliant, switch to mandatory mode to prevent future non-compliant deployments.

Getting started

The pack works with both AWS Classic and AWS Native Pulumi providers, covering the full range of taggable AWS resources. To get started:

Configure tag policies in AWS Organizations following the AWS documentation.
Grant required permissions by adding the resourcegroupstaggingapi:ListRequiredTags permission to the IAM role or user that runs your Pulumi deployments.
Enable the pack in Pulumi Cloud:
1. From within your organization, navigate to the Policies tab
2. Under Policy Packs, select the Available tab
3. Select AWS Organizations Tag Policies and select Add to organization
4. From the Organizations tab, apply the policy to a Policy Group
Configure enforcement level: Set to advisory for warnings or mandatory to block non-compliant deployments.

Within minutes, every Pulumi deployment in your organization will validate tag compliance, ensuring that no resources are created without required tags.

Try it today

The AWS Organizations Tag Policies policy pack is now available to all Pulumi Team and Enterprise customers.

Get started with the integration
Learn about enforcing tag policies with AWS Organizations Tag Policies
Sign up for Pulumi Cloud if you’re new to Pulumi
Join the Community Slack to share feedback

We’re excited to partner with AWS on this capability and help organizations proactively enforce tag governance. Give it a try and let us know what you think!

New Audit Policy Scans for Pulumi Stacks

Levi Blackstone — Wed, 05 Nov 2025 00:04:00 +0000

Audit Policy Scans for Pulumi Stacks is part of the next generation of Pulumi Policies. This capability uses policies to run compliance checks against the last successful deployment state of your stacks, providing continuous compliance monitoring without impacting your existing CI/CD workflows.

Until now, Pulumi’s preventative policies have served as a critical “shift-left” gate, blocking non-compliant changes during pulumi up. While essential, this created challenges for organizations wanting to roll out new governance across thousands of existing stacks. This new evaluation mode solves that problem, giving you a complete and continuous view of your IaC compliance posture without the friction.

A Complete Audit Story: Cloud Accounts and IaC Stacks

Pulumi’s audit philosophy is to provide complete visibility across your entire cloud footprint. We achieve this through two complementary audit modes:

Audit Scans for Cloud Accounts (Existing): This capability scans your live cloud environments (like an AWS account or Azure subscription). Its primary purpose is to give you a holistic view of your security posture by discovering all resources, including those not managed by Pulumi, and detecting configuration drift. This is how you find unmanaged, legacy, or manually-created resources that violate your policies.
Audit Scans for Pulumi Stacks (New): The feature extends this audit power to the source of truth for your managed infrastructure: your Pulumi stacks. It evaluates the last successfully deployed state of your IaC. This allows you to get an instant compliance baseline of all your managed infrastructure without having to redeploy anything, making it perfect for frictionless policy rollouts at scale.

Together, these two audit modes give you a comprehensive picture of your entire cloud estate, all feeding into one unified Policy Findings hub.

Key Scenarios for Audit Scans for Stacks

This new evaluation mode for IaC stacks is designed to unlock policy adoption at scale and accelerate developer velocity. Key use cases include:

Gain an instant compliance overview across all existing stacks: Apply policies centrally and get immediate visibility into your compliance posture without requiring redeployment of every stack.
Accelerate policy rollouts: By decoupling policy evaluation from the critical deployment path, deployments become faster and developers are unblocked. Teams still get immediate feedback on the compliance of the deployed infrastructure.
Ensure continuous compliance: Evaluation is automatically triggered whenever policy configurations change. This ensures the latest policies are always evaluated against the latest deployed infrastructure.

How It Works

This new mechanism runs against the last known successfully deployed state of your IaC Stacks as recorded by Pulumi Cloud.

Evaluation is triggered automatically after a successful pulumi up or when a policy pack attached to the stack is updated.
Results are unified into the same Policy Findings hub you use today, giving you a single pane of glass for all preventative and audit policy findings.

How to Get Started

You can enable audit scans for your IaC stacks by adding them to an Audit Policy Group.

Navigate to the Policies tab in the left navigation bar of the Pulumi Cloud console.
Create a new Audit Policy Group or select an existing one.
Select Pulumi Stacks and add the specific stacks you want to monitor.
Add Policy Packs to the group.
Save the policy group. That’s it!

The next time any of the selected stacks completes a pulumi up, a post-deployment evaluation will be automatically triggered, and the results will populate in the Policy Findings hub.

Audit policy scans consume workflow minutes from your Pulumi Cloud plan. Each scan counts toward your monthly quota based on the complexity and number of resources evaluated. See pricing documentation for details.

A Complete Governance Picture

With the addition of post-deployment evaluation for IaC stacks, you now have a complete, 360-degree view of your cloud environment. You can use audit scans for cloud accounts to get a handle on your entire live footprint, and use audit scans for stacks to easily assess your IaC-managed footprint without adding friction to your development process.

Try Pulumi Policies

Ready to try these features?

Sign up for Pulumi Cloud and start a Neo task
Read the Get Started guide to continuously scan resources and identify violations
Join the Community Slack to share feedback on the new features

For complete documentation, visit our Policies documentation.

Policy Findings Hub: Move From Alert Fatigue to Action

Alejandro Cotroneo — Wed, 05 Nov 2025 00:03:00 +0000

For platform and security teams, enabling robust cloud scanning often creates a new problem: an unmanageable firehose of policy alerts. Identifying a violation is only the first step. Without a system to manage the lifecycle of these findings, teams are quickly overwhelmed, leading to prioritization paralysis and a perpetually growing backlog.

The Policy Findings hub in Pulumi Cloud is the solution to this alert fatigue. It’s a purpose-built, collaborative workspace that turns a noisy list of violations into organized, actionable tasks. The hub brings clarity and structure to the compliance process, guiding teams from initial discovery to a verified fix.

From Raw Data to Actionable Insights

The Policy Findings hub is designed with distinct views for every stakeholder involved in the governance lifecycle.

1. The Overview Tab: A Dashboard for Leaders

For a platform lead or security manager, the goal is to understand the big picture. The Overview tab provides a high-level dashboard of your organization’s compliance health, answering key questions at a glance:

What is our overall resource compliance score?
Are we trending in the right direction?
Which parts of our cloud infrastructure (stacks, accounts, etc.) carry the most risk?

This view helps leadership track progress and make data-driven decisions about where to focus engineering efforts.

2. The Compliance Tab: The Auditor and Infosec Workspace

For the infosec members and auditors, context is everything. Simply listing thousands of violations is not helpful. The Compliance tab provides a policy-centric view, grouping all findings by the specific control they violated (e.g., a specific rule within CIS or NIST).

This is crucial when preparing for an audit or assessing adherence to a specific security framework, as it allows you to see exactly where you are compliant and where you have gaps, control by control.

3. The Issues Tab: The Team’s Daily Workspace

This is the space where insight is turned into action. The Issues tab is a collaborative triage board designed for the day-to-day workflow of platform and development teams. It provides the full toolset needed to manage the lifecycle of an issue from start to finish:

Triage and Prioritize: Filter issues by severity, resource type, or policy to focus on what matters most. Set a priority level from P0 (critical) to P4 (low).
Assign Ownership: Assign issues to specific team members to ensure clear ownership and accountability.
Manage Lifecycle: Mark an issue as “Ignored” with a justification. This is a critical workflow for acknowledging intentional exceptions, which cleans up your dashboard and allows the team to focus on legitimate issues.

And for the most critical part of the workflow — the fix itself — we’ve integrated our AI agent, Pulumi Neo, directly into this view.

After selecting one or more issues, your team can assign the task to Neo. It will analyze the violations and automatically generate a pull request with the necessary code changes. For unmanaged resources, Neo will even generate the code to import them into Pulumi and apply the fix. This turns a complex manual task into a simple review-and-merge process, allowing your team to finally burn down the backlog.

Turning Alerts into Action

Effective governance goes beyond identifying violations. It requires a structured system that turns every finding into a clear and trackable path to resolution. The new Policy Findings hub provides that end-to-end workflow, from visibility to accountability to automated remediation.

By organizing policy data into meaningful views and integrating Pulumi Neo directly into the issue management process, teams can move past alert fatigue and focus on what matters most: fixing problems quickly and maintaining continuous compliance.

This new experience is now available. Navigate to the Policies > Findings tab in the Pulumi Cloud to explore your new compliance dashboard and start turning alerts into action.

Try Pulumi Policies

Ready to try these features?

Sign up for Pulumi Cloud and start a Neo task
Read the Get Started guide to manage compliance across your cloud infrastructure
Join the Community Slack to share feedback on the new features

For complete documentation, visit our Policies documentation.

New Compliance Packs for CIS, NIST, and PCI DSS

Luke Ward — Wed, 05 Nov 2025 00:02:00 +0000

Achieving compliance with industry standards such as CIS, NIST, or PCI DSS is a foundational step for every organization. Yet for many teams, it’s often a manual, months-long process that involves interpreting controls, authoring custom policies, and validating configurations across multiple clouds. These challenges often slow progress toward a known and secure cloud state.

We’re changing that. To simplify this journey, Pulumi launched a new suite of pre-built compliance policy packs for CIS Controls v8.1, NIST SP 800-53 Rev. 5, and PCI DSS v4.0.

These packs are your accelerator for the “Get Clean” journey, allowing you to enforce critical security and compliance baselines across your cloud infrastructure in minutes, not months.

More Than Just Detection: The Complete Governance Lifecycle

Traditional security tools are reactive, scanning for problems after resources have been deployed. With Pulumi, these new compliance packs are the engine for an end-to-end governance lifecycle that integrates directly into your cloud operations.

Audit for Full Coverage: Run these packs in audit mode to scan your entire cloud estate, including resources managed by Pulumi and those created through other means. This gives you an instant, comprehensive view of your current compliance posture.
Triage and Remediate: When a pack finds a violation, the finding appears in the new Policy Findings hub. From there, your team can triage, assign, and track the issue through its entire lifecycle. And with our new AI-powered capabilities, you can assign the issue to Pulumi Neo to automatically generate a pull request with the fix.
Prevent Non-Compliance: Once your environment is clean, you use these same packs as preventative guardrails. By running them during pulumi up, you block non-compliant resources before they are ever created, ensuring you “Stay Clean.”

This tri-modal capability—Audit, Remediate, and Prevent—is uniquely powerful, allowing you to fix existing issues while stopping new ones from being introduced.

New and Expanded Compliance Packs

Our new policy packs provide extensive, out-of-the-box coverage for some of the most widely adopted security frameworks. They are authored and maintained by Pulumi experts and join our existing library to provide a comprehensive toolkit for cloud governance.

Framework	AWS	Azure	Google Cloud
CIS Controls v8.1	✅	✅	✅
NIST SP 800-53 Rev. 5	✅
PCI DSS v4.0	✅
HITRUST CSF v11.5	✅	✅	✅
Pulumi Best Practices	✅	✅	✅

Benefits of Pre-Built Packs

Accelerate Compliance: Implement comprehensive governance controls in minutes without authoring hundreds of policies from scratch.
Leverage Expert Knowledge: Packs are authored and maintained by Pulumi, incorporating deep expertise in cloud and the nuances of each framework.
Codify Controls for Audits: Demonstrate to auditors that specific compliance controls are consistently enforced through code, providing a clear evidence trail.
Reduce Risk Proactively: Catch common security risks and compliance violations before deployment, drastically reducing your organization’s exposure.

Get Started Today

These policy packs are available now and are the perfect way to begin your governance journey with Pulumi.

To get started, head to the Policies page in your Pulumi Cloud organization and click on the All tab to find these new packs. Add them to an Audit Policy Group and run a scan. Within minutes, you’ll see a complete picture of your compliance posture in the Policy Findings hub, ready for triage and remediation.

Need a compliance pack for a standard that isn’t listed here? Please let us know by raising a request on our GitHub repository.

Try Pulumi Policies

New to Pulumi? Start your governance journey today.

Sign up for Pulumi Cloud and start a compliance task with Neo
Read the Get Started guide to apply and manage policies across your cloud infrastructure
Join the Community Slack to share feedback on the new features

For complete documentation, visit our Policies documentation.

Policy Comes to Team and Enterprise, with New Out-of-the-box Policies and Management Experience

Luke Ward — Wed, 17 Sep 2025 00:00:00 +0000

Pulumi’s Infrastructure as Code has included a powerful policy engine from day one. Over the past year, we’ve been enhancing it significantly to provide stronger governance for modern cloud platforms. Until now, these capabilities were limited to our Business Critical tier. Today, we’re excited to announce that policy guardrails are now available to all Team and Enterprise customers. Alongside this, we’re launching a redesigned policy management experience and introducing out-of-the-box policy packs that make it easier than ever to secure, govern, and optimize your cloud environments—even when powered by AI agents like Pulumi Neo.

Policy as Guardrails for AI Infrastructure

As developer velocity accelerates, AI agents like Neo are helping teams create and manage infrastructure at unprecedented speed. That speed creates a governance challenge: how do you ensure security, compliance, and cost-effectiveness without slowing developers down?

Policy guardrails provide the answer. Pulumi’s Policy as Code (PaC) framework applies DevOps best practices to governance, letting you codify rules, test them through pull requests, and version them alongside your infrastructure. With policies in place, you can ensure that every change stays within your organization’s standards, whether it is a human developer or Neo making a change.

What Makes Pulumi Policy Different

Unlike many other policy solutions, Pulumi Policy uses general-purpose programming languages such as TypeScript and Python rather than restrictive DSLs or YAML. This unlocks richer and more flexible capabilities, including:

Conditional logic to codify your organization’s nuanced rules.
Reusable functions and abstractions to create a shared library of policies.
Unit tests to validate policy behavior before rollout.

With today’s updates, this foundation is easier to adopt and scale across your teams than ever before.

New Simplified Experience

While Pulumi Policy has always allowed you to enforce compliance using TypeScript and Python, the existing workflow could be cumbersome—discovering policies required switching between the console and CLI, and applying them involved multiple steps.

We’ve removed that friction to provide the seamless guardrails needed for this high-velocity, AI-driven world. The new experience is built around a streamlined, in-console workflow for discovering, applying, and managing your policies.

In-Console Discoverability

We are making it easier to find and understand policy packs. You can now browse a rich set of pre-built policy packs directly within the Pulumi Cloud console—no CLI or context switching required.

You’ll find:

A rich browsing experience: See all available policy packs in one place.
Detailed information: Each pack comes with a clear description of the policies included.
Organization-approved packs: Org admins can curate a list of approved policy packs, ensuring your teams—and AI agents like Neo—are using a vetted set of policies.

New Pre-Built Policy Packs

To help you establish guardrails immediately, we have authored several pre-built policy packs. We are excited to highlight two that are available today:

Pulumi Best Practices: A foundational set of recommended governance and security controls that serves as a strong starting point for any organization.
HITRUST CSF v11.5: Provides predefined controls that help align cloud resources with HITRUST CSF requirements.

Streamlined Policy Management and Application

The new policy management experience dramatically simplifies policy application:

Intuitive Interface: Browse, select, and apply policies through a streamlined workflow using Policy Groups to bundle related policies and apply them to your stacks or cloud accounts.
Expanded Scale: We’ve eliminated the 4,000 stack UI limit on policy groups, allowing you to scale policies across your entire infrastructure.
Granular Enforcement: Configure the enforcement level (advisory or mandatory) for policies to either warn developers or block non-compliant deployments entirely.

Preventative and Audit Approaches

Pulumi Policy supports two complementary approaches to governance.

Preventative policies: Block non-compliant deployments during pulumi up, providing real-time guardrails for developers and AI agents.
Audit policies: Continuously scan existing resources for ongoing compliance monitoring, giving you a complete picture of your cloud security posture.

This dual approach ensures new deployments meet standards while maintaining visibility across your entire infrastructure. Learn more in our Preventative vs. Audit Policies guide.

How to Get Started

Getting started with the new policy management experience is straightforward:

Browse Policy Packs: Navigate to the Policies tab in your Pulumi Cloud console to discover pre-built policy packs like Pulumi Best Practices and HITRUST CSF. Learn more about Policy as Code configuration and setup.
Choose Your Approach: Decide whether you need preventative policies (to block non-compliant deployments during pulumi up) or audit policies (for continuous compliance monitoring across all cloud resources).
Create Policy Groups: Set up policy groups to bundle related policies and apply them to your stacks or cloud accounts.
Configure Enforcement: Set enforcement levels (advisory, mandatory, or remediate) for each policy based on your requirements.

Now Available To Team and Enterprise Customers

To ensure every organization can build with confidence, these policy management enhancements and the pulumi-best-practices policy packs are now available to Team and Enterprise customers. Checkout our pricing page for more information.

Conclusion

Governance doesn’t need to be a roadblock—it can be a foundation that accelerates innovation. With enhanced policy management and ready-to-use guardrails, Pulumi helps your teams and AI agents like Neo move fast while staying secure, compliant, and cost effective.

Try the new experience in Pulumi Cloud today, and let us know what you think in the Pulumi Community Slack.

Unified Resources in Pulumi Cloud

Pulumi Insights Team — Mon, 08 Sep 2025 09:00:00 -0800

We’re excited to announce unified resources in Pulumi Cloud. This powerful new feature automatically consolidates resources from multiple sources into single, comprehensive views. When the same AWS S3 bucket, Azure VM, or Google Cloud database appears in both your IaC stacks and Pulumi Insights, you’ll now see one unified entry instead of duplicates cluttering your search results.

Why We Built This

Cloud resources naturally exist across multiple contexts in modern organizations. The same S3 bucket might be imported into a Pulumi stack, discovered by Pulumi Insights, and referenced in multiple projects. Previously, this created fragmented views with duplicate search results that made it difficult to understand your true infrastructure footprint.

Teams told us they needed a way to see the complete picture of each resource without manually correlating information across different sources. They wanted accurate resource counts, clear visibility into management states, and faster access to all relevant information when troubleshooting issues.

Unified resources solve these challenges by automatically detecting when the same cloud resource appears across multiple sources and consolidating them intelligently.

How It Works

When you search for resources in Pulumi Cloud, our system now automatically identifies duplicates across all sources including:

Resources managed by Pulumi IaC
Resources imported into Pulumi stacks
Resources discovered through Pulumi Insights including resources managed outside of Pulumi IaC

Resources with multiple sources are marked with a distinctive icon in search results. This visual indicator lets you immediately identify which resources have rich, multi-source information available.

The consolidation happens automatically. Your existing workflows continue unchanged, but now with cleaner, more actionable results.

The New Unified Resource Details Page

The centerpiece of this release is the completely redesigned resource details page. Previously, clicking on a resource from different sources led to separate, disconnected views. Now, every resource has a single, unified details page that brings together all available information.

Complete Source Visibility

The new details page shows every source where a resource appears:

Pulumi stacks: See which stacks manage or import this resource
Insights accounts: View all cloud accounts where the resource was discovered
Source metadata: Access provider details, last update times, and source-specific details

Comprehensive Property Views

Compare resource properties across all sources to:

Detect configuration changes between IaC definitions and actual cloud state
View complete metadata from both IaC and cloud discovery
Track property changes over time

Key Benefits for Your Team

Accurate Infrastructure Inventory Get an accurate view of your resources without manual deduplication. Understand exactly what’s running in your cloud accounts and how resources are distributed across regions and projects.

Enhanced Compliance Visibility Instantly identify which resources are managed by IaC versus those created outside your governance processes. Track your progress in bringing unmanaged resources under control.

Faster Incident Response When investigating issues, find all relevant information about a resource in one place. No more switching between multiple views or manually correlating data from different sources.

Learn More

Unified resources are available now for all Pulumi Cloud users. Ready to see unified resources in action? Check out these resources:

Resource search documentation for search tips and filtering options
API reference for programmatic access
Pulumi Insights overview for the complete platform capabilities

We’d love to hear your feedback as you explore unified resources. Share your thoughts in the Pulumi Community Slack or connect with your customer success team.

Start exploring your unified resource inventory today in Pulumi Cloud.

Announcing Pulumi Identity and Access Management (IAM)

Germán Lena — Mon, 09 Jun 2025 00:00:00 +0000

Cloud development is accelerating at an unprecedented pace, fueled by AI and the relentless drive for innovation. But this incredible speed demands unwavering trust in your security posture. How do you empower teams to deploy rapidly and frequently without opening doors to risk or violating compliance mandates? Today, we’re thrilled to answer that critical challenge by introducing Pulumi Identity and Access Management (IAM) – a foundational new capability designed to embed robust, granular security directly into your cloud development lifecycle, enabling you to innovate both quickly and safely with Pulumi. Pulumi IAM provides the unified framework for fine-grained authorization needed to confidently manage modern cloud infrastructure and applications across the entire Pulumi Cloud platform.

Our Vision for Pulumi IAM

Pulumi IAM is a foundational investment, delivering enterprise-grade access management through a phased approach. Today’s release marks the beginning, with much more planned:

Phase 1: Granular Access Tokens & Custom Roles (Available Today)
- Define custom, reusable Permissions with fine-grained scopes (e.g., stack:delete only).
- Create Custom Roles by combining Permissions with specific Pulumi Entities (Stacks, Environments, etc.).
- Generate Organization Access Tokens scoped precisely to these Custom Roles, perfect for secure automation.
Phase 2: User & Team Role Assignment (Coming Soon)
- Leverage OIDC configuration to dynamically assume Custom Roles for secure, tokenless authentication from CI/CD systems like GitHub Actions, GitLab, and more.
- Assign these powerful Custom Roles directly to individual users and teams within your Pulumi organization.
- Implement a complete overhaul of user and team access management, moving beyond the basic Admin/Member distinctions, and enabling reusability of custom building blocks permissions and roles that work for your organization
Phase 3: Advanced Authorization & Scalability (Future Release)
- Introduce Attribute-Based Access Control (ABAC), allowing policies based on tags or other attributes of Pulumi Entities (e.g., “grant ‘dev-role’ access to all stacks tagged ’env:dev’”).
- Enable the creation of Custom RBAC Policies with conditional logic for highly specific access scenarios and reuse them
- Provide mechanisms to manage permissions across hundreds or thousands of Pulumi Entities efficiently.

A Foundation for Zero Trust & Unified Security

Pulumi IAM isn’t just another feature; it’s a foundational pillar underpinning security across the entire Pulumi Cloud ecosystem, enabling organizations to implement Zero Trust principles for their infrastructure management. Modern security models assume breaches will happen and demand rigorous verification for every access request. Static, organization-wide roles no longer suffice where separation of duties, least privilege, and compliance are paramount.

Pulumi IAM addresses these challenges by providing:

Least Privilege Enforcement: Define precisely who can do what on which specific resources, minimizing the potential impact if credentials or accounts are compromised. This is core to Zero Trust – grant only the minimum necessary access, verified at the point of action.
Granular Control Across Pulumi:
- Infrastructure as Code (IaC): Apply fine-grained controls over Pulumi Stacks
- Secrets Management: Define specific access levels for Pulumi ESC Environments.
- Insights: Manage permissions for Pulumi Insights account settings.
Secure Automation: Provide secure, least-privilege tokens and OIDC integration for CI/CD pipelines and automation, drastically reducing the risk associated with over-privileged service accounts.
Unified, Scalable Governance: Establish a consistent authorization model that simplifies administration and scales from small teams to complex enterprise environments, ensuring security doesn’t hinder velocity.

Launching Today: Granular Access Tokens via Custom Roles

This vision begins today with the initial phase of Pulumi IAM, enabling you to define Custom Roles built from fine-grained Permissions and apply them specifically to Organization Access Tokens. This initial step provides immediate, significant security benefits, particularly for automation:

True Least Privilege for CI/CD: Scope pipeline tokens to only the actions (e.g., pulumi up) and Entities (e.g., stack: myapp-prod) they absolutely need.
Reduced Blast Radius: If a scoped token is compromised, the potential damage is limited strictly to the permissions defined in its associated role.
Enhanced Compliance: Demonstrate precise control over programmatic access to auditors.

How to Get Started with Granular Access Tokens

Configuring and using Custom Roles for scoped tokens is done via the Pulumi Cloud console:

1. Define a Custom Permission (Optional)

Create reusable sets of fine-grained scopes.

As an admin, navigate to Organization Settings -> Roles -> Permissions
Follow instructions for creating a custom permission.

2. Create a Custom Role

Combine permissions with specific resources.

As an admin, navigate to Organization Settings -> Roles
Follow instructions for creating a custom role.

3. Generate a Scoped Organization Access Token

Generate an organization access token with narrowed scope.

As an admin, navigate to Organization Settings -> Access Tokens -> Organization Access Tokens.*
Click “Create token”. Provide a description. Select your Custom Role from the “Role” dropdown. Generate the token.

New Scenarios Unlocked Today

This release immediately enables more secure and compliant workflows:

Secure Multi-Environment CI/CD: A single pipeline can use different tokens based on the target environment (dev, staging, prod), each assuming a role with appropriately restricted permissions (e.g., read-only for prod dependencies, write for the target stack).
Restricted Operational Scripts: An automation script designed only to read audit logs can use a token tied to a role granting only audit_log:read permission, preventing accidental or malicious modifications.
Safer ChatOps & Tooling: Integrations like ChatOps bots can operate with tokens scoped down to only necessary actions (e.g., triggering a pulumi preview on specific stacks).

Available Today: Custom Permissions, Custom Roles, and the ability to scope Organization Access Tokens using these roles, is available now for customers on the Pulumi Enterprise and Pulumi Business Critical tiers. Explore these features in your Pulumi Cloud organization settings!

Conclusion: Building a More Secure Future

Pulumi Identity and Access Management (IAM) represents a fundamental advancement in securing cloud development lifecycles managed by Pulumi, providing the controls needed to confidently embrace speed and scale. Today’s launch of Granular Access Tokens via Custom Roles provides immediate security improvements for automation and programmatic access, laying the vital groundwork for our comprehensive IAM vision rooted in Zero Trust principles.

This empowers platform and security teams with the fine-grained control needed to implement least privilege, enhance compliance, and scale Pulumi usage securely without sacrificing velocity.

We encourage our Enterprise and Business Critical customers to explore Custom Roles and Granular Access Tokens today. Dive into the documentation and start building roles tailored to your security requirements. We welcome your feedback and feature requests in our GitHub repository. Join us as we build a more secure foundation for cloud engineering!

Learn More

Learn more about Pulumi Cloud’s new IAM & RBAC features:

Why Choose Pulumi Cloud Over DIY Backends?

Aaron Kao — Wed, 19 Mar 2025 09:00:00 -0700

Note: This post discusses Pulumi Copilot, which Pulumi Neo has replaced. Learn about Neo →

Pulumi Cloud empowers engineers to automate, secure, and manage modern infrastructure platforms.

Many companies are building internal developer platforms or modern infrastructure platforms to provide developer self-service while maintaining security and compliance. Companies adopt Pulumi IaC so they can apply software engineering practices to their infrastructure scaling problems and because it is fully open source with a strong community and public roadmap.

At Pulumi, we’re committed to open source—always have been; always will be. Pulumi IaC is entirely open source (Apache 2.0 license), meaning you can adopt and extend it however you like. If you’re new to Pulumi, the open source edition is an excellent way to start modernizing your infrastructure. But as your organization grows and the complexity of your environment increases, you may find yourself devoting significant time to rolling your own enterprise IaC backend features.

That’s why we built Pulumi Cloud—to help you avoid building and maintaining these capabilities from scratch while ensuring you can automate, secure, and manage your infrastructure at scale. Pulumi Cloud provides enterprise capabilities that make it easier to build modern infrastructure platforms. Companies receive increasing value from Pulumi Cloud as their organization and their infrastructure platforms grow in size and complexity.

As companies expand or platform engineering mandates become more expansive, challenges arise around collaboration, security, governance, and scaling. Some questions that need answering include:

How do teams collaborate?
How do you securely manage infrastructure state?
How do you enable self-service infrastructure?
How do you adhere to IT security standards?
How do you enforce governance policies?
How do you protect sensitive data?
How do you enforce least privileged access across the organization?
How do you maintain uptime or get support for your architecture?
How do you manage the cost and complexity of multi-cloud environments?

If some of these questions apply to you or your team, learn more about Pulumi Cloud below to understand when it makes sense to transition to a paid Pulumi offering.

What drives the most value in Pulumi Cloud?

The most frequent business values that our existing customers experience with Pulumi Cloud relate to speed, scale, security, and savings.

Speed

There are speed benefits that customers typically experience across three areas: the infrastructure platform, developer productivity, and operations. Pulumi Cloud simplifies building and running complex infrastructure automation workflows through the Automation API. It also makes it easy to componentize best practices that can be easily shared and distributed through a centralized repository.

Pulumi Cloud streamlines the software delivery pipeline with Pulumi Deployments and a wide range of 3rd party CI/CD integrations.

Pulumi Cloud provides Pulumi Insights, offering search, analytics, and AI-driven insights over your infrastructure. With Insights, you can instantly search for critical information - such as finding MySQL databases on end-of-life versions across all your cloud assets, reducing the operational time it takes to find needles in haystacks.

Scale

Part of building an infrastructure platform is so your organization can scale and make it easy to onboard new developers. Pulumi Cloud integrates seamlessly with various identity providers like Azure ActiveDirectory, Okta, G Suite, or any SAML/SSO provider, offering deep support for role-based access control (RBAC) and SCIM for automatic synchronization and revocation of access based on identity provider groups. Audit logs keep track of developer activity within an organization, recording what actions were taken, when, and by whom.

Pulumi Cloud also makes it easy to build developer portals for developer self-service. Organization Templates can provide a centralized repository for cloud components, best practices and configurations. The New Project Wizard also provides a gallery interface to pick a template and easily walk through configuration and deployment of the infrastructure.

Security

Another reason your organization is investing in an infrastructure platform is so that security and compliance can be automated as infrastructure is self-serviced. Your platform must prevent infrastructure deployments that violate security, reliability, cost, or compliance policies. Pulumi Cloud, through Pulumi CrossGuard, provides out-of-the-box support for common security and compliance policies, ensuring PCIDSS, ISO27001, SOC2, and CIS compliance for cloud applications and infrastructure.

For applications being built across the organization, securing sensitive information like database passwords, cloud credentials, and API keys is paramount. Secrets can inadvertently end up in insecurely stored state files, leading to potential breaches. Pulumi Cloud, however, encrypts all data in transit and at rest, utilizing hardware security module (HSM) based encryption. Read the Pulumi Cloud Security Whitepaper for more information.

Pulumi Cloud further enhances security with Pulumi ESC, a centralized secrets management and orchestration service. This service pulls and syncs secrets from various stores like HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, and 1Password, making it easy to adopt dynamic, short-lived secrets on demand. Secrets can be accessed via CLI, API, Kubernetes operator, the Pulumi Cloud UI, and in-code with TypeScript/JavaScript, Python, and Go SDKs. Pulumi ESC leverages the same identity, RBAC, Teams, SAML/SCIM, OIDC, and scoped access tokens used by Pulumi IaC, ensuring that secrets management complies with enterprise security policies.

Savings

Building a platform and managing cloud infrastructure demands considerable time and energy. As discussed above, Pulumi Insights X-Rays your entire cloud footprint, so you can observe, plan, and drive changes across your infrastructure. With this total visibility, Pulumi Insights helps you reduce waste by showing you usage information and identifying potentially stale infrastructure, which can lead to substantial cost savings.

You can also have a conversation with Pulumi Copilot about your infrastructure in natural language and get answers to operational questions that would take hours to piece together from other sources.

Why not build your own enterprise features on top of Pulumi IaC open source?

Build vs buy is a question of opportunity cost. Should you and your team build and operate your own enterprise backend service that engineers at Pulumi have already built to handle the needs and scale of the world’s biggest companies? Or is their time better spent focused on building a modern infrastructure platform that will increase development velocity across the company and drive business growth?

Maintenance costs

When you build and operate your own enterprise backend, you’ll need to dedicate one full-time engineer for every team of ten - that’s nearly 10% of your engineering expense. Running a backend requires maintenance, updates, and troubleshooting. Outages and incidents can lead to significant financial losses. Pulumi Cloud, as a fully managed service, frees up your team’s time from the operational and maintenance burdens of managing an IaC backend.

Operational reliability and availability

One of the primary functions of the enterprise backend is managing state. State management involves managing concurrency controls, preventing state corruption, ensuring backup and recovery, maintaining high availability of the state service, and providing consistent visibility across all managed resources; this is easy to get wrong. Manual human intervention is frequently required to recover and repair state files, a process that is time-consuming, can create or prolong outages, and carries significant risk.

Security and compliance

Building your own enterprise backend also requires you to design and manage the service to adhere to numerous IT security standards, including SOC 1/SSAE 16/ISAE 3402, SOC 2, SOC 3, FISMA, FedRAMP, DOD SRG Levels 2 and 4, PCI DSS Level 1, EU Model Clauses, ISO 9001 / ISO 27001 / ISO 27017 / ISO 27018, ITAR, IRAP, FIPS 140-2, MLPS Level 3, and MTCS. This involves a manual assessment and validation process for each standard, which can be time-consuming and complex.

Customer support

You will also be giving up 12x5 or 24x7 customer support, which helps ensure your organization receives immediate assistance with any architectural, cloud-related, or Pulumi best-practices issues. Pulumi also has an experienced group of Solutions Architects and Customer Success Architects that have experience scaling infrastructure as code and building modern infrastructure platforms.

Conclusion

Pulumi Cloud is an enterprise-ready solution that comes with less risk and less maintenance costs than the DIY approach. With Pulumi Cloud, you get a fully managed service that automates deployments, ensures compliance, and offers comprehensive security features out-of-the-box. You’ll get a clear understanding of the product roadmap as well as talented engineers supporting your architecture and use cases.

Pulumi Cloud gives you the platform to automate, secure, and manage your modern infrastructure platform so your company can choose to focus on innovation and growth.

Try Pulumi Cloud for free and see how it can accelerate your infrastructure automation. Sign up today and start building with Pulumi Cloud.

Pulumi + Gitlab: Better Than Ever

Meagan Cojocar — Fri, 14 Mar 2025 00:00:00 +0000

Pulumi’s integration with GitLab has reached new heights with enhancements designed to streamline your infrastructure as code workflows. Today, we’re excited to announce several significant improvements to our GitLab integration that make managing cloud infrastructure with Pulumi and GitLab more seamless than ever before: GitLab as a first-class VCS in Pulumi Cloud, enhanced merge request comments, organizational templates in GitLab, and later this year, Pulumi Deployments for GitLab.

Pulumi and GitLab have long enjoyed a productive partnership. From supporting GitLab sign-in to enabling GitLab CI/CD pipelines for infrastructure deployments, we’ve consistently worked to ensure GitLab users can leverage Pulumi’s powerful infrastructure as code capabilities within their existing workflows.

Our GitLab Merge Request integration allows teams to visualize infrastructure changes directly within merge requests, making code reviews more effective and infrastructure changes more transparent.

What’s New in Our GitLab Integration

Enhanced Merge Request Comments

We’ve revamped how Pulumi interacts with GitLab by building a Gitlab application to handle the authentication. Previously, only customers using Gitlab as an identity provider to Pulumi Cloud could leverage it. Now, Pulumi provides even more detailed and actionable comments on your merge requests, giving reviewers comprehensive insights into proposed infrastructure changes.

These comments include:

Streamlined discoverability of infrastructure changes
Resource-by-resource breakdown of changes
Direct links to the Pulumi Console for deeper analysis

To configure the GitLab integration:

Navigate to Organization Settings → Integrations in Pulumi Cloud
Select GitLab and enter your access token
Choose which projects or groups should receive Pulumi comments

GitLab as a First-Class VCS in Pulumi Cloud

Version control systems are a first-class, configurable concept in Pulumi Cloud. When you select GitLab as your VCS, the Pulumi Cloud interface adapts to show only relevant options and terminology, creating a more intuitive experience for GitLab users.

This integration enables:

Direct linking to GitLab repositories, branches, and commits
Automatic detection of Pulumi projects in GitLab repositories
Streamlined setup for GitLab-based CI/CD workflows, using the CI/CD wizard on a stack’s page

Organizational Templates in GitLab

Pulumi Cloud now fully supports organizational templates stored in GitLab repositories. This powerful feature allows platform teams to define standardized infrastructure templates that developers across the organization can easily discover and use to create new projects.

Once a GitLab repository is registered as a template source, Pulumi automatically detects pulumi.yaml files and surfaces them in the template gallery. These templates can be:

Public or private repositories
Subject to Pulumi’s role-based access control (RBAC)
Available in both the UI and CLI via pulumi new

This integration makes it easier than ever to standardize infrastructure patterns across your organization while leveraging GitLab for version control and collaboration.

Coming Soon: Pulumi Deployments for GitLab

Pulumi Deployments will also soon support GitLab, enabling fully automated infrastructure provisioning directly from your GitLab pipelines. This integration will provide:

Fully managed compute for running Pulumi operations
Click to deploy self service workflows in the Pulumi Cloud UI
Rich new out of the box functionality like Time to Live Stacks, Drift Detection, Click to Deploy, Git Push to Deploy, Review Stacks and Scheduled Deployments.

All this functionality is available today by specifying the raw git credentials, but we look forward to making the integration frictionless in the future. To learn more about Pulumi Deployments read our Pulumi Deployments documentation.

Getting Started

Ready to try these new GitLab integrations? Here’s how to get started:

If you’re new to Pulumi, sign up for a free account
For existing users, navigate to your organization settings to configure the GitLab integration
Check out our updated documentation for detailed setup instructions

Conclusion

With these enhancements, Pulumi’s GitLab integration is better than ever, providing a seamless experience for managing infrastructure as code within your GitLab workflows. Learn more in the Pulumi GitLab documentation. We’re committed to continuing to improve this integration based on your feedback.

Have questions or feedback? Join our Community Slack to connect with the Pulumi team and other users, or open an issue on our GitHub repository.

Pulumi Cloud Gets Full Historical Views of Resources and Stack Outputs

Meagan Cojocar — Tue, 12 Dec 2023 10:34:32 -0800

As part of our ongoing commitment to providing developers and infrastructure teams with powerful tools, we’re thrilled to introduce the latest enhancement to Pulumi Cloud’s stack update pages. We have shipped an improvement to Pulumi Cloud stack update pages where all update pages now show the resources in the stack at that time and the stack outputs going back since your first update on the stack.

Expanded Resource Information

Now, each update will provide detailed information about the resources. This includes a list of resources created, modified, or deleted in each update, offering a clearer understanding of the changes made to your infrastructure.

Stack Outputs

The updated pages also now include information on the stack’s outputs for each update instead of just the current point in time. The value of this is being able to go back and see what output values were after any update.

The Value of Enhanced Data Visibility

Having a more detailed and transparent view of your stack updates provides several key benefits:

Resource Lifecycle Management: Understanding when and why a resource was added, modified, or deleted helps in better managing your infrastructure’s lifecycle and planning future changes.
Enhanced Troubleshooting and Analysis: The ability to go back to a specific point in time and analyze the state of your infrastructure at that moment can be invaluable in troubleshooting issues or understanding the impact of certain changes.

In summary, the improved Pulumi Cloud stack update pages offer a more detailed, transparent, and insightful view of your infrastructure changes. This upgrade came directly from customer asks, and underscores our commitment to empowering developers with the tools and information they need to effectively manage and understand their cloud resources and how they change over time.

Stay tuned for more updates as we continue to enhance our platform to better meet your needs. As always, submit any feedback on the feature in the Pulumi Cloud Requests repository.

Announcing Microsoft Teams Webhook Integration for Pulumi Cloud

Meagan Cojocar — Mon, 11 Sep 2023 00:00:00 +0000

Getting your Pulumi notifications into Microsoft Teams is now easier than ever. Organizations using Pulumi Cloud have previously been setting up Microsoft Teams notifications for their stacks using Pulumi Cloud Webhooks. Webhooks can attach to a Pulumi organization or a Pulumi stack. Starting today, customers can set up a Microsoft Teams integration, for organization or stack notifications, with fewer steps and without needing to host the infrastructure themselves.

Pulumi Cloud Webhooks, including the Microsoft Teams integration, are available to all Pulumi Cloud organizations.

See it in action!

Pulumi Microsoft Teams notifications enable central visibility for your team. In addition to getting the notification of a successful or failed update, you will have links to take you directly to the stack and directly to the update itself. You can see which Pulumi operation was being run, which user initiated it and the number of resources changed and unaffected. All of this information in one place lets you spend less time context switching and more time collaborating.

Setting up the Microsoft Teams Integration

Before today, Pulumi customers used Pulumi Cloud Webhooks to set up generic JSON webhooks. When events occur, we send a HTTP POST request to any registered listeners. Webhooks can then be used to send notifications to an app (like Microsoft Teams), start running automated tests, or even to update another stack! We have now built support for Microsoft Teams formatted webhooks, which allow you to quickly enable notifications about your Pulumi stacks and organizations into your Microsoft Teams workspace by simply providing a incoming webhook URL.

By following these steps, which can also be found in our webhooks documentation, in a few clicks you will have a Microsoft Teams incoming webhook URL which you can use to set up a webhook in Pulumi Cloud, as shown in the GIF below.

There are Pulumi customers with hundreds to thousands of stacks, making setting up webhooks for each via the UI a time consuming task. In order to enable Pulumi notifications at scale, we have added Pulumi Cloud REST API endpoints for creating webhooks as well as Pulumi Service Provider support.

Pulumi Cloud REST API

Create a webhook via the Pulumi Cloud REST API formatted for Microsoft Teams, as shown in the example below.


curl \
 -H "Accept: application/vnd.pulumi+8" \
 -H "Content-Type: application/json" \
 -H "Authorization: token $PULUMI_ACCESS_TOKEN" \
 --request POST \
 --data '{
 "organizationName": "{organization}",
 "projectName": "{project}",
 "stackName": "{stack}",
 "displayName": "my-display-name",
 "payloadUrl": "https://xxxxx.webhook.office.com/xxxxxxxxx",
 "format": "ms_teams",
 "active": true
 }' \
 https://api.pulumi.com/api/orgs/{organization}/{project}/{stack}/hooks

Pulumi Service Provider

The Pulumi Service provider allows you to create Pulumi Cloud resources via Pulumi. You can provision and manage webhooks, including Microsoft Teams webhooks, using this provider.

import * as pulumi from "@pulumi/pulumi";
import { Webhook, WebhookFormat, WebhookFilters } from "@pulumi/pulumiservice";

const orgName = "my-org";

const orgWebhook = new Webhook("org-webhook", {
 active: true,
 displayName: "my-teams-channel",
 organizationName: orgName,
 payloadUrl: "https://xxxxx.webhook.office.com/xxxxxxxxx",
 format: WebhookFormat.MicrosoftTeams,
 filters: [
 WebhookFilters.StackCreated,
 WebhookFilters.StackDeleted,
 WebhookFilters.DeploymentSucceeded,
 WebhookFilters.DeploymentFailed,
 ],
});

const stackWebhook = new Webhook("stack-webhook", {
 active: true,
 displayName: "my-teams-channel",
 organizationName: orgName,
 projectName: pulumi.getProject(),
 stackName: pulumi.getStack(),
 payloadUrl: "https://xxxxx.webhook.office.com/xxxxxxxxx",
 format: WebhookFormat.MicrosoftTeams,
});

export const orgWebhookName = orgWebhook.name;
export const stackWebhookName = stackWebhook.name;


name: webhook-examples
runtime: yaml
description: An example of provisioning a Pulumi Cloud Webhook via Pulumi Service Provider

resources:
 orgWebhook:
 type: pulumiservice:index:Webhook
 properties:
 active: true
 displayName: my-teams-channel
 organizationName: my-org
 payloadUrl: "https://xxxxx.webhook.office.com/xxxxxxxxx"
 format: ms_teams
 filters:
 - stack_created
 - stack_deleted
 - deployment_succeeded
 - deployment_failed
 stackWebhook:
 type: pulumiservice:index:Webhook
 properties:
 active: true
 displayName: my-teams-channel
 organizationName: my-org
 projectName: webhook-examples
 stackName: dev
 payloadUrl: "https://xxxxx.webhook.office.com/xxxxxxxxx"
 format: ms_teams

outputs:
 # export the name of the webhooks
 orgWebhookName: ${orgWebhook.name}
 stackWebhookName: ${stackWebhook.name}

import pulumi
import pulumi_pulumiservice as pulumiservice

org_webhook = pulumiservice.Webhook("orgWebhook",
 active=True,
 display_name="my-teams-channel",
 organization_name="my-org",
 payload_url="https://xxxxx.webhook.office.com/xxxxxxxxx",
 format=pulumiservice.WebhookFormat.MICROSOFT_TEAMS,
 filters=[
 pulumiservice.WebhookFilters.STACK_CREATED,
 pulumiservice.WebhookFilters.STACK_DELETED,
 pulumiservice.WebhookFilters.DEPLOYMENT_SUCCEEDED,
 pulumiservice.WebhookFilters.DEPLOYMENT_FAILED,
 ])

stack_webhook = pulumiservice.Webhook("stackWebhook",
 active=True,
 display_name="my-teams-channel",
 organization_name="my-org",
 project_name="webhook-examples",
 stack_name="dev",
 payload_url="https://xxxxx.webhook.office.com/xxxxxxxxx",
 format=pulumiservice.WebhookFormat.MICROSOFT_TEAMS)

pulumi.export("orgWebhookName", org_webhook.name)
pulumi.export("stackWebhookName", stack_webhook.name)

package main

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

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 orgWebhook, err := pulumiservice.NewWebhook(ctx, "orgWebhook", &pulumiservice.WebhookArgs{
 Active: pulumi.Bool(true),
 DisplayName: pulumi.String("my-teams-channel"),
 OrganizationName: pulumi.String("my-org"),
 PayloadUrl: pulumi.String("https://xxxxx.webhook.office.com/xxxxxxxxx"),
 Format: pulumiservice.WebhookFormatMicrosoftTeams,
 Filters: pulumiservice.WebhookFiltersArray{
 pulumiservice.WebhookFiltersStackCreated,
 pulumiservice.WebhookFiltersStackDeleted,
 pulumiservice.WebhookFiltersDeploymentSucceeded,
 pulumiservice.WebhookFiltersDeploymentFailed,
 },
 })
 if err != nil {
 return err
 }
 stackWebhook, err := pulumiservice.NewWebhook(ctx, "stackWebhook", &pulumiservice.WebhookArgs{
 Active: pulumi.Bool(true),
 DisplayName: pulumi.String("my-teams-channel"),
 OrganizationName: pulumi.String("my-org"),
 ProjectName: pulumi.String("webhook-examples"),
 StackName: pulumi.String("dev"),
 PayloadUrl: pulumi.String("https://xxxxx.webhook.office.com/xxxxxxxxx"),
 Format: pulumiservice.WebhookFormatMicrosoftTeams,
 })
 if err != nil {
 return err
 }
 ctx.Export("orgWebhookName", orgWebhook.Name)
 ctx.Export("stackWebhookName", stackWebhook.Name)
 return nil
 })
}

using System.Collections.Generic;
using System.Linq;
using Pulumi;
using PulumiService = Pulumi.PulumiService;

return await Deployment.RunAsync(() =>
{
 var orgWebhook = new PulumiService.Webhook("orgWebhook", new()
 {
 Active = true,
 DisplayName = "my-teams-channel",
 OrganizationName = "my-org",
 PayloadUrl = "https://xxxxx.webhook.office.com/xxxxxxxxx",
 Format = PulumiService.WebhookFormat.MicrosoftTeams,
 Filters = new[]
 {
 PulumiService.WebhookFilters.StackCreated,
 PulumiService.WebhookFilters.StackDeleted,
 PulumiService.WebhookFilters.DeploymentSucceeded,
 PulumiService.WebhookFilters.DeploymentFailed,
 },
 });

 var stackWebhook = new PulumiService.Webhook("stackWebhook", new()
 {
 Active = true,
 DisplayName = "my-teams-channel",
 OrganizationName = "my-org",
 ProjectName = "webhook-examples",
 StackName = "dev",
 PayloadUrl = "https://xxxxx.webhook.office.com/xxxxxxxxx",
 Format = PulumiService.WebhookFormat.MicrosoftTeams,
 });

 return new Dictionary<string, object?>
 {
 ["orgWebhookName"] = orgWebhook.Name,
 ["stackWebhookName"] = stackWebhook.Name,
 };
});

package generated_program;

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.core.Output;
import com.pulumi.pulumiservice.Webhook;
import com.pulumi.pulumiservice.WebhookArgs;
import java.util.List;
import java.util.ArrayList;
import java.util.Map;
import java.io.File;
import java.nio.file.Files;
import java.nio.file.Paths;

public class App {
 public static void main(String[] args) {
 Pulumi.run(App::stack);
 }

 public static void stack(Context ctx) {
 var orgWebhook = new Webhook("orgWebhook", WebhookArgs.builder()
 .active(true)
 .displayName("my-teams-channel")
 .organizationName("my-org")
 .payloadUrl("https://xxxxx.webhook.office.com/xxxxxxxxx")
 .format("ms_teams")
 .filters(
 "stack_created",
 "stack_deleted",
 "deployment_succeeded",
 "deployment_failed")
 .build());

 var stackWebhook = new Webhook("stackWebhook", WebhookArgs.builder()
 .active(true)
 .displayName("my-teams-channel")
 .organizationName("my-org")
 .projectName("webhook-examples")
 .stackName("dev")
 .payloadUrl("https://xxxxx.webhook.office.com/xxxxxxxxx")
 .format("ms_teams")
 .build());

 ctx.export("orgWebhookName", orgWebhook.name());
 ctx.export("stackWebhookName", stackWebhook.name());
 }
}

Wrapping up

Our webhooks improvements enable ChatOps workflows and more visibility into your infrastructure. As always, please let us know if you have feedback on the feature by opening an issue in the Pulumi Cloud requests repository or if you have other features you would like to see in Pulumi Cloud.

Happy building! 👷

Property Search: Enhanced Resource Search in Pulumi Cloud

Meagan Cojocar — Tue, 13 Jun 2023 00:00:00 +0000

Two months ago we launched Resource Search for Pulumi Cloud to offer multi-cloud resource search and analytics across every cloud environment in your organization. Today, we’re excited to announce that we are taking this a step further and exposing a much larger set of data to search over: resource properties.

Including property names and values in your resource searches enables you to search on an even richer variety of dimensions, everything from instance type, to database version, to region and availability zone, to whether resources are open to the internet. By searching on property data, in addition to overall resource metadata, you can craft expressive queries that serve key compliance, operational and diagnostic use cases.

Pulumi Resource Search, including the ability to search on property data, is applicable across all cloud resources, whether they reside in AWS, Google Cloud, Azure, or any of Pulumi’s 100+ cloud providers. Support for querying on property data is available in the Enterprise and Business Critical editions of Pulumi Cloud.

Feature Overview

Cloud resources come with various properties that define their behavior, performance, location, and more. You can now use Pulumi Resource Search to search based on these properties in addition to other resource metadata across 100+ clouds. Whether you’re trying to find resources running in a specific region, instances with a particular tag, or databases running a certain engine version, searching over properties with Pulumi Cloud streamlines and simplifies your tasks.

Using the new feature is simple and straightforward. Go to the Pulumi console, navigate to the search bar, and start typing the property you’re interested in. For example, if you’re searching for all AWS RDS instances running MySQL with a particular engine version, simply type .engineVersion:5.7 and press enter.

The ability to search for resources based on their properties is a powerful tool for optimizing cloud resource management. It provides deeper insights into your infrastructure and aids in identifying resources that are misconfigured, out-of-date, or not adhering to your organization’s best practices. Essentially, it’s a significant step towards more proactive, informed, and efficient management of your cloud environment.Customers like Alkira, a company that reinvents networking for the cloud era, have found it to be a significant step towards more proactive, informed, and efficient management of the cloud.

“I’m making developers at Alkira significantly more productive while also making my job easier using Pulumi’s IaC platform and features like Pulumi Insights and Deployments,” said Santosh Dornal, Head of Software Test & DevOps, Alkira. “I can get developers using IaC immediately with Pulumi Deployments and its GitHub integration, while Pulumi Insights makes it really easy to find idle developer environments that need to be shut down, which reduces our cloud costs.”

Example queries

Before Property Search, using just Resource Search, you were able to find resources by their name, type, URN, parent, the team they are in, and so on… but today, any property on your resource will be indexed by Pulumi Cloud and searchable after each stack update. Let’s walk through some examples of the types of queries you can now perform.

AI Assist & properties

Pulumi AI Assist allows you to use natural language to search for resources. AI Assist works by converting natural language to a query in our search syntax. This becomes even more valuable with property search. Resources can have dozens of properties, and remembering exactly how to search for property values can be challenging, especially when they change depending on the provider. AI Assist is going to step in so that you don’t have to remember everything.

Here is a list of example natural language queries we have seen customers use and the AI Assist output:

Natural language	Query result
resources tagged with stack production	`.tags.stack:production`
resources without a tag in production	`-tags: stack:production`
aurora engines running MySQL engine version 5	`type:"aws:rds/cluster:Cluster" .engine:aurora .engineVersion:5`
s3 buckets read write in production	`type:"aws:s3/bucket:Bucket" stack:production .acl:public-read-write`
buckets objects in all clouds	`type:"aws:s3/bucket:Bucket" OR type:"google:storage/bucket:Bucket" OR type:"azure:storage:BlobContainer"`
all resources in us east 1	`region:"us-east-1"`
resources with a private ip	`.privateIpAddress:`

Search syntax

Properties can be used in your queries by using a . prefix. For example, if you want to see all resources with an Instance Type property, you type in the search bar .instanceType:. If you want to only look at a specific value, you can search for the value behind the colon. In this case our query would become .instanceType:t3.large.

Here are some query examples we have seen customers use:

project:pulumi-service stack:staging .instanceType:
type:aws:rds/cluster:Cluster .engine:aurora .engineVersion:8
type:aws:s3/bucket:Bucket stack:production .acl:public-read
team:data package:snowflake .availabilityZone:us-west-2a
vpc created:2023-06-12 .tags.Environment:production

Use the REST API

In addition to searching for resources you can also export them to perform analytics: whether that is something simple like opening it in a spreadsheet or something more sophisticated, like if you want to regularly ingest it to your data warehouse. You can download a CSV from the console or get the data using the Data Export API.

But the value of Resource Search is not limited to what you do in the console and for analytics. You can also leverage the Resource Search API to create automation and workflows off of search results. Find below details on how to use the API.

const headers = {
 Accept: "application/json",
 Authorization: "token pul-abc123",
};

const body = await (
 await fetch("https://api.pulumi.com/api/orgs/{org}/search/resources?properties=true?query=.instanceType", {
 method: "GET",
 headers: headers,
 })
).json();

console.log(body);

const headers = {
 Accept: "application/json",
 Authorization: "token pul-abc123",
};

const body = await(
 await fetch("https://api.pulumi.com/api/orgs/{org}/search/resources?properties=true?query=.instanceType", {
 method: "GET",
 headers: headers,
 }),
).json();

console.log(body);

import requests
headers = {
 'Accept': 'application/json',
 'Authorization': 'token pul-abc123'
}

r = requests.get('https://api.pulumi.com/api/orgs/{org}/search/resources?properties=true?query=.instanceType', headers = headers)

print(r.json())

package main

import (
 "bytes"
 "net/http"
)

func main() {
 headers := map[string][]string{
 "Accept": []string{"application/json"},
 "Authorization": []string{"token pul-abc123"},
 }

 data := bytes.NewBuffer([]byte{jsonReq})
 req, err := http.NewRequest("GET", "https://api.pulumi.com/api/orgs/{org}/search/resources?properties=true?query=.instanceType", data)
 req.Header = headers

 client := &http.Client{}
 resp, err := client.Do(req)
 // ...
}

using System;
using System.Collections.Generic;
using System.Net.Http;
using System.Net.Http.Headers;
using System.Text;
using System.Threading.Tasks;
using Newtonsoft.Json;

public class HttpExample
{
 private HttpClient Client { get; set; }

 public HttpExample()
 {
 Client = new HttpClient();
 }

 public async Task MakeGetRequest()
 {
 string url = "https://api.pulumi.com/api/orgs/{org}/search/resources?properties=true?query=.instanceType";
 var result = await GetAsync(url);
 }

 /// Performs a GET Request
 public async Task GetAsync(string url)
 {
 //Start the request
 HttpResponseMessage response = await Client.GetAsync(url);

 //Validate result
 response.EnsureSuccessStatusCode();

 }

 /// Deserialize object from request response
 private async Task DeserializeObject(HttpResponseMessage response)
 {
 //Read body
 string responseBody = await response.Content.ReadAsStringAsync();

 //Deserialize Body to object
 var result = JsonConvert.DeserializeObject(responseBody);
 }
}

URL obj = new URL("https://api.pulumi.com/api/orgs/{org}/search/resources?properties=true?query=.instanceType");
HttpURLConnection con = (HttpURLConnection) obj.openConnection();
con.setRequestMethod("GET");
int responseCode = con.getResponseCode();
BufferedReader in = new BufferedReader(
 new InputStreamReader(con.getInputStream()));
String inputLine;
StringBuffer response = new StringBuffer();
while ((inputLine = in.readLine()) != null) {
 response.append(inputLine);
}
in.close();
System.out.println(response.toString());

Wrapping it all up

We are excited to be extending Pulumi Resource Search with access to search over every property of your resources. We can’t wait to see what new capabilities it unlocks for your organization. As always, submit any feedback on the feature in the Pulumi Cloud Requests repository.

Happy searching!

Announcing Slack and Deployment Notifications for Pulumi Cloud

Meagan Cojocar — Tue, 30 May 2023 00:00:00 +0000

Today, we are excited to introduce a set of improvements to Pulumi Cloud Webhooks designed to deliver your deployment notifications to where you already spend your time, enabling faster response times to critical issues. Getting your deployment notifications into Slack is now easier than ever on Pulumi Cloud with our new Slack integration. We are also announcing two new improvements to our webhooks feature: Pulumi Deployments events and fine-grained event filtering.

Teams using Pulumi Cloud have been setting up Slack notifications for their stacks using Pulumi Cloud Webhooks. Webhooks can attach to a Pulumi organization or a Pulumi stack. Starting today, customers can set up a Slack integration, for organization or stack notifications, with fewer steps and without needing to host the infrastructure themselves. We have also expanded the types of event notifications and the filtering options on both Pulumi Cloud Webhooks and for the Slack integration.

Pulumi Cloud Webhooks, including the Slack integration, are available to all Pulumi Cloud organizations.

Slack integration

Pulumi Slack notifications enable central visibility for your team. In addition to getting the notification of a successful or failed update, you will have links to take you directly to the stack and directly to the update itself. You can see what Pulumi operation was being run, which user initiated it and the number of resources changed and unaffected. All of this information in one place lets you spend less time context switching and more time collaborating.

Setting up the Slack Integration

Before today Pulumi customers used Pulumi Cloud Webhooks to set up generic JSON webhooks. When events occur, we send a HTTP POST request to any registered listeners. Webhooks can then be used to send notifications to an app (like Slack), start running automated tests, or even to update another stack! We have now built support for Slack-formatted webhooks, which allow you to quickly enable notifications about your Pulumi stacks and organizations into your Slack workspace by simply providing a Slack incoming webhook URL.

You can either create your own Slack app (or use an existing one you may already have installed in your workspace) or you can use the link below to quickly get started with a predefined Slack app manifest.

Create a Slack app from manifest

By following these steps, which can also be found in our webhooks documentation, in a few clicks you will have a Slack incoming webhook URL which you can use to set up a webhook in Pulumi Cloud, as shown in the GIF below.

Pulumi Cloud REST API

Create a webhook via the Pulumi Cloud REST API formatted for Slack, as shown in the example below.


curl \
 -H "Accept: application/vnd.pulumi+8" \
 -H "Content-Type: application/json" \
 -H "Authorization: token $PULUMI_ACCESS_TOKEN" \
 --request POST \
 --data '{
 "organizationName":"{organization}",
 "projectName":"{project}",
 "stackName":"{stack}",
 "displayName":"#some-slack-channel",
 "payloadUrl":"https://hooks.slack.com/services/...",
 "format": "slack",
 "active":true
 }' \
 https://api.pulumi.com/api/orgs/{organization}/{project}/{stack}/hooks

Pulumi Service Provider

The Pulumi Service provider allows you to create Pulumi Cloud resources via Pulumi. You can provision and manage webhooks, including Slack-formatted webhooks, using this provider.

import * as pulumi from "@pulumi/pulumi";
import { Webhook, WebhookFormat, WebhookFilters } from "@pulumi/pulumiservice";

const orgName = "my-org";

const orgWebhook = new Webhook("org-webhook", {
 active: true,
 displayName: "#my-org-activity-channel",
 organizationName: orgName,
 payloadUrl: "https://hooks.slack.com/services/...",
 format: WebhookFormat.Slack,
 filters: [
 WebhookFilters.StackCreated,
 WebhookFilters.StackDeleted,
 WebhookFilters.DeploymentSucceeded,
 WebhookFilters.DeploymentFailed,
 ],
});

const stackWebhook = new Webhook("stack-webhook", {
 active: true,
 displayName: "#my-stack-activity-channel",
 organizationName: orgName,
 projectName: pulumi.getProject(),
 stackName: pulumi.getStack(),
 payloadUrl: "https://hooks.slack.com/services/...",
 format: WebhookFormat.Slack,
});

export const orgWebhookName = orgWebhook.name;
export const stackWebhookName = stackWebhook.name;


name: webhook-examples
runtime: yaml
description: An example of provisioning a Pulumi Cloud Webhook via Pulumi Service Provider

resources:
 orgWebhook:
 type: pulumiservice:index:Webhook
 properties:
 active: true
 displayName: "#my-org-activity-channel"
 organizationName: my-org
 payloadUrl: "https://hooks.slack.com/services/..."
 format: slack
 filters:
 - stack_created
 - stack_deleted
 - deployment_succeeded
 - deployment_failed
 stackWebhook:
 type: pulumiservice:index:Webhook
 properties:
 active: true
 displayName: "#my-stack-activity-channel"
 organizationName: my-org
 projectName: webhook-examples
 stackName: dev
 payloadUrl: "https://hooks.slack.com/services/..."
 format: slack

outputs:
 # export the name of the webhooks
 orgWebhookName: ${orgWebhook.name}
 stackWebhookName: ${stackWebhook.name}

import pulumi
import pulumi_pulumiservice as pulumiservice

org_webhook = pulumiservice.Webhook("orgWebhook",
 active=True,
 display_name="#my-org-activity-channel",
 organization_name="my-org",
 payload_url="https://hooks.slack.com/services/...",
 format=pulumiservice.WebhookFormat.SLACK,
 filters=[
 pulumiservice.WebhookFilters.STACK_CREATED,
 pulumiservice.WebhookFilters.STACK_DELETED,
 pulumiservice.WebhookFilters.DEPLOYMENT_SUCCEEDED,
 pulumiservice.WebhookFilters.DEPLOYMENT_FAILED,
 ])

stack_webhook = pulumiservice.Webhook("stackWebhook",
 active=True,
 display_name="#my-stack-activity-channel",
 organization_name="my-org",
 project_name="webhook-examples",
 stack_name="dev",
 payload_url="https://hooks.slack.com/services/...",
 format=pulumiservice.WebhookFormat.SLACK)

pulumi.export("orgWebhookName", org_webhook.name)
pulumi.export("stackWebhookName", stack_webhook.name)

package main

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

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 orgWebhook, err := pulumiservice.NewWebhook(ctx, "orgWebhook", &pulumiservice.WebhookArgs{
 Active: pulumi.Bool(true),
 DisplayName: pulumi.String("#my-org-activity-channel"),
 OrganizationName: pulumi.String("my-org"),
 PayloadUrl: pulumi.String("https://hooks.slack.com/services/..."),
 Format: pulumiservice.WebhookFormatSlack,
 Filters: pulumiservice.WebhookFiltersArray{
 pulumiservice.WebhookFiltersStackCreated,
 pulumiservice.WebhookFiltersStackDeleted,
 pulumiservice.WebhookFiltersDeploymentSucceeded,
 pulumiservice.WebhookFiltersDeploymentFailed,
 },
 })
 if err != nil {
 return err
 }
 stackWebhook, err := pulumiservice.NewWebhook(ctx, "stackWebhook", &pulumiservice.WebhookArgs{
 Active: pulumi.Bool(true),
 DisplayName: pulumi.String("#my-stack-activity-channel"),
 OrganizationName: pulumi.String("my-org"),
 ProjectName: pulumi.String("webhook-examples"),
 StackName: pulumi.String("dev"),
 PayloadUrl: pulumi.String("https://hooks.slack.com/services/..."),
 Format: pulumiservice.WebhookFormatSlack,
 })
 if err != nil {
 return err
 }
 ctx.Export("orgWebhookName", orgWebhook.Name)
 ctx.Export("stackWebhookName", stackWebhook.Name)
 return nil
 })
}

using System.Collections.Generic;
using System.Linq;
using Pulumi;
using PulumiService = Pulumi.PulumiService;

return await Deployment.RunAsync(() =>
{
 var orgWebhook = new PulumiService.Webhook("orgWebhook", new()
 {
 Active = true,
 DisplayName = "#my-org-activity-channel",
 OrganizationName = "my-org",
 PayloadUrl = "https://hooks.slack.com/services/...",
 Format = PulumiService.WebhookFormat.Slack,
 Filters = new[]
 {
 PulumiService.WebhookFilters.StackCreated,
 PulumiService.WebhookFilters.StackDeleted,
 PulumiService.WebhookFilters.DeploymentSucceeded,
 PulumiService.WebhookFilters.DeploymentFailed,
 },
 });

 var stackWebhook = new PulumiService.Webhook("stackWebhook", new()
 {
 Active = true,
 DisplayName = "#my-stack-activity-channel",
 OrganizationName = "my-org",
 ProjectName = "webhook-examples",
 StackName = "dev",
 PayloadUrl = "https://hooks.slack.com/services/...",
 Format = PulumiService.WebhookFormat.Slack,
 });

 return new Dictionary<string, object?>
 {
 ["orgWebhookName"] = orgWebhook.Name,
 ["stackWebhookName"] = stackWebhook.Name,
 };
});

package generated_program;

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.core.Output;
import com.pulumi.pulumiservice.Webhook;
import com.pulumi.pulumiservice.WebhookArgs;
import java.util.List;
import java.util.ArrayList;
import java.util.Map;
import java.io.File;
import java.nio.file.Files;
import java.nio.file.Paths;

public class App {
 public static void main(String[] args) {
 Pulumi.run(App::stack);
 }

 public static void stack(Context ctx) {
 var orgWebhook = new Webhook("orgWebhook", WebhookArgs.builder()
 .active(true)
 .displayName("#my-org-activity-channel")
 .organizationName("my-org")
 .payloadUrl("https://hooks.slack.com/services/...")
 .format("slack")
 .filters(
 "stack_created",
 "stack_deleted",
 "deployment_succeeded",
 "deployment_failed")
 .build());

 var stackWebhook = new Webhook("stackWebhook", WebhookArgs.builder()
 .active(true)
 .displayName("#my-stack-activity-channel")
 .organizationName("my-org")
 .projectName("webhook-examples")
 .stackName("dev")
 .payloadUrl("https://hooks.slack.com/services/...")
 .format("slack")
 .build());

 ctx.export("orgWebhookName", orgWebhook.name());
 ctx.export("stackWebhookName", stackWebhook.name());
 }
}

Pulumi Deployment Notification Events

Pulumi Deployments is a fully managed platform for managing infrastructure at scale. With Pulumi Deployments, you can run a Pulumi infrastructure as code action (a preview, update, destroy or refresh) inside Pulumi Cloud. Pulumi provides scalability, observability and security for deployments. Both Slack-formatted and generic JSON webhooks in Pulumi Cloud now send notifications events on Pulumi Deployments statuses: when a deployment is queued, started, succeeds and fails.

Filtering Notification Events

Event filtering allows you to select which events should be delivered to each webhook. You may want to receive all events, or filter to specific events (only failures, only deployment events, etc.). The following table describes the various event filters available and the context in which they are relevant.

Filter	Event Kind	Webhook Type	Triggered
`stack_created`	`stack`	Organization webhooks only	When a stack is created.
`stack_deleted`	`stack`	Organization webhooks only	When a stack is deleted.
`preview_succeeded`	`stack_preview`	Both	When a stack `preview` succeeds.
`preview_failed`	`stack_preview`	Both	When a stack `preview` fails.
`update_succeeded`	`stack_update`	Both	When a stack `update` succeeds.
`update_failed`	`stack_update`	Both	When a stack `update` fails.
`destroy_succeeded`	`stack_update`	Both	When a stack `destroy` succeeds.
`destroy_failed`	`stack_update`	Both	When a stack `destroy` fails.
`refresh_succeeded`	`stack_update`	Both	When a stack `refresh` succeeds.
`refresh failed`	`stack_update`	Both	When a stack `refresh` fails.
`deployment_queued`	`deployment`	Both	When a deployment is queued.
`deployment_started`	`deployment`	Both	When a deployment starts running.
`deployment_succeeded`	`deployment`	Both	When a deployment succeeds.
`deployment_failed`	`deployment`	Both	When a deployment fails.

Wrapping up

We hope you and your team can streamline deployment related notifications to where you spend your time. Our webhooks improvements enable ChatOps workflows and more visibility into your infrastructure. As always, please let us know if you have feedback on the feature by opening an issue in the Pulumi Cloud requests repository or if you have other features you would like to see in Pulumi Cloud.

Happy building! 👷

Transferring Stacks in the Pulumi Service Just Got Easier

Meagan Cojocar — Wed, 07 Dec 2022 11:11:45 -0800

Exactly 3 years ago we added support in the Pulumi Service to transfer stacks from an Individual account to a Pulumi organization and between Pulumi organizations. We heard from customers that they love this feature but found it both hard to discover and tedious when moving a large workload from one organization to another and from Individual accounts to organizations. We are excited to announce bulk stack transfer to address this feedback and a new organization set up wizard to improve discovery of the feature.

Let’s review how bulk stack transfers can be used and when you would use them. Stack transfers relocate a stack between organizations and Individual accounts. Let’s highlight some use cases:

Use case #1: Individual account to a collaborative organization: We know that users are building projects in Individual accounts and want to easily move their stacks to an organization so they can collaboratively build infrastructure with others.
Use case #2: Organization to Individual account: There may be instances where users want to take a stack from an organization into their Individual org. This could be due to mistakenly creating a stack in the wrong location.
Use case #3: Organization to organization: As customers scale there may be use cases where they want to add additional organizations and being able to transfer stacks in bulk will help with this.

Transferring one stack

To transfer a specific stack, you can navigate to that stack and then go to Settings > Transfer Stack. To transfer a stack, you need to be either the Stack Admin or an Organization Admin. For organizations on the Pulumi Enterprise or Business Critical Editions, an audit log will be produced each time a stack is transferred and it records which organization the stack was transferred to.

Transferring multiple stacks

To transfer multiple stacks, you can navigate to the Stacks page and then click the ... icon beside the ‘Create a Project’ button in a collaborative organization and the Transfer stacks button in an Individual account. In order to transfer multiple stacks you need to be an Organization Admin. For organizations on the Pulumi Enterprise or Business Critical Editions, an audit log will be produced each time a stack is transferred and it records which organization the stack was transferred to.

Bringing stacks into new organizations

We recently added a new organization setup wizard that will walk you through inviting members, importing stacks and setting your preferred cloud and language when you create a new organization. This compacts common usage patterns into one place to make it easier for you.

See it in action!

Learn more in the Stack Transfer documentation. Please submit an issue in the Pulumi Service Requests repo if you have feature requests for the Pulumi Service or join our Slack channel if you have questions.

Until next time!

The New and Improved Pulumi Service console

Meagan Cojocar — Mon, 29 Aug 2022 00:00:00 +0000

The Pulumi Service is the easiest way to use Pulumi’s open source, universal infrastructure as code SDK at scale and provides a fully managed experience. It handles infrastructure state and secrets, sets up SAML SSO, integrates with CI/CD pipelines, and enforces compliance rules.

It’s been nearly four years since the Pulumi Service launched back in 2018. In these last four years, our customer base has grown significantly and as a result, the Service’s features and capabilities have grown with it.

We’ve added features like audit logs, SAML SSO and SCIM, Teams, Organization and Team Access Tokens, and much more! But throughout all these changes, the look and feel of the Service has largely stayed the same—until now! Today we’re excited to launch a set of improvements to the overall user experience of the Pulumi Service. These updates include:

Increased organizational insights on the Service Dashboard
Quick access to stacks with a new Stack Favorites feature
Easier navigation around the Service with a new left navigation pane

These changes came directly from consultation with our users and we’ve spent time with customers in the past few weeks refining it. One of these customers was dutchie, an all-in-one technology platform powering the cannabis industry with Point of Sale, Ecommerce, Payments, and more. “The new Pulumi Service console is a change we are really excited to see, literally. It has better use of white space and an improved balance of information on the Dashboard at the same time and that shows a real and welcome focus on user experience. It is a genuine quality of life improvement in a portion of the product that we use daily.” said Jordan Rinke, Infrastructure Architect at dutchie.

Want to try these features out for yourself? Sign in to your Pulumi Service account or if you are new to Pulumi, create a free account.

Increased organizational insights on the Service Dashboard

Lastly, we’ve made significant changes to the Pulumi Service dashboard. Now you can access more information to help survey your operations at a glance.

Organizations can access some quick usage statistics at the top of their dashboards:

Member count and +/- change in the past week
Total stack count and percent change in the past week
Total resource count and percent change in the past week
Number of successful updates in the past day, week, month, and year

If you’re part of an organization, you’ll also see a “Members” card that tracks recently joined members. If you’re an admin, you can manage any pending invites from this card.

We’ve also exposed more operation updates in the “Latest Stack Activity” card. You can see up to ten most recent updates and favorite those stacks directly from the dashboard card.

Quick access to stacks with a new Stack Favorites feature

Many Pulumi users have access to dozens of hundreds of stacks. But only a few of those stacks may require regular interaction. We’ve introduced a new Stack Favorites feature to let you flag the stacks that are most important. This way you can access those stacks from anywhere in the Service.

Your favorites list is your own. Even if you’re part of an organization, your favorites won’t be shared with anyone other than you. And you can have as many favorites as you like!

Look for the star icon next to any stack name and select it to start building your favorites list.

You can access the favorites list from two key locations in the Service: the left navigation pane and the dashboard. All your favorites will appear in the navigation pane under the “Stacks” heading. You’ll also have your list of favorites in a new dashboard card.

Among the biggest changes to the feel of the Service is our new left navigation pane. Navigation items like your Dashboard, Stacks, and Settings are accessible in the new pane from anywhere in the Service.

The navigation pane consolidates actions and information so it’s easy for you to find common items. You’ll find options in the pane to:

Switch between your individual account and any other organizations you’re part of
Create new organizations
Access Stack Favorites
Directly access sub-pages like Billing or Access Tokens
Send us your feedback!

These changes will help you move through the Pulumi Service without losing your place and to ensure convenient access to key pages. You can even collapse the navigation pane for more screen real estate and still access any page you need.

If you’re looking for your account details, they have moved into the black utility toolbar. To access your account settings or logout of the Pulumi Service, select your profile image at the top right of your browser window.

Try out the Pulumi Service today

We’d love for you to try out the new and improved Pulumi Service console! Don’t hesitate to reach out on the Pulumi Community Slack about any thoughts and feelings you have about these changes or any and all things Pulumi! We also have a public GitHub repo to track any requests related to the Service.

These changes wouldn’t be possible without the users who generously gave their time to have a conversation with us. We’ll continue to translate user feedback into a better Pulumi experience.

We look forward to hearing what you think of these changes!

Announcing Team Access Tokens for the Pulumi Service

Devon Grove — Tue, 16 Aug 2022 14:00:00 -0700

A few months ago we launched Organization Access Tokens for the Pulumi Service and saw overwhelmingly fast adoption from our customer base. Based on this customer demand, and existing customer feedback, we prioritized improvements in the scoping of access tokens. Today, we are launching Team Access Tokens, which allow Organization and Team Admins to create access tokens scoped to a Pulumi Team. Pulumi Service customers on the Enterprise and Business Critical editions can use Pulumi Teams to set role-based access controls (RBAC) for stacks by enabling Organization administrators to assign a set of stack permissions to a group of users.

Since Pulumi Teams are only available on these editions, Team Access Tokens are also only available to customers on the Enterprise and Business Critical editions of the Pulumi Service. See the Team Access Tokens documentation for more information on how to use the feature.

See it in action!

Hear from our customers

Snowflake, a Pulumi customer, delivers the Data Cloud, a global network where thousands of organizations mobilize data with near-unlimited scale, concurrency, and performance. “Scoping down access tokens will help our Platform team manage Pulumi stacks at scale across multiple departments within Snowflake. When Organization Access Tokens came out we were quick to adopt them internally and intend to adopt Team Access Tokens now as well. Using Pulumi Teams and Team Access Tokens enables us to follow the principle of least privilege.” said Jonas-Taha El Sesiy, Senior Software Engineer at Snowflake.

Feature overview

This feature is particularly useful for:

Scoping programmatic access for continuous integration and continuous delivery (CI/CD) tools and other automated processes to the Pulumi Team instead of the entire Organization
Enterprise customers using SSO/SAML/SCIM, as it enables them to set fine-grained stack permissions to the Pulumi Teams provisioned through their identity provider

Team Access Tokens scope token access down to the stacks a Pulumi Team has access to. Customers can use Team Access Tokens when they need more fine grained access than a Personal Access Token. Personal Access Tokens have full permissions the user has across Organizations, Teams and Stacks. Team Access Tokens have less privilege than Organization Access Tokens, which have access across the Pulumi Organization and across multiple Teams.

With the launch of Team Access Tokens, Pulumi users can now create the following access token types:

Personal Access Tokens: access tokens tied to a user’s access
Organization Access Tokens: access tokens tied to a Pulumi organization’s access
Team Access Tokens: access tokens scoped to a Pulumi Team’s access

This feature is available to all Enterprise and Business Critical customers today, as well as those on our 14-day trial. You can start a trial or Contact Us about the Pulumi Enterprise Edition and Business Critical Edition to take it for a spin!

Introducing Billing Managers: A new role in the Pulumi Service

Isabel Suchanek — Thu, 11 Aug 2022 15:00:22 -0700

We are excited to announce that starting today Pulumi customers can create a Billing Manager role for their organization on the Pulumi Service. We have heard from our customers that having a Billing Manager would solve internal process challenges and are aiming to solve these pain points with the new Billing Manager role.

Feature overview

The Billing Manager role gives the user permissions to access and edit only billing information, with no read or write permissions for stacks. This role is for when you need someone in your Organization to manage billing operations but you do not want them to have any permissions beyond that. Billing Managers can only be invited or added to the Organization by Organization Admins. Once added, the only information a Billing Manager will see is metrics about the Organization and the Billing and Usage page. Learn more about the permissions in the Billing Manager documentation.

Billing Managers can be used for different purposes depending on the Pulumi Service Edition you are on, let’s walk through them.

Pulumi Team Growth Edition

If you are using the Pulumi Team Growth or the legacy Team Pro Edition of the Pulumi Service the Billing Manager role in your Pulumi Organization can do the following:

Add or update credit card information for the Organization (this was the top reported pain point for the customers on Team Editions!)
View the Pulumi Service Edition your Organization is on
View your invoices and the frequency you are invoiced
Update the number of seats your Organization is using (for legacy Editions only)

Team Editions of the Pulumi Service can have 1 Billing Manager at a time.

Pulumi Enterprise Growth and Business Critical Editions

If you are using the Pulumi Enterprise Growth (or the legacy Enterprise per seat Edition) or the Business Critical Edition of the Pulumi Service the Billing Manager role in your Pulumi Organization can do the following:

View the billing period and the renewal date for your Organization
View the number of pre-paid credits
View the amount of pre-paid credits that have been consumed in the billing period
View the Pulumi Service Edition your Organization is on
Update the number of seats your Organization is using (for legacy Editions only)

Enterprise and Business Critical Editions can have unlimited Billing Managers in their Organization.

Let’s see it

Getting started

To add a Billing Manager, make sure you are an Organization Administrator and then follow these steps:

Log in to the Pulumi Service
Navigate to the Billing and Usage page under Organization Settings
In the ‘Billing Managers’ section either invite a Billing Manager by entering their email or copy the Billing Manager invite link and send it to them directly
Once signed up, the Billing Manager will be able to see usage metrics on the Dashboard and navigate to the Billing and Usage page to perform actions and view billing information

This feature is available to all Pulumi Organizations today. Please let us know if you have any feedback on this feature, either by raising an issue in our Pulumi Service GitHub repository or by posting it in our Community Slack. We hope it solves some friction for your organization!

Six Things You Might Not Know About the Pulumi Service

Chris Smith — Mon, 24 Jan 2022 00:00:00 +0000

As a reader of this blog, you’ve probably heard of the Pulumi Service, the default state-management backend of the Pulumi CLI. If that’s the case, there’s also a good chance you’ve heard of a number of the Service’s key features, like helping you organize your projects and stacks, collaborate with others with the help of organizations, or handle sensitive data securely with built-in support for encrypted secrets.

What you might not know, though, is that we’re adding new features to the Pulumi Service all the time, and that some of these features can be fairly easy to miss. So in this post, we’ll highlight a handful of the features you might not be aware of, and that we think make it even easier to manage your infrastructure with Pulumi.

Let’s get started!

Feature 1: Stack Tags

The first thing we’ll cover is the Pulumi stack tags feature. Stack tags are key/value pairs that are associated with your Pulumi stack. You can use them for any number of purposes, from keeping things organized to even flagging whether or not it’s okay for a script to reclaim the stack’s resources.

While you can create, edit, and remove stack tags using the Pulumi CLI (see pulumi stack tag), you can also do so in the Pulumi Console:

Once set, you can quickly filter stacks on your organization’s Projects tab as well.

Feature 2: Link Updates to your CI/CD pipeline

Another helpful thing the Pulumi Service can do is link the Pulumi stack update to the CI/CD job or run that was used to perform it, as well as to the specific source commit:

When Pulumi updates a stack, it will store some information about the local machine state, such the current git SHA if the stack resides in a git repository. It is with this data that the Pulumi Service links to relevant services where possible.

If you’re curious to know all of the information Pulumi has for a stack update, you can navigate to the Environment tab for that update:

Feature 3: Custom Update Messages

One of the most useful pieces of additional data stored with each update is the message property. By default, Pulumi will use whatever the latest git commit message is. But did you know you can customize that message from the command line?

By passing the --message (or -m) flag to pulumi up, you can provide a custom update message, which can help explain the context for why you made a particular infrastructure change:

$ pulumi up --message "Release the hounds\!"

Feature 4: Viewing Resource Changes

Another thing you might have missed is that the Pulumi Service supports multiple views for a stack update’s logs.

The standard view mimics the Pulumi CLI’s output. However, you can switch to the Diff or Diagnostic views, too.

The Diff view displays all of the properties of modified resources, along with their previous/updated values. This can be helpful when trying to understand exactly what happened for a stack update.

The Diagnostic view just outputs so-called “diagnostic” messages from the Pulumi update. Most commonly, this is where you will see the output of things like calls to JavaScript’s console.log(...) or Python’s print(...) functions. It’ll also include the output of dependent tools, like the output when building Docker containers.

Feature 5: Stack Resource Visualization

Another cool feature of the Pulumi Service is being able to visualize a stack’s resources and their relationships to one another. This is a really important feature!

One of the advantages of using an infrastructure as code tool like Pulumi is that you aren’t just creating a flat list of resources. Instead, by the virtue of how the code and resource graph is structured, you are building a graph of resources.

This means that Pulumi has a semantic understanding of not only what resources are in your stack but also how they relate to one another.

If you navigate to a stack’s Resources tab, by default you see them listed in a table. You can filter this list by resource type, or by providing a custom filter:

However, in order to see the expanded resource graph, click the Graph View button. This will switch to rendering the resources as an interactive graph.

Notice here that the resources that are part of a component are grouped together. Also, you can double click on those nodes in the graph to expand or collapse them!

Feature 6: Drilling into Resource Properties

But you don’t need to just settle for a “top-level view” of your resources. You can click on any specific resource on the Resources tab, and see all of the properties of that resource.

This allows you to see all of the properties that Pulumi is tracking for that resource. It will also show you any relationships to other resources in the same stack.

The Pulumi Service also links you to the resource’s cloud provider’s console where possible, so you can see even more details.

Is your resource missing a link to the cloud provider console? With new services being launched from the myriad providers Pulumi supports every day, it’s hard to keep up. So if you would like us to add cloud provider links, please file an issue over in the pulumi/console-requests GitHub repository so we can update our database.

There are plenty of other features to check out in the Pulumi Service, and we have exciting improvements on the way! As always, feel free to stop by the Pulumi Community Slack to learn more, ask questions, or share anything cool you’re up to!

Pulumi Blog: Pulumi cloud

Connect Your Cloud Accounts to Pulumi in Minutes

From hours of setup to a single flow

How it works

Choose the right access level for your security posture

Everything set up, nothing hidden

Get started

Enforce ISO 27001 Across Your AWS Infrastructure

Why ISO 27001 matters

How the pack maps to ISO 27001

Audit and prevent

A growing library of pre-built packs

Get started today

Try Pulumi policies

Trigger Deployments on Git Tags

Why tags?

How it works

Works across every VCS integration

Get started

Generating a Pulumi Provider from an OpenAPI Spec

Why this matters for users

What’s new in v1.0

How it works

What the api namespace covers

What to know before adopting the preview

Try it

Connect Any Git or Mercurial Repo to Pulumi with Custom VCS

The problem

How Custom VCS works

What’s supported

Neo support

Get started

Learn more

Pulumi Cloud REST API Docs, Now Generated from OpenAPI

Why this matters

What’s new

What this unlocks for agents

Same URL, existing links keep working

Try it out

Bitbucket Cloud Meets Pulumi Cloud

Deploy infrastructure from Bitbucket

Two ways to connect

Scaffold new projects from your repositories

Getting started

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

Why tag-based access control?

What’s new?

Tag-based access control

Team role assignments

User role assignments

How permissions work together

How to get started

1. Create a custom role with tag-based rules

2. Assign the role to a team

3. Assign a role to an individual user

Enforce tagging standards with Pulumi Policy

Availability

Conclusion

Learn more

Pulumi Cloud Now Supports Google Sign-In

How it works

Signing up or signing in

Connecting Google to an existing account

Google sign-in vs. SAML SSO

Get started

Expanded Version Control Support in Pulumi Cloud

Connect multiple providers and accounts

What your team can do

Deploy on every push

Preview changes on pull requests

Neo explains your changes

Let Neo open pull requests for you

Detect and fix drift

Secure authentication

Set up new projects from your VCS

Getting started

Now in Public Preview: Store Terraform State in Pulumi Cloud

Why this matters

What you get

How it works