Pulumi Blog: Meagan Cojocar

Introducing the Stash Resource in Pulumi IaC

Fraser Waters — Mon, 12 Jan 2026 00:00:00 +0000

We’re excited to announce the Stash resource, a new built-in Pulumi resource that lets you save arbitrary values directly to your stack’s state. Whether you need to capture a computed result, record who first deployed your infrastructure, or persist configuration that should remain stable across updates, Stash provides a simpler and more ergonomic solution.

Why Stash?

Infrastructure code often produces values that need to persist beyond a single deployment. Maybe you’re generating a random identifier that should stay consistent, tracking which team member initially set up a stack, or recording a timestamp from the first deployment. Previously, you’d need workarounds like external storage, custom resources, or careful state manipulation.

The Stash resource helps with that. It takes an input value, stores it in your stack’s state, and makes it available as an output property. The output property preserves the original value even when the input changes in subsequent deployments, making Stash perfect for “first-run” scenarios where you want to capture and preserve a value from the initial deployment.

Using Stash

Creating a Stash is straightforward. Here’s how you’d capture the username of whoever first deploys the stack (using Node.js):

import * as pulumi from "@pulumi/pulumi";
import * as os from "os"; // Node.js built-in module

const firstDeployer = new pulumi.Stash("firstDeployer", {
 input: os.userInfo().username,
});

export const originalDeployer = firstDeployer.output;

The first time this runs, both input and output will show the current user. On subsequent deployments by different users, input will update to show the new user, but output will continue returning the original deployer’s name.

Stash supports any value type—strings, numbers, objects, arrays, and nested structures. It also respects secret annotations, so if you stash a secret value, it stays encrypted in your state.

When to replace

Since Stash preserves the original value by design, updating the stored value requires a replacement. You have several options:

Use --target-replace during pulumi up:

pulumi up --target-replace urn:pulumi:dev::my-project::pulumi:index:Stash::firstDeployer

Run pulumi state taint to mark the resource for replacement:

pulumi state taint urn:pulumi:dev::my-project::pulumi:index:Stash::firstDeployer

Use the replacementTrigger resource option to automate replacements based on value changes:

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

const remoteConfig = fetch("https://example.com/my-service").then(response => response.json())

const myStash = new pulumi.Stash("myStash",
 {
 input: os.userInfo().username,
 }, {
 replacementTrigger: remoteConfig.someValue,
 }
);

export const stashedValue = myStash.output;

With replacementTrigger, when remoteConfig.someValue changes, the Stash resource will be replaced and the new input value will be captured.

Learn more

The Stash resource is available now in Pulumi v3.208.0 and later across all supported languages. Check out the Stash documentation for detailed examples in TypeScript, Python, Go, C#, and YAML.

We’d love to hear how you’re using Stash and any feedback you have on it! Share your use cases in our Community Slack or open an issue if you see any on pulumi/pulumi.

Happy hacking!

10 Things You Can Do With Our Infrastructure Agent, Neo

Meagan Cojocar — Mon, 06 Oct 2025 00:00:00 +0000

Since launching Pulumi Neo two weeks ago, we’ve seen platform teams discover creative ways to put their newest AI teammate to work. We have also been using Neo internally for a handful of use cases. Neo shifts the conversation from “what could AI do for infrastructure?” to “what can I actually accomplish with Neo today?”

The answer is quite a bit. Here are 10 concrete workflows that platform teams can use Neo for right now, each one designed to save hours of manual work while keeping humans in the driver seat.

1. Explain infrastructure in plain English or diagrams

Neo answers questions about your infrastructure instantly, turning complex resource relationships into conversational insights (and diagrams!).

No more digging through AWS consoles or parsing state files to understand what you have deployed. Neo speaks your language about your infrastructure. Ask questions like “What databases do we have?”, “Which S3 buckets aren’t encrypted?”, “Show me all resources in us-east-1” or “draw an architecture diagram of our service” and get immediate, accurate answers.

2. Generate infrastructure code from natural language

Neo turns plain English descriptions into production-ready Pulumi code, eliminating the blank-page problem that slows down new projects.

Instead of starting from scratch or hunting through documentation, describe what you need and Neo generates the complete infrastructure. Ask Neo: “Create a serverless API with PostgreSQL database and Redis cache on AWS” and it produces fully configured resources with proper networking, security groups, and IAM policies.

3. Assist with Terraform to Pulumi migration

Neo analyzes existing Terraform code (and/or state files) and generates equivalent Pulumi programs, accelerating migration without starting from scratch.

Migrating from Terraform to Pulumi traditionally means rewriting everything. Neo understands both languages and can convert HCL to TypeScript, Python, or Go while preserving your infrastructure patterns. You can also use the Terraform state file. Ask Neo: “Analyze the provided terraform state. Based on it, generate a python pulumi program that imports the resources without requiring updates.” and it generates equivalent code with proper typing and best practices.

Using this prompt with a Terraform state file containing EC2 instances and supporting resources, Neo generated a complete Pulumi program that imported everything without requiring updates:

4. Automate CI/CD pipeline generation

Neo creates complete GitHub Actions workflows configured specifically for Pulumi deployments, with proper preview stages.

Setting up CI/CD for infrastructure projects usually involves copying workflows from other repos and adapting them. Neo generates purpose-built pipelines that understand your stack structure and deployment patterns. Ask Neo: “Create a GitHub Actions pipeline for this Pulumi project with preview and production stages” and it produces workflows with proper secrets management, approval gates, and deployment strategies.

Here is what Neo gives us using that prompt on a very basic Pulumi project:

name: Simple Pulumi Deploy

on:
 push:
 branches: [main]
 workflow_dispatch:

env:
 PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
 AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
 AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

jobs:
 deploy:
 runs-on: ubuntu-latest
 steps:
 - name: Checkout code
 uses: actions/checkout@v4

 - name: Install Pulumi
 uses: pulumi/actions@v4
 with:
 pulumi-version: latest

 - name: Configure AWS credentials
 uses: aws-actions/configure-aws-credentials@v4
 with:
 aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
 aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
 aws-region: us-west-2

 - name: Deploy infrastructure
 run: |
 pulumi stack select production
 pulumi up --yes
 working-directory: ./infrastructure

5. Identify inefficient infrastructure patterns

Neo analyzes your infrastructure and spots patterns that create unnecessary management overhead, helping you consolidate and optimize.

When you have 10 identical EC2 instances that should be an auto-scaling group, or multiple Lambda functions doing the same job, Neo spots these patterns. Ask Neo: “Analyze our infrastructure for inefficient patterns” and it can identify consolidation opportunities.

Example analysis:

Neo identified these optimization opportunities:

1. Duplicate EC2 Instances (High Priority)
 • Found 8 identical t3.medium instances running the same application
 • Recommendation: Consolidate into an Auto Scaling Group
 • Benefits: Simplified management, automatic scaling, reduced configuration drift

2. Scattered Lambda Functions (Medium Priority)
 • Found 12 Lambda functions with identical runtime and dependencies
 • Recommendation: Combine into a single function with routing logic
 • Benefits: Reduced cold starts, simplified monitoring, easier updates

3. Redundant Security Groups (Low Priority)
 • Found 15 security groups with identical rules
 • Recommendation: Create shared security groups for common patterns
 • Benefits: Easier rule management, reduced complexity

6. Upgrade EKS/Kubernetes clusters

Neo manages Kubernetes version upgrades across multiple clusters, planning upgrade paths and validating compatibility.

Kubernetes upgrades are complex, especially across multiple clusters with different workloads. Neo analyzes your cluster configurations, identifies upgrade blockers, and creates systematic upgrade plans. Ask Neo: “Plan an upgrade path for our EKS clusters from 1.27 to 1.28” and it maps dependencies, checks add-on compatibility, and sequences the upgrades.

7. Respond to security vulnerabilities

When CVEs are announced, Neo can help security teams move at machine speed addressing them.

Security vulnerabilities require immediate response across your entire infrastructure. Neo understands your resource inventory and can quickly identify what’s affected by new CVEs. When you ask Neo: “Identify all resources affected by CVE-2025-XXXXX and create remediation PRs”, it scans your infrastructure, maps vulnerable components, and generates targeted fixes.

8. Remediate policy violations

Neo detects non-compliant resources and generates pull requests to fix them, turning compliance headaches into automated workflows.

When your policy violations detect unencrypted EBS volumes, overly permissive security groups, or missing resource tags, Neo identifies the issues and proposes specific fixes. Ask Neo: “Fix all policy violations in our production account” and it analyzes your compliance dashboard, identifies the problematic resources, and creates PRs with the exact changes needed.

9. Update Lambda runtimes across multiple accounts

Neo identifies outdated Lambda runtimes, stages updates, and manages the rollout across your entire AWS organization.

When AWS announces runtime deprecations, Neo scans all your accounts, identifies functions running outdated versions, and creates a systematic upgrade plan. Ask Neo: “Upgrade all Lambda functions to Python 3.11” and it maps your functions, checks compatibility, and generates account-by-account PRs.

Before (outdated runtime):

// Create the process email Lambda function
const lambdaFunction = new aws.lambda.Function("emailProcessor", {
 runtime: aws.lambda.Runtime.Python3d8, // ❌ Deprecated
 code: new pulumi.asset.AssetArchive({
 ".": new pulumi.asset.FileArchive("./lambda"),
 }),
 // ... other configuration
});

After (Neo’s upgrade):

// Create the process email Lambda function
const lambdaFunction = new aws.lambda.Function("emailProcessor", {
 runtime: aws.lambda.Runtime.Python3d11, // ✅ Upgraded
 code: new pulumi.asset.AssetArchive({
 ".": new pulumi.asset.FileArchive("./lambda"),
 }),
 // ... other configuration
});

10. Enforce multi-account policy compliance

Neo applies organizational policies across your entire AWS Organizations structure, ensuring governance at scale without creating bottlenecks.

Large organizations struggle to maintain consistent policies across dozens of AWS accounts. Neo understands your organizational structure and can enforce tagging standards, encryption requirements, and security policies uniformly. Ask Neo: “Ensure all accounts follow our tagging and encryption policies” and it audits compliance across your organization.

Your newest platform engineer

These workflows represent just the beginning of what’s possible when an AI agent deeply understands infrastructure context.

The outcome is simple: spend less time on operational toil and more time on the architecture and policies that make your organizations successful.

Get started with Neo and discover what becomes possible when AI truly understands infrastructure.

The future of platform engineering isn’t about choosing between speed and safety. It’s about having tools that help you with both simultaneously.

Precise Resource Replacement with Pulumi State Taint

Meagan Cojocar — Sun, 31 Aug 2025 00:00:00 +0000

Sometimes infrastructure needs a clean slate. A VM with a corrupted disk, an expired certificate, or a stuck Kubernetes object. Pulumi CLI v3.192.0 introduces pulumi state taint and pulumi state untaint commands that let you mark resources for replacement—especially valuable when you have state access but restricted cloud permissions.

The New Commands

pulumi state taint <resource-urn> - Mark a resource for replacement
pulumi state untaint <resource-urn> - Cancel the replacement (use --all to untaint all resources)

Note: This provides the same functionality as pulumi up --replace <urn>, but lets you mark resources upfront and preview changes before the update. This can be preferred when the pulumi up happens later in CI/CD, where arranging for --replace flags would be tedious.

Why This Matters

The taint and untaint commands solve several infrastructure management challenges. For example, many organizations restrict direct cloud access to production environments, allowing changes only through CI/CD pipelines. In these cases, you can access Pulumi state but not cloud APIs directly—taint lets you mark problematic resources for replacement and let the next automated deployment handle the actual changes, no emergency access requests required.

Workflow

# 1. Find the resource URN
pulumi stack --show-urns

# 2. Mark for replacement
pulumi state taint urn:pulumi:production::webapp::aws:ec2/instance:Instance::web-server

# 3. Preview the changes
pulumi preview

# 4. Apply the replacement
pulumi up

# Optional: Cancel the taint
pulumi state untaint urn:pulumi:production::webapp::aws:ec2/instance:Instance::web-server

Get Started

Available now in Pulumi CLI v3.192.0. Try it in a development stack first to get familiar with the workflow.

This feature originated from feedback in issue #11657. See the v3.192.0 release notes for full details. Have feedback or ideas? Join the discussion in the Pulumi CLI repository.

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!

Azure Native V3: A Leaner, Faster SDK for Microsoft Azure

Thomas Kappler — Thu, 03 Apr 2025 00:00:00 +0000

Pulumi Azure Native V3 is the most comprehensive infrastructure as code (IaC) solution for Microsoft Azure, combining full resource coverage with dramatic improvements in performance and developer experience.

With V3, the Pulumi Azure Native SDK is 75% smaller while maintaining 100% coverage of the Azure Resource Manager (ARM) API. This makes it the most efficient and complete way to define and manage Azure infrastructure with real programming languages.

Pulumi Azure Native provides direct access to the Azure Resource Manager API, making it hands-down the best infrastructure as code solution for Microsoft Azure. Unlike traditional providers that abstract away cloud APIs, Azure Native gives you more resource and property coverage compared to Terraform by directly mapping to Azure’s native REST API. This means:

Complete API coverage: Access every Azure resource available in ARM
Same-day updates: New Azure services and properties are available immediately
Advanced property support: Work with every resource property, not just a subset
Latest API versions: Always up to date with the newest stable Azure APIs

And with V3’s slimmer SDK footprint, developers benefit from faster IDE performance, reduced memory usage, quicker installs, and improved CI/CD pipeline efficiency.

These improvements came about through our RFC process, where we explored various options to balance SDK size with the flexibility needed by advanced users.

A Slimmer, More Efficient SDK

The most significant improvement in Azure Native V3 is the dramatic 75% reduction in SDK size across all languages. By optimizing the SDK to include only the default API versions, we’ve solved one of the main pain points reported by our users, the size of the package:

Language	Before	After	Reduction
.NET	77 MB	15 MB	80.5%
JS/TS	494 MB	87 MB	82.4%
Python	104.6 MB	25 MB	76.3%
Go (source)	910 MB	167 MB	81.6%
Java (explicit versions were not supported in v2)	68 MB	71 MB	+4.4%
YAML	no SDK	no SDK	-

This transformation delivers immediate benefits that every developer will notice: faster IDE performance with reduced load times, more responsive language servers for better autocompletion, reduced memory consumption, significantly quicker package installation, and improved CI/CD pipeline performance.

Additional Enhancements in Azure Native V3

Azure Native V3 introduces more than just SDK size optimization. Other improvements include:

Reorganized module structure better aligned with Azure SDK conventions
Improved resource naming for clearer distinction between similar resources
Enhanced handling of nested properties to avoid accidental overwriting
Better state management with the removal of unnecessary __inputs fields (most noticeable with large stacks)

Understanding Azure Versioning

The Pulumi Azure Native provider needs to manage two different versioning systems:

Pulumi’s Semantic Versioning: Our SDKs follow the traditional major.minor.patch format (e.g., 3.0.0)
- Patch versions (3.0.1) contain bug fixes only
- Minor versions (3.1.0) add new resources and non-breaking features
- Major versions (3.0.0) may contain breaking changes
Azure’s Date-based API Versions: Azure resources use date-based versions like “2024-01-01” or “2023-05-15-preview”
- Each Azure service (resource provider) has its own set of API versions
- Breaking changes can occur between different API versions
- Preview versions (with “-preview” suffix) contain newer features that may not be stable yet

Default API Versions

Azure Native V3 includes refreshed default API versions across nearly all resources, ensuring you’re automatically working with the latest stable Azure features and capabilities without any extra configuration. The new default versions unlock powerful new Azure functionality out of the box, such as:

EventGrid (now 2025-02-15): Support for advanced filtering, dead-lettering, and custom event schemas
MachineLearningServices (now 2024-10-01): Enhanced compute instance capabilities and new model deployment options
Storage (now 2024-01-01): Improved performance tiers and expanded security features
KeyVault (now 2024-03-01): Enhanced certificate management and expanded access policy options

Using Non-Default API Versions

Most users (approximately 95% based on our Pulumi Cloud data) will be perfectly served by these default API versions. However, there are situations where you might need to use a specific API version.

For these cases, Azure Native V3 provides two flexible approaches:

Option 1: Accessing Explicit API Versions via Local Packages

The most type-safe way to use explicit API versions is through local packages. This approach gives you the full SDK experience with strong typing, auto-completion, and documentation.

Add the specific API version package

Use the Pulumi CLI to add just the packages and versions you need:

pulumi package add azure-native storage v20240101

For more details on the package add command, see the CLI documentation.

Step 2: Import and use the versioned package

Once added, you can import and use the specific API version in your code:

import * as resources from "@pulumi/azure-native/resources";
import * as storage_v20240101 from "@pulumi/azure-native_storage_v20240101";

const resourceGroup = new resources.ResourceGroup("resourceGroup");

const storageAccount = new storage_v20240101.storage.StorageAccount("sa", {
 resourceGroupName: resourceGroup.name,
 sku: {
 name: storage_v20240101.storage.SkuName.Standard_LRS,
 },
 kind: storage_v20240101.storage.Kind.StorageV2,
});

import pulumi
from pulumi_azure_native import resources
import pulumi_azure_native_storage_v20240101 as storage_v20240101

resource_group = resources.ResourceGroup("resource_group")

storage_account = storage_v20240101.storage.StorageAccount("sa",
 resource_group_name=resource_group.name,
 sku=storage_v20240101.storage.SkuArgs(
 name=storage_v20240101.storage.SkuName.STANDARD_LRS,
 ),
 kind=storage_v20240101.storage.Kind.STORAGE_V2)

using Pulumi;
using Pulumi.AzureNative.Resources;
using Storage_v20240101 = Pulumi.AzureNative_Storage_v20240101;

class MyStack : Stack
{
 public MyStack()
 {
 var resourceGroup = new ResourceGroup("resourceGroup");

 var storageAccount = new Storage_v20240101.Storage.StorageAccount("sa", new()
 {
 ResourceGroupName = resourceGroup.Name,
 Sku = new Storage_v20240101.Storage.SkuArgs
 {
 Name = Storage_v20240101.Storage.SkuName.Standard_LRS,
 },
 Kind = Storage_v20240101.Storage.Kind.StorageV2,
 });
 }
}

package main

import (
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
 "github.com/pulumi/pulumi-azure-native/sdk/go/azure/resources"
 storage_v20240101 "github.com/pulumi-azure-native-storage-v20240101/sdk/go/azure/storage"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 resourceGroup, err := resources.NewResourceGroup(ctx, "resourceGroup", nil)
 if err != nil {
 return err
 }

 storageAccount, err := storage_v20240101.NewStorageAccount(ctx, "sa", &storage_v20240101.StorageAccountArgs{
 ResourceGroupName: resourceGroup.Name,
 Sku: &storage_v20240101.SkuArgs{
 Name: storage_v20240101.SkuNameStandard_LRS,
 },
 Kind: storage_v20240101.KindStorageV2,
 })
 if err != nil {
 return err
 }

 return nil
 })
}

name: azure-native-example
runtime: yaml
description: A minimal Azure Native Pulumi YAML program
resources:
 resourceGroup:
 type: azure-native:resources:ResourceGroup
 properties:
 location: westus2

 # Using specific API version package
 storageAccount:
 type: azure-native_storage_v20240101:storage:StorageAccount
 properties:
 resourceGroupName: ${resourceGroup.name}
 sku:
 name: Standard_LRS
 kind: StorageV2

package myproject;

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.azurenative.resources.ResourceGroup;
import com.pulumi.azurenative.resources.ResourceGroupArgs;
import com.pulumi.azurenative_storage_v20240101.storage.StorageAccount;
import com.pulumi.azurenative_storage_v20240101.storage.StorageAccountArgs;
import com.pulumi.azurenative_storage_v20240101.storage.enums.Kind;
import com.pulumi.azurenative_storage_v20240101.storage.enums.SkuName;
import com.pulumi.azurenative_storage_v20240101.storage.inputs.SkuArgs;

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

 private static void stack(Context ctx) {
 var resourceGroup = new ResourceGroup("resourceGroup");

 var storageAccount = new StorageAccount("sa", StorageAccountArgs.builder()
 .resourceGroupName(resourceGroup.name())
 .sku(SkuArgs.builder()
 .name(SkuName.Standard_LRS)
 .build())
 .kind(Kind.StorageV2)
 .build());
 }
}

Option 2: Using the Generic Resource

An alternative approach is to use the generic azure-native.resources.Resource. This special resource allows you to access any Azure resource at any API version, including older versions that might not be available through local packages.

While not as type-safe as the local package approach, the generic resource offers maximum flexibility and is useful when you need to access a resource that is not yet supported by the Pulumi provider or when an issue prevents you from using a specific resource.

In most cases, we recommend using the local packages approach when you need a specific API version, and only falling back to the generic resource for special cases or resources not yet supported by the Pulumi provider.

For more details, see the Azure Native version guide.

Getting Started with Azure Native V3

If You’re Already Using Pulumi Azure Native

Upgrading ensures you benefit from the smaller SDK, refreshed defaults, and the best performance when managing Azure at scale.

Upgrading from v2: Follow the v2 to v3 migration guide.
Upgrading from v1: First move to v2 using our v1 to v2 upgrade guide, the follow the v2 to v3 migration guide. This two-step process resolves deprecation warnings and ensures a smoother migration.

For language-specific installation instructions, see our Azure Native setup guide.

If You’re New to Pulumi

Pulumi makes it easy to define, deploy, and manage Azure infrastructure using your favorite programming languages. To get started:

Sign up for Pulumi Cloud - free for individuals and teams.
Explore the Azure Native installation guide.
Try a quickstart project to provision real Azure resources in minutes.

Conclusion

Pulumi Azure Native V3 is the most complete and efficient solution for managing Azure infrastructure as code. With a dramatically smaller SDK, updated defaults, flexible API versioning, and enhanced developer experience, it offers the best combination of performance, coverage, and control for Microsoft Azure users.

We’d like to thank our community for their valuable feedback throughout the development of V3. Your input helped shape this release, and we’re excited to see what you’ll build with it.

Have questions or suggestions? Open an issue on GitHub, join our Community Slack.

Announcing the Next-Generation of Pulumi Components: Enabling Infrastructure Abstractions

Mikhail Shilkov — Thu, 27 Mar 2025 00:00:00 +0000

Pulumi Components enable you to create, share, and consume reusable infrastructure building blocks across your organization and the broader community. Today, we’re excited to announce significant enhancements to Pulumi Components that make them more powerful, accessible, and easier to use than ever before.

With this release, we’ve made it possible to author components in one language and consume them in any other Pulumi language—including Pulumi YAML. This breakthrough enables platform teams to build sophisticated infrastructure abstractions in their preferred programming language while application developers can easily consume these components using simpler interfaces or even YAML, all without sacrificing type safety or functionality.

For platform teams, the new Pulumi Components offer a more intuitive, more secure way to codify organizational standards. For developers, it’s a straightforward way to pull in platform-approved abstractions without having to worry about all the underlying details. It’s a win-win that drastically accelerates innovation and drives productivity across your teams.

Understanding Pulumi Components

At their core, Pulumi Components are logical groupings of resources that encapsulate infrastructure patterns and best practices. Unlike standard resources that map directly to cloud provider resources, components are higher-level abstractions that can contain multiple child resources working together to implement a specific capability. While similar in concept to Terraform modules, Pulumi Components offer more power through full programming language capabilities, stronger typing, and now, cross-language support.

For example, a SecureBucket component might include a bucket, versioning configuration, encryption settings, and tagging policies—all bundled together as a single, reusable unit that enforces your organization’s security and compliance standards.

Pulumi has always supported creating components within a single language - you can simply create a class that extends ComponentResource in your language of choice and use it within programs written in that same language. This approach works well for teams working within a single language ecosystem, requiring no additional setup beyond standard programming patterns. However, these traditional single-language components can’t be consumed from other Pulumi languages, limiting their shareability across teams with different language preferences.

What’s New with Pulumi Components

Our latest enhancements focus on making components more accessible and easier to share:

Cross-language consumption: Components authored in one language can now be consumed in any Pulumi language, now including Pulumi YAML.
Simplified sharing: Share components by simply pushing code to a git repository - no need to manually publish SDKs.
Streamlined consumption: Use the pulumi package add command with any git URL (like github.com/org/repo) to easily incorporate any components into your projects.
YAML authoring support: For the first time, you can now author components directly in YAML, making it easier for teams with limited programming experience to create and maintain reusable infrastructure patterns.

How It Works

Creating Components

The code for creating a cross-language component starts similarly to a single-language component: define a class that extends ComponentResource:

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

export interface SecureBucketArgs {
 bucketName?: pulumi.Input<string>;
 versioning?: pulumi.Input<boolean>;
 encryption?: pulumi.Input<boolean>;
 tags?: { [key: string]: pulumi.Input<string> };
}

export class SecureBucket extends pulumi.ComponentResource {
 public readonly bucket: aws.s3.BucketV2;
 public readonly bucketName: pulumi.Output<string>;

 constructor(name: string, args: SecureBucketArgs = {}, opts?: pulumi.ComponentResourceOptions) {
 super("mycomponents:index:SecureBucket", name, {}, opts);

 // Create an S3 bucket with best practices by default
 this.bucket = new aws.s3.BucketV2(`${name}`, {
 bucket: args.bucketName,
 tags: {
 ManagedBy: "Pulumi",
 ...args.tags,
 },
 }, { parent: this });

 // Conditionally enable versioning
 if (args.versioning !== false) {
 new aws.s3.BucketVersioningV2(`${name}-versioning`, {
 bucket: this.bucket.id,
 versioningConfiguration: {
 status: "Enabled",
 },
 }, { parent: this });
 }

 // Conditionally enable encryption
 if (args.encryption !== false) {
 new aws.s3.BucketServerSideEncryptionConfigurationV2(`${name}-encryption`, {
 bucket: this.bucket.id,
 rules: [{
 applyServerSideEncryptionByDefault: {
 sseAlgorithm: "AES256",
 },
 }],
 }, { parent: this });
 }

 this.bucketName = this.bucket.id;

 this.registerOutputs({
 bucket: this.bucket,
 bucketName: this.bucketName,
 });
 }
}

import pulumi
import pulumi_aws as aws
from typing import Optional, Dict, Any, Mapping

class SecureBucketArgs(TypedDict):
 bucket_name: Optional[pulumi.Input[str]]
 versioning: Optional[bool]
 encryption: Optional[bool]
 tags: Optional[Mapping[str, pulumi.Input[str]]]

class SecureBucket(pulumi.ComponentResource):
 bucket_name: pulumi.Output[str]
 def __init__(self, name: str, args: SecureBucketArgs, opts: Optional[pulumi.ResourceOptions] = None):
 super().__init__('mycomponents:index:SecureBucket', name, {}, opts)

 args = args or SecureBucketArgs()

 # Create an S3 bucket with best practices by default
 bucket = aws.s3.BucketV2(
 f"{name}",
 bucket=args.get("bucket_name"),
 tags={
 "ManagedBy": "Pulumi",
 **args.get("tags", {})
 },
 opts=pulumi.ResourceOptions(parent=self)
 )

 # Conditionally enable versioning
 if args.get("versioning", True):
 aws.s3.BucketVersioningV2(
 f"{name}-versioning",
 bucket=bucket.id,
 versioning_configuration=aws.s3.BucketVersioningV2VersioningConfigurationArgs(
 status="Enabled"
 ),
 opts=pulumi.ResourceOptions(parent=self)
 )

 # Conditionally enable encryption
 if args.get("encryption", True):
 aws.s3.BucketServerSideEncryptionConfigurationV2(
 f"{name}-encryption",
 bucket=bucket.id,
 rules=[aws.s3.BucketServerSideEncryptionConfigurationV2RuleArgs(
 apply_server_side_encryption_by_default=aws.s3.BucketServerSideEncryptionConfigurationV2RuleApplyServerSideEncryptionByDefaultArgs(
 sse_algorithm="AES256"
 )
 )],
 opts=pulumi.ResourceOptions(parent=self)
 )

 self.bucket_name = bucket.id

 self.register_outputs({
 "bucketName": self.bucket_name
 })

using System.Collections.Generic;
using Pulumi;
using Pulumi.Aws.S3;
using Pulumi.Aws.S3.Inputs;

namespace MyComponents
{
 public class SecureBucketArgs : ResourceArgs
 {
 [Input("bucketName")]
 public Input<string>? BucketName { get; set; }

 [Input("versioning")]
 public bool? Versioning { get; set; }

 [Input("encryption")]
 public bool? Encryption { get; set; }

 [Input("tags")]
 public Dictionary<string, Input<string>>? Tags { get; set; }
 }

 public class SecureBucket : ComponentResource
 {
 [Output("bucketName")]
 public Output<string> BucketName { get; private set; }

 public SecureBucket(string name, SecureBucketArgs? args, ComponentResourceOptions? opts = null)
 : base("mycomponents:index:SecureBucket", name, opts)
 {
 args ??= new SecureBucketArgs();

 // Create an S3 bucket with best practices by default
 var tags = new InputMap<string>
 {
 { "ManagedBy", "Pulumi" }
 };

 if (args.Tags != null)
 {
 foreach (var tag in args.Tags)
 {
 tags[tag.Key] = tag.Value;
 }
 }

 var bucket = new BucketV2($"{name}", new BucketV2Args
 {
 Bucket = args.BucketName,
 Tags = tags
 }, new CustomResourceOptions { Parent = this });

 // Conditionally enable versioning
 if (args.Versioning != false)
 {
 new BucketVersioningV2($"{name}-versioning", new BucketVersioningV2Args
 {
 Bucket = bucket.Id,
 VersioningConfiguration = new BucketVersioningV2VersioningConfigurationArgs
 {
 Status = "Enabled"
 }
 }, new CustomResourceOptions { Parent = this });
 }

 // Conditionally enable encryption
 if (args.Encryption != false)
 {
 new BucketServerSideEncryptionConfigurationV2($"{name}-encryption", new BucketServerSideEncryptionConfigurationV2Args
 {
 Bucket = bucket.Id,
 Rules = new[]
 {
 new BucketServerSideEncryptionConfigurationV2RuleArgs
 {
 ApplyServerSideEncryptionByDefault = new BucketServerSideEncryptionConfigurationV2RuleApplyServerSideEncryptionByDefaultArgs
 {
 SseAlgorithm = "AES256"
 }
 }
 }
 }, new CustomResourceOptions { Parent = this });
 }

 BucketName = bucket.Id;

 RegisterOutputs(new Dictionary<string, object?>
 {
 { "BucketName", BucketName }
 });
 }
 }
}

package components

import (
 "github.com/pulumi/pulumi-aws/sdk/v7/go/aws/s3"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

// SecureBucketArgs contains the arguments for creating a SecureBucket
type SecureBucketArgs struct {
 BucketName pulumi.StringInput `pulumi:"bucketName,optional"`
 Versioning *bool `pulumi:"versioning,optional"`
 Encryption *bool `pulumi:"encryption,optional"`
 Tags map[string]pulumi.StringInput `pulumi:"tags,optional"`
}

// SecureBucket is a component that creates an S3 bucket with security best practices
type SecureBucket struct {
 pulumi.ResourceState

 BucketName pulumi.StringOutput `pulumi:"bucketName"`
}

// NewSecureBucket creates a new SecureBucket component
func NewSecureBucket(ctx *pulumi.Context, name string, args SecureBucketArgs, opts ...pulumi.ResourceOption) (*SecureBucket, error) {
 component := &SecureBucket{}
 err := ctx.RegisterComponentResource("mycomponents:index:SecureBucket", name, component, opts...)
 if err != nil {
 return nil, err
 }

 // Create an S3 bucket with best practices by default
 tags := pulumi.StringMap{
 "ManagedBy": pulumi.String("Pulumi"),
 }
 if args.Tags != nil {
 for k, v := range args.Tags {
 tags[k] = v
 }
 }

 bucket, err := s3.NewBucketV2(ctx, name, &s3.BucketV2Args{
 Bucket: args.BucketName,
 Tags: tags,
 }, pulumi.Parent(component))
 if err != nil {
 return nil, err
 }

 // Conditionally enable versioning
 if args.Versioning != nil && !*args.Versioning {
 // Skip versioning
 } else {
 _, err = s3.NewBucketVersioningV2(ctx, name+"-versioning", &s3.BucketVersioningV2Args{
 Bucket: bucket.ID(),
 VersioningConfiguration: &s3.BucketVersioningV2VersioningConfigurationArgs{
 Status: pulumi.String("Enabled"),
 },
 }, pulumi.Parent(component))
 if err != nil {
 return nil, err
 }
 }

 // Conditionally enable encryption
 if args.Encryption != nil && !*args.Encryption {
 // Skip encryption
 } else {
 _, err = s3.NewBucketServerSideEncryptionConfigurationV2(ctx, name+"-encryption", &s3.BucketServerSideEncryptionConfigurationV2Args{
 Bucket: bucket.ID(),
 Rules: s3.BucketServerSideEncryptionConfigurationV2RuleArray{
 &s3.BucketServerSideEncryptionConfigurationV2RuleArgs{
 ApplyServerSideEncryptionByDefault: &s3.BucketServerSideEncryptionConfigurationV2RuleApplyServerSideEncryptionByDefaultArgs{
 SseAlgorithm: pulumi.String("AES256"),
 },
 },
 },
 }, pulumi.Parent(component))
 if err != nil {
 return nil, err
 }
 }

 component.BucketName = bucket.ID().ToStringOutput()
 return component, nil
}

package io.mikhail.components;

import com.pulumi.core.Output;
import com.pulumi.aws.s3.BucketV2;
import com.pulumi.aws.s3.BucketV2Args;
import com.pulumi.aws.s3.BucketVersioningV2;
import com.pulumi.aws.s3.BucketVersioningV2Args;
import com.pulumi.aws.s3.inputs.BucketVersioningV2VersioningConfigurationArgs;
import com.pulumi.aws.s3.BucketServerSideEncryptionConfigurationV2;
import com.pulumi.aws.s3.BucketServerSideEncryptionConfigurationV2Args;
import com.pulumi.aws.s3.inputs.BucketServerSideEncryptionConfigurationV2RuleArgs;
import com.pulumi.aws.s3.inputs.BucketServerSideEncryptionConfigurationV2RuleApplyServerSideEncryptionByDefaultArgs;
import com.pulumi.resources.ComponentResource;
import com.pulumi.resources.ComponentResourceOptions;
import com.pulumi.resources.CustomResourceOptions;
import com.pulumi.core.annotations.Export;
import java.util.Map;
import java.util.HashMap;
import java.util.List;

public class SecureBucket extends ComponentResource {
 @Export
 public final Output<String> bucketName;

 public SecureBucket(String name, SecureBucketArgs args, ComponentResourceOptions options) {
 super("mycomponents:index:SecureBucket", name, options);

 // Create an S3 bucket with best practices by default
 Map<String, Output<String>> tags = new HashMap<>();
 tags.put("ManagedBy", Output.of("Pulumi"));
 if (args.tags() != null && !args.tags().isEmpty()) {
 tags.putAll(args.tags());
 }

 var bucket = new BucketV2(name, BucketV2Args.builder()
 .bucket(args.bucketName())
 //.tags(tags)
 .build(),
 CustomResourceOptions.builder().parent(this).build());

 // Conditionally enable versioning
 if (args.versioning() != Boolean.FALSE) {
 new BucketVersioningV2(name + "-versioning", BucketVersioningV2Args.builder()
 .bucket(bucket.id())
 .versioningConfiguration(BucketVersioningV2VersioningConfigurationArgs.builder()
 .status("Enabled")
 .build())
 .build(),
 CustomResourceOptions.builder().parent(this).build());
 }

 // Conditionally enable encryption
 if (args.encryption() != Boolean.FALSE) {
 new BucketServerSideEncryptionConfigurationV2(name + "-encryption",
 BucketServerSideEncryptionConfigurationV2Args.builder()
 .bucket(bucket.id())
 .rules(List.of(BucketServerSideEncryptionConfigurationV2RuleArgs.builder()
 .applyServerSideEncryptionByDefault(
 BucketServerSideEncryptionConfigurationV2RuleApplyServerSideEncryptionByDefaultArgs.builder()
 .sseAlgorithm("AES256")
 .build())
 .build()))
 .build(),
 CustomResourceOptions.builder().parent(this).build());
 }

 this.bucketName = bucket.id();

 this.registerOutputs(Map.of(
 "bucketName", this.bucketName
 ));
 }
}

package io.mikhail.components;

import com.pulumi.core.Output;
import com.pulumi.resources.ResourceArgs;
import com.pulumi.core.annotations.Import;

import java.util.Map;
import java.util.HashMap;

public class SecureBucketArgs extends ResourceArgs {
 @Import(name="bucketName")
 private Output<String> bucketName;

 public Output<String> bucketName() {
 return this.bucketName;
 }

 @Import(name="versioning")
 private Boolean versioning;

 public Boolean versioning() {
 return this.versioning;
 }

 @Import(name="encryption")
 private Boolean encryption;

 public Boolean encryption() {
 return this.encryption;
 }

 @Import(name="tags")
 private Map<String, Output<String>> tags = new HashMap<>();

 public Map<String, Output<String>> tags() {
 return this.tags;
 }

 private SecureBucketArgs() {}

 public SecureBucketArgs(Output<String> bucketName, Boolean versioning, Boolean encryption, Map<String, Output<String>> tags) {
 this.bucketName = bucketName;
 this.versioning = versioning;
 this.encryption = encryption;
 this.tags = tags;
 }
}

# YAML doesn't directly support authoring complex components
# For a complete component, you'd typically write it in another language
# This is a simplified component without conditionals or tags merges
runtime: yaml
name: my-components
components:
 SecureBucket:
 inputs:
 bucketName:
 type: string
 resources:
 bucket:
 type: aws:s3/bucketV2:BucketV2
 properties:
 bucket: ${bucketName}
 tags:
 ManagedBy: Pulumi

 bucketVersioning:
 type: aws:s3/bucketVersioningV2:BucketVersioningV2
 properties:
 bucket: ${bucket.id}
 versioningConfiguration:
 status: Enabled

 bucketEncryption:
 type: aws:s3/bucketServerSideEncryptionConfigurationV2:BucketServerSideEncryptionConfigurationV2
 properties:
 bucket: ${bucket.id}
 rules:
 - applyServerSideEncryptionByDefault:
 sseAlgorithm: AES256

 outputs:
 bucketName: ${bucket.id}

The PulumiPlugin.yaml File

The PulumiPlugin.yaml file tells Pulumi that this directory is a component package that can be consumed across languages (it is not required for a single language component), rather than a standard Pulumi program. In it, you define the language runtime needed to load the plugin:

runtime: nodejs

runtime: python

runtime: dotnet

runtime: go

runtime: java

runtime: yaml

For other languages, you’d use the appropriate runtime value. This file is the key that enables Pulumi to generate SDKs in other languages from your component code.

Define an Entry Point

The entrypoint analyzes components to automatically build a schema, and interact with the Pulumi engine to manage the component lifecycle.

No separate entry point is required for TypeScript. All exported component classes will automatically be exposed to be consumed from other languages.

Create a _main_.py file in your component directory
In the main function, add a call to component_provider_host, specifying a list of components for the components argument

from pulumi.provider.experimental import component_provider_host
from staticpage import MyComponent

if __name__ == "__main__":
 component_provider_host(name="python-components", components=[MyComponent])

Define a main.go file
Declare an instance of NewProviderBuilder, passing in a name, namespace and the components being built

The code below uses the new pulumi-go-provider v1 APIs. Make sure you are using the latest version of github.com/pulumi/pulumi-go-provider.

package main

import (
 "context"

 "github.com/pulumi/pulumi-go-provider/infer"
)

func main() {
 prov, err := infer.NewProviderBuilder().
 WithNamespace("your-org-name").
 WithComponents(
 infer.ComponentF(NewSecureBucket),
 ).
 Build()
 if err != nil {
 panic(err)
 }

 _ = prov.Run(context.Background(), "go-components", "v0.0.1")
}

Create a Program.cs file
Add an entry point that calls the ComponentProviderHost

using System.Threading.Tasks;

class Program
{
 public static Task Main(string []args) =>
 Pulumi.Experimental.Provider.ComponentProviderHost.Serve(args);
}

Create an App.java file
Create a new instance of ComponentProviderHost in the entry point

package com.example.components;

import java.io.IOException;
import com.pulumi.provider.internal.Metadata;
import com.pulumi.provider.internal.ComponentProviderHost;

public class App {
 public static void main(String[] args) throws IOException, InterruptedException {
 new ComponentProviderHost("java-components", App.class.getPackage()).start(args);
 }
}

No separate entry point is required for YAML.

Pulumi Components new capability is designed to make sharing infrastructure building blocks as easy as possible, whether you’re publishing them to a Git repository or referencing them from a local folder in a monorepo.

Publishing to Git

Once you’ve authored your component, sharing it is as simple as pushing your code to a Git repository and optionally tagging a release. From there, anyone (including you) can pull it down and use it in their own Pulumi projects.

For example, after pushing your SecureBucket to GitHub and tagging it as v1.0.0, others can consume it by running:

pulumi package add github.com/myorg/secure-s3-component@v1.0.0

Under the hood, Pulumi:

Fetches your code from GitHub
Auto-generates a local SDK from the component’s schema
Makes it available to your Pulumi program in your chosen language

Referencing Components Locally

For scenarios like monorepos, rapid development iterations, or when you’re working with components that don’t need to be published to a repository, you can reference local source code directly:

pulumi package add ./components/secure-s3-component

Pulumi will identify the folder as a Pulumi component project, generate a local SDK, and make it available for import in your program—even if your consumer program is in a different language. Both relative paths (as shown above) and absolute paths (like /path/to/local/secure-s3-component) are supported, giving you flexibility for different project layouts.

Consuming Components Across Languages

The real power comes in how these components can now be consumed in any Pulumi language:

import * as pulumi from "@pulumi/pulumi";
import { SecureBucket } from "@myorg/secure-s3-component";

const secureBucket = new SecureBucket("my-secure-bucket", {
 bucketName: "my-company-secure-assets",
 tags: {
 Environment: "production",
 Department: "engineering",
 },
});

export const bucketName = secureBucket.bucketName;

import pulumi
from myorg_secure_s3_component import SecureBucket

secure_bucket = SecureBucket("my-secure-bucket",
 bucket_name="my-company-secure-assets",
 tags={
 "Environment": "production",
 "Department": "engineering",
 })

pulumi.export("bucket_name", secure_bucket.bucket_name)

using System.Collections.Generic;
using Pulumi;
using MyOrg.SecureS3Component;

return await Deployment.RunAsync(() =>
{
 var tags = new Dictionary<string, string>
 {
 { "Environment", "production" },
 { "Department", "engineering" }
 };

 var secureBucket = new SecureBucket("my-secure-bucket", new SecureBucketArgs
 {
 bucketName = "my-company-secure-assets",
 Tags = tags
 });

 // Export the bucket name
 return new Dictionary<string, object?>
 {
 ["BucketName"] = secureBucket.BucketName
 };
});

package main

import (
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
 secure "github.com/myorg/secure-s3-component/sdk/go/secure-s3-component"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 tags := make(map[string]string)
 tags["Environment"] = "production"
 tags["Department"] = "engineering"

 secureBucket, err := secure.NewSecureBucket(ctx, "my-secure-bucket", &secure.SecureBucketArgs{
 BucketName: pulumi.String("my-company-secure-assets"),
 Tags: pulumi.ToStringMap(tags),
 })
 if err != nil {
 return err
 }

 ctx.Export("bucketName", secureBucket.BucketName)
 return nil
 })
}

package mypackage;

import com.pulumi.Pulumi;
import com.pulumi.core.Output;
import com.myorg.secures3component.SecureBucket;
import com.myorg.secures3component.SecureBucketArgs;

import java.util.Map;

public class App {
 public static void main(String[] args) {
 Pulumi.run(ctx -> {
 var tags = Map.of(
 "Environment", "production",
 "Department", "engineering"
 );

 var bucketArgs = SecureBucketArgs.builder()
 .bucketName("my-company-secure-assets")
 .tags(tags)
 .build();

 var secureBucket = new SecureBucket("my-secure-bucket", bucketArgs);

 ctx.export("bucketName", secureBucket.bucketName());
 });
 }
}

name: my-infrastructure
runtime: yaml
description: A stack that uses SecureBucket component

packages:
 secure-s3-component: github.com/myorg/secure-s3-component@v1.0.0

resources:
 secureBucket:
 type: secure-s3-component:SecureBucket
 properties:
 bucketName: my-company-secure-assets
 tags:
 Environment: production
 Department: engineering

outputs:
 bucketName: ${secureBucket.bucketName}

See It In Action

Check out this video of authoring components in Java and consuming them in YAML to see Pulumi Components in action:

Build reusable infrastructure components

Author a component once in your preferred language, then let your teams consume it from TypeScript, Python, Go, or YAML with Pulumi.

Get started

Pro Tips

Tagging Releases: If you’re working with Git-based components, you can tag version releases (both stable and preview versions). This ensures downstream users can easily choose specific versions without chasing a moving target.
Managing Dependencies: Once you’ve added an entry to the packages section of your Pulumi.yaml file, you can run pulumi install to generate a local SDK in your project. This command will process all packages listed in your Pulumi.yaml and create the necessary SDK files. Check in these files if you want fully reproducible builds; or add them to .gitignore if you prefer to regenerate them on each checkout. When using .gitignore, team members will need to run pulumi install after checkout to regenerate the SDK.
Leveraging Private Repos: If you need to keep your components private, you can still point to a Git source in a private repository. Just make sure the correct access tokens are set in the environment as described in our package management documentation.

The Spectrum of Pulumi Components You Can Build

You can use Pulumi Components with more flexibility and control depending on your use case. This table shows the variety of use cases:

Feature	Single language	Multi-language with Auto-Generated SDKs	Manual Schema and SDKs
Best for	Quick development within a single language ecosystem	Cross-language teams needing to share components	More flexibility and control needed or strict API requirements
Cross-language consumption	No - limited to original language	Yes - consume in any Pulumi language	Yes - consume in any Pulumi language
Setup complexity	Minimal - standard programming patterns	Minimal - just requires package management	High - requires schema authoring and validation
Development workflow	Fast iteration with direct code changes	Fast, requires SDK regeneration when component changes	Complex with schema updates and SDK publishing
API control	Full control within your language	Moderate - auto-generated from source	Full - ship the same interface to all consumers
Version management	Simple - standard code versioning	Moderate - requires careful API changes	Complex - strict semantic versioning needed
Typical user	Individual developers or same-language teams	Platform teams sharing with developers	Enterprise teams with strict requirements or package publishers
Ideal use cases	• Rapid prototyping • Single team projects • Simple components	• Organization-wide libraries • Platform engineering • Multi-language environments	• Published packages • Complex validation needs
Limitations	• Single language only • No additional setup required	• SDK regeneration overhead • Runtime dependencies • Some translation limitations	• Complex setup • Steep learning curve • Slower iteration

Conclusion

The ability to author components in one language and consume them in any other Pulumi language—including YAML—provides unprecedented flexibility and collaboration opportunities between platform teams and application developers.

To learn more about Pulumi Components, check out our documentation on components, building a component, packaging and publishing components, and component schemas.

We’re excited to see what you build with Pulumi Components! Share your feedback with us on the Pulumi Community Slack or open an issue in the pulumi/pulumi GitHub repository.

Expanding the Pulumi Registry: 27 New Providers to Expand the Ecosystem

Meagan Cojocar — Tue, 18 Mar 2025 00:00:00 +0000

Pulumi is excited to announce the addition of 27 new providers to the Pulumi Registry, significantly expanding our ecosystem and empowering developers with more choices for infrastructure as code. This expansion includes providers like Temporal, Vantage, and Honeycomb, among many others, making it even easier to manage diverse cloud and SaaS services with Pulumi.

This milestone is made possible by Pulumi’s new ability to use any Terraform provider (bridging existing Terraform providers for use in Pulumi), as detailed in our recent blog post. Since that announcement, Pulumi users have already begun to use many of the new infrastructure and SaaS providers that are now accessible within the familiar Pulumi programming model. To ensure the best developer experience, we’ve also added comprehensive documentation for 27 of these new providers directly in the Pulumi Registry. This means you can find everything you need right where you’re already spending time.

“Developers thrive on tools that seamlessly integrate into their existing build, test, and deployment workflows. That’s why we’re excited to have Temporal included in the Pulumi Registry—making it effortless to create and manage Temporal resources alongside other critical infrastructure using the programming languages developers already know and love.” - Jay Sivachelvan, VP of Partnerships - Temporal

This release represents just the first wave of our expanded provider documentation initiative. We’ve prioritized these initial 27 providers based on direct user and customer feedback. We’re committed to continuing this effort, with plans to add documentation for many more providers to the Pulumi Registry in the coming months. Our goal is to create the most comprehensive and user-friendly infrastructure as code ecosystem, making it even easier for you to manage your entire cloud infrastructure from a single platform.

This update is designed with developers in mind and features enriched documentation directly in the Registry, ensuring you have all the resources you need right at your fingertips. We’re also spotlighting a few partner providers:

Temporal – Manage Temporal Cloud as code.
Vantage – Gain cost visibility and optimize cloud spending.
Honeycomb – Seamlessly integrate observability best practices.
Timescale – Time series and real-time analytics on PostgreSQL.

“Timescale Cloud brings high-performance PostgreSQL to time-series, real-time analytics, and AI workloads, now with a seamless Pulumi integration. Developers can deploy and manage their infrastructure using their preferred language, making it easier than ever to scale PostgreSQL without resource-management headaches.” - Mike Freedman, CTO - Timescale

Full List of New Providers

Explore the complete list of new providers now available in the Pulumi Registry:

Dive into the comprehensive docs in the Registry, experiment with the new capabilities, and let us know what you build next.

Happy coding!

Pulumi + Gitlab: Better Than Ever

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

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

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

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

What’s New in Our GitLab Integration

Enhanced Merge Request Comments

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

These comments include:

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

To configure the GitLab integration:

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

GitLab as a First-Class VCS in Pulumi Cloud

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

This integration enables:

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

Organizational Templates in GitLab

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

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

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

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

Coming Soon: Pulumi Deployments for GitLab

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

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

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

Getting Started

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

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

Conclusion

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

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

Converting Terraform to Pulumi Just Got Easier

Brandon Pollack — Tue, 04 Mar 2025 00:00:00 +0000

Big news for infrastructure teams looking to migrate – we’ve significantly improved Pulumi’s Terraform conversion capabilities, making modernization smoother and reducing the amount of manual work usually required.

Pulumi already lets you use any Terraform/OpenTofu provider in your existing projects, and now we’ve taken it to the next level. With Pulumi CLI version 3.153.0 and above, you can now automatically convert ANY Terraform project to Pulumi and import its resources - even if it uses providers that don’t have native Pulumi equivalents!

This means you can finally:

Convert your entire Terraform codebase without provider limitations
Maintain access to the Terraform providers you leverage
Modernize your infrastructure deployment while keeping your existing resources

Try It Now: Use ‘pulumi convert’

Ready to give it a spin? After installing the latest Pulumi CLI, you can start the conversion with:

pulumi convert --from terraform --language nodejs

pulumi convert --from terraform --language typescript

pulumi convert --from terraform --language python

pulumi convert --from terraform --language go

pulumi convert --from terraform --language java

pulumi convert --from terraform --language yaml

This will download the necessary plugins, run the conversion and output it in the current directory, generating all necessary project files.

You can then run pulumi preview to see if the project can deploy successfully.

See It In Action: A Real-World Example

Let’s look at something cool – we’ll convert a project that combines Google Cloud with PlanetScale (a provider that isn’t available in the Pulumi registry yet!). This example shows how the new converter can handle mixed provider scenarios with far less manual setup than before.

Here is the Terraform code in a single main.tf file:

terraform {
 required_version = ">= 1.1.0"

 required_providers {
 google = {
 source = "hashicorp/google"
 version = "~> 6.0"
 }
 planetscale = {
 source = "planetscale/planetscale"
 version = "~> 0.1.0"
 }
 }
}

# Configure the google provider using the project variables below.
provider "google" {
 project = var.gcp_project
 region = var.gcp_region
 zone = var.gcp_zone
}

provider "planetscale" {
 service_token = var.planetscale_service_token
 service_token_name = "planetscaletoken"
}

variable "gcp_project" {
 description = "GCP project ID"
 default = "pulumi-convert-example-gcp-project"
}

variable "gcp_region" {
 description = "GCP region to use"
 default = "us-central1"
}

variable "gcp_zone" {
 description = "GCP zone"
 default = "us-central1-a"
}

variable "planetscale_org" {
 description = "PlanetScale organization name"
 default = "pulumi-convert-planetscale-org"
}

variable "planetscale_service_token" {
 description = "PlanetScale service token secret"
 sensitive = true
 default = "test-planetscale-service-token"
}

# Create the PlanetScale database
resource "planetscale_database" "db" {
 name = "pulumi-convert-db"
 organization = var.planetscale_org
}

# Generate a password for connecting to the DB
resource "planetscale_password" "db_password" {
 organization = "brandonpollack23"
 name = "terraform-generated"
 database = planetscale_database.db.name
 branch = planetscale_database.db.default_branch
}

# Spin up a small GCE VM
resource "google_compute_instance" "vm" {
 name = "demo-vm"
 machine_type = "e2-micro"
 zone = var.gcp_zone

 # Minimal Debian boot disk
 boot_disk {
 initialize_params {
 image = "debian-cloud/debian-11"
 }
 }

 # Use the default VPC with a public IP
 network_interface {
 network = "default"
 access_config {}
 }

 # Pass PlanetScale connection info as metadata
 metadata = {
 DB_HOST = planetscale_database.db.url
 DB_USER = "root"
 DB_PASS = planetscale_password.db_password.plaintext
 DB_NAME = planetscale_database.db.name
 }
}

Never store secrets or keys in plain text in your code or configuration files committed to a code repository. We are only storing a db_password here in plain text for the sake of readability.

Consider using Pulumi ESC to store these types of secrets (and any other configuration!) and access them directly from your Pulumi programs or as environment variables with the CLI.

Note that while this program will terraform plan successfully, you’ll need real credentials in order to actually apply and deploy it. You can set these in .tfvars, environment variables, or on the command line, for instance.

We’ll convert this into a new Pulumi project with the following command:

pulumi convert --from terraform --language typescript --out pulumi-ts-program

Here we’ve opted to output generated code to a different directory (pulumi-ts-program) to preserve the contents of our Terraform project.

Project structure

If we navigate to the pulumi-ts-program directory, we can see a few things:

Pulumi.yaml, the Pulumi configuration file.
index.ts, our equivalent to main.tf for TypeScript projects.
An sdks directory, where generated code for providers not in the Pulumi registry (in this case, planetscale) has been placed.
Other Node.js project artifacts such as package.json, node_modules, tsconfig.json, and so on.

pulumi convert --from terraform --language python --out pulumi-python-program

Here we’ve opted to output generated code to a different directory (pulumi-python-program) to preserve the contents of our Terraform project.

Project structure

If we navigate to the pulumi-python-program directory, we can see a few things:

Pulumi.yaml, the Pulumi configuration file.
__main__.py, our equivalent to main.tf for Python projects.
An sdks directory, where generated code for providers not in the Pulumi registry (in this case, planetscale) has been placed.
Other Python project artifacts such as requirements.txt or pyproject.toml.

pulumi convert --from terraform --language go --out pulumi-go-program

Here we’ve opted to output generated code to a different directory (pulumi-go-program) to preserve the contents of our Terraform project.

Project structure

If we navigate to the pulumi-go-program directory, we can see a few things:

Pulumi.yaml, the Pulumi configuration file.
main.go, our equivalent to main.tf for Go projects.
An sdks directory, where generated code for providers not in the Pulumi registry (in this case, planetscale) has been placed.
Other Go project artifacts such as go.mod and go.sum.

Go-specific cleanup

Pulumi’s Go code generation currently produces code for everything in the Terraform code, even if it is unused. This is an error in a Go program, so we’ll have to rename variables such as gcpProject, region, and planetscaleServiceToken to the special _ identifier in order to avoid compilation errors. We plan on continuing to polish the Go experience to remove manual steps like this.

pulumi convert --from terraform --language java --out pulumi-java-program

Here we’ve opted to output generated code to a different directory (pulumi-java-program) to preserve the contents of our Terraform project.

Project structure

If we navigate to the pulumi-java-program directory, we can see a few things:

Pulumi.yaml, the Pulumi configuration file.
An App.java file under the src/main/java/generated_program directory, our equivalent to main.tf for Java projects.
An sdks directory, where generated code for providers not in the Pulumi registry (in this case, planetscale) has been placed.
Other Java project artifacts such as pom.xml.

Java-specific cleanup

Pulumi’s Java code generation currently does not set up Maven project dependencies for you when generating SDKs for Terraform providers not in the Pulumi registry. As a result you will need to follow the printed instructions and copy the relevant SDK code into your source directory:

cp -r sdks/planetscale/src/* src/

You might also notice that the generated Java code is using the wrong overload for setting the metadata in our GCP instance to set environment variables. We can fix this by modifying the relevant calls to invoke toString on the values being passed:

.metadata(Map.ofEntries(
- Map.entry("DB_HOST", db.url()),
+ Map.entry("DB_HOST", db.url().toString()),
 Map.entry("DB_USER", "root"),
- Map.entry("DB_PASS", dbPassword.plaintext()),
+ Map.entry("DB_PASS", dbPassword.plaintext().toString()),
- Map.entry("DB_NAME", db.name())
+ Map.entry("DB_NAME", db.name().toString())
))

While Pulumi’s code generation does its best to infer the correct types from what can be quite dynamic Terraform code, there are some cases like these where manual intervention is required. We plan on continuing to polish the Java experience to remove work like this.

pulumi convert --from terraform --language yaml --out pulumi-yaml-program

Here we’ve opted to output generated code to a different directory (pulumi-yaml-program) to preserve the contents of our Terraform project.

Project structure

If we navigate to the pulumi-yaml-program directory, we can see a few things:

Pulumi.yaml, the Pulumi configuration file.
Main.yaml, our equivalent to main.tf for YAML projects.
An sdks directory, where generated code for providers not in the Pulumi registry (in this case, planetscale) has been placed.

Configuration

While our project’s code is now ready to go, if we simply run pulumi up things won’t work right away. We first need to create a stack configuration containing our GCP and PlanetScale credentials (you may have noticed some warnings to the tune of warning: /Users/PulumiUser/src/MyAwesomeProject/deployment/main.tf:16,1-18: Failed to evaluate provider config; Could not evaluate expression for gcp:project that indicate these configuration values need to be set up in Pulumi). This is akin to using e.g. .tfvars files in Terraform.

Pulumi has generated placeholders in the Pulumi.yaml file for these values, so we just need to fill them in:

name: terraform-convert-example
runtime: nodejs
config:
 gcp:project:
 value: 'TODO: var.gcp_project' # fill in here
 gcp:region:
 value: 'TODO: var.gcp_region'
 gcp:zone:
 value: 'TODO: var.gcp_zone'
 planetscale:serviceToken:
 value: 'TODO: var.planetscale_service_token'
 planetscale:serviceTokenName:
 value: planetscaletoken

After replacing all the placeholders we have something like this:

name: terraform-convert-example
runtime: nodejs
config:
 gcp:project:
 value: 'brandonpollack23'
 gcp:region:
 value: 'us-central1'
 gcp:zone:
 value: 'us-central1-a'
 planetscale:serviceToken:
 value: 'supersecrettoken'
 planetscale:serviceTokenName:
 value: planetscaletoken

Once again—and it is worth reiterating—never, ever store secrets or keys in plain text in your code or configuration files committed to a code repository. Even in a private repository, certain secrets might not be something everyone with access to the source in your repository should have access to. Consider using Pulumi ESC to store these types of secrets, or consult the documentation on Pulumi’s rich set of built-in features for working with secrets and encrypted configuration values.

Now we can run pulumi preview to see the proposed updates. With real credentials, we can follow that command with pulumi up to deploy our infrastructure.

Of course, the code generated by pulumi convert is just a starting point – from here there is so much more that we can do! Here are some suggestions:

Abstract functionality that is shared, perhaps by extracting it into reusable functions or classes.
Consider moving any functions that you will use in different infrastructure projects to a shared dependency or a Component Resource.
Customize your infrastructure however you need: consolidate functionality from development scripts, read data from files and services, and more! You can do anything the language can do because a Pulumi program is just a program!

Importing Resources from Any Terraform Provider

With the release of Pulumi 3.153.0, we have also added the ability to import resources from any Terraform provider. See the documentation for pulumi import for more details. As an example, let’s import a resource from Backblaze, a block storage service that doesn’t have a native Pulumi provider:

First, we’ll create our application keys on the Backblaze portal.

Next, we’ll run terraform apply on the following main.tf file to create some infrastructure that we can later import into Pulumi:

terraform {
 required_version = ">= 1.0.0"
 required_providers {
 b2 = {
 source = "Backblaze/b2"
 }
 }
}

provider "b2" {
 application_key_id = "YOUR_KEY_ID"
 application_key = "YOUR_KEY"
}

resource "b2_bucket" "example_bucket" {
 bucket_name = "pulumi-import-test"
 bucket_type = "allPublic"
}

From our Pulumi project, we’ll use Pulumi’s support for any Terraform provider to add Backblaze support to our project:
```
pulumi package add terraform-provider backblaze/b2
```

We can then configure the provider in our Pulumi stack by adding the appropriate keys to our Pulumi.yaml:

name: pulumi_project
description: A minimal AWS TypeScript Pulumi program
runtime:
 name: nodejs
 options:
 packagemanager: npm
config:
 pulumi:tags:
 value:
 pulumi:template: aws-typescript
 b2:applicationKeyId:
 value: 'YOUR_KEY_ID'
 b2:applicationKey:
 value: 'YOUR_KEY'

To import a resource, we’ll need both its Pulumi type and the internal ID used by the cloud provider (here, Backblaze) to identify the resource. We’ll start with the Pulumi type, which we can find by inspecting the provider’s schema:
```
pulumi package get-schema terraform-provider backblaze/b2
```
Inside the JSON response we can find the resources section and from here extract the type corresponding to the resource we want to import. In this case, the type we’re after is b2:index/bucket:Bucket.

For the internal provider ID, we can exploit the fact that this is part of the Terraform state and use the terraform show command to find it.

With all the pieces in hand, we run pulumi import:

pulumi import "b2:index/bucket:Bucket" example_bucket "YOUR_BUCKET_ID"

During the import Pulumi generates code for you to add to your project that will allow you to manage the newly imported resource as needed. By default, Pulumi will set the protect option when generating code, which prevents the resources from being deleted by Pulumi; you can use --protect=false to disable this.

Considerations

While Pulumi’s coverage of Terraform functionality is fairly mature at this point, some functions are still not fully implemented and may require manual intervention.
If you define your Terraform Module in a parent directory of your deployment code, you’ll encounter a known bug when converting. You can work around this issue by restructuring your Terraform code before starting a conversion.
Terraform programs are dynamically typed. When converting to a type-safe language such as TypeScript or Go, it may be necessary to use “catch-all” types such as any in TypeScript or interface{} in Go in order to capture the full range of behaviour supported by the source program.
Variables and configuration are not yet converted automatically, so .tfvars files etc will need to be manually converted into Pulumi stack configurations.
We have some improvements we’re still working on to make the code generation as seamless as possible, so expect more updates soon!
A large number of Terraform modules utilize the try function. We hope to tackle handling converting this (very dynamic) function soon – stay tuned!

What’s Really New Here? 🚀

Automatic Provider Bridging: The converter now automatically handles any Terraform provider, even ones without Pulumi equivalents
Increased Terraform Compatibility: As part of this effort, we’ve bumped up our coverage of built in Terraform functions to over 90% using code generation and our pulumi-std Provider
Improved Import Support: With Pulumi 3.153.0, you can now import resources from any Terraform provider
Seamless Integration: Generated code is designed to work out of the box for many cases, though some tweaking may still be needed, especially for complex or less common providers.

The Road Ahead

Stay tuned for even more improvements to make your infrastructure modernization journey smoother!

If you’re new to Pulumi, check out our getting started guide to get up and running in just a few minutes.

Pulumi Kubernetes Operator 2.0 is Now Generally Available!

Eron Wright — Thu, 20 Feb 2025 00:00:00 +0000

Today marks an exciting milestone as we announce the General Availability (GA) release of the Pulumi Kubernetes Operator 2.0! This release builds upon the foundation we laid during the beta phase, delivering a production-ready solution that transforms how teams manage their cloud infrastructure.

Learn more about the Pulumi Kubernetes Operator in our documentation

What Is the Pulumi Kubernetes Operator?

The Pulumi Kubernetes Operator brings infrastructure automation directly to your Kubernetes cluster. By treating your infrastructure as native Kubernetes resources, it enables teams to manage their entire cloud environment—from databases to DNS records—using familiar Kubernetes workflows and tools.

Imagine having a dedicated infrastructure automation engine running within your cluster, continuously ensuring your cloud resources stay in sync with your desired state. That’s exactly what the Pulumi Kubernetes Operator delivers, complete with the observability and control you need for production environments.

The Evolution to 2.0

Pulumi Kubernetes Operator 2.0 introduces a completely new architecture for running Pulumi programs. The key changes include:

Each Stack now runs in its own dedicated Workspace pod, rather than within the Operator pod
A new Workspace custom resource manages the Workspace pod lifecycle
Stack operations are coordinated through a new Update custom resource
The Stack custom resource API remains the primary interface, maintaining backward compatibility

This architecture delivers improved resource isolation, better secrets management, and flexible Workspace customization options. The pod-per-stack model ensures reliable resource allocation and clear operational boundaries for each deployment.

What’s New in GA?

The GA release introduces three powerful capabilities that give you more control over your deployments:

Enhanced Logging Control

You can now set the log verbosity level of the Pulumi CLI for any given stack or Workspace. This feature offers granular control over logging output, making debugging and fine-tuning your deployment process more efficient.

New Controller Events for Better Instrumentation

Additional controller events have been introduced to provide richer instrumentation and observability. These events offer improved insights into the operator’s behavior, enabling more effective monitoring of your infrastructure.

Workspace Reclaim Policy

Managing Workspace lifecycles is now even more flexible with the new workspaceReclaimPolicy field in the Stack specification. This enhancement allows you to define how workspace resources should be handled after stack deployment. The supported policies are:

Retain: Keeps the Workspace and its resources after deployment (default)
Delete: Automatically removes the Workspace once the stack is fully deployed

This gives you fine-grained control over resource cleanup and helps prevent workspace sprawl in your cluster.

See It in Action

Here’s an example that demonstrates how to deploy a Pulumi stack using the operator. This configuration creates a service account with appropriate permissions and defines a Stack resource that deploys a sample project from the Pulumi examples repository:

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

// Create a Kubernetes ServiceAccount for the Pulumi Workspace pod
const sa = new k8s.core.v1.ServiceAccount("random-yaml", {});

// Grant system:auth-delegator to the ServiceAccount
const crb = new k8s.rbac.v1.ClusterRoleBinding("random-yaml:system:auth-delegator", {
 roleRef: {
 apiGroup: "rbac.authorization.k8s.io",
 kind: "ClusterRole",
 name: "system:auth-delegator",
 },
 subjects: [{
 kind: "ServiceAccount",
 name: sa.metadata.name,
 namespace: sa.metadata.namespace,
 }],
});

// Provision a Pulumi Cloud access token and store it in a Kubernetes Secret
const accessToken = new pulumiservice.AccessToken("random-yaml", {
 description: `For stack "${pulumi.runtime.getOrganization()}/${pulumi.runtime.getProject()}/${pulumi.runtime.getStack()}"`,
});
const apiSecret = new k8s.core.v1.Secret("random-yaml", {
 stringData: {
 "accessToken": accessToken.value,
 }
});

// Deploy the "random-yaml" program from the github.com/pulumi/examples repository.
const stack = new k8s.apiextensions.CustomResource("random-yaml", {
 apiVersion: 'pulumi.com/v1',
 kind: 'Stack',
 spec: {
 serviceAccountName: sa.metadata.name,
 projectRepo: "https://github.com/pulumi/examples",
 repoDir: "random-yaml/",
 branch: "master",
 shallow: true,
 stack: "pulumi-ts",
 refresh: true,
 destroyOnFinalize: true,
 envRefs: {
 PULUMI_ACCESS_TOKEN: {
 type: "Secret",
 secret: {
 name: apiSecret.metadata.name,
 key: "accessToken",
 },
 },
 },
 workspaceTemplate: {
 spec: {
 image: "pulumi/pulumi:3.147.0-nonroot",
 },
 },
 },
}, {dependsOn: [sa, crb, apiSecret]});

Here’s an example of the enhanced event stream that shows the lifecycle of a stack deployment, from workspace creation to successful completion:

88s Normal SuccessfulCreate statefulset/random-yaml-09aa1aad-workspace create Pod random-yaml-09aa1aad-workspace-0 in StatefulSet random-yaml-09aa1aad-workspace successful
88s Normal StackUpdateDetected stack/random-yaml-09aa1aad Initial stack update
0s Normal Pulled pod/random-yaml-09aa1aad-workspace-0 Container image "pulumi/pulumi:3.147.0-nonroot" already present on machine
0s Normal Created pod/random-yaml-09aa1aad-workspace-0 Created container pulumi
0s Normal Started pod/random-yaml-09aa1aad-workspace-0 Started container pulumi
0s Normal Initialized workspace/random-yaml-09aa1aad Initialized workspace pod "random-yaml-09aa1aad-workspace-0"
0s Normal StackUpdateDetected stack/random-yaml-09aa1aad Initial stack update
0s Normal UpdateSucceeded update/random-yaml-09aa1aad-195200641a9 Updated stack "pulumi-ts"
0s Normal StackCreated stack/random-yaml-09aa1aad Successfully updated stack

Additional Resources

To help you get the most out of Pulumi Kubernetes Operator 2.0, we’ve prepared comprehensive documentation:

Migration Guide: Step-by-step instructions for upgrading from v1.x to v2.0
Troubleshooting Guide: Common issues and their solutions
Release Notes: Full details of what’s new in version 2.0

Start Using It Today

We are excited to see how you will use these new features to transform your cloud operations. Share your experiences, questions, and insights with us through our community forums or Slack channel.

Get started with the Pulumi Kubernetes Operator in our documentation

Happy deploying!

Pulumi Copilot is Now Available in VS Code

Meagan Cojocar — Mon, 03 Feb 2025 00:00:00 +0000

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

Programming languages offer dozens of advantages for writing Infrastructure as Code (IaC). One of them is that Large Language Models are effective at using general-purpose programming languages, thanks to the vast amount of high-quality training data available. Building on this advantage, we introduced Pulumi AI and Pulumi Copilot last year to enhance Infrastructure-as-Code development with generative AI capabilities. These tools have significantly streamlined infrastructure deployment for tens of thousands of developers.

Today, we are thrilled to announce that Pulumi Copilot is now available directly within Pulumi Copilot Chat Extension. By simply typing @pulumi in Copilot Chat, developers can now access the power of Pulumi Copilot right within their IDE, saving them time on writing IaC and getting infrastructure deployed.

Video Walk Through

Hear Adam and Eron from Pulumi walk through this new feature in our PulumiTV introduction to the Visual Studio Code extension.

What is Pulumi Copilot?

Pulumi Copilot is an AI-powered conversational assistant that seamlessly integrates with Pulumi Cloud, helping users:

Explore and manage cloud infrastructure
Gain insights into resources, policies, and deployments
Troubleshoot errors and optimize configurations
Author and deploy Pulumi IaC more effectively

Pulumi Copilot combines industry-leading AI models with Pulumi specific knowledge like the latest versions of providers, IaC best practices, and context from Pulumi Cloud on your environment.

The Pulumi Copilot REST API

The Pulumi Tools Visual Studio Code extension is powered by the recently announced Pulumi Copilot REST API, which enables developers to integrate Pulumi Copilot’s capabilities into their own tools and platforms. Just as we’ve built this extension to bring Pulumi Copilot directly into your development environment, you can use the same REST API to create your own innovative integrations, whether that’s a custom CLI tool, a chat bot, or another IDE extension. The API’s support for multi-turn conversations and contextual understanding makes it possible to build rich, interactive experiences like the one we’re delivering today.

How to Use Pulumi Copilot in Visual Studio Code

Using Pulumi Copilot in Visual Studio Code (VS Code) is as simple as 1-2-3:

Install the Pulumi VS Code extension
Open VS Code and navigate to Copilot Chat (icon to the right of the search bar)
Type @pulumi to activate Pulumi Copilot

You can then ask questions about your infrastructure, generate code, check deployment status, debug Pulumi errors, and more.

This seamless integration brings Pulumi’s intelligence directly into the developer workflow.

Pulumi Copilot respects all role-based access control (RBAC) settings in Pulumi Cloud, ensuring that AI-generated responses are scoped only to authorized users within an organization.

Key Use Cases

Let’s explore four powerful ways to use Pulumi Copilot in VS Code:

Infrastructure Code Generation

With Pulumi Copilot in VS Code, developers can generate Pulumi programs for new use cases, solving the blank page problem and getting you from 0 to 0.9.

Simply describe what you want to build and Pulumi Copilot will generate the infrastructure code for you. For example, ask “Create an AWS S3 bucket with versioning enabled and encrypted with a KMS key” and Copilot will generate the complete Pulumi program. Or ask Pulumi Copilot to extend an existing project such as adding a ManagedNodeGroup to your AWS EKS cluster.

Terraform to Pulumi Migration

Migrating from Terraform to Pulumi? Just point Copilot at your Terraform files and ask it to convert them. For example:

Open your main.tf file in VS Code
Type @pulumi convert this Terraform configuration to TypeScript
Copilot will analyze your Terraform code and generate equivalent Pulumi code in index.ts

The conversion maintains your existing resource configurations while taking advantage of Pulumi’s native programming language features.

Resource Discovery

Pulumi Copilot can search across your entire infrastructure to find resource usage patterns. Ask questions like “Do we use AWS Lambda functions in any other stacks?” or “Show me all S3 buckets with public access enabled.” Copilot will search your codebase and Pulumi Cloud to provide comprehensive answers about your infrastructure.

Error Resolution

When you encounter errors in the terminal during Pulumi operations, Copilot can help explain and resolve them. Simply copy the error message and ask Copilot to explain it. For example:

Error: Error creating S3 Bucket (my-bucket): BucketAlreadyExists: The requested bucket name is not available

Copilot will explain the error in plain language, suggest potential solutions, provide code examples for fixing the issue, and reference similar issues from your organization’s history.

Getting Started

Pulumi Copilot is free to use for all organizations in Pulumi Cloud. Organization administrators can enable Pulumi Copilot by navigating to: Settings > Access Management > Pulumi Copilot in the Pulumi Cloud console.

Try it now in VS Code and experience AI-driven cloud infrastructure management right in your IDE.

👉 Start Using Pulumi Copilot 👉 Start Using Pulumi Copilot in Visual Studio Code

We can’t wait to see what you build with Pulumi Copilot! 🚀

The Past 6 Months of Pulumi Releases

Meagan Cojocar — Tue, 24 Dec 2024 00:00:00 +0000

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

As we wrap up 2024, let’s look back at the significant features and improvements Pulumi has delivered in the last half of the year. Some key highlights:

Pulumi Visual Studio Code Extension
Pulumi ESC General Availability
Pulumi Insights 2.0 with Resource Explorer
Enhanced Kubernetes support

Pulumi Infrastructure as Code

Kubernetes Enhancements

Pulumi Kubernetes Operator 2.0 Major update introducing a horizontally scalable architecture, enhanced security features, and improved customization for the Pulumi Kubernetes Operator.
EKS Auto Mode A groundbreaking feature that simplifies EKS cluster management by automatically handling compute, storage, and networking configurations based on AWS’s operational expertise.
Pulumi EKS 3.0 Release Update introducing support for Amazon Linux 2023, Access Entries for IAM integration, EKS managed addons, and enhanced security features.
Pulumi Kubernetes Await Logic Better resource dependency tracking, improved error reporting, faster deletions with propagation policies, and custom readiness criteria support.

Provider Updates

Use Any Terraform Provider Automatic generation of Pulumi providers from any Terraform provider, dramatically expanding the ecosystem of available resources.
AWS CDK On Pulumi 1.0 Expanded compatibility with AWS CDK features and construct hub integration, allowing developers to continue using familiar AWS CDK patterns within Pulumi.
Azure v6 Release Major update ensuring compatibility with the latest Azure services, improved error messages, and new resource types.
Google Cloud Provider v8.0.0 Comprehensive support for new Google Cloud services and improved resource management capabilities.
AWS Cloud Control Provider GA Native AWS API support with day-zero coverage for new AWS features and improved consistency in resource management.

Core Platform Features

Pulumi Visual Studio Code Extension Enhanced IaC debugging in the IDE, Pulumi YAML support, and ESC management within VS Code.
Pulumi Docker Image Improvements Versioned images with pre-installed tools for Python, Node.js, and .NET. Pulumi Deployments now supports setting the version of the Node.js and Python runtimes used in the Deployment environment.
Python UV Support Built-in support for uv, an extremely fast Python package manager that speeds up dependency installation by up to 100x compared to traditional tools.
DependsOn for Provider Functions Manage explicit dependencies between provider functions for more accurate execution in complex deployments.

Pulumi Environments, Secrets and Configuration (Pulumi ESC)

General Availability & Key Enhancements

ESC General Availability GA of Pulumi ESC - redefining secrets management with features like dynamic credentials, hierarchical environments, a secrets broker with external stores like AWS Secrets Manager, and Kubernetes operators for runtime integration.
ESC Projects & Environment Tags Organize secrets and configurations at scale with new grouping capabilities.
ESC Webhooks Real-time notifications and automated actions based on environment changes.
AWS Parameter Store Integration Native integration with AWS Systems Manager Parameter Store for seamless import of parameters and secrets into ESC environments.
Environment Import Discovery Enhanced visibility into environment dependencies with new features to track downstream usage, version tags, and impact analysis for configuration changes.

Deployment Improvements

Dependency Caching Speed up deployments by up to 80% by caching dependencies between runs, with support for npm, pip, and go modules.
Kubernetes-native Agent Purpose-built agent for Kubernetes environments, enabling self-hosted deployment agents within your Kubernetes clusters without requiring Docker in Docker or privileged execution.

Pulumi AI and Insights

Pulumi Insights 2.0

Resource Explorer Enhanced visual interface for exploring cloud resources with new features like customizable columns, nested grouping capabilities, advanced filtering, and shareable saved views across your organization.
Account Discovery Preview New capability to discover and manage all cloud resources regardless of how they were created, with AI-powered search and comprehensive resource visibility across your infrastructure.

Pulumi Copilot Enhancements

REST API Integration: Enabling programmatic access to Pulumi Copilot’s AI capabilities through a REST API, supporting multi-user interactions, automation of queries, and integration with workplace collaboration platforms.
System Prompts: New organization-level customization allowing teams to set default preferences for programming languages, cloud providers, compliance guidelines, and infrastructure standards.
One-Click Update Analysis: Debug failed updates instantly with Copilot by analyzing logs and suggesting fixes directly from the update page or from the CLI.
Documentation Integration: Integrated throughout Pulumi’s website and documentation, providing contextual assistance and documentation search capabilities to help users find relevant resources and answers to their questions.

Pulumi Cloud Console Improvements

Organization-wide Policies New centralized Policy Violations page providing comprehensive visibility of compliance across projects, with the ability to group violations by Policy Pack, Project, Stack, and Resource, plus API access for automation.
Stacks Page Redesign Major redesign offering improved performance with thousands of stacks, flexible grouping up to three levels, enhanced sorting options, shareable views via URL parameters, and personalized preferences that persist between sessions.

That’s a wrap for July through December 2024! From major IaC updates to advanced Pulumi ESC features to the launch of Pulumi Insights 2.0 and powerful AI integrations, Pulumi continues to innovate across the cloud engineering space. Be sure to check out the linked blog posts and docs for more details on each release. Happy building!

Pulumi Copilot is Now Integrated with Pulumi Docs: A New Way to Learn and Explore

Meagan Cojocar — Thu, 24 Oct 2024 23:59:00 -0700

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

Pulumi Copilot has been making our customers’ day-to-day tasks easier since its release, and today we’re excited to expand its capabilities—Pulumi Copilot is now available across Pulumi Documentation and pulumi.com, and comes equipped with a powerful new Documentation Skill!

These additions make learning about Pulumi more interactive and intuitive by allowing users to explore cloud infrastructure concepts directly within the documentation through a conversational interface. Whether you’re a seasoned Pulumi user or just starting out, Pulumi Copilot is here to help you when you need it most, where you need it most.

New Enhancements in Pulumi Copilot

Expanded Website Integration

Pulumi Copilot is now embedded throughout the Pulumi website, providing contextual assistance no matter where you are. Whether you’re exploring documentation, reading a blog post, browsing the Pulumi registry, or reviewing case studies, Pulumi Copilot offers helpful suggestions, explanations, and links to guide you to relevant resources.

Pulumi Documentation Skill

The new Documentation Skill is designed to make Pulumi’s docs more accessible from wherever. You can ask questions like “How do I use the dependsOn resource option?” or “How do I use SAML in my organization?" or “How can I store and retrieve secrets using Pulumi ESC?” and Pulumi Copilot will answer them by searching through our documentation on your behalf. This new skill is available everywhere Pulumi Copilot is: in Pulumi Cloud, in Pulumi documentation, across the Pulumi website, and the Registry.

Try Pulumi Copilot Today

Pulumi Copilot’s new Documentation Skill and website integration are available now! These features are free to use today. You can unlock more messages by being logged in to Pulumi Cloud.

To get started, visit the Pulumi Cloud console and enable Pulumi Copilot in your settings under Access Management.

Pulumi Copilot is already making waves, and with these latest enhancements, it’s now easier than ever to manage and learn about your cloud infrastructure. We can’t wait for you to experience it firsthand!

Enhancing Pulumi Copilot: Introducing System Prompts for Your Organization

Meagan Cojocar — Thu, 10 Oct 2024 00:00:00 -0700

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

We are excited to announce a new feature for Pulumi Copilot: System Prompts. This enhancement empowers organizations to customize Pulumi Copilot’s responses for your organization, making your interactions with our AI assistant even more personalized to save you even more time.

Pulumi Copilot is a conversational chat interface integrated throughout Pulumi Cloud, enabling users to quickly accomplish a variety of cloud infrastructure management tasks by leveraging the power of large language models plus the rich capabilities of Pulumi Cloud. We released Pulumi Copilot in June this year, and have seen remarkable uptake across our customer base. We are excited to be announcing enhancements on the Pulumi Copilot experience- keep an eye out for more to come in the near future.

System prompts allow organization administrators to set default preferences and guidelines for Pulumi Copilot. By configuring these prompts, you can tailor Pulumi Copilot’s behavior to better suit your team’s needs and policies. Here are some ways you might use organization system prompts:

Set a Default Programming Language: Ensure that all code snippets and examples provided by Pulumi Copilot are in your team’s preferred language.
Specify a Default Cloud Provider: Streamline resource searches and code generation by focusing on your primary cloud environment. Specify providers your organization prefers to use, such as using Azure Native instead of Azure Classic.
Enforce Compliance Guidelines: Instruct Copilot to generate code and provide guidance that adheres to specific compliance standards, such as SOC 2.
Standardize Infrastructure Components: Provide example code templates for resources to ensure consistency across your organization’s projects, such as “here is how we create VPCs”

How to Set Organization System Prompts

Setting up system prompts is straightforward:

Log in to Pulumi Cloud and go to your organization’s settings in the left hand navigation
Under the settings menu, select “Access Management.”
In the Copilot section, you’ll find the option to set your system prompts.

Though the system prompt supports 10k characters of context, we recommend keeping it concise to ensure optimal performance. See more information on setting system prompts in our Pulumi Copilot documentation.

Wrapping it up

This is just the beginning. We’re dedicated to making Pulumi Copilot an indispensable part of your cloud infrastructure management toolkit. Stay tuned for more updates and enhancements based on your feedback.

If you have suggestions or encounter any issues, please let us know through our Pulumi Cloud requests GitHub repository.

Announcing the Pulumi Visual Studio Code Extension

Meagan Cojocar — Wed, 18 Sep 2024 08:56:00 +0000

At the heart of Pulumi’s approach to cloud infrastructure and secrets management is a belief in empowering engineers to use the best software engineering tools to manage complexity at scale and to be maximally productive building cloud infrastructure and applications for their businesses.

Today, we’re excited to announce a next big step in delivering great software engineering tools for Pulumi users, with the launch of a new Pulumi Visual Studio Code (VS Code) Extension. The Pulumi VS Code Extension brings Pulumi key features for Pulumi IaC and Pulumi ESC directly into the IDE environment that many Pulumi users work in every day. Pulumi IaC users can now debug their applications and get Pulumi YAML language support directly in VS Code. And Pulumi ESC users can now create and manage environments, secrets and configuration directly within the IDE with rich IDE features.

The following are a few examples of new capabilities available for Pulumi users in VS Code today:

Launch your Pulumi program under a debugger
Automatically generate a launch configuration for a Pulumi project
Create and explore Pulumi ESC (Environments, Secrets, and Configuration) environments
Get contextual warnings and errors directly within the editor for Pulumi YAML

Getting Started

Install the Software

Install Pulumi 3.132.0 (or greater) using these instructions.
Install the Pulumi VS Code extension from the Visual Studio Marketplace.

Debugging Pulumi IaC Programs

For simple Pulumi programs, it’s easy enough to see what will happen when you look at the IaC code. But as teams build more complex cloud infrastructure components, fully taking advantage of Pulumi’s support for all of the rich componentization and control flow features in their language of choice, it can become more challenging to diagnose why a particular input value is being used for a cloud infrastructure resource, and what set of decisions were made by the infrastructure components to arrive at that. The pulumi CLI recently added support for a new --attach-debugger flag, which allows attaching a debugger to any language processes that are run as part of a Pulumi operation - regardless of the language. We’ve now added native VS Code debugger extension support for it as well, so that you can debug your Pulumi programs in any language with just a couple of clicks.

Start Debugging

The Pulumi VS Code Extension allows you to run and debug Pulumi programs with ease. Open a new or existing Pulumi project in VS Code and use an automatic or customized launch configuration.

Select the Run and Debug icon.
Choose Show all automatic debug configurations.
Select “Pulumi…” then “pulumi preview” or “pulumi up”.

Pulumi automatically generates a debug configuration for the current stack, making it simple to get started. You can also set breakpoints in your program and use the full functionality of the VS Code debugger.

You can now step through your code, set breakpoints on resource constructors or inside apply callbacks, and see the callstack and the values of variables within the VS Code debugger.

Create a Launch Configuration

For more control, you can create a customized launch configuration:

Click the gear icon when selecting an automatic debug configuration to customize it.
Alternatively, create a launch.json file and use a configuration template.

You can run without debugging by selecting “Run Without Debugging” from the Run menu or by adding "noDebug": "true" to your configuration.

Using Pulumi ESC

Pulumi ESC manages secrets and configuration for your applications and infrastructure within a centralized and composable secrets store. The environments are stored securely within Pulumi Cloud, and can be edited and opened from the Pulumi Cloud console or from the pulumi CLI or REST API.

For developers working with both their application infrastructure code as well as their Pulumi ESC environments, it is convenient to be able to edit ESC environments and the secrets they contain directly within the IDE without switching contexts.

The Pulumi ESC integration in the Pulumi VS Code extensions makes this easy. You can navigate through your environments, see all the projects and versions, and directly edit the source of the environments within VS Code. When you save, the edit to the environment is saved directly back into Pulumi ESC as a new version. And while you have it open in VS Code, you get all the amazing software engineering productivity feature of your IDE - colorization, completion lists, error checking, goto definition, find references and much more!

Open the ESC Explorer

From the primary sidebar, open the “Pulumi ESC Explorer” view and click “Login” to authenticate to Pulumi Cloud. Once logged in, you’ll see a tree of your organizations and environments.

Key Capabilities

Easily create or edit environments by clicking the plus sign on an organization or project node. The extension opens an editor where you can define and save new environment revisions. The IntelliSense functionality will guide you on various values, such as completion for setting up provider configuration.

You can also:

Run your application in the context of your environment by hovering over it and selecting the terminal icon

Delete environments by hovering over them and selecting the delete icon
Decrypt environments for cloning or moving
View environment versions over time
Compare different environments or environment versions
Use the search icon to quickly find environments
Tag specific environment revisions for easy reference.

Manage infrastructure from your editor

Pulumi brings infrastructure as code and Pulumi ESC into the tools you already work in. Build, deploy, and debug your stacks, then manage secrets and configuration in Pulumi Cloud.

Get started

Pulumi YAML Support

Along with support for many popular programming languages including TypeScript, Python, Go, .NET and Java - Pulumi also supports a simple declarative YAML language for defining and managing infrastructure. VS Code already has great support for all the other languages Pulumi supports, but for Pulumi YAML, the Pulumi VS Code Extension offers great support for working in this YAML dialect, including support for type checking, completion lists, colorization and more.

Building on a Pulumi YAML Language Server Protocol (LSP) available for use in any IDE environment, the Pulumi YAML IDE support providers a wide range of editor integrations.

Type Checking

The Pulumi YAML LSP provides contextual warnings and errors directly within the editor.

Warnings: Alerts when a variable is defined but never referenced.
Errors:
- Invalid YAML document detection.
- Reference errors for non-existent variables.
- Duplicate names for variables/resources.

Hover Tooltips

Hover over a resource type token or function type token to see a popup with descriptions, helping you understand your resources and functions better.

Completion Lists

Experience semantic completion for:

Predefined Pulumi YAML keys such as “resources” or “properties”.
Resource properties or function arguments.
Type tokens for resources or functions.
Structured variables (e.g., referencing properties within complex objects).

Wrapping up

This extension is currently in public beta, and we’re eager to hear from the Pulumi community. Your feedback is crucial in helping us shape the future of the extension. If you have suggestions for new features or encounter any bugs, please open an issue.

What’s Next

We’re committed to making Pulumi development as efficient and enjoyable as possible. In the coming months, expect even more features and improvements, all aimed at helping you work smarter and faster. Stay tuned for updates as we continue to build out this powerful extension and bring new capabilities to the Pulumi platform.

Introducing the Centralized Policy Violations Page: Streamlined Compliance Management

Meagan Cojocar — Mon, 26 Aug 2024 09:00:00 -0700

We’re excited to introduce a new centralized Policy Violations destination in Pulumi Cloud to simplify policy management and compliance. This powerful addition provides a comprehensive view of all policy violations across your organization, helping you maintain visibility and control over your infrastructure.

Pulumi’s Policy as Code (PaC) feature, CrossGuard, allows you to define and enforce policies for your infrastructure using familiar programming languages. By integrating these policies directly into your infrastructure code, you can automate compliance checks, gate deployments to ensure security best practices, and maintain governance across all your providers.

Note: Pulumi CrossGuard is available in the Pulumi Business Critical edition.

Centralized Policy Violations: Why It Matters

Ensuring compliance across multiple projects and stacks can be challenging in large and complex environments. The new Policy Violations page addresses this challenge by consolidating all violations into one place. This allows you to quickly assess the overall compliance of your infrastructure and separate signal from noise. This streamlined view saves time and reduces the risk of missing critical issues.

By having all violations on a single page, organization admins can efficiently prioritize remediation efforts and identify patterns in non-compliance. They can triage the violations and send the critical ones to teams to resolve.

Grouping Violations: Enhanced Insights Across Multiple Dimensions

One of the standout features of the new page is the ability to group violations by various fields, including Policy Pack, Policy, Project, Stack, Resource, and more! This flexibility allows you to gain deeper insights into your infrastructure’s compliance landscape.

Grouping violations based on these fields enables you to answer critical questions such as:

Policy Pack and Policy: Which Policy Packs and Policies have the most frequent violations?
Project and Stack: Are there specific projects or stacks that are more prone to compliance issues?
Resource: Which resources have failed policies?
Reason and Enforcement Level: What are the common reasons for violations, and how critical are they?
Violation Date: When are violations most likely to occur, and are there patterns over time?

These insights empower you to refine your policies, address the most problematic areas, and improve your overall compliance strategy.

Accessing Policy Violations via API

To further enhance your compliance management, you can leverage the Pulumi Cloud REST API to programmatically access policy violations, trigger automated workflows, and import data into your analytics systems. The API can automate the monitoring of your infrastructure’s compliance status, ensuring that policy violations are promptly detected and addressed. This capability enables you to integrate Pulumi’s compliance data with your existing tools, creating a seamless and efficient compliance management process.

For example, you can use the following command to retrieve a list of policy violations:

curl \
 -H "Accept: application/vnd.pulumi+8" \
 -H "Content-Type: application/json" \
 -H "Authorization: token $PULUMI_ACCESS_TOKEN" \
 https://api.pulumi.com/api/orgs/{organization}/policyresults/violations

For more details on how to integrate this API into your workflow, visit the Pulumi API documentation.

Streamlining Compliance with Future Enhancements

Centralizing and surfacing policy violations is just the beginning. Future updates will include additional capabilities like advanced search and filtering, making it even easier to manage violations. We’re committed to providing the tools you need to keep your infrastructure secure, compliant, and running smoothly.

Wrapping It Up

The Centralized Policy Violations Page to Pulumi is a significant step forward in simplifying policy management and enhancing compliance. By bringing all violations into a single, easily accessible view, we’re making it easier for admins to maintain control and ensure their infrastructure remains secure and compliant.

Try out this new feature today and experience the benefits of streamlined compliance management. For more information, visit our Policy Violations documentation. To use this feature, start a trial or contact sales to get a demo or to trial Policy as Code.

Kubernetes-native Option for Pulumi Deployments Customer-Managed Agents

Levi Blackstone — Wed, 14 Aug 2024 08:08:31 -0700

We are excited to announce the availability of Kubernetes-native support for Pulumi Deployments Customer-Managed Agents, further enhancing the flexibility and control over your infrastructure deployments. This new feature allows you to self-host deployment agents within your Kubernetes environment, bringing the same power and flexibility of Pulumi-hosted deployments to isolated environments.

Customer Managed Agents: Flexibility and Control

Customer Managed Agents, announced earlier this year, allow you to self-host deployment agents, delivering the power and flexibility of Pulumi Deployments within your own infrastructure. Here’s how you can benefit:

Host Anywhere: Deploy Customer Managed Agents on any hardware or environment of your choice, including fully private VPCs.
Compliance and Security: Keep your cloud provider credentials within your private network, meeting stringent compliance requirements.
Scalability: Set up multiple agent pools and scale dynamically, supporting up to 150 concurrent deployments.
Versatility: Mix and match Pulumi-hosted and self-hosted deployments to suit different infrastructure needs.

Key Features of Pulumi Deployments

Customer-Managed agents support all the capabilities of Pulumi Deployments including:

Multiple Deployment Triggers: Supports all Pulumi Deployment triggers such as Drift Detection, Scheduled Deployments, click to deploy, REST API, Git push to deploy, Review Stacks, and remote Automation API.
OpenID Authentication: Fetch tokens dynamically for increased security.
Flexible Configuration: Configure through YAML files or environment variables, adaptable to various deployment environments.

Docker and Kubernetes Support

By default, Customer-Managed Agents are deployed on Virtual Machines using Docker. However, with this new release, you can now leverage Kubernetes to run these agents, enabling you to deploy them within your existing infrastructure. This integrates natively with Kubernetes pods and does not require Docker in Docker or privileged execution.

Getting Started with Kubernetes

To use Kubernetes for running Customer-Managed Agents:

Install the Pulumi GitHub App: Install the Pulumi GitHub App and ensure that it is integrated with your source control.
Set Up Deployment Pools:
- Navigate to Deployment Runners under Organization Settings in the left hand navigation bar.
- Create a new pool by clicking ‘Add new pool’
- You will get a new access token, copy and save the token.
Install Agents:
- Follow the instructions provided on the Deployment Runners page to install agents within your Kubernetes environment.
Configure Agents:
- All configuration for Customer-Managed Agents is done through the pulumi-deployment-agent.yamlfile. This file can be created manually or with the customer-managed-deployment-agent configure command.
- Or you can leverage the Pulumi program example repo.
- Set environment variables directly in your Kubernetes deployment.
Configure Stack:
- Go to Deploy settings, found under the Settings tab on a stack. Scroll down and select the pool you created under the Deployment Runner pool drop-down.

Verification

After setting up, verify the agent by doing a pulumi refresh through the Deploy Actions drop-down on your stack page.

To increase deployment concurrency, use the same token to set up multiple agents and they will be assigned to the same pool.

Wrapping It Up

Customer-Managed Agents with Kubernetes support empower you to manage deployments according to your specific needs. Whether it’s for security, compliance, or operational efficiency, this feature provides the flexibility and control necessary for modern infrastructure management.

For more details, check out our documentation or contact our sales team to get started with Customer-Managed Agents today.

Feel free to reach out with feedback or questions. We’re here to support you every step of the way.

Self-Hosted Pulumi Cloud Support for Resource Search and Pulumi Deployments

Meagan Cojocar — Wed, 03 Jul 2024 09:08:31 -0700

We are excited to introduce two powerful new features for our Self-Hosted Pulumi Cloud offering: Resource Search and Pulumi Deployments. These two additions are the most significant features added to Pulumi Cloud in the last year and we are thrilled to bring them to our self-hosted customers. Resource Search and Pulumi Deployments both improve the way you can manage and deploy your cloud infrastructure, providing greater visibility, control, and automation.

Alongside these features, we are also introducing today a Self-Hosted Changelog, a log of all relevant changes that self-hosted customers should be aware of.

Self-Hosted Pulumi Cloud Overview

Self-Hosting is available in the Pulumi Business Critical edition of Pulumi Cloud, you can try it out with our 30 day trial. This allows organizations to run the Pulumi Cloud within their own environments, ensuring data control, compliance, and customizability. While Pulumi manages all aspects of its SaaS offering (Pulumi Cloud), Self-Hosted Pulumi Cloud requires customers to handle data backups, service maintenance, and updates.

Here’s a deep dive into what the new features offer and how they can benefit your organization:

Resource Search: Find and Analyze Your Cloud Resources with Ease

Pulumi Resource Search offers multi-cloud search and analytics across every resource in your organization. You can issue queries that find all of your AWS VPCs, or all of your VPCs in AWS and VNets in Azure, or all resources with the “production” tag across all cloud environments. You also have access to statistics about cloud usage, including a breakdown by cloud provider, resource type, and department. Resource search enables you to find the needle within your cloud haystack and visualize cloud consumption trends.

Key Features

Multi-Cloud Search: Query resources across various cloud environments.
Advanced Filtering: See top stacks, projects, providers, teams, and types by resource count.
Resource Search API: Integrate search functionality into your internal systems using the Search API.
Search from the CLI: Issue resource search queries from within the terminal without needing to change contexts.
Data Export: Export resource data for further analysis in your data warehouse.

Get more details on these features in our Resource Search documentation. For more information on how to enable it in your self-hosted instance read the self-hosted Resource Search documentation.

Pulumi Deployments: Automate and Manage Your Infrastructure with Ease

Pulumi Deployments is engineered to streamline infrastructure management tasks with a focus on scalability, automation, and control. This platform allows cloud engineers and platform teams to execute infrastructure actions such as previews, updates, destroys, and refreshes directly within Pulumi’s managed service. By bundling deployment settings like source code, cloud credentials, and environment variables into a single unit, Pulumi Deployments eliminates the complexities of stack management. Users can trigger deployments via Git events, through the Pulumi Cloud UI or leverage REST APIs for custom workflows, providing the flexibility to efficiently transition from code to cloud. In addition, customers using Pulumi Deployments can set up Drift Detection and Remediation, the ability to get notified when the state of your resources changes unexpectedly and optionally remediate it, as well as Time to Live Stacks, the ability to set a expiration on a stack when it will be destroyed.

Key Features

Git Push to Deploy: Automatically deploy infrastructure changes with each git push.
Click to Deploy: Deploy infrastructure with a single click from the Pulumi console.
REST API: Integrate Pulumi deployments with your applications using the REST API.
Automation API: Automate infrastructure provisioning and management with Pulumi’s Automation API.
Drift Detection: Identify and rectify configuration drift in your deployed stacks.
Time to Live Stacks: Automatically destroy stacks after a specified time period.
Scheduled Deployments: Schedule deployments to occur at specific times.
Review Stacks: Review and approve stack changes before deployment.

Get more details on these features in our Pulumi Deployments documentation. For more information on how to enable it in your self-hosted instance read the self-hosted Pulumi Deployments documentation.

Self-Hosted Changelog

The Self-Hosted Changelog is a newly introduced page that provides a comprehensive log of updates and changes specifically relevant to our self-hosted customers. This changelog ensures customers are fully informed about the latest improvements, bug fixes, and new features in the codebase and associated infrastructure. By keeping up-to-date of these updates, self-hosted customers can better manage their systems, anticipate and resolve potential issues, and take advantage of new functionalities as soon as they become available. Some examples of the types of recent updates on the changelog are adding support for expiration dates on access tokens or adding the ability to enable OTel metrics. This transparency not only helps in maintaining an optimal system but also empowers customers with the knowledge needed to leverage the full potential of our platform.

Wrapping It Up

The addition of Resource Search and Pulumi Deployments to our Self-Hosted Pulumi Cloud offering empowers you to manage your cloud resources more effectively and ensure the stability of your infrastructure. Whether you are looking to gain insights into your cloud usage or automate the detection and correction of configuration drift, these features provide the tools you need to succeed.

As of today, all Pulumi Cloud features that have been made generally available are supported in the self-hosted version. We intend to continue to have parity with Pulumi Cloud features in the self-hosted version within 6 months of making the feature generally available.

Try these new features today and experience the enhanced capabilities of the Self-Hosted Pulumi Cloud. For more information or to start a 30-day trial, contact us or visit our self-hosting documentation.

Announcing Short Lived Access Tokens in Pulumi Cloud

Meagan Cojocar — Tue, 25 Jun 2024 09:08:31 -0700

We are excited to introduce a new feature that our users have been eagerly awaiting: Short-Lived Access Tokens! This enhancement allows you to set an optional expiry date on Personal Access Token, Team Access Token, and Organization Access Token, making them automatically invalid after a specified date. This feature is now available in the Pulumi Cloud console and the Pulumi Cloud REST API, providing enhanced security and control over your access tokens.

Why Short-Lived Access Tokens?

Security and flexibility are paramount in managing infrastructure as code (IaC) and Environments, Secrets and Config (ESC), and our users have consistently requested the ability to create access tokens with a limited lifespan. With short-lived access tokens, you can:

Enhance Security: By limiting the lifespan of your access tokens, you reduce the risk of tokens being misused if they are inadvertently exposed.
Improve Automation: Automate token management in your CI/CD pipelines, ensuring that tokens expire as needed and can then be rotated.
Simplify Audits: Easily track and manage token expirations, ensuring compliance with your organization’s security policies.

How It Works

Creating Short-Lived Tokens in the console

When creating a new access token in the Pulumi Console, you will now see an optional expiry date field. Simply set the date when you want the token to expire, and it will automatically become invalid on that date. This feature is available for Personal Access Tokens, Team Access Tokens, and Organization Access Tokens (note: Team Access Tokens and Organization Access Tokens are only available in the Enterprise and Business Critical editions of Pulumi Cloud).

Learn more by reviewing our access token documentation.

OIDC Trust Relationships

A few months ago we released OpenID Connect (OIDC) Trust Relationships for Pulumi Cloud, allowing you to generate short-lived Pulumi Cloud tokens using OIDC from within your CI/CD pipelines, such as GitHub Actions. Now we are exposing the optional expiration field in the console and in the REST API. Your OIDC generated tokens will also show in the UI alongside those created with other methods.

REST API Support

We have also exposed this functionality in the Pulumi REST API, allowing you to programmatically create and manage short-lived tokens. This makes it easier to integrate token management into your automation scripts and tools.

# Example API request to create a short-lived token
curl \
 -H "Accept: application/vnd.pulumi+8" \
 -H "Content-Type: application/json" \
 -H "Authorization: token $PULUMI_ACCESS_TOKEN" \
 --request POST \
 --data '{"description": "{description}", "name": "{unique_name}", "expires": 0}' \
 https://api.pulumi.com/api/orgs/{org}/teams/{team}/tokens

Try It Today

We invite you to try out the new short lived access tokens in Pulumi Cloud. As always, we value your feedback and look forward to hearing how this feature helps streamline your workflows and enhances security.

For more details, check out our documentation and API reference docs. If you have any questions or need assistance, our support team is here to help.

Pulumi Announces Drift Detection and Remediation: Continuously Monitor Your Infrastructure Changes

Meagan Cojocar — Wed, 24 Apr 2024 07:00:04 -0800

At Pulumi, we recognize the challenges platform teams face in maintaining the stability and compliance of their cloud infrastructures. One of the primary challenges is configuration drift, where the actual state of the infrastructure deviates from its intended state. This deviation can occur for various reasons, including manual adjustments made directly in the cloud provider’s console, unintended consequences of scripts, or unauthorized changes. Such drift can lead to significant problems including security vulnerabilities that open up potential breaches, compliance violations that can result in penalties, operational disruptions that affect user experience and business operations, and increased costs from unnecessary resource spend.

Today, we are excited to launch a new Drift Detection and Remediation feature in Pulumi Cloud to address these challenges. This new functionality is designed to automate the detection and correction of drift in your cloud environments, seamlessly integrating into your existing workflows, whether you use Pulumi Deployments or other CI/CD systems, and is supported for any resource you can manage with Pulumi, whether they are from Amazon Web Services, Microsoft Azure, Google Cloud Platform, or any of the 180+ supported providers. Drift Detection and Remediation is available today on the Enterprise and Business Critical editions of Pulumi Cloud.

Why Pulumi Cloud Drift Detection and Remediation?

Drift Detection is the process of identifying changes in the actual state of your cloud environment that deviate from the expected configuration stored in Pulumi Cloud. This can occur when an operator makes an out-of-band change directly in the cloud provider console, bypassing the usual code deployment processes.

Key benefits:

Enhanced Security: Stay ahead of potential security breaches caused by unauthorized changes to your infrastructure.
Compliance Assurance: Ensure that your infrastructure remains compliant with organizational policies and standards after out of band changes.
Time and Cost Efficiency: Reduce the time spent on tracking and rectifying configuration drift or managing a custom drift solution: leading to cost savings.
Risk Mitigation: Minimize the risk of errors and potential outages by promptly identifying and addressing accidental drifts in your environments.

How Drift Detection Works

Pulumi Cloud’s Drift Detection and Remediation operates continuously, on a schedule of your choosing, comparing the state of your resources with the expected configurations defined in your Pulumi setups. Any discrepancies triggered by modifications, deletions, or additions of resources are promptly reported in the new Drift tab in the Pulumi Cloud console. Alerts can be configured to be sent via webhooks, Slack, or Microsoft Teams when drift occurs, with detailed information about the drift’s nature and scope provided directly within the alerts.

For those using Pulumi Deployments, the system not only regularly detects but can also remedy the drift to align with your Pulumi program. This auto-remediation applies the last known infrastructure as code state, overwriting the drift. Auto-remediation can be set to occur by default or turned off to allow for manual intervention in the remediation of drift, depending on the criticality and nature of the stacks involved.

Under the hood, drift is detected by regularly running a new Pulumi operation we have added, pulumi refresh --preview-only. This operation collects the set of changes that exist between the cloud provider and the current desired state in Pulumi. These scheduled operations build on top of the new Scheduled Deployments functionality as is Time-to-Live Stacks, both of which were also announced today. If there is a delta between the cloud and the current desired state, it is presented in the Drift tab along with a “Drift detected” notification on the stack. If auto-remediation is configured, a pulumi update --refresh is run automatically following any detection of drift. All of this is automated by Pulumi Deployments for users who have configured Pulumi Deployments on their stack. For users who are not using Pulumi Deployments, they can configure their existing CI/CD system to run these same operations regularly, and the results will still be displayed as part of the Drift tab in Pulumi Cloud and you can receive notifications when drift is detected.

Getting Started with Drift Detection

To get started with Drift Detection in Pulumi, select which deployment route you will be using:

Pulumi Deployments: Pulumi programs are run on Pulumi-hosted compute, allowing you to set a schedule and let us handle the rest, including detecting drift, auto-remediation if you turn it on, history of each drift run and what was detected and notifications for drift events.
Existing CI/CD system: Run Drift Detection by regularly running pulumi refresh --preview-only to see what drift is detected in the Pulumi Cloud console and get notified on drift events.

Setting it Up in the Pulumi Cloud Console

In order to set up Drift Detection and Remediation in the Pulumi Cloud console, follow these steps:

Ensure Deployments Settings are configured on the stack see the docs
Navigate to the Stack > Settings > Schedules page
Select “Drift”
(Optional) Turn on auto-remediation if applicable
Set the schedule using a cron expression
Save the Schedule

And just like that, you have Drift Detection! To test what the output will look like you can use the Actions button in the top right on the Stack page to run an ad hoc Drift Detection operation or an Auto-remediate operation. Note: if you have never run a pulumi refresh on that stack before, you will want to run one before setting up Drift Detection and ensure a clean refresh state. More details on getting a clean refresh state in our documentation.

You will now see on the Drift tab, a summary of what resources have been updated or deleted, the properties that have changed, when the drift run happened and a link to the Deployment with further details.

When drift is detected, you have a couple of options:

Run remediation from Pulumi Cloud: If you want to overwrite the changes made in your cloud provider with the most recently specified desired state of your Pulumi program. This can be done via the “Remediate drift” option in the Actions drop down on your stack page.
Run refresh from Pulumi Cloud: If you want to accept the changes made in your cloud provider back into your Pulumi desired state. This can be done via the “Refresh” option in the Actions drop down on your stack page. You may also want to update your Pulumi program to align with the changes made in the cloud provider.

Setting it Up via the API

For those who prefer to automate and script their infrastructure tasks, Drift Detection and Remediation can be configured programmatically using simple HTTP requests. Here are the new endpoints we have added:

Create a Drift schedule
Get a Drift schedule
Update or delete a Drift schedule
Pause or resume a Drift schedule
List all schedules (includes raw Pulumi operations and Time-to-Live schedules)

Below is an example of setting up Drift Detection and Remediation on a stack, see the Pulumi Deployments REST API documentation for more details on how to set Drift Detection and Remediation up programmatically.

Create a Drift Detection and Remediation schedule:

curl -H "Accept: application/vnd.pulumi+json" \
 -H "Content-Type: application/json" \
 -H "Authorization: token $PULUMI_ACCESS_TOKEN" \
 --request POST \
 --data '{"scheduleCron":"0 0 * * *","autoRemediate":true}' \
 https://api.pulumi.com/api/stacks/{organization}/{project}/{stack}/deployments/drift/schedules

Setting it Up via the Pulumi Service Provider

The Pulumi Service Provider allows you to set up automated Drift Detection and Remediation in source control.

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

const organizationName = "my-org";
const projectName = "my-project";
const stackName = "production";

// Creating a DriftSchedule for automatically running drift detection
const driftDetectionSchedule = new pulumiservice.DriftSchedule("driftDetectionSchedule", {
 organization: organizationName,
 project: projectName,
 stack: stackName,
 scheduleCron: "0 0 * * *", // Run drift detection daily at midnight
 autoRemediate: true, // Automatically remediate any drift detected
});

export const driftScheduleId = driftDetectionSchedule.scheduleId;

import pulumi
import pulumi_pulumiservice as pulumiservice

organization_name = "my-org"
project_name = "my-project"
stack_name = "production"

# Create a drift detection schedule
drift_detection_schedule = pulumiservice.DriftSchedule("driftDetectionSchedule",
 organization=organization_name,
 project=project_name,
 stack=stack_name,
 schedule_cron="0 0 * * *", # Run drift detection daily at midnight
 auto_remediate=True) # Automatically remediate any drift detected

pulumi.export('driftScheduleId', drift_detection_schedule.schedule_id)

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 {
 driftDetectionSchedule, err := pulumiservice.NewDriftSchedule(ctx, "driftDetectionSchedule", &pulumiservice.DriftScheduleArgs{
 Organization: pulumi.String("my-org"),
 Project: pulumi.String("my-project"),
 Stack: pulumi.String("production"),
 ScheduleCron: pulumi.String("0 0 * * *"), // Run drift detection daily at midnight
 AutoRemediate: pulumi.Bool(true), // Automatically remediate any drift detected
 })
 if err != nil {
 return err
 }

 ctx.Export("driftScheduleId", driftDetectionSchedule.ScheduleId)
 return nil
 })
}

using Pulumi;
using PulumiService = Pulumi.PulumiService;

class Program
{
 static Task<int> Main() => Deployment.RunAsync(() => {
 var driftDetectionSchedule = new PulumiService.DriftSchedule("driftDetectionSchedule", new PulumiService.DriftScheduleArgs
 {
 Organization = "my-org",
 Project = "my-project",
 Stack = "production",
 ScheduleCron = "0 0 * * *", // Run drift detection daily at midnight
 AutoRemediate = true, // Automatically remediate any drift detected
 });

 return new Dictionary<string, object?>
 {
 { "driftScheduleId", driftDetectionSchedule.ScheduleId }
 };
 });
}

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.pulumiservice.Webhook;
import com.pulumi.pulumiservice.WebhookArgs;

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

 private static void stack(Context ctx) {
 var driftDetectionSchedule = new Webhook("driftDetectionSchedule", WebhookArgs.builder()
 .organization("my-org")
 .project("my-project")
 .stack("production")
 .scheduleCron("0 0 * * *") // Run drift detection daily at midnight
 .autoRemediate(true) // Automatically remediate any drift detected
 .build());

 ctx.export("driftScheduleId", driftDetectionSchedule.scheduleId());
 }
}

name: drift-detection-setup
runtime: yaml
description: Setup of automated drift detection with Pulumi

resources:
 driftDetectionSchedule:
 type: pulumiservice:index:DriftSchedule
 properties:
 organization: my-org
 project: my-project
 stack: production
 scheduleCron: "0 0 * * *" # Run drift detection daily at midnight
 autoRemediate: true # Automatically remediate any drift detected

outputs:
 driftScheduleId: ${driftDetectionSchedule.scheduleId}

See the Pulumi Service Provider documentation for more details on how to manage Drift Detection and Remediation in source control.

Wrapping it up

We are thrilled to be releasing a top customer ask today and are looking forward to hearing about your experience using Drift Detection and Remediation.

Until next time, happy building!

Time-to-Live Stacks: Auto-Destroying Stacks

Meagan Cojocar — Wed, 24 Apr 2024 07:00:03 -0800

In the dynamic landscape of cloud-based software development, platform teams face the continuous challenge of balancing the need for innovation with the imperative to control cloud costs and security. Pulumi Cloud’s new Time-to-Live (TTL) Stacks feature directly addresses this challenge by empowering teams to manage infrastructure lifecycles automatically, mitigating the risks associated with stale infrastructure and resource costs ballooning.

Creating temporary environments for development, testing, or staging is a common practice in the lifecycle of software development. These environments are crucial for running experiments, testing new features, and ensuring that everything works smoothly before going live. However, these environments often don’t get decommissioned properly and linger, forgotten, consuming resources and adding unnecessary costs to your cloud bill.

Furthermore, managing these temporary stacks usually requires manual oversight, adding to the operational burden of your team. They need to track which environments are active, which are outdated, and manually shut them down to avoid security risks from idle and unmonitored resources. This process is not only time-consuming but also prone to human error, leading to either premature deletion of necessary resources or overlooked environments that pose security risks.

Simplifying Stack Management with Time-to-Live Stacks

The Time-to-Live Stacks feature in Pulumi Cloud is designed to solve these pain points by allowing teams to set a predefined lifespan on any stack directly in Pulumi Cloud. After the specified time, these stacks are automatically destroyed, and using the optional “delete after destroy” setting, they are also removed from Pulumi Cloud entirely. This setting plays a pivotal role by not just destroying the resources but also cleaning up the stack itself after all resources have been terminated, ensuring that no residual artifacts are left behind. This maintains a clean state in the cloud environment and further reduces costs by reducing clutter. Time-to-Live Stacks are available today on the Enterprise and Business Critical editions of Pulumi Cloud.

Key Benefits of TTL Stacks

Cost Control: Automatically terminate stacks that are no longer needed, helping to avoid overspending on cloud resources that are not in active use.
Developer Enablement: Provides developers the flexibility to quickly spin up and test application changes in sandbox environments without worrying about the cleanup.
Operational Efficiency: Reduces the administrative burden of manually tracking and decommissioning temporary or outdated stacks, allowing teams to focus on more strategic tasks.
Enhanced Security: Automatically removing unused or neglected stacks helps ensure compliance and reduces the potential attack surface, making your infrastructure safer.

Getting Started with Time-to-Live Stacks

Setting it up in the Pulumi Cloud Console

In order to set up Time-to-Live Stacks in the Pulumi Cloud console, follow these steps:

Ensure Deployments Settings are configured on the stack see the docs
Navigate to the Stack > Settings > Schedules page
Select “Time-to-Live”
(Optional) Turn on “Delete After Destroy” if applicable
Set the schedule using a cron expression
Save the Schedule

You will now see a schedule in the Schedules tab which highlights when the destroy will occur.

Setting it up via the API

For those who prefer to automate and script their infrastructure tasks, Time-to-Live schedules can be configured programmatically using simple HTTP requests.

Create a Time-to-Live schedule
Get a Time-to-Live schedule for a stack
Update or delete a Time-to-Live schedule
Pause or resume a Time-to-Live schedule
List all schedules in the organization (includes raw Pulumi operations and Drift schedules)

Below is an example of setting up Time-To-Live on a stack programmatically:

curl -H "Accept: application/vnd.pulumi+json" \
 -H "Content-Type: application/json" \
 -H "Authorization: token $PULUMI_ACCESS_TOKEN" \
 --request POST \
 --data '{"timestamp":"2024-12-31T23:59:59Z","deleteAfterDestroy":true}' \
 https://api.pulumi.com/api/stacks/{organization}/{project}/{stack}/deployments/ttl/schedules

Refer to the Pulumi Deployments REST API documentation for more details on how to use the REST API to manage Time-to-Live Stacks.

Setting it up via the Pulumi Service Provider

The Pulumi Service Provider allows you to set up and manage Time-to-Live Stacks in source control.

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

const organizationName = "my-org";
const projectName = "my-project";
const stackName = "temp-stack";

const ttlSchedule = new pulumiservice.TtlSchedule("ttlSchedule", {
 organization: organizationName,
 project: projectName,
 stack: stackName,
 timestamp: "2024-01-01T00:00:00Z" // Specify the ISO date/time for destruction
});

export const scheduleId = ttlSchedule.scheduleId;

import pulumi
import pulumi_pulumiservice as pulumiservice

organization_name = "my-org"
project_name = "my-project"
stack_name = "temp-stack"

# Create a TTL schedule for stack destruction
ttl_schedule = pulumiservice.TtlSchedule("ttlSchedule",
 organization=organization_name,
 project=project_name,
 stack=stack_name,
 timestamp="2024-01-01T00:00:00Z") # Specify the ISO date/time for destruction

pulumi.export('scheduleId', ttl_schedule.schedule_id)


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 {
 ttlSchedule, err := pulumiservice.NewTtlSchedule(ctx, "ttlSchedule", &pulumiservice.TtlScheduleArgs{
 Organization: pulumi.String("my-org"),
 Project: pulumi.String("my-project"),
 Stack: pulumi.String("temp-stack"),
 Timestamp: pulumi.String("2024-01-01T00:00:00Z"), // Specify the ISO date/time for destruction
 })
 if err != nil {
 return err
 }

 ctx.Export("scheduleId", ttlSchedule.ScheduleId)
 return nil
 })
}

using Pulumi;
using PulumiService = Pulumi.PulumiService;

class Program
{
 static Task<int> Main() => Deployment.RunAsync(() => {
 var ttlSchedule = new PulumiService.TtlSchedule("ttlSchedule", new PulumiService.TtlScheduleArgs
 {
 Organization = "my-org",
 Project = "my-project",
 Stack = "temp-stack",
 Timestamp = "2024-01-01T00:00:00Z", // Specify the ISO date/time for destruction
 });

 return new Dictionary<string, object?>
 {
 { "scheduleID", ttlSchedule.ScheduleId }
 };
 });
}

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.pulumiservice.TtlSchedule;
import com.pulumi.pulumiservice.TtlScheduleArgs;

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

 private static void stack(Context ctx) {
 var ttlSchedule = new TtlSchedule("ttlSchedule", TtlScheduleArgs.builder()
 .organization("my-org")
 .project("my-project")
 .stack("temp-stack")
 .timestamp("2024-01-01T00:00:00Z") // Specify the ISO date/time for destruction
 .build());

 ctx.export("scheduleID", ttlSchedule.scheduleId());
 }
}

name: ttl-schedule-setup
runtime: yaml
description: Setup of TTL for automatic resource destruction with Pulumi

resources:
 ttlSchedule:
 type: pulumiservice:index:TtlSchedule
 properties:
 organization: my-org
 project: my-project
 stack: temp-stack
 timestamp: "2024-01-01T00:00:00Z" # Specify the ISO date/time for destruction

outputs:
 scheduleId: ${ttlSchedule.scheduleId}

See the Pulumi Service Provider documentation for more details on how to manage Time-to-Live Stacks in source control.

Wrapping it up

Time-to-Live Stacks has been one of the top requests from our Pulumi Cloud users, and we are thrilled to be making it available today. We look forward to further feedback on where Pulumi Cloud can best support your organizations’ infrastructure lifecycle management needs.

Happy hacking!

Pulumi Launches Scheduled Deployments: Automate Recurring Workflows

Meagan Cojocar — Wed, 24 Apr 2024 07:00:02 -0800

We are excited to announce Scheduled Deployments for Pulumi Cloud. This new feature, which builds upon the robust foundation of Pulumi Deployments, is designed to streamline cloud management by automating the deployment and deactivation of resources according to customizable schedules. Two new Pulumi features also announced today, Drift Detection and Remediation and Time-to-Live Stacks, are built on top of the new Scheduled Deployments functionality. These three new features are available today on the Enterprise and Business Critical editions of Pulumi Cloud.

Simplifying Cloud Operations Through Automation

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 feature is not just about automating routine tasks; it’s about enhancing operational efficiency, reducing costs, and deploying resources exactly when needed.

Example Use Cases

Automating Deployments outside of Git: Pulumi Deployments handles Git based Deployments well, but we have heard from customers there are times you want to intentionally diverge from Git triggered Deployments, such as wanting to deploy only at set times ahead of a large usage event or deploy only on non-peak traffic times.
Cost Optimization: Automatically power down non-critical development or test stacks during off-hours to cut unnecessary cloud spend. These stacks can be reactivated on a schedule or on-demand, ensuring resources are available precisely when teams need them without incurring costs during idle times.
Product Launches: Configure infrastructure to deploy right before a major release with pulumi up, ensuring that all resources are aligned and active precisely for the event, eliminating the need for last-minute manual updates.
Scheduled Processing: Perfect for tasks that require computing resources at specific times, such as nightly batch processing or periodic machine learning model training. Schedule these operations to maximize resource utilization and shut down upon task completion to optimize costs.

How Scheduled Deployments Work

Users can define schedules for any Pulumi operation, on any stack, using cron expressions, which provide the flexibility to specify exact times for operations. This granular control over deployment timing allows for effective management of infrastructure tasks, accommodating even the most complex scheduling needs. Pulumi Deployments Schedules can be set up using the Pulumi Cloud console, our REST API or managed in source control using the Pulumi Service Provider.

Integration with Existing Features

Scheduled Deployments integrate seamlessly with existing Pulumi Deployments. The concurrency limits of Pulumi Deployments apply and if deployments on a stack are paused, the scheduled deployments will queue, waiting for the pause to lift before executing. This integration ensures that all scheduled activities respect the operational parameters set within Pulumi Cloud.

Getting Started with Scheduled Deployments

Setting it up in the Pulumi Cloud Console

We’ll walk through how to get up and running with Scheduled Deployments in the Pulumi Cloud console, REST API and Pulumi Service Provider. For more details on how to implement and maximize the benefits of Scheduled Deployments, please visit our documentation.

Setting up Scheduled Deployments via the Pulumi Cloud console is straightforward:

In order to set up Scheduled Deployments in the Pulumi Cloud console, follow these steps:

Ensure Deployments Settings are configured on the stack see the docs
Navigate to the Stack > Settings > Schedules page
Select “Raw operation”
Select from the drop-down the type of operation you would like to schedule
Set the schedule using a cron expression
Save the Schedule

Now you have a Scheduled Deployment!

The Stack > Settings > Schedules page will show all of the schedules configured for your stack, including Drift, TTL or Raw Operation schedules.

Setting it up in the API

For those who prefer to automate and script their infrastructure tasks, Time-to-Live schedules can be configured programmatically using simple HTTP requests.

Create a schedule
Get a schedule for a stack
Update or delete a schedule
Pause or resume a schedule
List all schedules in the organization (includes Drift and Time-to-Live schedules)

Below is an example of creating a Schedule on a stack programmatically:

curl \
 -H "Accept: application/vnd.pulumi+8" \
 -H "Content-Type: application/json" \
 -H "Authorization: token $PULUMI_ACCESS_TOKEN" \
 --request POST \
 --data '{ "scheduleCron":"0 0 * * *", "request": { "operation": "update" } }' \
 https://api.pulumi.com/api/stacks/{organization}/{project}/{stack}/deployments/schedules

Refer to the Pulumi Deployments REST API documentation for more details on how to use the REST API to manage Scheduled Deployments.

Setting it up in the Pulumi Service Provider

Pulumi Service Provider for Creating a Raw Schedule

The Pulumi Service provider allows you to set up a raw schedule for operations like updates or deployments based on a specific time or a recurring schedule inside of source control.

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

const organizationName = "my-org";
const projectName = "my-project";
const stackName = "prod-stack";

const rawSchedule = new pulumiservice.DeploymentSchedule("rawSchedule", {
 organization: organizationName,
 project: projectName,
 stack: stackName,
 scheduleCron: "0 0 * * *", // Run an update daily at midnight
 pulumiOperation: pulumiservice.PulumiOperation.update
});

export const scheduleId = rawSchedule.scheduleId;

import pulumi
import pulumi_pulumiservice as pulumiservice

organization_name = "my-org"
project_name = "my-project"
stack_name = "prod-stack"

# Create a raw deployment schedule
raw_schedule = pulumiservice.DeploymentSchedule("rawSchedule",
 organization=organization_name,
 project=project_name,
 stack=stack_name,
 schedule_cron="0 0 * * *", # Run an update daily at midnight
 pulumi_operation=pulumiservice.PulumiOperation.update)

pulumi.export('scheduleId', raw_schedule.schedule_id)

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 {
 rawSchedule, err := pulumiservice.NewDeploymentSchedule(ctx, "rawSchedule", &pulumiservice.DeploymentScheduleArgs{
 Organization: pulumi.String("my-org"),
 Project: pulumi.String("my-project"),
 Stack: pulumi.String("prod-stack"),
 ScheduleCron: pulumi.String("0 0 * * *"), // Run an update daily at midnight
 PulumiOperation: pulumiservice.PulumiOperationUpdate,
 })
 if err != nil {
 return err
 }

 ctx.Export("scheduleId", rawSchedule.ScheduleID)
 return nil
 })
}

using Pulumi;
using PulumiService = Pulumi.PulumiService;

class Program
{
 static Task<int> Main() => Deployment.RunAsync(() => {
 var rawSchedule = new PulumiService.DeploymentSchedule("rawSchedule", new PulumiService.DeploymentScheduleArgs
 {
 Organization = "my-org",
 Project = "my-project",
 Stack = "prod-stack",
 ScheduleCron = "0 0 * * *", // Run an update daily at midnight
 PulumiOperation = PulumiService.PulumiOperation.Update,
 });

 return new Dictionary<string, object?>
 {
 { "scheduleId", rawSchedule.ScheduleId }
 };
 });
}

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.pulumiservice.DeploymentSchedule;
import com.pulumi.pulumiservice.DeploymentScheduleArgs;

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

 private static to stack(Context ctx) {
 var rawSchedule = new DeploymentSchedule("rawSchedule", DeploymentScheduleArgs.builder()
 .organization("my-org")
 .project("my-project")
 .stack("prod-stack")
 .scheduleCron("0 0 * * *") // Run an update daily at midnight
 .pulumiOperation(com.pulumi.pulumiservice.PulumiOperation.update())
 .build());

 ctx.export("scheduleId", rawSchedule.name());
 }
}

name: raw-schedule-setup
runtime: yaml
description: Setup of a raw schedule for automatic operations with Pulumi

resources:
 rawSchedule:
 type: pulumiservice:index:DeploymentSchedule
 properties:
 organization: my-org
 project: my-project
 stack: prod-stack
 scheduleCron: "0 0 * * *" # Run an update daily at midnight
 pulumiOperation: update

outputs:
 scheduleId: ${rawSchedule.scheduleId}

See the Pulumi Service Provider documentation for more details on how to manage Scheduled Deployments in source control.

Wrapping it up

We are looking forward to unlocking this capability to enable an out of the box way to automate your reoccuring workflows.

Happy building!

New Pulumi Deployments Free Tier for Everyone: Automate Your Infrastructure Workflows

Meagan Cojocar — Wed, 24 Apr 2024 07:00:01 -0800

At Pulumi, we are committed to empowering developers and infrastructure teams with the tools they need to efficiently manage cloud resources at scale. As part of our ongoing efforts to enhance user experience and ease of use, we are excited to share some significant updates to Pulumi Deployments pricing, making it easier for all customers to experiment with and adopt the easiest way to go from code to cloud.

Starting today, all paid Pulumi Cloud organizations get 3,000 minutes per month of Pulumi Deployments included with their Pulumi Cloud subscription.

Paired with the launch of Drift Detection and Remediation, Time-to-Live Stacks and Scheduled Deployments - it has never been easier to kick the tires on the latest and greatest tools for infrastructure lifecycle management.

Introduction to Pulumi Deployments

Pulumi Deployments is a fully managed platform designed to empower teams to efficiently manage and scale their cloud infrastructure. Whether you are just getting started in the cloud and want the easiest path to set up secure CI/CD, or are a platform engineer building a self-service platform to support thousands of engineers, Pulumi Deployments provides you with the building blocks that enable you to scale your cloud footprint without scaling your headcount. It offers a fully managed, secure, and elastic compute environment for running infrastructure deployments. It simplifies configuration by centralizing the management of source code, cloud credentials, and other necessities at the stack level. Additionally, the platform supports a variety of deployment triggers such as REST API, Git Push to Deploy, and Click to Deploy, allowing users to customize and automate their cloud operations beyond the capabilities of traditional CI/CD systems. When a stack is managed with Pulumi Deployments, richer Pulumi Cloud functionality is supported, such as Review Stacks and Click to Deploy templates in the New Project Wizard.

Exciting New Features

Drift Detection

Stay on top of your infrastructure’s health with our new Drift Detection feature. Drift Detection helps you monitor and rectify discrepancies between your desired infrastructure state and the actual state, ensuring consistency and compliance.

TTL Stacks

Manage resources effectively with Time to Live (TTL) Stacks. This feature automatically deallocates resources after a set period, perfect for temporary or experimental deployments, reducing costs and manual cleanup efforts.

Scheduled Deployments

Optimize your deployment strategy with Scheduled Deployments. This feature allows you to plan and execute deployments at specific times, making it easier to manage updates during off-peak hours, minimizing impact on your services.

Pulumi Deployments for Everyone

To help ensure all Pulumi Cloud users can get started with Pulumi Deployments, we are introducing an updated allocation model for deployment minutes. Now, all customer tiers—Team, Enterprise, and Business Critical—will receive 3,000 free deployment minutes each month. This change allows our users to test and leverage Pulumi Deployments without upfront commitments or the need to engage in lengthy procurement processes. The table below shows the Pulumi Deployments dimensions (both pricing and limits) by tier, more details can be found on our pricing page.

Dimension	Individual	Team	Enterprise	Business Critical
Minutes Included	500/month	3000/month	3000/month	3000/month
Cost per minute		$0.01	Starts at $0.01	Starts at $0.01
Concurrency Limit	1	5	25	150
Self-hosted Deployment Runners	Available	Available	Available	Included

Looking Forward

As a core part of Pulumi Cloud, Pulumi Deployments is now easier to adopt in your organization. We expect to release even more rich features built on Pulumi Deployments, offloading the time consuming work to Pulumi Cloud with turn-key features to solve your existing pain points.

We can’t wait to hear any feedback on this new set of features and Pulumi Deployments as a whole!

Developer Portal Gallery: Org Templates, Pulumi Templates and AI Generated Templates

Meagan Cojocar — Thu, 25 Jan 2024 00:00:00 +0000

Late last year we announced Pulumi for Developer Portals: a suite of features designed to empower organizations to construct robust internal developer portals. Since launching the level of adoption and customer interest has led us to make further improvements to enhance developer productivity and collaboration in the authoring experience. We are excited to announce the latest enhancement in Pulumi Cloud: the introduction of a template gallery in New Project Wizard, making creating cloud infrastructure easier than ever.

See it in action

What the Pulumi Cloud New Project Wizard?

The Pulumi Cloud New Project Wizard is the fastest way to get a Pulumi program up and running. The New Project Wizard provides a more turnkey, out-of-the-box alternative to the Pulumi Backstage Plugin or custom-built integrations.

By using the wizard, developers can generate Pulumi programs from your Organization Templates, commit and push code to GitHub, and trigger an initial deployment – all in a few clicks and without leaving the browser.

Try it out by selecting the ‘New Project’ option on the left-nav bar inside your Pulumi organization.

What is a template gallery?

The Pulumi Cloud template gallery is a curated collection of templates designed to help Platform Teams provision and distribute templates that get their developers up and running. Whether they’re setting up a simple server or orchestrating a complex microservices architecture, the template gallery can support a wide array of starting points that are both time-efficient and best practice-oriented. The idea is simple yet powerful – provide developers with the resources they need to get up and running swiftly, without having to reinvent the wheel each time.

The new template gallery in Pulumi Cloud contains three types of templates:

Organization Templates: Pulumi Cloud Enterprise and Business Critical editions support registering your own custom templates for your organization which will be made available in the New Project Wizard. This enables platform teams to standardize infrastructure creation and distribute those best practices where developers are already spending their time.
Pulumi Templates: All Pulumi Cloud organizations get a handful of Pulumi templates included in the gallery, templates Pulumi has authored to cover common architecture patterns.
AI Generated Templates: Starting today, you can leverage Pulumi AI to genera†e the templates you need from the template gallery. Pulumi AI is a purpose-built AI assistant that can create cloud infrastructure using Pulumi. If your developers are looking for a template that is not yet created, Pulumi AI can dramatically reduce the time it takes to build their Pulumi program.

Wrapping up

We look forward to hearing about your experience trying out the new project wizard template gallery! As always, please raise any feedback- big or small- in the Pulumi Cloud Requests repository.

Happy building!

Introducing the Pulumi Cloud Team Edition Cost Calculator

Meagan Cojocar — Fri, 15 Dec 2023 15:54:54 -0800

Pulumi Cloud pricing is straightforward- a charge per resource hour for every resource managed by Pulumi Cloud and a charge for every deployment minute (only applicable if using Pulumi Deployments). However, when prospective customers first look at Pulumi Cloud costs it can be overwhelming to determine what your workload will look like and then do the math.

Today we are making available a simple tool for estimating your cost on the Team Edition of Pulumi Cloud to get prospective customers to the information as quickly as possible.

Just input the number of resources in all your cloud accounts and the percentage of time they will be up (12 hours a day would be 50% of the time) and you have an estimate of your costs! If you are already using Pulumi for your Infrastructure as Code (IaC) you can run a pulumi preview to see the resource count in a stack. Add your estimated deployment minutes to see Pulumi Deployments costs included. The amount of time it takes to run an update on a stack locally is a good starting place for estimating deployment costs. Toggle from Per Month to Per Day to see your daily cost estimate instead of monthly.

Calculate Pulumi Cloud Costs

What inputs are required:

Number of resources
Utilization
Deployment minutes (optional)

The pricing calculator then provides:

Estimated cost per month or day
Free credits included
Cost per credit

And just like that you have your estimate! For customers who will be spending over $20,000 a year, please contact sales to see what bulk discount options are available for your organization.

Pulumi Cloud Gets Full Historical Views of Resources and Stack Outputs

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

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

Expanded Resource Information

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

Stack Outputs

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

The Value of Enhanced Data Visibility

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

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

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

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

Pulumi Cloud Adds Multi-factor Authentication

Meagan Cojocar — Tue, 28 Nov 2023 10:49:53 -0800

We are excited to announce that all users of Pulumi Cloud can now secure their account with multi-factor authentication (MFA). By requiring an additional verification step during the login process, MFA shields against unauthorized access, reducing the risk of breaches. This feature aligns with our commitment to providing robust security measures for our users. As an organization administrator, you can further protect your organization by having your members enable MFA.

How to set it up

Let’s walk through the steps to enable MFA on your account:

Click on your account avatar in the top right corner
Navigate to Account Settings
Scroll to the MFA section
Press Enroll
Use your authenticator application of choice to scan the QR code or paste the code
On your next login, you will be prompted for a passcode:

You are enrolled! When signing in you will now be asked for a one-time passcode.

Limitations

Initially, MFA in Pulumi Cloud will support TOTP (time-based one-time passwords) and it will only be available for Pulumi Cloud-backed users. Users authenticating with a third party (such as GitHub or GitLab) will need to use MFA through those providers at this time. Some other future improvements we are considering and will prioritize based on feedback we hear from customers are extending support for WebAuthN/passkeys, Duo, SMS/Email OTP and admins enforcing MFA for their entire organization.

Wrapping it up

We’re committed to continually evolving our services to meet the needs of our diverse and growing user base. Stay tuned for more updates and features as we progress on this journey together.

Pulumi Deployments is Generally Available: Scale Your Infrastructure, Not Your Headcount

Meagan Cojocar — Tue, 24 Oct 2023 08:06:12 -0700

We are thrilled to announce the general availability (GA) of Pulumi Deployments, a fully managed platform designed to simplify and accelerate your journey from code to cloud. Whether you’re an organization just beginning your cloud journey or a platform team supporting thousands of engineers, Pulumi Deployments is your go-to solution for managing infrastructure at scale. With the GA of Pulumi Deployments comes a suite of feature improvements since launch and a pricing model starting November 1st.

Introduction to Pulumi Deployments

Pulumi Deployments is a fully managed platform engineered to streamline your infrastructure management tasks, offering an unparalleled blend of scalability, automation, and control. Designed with the needs of platform teams and cloud engineers in mind, this platform allows you to execute a range of infrastructure as code actions—such as previews, updates, destroys, and refreshes—right within Pulumi’s managed service. Through a centralized configuration system, it bundles all your deployment necessities like source code, cloud credentials, and environment variables into a single, atomic unit, thereby eliminating the complexities often associated with stack management. Whether you want to trigger deployments via a simple click in the Pulumi Cloud UI or leverage REST APIs for custom automation workflows, Pulumi Deployments offers the flexibility and building blocks you need to efficiently go from code to cloud.

“Pulumi Deployments is easier to set up for new projects than our in-house developed CI/CD pipelines for running Pulumi, it’s more fully featured and it has much better integration with our version control system. The best part is that I don’t have to maintain it myself so I can spend more time focused on managing infrastructure.” said Mark Morlino, DevOps Engineer at Boost Insurance.

A Year in Review: Paving the Fastest Way to Go from Code to Cloud

It’s been a year since we launched Pulumi Deployments and we have seen incredible adoption, with hundreds of Pulumi Cloud customers leveraging it, thousands of stacks with deployment settings configured and hundreds of thousands of deployments executed. This success would not have been possible without the customers who spent time with us outlining their deployment challenges and iterating with us as we built solutions for them.

OpenID Connect (OIDC) Configuration: OIDC enables your deployments to exchange a signed, short-lived token issued by the Pulumi Cloud for short-term credentials from your cloud provider.
Scalability Improvements: We added concurrency limits, made security improvements and increased deployment capacity.
Review Stacks: We build a top requested feature, Review Stacks: dedicated cloud environments that get created automatically every time a pull request is opened, powered by Pulumi Deployments.
Dependent Stack Updates: Trigger updates on one stack based on changes in another stack.
Deployment Webhook Events: Build custom workflows using Deployment webhooks, trigger workflows based on an update failing or succeeding.
Slack and Microsoft Teams Deployment Notifications: Enable ChatOps workflows - get notified about deployment status where you already spend your time.
Pause and Skip Deployments: Pause deployments on a stack or organization level and skip deployments on stack if there are multiple.

Our release velocity has been high in the past year, and given the traction of the feature, we expect it to only increase from here.

What’s New in General Availability

Pricing and Billing

Starting November 1st Pulumi Deployments will cost $0.01 per deploy minute. New free tiers and concurrency limits ensure that you can try the feature out without worrying about cost, but then also scale efficiently and cost-effectively.

To learn more about Pulumi Deployments visit the pricing page.

Customer-managed Deployment Agents

For those with specific on-premises requirements, we now offer customer self-hosted agents, giving you even more control over your deployments and allowing you to access infrastructure not accessible by the internet.

To sign up for the Customer-managed Deployment Agents preview, submit the form to register your interest.

GitHub Enterprise Support

We’ve expanded our support to include GitHub Enterprise, making it easier for more organizations who use GitHub Enterprise to integrate Pulumi Deployments into their existing infrastructure. The GitHub Enterprise integration is available on the Business Critical edition.

To learn more about setting up Deployments with GitHub Enterprise read the documentation.

Organization-Level Deployments Page

Our new organization-level deployments page allows you to manage all deployments across multiple teams and projects from a single pane of glass, with actions like pausing Deployments for the organization or for a specific stack.

Activity Split & Deployments Dashboard Card

See your Deployments on each stack in a separate tab to easily distinguish it from update activity.

We also added a Deployments card to the Dashboard. This allows you to see at a glace the running and recently completed Deployments across the organization and navigate right to them.

Ready to Power Your Platform?

Pulumi Deployments is now generally available for all. We invite you to experience this next chapter in cloud infrastructure management.

To learn more about Pulumi Deployments or to get started, visit our official documentation or contact our sales team for a personalized demo.

We can’t wait for you to join us on this exciting journey. Happy building! 🚀🚀🚀

Build The Best Developer Portal with Pulumi Templates

Meagan Cojocar — Thu, 12 Oct 2023 00:00:00 +0000

At Pulumi, we work with organizations that range from a few platform team members to entire departments for managing infrastructure. Many organizations, like Mercedes-Benz, have built internal developer platforms on top of Pulumi to enable developers to self-serve infrastructure templates, and partners like AWS Proton and Port have built integrations with Pulumi to enable self-service scenarios. We are thrilled to have announced yesterday the launch of our new suite of tools to build internal developer portals with Pulumi, a result of working directly with our customers to understand their problems and how Pulumi can solve it.

Pulumi launched Pulumi Templates last year, out of the box templates based for common architectures, such as serverless templates, container service templates and Kubernetes cluster templates. The introduction of these templates allows Pulumi customers to go from 0 to 1 much quicker, but as they scale their IaC complexity a need for custom templates arises. To address this, we are expending into managing custom templates as a self-service provisioning experience.

Introduction to Developer Portals with Pulumi

Many of our customers are building their own developer portals on top of Pulumi Automation API and Pulumi Deployments, but we also wanted to offer options for teams that cannot (or do not want to) build a custom solution. The suite of tools for building internal developer portals include:

New Project Wizard: Showcased in the GIF above, Pulumi Cloud now enables developers to provision infrastructure entirely via point-and-click in Pulumi Cloud with the new New Project Wizard experience. This offers a great out-of-the box developer portal experience for any team using Pulumi Cloud.
Organization Templates: Pulumi Cloud now supports registering your own custom templates for your organization which will be made available in the New Project Wizard. This enables platform teams to standardize infrastructure creation and distribute those best practices where developers are already spending their time.
Pulumi Backstage Plugin: For teams using Backstage, they can now integrate Pulumi directly within their Backstage instance, via support for a new Pulumi plugin as well as new Pulumi scaffolder actions.
pulumi new support for private templates: By default, pulumi new provides a number of templates provided by Pulumi, but now your organization can also use private templates.

Key Benefits

Ease of Deployment: With this new functionality, you can quickly find and deploy the services you need, reducing the time and complexity of managing your cloud infrastructure. As a developer, if you are looking for a platform team sanctioned way to deploy a Kubernetes cluster, instead of chasing it down you can head to Pulumi Cloud, find the golden template and deploy it.

Enhanced Distribution: As a platform team member, share templates and configurations with your developers to ensure consistency and collaboration across your organization. It’s as simple as adding the template to a repo and selecting that repo in Pulumi Cloud. Now all of your developers have access to it when they go to create new infrastructure.

Combination with Other Features: The new template experience seamlessly integrates with your existing Pulumi workflows, providing a unified experience across your infrastructure management. Increase your developer productivity by using this suite of features in combination with Pulumi ESC. Attach an Environment to your template to have it come with configuration and secret values. Once the templates are deployed they will show in the Pulumi Cloud console use Policies over it, set up Review Stacks on the new stack to get ephemeral environments tied to PRs, find the resources that were deployed with Resource Search, and all the other Pulumi Cloud features.

Extensibility: You can leverage the out of the box New Project Wizard Experience or build developer portals with Pulumi yourself using any combination of: the Pulumi Backstage Plugin, pulumi new public and private templates, Automation API, Pulumi Deployments, or the Pulumi Cloud REST API.

Getting Started

New Project Wizard

The New Project Wizard allows anyone in your organization to pick a template they want to install, create the repo or directory for it, and walk through configuring the deployment of that template. We’ve added support for configuring Pulumi Deployments, meaning any template can be deployed without needing the Pulumi CLI locally, or any other CI/CD configuration. Follow these steps to be up and running with your infrastructure in a few clicks:

You can either 1/ use the UI or 2/ use Deploy with Pulumi buttons. If using the UI, navigate to the “New Project” tab. Select “Use a template” if you’d like to create a fully featured project, or select “Use a starter” if you want to create a bare-bones project with only the minimal necessary boilerplate file structure and Pulumi code. If you are using Deploy with Pulumi buttons, you can embed a button on your templates inside GitHub to enable point-and-click deployment of those templates.
In order to use templates you will need to authorize Pulumi with GitHub so that it can clone private repositories as template sources and commit new code for your projects. Click the “Authorize GitHub” button and accept the required permissions if you would like to use templates.
On the next screen select your deployment method. You may need to install the Pulumi GitHub app if you haven’t already to use Pulumi Deployments.
You’ll now be prompted to enter some information about the project you’re about to create: the project and stack name, the configuration details specific to that template, the repo to use when committing your new project code, and optionally the Environment you want to use. Environments enable you to use a bundle of pre-configured secrets and configuration values without needing to re-specify all of them during project creation.
After you’ve configured your project settings, you will be able to configure the behavior of Deployments, including when to trigger new Deployments and environment variables to include with your updates.

And just like that you have created a new project from a template that is deployed, without the use of the Pulumi CLI.

Organization Templates

Pulumi now allows customers on the Pulumi Cloud Enterprise and Business Critical editions to define Organization Templates to help get projects off the ground faster. A Pulumi organization admin can specify an Organization Template Source (or Sources) which will then be populated in the New Project Wizard experience described above.

Navigate to the “Integrations” tab to define your Organization Templates Source. Enter sources as github.com/<owner>/<repo>/<optional subdirectory>. A source can be a directory containing either a Pulumi.yaml, or other subdirectories with their own Pulumi.yaml files. A single repository can provide multiple templates from various subdirectories. For example, these are both valid sources: github.com/pulumi/templates (all public Pulumi templates) and github.com/pulumi/templates/aws-typescript (a specific public template).

The Pulumi.yaml file can optionally contain a template section, which typically includes a config section for specifying required config values for the project. Each config value can have a description and a default value which can be overridden. Config values can be marked as secret, which ensures values in templated projects will be stored with secure encryption.

name: my-aws-project
runtime: nodejs
description: My AWS project description
template:
 config:
 aws:region:
 description: The AWS region to deploy into
 default: us-west-2
 myAccessToken:
 description: My access token
 secret: true

The above snippet includes an aws:region configuration value with a default value of us-west-2, as well as a myAccessToken secret without a default value.

Pulumi & Backstage

We’ve seen many developer portal technologies rapidly growing in popularity over the last few years. In particular, we’ve seen Pulumi users adopting Backstage and as a result we built the Pulumi Backstage Plugin to address the needs of organizations using Backstage and Pulumi together. There are now two ways to use Pulumi from within Backstage, you can leverage both or just one or the other:

Pulumi Scaffolder Backend Module
Pulumi Backstage Plugin

Pulumi Scaffolder Backend Module: The Pulumi Scaffolder Backend Module extends the scaffolding with two new actions: Pulumi New and Pulumi Up. The Pulumi New action is a custom action that allows you to create a new Pulumi project from a template using the pulumi new Pulumi CLI command. The Pulumi Up Action is a custom action that allows you to run the pulumi up command, which creates or updates resources in a stack.

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
 name: kubernetes-template
 title: Kubernetes Cluster
 description: |
 A template for creating a new Kubernetes Cluster.
 tags:
 - pulumi
 - kubernetes
spec:
 steps:
 - id: pulumi-new-component
 name: Cookie cut the component Pulumi project
 action: pulumi:new
 input:
 name: "${{ parameters.component_id }}-infrastructure"
 description: ${{ parameters.description | dump }}
 organization: ediri
 stack: ${{ parameters.stack }}
 template: "https://github.com/my-silly-organisation/microservice-civo/tree/main/infrastructure-${{ parameters.cloud }}-${{ parameters.language }}"
 config:
 "node:node_count": "${{ parameters.nodeCount }}"
 folder: .

With a few clicks, developers can create new software projects provisioned with best practices, with code managed in the right repositories, and with the right configurations, all from a self-service UI.

Pulumi Backstage Plugin: Backstage Plugins are extensions or add-ons to the core Backstage application that allow you to integrate additional tools, services, and functionalities into the platform, enhancing its capabilities and customizing it to meet the specific needs of your development environment.

The Pulumi Backstage Plugin extends Backstage by displaying essential details like the Pulumi stack, organization, project name, and description, as well as providing an activity view with aggregated information from the Pulumi Cloud. See a screenshot of the new Pulumi tab within Backstage below:

Check out the Pulumi Backstage Plugin in the Backstage Plugin directory or the Roadie Pulumi Backstage Plugin guide to get started today.

Wrapping it up

The launch of this new functionality for internal developer portals marks a significant step forward in our commitment to providing powerful, turn-key tools for platform teams. We believe these features will enhance your experience with Pulumi, whether you’re a seasoned cloud expert leading a team of platform engineers or just getting started on your IaC journey.

As always, we welcome your feedback in the Pulumi Cloud Requests repository and are here to support you every step of the way on your platform engineering journey.

Announcing Microsoft Teams Webhook Integration for Pulumi Cloud

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

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

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

See it in action!

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

Setting up the Microsoft Teams Integration

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

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

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

Pulumi Cloud REST API

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


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

Pulumi Service Provider

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

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

const orgName = "my-org";

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

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

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


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

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

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

import pulumi
import pulumi_pulumiservice as pulumiservice

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

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

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

package main

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

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

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

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

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

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

package generated_program;

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

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

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

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

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

Wrapping up

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

Happy building! 👷

Admin Organization Access Tokens in Pulumi Cloud

Meagan Cojocar — Mon, 28 Aug 2023 00:00:00 +0000

Last year we launched Organization Access Tokens for Pulumi Cloud, service tokens not tied to individual users, ideal for garnering programmatic access for continuous integration and continuous delivery (CI/CD) tools and other automated processes. After launching this feature we saw record level adoption, with a majority of customers who could use it creating Organization Access Tokens within a matter of weeks.

Organization Access Tokens have member level permissions, meaning they can be used to perform actions that a member has permissions to perform. We heard from multiple customers that being able to provision access tokens with admin level permissions would light up several programmatic use cases. Today we are launching an Admin permission scope for Organization Access Tokens: increased privileges for when you need them.

See it in action!

Increased Privileges

Admin Organization Access Tokens have elevated permissions, please use them with caution.

Admin Organization Access Tokens can perform many actions that a regular Organization Access Token can not. Here are some of the actions you can now perform with a token that were previously not possible:

Transferring stacks
Adding and removing users in your organization
Update team membership roles
Add and remove stacks from Teams
Add and remove Team Access Tokens
Get audit log events

For a full list of all actions that can be performed by each access token type please refer to the Access Token documentation.

Wrapping up

Organization Access Tokens are available to Enterprise and Business Critical customers, as well as on our 14-day trial. You can start a trial or Contact Us about the Pulumi Service Enterprise Edition and Business Critical Edition to take it for a spin!

As always, submit any feedback on the feature in the Pulumi Cloud Requests repository.

Resource Search - AI Assist is Generally Available

Meagan Cojocar — Mon, 07 Aug 2023 08:42:44 -0700

Pulumi Cloud Resource Search AI assist functionality is now generally available to all organizations! In addition we have shipped some improvements to the feature to make it easier to use and more discoverable: a toggle on the search bar, suggested queries and an “I’m Feeling Lucky” button to generate a random query for you.

See it in action below!

AI Assist is Generally Available

Resource Search AI assist is a way to search your Pulumi organization using natural language. We launched it in a private beta in April this year. Previously only customers who requested private beta access have been able to leverage natural language resource search, starting today customers on any edition of Pulumi Cloud, AI assist is generally available. You can provide a plain English (or Spanish, or French, or Japanese!) request, to express queries where you might not know the exact syntax, type tokens, or package names. AI Assist makes it easier to gain insight over infrastructure, using queries like:

show me all s3 buckets not tagged in production
show azure and azure native security groups
show all AWS VPCs

Suggested Queries and I’m Feeling Lucky

A blank search bar can be intimidating. We now have suggested natural language searches to get you up and running faster. We also added “I’m Feeling Lucky” functionality that generates random queries for you. This can be a good way to quickly understand the types of insights Resource Search can deliver for your organization.

Wrapping Up

As always, submit any feedback on the feature in the Pulumi Cloud Requests repository.

Announcing Restore Stacks: Recover Deleted Stacks in the Pulumi Cloud

Meagan Cojocar — Wed, 19 Jul 2023 00:00:00 +0000

This post announced the Restore Stacks feature. For the most up-to-date information on recovering deleted stacks, see the Restoring deleted stacks documentation.

Starting today, you can restore previously deleted stacks in the Pulumi Cloud console. We’ve had a number of requests from customers to recover stacks, either because the stack was accidentally deleted or the stack was intentionally deleted but, later on, they want to restore and preserve the activity history on the stack and just remove its resources.

Customers often use pulumi destroy to delete the resources in a stack but leave the state file. If they want to delete the state file they use pulumi stack rm. Customers might also use pulumi stack rm --force, which forces the deletion of the state file but leaves behind its resources and in doing so you lose the ability to manage those resources going forward. There are cases where a force delete is a valid choice, but at Pulumi we sometimes receive customer support tickets when someone runs pulumi stack rm --force accidentally. One of the benefits of using Pulumi Cloud is that it maintains state file versions enabling Pulumi to be able to restore deleted state files. Starting today we have built this recovery process into the product, allowing customers to self-serve restoration of deleted state files.

See it in action

And tada 🎉, you how have a trash bin for your stacks! To recover a deleted stack, organization admins should navigate to the Stacks page. Next to the Create Project button there is a three dot menu to transfer stacks and restore stacks. Click on restore stacks to navigate to your recently deleted stacks. The last 25 deleted stacks in an organization can be restored, if you need a stack restored that is older, contact support.

Keep the feedback coming

As always, submit any feedback on the feature in the Pulumi Cloud Requests repository.

Property Search: Enhanced Resource Search in Pulumi Cloud

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

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

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

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

Feature Overview

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

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

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

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

Example queries

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

AI Assist & properties

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

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

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

Search syntax

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

Here are some query examples we have seen customers use:

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

Use the REST API

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

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

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

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

console.log(body);

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

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

console.log(body);

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

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

print(r.json())

package main

import (
 "bytes"
 "net/http"
)

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

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

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

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

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

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

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

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

 //Validate result
 response.EnsureSuccessStatusCode();

 }

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

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

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

Wrapping it all up

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

Happy searching!

Announcing Slack and Deployment Notifications for Pulumi Cloud

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

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

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

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

Slack integration

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

Setting up the Slack Integration

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

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

Create a Slack app from manifest

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

Pulumi Cloud REST API

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


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

Pulumi Service Provider

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

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

const orgName = "my-org";

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

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

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


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

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

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

import pulumi
import pulumi_pulumiservice as pulumiservice

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

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

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

package main

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

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

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

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

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

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

package generated_program;

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

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

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

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

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

Pulumi Deployment Notification Events

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

Filtering Notification Events

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

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

Wrapping up

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

Happy building! 👷

Pulumi Release Notes: Resource Search, Deployment Actions, Projects in Self-Managed Backends, and more

Mikhail Shilkov — Wed, 24 May 2023 00:00:00 +0000

We have been busy shipping improvements in the last 2 months. Let’s walk through the release highlights across Pulumi engineering areas from March and April. If you want to learn more between release blogs, follow the CLI improvements in the pulumi/pulumi repo changelog and Pulumi Cloud features in the new features blogs.

Quick shortcuts to jump to your favorite area:

Pulumi CLI
Pulumi Automation API
- Manage Stack Tags
- Full “Who Am I” command support
Cloud Providers and Packages
Pulumi Cloud & Pulumi.com

Pulumi CLI

Aligning Projects between Service and Self-Managed Backends

While the majority of Pulumi users do choose to use Pulumi Cloud, we also know that there are good reasons why some organizations would prefer to use Pulumi IaC alone without Pulumi Cloud. The self-managed backends have historically stored all stacks in a single namespace across all projects.

With the 3.61.0 release of Pulumi, we’ve added support for project-scoped stacks to the Self-Managed backend. Stacks created in new or empty self-managed backends will automatically use the new project-scoped layout.

👉 Learn more in the Aligning Projects between Service and Self-Managed Backends blog post.

Improved Interactive Scrolling Experience

We’ve improved the user experience of deploying a large number of resources interactively in the CLI. The recent changes make two improvements to scrolling through a long list of action:

The interactive display can now be scrolled using the page-down and page-up keys. These keys scroll the display N lines at a time, where N is the height of the terminal.
If the display is scrolled to the bottom, it will now autoscroll it as new lines are added to the output.

👉 Learn more in the Improve interactive scrolling pull request.

Shortcut to See the Current Update in Web Browser

While a CLI preview or update operation is running, you can now use the Ctrl-O keyboard shortcut to open the same update in Pulumi Cloud using your web browser.

The shortcut and the Pulumi Cloud URL are shown at the top of the update operation:

$ pulumi up
Previewing update (dev)
View in Browser (Ctrl+O): https://app.pulumi.com/mikhailshilkov/dev-ts/dev/previews/01234567-ec03-4ccc-9b44-02ec864e14ee
Type Name Plan
+ pulumi:pulumi:Stack ts-dev create...

👉 Learn more in the Open in Web Browser shortcut pull request.

New Flag to Specify Teams for a Newly Created Stack

We’ve added a --teams flag to pulumi stack init command. The flag accepts a string and can be provided multiple times. Each team that is provided is assigned read/write permissions on the stack after it has been initialized.

$ pulumi stack init dev-stack --teams devs

👉 Learn more in the Add –teams flag to assign team name to stack pull request.

Visual Indication of Retained Resources

You can use the RetainOnDelete resource option to let Pulumi retain the actual cloud resource while deleting it from your Pulumi stack. This option is useful, for instance, when you need to start managing the same resource from another stack or project.

Now, the CLI will explicitly mark deleted or replaced resources as retained in the cloud. See the Plan column of the preview view:

👉 Learn more in the Retain display pull request.

View More Details in Stack History

Sometimes, to troubleshoot a past action, you would want to see more details about the context of a past CLI operation. We’ve added more details to pulumi stack history command output, so that you could see the names of CLI parameters, the names of environment variables, the version of the Pulumi CLI, and OS architecture:

No sensitive information like parameter or environment variable values is captured or displayed.

👉 Learn more in the Add more details to pulumi stack history pull request.

Pulumi Automation API

Manage Stack Tags

We’ve added support to set, get, list, and remove tags on Pulumi stacks. Shoutout to Matthew Rodrigues for contributions in this area!

👉 Learn more in the Ensure Parity for Stack Tags issue.

Full “Who Am I” command support

The pulumi whoami CLI command now added a --json flag. The same flag is consumed from the Automation API to return user’s organization and URL in addition to the user name.

Another shoutout to Matthew Rodrigues for the contribution!

👉 Learn more in the WhoAmI JSON flag pull request.

Cloud Providers and Packages

Every week we keep shipping provider updates. A few highlights on our native providers:

Kubernetes shipped support for v1.27.0 and all its resources (changelog)
Azure Native shipped six new resources for containerstorage, guestconfiguration, and hybridcloud (releases)
AWS Native shipped 33 new resources in apigatewayv2, appconfig, chatbot, comprehend, connect, datasync, devopsguru, ec2, frauddetector, lambda, msk, neptune, quicksight, ram, sagemaker, ssmcontacts, and vpclattice modules (changelog)

Two new community packages were added to the Registry:

AzAPI - shoutout to Engin Diri
StrongDM - shoutout to Piers Karsenbarg

Pulumi Cloud & Pulumi.com

Resource Search Improvements

More Advanced Filtering

Based on customer feedback we have extended the number of advanced filtering options (Stack, Project, Package and Type) to show the top 10 results by resource count instead of top 3. We know our customers are getting a ton of value from these aggregates to inform and refine their searches and expect the 7 additional values to improve this further.

Pulumi Teams support

Customers who use Pulumi Teams for role based access control on Pulumi Cloud can now filter resources by team access. We have added a new aggregate on the Resource Search page for Teams, allowing you to see at a glance the teams in your organization with the most resources. You can query which teams have access to what resources, track resource usage by team by exporting your resource data and see in the search results table which teams have access to that resource.

Events Dashboard card

We have added a new card to the organizations dashboard which shows upcoming Pulumi events and Pulumi workshops to give users a central place to see events of interest.

Stacks Page Icons

We have added icons on the Stacks page to enable you to see at a glance information about your Pulumi Stacks, such as if Policies are being applied, if Pulumi Deployments is configured for that stack and the resource count. In addition, there is now a quick action menu on each stack to jump to configuring Pulumi Deployments and adding it to a Policy.

Deployment Actions

You can now view the Pulumi Deployments Click-to-Deploy menu on all stack pages, even if not configured to Pulumi Deployments. This allows users to quickly navigate to Deployments Settings to connect the stack.

SAML Admin

For customers on the Enterprise or Business Critical Editions of Pulumi Cloud there is a new role for a SAML admin in your organization. SAML Admins can add another identity to authenticate when SAML is the only permitting authentication method. This could be an email and password or another authentication method, like GitHub. We are slowly rolling this out across our customer base, if it is not yet in your organization you should expect it in the coming weeks.

Pulumi Resource Search: Find the Needle in the Haystack

Meagan Cojocar — Fri, 19 May 2023 00:00:00 +0000

Last month we announced a new Pulumi Cloud feature available for everyone: Resource Search. In the past month, Resource Search has been the fastest adopted feature since launching Pulumi Cloud, with thousands of users leveraging the feature to find resources across cloud environments, projects, stacks, teams, and users. Today we are announcing two new improvements to Resource Search: advanced filtering and Pulumi Teams support.

Introduction to Resource Search

Platform and developer teams are spinning up resources across many cloud accounts within multiple cloud providers. A common pain point we have heard from our customers is having a uniform view of resources across them, as every account (by design) is a walled garden. Often to answer key questions about their business, such as “which team has the largest cloud footprint”, teams need to combine data across various clouds, cloud accounts, and SaaS tools. This prevents organizations from getting quick answers to operational questions and barriers to build aggregations to derive insights.

Pulumi Resource Search offers multi-cloud search and analytics across every environment in your organization. You can issue queries that find all of your AWS VPCs, or all of your VPCs in AWS and Azure, or all resources with the “production” tag across all cloud environments. You also have access to statistics about cloud usage, including a breakdown by cloud provider, resource type, and department. Resource search enables you to find the needle within your cloud haystack and visualize cloud consumption trends.

When we undertook solving this pain point for our customers we partnered with multiple companies to inform the design. Without the dozens of organizations that participated in the Pulumi Resource Search private beta we would not have been able to release a feature with strong adoption in a short time frame. Today we are announcing two improvements to Resource Search as a result of this feedback: more advanced filtering options and Pulumi Teams support.

See it in action!

Feature Overview

Pulumi Resource Search is composed of:

Query syntax: Infrastructure can be discovered interactively with a rich, structured query language, for example package:snowflake.
AI Assist: A natural language query interface that generates the query syntax for you. You can use it to express queries where you might not know the exact syntax, type tokens, or package names. You can join the waitlist for access to this additional functionality for search.
Search advanced filtering: Advanced filtering allows you to see aggregations over your data at a glance, such as top stacks, projects, providers, teams and types by resource count. Additionally, if you are searching for something specific they can help you understand the shape of your search results and further refine them.
Search API: We understand that console searches aren’t the only way our customers want to utilize Resource Search. To meet this need, we’re also launching new Resource Search API endpoints, allowing you to integrate Resource Search into your internal systems and workflows. Use the API to add search functionality to your Internal Developer Platform or create automation around search results. API spec details are in the Pulumi Service REST API documentation.
Data Export: Export resource data to ingest in your data warehouse. This will be covered in more detail in a future blog post, stay tuned!

Query Syntax

It can be helpful when picking up a new feature to see some example queries that you can edit for your organization. See below a list of example query syntax queries:

See all resources that have not been modified in a year

modified:<=2022-05-18

See all resources with a certain tag in your cloud provider

type:aws:s3/bucket:Bucket tags.costcenter:1234

Find the Snowflake resources used in your data engineering team

package:snowflake stack:production team:data

Find resources in a project that aren’t in a certain stack

package:aws project:pulumi-cloud-import-aws stack:-staging-us-west-2

AI Assist Examples

show me all virtual machines across all cloud providers

(type:aws:ec2/instance:Instance OR type:azure:compute:VirtualMachine OR type:gcp:compute:Instance)

show me all s3 buckets not tagged in production

(type:aws:s3/bucket:Bucket -tags.enviornment:production

show azure and azure native security groups

((type:azure:network:NetworkSecurityGroup OR type:azure-native:network:NetworkSecurityGroup)

Advanced Filtering & Pulumi Teams support

The new advanced filtering menu!

When navigating to the Resources page you will find your top 3 resource types, projects, stacks, teams and packages by resource count. We have extended this to show the top 10 when you click ‘Show more’. This came as a direct byproduct of the feedback we have gotten from our customers that this feature added value upon first page load, and having more items would make it even more valuable.

Customers who use Pulumi Teams for role based access control on Pulumi Cloud can now filter resources by team access. We have added a new advanced filter option for Teams, allowing you to see at a glance the teams in your organization with the most resources. You can query which teams have access to what resources, track resource usage by team by exporting your resource data and see in the search results table which teams have access to that resource.

Wrapping it up

Resource Search is available to all Pulumi users for free, making it even easier to manage your cloud resources and gain valuable insights into your infrastructure. It’s just one of the many ways Pulumi continues to innovate and support organizations in their journey to the cloud. Try Resource Search today and see the difference it can make in helping you explore and find resources in your organization.

Pulumi Deployments: API-Driven Infrastructure at Scale

Evan Boyle — Wed, 29 Mar 2023 00:00:00 +0000

Delivering software has been conventionally driven by CI/CD workflows. A single commit is merged into a codebase, and a small, and static set of workflow runs are triggered by the CI system to update the appropriate environments (Dev -> Staging -> Production). This may have been fine when the only product a company had to offer was a single stateless web service, but increasingly companies are called upon to deliver cloud infrastructure as a product.

There are obvious forms of this, such as IaaS companies building database-as-a-service offerings and SaaS companies deploying self-hosted installations into customer environments. But there are less apparent forms like internal platform teams that are chartered with enabling self-service of Kubernetes clusters configured with best practices to thousands of application engineers within an enterprise. In any of these cases, engineers are delivering infrastructure as the product but only have conventional tools like gitops and CI/CD to reach for.

The assumptions that CI/CD systems make are limiting for infrastructure. We are not pushing a single application commit across three environments. We are templating infrastructure hundreds and thousands of times. Once that infrastructure is templated, we’re responsible for ensuring it is secure, up-to-date, and can be customized by self-service users. CI/CD is a poor fit due to the design choices that are locked in around source control and source events. CI/CD is typically configured via templated YAML that is checked into source control, with no way to create or customize behavior dynamically from a REST API. And beyond configuration, there aren’t REST APIs for triggering updates and workflow runs. The best you can expect is the ability to add more YAML to configure a cron job. What do you do if you need to create a self-service platform, or configure CI/CD across thousands of projects across your organization?

Today we’re excited to announce the release of a new version of Pulumi Deployments, a fully managed platform for shipping infrastructure at scale. It provides:

Compute - run infrastructure deployments and workloads (i.e. pulumi up) on fully managed, secure, and elastic compute.
Configuration - A simple, centralized format for specifying everything you need to deploy your infrastructure at the stack level. Source code, cloud credentials, OpenID Connect (OIDC), environment variables, build prerequisites, and dependencies are bundled in an atomic unit.
Composition - Trigger deployments via our REST API, click to deploy in the Pulumi Service UI, Git Push to Deploy, Remote Automation API, and other programmatic building blocks that you can compose to build custom cloud automation.

Pulumi Deployments is built on top of a powerful set of public REST APIs. Unlike any other platform, Deployments lets you configure CI/CD settings programmatically. Service-catalog scenarios and guard rails that enforce CI/CD best practices across thousands of projects are far easier to achieve when you have REST APIs that you can build software on top of. No more generating and templating YAML to configure infrastructure deployments at scale.

Deployment Settings and Triggers

Deployments can be configured at a stack level via Deployment Settings in three ways:

The Pulumi Service UI enables setting up OIDC and git push to deploy in just a few clicks
The Pulumi Service Provider lets you define deployment configuration as Pulumi code in you language of choice, reviewed and managed in source control.
The Deployment Settings REST API provides programmatic access to configure Deployments and CI/CD dynamically, without needing to generate or check in YAML.

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

const config = new pulumi.Config();

// deployment settings configured via a pulumi program
const settings = new service.DeploymentSettings("deployment_settings", {
 organization: "service-provider-test-org",
 project: "test-deployment-settings-proj",
 stack: "dev",
 operationContext: {
 environmentVariables: {
 TEST_VAR: "foo",
 SECRET_VAR: config.requireSecret("my_secret"),
 }
 },
 sourceContext: {
 git: {
 repoUrl: "https://github.com/pulumi/deploy-demos.git",
 branch: "refs/heads/main",
 repoDir: "pulumi-programs/simple-resource"
 }
 }
});

Each stack configured with Pulumi Deployments gets access to a number of triggers that can be used to start a Pulumi operation (i.e. pulumi up):

Deployments REST API - an endpoint available at api.pulumi.com that can trigger a variety of pulumi (up/destroy/refresh/preview) operations. Calls to this trigger can override individual settings to customize deployment behavior (i.e. - deploy a different branch, or override a particular environment variable).
git push to Deploy - Deep integration with the Pulumi GitHub App that enables automatic previews on every pull request, and an automated update whenever code is pushed to the target branch.
Click to Deploy - trigger a deployment from the Pulumi Service Console with the push of a button. Very useful for day-to-day operational activities such as debugging a stuck stack, or rectifying drift via a refresh without having to pull a stack and its accompanying source code onto your machine.
Remote Automation API - Your favorite strongly typed Pulumi orchestration tool, Automation API, lets you offload update workloads into the cloud. Write deployment scripts that update thousands of environments simultaneously without worrying about compute.

You can mix, match, and compose Deployment Settings and Triggers to create a golden path to production that is perfect for your enterprise’s needs.

Example: Building RESTful Infrastructure APIs

Increasingly, infrastructure updates happen in response to user action and not source control events like a git commit. For instance, a SaaS database company might need to spin up dedicated compute and storage when a customer puts in a credit card and self-serves onto a specific SKU. This signup workflow might happen hundreds or even thousands of times an hour. Traditional deployment systems are optimized for infrastructure that spans, at most, a handful of environments (dev/staging/production).

Leading SaaS and infrastructure companies want the best of both worlds:

Custom, domain-specific REST APIs to create infrastructure on demand.
Desired state configuration that keeps track of what is deployed, and where.

You can build on top of the Deployments REST API to build your own infrastructure APIs. Here we have a simple Go web server that offers a RESTful interface over top of a static website. Users can create, update, and delete static websites, specifying the content for the site in the POST payload. Here’s our web server:

 router := httprouter.New()
 router.POST("/sites", server.create)
 router.GET("/sites/:id", server.get)
 router.POST("/sites/:id", server.update)
 router.DELETE("/sites/:id", server.delete)

 http.ListenAndServe(*addr, router)

Within the create handler, we first dynamically configure Deployment Settings for the stack, including the branch of the Pulumi program to be deployed, the AWS OIDC provider used for cloud credentials, and the configuration of git push Deployment Triggers`:

 err := s.client.patchDeploymentSettings(r.Context(), s.org, s.project, stack, DeploymentSettings{
 SourceContext: &sourceContext{
 Git: gitContext{
 Branch: s.branch,
 RepoDir: s.dir,
 },
 },
 OperationContext: &operationContext{
 Environment: map[string]string{
 "AWS_REGION": s.region,
 },
 OIDC: &oidcContext{
 AWS: &awsOIDCContext{
 RoleARN: s.roleARN,
 SessionName: s.sessionName,
 },
 },
 },
 GitHub: &gitHubContext{
 Repository: s.repository,
 Paths: paths,
 DeployCommits: true,
 PreviewPullRequests: false,
 },
 })

These settings configure the stack to trigger an update when new commits are pushed to the branch. In addition, our create handler also kicks off the initial update to create the infrastructure:

err = s.client.createDeployment(ctx, s.org, s.project, stack, createDeploymentRequest{
 DeploymentSettings: DeploymentSettings{
 OperationContext: &operationContext{
 Environment: map[string]string{
 "SITE_CONTENT": content,
 },
 },
 },
 InheritSettings: true,
 Operation: "update",
 })

Notice how this REST API call specifies InheritSettings: true so that Deployment Settings are read from the Pulumi Service and merged with the incoming request payload to create deployment configuration for this run. This stack also has to Click to Deploy via the Pulumi Service UI, so operational tasks like refreshing the stack can be done on demand without pulling down source code onto your local machine.

The Deployments Platform does all of the heavy lifting of managing deployment compute, providing asynchronous workflow orchestration, queueing, status and logging API access, and more. At the end, you get a Pulumi Stack and state file containing a manifest of all cloud resources and their properties managed by the Pulumi Service.

Deployment Settings and Triggers can be combined to ship infrastructure in novel ways with just a few lines of code. See the full RESTful infrastructure API example to try it out yourself.

Pave your Golden Path Today

Pulumi Deployments is the platform for shipping infrastructure at scale. It gives you the programmatic building blocks you need to deliver infrastructure on demand in a large organization. Get started with Deployments today. Happy automating!

Pulumi Release Notes: Colorized Stack Traces, Output Methods for JSON, OIDC integration, and much more!

Mikhail Shilkov — Wed, 22 Mar 2023 00:00:00 +0000

We have been busy shipping improvements in the last 2 months. Let’s walk through the release highlights across Pulumi engineering areas from January and February. If you want to learn more between release blogs, follow the CLI improvements in the pulumi/pulumi repo changelog and Pulumi Service features in the new features blogs.

Quick shortcuts to jump to your favorite area:

Pulumi CLI
Pulumi Language SDKs
Pulumi Automation API
- Adding tags to stacks through Automation API
- Support cloning from Azure DevOps in Automation API
Cloud Providers and Packages
Pulumi Service & Pulumi.com
- OIDC integration
- Pulumi Deployments

Pulumi CLI

Colorized stack traces for Node.js errors

When an error happens in a Pulumi program, stack traces can be instrumental to understand the reasons behind the failure. Stack traces can often be large and contain frames unrelated to user code, which makes debugging harder.

We have now changed the CLI to display Node.js stack traces with colors, where the important bits are highlighted and less important parts faded out. The new display technique helps draw attention to relevant details and is similar to running vanilla node programs.

👉 Learn more in the Emit colorized stack traces pull request.

New –shell option for `pulumi stack output`

We added a new --shell option to the pulumi stack output command that writes the outputs for a stack as a shell script:

% pulumi stack output --shell
bucketName=mybucket-1234
websiteURL="http://mybucket-1234.example.com"

On Windows, it will produce a Powershell script:

% pulumi stack output --shell
$bucketName = 'mybucket-1234'
$websiteURL = 'http://mybucket-1234.example.com'

As a result, Pulumi users are now able to write shell scripts like the one below:

eval "$(pulumi stack output --shell)"
echo "Created bucket $bucketName"
# => Created bucket mybucket-1234

echo "Visit at $websiteURL"
# => Visit at http://mybucket-1234.example.com

👉 Learn more in the Add –shell option pull request.

`pulumi new` in directories with source control

By default, pulumi new won’t run unless the current directory is empty to avoid overriding any existing files. This behavior meant that the command failed in directories with initialized source control.

We shipped an improvement where Pulumi CLI will ignore .git, .hg, and .bzr files and directories when considering whether a directory is empty.

👉 Learn more in the Ignore VCS directories pull request.

Support plugins hosted in GitLab

Pulumi comes with a wealth of packages but users can also create and use custom providers and components. By default, Pulumi expects the binaries to be hosted on GitHub. On top of that, the CLI now supports GitLab as a first-class source of package downloads.

If your package binary is hosted on GitLab, you can now set its pluginDownloadURL property (see Publish your package) to point to your GitLab project, e.g. to gitlab://gitlab.com/43429536.

👉 Learn more in the Support custom plugins from other sources issue.

Use access tokens to authenticate to Google Cloud backend

When storing the state files in Google Cloud backend, you can now authenticate to the Google Cloud Storage using Google access tokens. If the environment variable GOOGLE_OAUTH_ACCESS_TOKEN is set during a pulumi login gs://..., Pulumi will utilize the provided token to login to the bucket, assuming this has not been preempted by another authentication type.

👉 Learn more in the Pulumi login to support google oauth access tokens for GCS buckets pull request.

Delete temporary files from plugin downloads

While a plugin is being installed, the CLI downloads the necessary archive and stores the archive in /tmp/pulumi-plugin-tar*. The CLI is now more mindful of cleaning the temporary file after plugin installation completes to save disk space.

👉 Learn more in the Delete temporary files from plugin downloads pull request.

“Yes, using Update Plans” prompt removed

Update Plans is a preview feature to constrain the update only to the operations that were planned during preview. To get extra feedback from our users, we experimented with showing an extra option “yes, using Update Plans” at the update prompt. The experiment is now complete, so we removed the option.

Lean more in the Remove the “yes, using Update Plans” prompt issue.

Pulumi Language SDKs

Output methods to serialize and deserialize JSON

Building JSON from values and parsing strings into JSON are two of the most common operations in Pulumi programs. All programming languages have built-in libraries to do so. However, quite often JSON operations need to be combined with Pulumi Inputs and Outputs, which required writing a cumbersome combination of Apply and serialization method calls.

To streamline this experience, Pulumi SDKs shipped helper serialization and deserialization functions that understand the type Output<T> natively. Here is a simple usage example in Python, where table.arn is an output coming from another resource:

policy = iam.Policy(
 "iam-policy",
 policy= Output.json_dumps({
 "Version": "2012-10-17",
 "Statement": [{
 "Action": [
 "dynamodb:PutItem",
 "dynamodb:GetItem"
 ],
 "Effect": "Allow",
 "Resource": [table.arn]
 }]
 }))

👉 Learn more in the Output methods issue that also tracks a number of further additions to the toolset of helper methods.

Retrieve stack reference outputs as plain values

You can read outputs from one stack in another stack’s program using Stack References. In the past, the resulting values were always wrapped inside an Output<T> container in order to preserve secret values (when needed).

With recent SDKs, we shipped an alternative method StackReference.getOutputDetails. This method returns a plain object with two fields: value and secretValue. At most one of these fields is set, depending on whether the stack reference output is a secret or not.

If you know that the output is not a secret, you can write a program to use the plain value immediately, for example, to iterate though a list in a loop and create resources in each iteration.

👉 Learn more for each language:

Native arm64 binaries in Python SDK

Pulumi Python SDK has been upgraded to use the grpcio library version 1.51.3, which comes with a wheel with native arm64 binaries (universal2). The change eases the installation of the Pulumi Python SDK on Apple M1/M2 machines.

👉 Learn more in the Python grpc 1.51.3 contains universal2 binaries pull request.

Go version raised to 1.18

The minimum version of Go required by Pulumi was raised to 1.18. Raising this directive allows us to use language features like generics in the codbase. The change is applied to both pkg and sdk.

👉 Learn more in the go.mod: Raise to ‘go 1.18 pull request.

Delegate alias computation to the engine

Sometimes, two classes in Pulumi SDKs represent the same cloud resource. To enable migration from one to another, Pulumi sets aliases for those classes and declares them to be compatible.

In the past, each SDK was responsible for calculating all possible alias combinations for a given resource and its inherited parent. We recently added support in the engine for this computation along with an optimization to reduce complexity from a multiplicative factor to a linear one.

As a follow-up step, we updated our SDKs to only provide the base aliases, and allow the engine to do this computation. This enables smaller SDKs and faster runtime performance, especially for longer chains of parented resources. Other than that, the user experience hasn’t changed.

👉 Learn more in the Delegate alias computation from SDKs to Engine issue.

Pulumi Automation API

Adding tags to stacks through Automation API

You can now use Automation API to get, set, list, or remove tags on stacks programmatically. Here is a quick example in TypeScript:

const workspace = await LocalWorkspace.create({
 projectSettings: projectSettings,
});
await workspace.createStack(stackName);
await workspace.setTag(stackName, "foo", "bar");
const tags = await workspace.listTags(stackName);
// tags will contain tags for `pulumi:project`, `pulumi:runtime`, and `foo` keys.

👉 Learn more in the Add support for adding tags to stacks through Automation API issue.

Support cloning from Azure DevOps in Automation API

We implemented a workaround to support Azure DevOps repositories when driving Pulumi from Automation API in Go. This is now also utilized in the Pulumi Kubernetes Operator.

👉 Learn more in the Support clones from Azure DevOps pull request.

Cloud Providers and Packages

Every week we keep shipping provider updates. Two highlights on our native providers:

Azure Native shipped 20 new resources, including support for networkcloud and voiceservices (changelog)
AWS Native shipped 30 new resources in apigatewayv2, appflow, applicationautoscaling, cloudtrail, connect, directoryservice, ec2, fms, gamecast, gamelift, kendraranking, networkmanager, omics, organizations, sagemaker, secretsmanager, simspaceweaver, and systemsmanagersap modules (changelog)

Five new community packages were added to the Registry: Vultr, Zscaler Private Access (ZPA), Zscaler Internet Access (ZIA), Statuscake, and Nuage.

Pulumi Service & Pulumi.com

After launching Pulumi Deployments a few months ago and receiving a ton of community feedback (thank you!) we launched an integration with OpenID Connect (OIDC) to enable security first deployments and industry best practices.

OpenID Connect (OIDC) is an identity layer built on top of the OAuth 2.0 framework. It allows third-party applications to verify the identity of the end-user and to obtain basic user profile information. OIDC uses JSON web tokens (JWTs), which you can obtain using flows conforming to the OAuth 2.0 specifications.

Overview

The main benefits of using the OIDC integration for Pulumi Deployments are as follows:

Temporary credentials: You can move away from long term credentials within your organization to leverage temporary credentials that are generated every time a deployment runs. The Pulumi Service issues a new OIDC token that is limited to that deployment. This token is used to obtain cloud credentials that automatically expire, meaning you do not need to store sensitive credentials that are reused with each deployment.
Granular access control: The OIDC token generated by the Pulumi Service contains detailed information about the deployment with which it is associated. In AWS for example, you can configure our OIDC integration to only use temporary credentials if that token is associated with a particular Pulumi stack or Pulumi organization. This enables you to follow the principle of least privilege access and scope access down to only what is needed. For AWS, Azure, and GCP, Pulumi Deployments can automatically exchange its OIDC token for temporary credentials and make those credentials available to providers. For advanced scenarios or other cloud providers, the OIDC token can be manually exchanged for credentials by the user.

👉 Learn more on how to get started with Pulumi Deployments OIDC by reading the blog post.

If you haven’t yet tried out Pulumi Deployments

You should now see a “Deploy” tab under Stack Settings in the Pulumi Service console and have access to the Deployments REST API. View the documentation for help getting started and join our Slack (#pulumi-deployments channel) for questions and feedback.

Transferring Stacks in the Pulumi Service Just Got Easier

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

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

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

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

Transferring one stack

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

Transferring multiple stacks

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

Bringing stacks into new organizations

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

See it in action!

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

Until next time!

Pulumi Release Notes: CED Launches, Skip Checkpoints flag, Automation API NodeJS parallel inline programs, and much more!

Meagan Cojocar — Tue, 08 Nov 2022 00:00:00 +0000

In addition to our Cloud Engineering Days launches, we have been busy shipping improvements in the last 2 months. Let’s walk through the release highlights across Pulumi engineering areas from September and October. If you want to learn more between release blogs, follow the CLI improvements in the pulumi/pulumi repo changelog and Pulumi Service features in the new features blogs.

Cloud Engineering Days Launches
Cloud Providers and Packages
- New Resources in our Providers
- Pulumi+Kubernetes Improvements
Pulumi CLI and core technologies
Pulumi Service & Pulumi.com
- Pulumi Deployments
- Architecture Templates Support

Cloud Engineering Days Launches

In the Pulumi Cloud Engineering Days 2022 we are announced a set of important new advancements in the Pulumi platform designed to help organizations scale with their infrastructure as code needs. These announcements were as follows:

Pulumi Deployments: The Pulumi Service now supports executing infrastructure deployments as a managed service, driven by click-to-deploy in the Console, Git push-to-deploy from GitHub, programmatic deployments via the Pulumi Service REST API as well as automation via the Pulumi Automation API. Pulumi Deployments enables organizations to scale up their infrastructure automation. Learn more in the Pulumi Service section below!
Pulumi YAML GA: In addition to supporting rich general purpose programming languages like TypeScript, Python, Go, .NET and Java, Pulumi added support last May for Pulumi YAML as a simple, declarative interface for accessing the full breadth of the Pulumi Universal Infrastructure as Code platform. Pulumi YAML is now Generally Available as part of its 1.0 release, enabling everyone in an organization to use Pulumi to manage cloud infrastructure.
Architecture Templates: New templates providing architecture-specific starting points for the most common infrastructure as code use cases - Containerized Services, Kubernetes Clusters, Serverless Applications, Static Websites and Virtual Machines - available across all major cloud platforms and supported languages.
Project Level Configuration: As cloud infrastructure projects grow in complexity, Pulumi provides many tools to manage the complexity of the software that defines these projects. But the configuration of that software also grows in complexity. New support for Project-Level Configuration across all Pulumi languages makes it easier to manage complex configuration as cloud projects scale up.

👉 Learn more in the Cloud Engineering Days Announcements blog.

Cloud Providers and Packages

New resources in our providers

We shipped new versions of the AWS Native provider, Google Native provider and the Azure Native provider that added support for 698 new resources in the last two months. 17 new resources were added to Google Native, 662 when including IAM binding and IAM member resources, 29 resources were added to the AWS Native provider and 7 were added to the Azure Native provider.

Pulumi+Kubernetes Improvements

In October we announced a set of major updates which deepen and extend Pulumi’s support for Kubernetes and the Kubernetes ecosystem. Here are a few of these exciting enhancements:

Pulumi Kubernetes Operator v1.10: New integration with Flux for richer GitOps support, and ability to deploy Pulumi stacks from directly within the Kubernetes resource model
New Pulumi Provider for Flux: Manage Flux with Infrastructure as Code
Pulumi Kubernetes Provider v3.22: Server Side Apply Option and Resource Patch

👉 Learn more in the Pulumi+Kubernetes: New Flux Integration and Inline Programs blog.

Pulumi CLI and core technologies

Pulumi CLI now displays time elapsed per resource

When you modify a resource the Pulumi CLI will display the time elapsed so you can determine how long the modification elapsed for. This change helps surface for each resource the time it takes to create or modify allowing you to plan for it next time. See it in action below!

👉 Learn more in the Elapsed Time per Resource blog post and in the resource creation times GitHub issue.

Automation API NodeJS parallel inline programs

Automation API now supports parallel execution of NodeJS inline programs in addition to the existing Python inline program support. Now users can run multiple NodeJS Pulumi programs in parallel when they are using Automation API. It uses NodeJS AsyncLocalContext to isolate state away from process environments and into context-specific stores owned by LocalWorkspaces. This functionality is also supported in Python and .NET.

👉 Learn more in the support parallel execution of NodeJS inline programs GitHub issue.

New –remove flag for `pulumi destroy`

A pulumi destroy operation destroys all existing resources in the stack, but not the stack itself. If you then wanted to delete the stack itself, once all the resources were destroyed, you would run a [pulumi stack rm]. A community member, mrod-io added a flag for pulumi destroy for when you want to remove the stack after its resources are destroyed: pulumi destroy --remove.

See it in action below:

meagancojocar@Meagans-MacBook-Pro demo % pulumi destroy --remove
Previewing destroy (demo/dev)

View Live: https://app.pulumi.com/meagan/demo/dev/previews/632658ed-41e0-411d-b8a8-f41cc6122ef4

 Type Name Plan
 - pulumi:pulumi:Stack dev delete
 - └─ aws:s3:Bucket my-bucket delete

Outputs:
 - bucketName: "my-bucket-ad305ba"

Resources:
 - 2 to delete

Do you want to perform this destroy? yes
Destroying (demo/dev)

👉 Learn more in the Add –remove as an option for pulumi destroy GitHub issue.

Add Output.format to the Python SDK

We added Output.format to the Python SDK to match helper methods in our other SDKs. Most languages have a standard way to format a string (String.Format in C#, fmt.Sprintf in Go, etc) but you can’t use those functions with our Output values. We have added a format method that’s similar to each language’s normal format method, but with support for outputs. We have added Output.format in Python which matches the standard Python str.format method. This is similar to how we have interpolate in TypeScript, and Output.Format in C#.

👉 Learn more in the Add Output.format to python SDK pull request.

Cloning Pulumi templates from Azure DevOps

We now support cloning Pulumi templates (pulumi new) from Azure DevOps repositories. When given a URL with a hostname of dev.azure.com, it will use system-installed Git and will clone the master/main branch.

Skip Checkpoints Experimental Flag

We have added a new experimental flag to improve performance for certain use cases. This flag makes Pulumi skip saving state checkpoints as it modifies resources and instead only save the final state of a deployment. This is an experimental feature that also requires an PULUMI_EXPERIMENTAL=true environment variable to be set. Using the feature introduces risk that in the case of network disconnect or crash state edits will be lost and may require manual recovery. When this risk is acceptable, using the feature can speed up Pulumi deployment times. As it is in experimental we may make changes to how it has been implemented down the track.

👉 Learn more by reviewing the Skip checkpoints pull request.

Token Authentication in Go Providers

Thank you to community member @aohoy for adding support for token authentication in the Go providers that use Git. You can now authenticated requests by tokens such as https://auth:token@gitlab.example.com/group/proj.git/tree/v0.0.0/path.

👉 Learn more by reviewing the Add token to Git Go module pull request.

Bump TypeScript version from v3.7.3 to v3.8.3

We updated the vendored version of TypeScript in the NodeJS SDK and runtime from v.3.7.3 to v3.8.3. Updating TypeScript versions enables you to use newer TypeScript features, such as the import type and export type syntax, which is required to use OpenTelemetry.

👉 Learn more by reviewing the Bump TSC version to 3.8.3 pull request.

Support lazy-loading Node modules

We now have opt-in support for generating lazy load code for Node modules. Modules that define functions and resources are loaded lazily when you opt-in. Generated code may use import type .. form when importing enums (“useTypeOnlyReferences” opt-in flag in schema). We plan to lazy-load Node modules in Azure Mative and other large Pulumi Packages to improve performance when using these libraries.

👉 Learn more by reviewing the Implement support for lazy-loaded Node modules pull request.

Pulumi Service & Pulumi.com

Pulumi Deployments

With Pulumi Deployments, you can run a Pulumi infrastructure as code action (a preview, update, destroy or refresh) inside Pulumi’s managed service. Pulumi provides scalability, observability, and security for deployments. It consists of five components:

The Deployments REST API - A fully managed REST API to execute Pulumi programs with the Pulumi Service. This includes APIs to observe your deployment and all associated logs.
Deployment Visualization - A dashboard for deployment observability including deployment status, logs, and queueing via the Pulumi Service console.
Click to Deploy - Deploy infrastructure with the click of a button from the Pulumi Service console.
Git push to Deploy - Configure automatic infrastructure deployments in response to git push events by installing and configuring the Pulumi GitHub App.
Remote Automation API - Our strongly typed infrastructure orchestration technology can now run deployments remotely in the cloud.

Click to Deploy

Pulumi Deployments removes the cloud as a bottleneck and unlocks it as an accelerant for your business. It is available in preview today. Deployments are free during the preview, with usage-based pricing to come. Check out these resources to get started today:

Request access to the Pulumi Deployments preview
The Pulumi Deployments demo video
Pulumi Deployments documentation
Pulumi Deployments REST API documentation
Automation API examples

👉 Learn more in the Pulumi Deployments launch blog post.

Architecture Templates Support

We added Architecture Templates support to the new project experience in the Pulumi Service console. Now in addition to selecting your cloud provider and language of choice you can select a template for your new project. We currently have Static Website, Serverless, Container Service, Virtual Machine, Kubernetes cluster and web application templates, with more to come!

Pulumi Release Notes: Pulumi Refresh updates, re-implementing Pulumi Watch, and much more!

Meagan Cojocar — Tue, 06 Sep 2022 00:00:00 +0000

It has been an action packed July and August here at Pulumi! Below you will find a highlight list of what we have built across the engineering areas, including new resources support in our providers, new Automation API functionality, interactive options for pulumi refresh and much more.

If you are curious to see all new functionality, learn more about CLI improvements in the pulumi/pulumi repo changelog and Pulumi Service features in the new features blogs.

Cloud Providers and Packages
Pulumi CLI and core technologies
Pulumi Service & Pulumi.com

Cloud Providers and Packages

New resources in our providers

We shipped new versions of the AWS Native provider, Google Native provider and the Azure Native provider that added support for 145 new resources in the last month. 83 of the new resources were for AWS Native, 42 for Azure Native, and 20 were added to Google Native.

New functionality in Google Native v0.25.0

Google Native v0.25.0 is out and includes a series of improvements beyond expanded resource support, including retrieving Kubeconfig and server config from Kubernetes clusters.

Learn more in the Google Native v0.25.0 release notes.

Kubernetes Operator v1.8.0

In the latest release of the Pulumi Kubernetes Operator we have added improvements to metrics collection and better branch detection in branch specifications.

Learn more in the Kubernetes Operator v1.8.0 release notes.

Pulumi CLI and core technologies

Pulumi YAML improvements

In the last two months we have made a series of improvements to Pulumi YAML, going from v0.5.2 to v0.5.5. Two key improvements we have made are:

Shorthand for Fn::Invoke Previously an invoke function in Pulumi YAML would look as follows:

Fn::Invoke:
 Function: aws:ec2:getVpc

Now we have a shorthand:

Fn::aws:ec2:getVpc: {}

Setting default providers You can now set a default provider to make it easier to author programs that work at multiple levels of infrastructure. This works really well with the disable default providers feature.

resources:
 eks:
 type: eks:Cluster
 k8sProvider:
 type: pulumi:pulumi:kubernetes
 defaultProvider: true
 properties:
 kubeconfig: ${eks.kubeconfig}
 # from this point on, all kubernetes resources will inherit the above provider
 # options:
 # provider: ${k8sProvider}

We also made a handful of improvements to pulumi convert. See the v0.5.5 release notes for more details.

Allow `pulumi refresh` to resolve pending creates

pulumi refresh can be used to bring Pulumi state back inline with external state. If something is changed in the actual state and Pulumi is not made aware of it or if Pulumi is terminated mid-operation you could end up with pending operations. Now when running pulumi refresh interactively, it will provide you with new options to deal with the pending operations. These new interactive options are as follows:

import: the flag --import-pending-creates has been added to allow scripting to resolve pending creates via pulumi refresh. It takes a list of URN IDs to be imported.
clear: to assist with the use case of removing all pending creates, the flag --clear-pending-creates has been added.
skip: the flag --skip-pending-creates has been added to disable this new behavior

Regardless of if these flags are passed, a refresh is still run. To learn more read the Repairing State with Pulumi Refresh blog post or the merge request.

Re-implementing `pulumi watch`

The pulumi watch command watches the working directory or specified paths for the current project and updates the active stack whenever the project changes and displays the logs along with update progress. Using pulumi watch cloud developers can speed up the rate of iteration and focus on their code and infrastructure, instead of on the mechanics of their deployments.

We have recently re-implemented pulumi watch to have cross platform compatibility (it works on Apple Silicon now!) and improved performance.

See it in action

Try it out today! See more information in the pulumi watch documentation, the original launch blog post and the merge request for the latest updates.

Automation API Python parallel inline programs

Automation API now supports parallel execution of Python inline programs. Now users can run multiple Python Pulumi programs in parallel when they are using Automation API. SETTINGS values are now global and context aware, and CONFIG, ROOT and _SECRET_KEYS were ported to ContextVars to prevent state leak between parallel line Pulumi programs.

Learn more in the SETTINGS attributes merge request and ContextVars merge request.

getOrganizations from inside a stack

Users can now get the current Pulumi Organization name from inside a stack. getStack, in both the Python and NodeJS SDKs returns the stack name itself. Now using getOrganization users can get both the stack and the Organization it is in. The other Pulumi languages will add getOrganization support shortly.

Learn more in the Add getOrganization merge request.

Control logging and tracing within Automation API

We have improved Pulumi Automation API functionality to permit finer control over logging by adding five additional options to the preview, up, refresh, and destroy operations in Automation API.

Enables Automation API to run with the equivalent of CLI arguments:

--logflow
--verbose
--logtostderr
--tracing
--debug

Learn more in the Add options to configure logging and tracing merge request.

Use `pulumi destroy -s <stack>` outside a Pulumi project dir

You can now specify a stack when using pulumi destroy while outside of the project directory.

Learn more in the pulumi destroy -s <stack> GitHub issue.

Pulumi Service & Pulumi.com

Team Access Tokens

We launched Team Access Tokens, which allow Organization and Team Admins to create access tokens scoped to a Pulumi Team. Pulumi Service customers on the Enterprise and Business Critical editions can use Pulumi Teams to set role-based access controls (RBAC) for stacks by enabling Organization administrators to assign a set of stack permissions to a group of users. Once you have Teams created you can use Team Access Tokens to generate a token scoped to that Team.

Learn more in the Team Access Tokens blog post and the Team Access Tokens documentation.

Billing Managers

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

Learn more about the permissions in the Billing Manager blog post and the Billing Manager documentation.

New Pulumi Service console

It’s been nearly four years since the Pulumi Service launched back in 2018. In these last four years, our customer base has grown significantly and as a result, the Service’s features and capabilities have grown with it. Over this time the look and feel of the Service has largely stayed the same, its time for a refresh!

We’re excited to launch a set of improvements to the overall user experience of the Pulumi Service. These updates include an update to the Dashboard as well as a new left navigation pane:

Increased organizational insights on the Service Dashboard

Easier navigation around the Service with a new left navigation pane

Stack Favorites

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

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

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

Pulumi Service Provider improvements

The Pulumi Service Provider builds on top of the Pulumi Service REST API which is another feature available to our customers to programmatically configuring the Pulumi Service. At launch, the Pulumi Service Provider had resource support for Teams, Webhooks, StackTags and AccessTokens. We have recently also added support for TeamStackPermissions, enabling users to add stacks to Teams and Provider to control Provider resources.

As always, please feel free to submit feature requests and bug reports to Pulumi Service Provider GitHub Repo. We look forward to seeing what you build with the Pulumi Service Provider!

Until next time, happy building!

The New and Improved Pulumi Service console

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

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

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

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

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

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

Increased organizational insights on the Service Dashboard

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

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

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

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

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

Quick access to stacks with a new Stack Favorites feature

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

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

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

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

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

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

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

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

Try out the Pulumi Service today

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

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

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

Announcing Team Access Tokens for the Pulumi Service

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

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

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

See it in action!

Hear from our customers

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

Feature overview

This feature is particularly useful for:

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

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

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

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

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

Introducing Billing Managers: A new role in the Pulumi Service

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

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

Feature overview

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

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

Pulumi Team Growth Edition

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

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

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

Pulumi Enterprise Growth and Business Critical Editions

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

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

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

Let’s see it

Getting started

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

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

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

Pulumi Release Notes: Pulumi YAML updates, Stack READMEs, and much more!

Meagan Cojocar — Wed, 06 Jul 2022 08:28:39 -0700

Our first release notes since the frenzy of releases for PulumiUP! The latest Pulumi updates also include our providers updates, compression of filestate backends, adding –stack to pulumi about, adding local policy packs to Automation API and much more! Learn about what’s new.

Cloud Providers and Packages
- New resources in our providers
Pulumi CLI and core technologies
Pulumi Service & Pulumi.com
- Stack READMEs
- SAML/SCIM improvements

Cloud Providers and Packages

New resources in our providers

We shipped new versions of the AWS Native provider, Google Native provider and the Azure Native provider that added support for 412 new resources in the last month. 385 of those resources were Azure Native, 7 AWS Native and 20 were added to Google Native.

Pulumi CLI and core technologies

Pulumi YAML v0.5.2

We released v0.5.2 of Pulumi YAML which included bug fixes, new functions, diagnostics and validation. Some specific improvements we made were:

Add errors when hanging invalid fields off of resources. #203
Add errors when hanging invalid fields off of resource options. #211
Add a type checker. #228
Add Fn::FromBase64 #218
Add support for Fn::ReadFile, enabling Pulumi Service Stack README support. #217
Allow Fn::Join to take expressions as inputs, previously the second argument had to be a syntactical list. #241

As always, please feel free to submit feature requests and bug reports to the Pulumi YAML GitHub Repo. We love hearing feedback from users!

Add local Policy Packs to Automation API

The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI. Conceptually, this can be thought of as encapsulating the functionality of the CLI (pulumi up, pulumi preview, pulumi destroy, pulumi stack init, and so on.) but with more flexibility. We have now added support for Pulumi Policy Packs can now be run with Automation API by specifying --policy-pack.

Add –stack to `pulumi about`

The pulumi about command lets you prints out information that can be helpful for debugging while using the Pulumi CLI. This includes information about, the CLI and how it was built, which OS Pulumi was run from, the current project, the current stack and the current backend. We added the ability to specify which stack to provide details about without having to select it first using pulumi about –stack, for example pulumi about --stack eks/staging.

Learn more in the add –stack to pulumi about GitHub pull request.

Add logout message

Based on a great community suggestion, we have added a confirmation message to pulumi logout to add clarity to the state after the command exits.

Previous behavior:

me@MacBook-Pro ~/r/m/myfolder> pulumi logout
me@MacBook-Pro ~/r/m/myfolder>

Current behavior:

me@MacBook-Pro ~/r/m/myfolder> pulumi logout
Logged out of https://app.pulumi.com/meagan
me@MacBook-Pro ~/r/m/myfolder>

Learn more in the added confirmation string to pulumi logout GitHub issue.

Compression of remote state backends

Users of the self-managed state backends can now enable compression via PULUMI_SELF_MANAGED_STATE_GZIP=true. A huge shoutout to community contributor @awoimbee for the pull request.

Learn more in the add gzip flag to filestate backend GitHub pull request.

Add `CompositeInvoke`

We have added a CompositeInvoke function to the Go SDK that makes it easier to work with invoke bundles.

Previous behavior:

opts := []pulumi.InvokeOption{pulumi.Parent(parent), pulumi.Provider(provider)}
pkg.SomeInvoke(nil, append(opts, , pulumi.Version("1.2.3"))...)

Current behavior:

opts := pulumi.CompositeInvoke(pulumi.Parent(parent), pulumi.Provider(provider))
pkg.SomeInvoke(nil, opts, pulumi.Version("1.2.3"))

Learn more in Add CompositeInvoke Github pull request.

Support Java in `pulumi convert`

You can now use pulumi convert --language java to generate programs for Java from YAML.

Pulumi Service & Pulumi.com

Stack READMEs

Users can create Stack READMEs in the Pulumi Service that dynamically update based on Stack Outputs.

A Pulumi Service Stack README is dynamically populated with details from your stack outputs. It does this by interpolating output variables on the stack, such as ${outputs.instances[0].ARN} so that each stack can construct links to dashboards, shell commands, and other pieces of documentation.

Learn more in the Stack READMEs blog!

SAML/SCIM improvements

We spent some time in the last month improving the SAML/SCIM experience for our customers. The key improvements made were around deprovisioning and provisioning users and how we handle username updates with special characters. Organization Administrators can now remove a user from their identity provider which will deprovision the user in Pulumi, and then re-add them through the identity provider and they will be re-added to the Pulumi organization. Our customers requested this functionality for supporting organization re-orgs and team permission changes. This makes the process of managing Pulumi access with a SCIM provisioner more seamless.

Stack READMEs in the Pulumi Service

Evan Boyle — Thu, 19 May 2022 09:35:01 -0700

Starting today, users can create Stack READMEs in the Pulumi Service that dynamically update based on Stack Outputs.

Each Pulumi Stack you deploy manages a key set of cloud infrastructure for your organization. The Pulumi Console includes a variety of features for exposing key information about your stack for other users within your organization - configuration, outputs, resources under management, links to cloud providers, and a graph of all resources. However, it’s often useful to allow the author of a Pulumi Stack to describe in their own words the key elements of a stack, so future viewers can quickly understand the components and cloud resources that are managed.

A README is a text file that introduces and explains a project. A Pulumi Service Stack README can contain documentation and common links for the Stack. The key difference between a source control README, such as a GitHub README, and a Pulumi Service Stack README, is that it is dynamically populated with details from your stack outputs. It does this by interpolating output variables on the stack (${outputs.instances[0].ARN}) so that each stack can construct links to dashboards, shell commands, and other pieces of documentation. All of this content stays up to date as you stand up new stacks, rename resources, and refactor your infrastructure.

There are a lot of operational activities that happen around Pulumi Stacks, but critical information is spread across many tools. We have heard from our users that it can be time consuming switching from different tools and web apps to manage their deployments- from their cloud Console, to the Pulumi Service User Interface (UI), to the CLI, and so on. By collecting resource outputs in the Pulumi Service UI, we are reducing this friction and keeping relevant Stack information in one place so that is kept up to date automatically.

README templates can reference Stack outputs and resource properties, for example ${outputs.vpc.ARN}. To walk you through a tangible example, a user can deploy an RDS instance and then use a variable in their README template to link to their CloudWatch dashboard to keep an eye on operational metrics. This CloudWatch dashboard link will dynamically update when deployments happen. You can use the same README template across dev, testing and production and have the correct dashboard links for each Stack. Learn more in the Stack READMEs documentation page.

The new experience lives in the Stack page, which can be navigated to through Projects and clicking on the specific Stack you want to view the README for. Let’s take a look at this new feature!

The Pulumi.README.md file we added to the Stack ‘Production’ above is a template README for our Pulumi Service. In it we have links to our AWS authentication tool, our CloudWatch metrics, to our production deployment documentation, and so on. The common places that we navigate to and from when managing this Stack. Here is some of the Markdown for this README:

# Pulumi Service README

[Sign in to AWS to view stack resources!](https://top-secret-url.com)

## On Call Operations

### Monitor

**Cloudwatch Metrics**
Monitor holistic metrics tracking overall service health
[Link](https://us-west-2.console.aws.amazon.com/cloudwatch/home?region=us-west-2#dashboards:name=${outputs.dashboardName})

**RDS Performance Metrics**
Monitor RDS performance (wait times, top queries)
[Link](https://us-west-2.console.aws.amazon.com/rds/home?region=us-west-2#performance-insights-v20206:/resourceId/${outputs.databaseClusterId}/resourceName/${outputs.rdsClusterWriterInstance})

**Cloudwatch Logs**
Search across service logs
[Link](https://us-west-2.console.aws.amazon.com/cloudwatch/home?region=us-west-2#logStream:group=${outputs.cloudwatchLogGroup})

How to add a Stack README to your Stack

In order to add a README to your Pulumi Stack, you will need to do the following:

Step 1

Export a Stack output named readme that contains your templated Stack README markdown, commonly by reading a file, i.e. Pulumi.README.md.

import { readFileSync } from "fs";
export const strVar = "foo";
export const arrVar = ["fizz", "buzz"];
// add readme to stack outputs. must be named "readme".
export const readme = readFileSync("./Pulumi.README.md").toString();

import pulumi
pulumi.export('strVar', 'foo')
pulumi.export('arrVar', ['fizz', 'buzz'])
# open template readme and read contents into stack output
with open('./Pulumi.README.md') as f:
 pulumi.export('readme', f.read())

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 strVar := "foo"
 arrVar := []string{"fizz", "buzz"}
 readmeBytes, err := ioutil.ReadFile("./Pulumi.README.md")
 if err != nil {
 return fmt.Errorf("failed to read readme: %w", err)
 }
 ctx.Export("strVar", pulumi.String(strVar))
 ctx.Export("arrVar", pulumi.ToStringArray(arrVar))
 ctx.Export("readme", pulumi.String(string(readmeBytes)))
 return nil
 })
}

using Pulumi;
class MyStack : Stack
{
 public MyStack()
 {
 this.StrVar = "foo";
 this.ArrVar = new string[] { "fizz", "buzz" };
 this.Readme = System.IO.File.ReadAllText("./Pulumi.README.md");
 }
 [Output]
 public Output<string> StrVar { get; set; }
 [Output]
 public Output<string[]> ArrVar { get; set; }
 [Output]
 public Output<string> Readme { get; set; }
}

package stackreadme;
import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Paths;
import com.pulumi.Pulumi;
import com.pulumi.core.Output;
public class App {
 public static void main(String[] args) {
 Pulumi.run(ctx -> {
 var strVar = "foo";
 var arrVar = new String[]{ "fizz", "buzz" };
 try {
 var readme = Files.readString(Paths.get("./Pulumi.README.md"));
 ctx.export("strVar", Output.of(strVar));
 ctx.export("arrVar", Output.of(arrVar));
 ctx.export("readme", Output.of(readme));
 } catch (IOException e) {
 throw new RuntimeException(e);
 }
 });
 }
}

name: stack-readme-yaml
runtime: yaml
description: A minimal Pulumi YAML program demonstrating stack readme feature
variables:
 readme:
 Fn::ReadFile: ./Pulumi.README.md
outputs:
 strVar: foo
 arrVar:
 - fizz
 - buzz
 readme: ${readme}

Step 2

Create a README template for the Stack. In this example, we will create a Pulumi.README.md file that looks as follows:

# Stack README

Full markdown support! Substitute stack outputs dynamically so that links can depend on your infrastructure! Link to dashboards, logs, metrics, and more.

1. Reference a string stack output: ${outputs.strVar}
2. Reference an array stack output: ${outputs.arrVar[1]}

Step 3

Run pulumi up on that Stack

Step 4

Open the Pulumi Service UI, navigate to Projects and then the Stack you have updated. Once on the Stack page you will see the README tab with your README file.

Ta da! 🎉

We now have a README on the Stack.

Refer to the Stack README documentation page for more details on how to use this feature. As always, please feel free to submit feature requests and bug reports to the Pulumi Service GitHub Repo. We love hearing feedback from users about ways we can improve your productivity when using Pulumi. We look forward to seeing how you make Stack READMEs fit your needs!

Pulumi Release Notes: Display richer diffs, clear pending operations, and much more!

Meagan Cojocar — Tue, 19 Apr 2022 07:26:49 -0700

The team has been busy releasing new features and improvements in the last month. The latest Pulumi updates include our providers updates, install Pulumi using winget, stack unselect command, GitHub release private plugins, and more. Read on to learn about what’s new in this release!

Cloud Providers and Packages
Pulumi CLI and core technologies
Pulumi Service & Pulumi.com
- Docs search improvements

Cloud Providers and Packages

Pulumi AWS Provider v5.0.0

We are excited to announce v5.0.0 of the Pulumi AWS provider. The AWS provider is one of the most heavily used providers across the Pulumi ecosystem, and offers access to the full surface area of the upstream Terraform AWS Provider from within Pulumi projects in all supported Pulumi languages. The v5.0.0 release brings a substantial set of fixes and improvements to the provider, including a number of breaking changes as part of the major version release.

Read more in the Pulumi AWS Provider v5.0.0 blog post.

Lambda function URLs

AWS Lambda functions are an incredibly easy and powerful way to stand up serverless capabilities which is why they are easily one of the most popular resources deployed by Pulumi users today. As of last week, Lambda Function URLs were made accessible via the Cloud Control API and therefore can be accessed in your Pulumi programs. End-users no longer need to set up an Amazon API Gateway to provide an HTTPS endpoint for their functions - further simplifying deployments.

You can learn more about Lambda Function URLs by reading the Lambda URLs blog post.

New resources in our providers

We shipped new versions of the AWS Native provider and the Azure Native provider that added support for 140 new resources in the last month, 82 of those in the Azure Native provider.

Pulumi CLI and core technologies

Display richer diffs

In 3.29.1 we have made a handful of improvements to how diffs are presented in the Pulumi CLI. These changes will improve the CLI experience by making easier to see what changes are being made. Specifically, we have improved the following:

Show rich diffs for JSON/YAML objects/arrays

We now render the diff between the decoded JSON and YAML values rather than the diff between text values. This will make it a lot easier to see what has changed when managing resources that produce JSON or YAML strings.

Before 3.29.1 a preview would look as follows: Now the preview shows the YAML diff:
Render changes to text properties as diffs

Instead of simply rendering the old and new values for textual properties, we now present the diff between the old and new values.
Retain Secret values

Instead of replacing Secret values with the text [secret], we now retain the Secret value and replace its element with the text [secret]. This allows the CLI’s diff renderer to understand that the contents of the value is secret if necessary.

Clear pending operations

We have made two changes to how pending operations are treated. The first change is that when there are pending operations, updates can be made but we will produce a warning to investigate the pending operations. This prevents users from ending up with live cloud resources that are not tracked by Pulumi (orphaned resources). The second change we made is now users can run pulumi refresh and clear pending operations. This adds an easy way to clean up pending operations that have been investigated and can be cleared.

Learn more in the clear pending operations GitHub issue.

List current users organizations

Users can now see a list of their organizations using pulumi whoami and pulumi about to better inform and improve their CLI experience. Using the command pulumi whoami –verbose will now return the list of organizations the user is a member of.

Learn more in the list current orgs GitHub issue.

Install Pulumi using Winget

You can now install Pulumi using the Winget package manager. Windows users on Windows 11 and later can now use winget install pulumi to install Pulumi and winget upgrade pulumi to get the latest version.

Learn more in the install Winget GitHub issue and in the Pulumi installation instructions.

Pulumi stack unselect

We have introduced the pulumi stack unselect command to remove a stack from the current workspace. Users select stacks with pulumi stack select [<stack>] [flags] and can now easily deselect them if they need to.

Learn more in the stack unselect GitHub issue.

GitHub Releases private plugins

We now support downloading a plugin from private Pulumi GitHub releases. We only look at the GITHUB_TOKEN environment variable now and GITHUB_ACTOR and GITHUB_PERSONAL_ACCESS_TOKEN are no longer used. The token is sent via the Authorization header instead of Authentication (see documentation).

Learn more in the GitHub Releases private plugins pull request.

Speed up `pulumi stack --show-name`

Now when running pulumi stack --show-name we will skip loading the snapshot and instead just provide the stack name and then exit. This results in less latency to see the stack name.

Learn more in the speed up show stack name GitHub issue.

Pulumi Service & Pulumi.com

Docs search improvements

We updated the search experience of our Docs to return more intuitive results as well as pinned the search bar on the top panel when users scroll through our Docs.

Pulumi Release Notes: Pulumi Import Improvements, RetainOnDelete as a resource option, and more!

Meagan Cojocar — Tue, 15 Mar 2022 08:47:42 -0800

The team has been busy releasing new features and improvements in the last 3 weeks. Read on to learn about what’s new in this release!

Pulumi CLI and core technologies

Pulumi CLI and core technologies

`pulumi import` Improvements

Last year, we introduced a new Pulumi import feature that allows you to import existing infrastructure into your Pulumi program. We’ve listened to feedback and delivered a plethora of updates and fixes to streamline the import experience to make it more useful, more convenient, and more powerful. Not only can this feature bring a resource into your Pulumi state file, but it can also generate the source code for your Pulumi program too.

You can now use the pulumi import command to import using all input fields instead of only the ones flagged as required, which will result in less check failures. If there are check failures, they are now treated as a warning not an error. In addition, we added an optional flag to pulumi import that allows users to skip the code generation step of import.

Learn more in the Improved Import blog post, import improvements GitHub issue and the disable codegen GitHub issue.

Add `RetainOnDelete` as a resource option

Pulumi is frequently used to manage the entire lifecycle of a resource, from creation, to updates, to replacement, to deletion. However, there are some cases where it is important to ensure that a resource’s life can extend beyond the lifetime of the Pulumi program that created it. To support these use cases, Pulumi now supports a new resource option RetainOnDelete which allows a resource to be retained in a cloud provider even after it is deleted from the Pulumi stack it is part of.

Learn more in the RetainOnDelete blog post and in the RetainOnDelete GitHub issue.

New `pulumi state rename` command

In some cases users may need to rename existing resources, which historically has been done by editing the checkpoint file directly. We’ve now made this even easier by offering a CLI command to rename resources. You can now use pulumi state rename to rename resources in an easy and safe manner. This feature will also be useful for customers migrating to the Azure AD provider without replacing resources.

Learn more in the add pulumi state GitHub issue.

Default `pulumi plugin install` to the latest version

When using pulumi plugin install, the version argument is now optional and will default to the latest version when a version argument is not provided. This will save users time when they want to use the latest plugin version as they no longer need to look it up.

Learn more in the latest plugin version GitHub issue.

Add console output in non-interactive mode

When resources are slow to create, Pulumi will now have a dot spinner in non-interactive mode. When running Pulumi in a hosted CI environment (such as CircleCI) if there is no console output while waiting for resources to create the CI tool may forcibly terminate the job. We have added a parameter to set a delay for a heartbeat message in non-interactive mode to keep the CI tool from killing jobs.

Learn more in the console output non-interactive mode GitHub issue.

Support `pulumi cancel` for filestate backends

We now support pulumi cancel for self-managed state backends, such as S3.

Learn more in the support pulumi cancel GitHub issue.

Introducing Pulumi Business Critical Edition for Enterprise Modernization

Meagan Cojocar — Wed, 02 Mar 2022 00:00:00 +0000

In the last 12 months, we have experienced 350% year-over-year growth of our enterprise customers, including Mercedes-Benz, Snowflake, Atlassian and SANS Institute. Given the growth in our enterprise customer base, we are excited to launch today a new Business Critical Edition for the Pulumi Service, a 30 day Self-Hosted Pulumi Service trial, and the option to purchase Pulumi Enterprise and Business Critical through the AWS Marketplace!

Pulumi Business Critical Edition

The Pulumi Cloud Engineering Platform enables organizations to build, deploy, and manage modern cloud infrastructure and applications with infrastructure as code using popular programming languages. With Pulumi, infrastructure and platform engineers can empower other developers in their organization to easily build modern cloud applications with self-service infrastructure or reusable infrastructure components. Full-stack developers or developers at companies without platform teams can quickly become proficient at building and deploying cloud infrastructure using Pulumi’s SDK and libraries, all backed by the ease and power of general-purpose programming languages.

Pulumi adoption continues to accelerate across enterprises around the world with more than one million downloads per month. These enterprise customers have specific requirements, like advanced security and compliance features, premium support, and self-hosting options. Today, the Pulumi Business Critical Edition joins our existing offerings, the Pulumi Team Edition and the Pulumi Enterprise Edition, to meet these customers’ needs. We are thrilled to be launching a new offering that enables us to support the most sophisticated production workloads in the modern cloud.

Existing customers of Pulumi Team and Enterprise Editions are unaffected by these changes. Customers who are looking to expand to leverage the features of Pulumi Business Critical Edition can contact us to get started. New customers trialing Pulumi for their organization will get access to all of the features of Business Critical Edition during their 14 day trial.

Full details of our Pulumi Service editions can be found on our pricing page.

The Pulumi Business Critical edition includes everything in the Pulumi Enterprise Edition, plus:

Organization policies and enforcement
Self-hosting available
Cross-domain identity (SCIM)
Automatic export of audit logs
24 x 7 support included
Premium training, onboarding and certain professional services

Policy as Code (CrossGuard), a Business Critical feature:

Self-Hosted Pulumi Service

We are also announcing today a 30 day trial for self-hosting the Pulumi Service. Self-Hosted Pulumi Service allows you to deploy and manage the Pulumi Service on your own infrastructure, either in the cloud or on-premises. Self-hosting is an option for organizations that need to maintain complete control over hosting, network isolation, identity, and data ownership in order to satisfy segment-specific compliance requirements. It can take time to install and configure a self-hosted product in your desired deployment option, and we want to make sure there is enough time to assess the product. This is why we have launched a 30 day trial, instead of 14 day like the Pulumi Service. Sign up today for the 30 day trial on our Self-Hosted Pulumi Service page.

The Self-Hosted Pulumi Service can be installed in any on-premises or cloud provider environment. It can also run in air-gapped environments without access to the Internet, including those with the most demanding compliance needs such as FedRAMP. In concert with the launch of the 30 day trial, we have made the deployment reference architectures public. For assistance setting up your environment or if you don’t see your desired deployment option, contact us. Full details on self-hosting the Pulumi Service can be found in our Self-Hosted Pulumi Service documentation.

Pulumi in the Amazon Web Services (AWS) Marketplace

In concert with the new Pulumi Business Critical Edition and Self-Hosted Pulumi Service trial we are excited to be listing on the AWS Marketplace. Pulumi Enterprise and Business Critical Editions are now available for purchase through AWS Marketplace, and support for additional cloud provider marketplaces is imminent. The AWS Marketplace listing can streamline the purchasing and internal approval processes for our customers managing cloud resources on AWS.

We hope the new Pulumi Business Critical Edition, Self-Hosted Pulumi Service trial, and AWS Marketplace listing make it easier for your organization to adopt and scale your Cloud Engineering practices using the Pulumi Service.

All editions of the Pulumi Service, including Business Critical and Self-Hosted, are immediately available. Enterprises can contact us to discuss which product experiences might be best suited to their needs. Enterprises can choose to deploy Pulumi on their own or take advantage of Pulumi’s Business Critical Edition onboarding program.

Pulumi Blog: Meagan Cojocar

Introducing the Stash Resource in Pulumi IaC

Why Stash?

Using Stash

When to replace

Learn more

10 Things You Can Do With Our Infrastructure Agent, Neo

1. Explain infrastructure in plain English or diagrams

2. Generate infrastructure code from natural language

3. Assist with Terraform to Pulumi migration

4. Automate CI/CD pipeline generation

5. Identify inefficient infrastructure patterns

6. Upgrade EKS/Kubernetes clusters

7. Respond to security vulnerabilities

8. Remediate policy violations

9. Update Lambda runtimes across multiple accounts

10. Enforce multi-account policy compliance

Your newest platform engineer

Precise Resource Replacement with Pulumi State Taint

The New Commands

Why This Matters

Workflow

Get Started

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

Pulumi IaC

Azure Native V3

Pulumi Model Context Protocol (MCP) Server

Next-Generation Pulumi Components

Registry Wave 2: 27 New Providers

Enhanced Terraform Conversion

Improved Refresh and Destroy Experience

GitLab Integration Improvements

Faster Secrets Management

Pulumi Kubernetes Operator 2.0

Java SDK 1.0

Pulumi Copilot in VSCode

Autonaming Configuration

Pulumi ESC

Rotated Secrets

Pulumi ESC GitHub Action

Pulumi Insights

Enforce Policy as Code on Discovered Resources

Wrap up

Azure Native V3: A Leaner, Faster SDK for Microsoft Azure

A Slimmer, More Efficient SDK

Additional Enhancements in Azure Native V3

Understanding Azure Versioning

Default API Versions

Using Non-Default API Versions

Option 1: Accessing Explicit API Versions via Local Packages

Option 2: Using the Generic Resource

Getting Started with Azure Native V3

If You’re Already Using Pulumi Azure Native

If You’re New to Pulumi

Conclusion

Announcing the Next-Generation of Pulumi Components: Enabling Infrastructure Abstractions

Understanding Pulumi Components

What’s New with Pulumi Components

How It Works

Creating Components

The PulumiPlugin.yaml File

Define an Entry Point

Sharing Components

Publishing to Git

Referencing Components Locally

Consuming Components Across Languages

See It In Action

Pro Tips

The Spectrum of Pulumi Components You Can Build

Conclusion

Expanding the Pulumi Registry: 27 New Providers to Expand the Ecosystem

Full List of New Providers

Pulumi + Gitlab: Better Than Ever

What’s New in Our GitLab Integration

Enhanced Merge Request Comments

GitLab as a First-Class VCS in Pulumi Cloud

Organizational Templates in GitLab

Coming Soon: Pulumi Deployments for GitLab

Getting Started

Conclusion