Pulumi Blog: Registry

New: Previous Provider Version Docs in Pulumi Registry

Cam Soper — Wed, 11 Mar 2026 00:00:00 +0000

The Pulumi Registry now supports browsing documentation for previous versions of first-party Pulumi providers. If you’ve ever needed to look up the API docs for an older provider version, you no longer have to dig through Git history or guess at changes — the docs are right there in the Registry. These docs also help Pulumi Neo and other agents more accurately assist you with your Pulumi code and operations.

How it works

When you visit a first-party provider’s page in the Pulumi Registry, you’ll now see a version dropdown selector that lets you switch between the current version and previous versions.

Select a previous version from the dropdown, and the Registry loads the full API documentation for that version.

What’s available

This feature currently includes documentation for the latest release of each previous major version, going back two major versions. For example, if a provider is on v7.x, you’ll be able to view docs for the latest v6.x and v5.x releases in addition to the current version.

Get started

Head over to the Pulumi Registry and try it out. Pick any first-party provider with multiple major versions and use the version dropdown to browse its history.

We’d love to hear your feedback — let us know what you think in the Pulumi Community Slack or by opening an issue on GitHub.

Explore the Pulumi Registry

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!

Leveling up Pulumi AI with the Pulumi Registry

Aaron Friel — Mon, 22 May 2023 00:00:00 +0000

Pulumi AI harnesses a form of generative AI, known as large language models, to help you discover, learn, and use new cloud infrastructure APIs with ease. Think of Pulumi AI as a sophisticated compass, guiding you through the ever-changing landscape of cloud infrastructure and pointing you in the direction of the most suitable solutions for your unique requirements.

In this blog post, we’ll explore our recent enhancements to Pulumi AI, focusing on how we’ve integrated Pulumi Package schema data to generate more accurate and relevant Pulumi programs. We’ll also share examples showcasing the improvements and how they can benefit your infrastructure as code journey.

Overcoming the Challenges in Pulumi AI

As powerful as Pulumi AI may seem, it was initially limited by the training cutoff of the model. Pulumi AI wasn’t aware of new providers or changes to resources after late 2021. Additionally, the limitations in generative AI made it difficult for the model to reproduce all the input properties and relevant details of the resources it was trained on from “memory.”

These factors led to a phenomenon researchers call “hallucination.” Pulumi AI would sometimes generate an API for a non-existent provider when asked to produce a Pulumi program. To overcome these challenges, we turned to the rich Pulumi Package schema data and CrossCode technology that powers the Pulumi Registry docs, our code conversion tools, and other Pulumi enhancements.

Integrating Pulumi Package Schema Data

Think of the Pulumi Package schema as a treasure trove of information about our providers. It’s a well-organized, comprehensive library that holds the keys to unlocking the full potential of Pulumi AI. However, we faced a challenge: these schemas were much larger than any current generative AI system could handle.

What puts the “large” in large language model is the volume of data required to train and the number of parameters in the model, typically in the trillions of tokens and billions of parameters, respectively. Unfortunately, these models aren’t capable of handling that much information in their context window. The context window is the thread of conversation or the “short-term memory” of the system. It’s how one can enhance a model trained a year ago with today’s data.

To better understand the limitations, let’s talk about tokens. Instead of operating on Unicode text, these models operate on token arrays, mapping many sequences of characters (words or parts of words) to 16-bit integers. For example, “Script” is one token, and “JavaScript” is typically two tokens. We found that despite this compression of words to tokens, the latest schemas for all of our providers would use on the order of one billion tokens.

The most powerful systems to date support at most 32,000 tokens in their prompt – enough to fit a novella! That should be enough, right?

We did the math: one billion minus 32,000… And we’re still about a billion tokens over the limit.

The right information, at the right time

To work around this limitation, we need to carefully select and inject the right schema information into the context window, ensuring that the model could understand, process, and generate the best possible solutions for users.

We cracked open our college textbooks on information storage & retrieval, evaluated the latest vector databases and embedding systems, and perused the literature. One internal demo we did used a technique similar to Hypothetical Document Embeddings (HyDE). While this did improve accuracy and reduce hallucinations, that approach also requires pre-processing the user’s query. That additional step results in a much higher time-to-first-token (TTFT) latency, negatively impacting user experience.

After iterating on these approaches in the weeks after launch, we’ve implemented a method that yields comparable results to HyDE without slowing the system down. Our current approach allowed us to maintain an engaging and responsive interface while still enhancing Pulumi AI’s accuracy.

We continue to follow the latest research in this space to improve Pulumi AI, and we hope we can contribute our learnings back in this exciting field of research!

Improved User Experience and Examples

With the integration of Pulumi Package schema data, Pulumi AI now generates more accurate and relevant Pulumi programs, favoring our high-level components and the generally available providers we recommend, such as the awsx, eks, and azure-native packages.

Powerful components

For EKS clusters, Pulumi AI now typically recommends our eks provider’s high level component when asked for “an eks cluster”:

To achieve your goal of creating an EKS cluster, I recommend using the eks.Cluster Pulumi resource, which is a higher-level component encapsulating the necessary AWS and Kubernetes resources. This resource makes it easy to provision, scale, and manage EKS clusters in a Pulumi Python program.

To proceed, you’ll need to have the pulumi-eks package installed:
pip install pulumi-eks
Here’s a simple Pulumi Python program that creates an EKS cluster:
import pulumi
from pulumi_eks import Cluster

# Create an EKS cluster.
my_cluster = Cluster("my-cluster")

# Export the cluster kubeconfig.
pulumi.export("kubeconfig", my_cluster.kubeconfig)

Simple building blocks

Pulumi AI now offers a more succinct solution for common queries such as “a static website on Azure”:

To accomplish your goal, I will generate a Pulumi TypeScript program using the azure-static-website.Website resource from the Pulumi Registry. This resource is designed specifically for hosting static websites on Azure.

Here’s a Pulumi TypeScript program to deploy a static website on Azure using the azure-static-website.Website resource.
import * as pulumi from "@pulumi/pulumi";
import * as azure from "@pulumi/azure";
import * as staticWebsites from "@pulumi/azure-static-website";

const website = new staticWebsites.Website("website", {
 sitePath: websitePath,
 resourceGroupName: resourceGroup.name,
 withCDN: true,
});

New products

When asked for modern resources such as Google AlloyDB, launched six weeks ago, Pulumi AI now references Registry documentation to answer “google alloydb with an automatic backup policy”:

Based on the Pulumi Registry results and trying to accomplish your goal of creating an AlloyDB cluster with an automatic backup policy, we can create a Google Cloud Platform (GCP) AlloyDB cluster using the gcp.alloydb.Cluster resource. You can set the automatedBackupPolicy property with the necessary configuration to enable automatic backups.

Here’s a Pulumi program in TypeScript that creates an AlloyDB Cluster with an automatic backup policy:

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

const projectId = gcp.config.project;
const location = "us-central1";

const network = new gcp.compute.Network("alloydb-network", {
 autoCreateSubnetworks: false,
});

const alloydbCluster = new gcp.alloydb.Cluster("alloydbCluster", {
 clusterId: "my-alloydb-cluster",
 location,
 project: projectId,
 network: network.selfLink,
 automatedBackupPolicy: {
 enabled: true,
 labels: {
 "backup-type": "automated",
 },
 location: "us-central1",
 quantityBasedRetention: {
 count: 7,
 },
 timeBasedRetention: {
 retentionPeriod: "7d",
 },
 weeklySchedule: {
 daysOfWeeks: ["MONDAY", "WEDNESDAY", "FRIDAY"],
 startTimes: [
 {startTime: "04:00:00"},
 ],
 },
 },
});

export const alloyDBClusterName = alloydbCluster.name;

Getting Started with the Enhanced Pulumi AI

Our enhancements to Pulumi AI have made it an even more useful tool for generating accurate and relevant cloud infrastructure solutions. We’re excited about the future of Pulumi AI as we continue to integrate it into Pulumi Cloud and empower everyone to become a cloud engineer.

We’ve also added new ways to reach Pulumi AI. In the Pulumi Registry, “Explore with Pulumi AI” links provide interactive documentation. And after you’ve had a conversation with Pulumi AI, you can share it via a “Share conversation” link in the bottom right corner of the message box:

Try out Pulumi AI today, and happy coding!

Using AWS Quick Starts with the Pulumi Registry

Aidan Hoolachan — Wed, 05 Jan 2022 00:00:00 +0000

As somebody who works on AWS projects across numerous projects, teams, and industries; I see the following three common types of infrastructure problems. I think the Pulumi Registry provides an incredible solution to each of these problems and will fundamentally change how people interact with AWS.

Common AWS infrastructure problems:

AWS Console Wizard Fever - These companies use the AWS Console to deploy resources. They move very quickly initially but eventually their AWS accounts become cluttered with untracked resources and they need to do some heavy lifting to set up robust dev / staging / prod environments. Many AWS developers scoff at the idea of using the Console, but I actually think this is currently an okay approach for a lot of people / companies in the early stages of AWS development. The console provides a lot of assistance when doing deployments and most people don’t need very complicated infrastructure initially. It’s not ideal because of the tech debt but it’s the right choice for many situations (at least, it was the right choice before the Pulumi registry).
YAML/JSON CloudFormation Template Ceiling - These companies have the right idea to use Infrastructure as Code, but CloudFormation YAML/JSON templates or other limited frameworks like Amplify are unwieldy and have their own scaling problems. Most people who work closely with AWS advocate for Infrastructure as Code (I do too), but it really is a steep learning curve and can be a lot of overhead for many simple applications. Setting up email alarms when a database goes down requires specialized AWS knowledge to do correctly – which makes a basic feature like email/slack alarm notifications feel like a sophisticated luxury. It shouldn’t be complicated, but it is.
AWS Lock-in - These are companies who lean into the AWS ecosystem for convenience sake. They might choose Cognito over a third-party Identity Provider even though the third-party Identity Provider might be a superior service.

The underlying cause of these problems is that AWS’s core services are designed for modularity within the AWS ecosystem, which is great for flexibility and experienced AWS developers, but it makes building best-practice AWS environments surprisingly difficult. Most “best practice” features on AWS, like email alarms when a database goes down, should really be the standard practice, but those features currently require complicated cross-service relationships that are difficult to implement correctly. The AWS ecosystem has been waiting for a layer of abstraction on top of these resources.

Pulumi and the AWS Quick Starts in the Pulumi Registry use higher-order components to abstract away that underlying complexity which makes configuring, deploying, and managing critical AWS resources straightforward – like it should be.

Configuring an Aurora Postgresql database with best practices (again, what should really just be the standard practices) requires specialized AWS knowledge and provisioning a zoo of other critical resources:

Encryption (2 resources) - KMS Key + KMS Key Policy
Access logging (4 resources) - S3 + S3 Bucket Policy + Encryption (KMS, again) + IAM Role
Alarms with notifications (3 Resources) - Cloudwatch Events + SNS + SNS Subscription
Networking infrastructure - (4+ resources) VPCs + Subnets + Gateways, etc.
Username and password - (1 resource) Secrets Manager Secret
Redundancy - (multiple resources) RDS multi-AZ clusters
IAM - (too many resources) Various IAM roles and policies

If “Aurora Postgres RDS” were a third-party SaaS or PaaS service provider, the service would abstract away the above details and provide simple parameters for enabling encryption, alarms, notifications, network security, redundancy, monitoring, and logging. With Pulumi, that abstraction is possible while providing open-source access to the underlying AWS resource definitions and with much more flexibility than traditional CloudFormation or Terraform. Those features can even be enabled by default. I believe that AWS “best practices” will also become the easiest approach with Pulumi as the ecosystem matures around the best packages.

When writing the Pulumi providers for AWS Quick Start VPC, AWS Quick Start Aurora Postgres, and AWS Quick Start Redshift, we were able to fight through the complexity and implement the best practices listed above. Those practices are enabled by default but can be disabled using a flag (eg enableEncryption: false). The result is a simple interface for deploying a VPC, an Aurora Postgresql cluster, and a Redshift cluster along with all of the other resources needed for best practice deployments. The process for writing these AWS providers was straightforward and intuitive. The Pulumi deployment and debug process was pleasant and I was able to go through most of the deploy + debug + tear down lifecycle without leaving the terminal.

The following code deploys a VPC, an Aurora Postgresql Cluster, a Redshift Cluster, and the various helper resources needed for encryption, logging, database alarms, vpc flow logs, etc. – for a total of 47 resources deployed using only three functions with simple parameters.

import * as pulumi from "@pulumi/pulumi";
import * as vpcQuickstart from "@pulumi/aws-quickstart-vpc";
import * as redshiftQuickstart from "@pulumi/aws-quickstart-redshift";
import * as auroraQuickstart from "@pulumi/aws-quickstart-aurora-postgres";

const notificationEmail = process.env.notificationEmail;
const dbPasswordSecret = pulumi.secret(process.env.databasePassword);

// Create a best-practices VPC
// Deploys 21 resources
const multiAvailabilityZoneVpc = new vpcQuickstart.Vpc("example-aurora-vpc", {
 cidrBlock: "10.0.0.0/16",
 availabilityZoneConfig: [{
 availabilityZone: "us-east-1a",
 publicSubnetCidr: "10.0.128.0/20",
 privateSubnetACidr: "10.0.32.0/19",
 }, {
 availabilityZone: "us-east-1b",
 privateSubnetACidr: "10.0.64.0/19",
 }]
})

// Create a best-practices Aurora Postgresql cluster
// Deploys 17 resources
const multiAvaialabilityZoneAuroraCluster = new auroraQuickstart.Cluster("example-aurora-cluster", {
 vpcID: multiAvailabilityZoneVpc.vpcID,
 dbName: "myDemoDatabase",
 dbEngineVersion: "11.9",
 dbInstanceClass: "db.t3.medium",
 availabilityZoneNames: ["us-east-1a", "us-east-1b"],
 dbNumDbClusterInstances: 2,
 dbMasterUsername: "mainuser",
 snsNotificationEmail: databaseNotificationEmail,
 enableEventSubscription: true,
 dbMasterPassword: dbPasswordSecret,
 dbParameterGroupFamily: "aurora-postgresql11",
 privateSubnetID1: multiAvailabilityZoneVpc.privateSubnetIDs.apply(x => x![0]),
 privateSubnetID2: multiAvailabilityZoneVpc.privateSubnetIDs.apply(x => x![1]),
});

// Create a best-practices Redshift cluster
// Deploys 8 resources
const cluster = new redshiftQuickstart.Cluster("example-redshift-cluster", {
 vpcID: multiAvailabilityZoneVpc.vpcID,
 dbPort: 5432,
 dbClusterIdentifier: "example-redshift-cluster",
 dbMasterUsername: "mainuser",
 notificationEmail: notificationEmail,
 enableEventSubscription: true,
 dbMasterPassword: dbPasswordSecret,
 dbName: "main",
 dbNodeType: "dc2.large",
 subnetIDs: multiAvailabilityZoneVpc.privateSubnetIDs as pulumi.Output<string[]>
})

These AWS Quick Start components are recommended for developers with all levels of AWS skill. For developers who don’t work with AWS frequently, these Quick Starts can replace the AWS Console Wizards for confidently provisioning resources.

For experienced AWS developers who want to use these components and are concerned about abstraction, there are several options: (1) review the underlying open source code, (2) do a quick proof-of-concept deployment and use Pulumi’s resource management tools to review the resources, and (3) when necessary, alter the underlying code! In my experience, because I was so accustomed to defining every painful detail of AWS infrastructure, the abstractions felt almost too easy to use. However, once I became comfortable with the underlying design patterns, these packages made deploying complicated AWS architectures incredibly easy, quick, and reliable.

For service providers considering providing a Pulumi package for their service offering – as an AWS developer, the most exciting part of this toolset is the ability to choose non-AWS tools without sacrificing convenience. I sometimes choose Cognito over Okta simply because Cognito is in the AWS ecosystem. If service provider packages are as convenient as using native AWS tools, they become more competitive with AWS’ native services.

Returning to the initial three problems:

AWS Console Wizard Fever - By creating many of the “helper” resources (like email notifications when the database goes down), the Pulumi registry serves the same purpose as the AWS Console wizards – “best practice” infrastructure / applications are available at the click of a button.
YAML/JSON CloudFormation Template Ceiling - Software / programming languages are much easier to work with than YAML or JSON templates. Programming languages provide simpler logic, abstraction, auto-complete, guardrails, open-source imports, and all of the other benefits of programming languages. Furthermore, the Pulumi framework provides infrastructure review tools during deployments, which mitigates the risks of programming language bugs affecting deployments (eg. there are robust safeguards against an infinite “for” loop spinning up an infinite number of EC2 instances).
AWS Lock-in - In addition to Pulumi making it substantially easier to use AWS services, Pulumi makes it substantially easier to use other SAAS and cloud providers alongside AWS resources. As the registry matures around standard abstractions, I can imagine constructs for “Postgres Database” or “Serverless Website” or “Next.js Deployment” that are implemented by multiple SAAS or cloud providers such that a developer can switch clouds with a few minor configuration changes.

For getting started, I recommend starting with the examples for the AWS Quick Start VPC, AWS Quick Start Aurora Postgres, and Aurora Quick Start Redshift.