Pulumi Blog: Arun Loganathan

Introducing pulumi do: Direct Resource Operations for Any Cloud

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

Infrastructure as code is the right model for production systems. State tracking, drift detection, and repeatable deployments all matter when you’re managing real workloads.

But sometimes, you also need a quick, one-off interaction with the cloud: create a bucket or a database, look up a VPC, delete a stray resource.

Today we’re introducing pulumi do, a new command for direct resource operations. With pulumi do, you can create, read, update, delete, and query any cloud resource from the terminal with a single command, across thousands of Pulumi-supported providers — no project, code, or state required.

The problem: Sometimes IaC is more than you need

When you’re managing production workloads, IaC is the proven solution. Code lets you declare complex systems, state tracking catches drift before it becomes a problem, dependency graphs sequence changes safely, and policy keeps everything in bounds. That full lifecycle, especially with the backing of a platform like Pulumi Cloud, is exactly what you want to build systems that scale.

But when you (or your coding agent) need an ad-hoc Postgres database, the simplest path with IaC still takes several steps: make a directory, create a project, configure your credentials, write the code, preview, deploy. It works, but it’s not always necessary for what should be a simple operation. pulumi do collapses all of those steps into one, using the same Pulumi providers, resource model, and ecosystem that powers the core Pulumi platform.

Resource creation is also only part of the problem. As Joe laid out in The Agentic Infrastructure Era, the real challenge for AI agents isn’t with code or CLI commands, it’s with everything else: getting a cloud account, resolving credentials, wiring configuration across multiple services. Agent accounts, also released this week, simplify this by letting an agent provision its own ephemeral Pulumi Cloud account, and Pulumi ESC takes care of consolidating credentials across providers. Together, with pulumi do, agents can now go from zero to deployed infrastructure without requiring a human in the loop — and when that one-off resource needs to grow into a more permanent system, there’s a clear graduation path back to full Pulumi IaC.

What it looks like

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

$ pulumi do aws:s3:Bucket create

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

$ pulumi do aws:s3:Bucket create

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

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

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

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

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

$ pulumi do aws:ec2:getVpc --default

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

Same CLI, same output contract, same provider ecosystem.

The command shape

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

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

$ pulumi do aws:s3

Functions and resources for the s3 module.

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

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

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

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

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

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

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

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

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

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

The result:

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

Resource operations

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

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

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

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

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

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

Provider configuration

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

Designed for humans and agents

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

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

What’s next

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

Unified credentials with Pulumi ESC

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

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

Cross-resource references

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

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

Stateful mode and the graduation path

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

Here’s what we’re planning:

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

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

Get started

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

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

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

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.

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!

Announcing the Next Generation of Pulumi Policies: AI-Accelerated Governance for the Cloud

Craig Symonds — Wed, 05 Nov 2025 00:05:00 +0000

The era of AI-accelerated development has created a paradox: the faster developers move, the bigger the governance challenge becomes. For years, security and platform teams have worked to “shift left,” but the tools available have been incomplete. Most focus on detection, which is necessary but not sufficient. They identify thousands of policy violations across an organization’s infrastructure but leave teams with an overwhelming backlog and no scalable way to remediate it. This creates a persistent gap between finding a problem and fixing it. The result is an impossible choice between development velocity and organizational control, forcing leadership to slow down innovation to manage risk.

Today, we end that compromise.

We are thrilled to announce the next generation of Pulumi Policies, a comprehensive governance solution that moves beyond detection to deliver AI-powered remediation at scale. We’re introducing a new lifecycle to secure your cloud: first, Get Clean by using AI to fix your existing policy violations. Second, Stay Clean by using policy as a universal guardrail that makes AI-driven development not just fast, but fundamentally safe. These are not strictly sequential steps; you can begin enforcing “Stay Clean” policies for all new infrastructure while you simultaneously work on the “Get Clean” process for your existing footprint.

Watch our Launch Video:

Part 1: Get Clean - From Thousands of Issues to a Compliant State

The first step to a secure cloud is tackling the mountain of existing misconfigurations spread across your environments.

First, Gain Complete Visibility with the New Policy Findings Hub

To fix your issues, you first need to see them clearly. We have introduced a powerful Policy Findings Hub designed to give every stakeholder the exact view they need.

The Overview Tab: A high-level dashboard with compliance scores for leadership to track trends and measure your organization’s posture.
The Compliance Tab: A control-centric view for auditors and infosec teams, grouping findings by policy (e.g., CIS, NIST) to simplify evidence gathering and prove compliance.
The Issues Tab: A collaborative workspace for platform and development teams to triage, assign, prioritize, and track the remediation of every policy issue.

This hub is powered by our flexible audit capabilities. With Audit Scans for IaC Stacks, you can get an instant compliance baseline on all your existing Pulumi-managed infrastructure without blocking developers or re-deploying thousands of stacks. This is combined with discovery scans of your cloud accounts to give you a single, unified view of every resource, whether managed by Pulumi or not.

The Solution to Remediation at Scale: AI-Powered Fixes with Pulumi Neo

Visibility creates a new problem: an overwhelming backlog. Manually fixing thousands of issues is an impossible task.

This is where Pulumi Neo provides a powerful solution.

Pulumi Neo, our AI platform engineer, is now integrated directly into the Policy Findings hub to automate the most difficult part of the process: the fix itself. From the Issues tab, your teams can now select a group of policy issues, assign them to Neo, and trigger a remediation flow.

Neo is smart. It will:

Analyze the non-compliant resources and the policies they are violating.
Understand the required configuration to make them compliant.
Generate a pull request with the exact code changes needed to fix the issues.

Most powerfully, for an unmanaged resource discovered via a cloud scan, Neo will generate the code to import the resource into a Pulumi stack and apply the fix. This “Import and Fix” workflow transforms unmanaged infrastructure into governed, compliant code, turning a task that could take a developer hours into a simple review-and-merge process. Your teams can finally burn down their issue backlog and achieve a state of continuous compliance.

Part 2: Stay Clean - The Universal Guardrail for Humans and AI

Once you begin cleaning your environment, the next challenge is to stay clean. As AI accelerates infrastructure creation, you need robust guardrails to ensure it doesn’t also accelerate the creation of security risks.

The answer is Policy as Real Code. Pulumi Policies uses general-purpose languages like TypeScript and Python to create sophisticated guardrails that govern every change. To help you establish these controls immediately, we are launching a new suite of pre-built compliance packs authored and maintained by Pulumi experts.

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	✅	✅	✅

These policies act as a universal guardrail for your entire organization by blocking non-compliant changes during pulumi up, before they are ever created. Learn more about our compliance packs.

And now, you can even use Neo to author new policies. You can ask Neo in plain English to “create a policy that prevents overly permissive IAM roles,” and it will generate the code for you. This creates a powerful, dynamic governance system where AI can help you build the very rules that then govern its own actions. If you then ask Neo to create an admin role, the deployment will be blocked by the policy it just helped write. This is how we make AI safe to go fast.

A New Era of Collaboration

This “Get Clean, Stay Clean” lifecycle transforms how teams work together:

Platform Teams lead prevention by building real-code guardrails, proving their value with measurable compliance scores.
Security Teams drive the “Get Clean” process with continuous, non-blocking audit scans and use the Findings hub to manage compliance without slowing development.

Governance That Accelerates You

The age of AI-driven development demands AI-powered governance. With this new generation of Pulumi Policies, we are providing the essential infrastructure for platform engineering teams to not just survive, but thrive. You can finally build preventative guardrails that developers love, secure your cloud at scale, and transform governance from a blocker into a business accelerator. Learn more about Pulumi Insights & Governance capabilities.

This powerful new experience is available today. Navigate to the Policies and Policy Findings tab in Pulumi Cloud to explore your new governance capabilities and meet the future of platform engineering.

Try Pulumi Policies

Ready to try these features?

Sign up for Pulumi Cloud and start a Neo task
Read the Get Started guide to set up and apply a policy group to stacks and clouds.
Join the Community Slack to share feedback on the new features

For complete documentation, visit our Policies documentation.

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.

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:

Announcing Snowflake Dynamic and Rotated Credentials with Pulumi ESC

Claire Gaestel — Thu, 01 May 2025 00:00:00 +0000

Snowflake is the data cloud powerhouse for countless businesses, critical for everything from customer dashboards to billing pipelines. The stakes are immense: this data must be strictly secured and always available. But managing this with static credentials or manual key rotation creates persistent security vulnerabilities and introduces operational instability, risking disruptions during clumsy updates. Pulumi ESC eliminates this dilemma with two purpose-built Snowflake integrations:

snowflake-login: Provides dynamic, short-lived OIDC tokens for temporary authentication to Snowflake.
snowflake-user: Automates the rotation of RSA keypair secrets for Snowflake users, essential for secure key-pair authentication.

Pulumi ESC allows you to securely manage and consume these Snowflake credentials in your applications, development workflows through ESC SDK, Pulumi CLI, Kubernetes integrations, and more!

Use the snowflake-login provider when you need temporary, just-in-time credentials to interact with Snowflake, such as from local development environments, CI/CD pipelines, or scripts. It leverages OIDC to mint short-lived access tokens, eliminating the need to store static tokens.

This approach significantly reduces the attack surface by removing long-lived credentials required for authentication.

Setup:

Configure OIDC in Snowflake: Create a Security Integration in Snowflake to trust the Pulumi OIDC provider (https://api.pulumi.com/oidc), map the appropriate user claims and create a Snowflake user. Check out the docs] for more details
Configure ESC Environment: Define the snowflake-login provider in your ESC environment, specifying the Snowflake account and the user configured for OIDC.

# my-org/logins/snowflake
values:
 snowflake:
 login:
 fn::open::snowflake-login:
 oidc:
 account: myorganization-account
 user: ESC_LOGIN_USER
 role: ESC_ROLE  # Optional

When this environment is opened, ESC securely handles the OIDC flow and makes the temporary token available under snowflake.login.token.

snowflake-user: Automated Rotation for RSA Key Secrets

For applications or services using Snowflake’s key-pair authentication, maintaining the security of those RSA keys is crucial. The snowflake-user rotator automates the lifecycle management of these keys as rotated secrets within ESC. This rotater uses the same two-secret rotation strategy we use in rest of ESC’s rotated secrets providers. This eliminates manual rotation toil and ensures keys are regularly refreshed according to policy, enhancing the security of the user secret itself. Check out the rotated secrets blog post to learn more about its benefits.

Setup:

Prepare Snowflake:
- Create the target user (e.g., MY_APP_SNOWFLAKE_USER) whose keys need rotation.
- Set up a dedicated rotation role with OWNERSHIP permission over the users you wish to rotate, so it can modify their keys.
- Create a service user using the rotation role, and setup OIDC to allow ESC to assume the role for rotation.
Rotation Environment: Define the rotation, importing the managing credentials and specifying the target user.

# Environment: my-org/rotators/snowflake-app-key
values:
 rotatedKey:
 fn::rotate::snowflake-user:
 inputs:
 login: ${environments.logins.snowflake.snowflake.login} #reference credentials created using `snowflake-login`
 targetUser: ESC_ROTATION_DEMO_USER # User whose keys rotate

After setup, use the triple-dot menu -> “Rotate Secrets” in the Pulumi Cloud UI and ensure rotation happens. Once you rotate a couple of time and ensured everything works well, navigate to the “Secret Rotation” tab for your Rotation environment in the Pulumi Cloud console and define the rotation schedule.

Feature	`snowflake-login` (Dynamic OIDC Login)	`snowflake-user` (Rotated Secrets)
Credential Type	Short-lived OIDC access token	Long-lived RSA Private Key secret (managed by ESC) + Public Keys (in Snowflake)
Primary Use Case	Temporary authentication to Snowflake (CLI, scripts, dev, CI/CD).	Key-pair authentication for long-lived applications/services connecting to Snowflake.
Ideal Scenario	Short-lived tasks; frequent, temporary access needs.	Applications needing persistent connections; keys required at deploy time; apps sensitive to auth blips.
Lifecycle	Generated on-demand, expires quickly (minutes/hours).	Rotated automatically on a schedule (e.g., days/months).
Connection Impact	Requires re-authentication or new token fetch when token expires.	Rotation is typically seamless; two-key strategy avoids connection drops if apps update keys promptly.
Benefit Focus	Eliminates static authentication tokens/credentials.	Automates lifecycle management of user key-pair secrets, ensures key freshness.

Conclusion

Pulumi ESC’s new Snowflake integrations provide robust solutions for modern credential management challenges. Use snowflake-login for secure, temporary OIDC-based access and snowflake-user to automate the rotation of critical RSA key secrets. By adopting these capabilities, you can significantly enhance your Snowflake security posture, reduce operational overhead, and simplify compliance.

Explore the detailed documentation for snowflake-login and snowflake-user, and see how Pulumi ESC can centralize and secure your configuration and secrets across all your environments. Join the conversation in the Pulumi Community Slack or our GitHub repository.

Introducing Automated Database Credential Rotation for PostgreSQL and MySQL in Pulumi ESC

Sean Yeh — Wed, 30 Apr 2025 00:00:00 +0000

Securing access to critical data stores is paramount in today’s cloud-native world. Yet, managing database credentials often involves static, long-lived passwords – a significant security blind spot. These static secrets, frequently embedded in application configurations or accessible to multiple team members, represent a prime target for attackers. Manually rotating these credentials is a cumbersome, error-prone task that’s often neglected, leaving databases vulnerable for extended periods. Building on our commitment to robust secrets management, we are excited to launch Automated Database Credential Rotation for PostgreSQL and MySQL in Pulumi ESC!

The Persistent Challenge of Static Database Secrets

Relying on static database credentials introduces substantial risks, which automated rotation helps mitigate:

Security Vulnerabilities & Exposure: Static credentials, if compromised through leaks, phishing, or unauthorized access, provide long-term access to attackers. Automated rotation significantly shrinks this window of opportunity.
Operational & Compliance Burdens: Manually rotating database credentials is complex, error-prone, and requires careful coordination to avoid downtime. These manual rotations are hard to audit and demonstrate compliance with regulations like SOC 2, GDPR, or HIPAA (which often mandate rotation).
Network Complexity & The DIY Burden: Databases in private networks (like AWS VPCs) require secure access for rotation. We provide an open-source Lambda connector for AWS VPCs. While homegrown solutions can bridge the network gap, building and maintaining the actual rotation logic (state, error handling, two-secret strategy) is complex. Crucially, DIY approaches typically lack integrated revision history, centralized auditing, and unified management provided by platforms like Pulumi ESC, increasing operational overhead.
Tooling, Ecosystem, and Cloud-Native Connectivity: Despite cloud IAM authentication options, many standard tools (GUIs, BI, ETL), legacy apps, and even certain cloud-native configurations (multi-cloud, specific Kubernetes setups) still rely on username/password. Direct IAM integration isn’t always feasible or practical, making automated rotation of traditional credentials essential for broad compatibility and security.

Pulumi ESC addresses these challenges by automating the secrets rotation process, including connectivity options for databases in private AWS networks using our Lambda connector, and allows you to consume them in your applications through ESC’s various developer-friendly methods including ESC SDK, Pulumi CLI, Kubernetes External Secrets Operator, CSI Driver, etc.

Introducing ESC Rotated Secrets for Databases

Pulumi ESC’s Rotated Secrets capability now extends to your critical databases, bringing automation and enhanced security to credential lifecycle management. We are adding support for the following databases and connectivity options:

Database	Publicly Accessible	AWS VPCs	Azure VNETs	GCloud VPCs
PostgreSQL	✅	✅ (via Lambda)	Planned (upvote issue)	Planned (upvote issue)
MySQL	✅	✅ (via Lambda)	Planned (upvote issue)	Planned (upvote issue)

Key benefits include:

Automated Rotation Schedules: Effortlessly define rotation frequencies (daily, weekly, monthly) that align with your security policies, eliminating manual toil and ensuring consistency.
On-Demand Rotation: Instantly rotate credentials in response to security events, personnel changes, or policy updates with a single click or command.
Seamless ESC Environment Integration: Manage rotated database credentials alongside all your other application configurations within ESC Environments, leveraging composition and environment inheritance.
Two-Secret Strategy: ESC maintains both the current and previous valid credentials simultaneously. This prevents application downtime during rotation, as instances can gracefully transition to the new credential.
Auditing and Tracking: Maintain a complete audit trail of credential rotations, including who initiated the rotation and when, simplifying compliance and governance.
Admin and Creator Control: Securely configure rotation using privileged database “managing user” credentials stored within ESC, keeping them separate from the rotated credentials consumed by applications.
Configure Webhooks for Automation: Trigger notifications, CI/CD pipelines (e.g., Pulumi Deployments to update application stacks), or custom workflows upon successful rotation, keeping dependent systems synchronized.

The following setup guide provides a detailed walkthrough for rotating PostgreSQL credentials for an AWS RDS instance hosted within a private VPC, which requires the AWS Lambda-based connector. For publicly accessible databases (PostgreSQL or MySQL), you can use the simpler Direct Connect method documented on the respective integration pages. Please refer to the MySQL documentation page for specific instructions on MySQL rotation (both Direct Connect and Lambda Connector).

How to Set Up and Use Rotation for AWS RDS PostgreSQL running in VPC

Setting up rotation for AWS RDS or Aurora PostgreSQL databases running inside an AWS VPC involves creating the required users within your database, deploying the AWS Lambda connector infrastructure via a Pulumi template, configuring ESC environments, and scheduling the rotation.

Understanding the AWS Lambda Connector: The open-source ESC Lambda connector acts as a secure proxy for database credential rotation within your VPC. It enables Pulumi ESC to safely rotate database credentials without needing direct network access from ESC to your database and without exposing your database to external networks. This connector is currently required to rotate credentials for PostgreSQL or MySQL databases hosted within an AWS VPC. Note: The AWS Lambda Connector is only available to Enterprise and Business Critical customers.

Step 1: Prepare Your PostgreSQL Database Users

You’ll need two types of users configured, resulting in three specific database user accounts:

Managing User: A privileged user that ESC will use (via the Lambda connector) to perform the password rotations. This user needs permissions to change the passwords of the application users.
Application User 1 and Application User 2: The two application users whose passwords ESC will manage. ESC rotates between these two users, ensuring two users are always active as applications gradually phase out the previous user credentials.

Connect to the database as a superuser and run the following SQL commands:

Create the application users whose passwords you want ESC to rotate automatically:

```sql
CREATE USER user1 WITH PASSWORD 'initial_password';
GRANT SELECT, INSERT, UPDATE ON yourDatabase TO user1;
CREATE USER user2 WITH PASSWORD 'initial_password';
GRANT SELECT, INSERT, UPDATE ON yourDatabase TO user2;
```

Create the designated “managing user” account with privileges to modify passwords for the application users:

```sql
CREATE USER managing_user WITH PASSWORD 'manager_password';
ALTER USER managing_user WITH CREATEROLE;
GRANT user1 TO managing_user WITH ADMIN OPTION;
GRANT user2 TO managing_user WITH ADMIN OPTION;
```

Step 2: Bootstrap Rotation Infrastructure (Lambda Connector) and Create ESC Environments

To rotate credentials for PostgreSQL databases within AWS VPCs securely, you need to configure an AWS Lambda function (the connector) within your VPC and create the corresponding ESC environments.

If your PostgreSQL instance is running on AWS RDS, we recommend using our Pulumi Template to simplify the process of creating the Lambda function, associated AWS IAM Roles, Security Groups, and the basic ESC environment structure. You can start it from the Pulumi console or by running the following command in your terminal:

Run pulumi new esc-connector-lambda-typescript in your terminal.
This command initializes a new Pulumi project designed to provision the necessary AWS Lambda connector resources and create the ESC environments.
Follow the prompts. You will first provide a Pulumi project name (e.g., my-db-rotation-infra). Then, you will be prompted for configuration values like:
- Your target AWS Region (aws:region)
- The RDS Database Identifier (rdsDbIdentifier)
- The specific name for the ESC rotation environment (e.g., postgresrotation/Rotator). This environment will contain the two application users’ credentials and configuration for rotation.
- The specific name for the ESC managing credentials environment (e.g., postgresrotation/ManagingCreds).
Run pulumi up to deploy the AWS resources and create the ESC environments using the names you provided.

Step 3: Configure ESC Environments and Test

The Pulumi template creates two ESC environments with most of the configuration pre-filled. You need to update them with your specific PostgreSQL user credentials and database name.

Managing Credentials Environment (e.g., postgresrotation/ManagingCreds): Navigate to this environment in the Pulumi Cloud console. Update the managing user’s username and password. The awsLogin section, which provides credentials for the Lambda connector to assume, should be pre-filled by the template.

# postgresrotation/ManagingCreds
values:
 managingUser:
 username: managing_user # Replace with your managing user's name
 password:
 # Securely replace the placeholder with your managing user's password using fn::secret
 fn::secret:
 ciphertext: ZXNjeA... # Replace with your encrypted password
 awsLogin:
 fn::open::aws-login:
 oidc:
 duration: 1h
 roleArn: arn:aws:iam::616138583583:role/PulumiEscSecretRotatorLambda-InvocationRole-7e4646f # Example Role ARN populated by template
 sessionName: pulumi-esc-secret-rotator-${esc.context.environment} # Example Session Name populated by template

Rotation Environment (e.g., <project-name>/Rotator): Navigate to this environment. Most fields related to the Lambda connector (Lambda ARN, host, port, references) are pre-filled by the template outputs. You must update the database name and the application usernames mapping. Note the connector.awsLambda block indicating the use of the Lambda connector.

# postgresrotation/Rotator
values:
 dbRotator:
 fn::rotate::postgres:
 inputs:
 database:
 # Configure the AWS Lambda connector for private VPC access
 connector:
 awsLambda:
 login: ${environments.postgresrotation.ManagingCreds.awsLogin}
 lambdaArn: arn:aws:lambda:us-west-2:616138583583:function:PulumiEscSecretRotatorLambda-Function-d9932fe # Example Lambda ARN populated by template
 # Database connection details (used by the Lambda connector)
 database: mydb # Replace with your DB name
 host: tf-20250428212643894700000001.cluster-chuqccm8uxqx.us-west-2.rds.amazonaws.com # Example Host populated by template
 port: 5432 # Example Port populated by template
 managingUser: ${environments.postgresrotation.ManagingCreds.managingUser}
 # List of application users whose passwords will be rotated
 rotateUsers:
 username1: user1 # Replace DB username if different from logical name
 username2: user2 # Replace DB username if different from logical name

 # state section is automatically managed by ESC after first rotation
 # Do not provide state unless migrating existing, known credentials.
 # state:
 # current:
 # password:
 # fn::secret:
 # ciphertext: ZXNjeAAAA...
 # username: user1
 # previous:
 # password:
 # fn::secret:
 # ciphertext: ZXNje21AA...
 # username: user2

Test with Manual Rotation:
- Use the triple-dot menu -> “Rotate Secrets” in the Pulumi Cloud UI for the Rotator environment.
- Alternatively, use the Pulumi CLI: pulumi env rotate <your-org>/<project-name>/Rotator> (e.g., pulumi env rotate myorg/postgresrotation/Rotator). Remember to replace <your-org> and <project-name>.
- Perform a rotation. If you didn’t provide the state block, this first rotation generates a new password for the user designated as current (e.g., user1 associated with username1) and updates it in the database via the Lambda connector. The dbRotator value in ESC will now show this user/password under current, and the state block will be populated.
- Perform a second rotation. Observe how the previous current user (user1/username1) and its password become the previous entry in the ESC value. The system now rotates the password for the other user (user2/username2), makes it the new current, and updates the database accordingly. Subsequent rotations cycle between user1 and user2.
- Check the Environment Revision History in the Pulumi Cloud console to track the changes to the current and previous state fields after each rotation.

Step 4: Schedule Automated Rotations

Once you are satisfied that manual rotations via the Lambda connector are working correctly, navigate to the “Secret Rotation” tab for your Rotator environment (e.g., postgresrotation/Rotator) in the Pulumi Cloud console.
Define your desired automated rotation schedule (e.g., every 30 days). ESC will automatically trigger rotations according to this schedule, ensuring your credentials stay fresh without manual intervention.

What’s Next?

This launch significantly enhances database security posture through automation for PostgreSQL and MySQL, but we’re just getting started. We plan to expand our rotated secrets capabilities:

More Databases: Support for MongoDB, Microsoft SQL Server, Oracle, and others.
Databases in Private Networks on Other Clouds: Rotation solutions for databases hosted in private networks within Azure, Google Cloud, and more.

Have a specific database or integration in mind? Upvote existing issues or open a new request in our GitHub repository!

Conclusion

Pulumi ESC’s Automated Database Credential Rotation drastically simplifies a critical security task. By automating the rotation of PostgreSQL and MySQL credentials, ESC reduces operational overhead, minimizes the risk associated with static secrets, and helps you meet compliance requirements more easily. Whether your databases are publicly accessible (using Direct Connect) or in private AWS networks (using the Lambda connector), ESC provides a unified way to manage their lifecycle securely.

We encourage you to explore the Pulumi ESC documentation and try out rotated database secrets for PostgreSQL and MySQL. Your feedback is invaluable – please share your experiences and suggestions on our GitHub repository. Secure your databases with automated rotation and build with confidence!

Announcing Infisical Providers for Pulumi ESC: Dynamic Login and Dynamic Secrets

Boris Schlosser — Mon, 28 Apr 2025 00:00:00 +0000

We are thrilled to announce enhanced integration support for Infisical within Pulumi ESC! Pulumi ESC centralizes secrets and configuration management, providing a unified source of truth across your environments. With the addition of Infisical, a popular open-source secrets management platform, ESC further extends its ecosystem, enabling seamless and secure access to secrets stored across diverse systems.

This release introduces two distinct dynamic providers for Infisical, each designed to improve security and streamline your workflows:

infisical-login (Dynamic Login): This provider securely generates short-lived OIDC access tokens for authenticating to Infisical. Static, long-lived credentials are a significant security risk. The infisical-login provider directly addresses this by generating temporary, just-in-time credentials using OIDC. Use this provider when you need temporary credentials to interact directly with Infisical, for instance, using the Infisical CLI or SDKs in local development or CI/CD pipelines, without storing long-lived static tokens. ESC manages the OIDC flow, providing a fresh token when needed.
infisical-secrets (Dynamic Secrets): This provider dynamically fetches secrets stored within your Infisical projects and makes them available within the Pulumi ESC environment. Use this provider when you need specific secrets from Infisical to configure your applications or infrastructure managed via ESC. This centralizes secret consumption, allowing you to access Infisical secrets using the same consistent ESC patterns used for AWS, Azure, GCP, Vault, 1Password, and more.

Pulumi ESC acts as a robust secrets broker provider consistent API interface for all your tools, applications and workflows. It securely handles both the generation of temporary authentication credentials (like with infisical-login) and the fetching of application secrets (like with infisical-secrets) from various providers such as Infisical, cloud platforms (AWS, Azure, GCP), and other secret managers (Vault, 1Password). Once centralized in ESC, these secrets and configurations are consistently available for you to consume via ESC’s many developer friendly methods including the ESC SDK, Pulumi CLI, Kubernetes External Secrets Operator, CSI Driver, or sync them to various platforms where they are needed such as GitHub Secrets, AWS Secrets Manager, and more!

Getting Started: Using the Infisical Providers

Let’s walk through how to configure and use each provider.

Prerequisites

Configure Infisical for OpenID Connect(OIDC) before you try out the providers. Follow the steps in Infisical OIDC documentation. This involves creating an Identity in Infisical, adding OIDC authentication pointing to https://api.pulumi.com/oidc, and configuring the audience and subject claims. Note down the Identity ID.

Create a Pulumi ESC environment (e.g., pulumi-org/infisical-auth/oidc-login) with the following environment definition and update the identityId.

# Environment: pulumi-org/infisical-auth/oidc-login
values:
 infisical:
 # Configure the Dynamic Login provider using OIDC
 login:
 fn::open::infisical-login:
 oidc:
 identityId: <your-identity-id> # Replace with your Infisical Identity ID

 # Expose the token as an environment variable for easy consumption
 environmentVariables:
 INFISICAL_TOKEN: ${infisical.login.accessToken}

Save the environment.
Validate the environment by clicking on Open in the Pulumi Cloud console, or running pulumi env open pulumi-org/infisical-auth/oidc-login in your CLI. The output will include the infisical.login.accessToken.

Usage Example: Run Infisical CLI commands dynamically:

pulumi env run pulumi-org/infisical-auth/oidc-login -- infisical secrets get API_KEY --projectId=<your-project-id>
# The INFISICAL_TOKEN env var is automatically injected

How to Use the infisical-secrets Provider (Dynamically Fetching Secrets)

Use this provider to pull secrets from Infisical into your ESC environment for consumption by your applications, CI/CD systems, Pulumi IaC, Terraform and more!

Create an ESC environment where you need the secrets (e.g., pulumi-org/my-app/dev).
Import the dynamic login environment (if using OIDC for authentication, which is recommended). This makes the temporary Infisical token available.
Configure the infisical-secrets provider, referencing the imported login details. See example below.

Specify the secrets to fetch using the get block. Replace placeholders.

# Environment: pulumi-org/my-app/dev
imports:
 # Import the environment performing Dynamic Login (recommended)
 - pulumi-org/infisical-auth/oidc-login # Use the path to your login environment

values:
 # Define a structure to hold secrets fetched from Infisical
 infisicalSecrets:
 fn::open::infisical-secrets:
 # Authenticate using the token from the imported Dynamic Login environment
 login: ${infisical.login} # Pass the login object from the import
 # Specify secrets to retrieve from Infisical
 get:
 # Define names for the secrets as they will appear in ESC's output under 'infisicalSecrets'
 apiKey: # This is the name within ESC
 projectId: <your-infisical-project-id>
 environment: prod # The Infisical environment slug (e.g., 'prod', 'dev')
 secretKey: api-key # The key of the secret in Infisical
 appSecret: # Pull another secret `app-secret` into ESC
 projectId: <your-infisical-project-id>
 environment: dev
 secretKey: app-secret

 # Optionally, map fetched secrets to environment variables for application consumption
 environmentVariables:
 API_KEY: ${infisicalSecrets.apiKey}
 APP_SECRET: ${infisicalSecrets.appSecret}

Save the environment.
Validate the environment by clicking on Open in the Pulumi Cloud console, or running pulumi env open pulumi-org/my-app/dev in your CLI. The output will show the imported infisical.login, the fetched secrets under infisicalSecrets, and the mapped environmentVariables.

Usage Example: Run an application that needs these secrets:

pulumi env run pulumi-org/my-app/dev -- node app.js
# The API_KEY and APP_SECRET env vars are automatically injected

Conclusion

The new infisical-login and infisical-secrets providers for Pulumi ESC offer powerful and secure ways to interact with Infisical. Use infisical-login for dynamic, short-lived OIDC authentication when interacting directly with Infisical APIs or CLIs. Use infisical-secrets to securely fetch secrets from Infisical into your centralized ESC environment. Together, they enhance your security posture and simplify configuration management.

We encourage you to explore these new capabilities. Dive into the infisical-login, infisical-secrets for detailed configuration options, check out the broader Pulumi ESC Documentation, and share your feedback or ask questions in the Pulumi Community Slack.

Pulumi Release Notes: Pulumi MCP Server, Pulumi ESC Rotated Secrets, and Policy Enhancements

Arun Loganathan — Fri, 25 Apr 2025 00:00:00 +0000

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

We’ve been busy over the past two months, shipping significant enhancements across the Pulumi ecosystem. From major improvements to our core IaC platform with Azure Native V3 and cross-language Components to powerful new capabilities in Pulumi ESC and Insights, these updates deliver on our commitment to making cloud management more powerful, accessible, and secure. We’re particularly excited about our AI integration through the MCP Server, enabling developers to work with infrastructure in a more intuitive, contextual way. Let’s dive into the details of what’s new.

Pulumi IaC
Pulumi ESC
- Rotated Secrets
- Pulumi ESC GitHub Action
Pulumi Insights
- Enforce Policy as Code on Discovered Resources
Wrap up

Pulumi IaC

Azure Native V3

We’re excited to announce the release of Pulumi Azure Native V3, delivering a remarkable 75% reduction in SDK size while maintaining complete coverage of the Azure ecosystem. The new SDK provides faster downloads, more manageable package sizes, and more reliable performance while maintaining access to all Azure resource properties. With a modern API surface, consistent input/output schemas, and simplified version management, it’s now easier than ever to build and deploy Azure resources with Pulumi. Read the blog post or check out the Azure Native Provider documentation.

Pulumi Model Context Protocol (MCP) Server

The new Pulumi Model Context Protocol (MCP) Server integration brings AI-assisted infrastructure development directly into your coding workflow. By connecting AI-powered code assistants with Pulumi’s CLI and registry, MCP enables real-time resource information and infrastructure management without leaving your editor. This integration drastically reduces context switching, accelerates resource discovery, and enables faster coding with intelligent assistance. Use it with tools like GitHub Copilot, Anthropic’s Claude Code, Cursor, and others to streamline your infrastructure development experience. Learn more about AI-assisted IaC.

Next-Generation Pulumi Components

Introducing the next generation of Pulumi Components with enhanced cross-language capabilities, enabling you to create reusable infrastructure abstractions once and deploy them using any supported Pulumi language. These improved components allow platform teams to codify organizational standards into shareable libraries while giving developers simpler, more approachable interfaces that enforce best practices automatically. With built-in input validation, detailed documentation, improved error messages, and cross-language support, your components can now reach a wider audience of developers regardless of their preferred programming language. Read the blog post or explore the Components documentation.

Registry Wave 2: 27 New Providers

We’ve expanded the Pulumi Registry with 27 new native providers, bringing the total to over 150 providers and 7,500 resource types. This wave adds support for popular services like Jira, Gitlab, Railway, Neon, PlanetScale, and many more, giving you more options for managing your entire cloud infrastructure with Pulumi. Each provider is published as a standalone package, making it easier to adopt new providers without updating your entire Pulumi installation. Start using these providers today to expand your infrastructure management capabilities. Read the blog post or browse the Pulumi Registry.

Enhanced Terraform Conversion

With Pulumi CLI version 3.153.0 and above, we’ve supercharged our Terraform conversion capabilities. Now you can automatically convert ANY Terraform project to Pulumi and import its resources - even if it uses providers that don’t have native Pulumi equivalents. This breakthrough eliminates a significant migration barrier, allowing teams to convert their entire Terraform codebase without provider limitations. The enhanced converter handles mixed provider scenarios effortlessly, maintaining access to specialized Terraform providers you already leverage while modernizing your infrastructure deployment. This builds on our existing capability to use any Terraform/OpenTofu provider in your Pulumi projects, making it easier than ever to migrate your infrastructure as code to Pulumi. Read the blog post to see examples and learn how to try it for yourself.

Improved Refresh and Destroy Experience

As of Pulumi CLI version 3.160.0, we’ve introduced a significant enhancement to the pulumi refresh and pulumi destroy commands. These commands now support the --run-program flag, which enables them to run your program code before refreshing or destroying your stack. This is especially valuable for teams working with short-lived credentials, dynamic resources, or any workflow where your code needs to run to establish the right context. Previously, while these commands took into account updated configuration from your Pulumi.<stack>.yaml files, they didn’t consider changes in your actual code, which could break workflows that depend on code to update credentials or determine resources to manage. This improvement ensures your infrastructure operations have the full context they need to succeed, particularly important when using OIDC-based authentication, dynamically fetching credentials from a secrets manager, or working with dynamic providers. We plan to make this the default behavior eventually, but are introducing it as an opt-in flag first to ensure a smooth transition. Read more in our RFC on making program execution the default behavior.

GitLab Integration Improvements

We’ve significantly enhanced our GitLab integration with support for multiple pipeline jobs and simplified authentication. The improved integration works with both GitLab CI/CD server and SaaS offerings, supporting parallel execution of multiple Pulumi steps within a single GitLab pipeline. Authentication has been streamlined with a new method that eliminates the need for personal access tokens, instead leveraging GitLab’s CI/CD variables for secure, seamless authentication. These enhancements make it easier than ever to implement GitOps workflows with Pulumi and GitLab. Read the blog post or check out the documentation.

Faster Secrets Management

We’ve optimized secrets performance in Pulumi, resulting in significantly faster operations when working with large numbers of secrets. Through focused engineering efforts, we’ve achieved up to 75% reduction in secrets processing time for large stacks, with the most dramatic improvements seen in stacks with many outputs. This enhancement particularly benefits workflows involving many secrets, resource outputs, or stack references. The improvements are available starting with Pulumi 3.123.0 and require no changes to your existing code. Read the blog post to learn more about these performance improvements.

Pulumi Kubernetes Operator 2.0

The Pulumi Kubernetes Operator 2.0 is now generally available, bringing advanced automation capabilities for managing Pulumi stacks within Kubernetes clusters. The new version includes a completely rewritten, faster codebase with enhanced reconciliation logic, better error handling, and improved CRD management. Version 2.0 also adds critical features like automatic retry for temporary failures, fine-grained refresh control, idempotent updates, and advanced stack management capabilities. These improvements make the operator more reliable and powerful for managing infrastructure directly from your Kubernetes clusters. Read the blog post or check out the operator documentation.

Java SDK 1.0

The Pulumi Java SDK is now generally available with its 1.0 release, providing first-class support for Java in Pulumi’s multi-language ecosystem. The GA release includes feature parity with other Pulumi languages, improved documentation, enhanced type safety, and support for the complete Pulumi programming model. We’ve also expanded the Java SDK to support all current LTS versions and ensure smooth interoperability with the broader Java ecosystem. This milestone makes Pulumi an excellent choice for Java teams looking to manage their infrastructure using their preferred language. Read the blog post or check out the Java getting started guide.

Pulumi Copilot in VSCode

Pulumi Copilot is now available in Visual Studio Code, bringing AI-powered assistance directly to your infrastructure development environment. The VSCode extension helps you write, understand, and debug Pulumi code with inline explanations, transformation suggestions, and code generation capabilities. Copilot can also assist with converting between Pulumi languages and translating from other IaC tools like Terraform and CloudFormation. This integration makes it easier to learn Pulumi, accelerate your infrastructure development, and solve complex configuration challenges. Read the blog post or install the extension today.

Autonaming Configuration

We’ve enhanced Pulumi’s autonaming feature with new configuration options that give you more control over resource naming. You can now globally disable autonaming or configure it on a per-component basis, allowing you to precisely control when Pulumi generates names for your resources. This is particularly valuable for organizations that want to ensure consistent, predictable resource naming across their infrastructure. The new configuration is available in Pulumi CLI version 3.91.1 and later, and requires no code changes to implement. Read the blog post or check out the documentation for implementation details.

Pulumi ESC

Rotated Secrets

Address the persistent challenge of static, long-lived credentials with the new Rotated Secrets capability in Pulumi ESC. Static secrets pose significant security risks due to potential exposure and infrequent, error-prone manual rotation. While dynamic secrets are ideal, Rotated Secrets provide a powerful alternative for applications requiring long-lived credentials, systems needing persistent connections, or where dynamic credentials aren’t feasible. Automatically rotate credentials like AWS IAM user access keys (with more integrations coming soon) on flexible schedules or on-demand, eliminating manual effort and reducing the window of vulnerability. Rotated Secrets seamlessly integrate into ESC environments, utilize a “two-secret” strategy for smooth transitions, offer robust auditing, and allow for separation of administrative and consumer roles. Configure rotations directly within your ESC definitions and set up webhooks to automate downstream updates. Read the blog post.

Pulumi ESC GitHub Action

Securely inject secrets and configuration directly into your GitHub Actions workflows with the new Pulumi ESC GitHub Action. This action lets you dynamically inject values from your Pulumi ESC environments as needed during CI/CD runs, eliminating the need to store static, long-lived credentials within GitHub and reducing secret sprawl. Leverage Pulumi ESC’s automatic secret rotation capabilities and run ESC commands directly within your workflows for streamlined environment management. Combine this action with pulumi/auth-actions for seamless, tokenless authentication to Pulumi Cloud using OIDC, further enhancing security. Read the blog post.

Pulumi Insights

Enforce Policy as Code on Discovered Resources

Extend the governance reach of Pulumi Policy as Code beyond IaC-managed resources to encompass your entire cloud environment with a powerful new capability in Pulumi Insights. You can now automatically apply your existing policies to resources discovered by Pulumi Insights, regardless of how they were created. Simply link your Insights Accounts (representing cloud provider integrations) to your Policy Groups alongside your stacks. Pulumi will then evaluate all resources within those accounts against your defined policies, surfacing violations centrally. This allows you to write policies once and apply them universally across both IaC and discovered resources, dramatically simplifying how you maintain consistent security and compliance standards at scale across AWS, Azure, OCI, and Kubernetes. Read the blog post.

Wrap up

These new features and enhancements represent our ongoing commitment to improving the cloud management experience for developers and platform teams. Whether you’re managing cloud resources with our streamlined Azure Native V3 provider, creating reusable abstractions with cross-language Components, leveraging AI assistance with the MCP Server, or strengthening your security posture with ESC Rotated Secrets and policy enforcement, we’re focused on making your infrastructure management more efficient, secure, and enjoyable. As we continue to innovate, your feedback helps shape our roadmap and prioritize improvements that matter most to you.

Explore all the new capabilities and share your feedback – we’re always listening! Open an issue in the Pulumi Cloud requests repository or the pulumi/pulumi repository for anything CLI-related. Stay tuned for more exciting updates!

Introducing Rotated Secrets in Pulumi ESC

Claire Gaestel — Wed, 19 Feb 2025 00:00:00 -0400

Managing secrets effectively is no longer a “nice-to-have”—it’s a must-have for any organization building and scaling applications in the cloud. Static, long-lived credentials like database passwords, API keys, and IAM user credentials are a major security vulnerability. They’re often overexposed, residing in source code, configuration files, or other easily accessible locations. Manual rotation processes are tedious, error-prone, and infrequent, leaving a wide window of opportunity for potential breaches. Today, we’re thrilled to announce a powerful new capability in Pulumi ESC that directly addresses this challenge: Rotated Secrets.

The Challenge with static secrets: A ticking time bomb

Traditional secrets management often relies on static, long-lived credentials. This approach creates several critical problems:

Increased attack surface: The longer a secret remains unchanged, the greater the chance it will be compromised through accidental exposure, phishing attacks, or insider threats.
Manual, error-prone rotation: Manual rotation processes are time-consuming and require significant coordination across teams. A single mistake can lead to application downtime or even data breaches.
Inconsistent practices: Ad-hoc scripts and manual procedures often lead to inconsistent rotation policies, making it difficult to enforce security best practices across the organization.
Compliance headaches: Many compliance regulations (like SOC 2, GDPR, and HIPAA) require regular secret rotation. Manual processes make it difficult to demonstrate compliance and can lead to costly penalties.

These challenges are amplified in complex, multi-cloud, hybrid, or on-premises environments where secrets are distributed across numerous systems. While Pulumi ESC’s Dynamic Secrets addresses all of these challenges and makes secret management much easier, static secrets remain a reality for many organizations. Legacy applications, compliance mandates, or integration limitations often prevent a full switch to dynamic credentials. In such cases, Rotated Secrets provide a second-best option—automating credential rotation to minimize risk while integrating seamlessly with existing workflows.

Introducing ESC Rotated Secrets

Pulumi ESC’s new Rotated Secrets feature provides an elegant solution to the challenges of secret lifecycle management. It enables automated, seamless rotation of credentials, ensuring that your secrets are always up-to-date and secure. Here’s how it solves the problems outlined above and more:

Automated rotation schedules: Define flexible rotation schedules tailored to your security and operational requirements. This eliminates manual effort and ensures consistent, frequent rotations.
On-demand rotation: Need to rotate a secret immediately due to a suspected breach or policy change? ESC allows you to trigger rotations on demand, giving you immediate control.
Seamless integration with ESC Environments: Rotated secrets are seamlessly integrated into your existing ESC environment definitions. This allows you to leverage the power of ESC’s composability, allowing you to manage rotated secrets alongside your other configuration values.
Two-secret strategy: ESC Rotated secrets uses a two-secret strategy in which two secrets are active and valid at any point in time. This is especially useful when multiple instances of an application share a credential but not all instances pull in the latest credential at the same time, allowing you to rotate a secret without worrying about some instances being unavailable due to invalid credentials.
Auditing and tracking: Gain complete visibility into credential usage, including a full history of generated credentials, active credentials, and the principals accessing them. This enhances governance and simplifies compliance.
Admin and creator control: Admins and creators/writers of rotated secrets can configure rotations using privileged user credentials and keep those credentials private while ensuring the consumers can still consume the resulting rotated secrets. This provides a clear separation of concern for administration and individual usage.
Configure webhooks for automation: Notify teams, trigger custom workflows, or trigger a Pulumi Deployment to update your IaC stacks whenever rotations occur, ensuring dependent teams and systems are updated on a timely basis

With today’s launch, we support AWS IAM user credential rotation with many more databases and cloud integrations on the way. Upvote on our GitHub issues to get support for new integrations.

How to Use ESC Rotated Secrets

Below are the steps to configure AWS IAM user rotated secrets using best practices. You can also configure this via Pulumi IaC. Check out the example program.

1. Provision an AWS IAM User on your AWS console

Create an AWS IAM user whose access keys you want to rotate.

2. Create a new environment with managing user credentials

In the example environment credentials/aws-creds below, we use the ESC’s aws-login provider using OIDC. This credential was configured with the privileged access to be able to rotate the IAM user credentials.

The minimal permissions the managing credential requires are IAM List, Create, and DeleteAccessKeys over the IAM user you created.

# credentials/aws-creds

values:
 aws:
 login:
 fn::open::aws-login:
 oidc:
 duration: 1h
 roleArn: arn:aws:iam::12345689:role/test-managing-role
 sessionName: pulumi-environments-session
 subjectAttributes:
 - currentEnvironment.name

3. Create a new environment with the IAM user rotation configuration

Define the rotation using rotated secrets aws-iam provider. Below is an example definition. Notice how the managing user credentials created in step 2 is referenced in the rotation provider input. This credential will only be used during rotation and never be exposed to the consumers of the rotated IAM user credential.

Providing current and previous credentials is optional. If you already have IAM user access keys that are actively used, you can specify them in the state field as current and previous. If not, you can leave the state empty.

values:
 rotated-creds:
 fn::rotate::aws-iam:
 inputs:
 region: us-west-1
 login: ${environments.credentials.aws-creds.aws.login}
 userArn: arn:aws:iam::{accountId}:user/{username}
 # state section below is optional.
 state:
 current:
 accessKeyId: AKIA...
 secretAccessKey:
 fn::secret: ASIA....
 previous:
 accessKeyId: AKIA...
 secretAccessKey:
 fn::secret: ASIA....

4. Test the setup with a manual rotation

In the Environment Editor screen, open the triple-dot menu and select Rotate Secrets. Alternatively, you can perform the rotation from the ‘secrets rotation’ tab or use the rotate CLI command. Every rotation creates a new revision.

If you did not provide current or precious credentials in step 3, rotation will generate new credentials automatically.

5. Monitor rotations

Perform multiple rotations to observe how access keys move from current → previous → deleted. Use the Environment Revision History to track changes.

6. Schedule rotations

Now that you’ve correctly configured your rotated secrets, set up an automated rotation schedule from the Secrets Rotation tab.

Rotated Secrets vs. Dynamic Credentials: Choosing the right tool

Pulumi ESC offers both Dynamic Secrets and Rotated Secrets. While both enhance security, they serve different purposes:

Dynamic secrets: These are short-lived, ephemeral credentials with a Time-To-Live (TTL) typically ranging from 1 to 8 hours. A new set of credentials is generated every time the environment is opened. This is ideal for minimizing the impact of compromised credentials, as they quickly become invalid.
Rotated secrets: These are longer-lived credentials, potentially lasting for days, weeks, or even months. The same latest credential is returned every time the environment is opened until the next scheduled rotation occurs. This provides stability and predictability for applications that need consistent credentials over a longer period.

Here are scenarios where rotated secrets are the preferred choice:

Legacy applications: Many legacy applications were built before modern secret management practices existed and cannot easily be rewritten to support dynamic secrets. For these applications, Rotated Secrets offer a practical way to enhance security without requiring a full application redesign or re-architecture.
Applications that can only update credentials during restarts and redeployments: Some applications require credentials to be available at startup and cannot refresh them dynamically. Rotated Secrets works well for this scenario, providing rotations and ensuring applications always have a valid credential when restarted.
Applications requiring persistent connections: High-performance applications or applications that have a long-lived database connections cannot afford to fetch fresh credentials every few hours. Rotated Secrets ensure such applications continue to function as needed while boosting security.
Third-Party API keys (Support coming soon): Some external services cannot provision dynamic short-term credentials. Rotated Secrets provide a way to comply with periodic key rotation policies without requiring real-time credential generation.
Databases in private networks (Support coming soon): Many Enterprise databases are not connected to the internet, thereby requiring a proxy or an agent running in their internal network to perform the rotation. Rotated Secrets offer stability in such environments by reducing the number of external calls, even when routed through a proxy.

What’s next?

This is just the beginning! We’re committed to expanding the capabilities of Rotated Secrets. Here’s a glimpse of what’s on the roadmap:

Database Secrets Rotation: Automated secrets rotation support for a wide range of databases including PostgreSQL, Snowflake, MySQL, and more!
Secret rotations for databases running in private networks
3rd party API key rotation (example: Twilio)
Other cloud provider support: Azure, GCP

Upvote integrations here. Want an integration not mentioned? Click here to raise a request.

Conclusion

Pulumi ESC’s Rotated Secrets feature represents a significant advancement in modern secrets management. By automating a traditionally manual and error-prone process, ESC reduces operational risks, strengthens your security posture, and helps you achieve compliance – all without slowing down development.

We encourage you to explore the docs and try out Rotated Secrets. Share any feedback or open new issues in our GitHub repository. We’re excited to see how you use this powerful new feature to build more secure and resilient applications!

Pulumi ESC: Discovering Environment Imports

Sean Yeh — Fri, 13 Dec 2024 00:00:00 -0700

Managing secrets and configuration across multiple environments and stacks can easily become complex, leading to duplicated values, inconsistencies, and security risks. Pulumi ESC solves this with composable environments via imports, allowing you to define configuration once and reuse it organization-wide. Now, with the new capabilities to discover environment imports, you gain unprecedented visibility and control, simplifying the management of even the most complex infrastructure and applications.

Understanding Pulumi ESC Imports

Pulumi ESC lets you define secrets and configuration as code collections called environments. These environments can import other environments, creating a hierarchical structure that promotes reusability, and reduces duplication and sprawl. You can centralize secrets and configuration within ESC and use them across Pulumi IaC Stacks, Pulumi Insights Accounts, and various other platforms through our integrations.

By using version tags, imports can target specific versions of an environment. This locks down the configuration used by dependents, ensuring stability and preventing unintended changes from rolling out to your critical environments.

What’s New?

We’ve added powerful discoverability features to give you clear insight into your environment dependencies:

New “Imported By” tab: Easily understand downstream dependencies by clicking the “Imported By” tab for each environment. This tab shows all environments and stacks that import a specific environment, including the specific tagged version used. Filter and sort by imported versions and downstream resources to narrow in on the resources that will be affected by a change you are trying to make.
Warnings for deletions and tag movements: Pulumi ESC now warns you about the potential impact of deleting an environment or modifying version tags before you make the change, helping you avoid disruptions.
Enhanced environment page: The Environments page now clearly indicates if an environment is used by other environments, stacks, or insights accounts, providing valuable relationship context at a glance.
Pulumi IaC stack visibility: Environment import information is also available on the Stacks page and within individual stack overview pages.

Conclusion

Pulumi ESC’s import feature is a paradigm shift in how you manage your secrets and configuration. The new suite of import discoverability features gives you the confidence to manage complex deployments with ease. Explore the new features and share your feedback through our Community Slack or GitHub Repo.

Unveiling the New Stacks Page

Germán Lena — Thu, 24 Oct 2024 00:00:00 -0700

We’re thrilled to unveil the redesigned Pulumi Infrastructure as Code (IaC) Stacks page within Pulumi Cloud console, addressing one of the most upvoted issues in our Pulumi Cloud Requests repository! This revamped experience delivers a significant boost in performance and usability, empowering even the most complex organizations to manage their infrastructure with ease.

Why a New Stacks Page?

As our customers scaled, the previous Stacks page faced some limitations that impacted its effectiveness. Here were some of the primary challenges:

Performance Issues: The page became sluggish with large numbers of stacks, making it difficult to scroll smoothly when you had thousands of stacks.
Limited Grouping and Sorting Options: Users had limited customization options for organizing their stacks, with minimal control over grouping and sorting.
Tag-Based Grouping Limitations: Grouping by tags wasn’t as reliable as we wanted—it sometimes failed to load completely.

What’s New?

The new Stacks page provides more information at a glance, offering a streamlined and powerful experience:

Effortless Scalability: Manage thousands of stacks with ease. The new page is optimized for performance, ensuring smooth scrolling and interaction regardless of scale.
Flexible Grouping: Group your stacks by repository, project, and tags simultaneously—up to three levels of grouping. Or opt for no grouping at all! The choice is yours. Expand and collapse groups as needed for a more organized and focused browsing experience.
Enhanced Sorting: Sort your stacks by last update or group name (ascending/descending) to quickly find what you need.
Shareable Views: The page now includes query parameters in the URL, allowing you to save and share your exact view with team members effortlessly.
Personalized Experience: The page remembers your last selected groups and sorting preferences, so you can pick up right where you left off.
Dynamic Loading: Enjoy instantaneous loading as you scroll, eliminating wait times and boosting efficiency.
Time-Saving Shortcuts: Use quick option to make group and sort selections or to reset them.

Classic View: Still Available

For users who prefer the familiar grouping by repository and project, and sorting by last updated, we’ve got you covered! Simply click the “Classic View” shortcut in the top right-corner to switch to the classic grouping and sorting option instantaneously.

Your Feedback Matters

We’re excited for you to experience the power and flexibility of the new Pulumi Stacks page! Share your feedback and suggestions through our Pulumi Cloud requests GitHub repository—we’re always listening and striving to improve.

Announcing the General Availability of Pulumi ESC - Welcome to a New Era of Secrets Management

Arun Loganathan — Wed, 18 Sep 2024 08:59:00 +0000

At Pulumi, we’ve been at the forefront of revolutionizing infrastructure management and DevOps processes. We’ve built the industry’s most comprehensive secrets management solution for IaC, securing production cloud credentials and secrets for countless organizations. Now, we’re taking that expertise and applying it to the broader challenges of managing secrets at scale with an open ecosystem approach.

Pulumi Environments, Secrets, and Configuration (Pulumi ESC), launched in preview in October 2023, is now generally available.

This next-generation secrets management and orchestration service is built with a robust software engineering approach, designed to bring security and simplicity to even the most complex secrets management needs.

Challenges in Secrets Management

In today’s cloud-native world, secrets are the keys to the cloud estate, but managing them effectively is a growing challenge. Modern applications rely on a complex web of secrets, but traditional approaches to secrets management are struggling to keep pace. This complexity creates major challenges for security and engineering teams:

Secrets Sprawl: Secrets scattered across numerous systems and platforms make it nearly impossible to track their usage, enforce consistent security policies, and prevent unauthorized access, significantly increasing the likelihood of a breach.
Long-Lived Credentials: Storing long-lived credentials, especially locally, creates a significant security liability. If these credentials are compromised, they can grant attackers prolonged access to sensitive systems.
The Trade-off Between Speed and Security: Many security measures designed to safeguard secrets can inadvertently impede development velocity. Complex storage and retrieval processes create unnecessary friction, leading to frustration and delays.
Insecure .env File Sharing: Developers often copy/paste secrets across many different files, including formats like .env files stored locally on their machine or shared through insecure channels (like Slack), creating blind spots for security teams and increasing the risk of data leaks.

Introducing Pulumi ESC: A Modern Approach to Environments, Secrets, and Configuration

Pulumi ESC is the modern secret management platform designed to streamline and secure how you manage environments, secrets, and configuration across your entire organization. Built with flexibility and security at its core, Pulumi ESC empowers you to:

Centralize and Simplify Secrets Management:

Unify Your Secrets: Say goodbye to secrets scattered across systems. Pulumi ESC lets you pull and synchronize secrets from any source—HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, 1Password, and more—and consume them securely from anywhere.
Streamline Access and Control: Access secrets seamlessly via CLI, API, Kubernetes operator, the intuitive Pulumi Cloud UI, or directly within your code using our TypeScript, Python, and Go SDKs. Robust RBAC ensures the right people have the right access at all times.
Eliminate .env File Risks: Stop sharing secrets through insecure channels. Pulumi ESC provides a secure and centralized way to manage and access secrets, eliminating the need for risky .env files.

Boost Developer Velocity and Security:

Empower Developers, Not Slow Them Down: Pulumi ESC is designed for developer convenience without compromising security. Access secrets programmatically, integrate with your existing workflows, and leverage flexible authoring options: Pulumi Cloud Editor, VS Code Plugin, SDKs, the Pulumi Service Provider, and our REST API - the choice is yours!
Gain Complete Visibility and Control: Track all secret access and changes with detailed audit logs. Understand the downstream impact of changes and ensure your secrets are used securely and consistently across your organization.
Secrets as Code: Pulumi ESC supports flexible composition of environments by allowing imports between one another. Construct hierarchical environments that avoid the need to copy/paste secrets and configurations, ensuring that changes are consistently propagated across all related environments.

Built for the Modern Cloud, Open by Design:

Use It Your Way: Pulumi ESC integrates seamlessly with other Pulumi products and features such as Pulumi IaC and Pulumi Deployments for a unified infrastructure management experience. But its flexibility extends to any platform or toolset, including HashiCorp Terraform.
Embrace the Open Ecosystem: We believe in freedom of choice. That’s why Pulumi ESC is built on an open-source foundation (Apache 2.0 license) and designed to retrieve and synchronize secrets with various platforms seamlessly. We empower our customers to choose the best tools for their needs and supercharge their workflows with Pulumi ESC.

Customer Stories

Since launch, we’ve seen an exponential increase in our customers using Pulumi ESC. Our users have reduced the duplication of their configuration and secrets by over 90% and made Pulumi ESC a core part of running and managing their mission-critical infrastructure and applications.

Hear from our customers directly what they had to say about Pulumi ESC:

“With Pulumi ESC, our developers get dynamic AWS and Azure credentials on-demand, that removes the need for long-lived tokens and enhances security. Onboarding new developers is quick and secure, with no more manually filling in .env templates, since a common ESC dev environment with RBAC is all we need. The integration with the Pulumi SDKs is a huge productivity boost, and allows us to integrate secrets seamlessly across all of our development workflows." states Liam White, Platform Lead at Tetrate.”
“Pulumi ESC has been a lifesaver for us”; said JK Jensen, Team Lead at Mysten Labs, “it’s nice to throw everything behind an ESC environment and eliminate one-off granting IAM permissions and other issues related to static credentials. It gives us peace of mind knowing that we can grant permissions quickly and revoke easily, limiting the blast radius for any access.”

“With Pulumi ESC, our developers get dynamic AWS/GCP credentials on-demand; that removes the need for long-lived tokens and enhances security. ESC allows for Pulumi programs to share secure credentials and access secrets in their given cloud environments. ESC is a great configuration ‘/and secrets management sharing tool to allow for a DRY (Don’t Repeat Yourself) approach to development,” says Richard Genthner, Lead DevOps Engineer at Boost Insurance.

Watch the snippet from our PulumiUP Keynote that walks you through how to achieve all these benefits our customers have experienced. Sign-up here to watch the full keynote.

Beyond Preview: The Evolution of Pulumi ESC

Since the launch of Pulumi ESC in preview, over the last 11 months, we have launched numerous features and enhancements driven by our customers. Some of the major ones include:

SDKs for TypeScript, Python, and Go to leverage Pulumi ESC within all your applications
Versioning that maintains full history of the changes you have made to your secrets and configuration and rollback to specific versions when needed
Version Tags allow you to assign tags and import specific versions by tags within your applications such that moving tags across versions changes the configuration but requires zero changes in your application code
Syncing your secrets to several external sources including GitHub and AWS SecretsManager
Kubernetes secrets operator to use Pulumi ESC within your Kubernetes applications to retrieve secrets and configuration using external secrets operator during runtime
VS Code Extension to author and view your environments directly from where you code
Webhooks to trigger your automated CI/CD workflows, restart applications with the latest secrets and configuration, notify your teams
Pulumi OIDC Trust relationship to get Pulumi short-term credentials using your existing Identity provider
Projects and Environment Tags to help you organize your Pulumi ESC environments and allow them to scale as your organization evolves
1Password integration to pull secrets stored in 1Password during runtime
In-built Document Editor Enhancements to ease authoring with Pulumi Cloud
Table Editor to support users who prefer point-and-click UI-driven method to secrets management
Pulumi Stack reference provider offering tighter integration with Pulumi IaC
Files support that allows getting Kubernetes credentials dynamically
Audit logs to monitor your environments

Pricing

Starting October 1st, 2024, Pulumi ESC will be billed per secret. We have heard from customers that this is a familiar pricing dimension that aligns to the value customers get out of ESC. To help you get started, we have included a generous free tier of secrets and API calls.

	Free	Team	Enterprise	Business Critical
Price per secret/month	25 free	$0.50	$0.75 / Custom	Custom
Price per plaintext config	Free	Free	Free	Free
Price per 10K API calls	10K free	$0.10	$0.10	$0.10
Commitment discounts			✔	✔

Check out our pricing page for more information about the various packages available. Contact us if you are interested in a demo, have any questions, or would like to discuss volume discounts.

Conclusion

Pulumi ESC represents a significant advancement in secrets and config management. By addressing the challenges faced by organizations today, such as secrets sprawl and the trade-off between speed and security, Pulumi ESC offers a modern, flexible solution. Its unique features, including support for dynamic, short-lived credentials and seamless integration with major cloud providers, GitHub, etc. make it an invaluable asset for teams looking to maintain agility without compromising on security. Pulumi ESC is set to redefine the standards of secrets management, enabling organizations to achieve their security and operational goals more effectively.

We can’t wait to see how you leverage Pulumi ESC. Sign-up for Pulumi Cloud to start using Pulumi ESC and check out our getting started guide to learn more about Pulumi ESC.

Introducing Webhooks for Pulumi ESC

Iaroslav Titov — Fri, 13 Sep 2024 00:00:00 -0300

Managing secrets and configurations across multiple environments and teams can be a complex juggling act for development teams. Pulumi ESC, our developer-friendly secrets management product, simplifies this process and accelerates your development cycle. Today, we’re excited to make this process even easier with the launch of Webhooks for Pulumi ESC, a powerful new feature that allows you to send a custom trigger to any URL endpoint, enabling you to automate workflows and keep your infrastructure and applications up to date. Pulumi ESC Webhooks also integrates seamlessly with popular communication platforms like Slack and Microsoft Teams.

With Pulumi ESC Webhooks, you can now receive real-time notifications and trigger automated actions based on specific events within your Pulumi ESC Environments. For example, you can set up a Webhook to notify your team’s Slack channel or automatically trigger a deployment pipeline via a POST request when a new environment revision is created due to changes in secrets and configuration. Webhooks can be triggered by changes to version tags and environment tags, and can be configured per environment or at the organization level for all environments.

Take your automation further by creating Webhooks that trigger Pulumi Deployments, automatically updating your infrastructure in response to configuration changes in Pulumi ESC—without writing custom code and all within the Pulumi Cloud Console.

Hierarchical configurations where one environment imports others are fundamental to Pulumi ESC. If an environment is importing another environment, any changes made to the imported environment trigger a Webhook configured within the current environment. The Webhook will notify you that the environment has changed, and you can call back to open the environment using SDK, REST API, Pulumi Service Provider, and Automation API, and get the latest secrets and configuration.

Getting Started with Pulumi ESC Webhooks

Setting up Webhooks is straightforward. You can use the Pulumi Cloud Console, the Pulumi Service Provider, or REST API.

Using Pulumi Cloud Console

Navigate to the “Webhooks” tab under settings for organization-wide Webhooks or within an individual environment’s top navigation bar.
Select your desired integration (Slack, Microsoft Teams, Pulumi Deployments, or generic JSON Webhooks).
Configure the Webhook details, including the events you want to trigger notifications on.

Using Pulumi Service Provider

Here is a sample code in TypeScript:

const environmentWebhook = new service.Webhook("env-webhook", {
 active: true,
 displayName: "env-webhook",
 organizationName: "my-org",
 projectName: environment.project,
 environmentName: environment.name,
 payloadUrl: "https://example.com",
 filters: [WebhookFilters.EnvironmentRevisionCreated, WebhookFilters.ImportedEnvironmentChanged],
})

Benefits of Pulumi ESC Webhooks

Pulumi ESC Webhooks offer a range of benefits designed to enhance visibility, streamline workflows, and automate key processes related to your secrets and configuration management:

Effortless Automation and Streamlined Workflows: Automatically trigger actions based on ESC events such as application restarts, infrastructure deployments, or configuration updates. Easily integrate Pulumi ESC Webhooks into your CI/CD pipelines to automate builds, tests, and deployments whenever environment updates occur.
Seamless Integration with Pulumi Deployments: Whether you need to update your infrastructure, preview changes, or create temporary infrastructure with TTL or review stacks, Pulumi ESC Webhooks handles all these scenarios, making deployments faster and easier.
Real-time Awareness and Collaboration: Receive instant notifications about critical changes in your Pulumi ESC environments, fostering better communication and collaboration between developers, operations teams, and security personnel. This real-time awareness enables faster incident response times, minimizing downtime and security risks.

Conclusion

Webhooks for Pulumi ESC equip your team with tools to improve visibility, streamline workflows, and automate key processes related to your secrets and configuration management. By integrating seamlessly with your existing communication and development tools, Pulumi ESC Webhooks empower you to automate and streamline your infrastructure management, giving you greater control and agility.

Dive into our documentation and explore the possibilities of Pulumi ESC Webhooks! As always, share any feedback or open new issues in our GitHub repository.

Introducing Pulumi ESC Projects and Environment Tags

Derek Schaller — Thu, 12 Sep 2024 13:00:00 -0400

We’re thrilled to unveil two new features that will empower you to organize your collection of Pulumi ESC Environments: Projects and Environment Tags. Projects offer a structured way to group related environments and Environment Tags allow you to add contextual information to each environment. Together, they offer a powerful way for you to manage, navigate, and collaborate on your secrets and configurations.

Overview of Pulumi ESC

Pulumi ESC is a developer-first platform designed to simplify the management of secrets and configurations into collections called environments. As a fully managed solution, it offers dynamic cloud provider credential resolution, a rich set of providers to retrieve secrets from external platforms, and the ability to use the secrets and configurations you have defined across any surface, including your applications and infrastructure via Multi-language SDKs, REST APIs, CLI, Pulumi-Service Provider, and Automation API. Like all Pulumi functionality, Pulumi ESC focuses on enhancing both agility and security in modern cloud development.

As developers have embraced Pulumi ESC to manage their collections of secrets and configurations across many teams and projects, the demand for more sophisticated organizational tools has increased. To address this growing need for more organized and efficient management of cloud environments, we are introducing Projects and Environment Tags in Pulumi ESC.

Introducing Projects

Projects offer a structured way to organize environments into logical groupings. Each Project has a distinct name, providing context for the environments within it, and can contain multiple environments with variations, each having a specific purpose. Additionally, Projects help large organizations simplify environment management by mitigating possible environment name conflicts and ensuring changes are made in isolation to the correct environments.

For example, your organization could have a project named “payments-app” containing dev, staging, and prod environments within it. Your organization could also have a project called “dev-credentials” which contains different environments used to provide temporary runtime access to credentials for developers while working.

We have two additional features as part of this launch:

Grouping and Search: You can group environments by either Project name or by Environment Tags, as well as search by them, making it simple to locate and manage your environments.
Environment Clone: Using the built-in cloning functionality, you can securely copy environments with sensitive information, preserving either the entire version history or just the latest environment state, depending on your needs.

To use Projects and Environment Tags, please update your Pulumi CLI and SDK to the latest.

Environments will now need to be referenced by specifying the project as part of the environment identifier. Any existing environments within your organization will be available in the default project. Projects are fully backward compatible - all your existing programs, imports and CLI commands will work without requiring any changes at the moment. Note that only environments within the default project will be backwards compatibly and resolve without a project prefix.

Users will be able to create new environments in the default project until Nov 30, 2024. Starting Dec 1, 2024, users will not be able to create new environments in the default project.

Starting Apr 1, 2025, users will not be able to edit their environments within the ‘default’ Project. We recommend customers migrate their existing environments to user-created projects at the earliest to take advantage of new Pulumi ESC capabilities.

Moving environments out of the default project is as easy as cloning the environment into a new project and updating any references to it. An example clone command that preserves all environment history, tags, and team access looks as follows

 $ pulumi env clone default/dev your-project/dev --preserve-history --preserve-env-tags --preserve-rev-tags --preserve-access

We offer numerous ways for you to get started with Projects via the Pulumi Web Console, SDK, REST API, CLI and Pulumi-Service Provider - choose what best fits your workflow. Here is one example using the Pulumi CLI to create and list environments within a project:

 $ pulumi env init cloud-pe/demo
 Environment created: dschaller/cloud-pe/demo

 $ pulumi env ls -p cloud-pe
 cloud-pe/demo
 pulumi/cloud-pe/demo

Breaking Changes

With the introduction of Projects, all existing environments part of the default project will continue to work without requiring any changes. However, when moving existing environments out of the default project you may notice some differences that we have outlined below.

If your environment was interpolating the context.currentEnvironment.name or context.rootEnvironment.name from Contextual information, this value will now include the project for any environments outside of the default project.
If you were using any of the secrets providers with OIDC, you will need to update both the subject and audience if a trust relationship has been set up. The subject will be either pulumi:environments:org:<organization name>:env:<project name>/<environment name> if no subjectAttributes are specified or if the currentEnvironment.name subject attribute is specified it will now resolve to currentEnvironment.name:<project name>/<environment name>. The audience will be the provider’s platform name (aws, azure, or gcp) followed by the org name of the environment (e.g. aws:pulumi).

Introducing Environment Tags

Using Environment Tags, teams can now assign any number of custom tags to each environment within Pulumi ESC. These tags serve as contextual identifiers that can streamline workflows by enabling you to group and search across environments based on specific criteria such as teams, project stages, deployment environments, compliance requirements, or geographic locations. This multi-dimensional approach provides unparalleled flexibility and control, ensuring your Pulumi ESC environments can scale seamlessly with your organizations evolving needs.

For example, suppose your organization has multiple environments across different geographic regions. You can use Environment Tags like ‘region: us-east’ or ‘region: eu-central-1’ to quickly filter environments by region. Similarly, for security audits, you might tag environments with ‘Compliance: SOC2’ or ‘Compliance: GDPR’ to easily find relevant environments and ensure they are compliant.

You can use the Pulumi Web Console and the CLI to create and manage Environment Tags. Here is an example of using the CLI to add and list Environment Tags.

$ pulumi env tag cloud-pe/demo region us-east-1
Name: region
Value: us-east-1
Last updated at 2024-09-10 11:03:05.708 -0700 PDT by Derek <dschaller>

$ pulumi env tag ls cloud-pe/demo
Name: region
Value: us-east-1
Last updated at 2024-09-10 11:03:05.708 -0700 PDT by Derek <dschaller>

Conclusion

Pulumi ESC Projects and Environment Tags are powerful additions that bring order and clarity to your secrets and configuration to even the most complex infrastructure landscapes. By enabling you to organize, group, and search for your environments with ease, we’re empowering you to scale your infrastructure with high confidence and flexibility.

We’re excited to see how you leverage these new capabilities. Check out the docs to learn more about Pulumi ESC Projects and Environment Tags and start organizing your environments today!

As always, please share your feedback on how we can further improve Pulumi ESC to suit your needs.

Pulumi ESC Table Editor Now Supports Dynamic Credential and Secret Integrations

Kimberley Mackenzie — Tue, 10 Sep 2024 00:00:00 -0700

We are pleased to announce a major update to the Pulumi ESC’s Table Editor: full support for provider configurations is now live! When we first introduced the ESC Table view, our goal was to offer a user-friendly interface for managing complex configuration and secrets for your applications and infrastructure. This has empowered teams to focus on what they do best—building and deploying software.

In our initial launch, the Table Editor allowed you to perform CRUD operations on your secrets and plaintext values, decrypt secrets, import environments, and manage variables—all within a visual interface. Today, we’re taking the next step by enabling full read-write support for provider configurations within the Table Editor. This new capability allows you to add, edit, and manage your provider configurations directly from the table view, offering a more integrated and seamless experience.

Primer on ESC Provider Configuration

Pulumi ESC’s provider ecosystem is one of its most powerful features. It supports two categories of providers:

Dynamic Cloud Provider Credentials: Dynamically acquire credentials from cloud providers like AWS, Azure, GCP, and Vault at runtime, eliminating the need for static, long-lived credentials. This enhances security by removing the reliance on dotenv files, locally stored secrets, or long-lived credentials in CI/CD environments, strengthening your workflows’ overall security.
Dynamic Secret Retrieval: ESC retrieves secrets from external secrets managers, such as AWS Secrets Manager, 1Password, and HashiCorp Vault, securely pulling them directly into your environments. Whether you are migrating or utilizing Pulumi ESC’s rich toolset, you can retrieve sensitive information at runtime and apply it seamlessly to your applications.

Enhancing the Table Editor: Provider Configuration Support

With the addition of provider configuration support in the Table view, incorporating Pulumi ESC provider capabilities into your workflow is now more straightforward. A clean, user-friendly form provides step-by-step guidance, promoting best practices like OIDC adoption and the secure handling of sensitive data. This streamlined approach reduces the need for external documentation, making the entire process more intuitive and efficient.

Conclusion

The new provider configuration support in the ESC Table view marks another step in our efforts to simplify and enhance the developer experience. We’re eager to see how you’ll leverage this new capability to streamline your workflows and strengthen your infrastructure’s security. As always, your feedback is invaluable to our development process, and we’re committed to continually improving the Table Editor and other Pulumi tools based on your needs. Please share your feedback with us here.

Check out our documentation to learn more about Pulumi ESC.

Pulumi Release Notes: Pulumi Copilot, Pulumi ESC Versioning, Pulumi ESC SDK, Docker Provider, and more!

Arun Loganathan — Mon, 24 Jun 2024 11:06:04 -0800

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

What an incredible two months at Pulumi! From the revolutionary AI-powered Pulumi Copilot to robust infrastructure lifecycle management, enhanced Pulumi ESC with versioning and SDKs, and a brand-new Docker Build provider, this release cycle is packed with high-impact features delivered at an unprecedented pace. Ready to see all the details? We’ve got a lot to cover, so let’s jump right into the highlights of this action-packed release.

AI
- Pulumi Copilot: The Future of Cloud Infrastructure
Pulumi Cloud
Core
- Continue On Error in the Pulumi CLI
- Run Pulumi with Any TypeScript Version
Providers and Packages
Wrap up

AI

Pulumi Copilot: The Future of Cloud Infrastructure

Pulumi Copilot is a game-changing conversational AI assistant for Pulumi Cloud, leveraging large language models (LLMs) to simplify and enhance your cloud management experience. Get instant answers about your cloud by querying the state of any resource managed by Pulumi, across all your clouds and accounts. Explore historical data on stacks, projects, deployments, and more, gaining deep insights into your infrastructure. Write and deploy IaC with ease as Pulumi Copilot brings the power of Pulumi AI directly to your fingertips. Gain insights from cloud provider metadata as Pulumi Copilot integrates with AWS, Azure, Kubernetes, and more; to provide real-time insights into usage, costs, and your infrastructure.

Pulumi Copilot enforces the same strict identity and RBAC rules as Pulumi Cloud, ensuring data security and privacy for your organization. Try Pulumi Copilot for free! It’s in public beta and available to all Pulumi Cloud organizations. Enable it in your organization settings: Settings > Access Management > Pulumi Copilot. Read the blog post | Explore the docs

Pulumi Cloud

New Infrastructure Lifecycle Management Features

We introduced a wave of new Infrastructure Lifecycle Management capabilities in Pulumi Cloud, building upon the power of Pulumi Deployments, and directly addressing the needs of our customers for robust Day 2 operations and beyond. These new features—Drift Detection and Remediation, Time-to-Live Stacks, and Scheduled Deployments—enhance security, optimize costs, and automate key infrastructure management tasks. We also announced a new Pulumi Deployments Free Tier for all users, providing 3,000 free deployment minutes every month to easily test and use these new features.

Drift Detection and Remediation

Uncontrolled configuration drift can wreak havoc on your cloud environments, leading to security vulnerabilities, compliance violations, costly outages, and wasted resources. Pulumi Cloud’s new Drift Detection and Remediation feature empowers platform teams to maintain complete control over their cloud infrastructure. This feature periodically compares the actual state of cloud resources with the desired state defined in Pulumi programs, identifying any discrepancies. Automatically detect any deviation from your desired state, whether caused by manual edits or external scripts, and receive timely alerts through integrations like Slack and Microsoft Teams. Pulumi Deployments users can enable automatic remediation to correct drift and ensure their infrastructure remains consistent with their code. You can manage Drift Detection and Remediation through the Pulumi Cloud console, the Pulumi CLI, the REST API, or the Pulumi Service Provider. Check out our detailed post.

Time-to-Live Stacks

Creating temporary environments is crucial for running experiments, testing new features, and ensuring that everything works smoothly before going live. However, these environments are often forgotten and left running, consuming resources and adding unnecessary costs. Manually managing these temporary stacks is time-consuming, operationally burdensome, and prone to errors. Pulumi’s Time-to-Live Stacks feature solves this by allowing teams to set a predefined lifespan on any stack. After the specified time, the stack is automatically destroyed, preventing cost overruns and reducing security risks from idle resources. This automated cleanup process ensures cost control, enhances developer enablement, and improves security. Time-to-Live Stacks can be easily managed through the Pulumi Cloud console, REST API, or the Pulumi Service Provider. See our launch blog post.

Scheduled Deployments

We also rolled out Scheduled Deployments, extending the automation capabilities of Drift Detection and Remediation and Time-to-Live Stacks. Scheduled Deployments enable precise automation of cloud operations, allowing users to schedule any Pulumi operation—such as pulumi up, pulumi refresh, pulumi destroy, or pulumi preview—for any stack with Pulumi Deployments. This provides greater flexibility for managing your cloud operations, whether it’s scheduling off-peak deployments, optimizing resource costs, or automating routine infrastructure updates. You can easily set up and manage Scheduled Deployments through the Pulumi Cloud console, REST API, or directly within your code using the Pulumi Service Provider.

Pulumi ESC: New Features to Supercharge Your Secrets and Config Management

We unleashed a wave of powerful new features for Pulumi Environments, Secrets, and Configuration (ESC), taking secrets and configuration management to the next level. Read the blog post to learn more about these enhancements that bring best-in-class software engineering practices to your fingertips, enabling you to manage secrets and configuration complexity at scale across all your cloud applications and infrastructure.

Pulumi ESC Versioning

Pulumi ESC Versioning gives you unprecedented control over your secrets and configuration. Every change is captured in an immutable revision history, allowing you to audit modifications, compare versions, and safely roll back. Assign meaningful tags to revisions (e.g., production, v1.2.1, stable) for easy management, just like Docker tags. When importing an environment, pin it to a specific version using tags or a revision number to prevent automatic propagation of changes from the source. This enables phased rollouts and thorough testing before deploying new configurations. You can also reference specific versions with the pulumi env run command, targeting different environments for different tasks. This granular control minimizes risks, enhances collaboration, and streamlines workflows. Access versioning features through the Pulumi Cloud Console, the Pulumi CLI, or the ESC REST API.

Pulumi ESC SDK

Pulumi ESC SDKs are now available for Python, TypeScript/JavaScript, and Go, making it easier than ever to harness the power of ESC directly within your applications using your favorite programming languages. The SDKs provide a simple and intuitive programmatic interface to manage your ESC environments, securely access secrets and configurations at runtime, and eliminate the need for hardcoded credentials. This streamlines your development process, enhances security, and promotes best practices for handling sensitive data. Check out our docs.

Pulumi Service Provider for ESC

You can now manage your Pulumi ESC Environments using the powerful Pulumi Service Provider. This means you can define environments, add version tags, and even control access using familiar Infrastructure as Code (IaC) practices, ensuring consistency and repeatability across your deployments. The Pulumi Service Provider empowers you to manage your entire infrastructure and application landscape through a unified approach.

Automation API Support for ESC

We’ve expanded the powerful Pulumi Automation API to include new methods for interacting with Pulumi ESC Environments programmatically. These new methods– addEnvironments(…), listEnvironments(), and removeEnvironment(environment) – enable you to seamlessly integrate environment management into your automated workflows and build sophisticated custom tooling. The Automation API provides the building blocks for advanced automation scenarios such as dynamically configuring applications based on environments, managing environment dependencies, and integrating ESC into CI/CD pipelines. Pulumi ESC Automation API capabilities are available for TypeScript/JavaScript, Go, and Python. Check out our blog post for examples.

Pulumi Cloud OIDC Trust Relationship

Pulumi Cloud now supports OpenID Connect (OIDC) Trust Relationships, allowing you to securely integrate Pulumi into any ecosystem that supports OIDC. This feature addresses the “secret zero” challenge by facilitating the exchange of secure platform tokens for short-lived Pulumi tokens, enhancing security and simplifying token management. You can configure trusted OIDC identity providers, such as GitHub, GitLab, or Google Cloud, and set granular policies to control token exchange based on issuer, subject, or additional claims. This integration extends to Kubernetes, enabling pods to authenticate to Pulumi Cloud using OIDC tokens issued by Google Kubernetes Engine GKE. To further streamline the integration with GitHub Actions, we introduced a new GitHub Action that automates the retrieval of Pulumi access tokens, making it even easier to leverage OIDC for secure authentication within your workflows. Check out our OIDC docs.

New Project Wizard Enhancements

We enhanced the New Project Wizard in Pulumi Cloud to streamline developer workflows and give platform teams more control over deployments. You can now configure the Developer Portal Gallery to exclusively display organization-specific templates, ensuring developers only use approved configurations. This simplifies template discovery and selection, reinforcing governance and compliance across development projects. We also streamlined project creation by introducing default repository locations and auto-generated project names, eliminating manual steps and potential naming conflicts. Read the New Project Wizard updates blog post for more details.

Core

Continue On Error in the Pulumi CLI

Pulumi now offers more control over error handling during deployments with the new --continue-on-error flag for pulumi up and pulumi destroy. When managing complex infrastructure with Pulumi, deployments can involve a large number of concurrent resource operations. Previously, if an error occurred during a deployment, Pulumi would stop all new operations to prevent potential cascading failures. While this approach is often desirable, there are cases where you might want to continue updating or destroying resources that are independent of the failed resource. The –continue-on-error flag enables this behavior, allowing deployments to proceed even in the presence of errors, while still respecting resource dependencies. This can be especially useful when destroying resources, as it allows you to clean up as much infrastructure as possible. Read the blog post for more details.

Run Pulumi with Any TypeScript Version

Previously, Pulumi’s seamless TypeScript experience was limited to version 3.8, requiring manual build steps for newer versions. But now, with the release of the Pulumi Node.js SDK 3.113.0, you can use any TypeScript version 3.8 or later, including the latest TypeScript 5.4, by simply adding it as a dependency in your project’s package.json file. Pulumi will automatically use the specified version for compilation, unlocking access to the newest TypeScript features and improved type checking. Read the blog post for a detailed example and instructions on upgrading your projects.

Providers and Packages

Next-Generation Docker Image Builds with Pulumi

Pulumi introduces the new Docker Build provider, a dedicated package designed to modernize and streamline Docker image builds directly from your Pulumi programs. The new provider exposes Docker’s next-generation buildx interface, unlocking advanced features such as multi-platform image support, advanced caching mechanisms, built-in support for build secrets, and seamless integration with Docker Build Cloud. This unlocks powerful scenarios, including building multi-architecture images and optimizing build performance with various cache backends. Read the blog post for detailed examples and migration guides.

Using Pulumi with Azure Deployment Environments

Pulumi now supports authoring Azure Deployment Environments (ADE) environment definitions, empowering developers to self-serve the application infrastructure they need while maintaining centralized management and governance. This integration allows you to leverage Pulumi’s familiar programming model and the full power of its Infrastructure as Code (IaC) platform to define and manage Azure resources within ADE environments. You can define ADE environments using a simple YAML configuration file that references a Pulumi program written in any of Pulumi’s supported languages, including C#, TypeScript, Python, Go, and YAML. Leveraging a dedicated Pulumi Docker image, ADE seamlessly executes the selected Pulumi program, provisioning the defined Azure resources. This streamlines the creation of new environments, enhances developer productivity, and ensures consistency and compliance with organizational standards. Read the blog post for a detailed walkthrough and examples.

Helm Chart v4 Resource

Pulumi introduces a new and improved Helm Chart v4 resource (kubernetes.helm.sh/v4.Chart) in the Pulumi Kubernetes provider, offering enhanced functionality, and a more streamlined experience for deploying Helm charts. A key improvement in v4 is expanded language support. Previous versions of the Chart resource were implemented separately for each Pulumi SDK, leading to inconsistencies and limited language compatibility. The new Chart v4 resource ensures consistent behavior and functionality across all Pulumi SDKs, including Python, TypeScript/JavaScript, Go, C#, Java, and YAML. Other notable enhancements include full OCI registry support, improved handling of chart values, better connectivity for cluster interactions, and improved resource ordering. Read the blog post for a detailed overview, examples, and migration guidance.

New Provider Resources

We have added 121 functions and 159 resources across our most popular providers, along with many more throughout our ecosystem. We also welcome our new community provider resource: Genesis cloud.

Wrap up

Phew, that’s a lot! We’ve packed this release with features to empower you to build and manage modern cloud infrastructure and applications with greater efficiency, control, and confidence. Explore all the new capabilities and share your feedback – we’re always listening! Open an issue in the Pulumi Cloud requests repository or the pulumi/pulumi repository for anything CLI-related. Stay tuned for more exciting updates!

Introducing Pulumi ESC Support in Automation API and the Pulumi Service Provider

Arun Loganathan — Wed, 05 Jun 2024 00:00:00 -0500

We’re excited to announce two powerful new capabilities for Pulumi Environments Secrets and Configurations (ESC) that supercharge how you manage and control your infrastructure and application secrets and configurations:

Pulumi Service Provider Support for ESC Environments: Manage your environments as code right alongside your infrastructure including fine-grained access control using Pulumi Service Provider.
Automation API Enhancements for ESC: Seamlessly integrate ESC Environments into your Automation API-based Pulumi projects.

These updates build upon Pulumi ESC’s commitment to simplify and streamline secrets and configuration management providing you with greater control, security, and automation capabilities.

Manage ESC Environments as Code with the Pulumi Service Provider

You can now manage your Pulumi ESC Environments directly within the Pulumi Service using the powerful Pulumi Service Provider. This means you can define environments, add version tags, and even control access using familiar Infrastructure as Code (IaC) practices ensuring consistency and repeatability across your deployments.

Here’s a glimpse of what you can achieve:

Programmatically create and manage ESC Environments: Define environments alongside your infrastructure code for a unified workflow.
Add version tags to environments: Add tags when you are creating the environment.
Enforce granular team permissions: Control who can read, open, or modify your environments ensuring secure collaboration and preventing unauthorized access.

Bringing Pulumi ESC Environments support into the Pulumi Service Provider empowers you to manage your entire infrastructure and application landscape through a unified approach.

Pulumi Service Provider ESC capabilities are available for TypeScript/JavaScript, Go, Python, C#, Java, and YAML. See our Environment, Environment Version Tag, and Environment Permissions Pulumi Service Provider docs. Here are examples of creating environments in TypeScript/JavaScript, Go, and Python:

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

var environment = new service.Environment("testing-environment", {
 organization: "service-provider-test-org",
 name: "testing-environment-ts",
 yaml: new pulumi.asset.StringAsset(
 `values:
 myKey1: "myValue1"
 myNestedKey:
 myKey2: "myValue2"
 myNumber: 1`
 )
})

import pulumi
from pulumi_pulumiservice import Environment

environment = Environment(
 "testing-environment",
 organization="service-provider-test-org",
 name="testing-environment-py",
 yaml=pulumi.StringAsset("""
 values:
 myKey1: "myValue1"
 myNestedKey:
 myKey2: "myValue2"
 myNumber: 1
 """)
)

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 {
 _, err := pulumiservice.NewEnvironment(ctx, "testing-environment", &pulumiservice.EnvironmentArgs{
 Name: pulumi.String("testing-environment-go"),
 Organization: pulumi.String("service-provider-test-org"),
 Yaml: pulumi.NewStringAsset(`
 values:
 myKey1: "myValue1"
 myNestedKey:
 myKey2: "myValue2"
 myNumber: 1`),
 })
 if err != nil {
 return err
 }
 return nil
 })
}

Streamline Automated Workflows with Automation API Enhancements

We’re expanding the powerful Pulumi Automation API to include new methods for interacting with Pulumi ESC Environments programmatically. This enables you to seamlessly integrate environment management into your automated workflows and build sophisticated custom tooling.

The new Automation API methods for ESC include:

addEnvironments(...): Append environments in order to your Pulumi stack’s import list.
listEnvironments(): Retrieve a list of environments currently imported into your stack.
removeEnvironment(environment): Remove a specific environment from your stack’s import list.

These additions provide the building blocks for advanced automation scenarios such as dynamically configuring applications based on environments, managing environment dependencies, and integrating ESC into CI/CD pipelines.

Pulumi ESC Automation API capabilities are available for TypeScript/JavaScript, Go, and Python. Here are some examples:

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

async function manageEnvironments() {
 const projectName = "myProject";
 const stackName = "dev";

 // Set up your stack options. Here we're using an empty program
 // since we're only manipulating environments, not deploying resources.
 const stackArgs: automation.InlineProgramArgs = {
 stackName,
 projectName,
 program: async () => { },
 };

 // Create or select an existing stack.
 const stack = await automation.LocalWorkspace.createOrSelectStack(stackArgs);

 // Add environments to your stack's configuration.
 // This is like adding them to the `imports` section of an ESC environment.
 await stack.addEnvironments("env1", "env2");
 // The stack's configuration now includes `env1` and `env2`.

 // List the environments currently configured for the stack.
 const environments = await stack.listEnvironments();
 console.log("Current environments:", environments); // Output: ["env1", "env2"]

 // Remove an environment from the stack's configuration.
 await stack.removeEnvironment("env1");
 // The stack's configuration now only includes `env2`.

 // List environments again to confirm the removal.
 const updatedEnvironments = await stack.listEnvironments();
 console.log("Updated environments:", updatedEnvironments); // Output: ["env2"]
}

// Call the async function to execute.
manageEnvironments().catch(console.error);

import pulumi
from pulumi.automation import LocalWorkspace, ProjectSettings, Stack

def manage_environments():
 stack_name = "dev"
 project_name = "myProject"

 # Define the project settings.
 project_settings = ProjectSettings(
 name=project_name,
 runtime="python",
 )

 # Create a LocalWorkspace with the project settings.
 workspace = LocalWorkspace(
 work_dir=".", # Use the current directory as the working directory
 project_settings=project_settings,
 )

 # Create or select an existing stack.
 stack = Stack.create(stack_name=stack_name, workspace=workspace)

 # Add environments to the stack's configuration.
 stack.add_environments("env1", "env2")

 # List the environments associated with the stack.
 environments = stack.list_environments()
 print("Current environments:", environments) # Output: ['env1', 'env2']

 # Remove an environment from the stack's configuration.
 stack.remove_environment("env1")

 # List the environments again to verify the removal.
 updated_environments = stack.list_environments()
 print("Updated environments:", updated_environments) # Output: ['env2']

# Run the function to manage environments.
manage_environments()

package main

import (
 "context"
 "fmt"
 "log"
 "github.com/pulumi/pulumi/sdk/v3/go/auto"
 "github.com/pulumi/pulumi/sdk/v3/go/common/tokens"
 "github.com/pulumi/pulumi/sdk/v3/go/common/workspace"
)

func main() {
 ctx := context.Background()
 projectName := "myProject"
 stackName := "dev"

 // Define the project configuration.
 project := workspace.Project{
 Name: tokens.PackageName(projectName),
 Runtime: workspace.NewProjectRuntimeInfo("go", nil),
 }

 // Create a workspace with the project configuration.
 // Here we're using an empty program since we're only manipulating environments, not deploying resources.
 ws, err := auto.NewLocalWorkspace(ctx, auto.Project(project), auto.Program(nil))
 if err != nil {
 log.Fatalf("Failed to create workspace: %v", err)
 }

 // Create or select an existing stack.
 stack, err := auto.UpsertStack(ctx, stackName, ws)
 if err != nil {
 log.Fatalf("Failed to create or select stack: %v", err)
 }

 // Add environments to the stack's configuration.
 // This is like adding them to the `imports` section of an ESC environment.
 err = stack.AddEnvironments(ctx, "env1", "env2")
 if err != nil {
 log.Fatalf("Failed to add environments: %v", err)
 }
 // The stack's configuration now includes `env1` and `env2`.

 // List the environments associated with the stack.
 envs, err := stack.ListEnvironments(ctx)
 if err != nil {
 log.Fatalf("Failed to list environments: %v", err)
 }
 fmt.Println("Current environments:", envs) // Output: map[env1:{env1} env2:{env2}]

 // Remove an environment from the stack's configuration.
 err = stack.RemoveEnvironment(ctx, "env1")
 if err != nil {
 log.Fatalf("Failed to remove environment: %v", err)
 }
 // The stack's configuration now only includes `env2`.

 // List the environments again to confirm the removal.
 envs, err = stack.ListEnvironments(ctx)
 if err != nil {
 log.Fatalf("Failed to list environments: %v", err)
 }
 fmt.Println("Updated environments:", envs) // Output: map[env2:{env2}]
}

What’s Coming in the Future

We have exciting plans to further enhance these capabilities. Here’s a sneak peek at what’s on the horizon:

Pulumi service Provider: Capabilities to Open, Read, and List any environment versions and version tags
Automation API: Capabilities to author new environments, and assign version tags

Need more features or want to share feedback? We encourage you to open new issues on our GitHub repository or upvote existing ones.

Get Started Today!

These powerful new features are available now! We’re excited to see how you leverage these updates to simplify your secrets and configuration management, enhance your security posture, and unlock new levels of automation.

To learn more and start leveraging the enhanced capabilities of Pulumi ESC check out the following resources:

Pulumi Service Provider for ESC Environment, Environment Version Tag, and Environment Permissions
Pulumi ESC Automation API in TypeScript/JavaScript, Go, and Python

Introducing Pulumi ESC SDK: Streamline Your Application Secrets Management

Arun Loganathan — Wed, 05 Jun 2024 00:00:00 -0400

Managing secrets and application configurations effectively is crucial for building secure and maintainable software. However, developers often face challenges such as hardcoded credentials, configuration inconsistencies, and security risks. Pulumi Environments Secrets and Configuration (ESC) simplifies the management of sensitive data and configuration across your entire application lifecycle. Today, we’re thrilled to introduce the official Pulumi ESC SDK in TypeScript/JavaScript, Go, and Python, making it even easier to integrate ESC directly into your applications.

Primer on Pulumi ESC

Pulumi ESC (Environments, Secrets, and Configuration) provides a developer-first solution to simplify how you manage sensitive data and configuration across your entire application lifecycle. It’s a fully managed solution allowing teams to generate dynamic cloud provider credentials, aggregate secrets and configuration from multiple sources, and manage them through composable collections called “environments.” These environments can be consumed from anywhere, making Pulumi ESC ideal for any application and development workflow. Additionally, while Pulumi ESC works independently to eliminate duplication and reduce drift and sprawl of secrets and configuration for all your applications, it also integrates smoothly with Pulumi Infrastructure as Code (IaC) to enhance these capabilities within the Pulumi ecosystem.

Introducing the Pulumi ESC SDK

We’re excited to unveil the official Pulumi ESC SDK, making it even easier to harness the power of ESC directly within your applications using your favorite programming languages. The SDK provides a simple programmatic interface to all of Pulumi ESC’s robust features, allowing you to:

Manage the Entire Lifecycle of Your Environments: Create new environments, list existing ones, and easily update or delete them as your needs evolve. You can even add version tags to your environments, making it simple to track changes and roll back to previous states if needed.
Seamlessly Integrate Secrets and Configurations: Securely access and utilize secrets and configurations within your applications, ensuring consistency of configuration across environments. The SDK provides a streamlined way to fetch the information you need, whether it’s dynamic cloud credentials, database connection strings, feature flags, or any other sensitive data.

The Pulumi ESC SDK streamlines secret and configuration management, promoting secure handling best practices. It handles the secure storage and retrieval of your sensitive data at runtime, eliminating the need to store credentials long-term and minimizing the risk of accidental exposure. The SDK is a natural extension of your development workflow, offering familiar objects and methods, smooth integration with your IDE, and the benefits of type safety such as compile-time checks and helpful code suggestions that reduce errors and accelerate development.

How to Get Started

Here are a few examples of how to use the ESC SDK for various languages:

import * as esc from "@pulumi/esc-sdk";

async function main() {
 const PULUMI_ACCESS_TOKEN = process.env.PULUMI_ACCESS_TOKEN!;
 const orgName = process.env.PULUMI_ORG!;
 const config = new esc.Configuration({ accessToken: PULUMI_ACCESS_TOKEN });
 const client = new esc.EscApi(config);

 const envName = "sdk-typescript-example";

 // Create a new environment
 await client.createEnvironment(orgName, envName);

 const envDef: esc.EnvironmentDefinition = {
 values: {
 my_secret: {
 "fn::secret": "shh! don't tell anyone",
 },
 },
 };

 // Update the environment with the new definition
 await client.updateEnvironment(orgName, envName, envDef);

 // Open and read the environment
 const openEnv = await client.openAndReadEnvironment(orgName, envName);

 if (!openEnv) {
 console.error("Failed to open and read the environment");
 return;
 }

 // Acces the value of the secret
 const secretValue = openEnv.values?.my_secret;
 console.log(`Secret value: ${secretValue}\n`);

 // List all the environments in the organization
 const orgEnvs = await client.listEnvironments(orgName);
 if (!orgEnvs || !orgEnvs.environments) {
 console.log("No environments found");
 return;
 }

 for (const env of orgEnvs.environments) {
 console.log(`Environment: ${env.name}`);
 }
}

(async ()=>{
 await main();
})();

import pulumi_esc_sdk as esc
import os

accessToken = os.getenv("PULUMI_ACCESS_TOKEN")

orgName = os.getenv("PULUMI_ORG")

configuration = esc.Configuration(access_token=accessToken)
client = esc.EscClient(configuration)

envName = "sdk-python-example"

# Create environment
client.create_environment(orgName, envName)

# create a new EnvironmentDefinition with "my_secret" as a secret in values additional_properties
envDef = esc.EnvironmentDefinition(
 imports=[],
 values=esc.EnvironmentDefinitionValues(
 additional_properties={
 "my_secret": {
 "fn::secret": "shh! don't tell anyone"
 }
 }
 )
)

# Update environment
client.update_environment(orgName, envName, envDef)

# Open and read the environment

env, values, yaml = client.open_and_read_environment(orgName, envName)

secret = values["my_secret"]
print(f'Secret: {secret}\n')

# List environments

environments = client.list_environments(orgName)

for env in environments.environments:
 print(f'Environment: {env.name}')

package main

import (
 "log"
 "os"

 esc "github.com/pulumi/esc-sdk/sdk/go"
)

func main() {
 accessToken := os.Getenv("PULUMI_ACCESS_TOKEN")
 orgName := os.Getenv("PULUMI_ORG")
 configuration := esc.NewConfiguration()
 escClient := esc.NewClient(configuration)
 authCtx := esc.NewAuthContext(accessToken)

 envName := "sdk-go-example"
 // Create Environment
 err := escClient.CreateEnvironment(authCtx, orgName, envName)
 if err != nil {
 log.Fatalf("Failed to create environment: %v", err)
 }

 // Update Environment with Secrets
 updatePayload := &esc.EnvironmentDefinition{
 Values: &esc.EnvironmentDefinitionValues{
 AdditionalProperties: map[string]interface{}{
 "my_secret": map[string]string{
 "fn::secret": "shh! don't tell anyone",
 },
 },
 },
 }

 _, err = escClient.UpdateEnvironment(authCtx, orgName, envName, updatePayload)
 if err != nil {
 log.Fatalf("Failed to update environment: %v", err)
 }

 // Open and View Secrets
 _, values, err := escClient.OpenAndReadEnvironment(authCtx, orgName, envName)
 if err != nil {
 log.Fatalf("Failed to open environment: %v", err)
 }

 mySecret, ok := values["my_secret"]
 if !ok {
 log.Fatalf("Secret 'my_secret' not found in environment %s", envName)
 }

 log.Printf("my_secret: %v\n", mySecret)

 orgEnvs, err := escClient.ListEnvironments(authCtx, orgName, nil)
 if err != nil {
 log.Fatalf("Failed to list environments: %v", err)
 }

 for _, orgEnv := range orgEnvs.Environments {
 log.Printf("Environment: %v\n", orgEnv.Name)
 }

}

Example Scenarios: Pulumi ESC SDK in Action

Here are some real-world scenarios showcasing how you can leverage the Pulumi ESC SDK:

Database Credentials: Applications can use the ESC SDK to fetch database credentials with a specified TTL, ensuring they always use valid credentials, even as the credentials are rotated in the background. This eliminates service interruptions due to expired credentials.
Secure Serverless Deployments: A Google Cloud Function requiring access to an AWS S3 bucket can leverage the ESC SDK to obtain temporary AWS credentials during runtime. This enables secure cross-cloud interactions without embedding long-lived AWS credentials directly within the function’s code.
Microservices Configuration: With ESC, development teams can manage diverse configurations for their microservices, including API endpoints, retry policies, and logging levels, specific to each environment (development, staging, production). The ESC SDK allows each microservice to retrieve the correct configuration values during runtime, simplifying environment-based customizations.

Get Started Today!

The Pulumi ESC SDK is available now! To learn more and start simplifying your application secrets workflow, check out the Pulumi ESC SDK Documentation. We’re confident that this powerful new tool will streamline your development process, enhance your application security, and empower you to build innovative solutions with confidence. Join us on this journey towards a more secure and manageable future for application secrets and configurations!

Unveiling Pulumi ESC Versioning: Manage Secrets and Deployments with Confidence

Arun Loganathan — Wed, 05 Jun 2024 00:00:00 -0300

Since the launch of Pulumi Environments, Secrets and Configuration (ESC), our developer-first configuration and secrets management platform, we’ve seen exponential growth in usage. Customers have used it to simplify their secrets and configuration management by organizing them into composable collections called ’environments’. Today, we are thrilled to introduce a comprehensive suite of versioning features, giving you unprecedented control and confidence in managing your environments.

Uncover the Key Features of Pulumi ESC Versioning

Pulumi ESC Versioning introduces a range of powerful features:

Immutable Revision History: Every time you save an environment, a new, immutable revision is created, preserving a complete and tamper-proof history of your changes.
Compare Revisions Side-by-Side: Gain a clear understanding of changes between revisions with our detailed side-by-side comparison view. This helps identify differences, troubleshoot issues, and ensure smooth transitions between versions.
Tag Revisions: Assign meaningful names to specific revisions, enabling you to easily manage and deploy different versions of your environments. You can use tags like production, v1.2.1, stable, pre-release, and in-development to clearly communicate the purpose or stage of each version. Each environment has a built-in latest tag that always points to the environment’s most recent revision.
Import Specific Versions: Precisely control which version of an environment is imported, either by specifying a tag (e.g., environmentA@prod) or using a specific revision number (e.g., environmentB@2). This method also applies when importing environments via Pulumi Stack Config or via other environments, to effectively ‘pin’ the desired version.
Rollback to a Specific Version: Quickly revert your environment to a previous state by rolling back to a specific version or revision. This provides a safety net for deployments and makes it easy to undo unwanted changes.
Retract a Revision: Quickly remove a revision from your history – crucial for situations like accidentally exposing a secret in plaintext.

Level Up Your Workflow

Pulumi ESC Versioning delivers significant benefits that can transform your development process:

Disaster Prevention: By pinning a version during import, you can test new configurations in isolation before applying them to critical production systems. This minimizes downtime, reduces risk, and ensures business continuity, boosting confidence in deployments and supporting agile practices.
Improved Auditing and Collaboration: Easily track the complete history of your environments, including who made changes and when. This granular audit trail enhances security, ensures compliance, and promotes seamless collaboration within your team.
Streamlined Development Workflows: Similar to Docker tags, Pulumi ESC version tags provide a familiar and intuitive way to categorize and utilize specific revisions to manage different stages of your environments.

Tags and specific version imports are available on the Enterprise and Business Critical editions of Pulumi Cloud. The Team Edition offers access to the latest 5 revisions.

How to Get Started

Ready to start using versioning in Pulumi ESC? Here’s how you can get started using the CLI or the Console:

Using the CLI

Make sure you have the latest Pulumi CLI installed before you perform these steps. In your terminal,

Run pulumi env edit <environment-name> to edit an environment
Run pulumi env version history <environment-name> to view all revision history
Run pulumi env diff <environment-name>[@<version>] [[<environment-name>]@<version>] to compare changes between versions
Run pulumi env version tag <environment-name>@<tag> to assign a tag to the latest revision
Create a new environment using pulumi env init <new-environment-name> and import the previously edited environment using this syntax:
```
imports:
- <environment-name>@<tag>
```
Run pulumi env open <new-environment-name> to open and confirm that you have imported the right environment version

Check out the Pulumi CLI documentation for more details on available options and commands.

Using the Console

In your Pulumi Cloud Console,

Open an environment, make a change, and click Save
Go to the Versions Tab and select Revision History view to see the history of changes made to the environment
Click on a revision to see its details or view the differences between revisions using compare revisions
Add a tag to a revision by clicking on the Actions menu
Go to the Tags view and copy the reference to the tag
Create a new environment and import the tag

Real-world Scenarios

Here are a few examples of how you might use these features:

Global Infrastructure Update: You need to deploy a new configuration to a global service spanning multiple regions. Tag the updated configuration as next and deploy it to one region for testing. After verifying stability, you can confidently roll it out to other regions. If issues arise, quickly revert to the previous stable version, ensuring resilient and minimally disruptive deployments.
Platform Team Releases: If you’re a Platform team responsible for generating configurations, by tagging releases with labels like v1.0-stable and v1.2-development, you can clearly communicate which configurations are production-ready, keeping other teams informed about the ongoing development, and fostering seamless collaboration.
Code Review and Debugging: You’re working in a development environment where the latest revision includes multiple recent changes, and you notice that the application is experiencing performance issues. By using the Compare Revisions Side-by-Side feature or pulumi env diff, you can quickly identify the specific changes that might be causing the problem, enabling faster troubleshooting and resolution.

These examples are just a glimpse of how Pulumi ESC’s versioning capabilities can streamline your development and deployment process. The possibilities are vast, and you can tailor your tagging strategy to fit your specific needs and operational workflows.

Conclusion

The versioning capabilities in Pulumi ESC mark a significant step towards a more developer-friendly and efficient platform for configuration and secrets management. These features provide a robust foundation for secure, reliable, and auditable deployments, whether you’re rolling out infrastructure updates or ensuring compliance with industry regulations.

We’re excited to see how you leverage these powerful capabilities. Your feedback is crucial in helping us shape the product to better serve your needs. We encourage you to open new issues on our GitHub repository, upvote existing ones, or join the conversation on our community Slack channel.

Check out the Pulumi CLI and Versioning docs.

Simplify OIDC Trust with the New Pulumi GitHub Action

Germán Lena — Mon, 20 May 2024 21:45:13 +0000

We’re excited to announce a new GitHub Action that simplifies the integration of Pulumi’s powerful OpenID Connect (OIDC) Trust feature into your GitHub Actions workflows. This action streamlines secure authentication with Pulumi Cloud, allowing you to leverage GitHub as an identity provider and eliminate the need for long-lived Pulumi access tokens.

A Quick Refresher on Pulumi’s OIDC Trust

The OIDC Trust feature allows you to configure trusted OIDC identity providers, such as GitHub, GitLab, or Google Cloud, within your Pulumi organization. This feature ensures secure and straightforward integration of Pulumi Cloud within any OIDC-compliant system. Once set up, you can securely exchange short-lived OIDC tokens from these providers for temporary Pulumi access tokens. These tokens can then be used to authenticate to Pulumi and perform actions such as deploying your infrastructure using Pulumi IaC, retrieving secrets stored in Pulumi ESC, etc. This approach enhances security by eliminating the need to store long-lived sensitive credentials and aligns with best cloud practices.

Streamlining OIDC Trust with GitHub Actions

Our new GitHub Action makes using OIDC Trust even easier. It automates the secure retrieval of Pulumi access tokens directly within your GitHub workflows, streamlining the authentication process and eliminating manual steps. This automation reduces errors, enhances security by reducing potential token leakage, and improves the maintainability of your workflows, making them cleaner, more readable, and easier to update.

Example Usage

This example demonstrates how to use the Action to authenticate with OIDC and run the pulumi preview command.

name: Pulumi preview
on:
 workflow_dispatch:

permissions:
 id-token: write
 contents: read

jobs:
 run_cron_job:
 runs-on: ubuntu-latest

 steps:
 - uses: actions/checkout@v4

 - uses: pulumi/auth-actions@v1
 with:
 organization: org-name
 requested-token-type: urn:pulumi:token-type:access_token:organization

 - uses: pulumi/actions@v5
 with:
 command: preview
 stack-name: org-name/stack-name

For more information about the pulumi/auth-actions@v1 Action, check the Pulumi Auth Action documentation.

Conclusion

The new GitHub Action for Pulumi OIDC Trust makes it easier than ever to incorporate secure, short-lived credential management into your GitHub Actions workflows. Embrace the power of OIDC, eliminate the “secret zero” problem, and streamline your Pulumi deployments with ease.

Give the action a try in your next GitHub Actions workflow and let us know what you think! Check out our documentation for more details.

Org-only Template Gallery and Setting Default Repositories: Streamline Your Development

Arun Loganathan — Fri, 19 Apr 2024 00:00:00 +0000

We’re constantly evolving the New Project Wizard to make it the preferred choice for platform teams to empower their internal teams to deploy resources quickly and in adherence to organizational standards. In January, we launched the Developer Portal Gallery to boost development velocity and reduce operational friction. Since then, we have seen strong adoption from our customers and received several new requests. We are excited to share the latest improvements we’ve made.

Primer on New Project Wizard and Developer Portal Gallery

The New Project Wizard

The New Project Wizard is a core component of Pulumi for Developer Portal that guides users through a structured process to deploy infrastructure resources through Pulumi. It allows users to select from pre-defined templates or generate new programs through Pulumi AI, configure, and deploy them without leaving the browser. This wizard significantly reduced the time and effort required to get projects off the ground, enabling developers to concentrate more on their development tasks and less on initial setup. Platform teams using the New Project Wizard do not have to custom-build and maintain complex tooling.

Overview of the Developer Portal Gallery

The Developer Portal Gallery allows platform teams to curate and distribute approved project templates within their organization. This feature supports compliance and standardization by ensuring that all projects adhere to organizational policies and best practices right from the start. The gallery not only facilitates the discovery and use of these templates but also makes it easy for developers to start new projects with templates that are pre-vetted and ready to deploy.

Using the Developer Portal Gallery can enhance collaboration across teams by standardizing the tools and processes used for creating and deploying projects. This alignment helps in maintaining a high level of governance as projects scale and ensures consistency across the development lifecycle. Platform teams can oversee template usage and configurations, making sure that each project conforms to the required security, architecture, and performance standards.

What’s New?

Here’s a breakdown of the latest enhancements:

Org-only Template Sources

Previously, the Developer Portal Gallery included both the Organization’s custom templates as well as Pulumi-authored templates. With this update, you can now add or remove the Pulumi-authored templates, ensuring that users only deploy organizationally approved templates. This simplifies template discovery and selection, reinforcing governance and compliance across development projects.

Default Repository Locations

We heard from customers they want their developers to not even have to worry about what repo their Pulumi code lives in. Starting today, admins can set default repository locations for each template source within the gallery. This eliminates the need for developers to select a repository, automatically using predetermined locations and streamlining their deployment process.

Auto-generated Project Names

Another improvement is the auto-generation of project names. Previously, users had to specify a project name, requiring additional input and sometimes leading to naming conflicts. Now, we automatically generate unique project names, further reducing friction and simplifying the project creation process.

Wrapping up

We’re continuously striving to make your experience with Pulumi Cloud as seamless and efficient as possible. Your feedback, big or small, is valuable to us, please feel free to share it in the Pulumi Cloud Requests repository.

Happy building!

Pulumi Release Notes: Pulumi Dev Releases, Pulumi ESC Table Editor, 1Password Support , and more!

Arun Loganathan — Mon, 15 Apr 2024 11:06:04 -0800

As always, we have been actively rolling out new features in response to the invaluable feedback from our ever-growing community. We’ve shipped several security and usability features to Pulumi ESC in response to feedback from our growing user base. Moreover, we’ve also added new enhancements to our core Platform CLI and Providers. In addition to the release notes, stay up-to-date with all things Pulumi by following the new features blogs and the pulumi/pulumi repo changelog. With so much to explore, let’s dive into the major updates across Pulumi from the past two months!

Pulumi Cloud
Core
Providers and Packages
AI
- Pulumi AI Evolution
Wrap up

Pulumi Cloud

Pulumi ESC 1Password Support

In collaboration with 1Password, we’ve launched the 1Password provider for Pulumi ESC in public preview. This feature, highly requested by our community, allows you to pull secrets and configurations stored in 1Password directly into ESC, and use them as environment variables or within Pulumi Config. This integration eliminates the need for manual secret copy and paste, enhancing both security and efficiency. For more details, refer to our blog post.

Pulumi ESC Table view

We’ve rolled out the Pulumi ESC Table view, offering a novel, user-friendly interface for managing secrets and configurations. This addition complements the existing YAML-based editor, providing intuitive and familiar experiences for your workflows with secrets and configurations. Table Editor supports capabilities including CRUD operations for secrets and plaintext values, secret decryption, environment imports, variable projections, and interpolations.

Pulumi ESC YAML Code Editor Enhancements

We’ve upgraded the Pulumi ESC YAML editor with features aimed at simplifying the environment authoring process and enhancing developer productivity. Key enhancements include auto-complete for faster coding, enhanced diagnostics offering deeper error insights, and hover documentation for easy access to information, reducing the need for context switching. Additionally, we have added support for accessing contextual information about the current user and current environments. This support can be used to fine-tune OIDC claims and enhance audit logs. For more details, check out our blog post.

Pulumi ESC OIDC customization

Pulumi ESC now offers subject customization for OIDC tokens, enhancing security across AWS, GCP and Azure by aligning federated credentials with specific identifiers. By configuring the subjectAttributes setting, users can include specific environment, user, and organization information in the OIDC token subject claim, offering more granular control and customization for cloud resource access. This capability is especially valuable for customers using Azure, where subject claims are required to precisely match the string specified in the policy.

Pulumi ESC Audit Logs

Pulumi ESC now features comprehensive Audit Logs for all Create, Read, Open, Update, and Delete (CRUD) operations, strengthening your cloud security framework. This critical addition to Pulumi ESC enables organizations to closely monitor and audit their cloud infrastructure changes, ensuring enhanced oversight and security compliance. Through detailed logging, teams gain valuable insights into their operational activities, facilitating improved governance and accountability across cloud resources.

Core

Dev Releases for the Pulumi CLI and SDKs

We introduced Dev Releases, allowing developers to access the latest features and improvements in Pulumi’s infrastructure as code tools ahead of their official release. With this initiative, we aim to engage our community and gather early feedback, enhancing the product development process. This is crucial for identifying and resolving potential issues early, contributing to a smoother transition to new releases. Dev Releases will also be at the cutting edge of Pulumi’s evolving capabilities, with the latest bug fixes and features available within minutes of Pulumi developers merging. For instructions on how to use the CLI Dev releases see the install docs, and for pre-release versions of Dev SDKs see the docs for Node.js, Python, .NET, and Go.

Automation API support to install Pulumi CLI

The Pulumi Automation API now offers the functionality to install the Pulumi CLI directly through the API. This feature enables deploying programs utilizing the Automation API without the need for prior CLI installation. Explore an example in Go and refer to the new APIs in Go, Node.js, Python, and .NET.

Node.js Monorepo Support

Pulumi now seamlessly integrates with Node.js monorepos using tools like Nx. We’ve enhanced Pulumi to support yarn/npm workspaces, widely used in Node.js monorepos. This enhancement facilitates better project management by automatically handling dependencies and building processes. The integration allows Pulumi infrastructure codes to coexist with application codes in the same repository, improving development workflow efficiency by using Nx’s capabilities to manage build and deploy dependencies effectively. Check out the blog post for more details.

Providers and Packages

New Provider Resources

We have added 121 functions and 159 resources across our most popular providers, along with many more throughout our ecosystem. Notably, Palo Alto Networks is now supported in the Azure Native Provider.

New Community Providers

We welcome new providers to our registry!

Pulumi Registry Documentation Update

The Pulumi Registry documentation has significantly improved example code generation across programming languages. Systemic improvements benefit over 900 examples—700+ in Python, 200+ in Go, and a selection in C#—with notable improvements in type instantiations.

AI

Pulumi AI Evolution

We continue to invest in Pulumi Neo and improve the quality of programs in TypeScript, Python, Go, and C#. Key enhancements include generating code that accurately imports providers, with a special focus on those authored by our community and partners, ensuring the use of correct syntax for Pulumi YAML, embracing modern C# syntax like top-level statements, and implementing comprehensive spellchecking for modules and parameters. These updates continue to push Pulumi AI as a robust, developer-friendly platform, enabling you to build with greater confidence and efficiency. Moreover, you can now cancel in-progress prompts within Pulumi AI should you need to make any changes to your prompt.

Wrap up

That marks the end of this update on Pulumi’s latest enhancements! We can’t wait to see what you build with these new tools. Your feedback drives our innovation. Feel free to open an issue in the Pulumi Cloud requests repository or in the pulumi/pulumi repository for anything CLI. Keep an eye on us for more exciting updates!

Introducing the Table Editor for Pulumi ESC

Arun Loganathan — Tue, 26 Mar 2024 00:00:00 -0700

We’re excited to announce the launch of the Pulumi Environments, Secrets, and Configurations (ESC) Table Editor. At Pulumi, we’re committed to providing flexible solutions that cater to diverse development needs and practices. This latest addition underscores our dedication to this principle by offering a user-friendly interface for managing complex configurations and secrets.

Pulumi ESC simplifies the management of secrets and configurations by reducing duplication and drift, empowering development teams to focus on building and deploying. The existing YAML-based code editor offers a native way for developers to author and manage configurations.

The Table Editor we are launching today introduces an alternate visual interface for handling configuration tasks, enabling the direct input of plaintext and secret values. Key capabilities of the Table Editor include:

CRUD Operations: Perform Create, Read, Update, and Delete (CRUD) operations on your secrets and plaintext values
Decrypting Secrets: Safely decrypt secrets one at a time, directly within the editor
Environment Imports: Import environments and define the order of imports to suit your project’s needs
Variables Projections: Make variables available as Pulumi Config, environment variables, and files, streamlining your deployment and runtime configuration.
Interpolations and References: Add references to existing path-values, or add interpolations to dynamically generate values

In the current release of the Table view, provider configurations and functions are set to read-only.

What’s Next?

Looking to the future, we are already working on the next set of enhancements for the Table view. Soon, you will have the capability to add and edit provider configurations directly within the table view.

Pulumi ESC’s diverse array of providers not only allows teams to dynamically acquire cloud provider credentials at runtime, thus eliminating the need for static, long-lived credentials but also enables retrieving secrets from external secrets managers, such as AWS Secrets Manager and HashiCorp Vault, directly within ESC. This means users can seamlessly pull and utilize secrets within ESC, enhancing security and flexibility. The upcoming provider configuration support in the Table view will offer a guided experience, simplifying the process of leveraging Pulumi ESC’s comprehensive set of providers.

Conclusion

The launch of the Table view marks an important step in our mission to make infrastructure as code more accessible and manageable for developers.

Your feedback is the cornerstone of our development process. As we look ahead, we’re focusing on incorporating your insights to further enhance the Table view. Together, we can continue to refine and advance Pulumi ESC, making it an even more powerful tool for the developer community.

Check out our documentation to learn more about Pulumi ESC.

Introducing the Latest ESC Editor Enhancements for Improved Authoring

Pat Gavlin — Thu, 22 Feb 2024 00:00:00 -0700

With Pulumi ESC, our goal is to not only create a tool that simplifies the development process but also one that developers love. In pursuit of this goal, we’re excited to announce enhancements to the Pulumi ESC environment editor. These enhancements are focused on addressing common challenges encountered when authoring environments: syntax errors, type errors, frequent context switches to and from documentation, and more. Our aim is to make the process of authoring environments as straightforward as possible by removing common hurdles.

Highlights

Auto-complete: This feature provides suggestions for code snippets and resource properties, easing the need to reference documentation. It is engineered to accelerate and refine the coding process, enabling developers to concentrate on innovation and problem-solving.
Enhanced Diagnostics: These diagnostics go beyond basic syntax checks by providing in-depth, as-you-type insights into errors.
Hover Documentation: Hover over any piece of code to see a detailed tooltip with relevant documentation and examples. This instant access to information reduces the need to context switch, streamlining the development process and minimizing disruptions.

Tap ‘Ctrl+Space’ in the editor reveal the list of functions and properties.

Contextual Information to your environments

We have also added support for accessing contextual information from within an ESC environment such as the current user, organization, and environment name. You can use this information to enrich audit logs, refine OIDC claims for more granular access, and more! This information is available by accessing the context property, and contains the following information:

context.rootEnvironment.name: the name of the root environment being evaluated
context.currentEnvironment.name: the name of the current environment being evaluated
context.user.login: the login of the user evaluating the environment
context.organization.login: the name of the user’s organization

values:
 rootEnv: ${context.rootEnvironment.name}
 currentUser: ${context.user.login}

A Seamless Authoring Experience Awaits

The updated editor experience is designed to minimize friction, boost productivity, and transform cloud development into a more enjoyable and effective journey. We are eager for you to explore these new features and see firsthand how they enhance your development process.

Discover more about the capabilities of Pulumi ESC and how it can support your projects by checking out our documentation.

Pulumi Release Notes: Pulumi ESC, Deployments GA, Pulumi AI Improvements, AWS S3 Express One Zone Support, and more!

Arun Loganathan — Thu, 01 Feb 2024 11:06:04 -0800

We’ve had a busy last few months at Pulumi. From shipping a brand new product offering, Pulumi ESC, to adding several major features in Pulumi Cloud and updates to various Pulumi providers - there is lots to catch up on. In addition to reading these release notes, check out the pulumi/pulumi repo changelog to stay up to date with CLI enhancements after each CLI release. For Pulumi Cloud updates, follow the new features blogs to stay updated on the latest feature releases. Let’s walk through the major updates across Pulumi from the last few months!

AI
Pulumi Cloud
Core
- Import Improvements
Providers and Packages
Wrap up

AI

Deploy with Pulumi within Pulumi AI

Pulumi AI’s new feature enables deploying cloud infrastructure using AI prompts. Users can rapidly generate and deploy templates through natural language inputs in ‘pulumi new’ CLI command and new project wizard, significantly streamlining the cloud setup process. Additionally, you now have the option to deploy the Pulumi AI generated Pulumi programs from within Pulumi Neo and in the New Project Wizard in the Pulumi Cloud console.

Pulumi AI coverage and performance

Pulumi AI can now write Pulumi programs for all 150 cloud providers in the Pulumi registry - up from 20 cloud providers. Pulumi AI has also been updated to OpenAI’s GPT-4 Turbo for enhanced performance along with fine tuning our prompts to improve our AI’s ability to write code.

Pulumi AI Answers

Pulumi AI Answers, launched late last year, has become a go-to repository, hosting an extensive collection of over 50,000 anonymized, infrastructure-as-code commonly asked queries, all carefully selected and presented by Pulumi. As this repository continues to expand, we’re seeing an exponential increase in user traffic, underscoring the immense value it offers. It’s inspiring to see the Pulumi community actively leveraging it as they build and scale their cloud infrastructure

Pulumi Cloud

Pulumi ESC Preview

Pulumi Environment, Secrets and Configuration (ESC) is our answer to the growing needs of our customers to manage secret sprawl and streamline config management. Pulumi ESC allows teams to store and aggregate secrets and configuration from various sources into a composable collection called an environment. You can dynamically generate OIDC credentials from all three major cloud providers (AWS, Azure and GCP), and integrate with other secrets managers like AWS Secrets Manager, Hashicorp Vault, Azure Vault and GCP Secret manager to pull secrets during runtime. Its hierarchical structure simplifies the composition and reuse of configurations, ensuring secure, auditable management and robust access control. With Pulumi ESC, the trend is clear: organizations are choosing its comprehensive approach for managing secrets and configurations, and they are here to stay. Get started with Pulumi ESC

Developer Portal Gallery

We launched a new template gallery in the New Project Wizard, supercharging Platform teams to provision and distribute organization templates for their development teams to get up and running fast. Developers can generate Pulumi programs from these templates, commit and push code to GitHub and trigger deployment within the Pulumi Cloud console. The gallery supports three template types: Organization Templates for custom internal projects, Pulumi Templates authored by Pulumi to cover common architectural patterns and AI-Generated Templates created through Pulumi AI. For more information, check out the full blog post.

Deployments GA

Pulumi Deployments was made generally available with new improvements such as support for GitHub Enterprise. Since launch, Pulumi Deployments has made infrastructure management at scale seamless for our customers, offering out of the box features such as Review Stacks and multiple deployment triggers.

Customer Managed Agents

Customer Managed Agents for Pulumi Deployments enable customers with hard security and compliance requirements to take advantage of the powerful capabilities of Pulumi Deployments. By self-hosting the agents, you can host them anywhere within your infrastructure on any hardware and environment in order to meet compliance requirements to keep cloud provider credentials within your private network.

MFA in Pulumi Cloud

We now support multi-factor authentication to prevent unauthorized access, ensuring robust security within your organization. Enable MFA by navigating to your account settings.

Pricing Calculator

Pulumi cost calculator for Team Edition enables you to quickly estimate the cost of using Pulumi Cloud. Simply input the number of resources in all your cloud accounts and the percentage of time they will be running to quickly get the total cost per month with a break down of estimated credits, free credits and cost per credit. You can also use the calculator to estimate the cost of using Pulumi Deployments.

Historical Views

The Pulumi Cloud stack update page now contains the historical resources in the stack and the historical stack outputs. Simply click on details on each Pulumi update to see the resource state and stack output at the time of the update. This history extends all the way back to the first update of the stack. See the historical views blog post for more details.

Core

Import Improvements

We have made several improvements to the pulumi import command to make it easier to bulk import resources into complex programs and components. You can now:

Import one resource and then use that resource as the parent for another imported resource. Previously, parents could only refer to resources that already existed; i.e., you would have had to do two imports
Specify that a resource is a component to be used as the parent of other imported resources via a new component property in the import file
Specify parents by name without having to include the parent URN in the nameTable
Specify the logicalName of resources
Run pulumi preview --import-file <file> on a program to generate a placeholder import file for every resource that would be created as part of the program. The generated file will contain all the names, types, and URNs already filled in, with blank id fields that need to be filled in. This is useful when you already have the structure of the resources for your program and only need to fill in the IDs of existing resources

Additionally, the import system no longer renames resources to try and make unique names and no longer generates errors just because two resources of different types have the same name. The rules for uniqueness now match what’s valid when writing a Pulumi program. The import system will generate an error if you try to import two resources that would end up with the same URN.

Providers and Packages

AWSX now uses AWS 6.0

We have launched AWSx 2.0, bringing all the benefits AWS 6.0 to Pulumi Crosswalk for AWS (AWSx). The new versions offer several fixes and improvements, including support for the latest Terraform Plugin Framework, 56 new resources and 23 new functions for various AWS services.

Pulumi Google Cloud Classic 7.0

We have updated the Pulumi Google Cloud Classic Provider to reflect the latest developments from Google Cloud, including updates to existing resources and adding support for new resources, functions and input properties. One of the key update is the fix for renaming of the Service Account resource for consistency and ease of use. We also made changes to align with upstream changes to labels. Upgrading to this new version is straightforward. Check out our blog post and migration guide.

AWS S3 Express One Zone Support

We added support for Amazon S3 Express One Zone, a new storage class offering up to 10x faster performance and reduced request costs by 50%. S3 Express One Zone is ideal for data-intensive applications such as AI/ML, HPC, etc. This update is part of our commitment to provide timely and effective support for the latest AWS offerings.

New Provider Resources

We have added 641 functions and 662 resources across our most popular providers, along with many more throughout our ecosystem.

New Community Providers

We welcome new providers to our registry!

Wrap up

That’s a wrap on our latest Pulumi release notes! With each new feature and improvement, from AI advancements to enhanced cloud deployment tools, we’re excited to see how you leverage these updates. Your feedback is crucial in shaping our path forward, feel free to open issues in our Pulumi Cloud requests repository or in the pulumi/pulumi repository for CLI feedback. Stay connected for more updates, and here’s to building a more efficient cloud future together!

Introducing Customer-Managed Agents for Pulumi Deployments

Arun Loganathan — Mon, 08 Jan 2024 08:06:12 -0700

At Pulumi, we constantly strive to build solutions that not only simplify infrastructure management but also align with the diverse and specific needs of our customers. To that end, we’re thrilled to announce the general availability of Customer-Managed Agents for Pulumi Deployments.

Primer on Pulumi Deployments

Pulumi Deployments is a fully managed platform for managing infrastructure at scale, providing easy-to-use building blocks that can be used as a simple CI/CD platform or to build a sophisticated self-serve platform to support thousands of engineers. Traditional CI/CD platforms focus on Git-push workflows which fall short when managing infrastructure where the same code base is used to create new infrastructure with no explicit Git-push event. Pulumi Deployments goes beyond the Git-push based workflows to offer deployment triggers based on the Pulumi Deployments REST API, click to deploy in the Pulumi Cloud console, Review Stacks, remote Automation API, and many more features to come.

Since its launch, Pulumi Deployments has transformed how organizations manage their infrastructure, offloading the execution of Pulumi infrastructure as code (IaC) actions — such as previews, updates, destroys, and refreshes — to Pulumi Cloud. Our customers have used it to deploy and manage mission-critical services, driving efficiencies and reducing the operational burden of deploying and managing infrastructure.

Deploy on Your Terms: Launching Customer-Managed Agents

With the launch of Customer-Managed Agents, you can now self-host the deployment agents within your infrastructure, bringing the same power and flexibility of Pulumi-hosted deployments to isolated environments. Customers with hard security and compliance requirements can now fully leverage Pulumi Deployments.

Newton, a leading crypto trading platform and a Pulumi Cloud customer, was in the private beta of Customer-Managed Agents. “Pulumi’s rapid innovation and customer-centric approach never fail to impress. The introduction of Customer-Managed Agents is a testament to their ongoing commitment,” said Shaun Martin, Director of Engineering at Newton. “We’re thrilled with the turnkey solutions Pulumi Deployments offer, enhancing our infrastructure management while upholding our stringent security requirements.”

Key Benefits of Customer-Managed Deployment Agents

Host anywhere: You can host the deployment agents anywhere to manage infrastructure, even within your fully private VPCs
Any hardware, any environment¹: Run the agents on any hardware of your choice and configure the environment that meets your needs
Mix & match: You can use standard Pulumi-hosted deployments for your development stacks and use self-hosted Customer-Managed Agents for your private network infrastructure. You can mix and match to suit your unique needs
Multiple pools: You can set up multiple deployment agent pools, assign stacks to specific pools, and scale agents dynamically to increase your deployment concurrency. Customers can have up to 150 concurrent deployments
Meet compliance: You can configure the agents with the credentials needed to manage your infrastructure. This way your cloud provider credentials never leave your private network

¹ Currently Linux and MacOS are supported

Customer-Managed Agents support all the deployment triggers currently offered by Pulumi Deployments such as click to deploy, the Pulumi Deployments REST API, Git push to deploy, Review Stacks, and remote Automation API.

Customer-Managed Agents is available on the Business Critical edition of Pulumi Cloud. Contact sales if you are interested and want to enable Customer-Managed Agents. If you are a self-hosted Pulumi Cloud customer, please get in touch to be notified when it is available.

How to get started

Before you begin, ensure you have installed the Pulumi Github App and update the source control settings. Docker is a requirement for the agent.

Install and configure the agent

Go to Deployment runners under Organization Settings in the left-hand navigation menu. Once on the Deployment runners page, choose Add a new pool. Next, provide a name and description for your agent. You will then get a new access token for the pool. Be sure to copy and save this token in a secure location.

Download and install the agents using the command provided. Once installed, provide the access token previously copied to configure the agent.

If you run into issues, ensure docker is running before you configure and start the agents. Ensure you restart or refresh the shell session (example: source ~/.zshrc).

Now your first agent should be up and running! You can verify the status of the agent by refreshing the page. Additionally, you can use the same token to set up multiple agents to increase concurrency of your deployments and they will be assigned to the same pool.

Agents poll Pulumi Cloud every 30 seconds to check for pending deployments. In the pool page, you can see the last online status of the agents. Agents will disappear from the list after 1-2 hours of being offline. If you are running the agent inside a firewall ensure to allow outbound requests to api.pulumi.com.

Configure Stack

Go to deployment settings, found under the settings tab on a stack under ‘Deploy’. Scroll down and select the pool you created under the Deployment Runner pool drop-down.

Ensure that agents have the cloud provider credentials to be able to deploy in your environments. You have two methods:

Use OpenID Connect (OIDC) to generate credentials
Directly provide credentials to agents through environment variables configured in the host, or passing the environment variables when invoking the binary. Example:
```
VARIABLE=value customer-managed-deployment-agent run
```
You also need to update the pulumi-deployment-agent.yaml configuration file by setting env_forward_allowlist. The configuration file can be found in the directory where the agent is extracted. env_forward_allowlist expects an array of strings. Example:
```
token: pul-d2d2….
version: v0.0.5
env_forward_allowlist:
 - key_one
 - key_two
 - key_three
```

Verify setup

You have completed the setup. Try out the agent by doing pulumi refresh through the Actions drop-down in your stack page.

You should see the logs in the agent running on the machine you configured and also in the Pulumi Cloud console.

On the deployments page, you can see all the deployments including pending deployments, and which deployment agents were used in a deployment.

Your Journey, Our Support

Customer-Managed Agents empower you to align your deployment strategies with the specific requirements of your infrastructure. Whether it’s ensuring compliance, enhancing security, or customizing deployment processes, Customer-Managed Agents provide the flexibility you need.

Embark on this journey to simplify your infrastructure deployments with our new feature. We are here every step of the way to assist you. Share any feedback in the Pulumi Cloud Requests repository with us.