Pulumi Blog: Pat Gavlin

Introducing pulumi do: Direct Resource Operations for Any Cloud

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

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

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

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

The problem: Sometimes IaC is more than you need

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

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

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

What it looks like

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

$ pulumi do aws:s3:Bucket create

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

$ pulumi do aws:s3:Bucket create

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

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

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

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

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

$ pulumi do aws:ec2:getVpc --default

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

Same CLI, same output contract, same provider ecosystem.

The command shape

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

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

$ pulumi do aws:s3

Functions and resources for the s3 module.

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

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

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

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

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

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

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

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

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

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

The result:

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

Resource operations

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

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

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

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

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

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

Provider configuration

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

Designed for humans and agents

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

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

What’s next

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

Unified credentials with Pulumi ESC

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

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

Cross-resource references

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

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

Stateful mode and the graduation path

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

Here’s what we’re planning:

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

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

Get started

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

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

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

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

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

What this means for you

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

Production results

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

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

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

What you need to do

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

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

Unveiling Pulumi ESC Versioning: Manage Secrets and Deployments with Confidence

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

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

Uncover the Key Features of Pulumi ESC Versioning

Pulumi ESC Versioning introduces a range of powerful features:

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

Level Up Your Workflow

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

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

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

How to Get Started

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

Using the CLI

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

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

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

Using the Console

In your Pulumi Cloud Console,

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

Real-world Scenarios

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

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

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

Conclusion

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

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

Check out the Pulumi CLI and Versioning docs.

Introducing the Latest ESC Editor Enhancements for Improved Authoring

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

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

Highlights

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

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

Contextual Information to your environments

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

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

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

For the current, complete list of context properties, see Built-in properties.

A Seamless Authoring Experience Awaits

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

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

Review Stacks: Collaborate in the Cloud

Evan Boyle — Wed, 14 Jun 2023 00:00:00 +0000

Today we’re excited to announce Review Stacks – dedicated cloud environments that get created automatically every time a pull request is opened, all powered by Pulumi Deployments. Open a pull request, and Pulumi Deployments will stand up a stack with your changes and the Pulumi GitHub App will add a PR comment with the outputs from your deployment. Merge the PR and Pulumi Deployments will destroy the stack and free up the associated resources. It has never been simpler to pick up an unfamiliar codebase, make changes to both application and infrastructure code, and share a live environment for review with your teammates.

Ephemeral environments for front-end development and static websites have become commonplace in recent years, but infrastructure and complex systems have been unsupported up until this point. Review Stacks enable you to iterate on both application code changes and infrastructure code changes at the same time. Making changes to HTML, CSS, Next.js, Go APIs, Pulumi configuration, subnet configuration, databases, and load balancers are all possible with Review Stacks. No more fumbling with out-of-date READMEs and developer documentation. Just open a pull request and you can start testing changes against everything from simple static websites to API servers, microservices, data pipelines, Kubernetes clusters, and any other piece of infrastructure across Pulumi’s 100+ cloud providers.

Review Stacks manage the full lifecycle of your cloud development environment including creating it when the PR is opened, updating it every time a new commit is pushed, and destroying and cleaning up all cloud resources when the pull request is merged or closed. They even integrate with GitHub checks so that you can gate your pull requests on successful Review Stack deployments.

Pulumi customers already using Review Stacks find that it saves their developers time. Having a standardized process for development environments and change management makes it easier to onboard new developers, and load-balance teammates onto unfamiliar projects and codebases. It also makes it substantially easier for developers to work on multiple feature branches and bug fixes at the same time, as they don’t have to worry about manually maintaining and juggling development environments.

“Pulumi allows every engineer to build and update infrastructure instead of only our infrastructure team, which enables us to ship faster than if we were using a domain-specific language,” said Aaron Gibralter, head of engineering, Mighty. “With Pulumi Deployments, we could easily set up a standardized CI/CD infrastructure workflow for every engineer that immediately makes them productive. Review Stacks automates the work of managing our own ephemeral infrastructure and makes our lives easier.”

Review Stacks also provide an avenue for optimizing cloud costs. Rather than keeping development infrastructure running 24/7, Review Stacks only exist as long as an engineer works on a feature. Since Review Stacks are flexible and built on Pulumi IaC, it is also possible to configure it to deploy to multi-tenant environments that share development infrastructure to further streamline costs.

“At GitHub, we are constantly seeking to improve the developer experience and our partner ecosystem plays a big role in that.” said Matthew Manning, Senior Business Development Manager for GitHub Actions, “The launch of Pulumi Review Stacks with GitHub makes it easier for teams to review and test their products before shipping which ultimately improves the developer experience.”

Configuring Review Stacks

Configuring Review Stacks is a simple three-step process:

Create a new stack, by convention named pr, and corresponding Pulumi.pr.yaml configuration file - this config will be copied into every review stack that gets created, and can even be modified within a PR.
Configure Deployment Settings for the stack - this specifies how to acquire source code, cloud credentials and more when deploying via Pulumi Deployments.
Set the pullRequestTemplate Deployment Setting to true - this indicates that all pull requests against this stack’s branch should reference this stack as a Review Stack template.

You can use an existing stack as a Review Stack template, as long as it has Deployment Settings configured. This will result in Review Stacks being deployed into the same cloud account. If you want to separate the cloud resources in your production stack from the resources created via Review Stacks then you can create a separate stack and template that references a different cloud account (AWS, Azure, GCP, etc).

Review Stacks and Deployment Settings can be configured via the Pulumi Cloud console, the Pulumi Cloud REST API, or within a Pulumi Program using the Pulumi Cloud Resource Provider.

Pulumi Cloud UI

It is just one click to turn on Review Stacks via the Pulumi Cloud console.

REST API

You can programmatically configure Review Stacks and Deployment Settings at scale across thousands of projects using the Deployments REST API.

curl -i -XPOST -H "Content-Type: application/json" -H "Authorization: token $PULUMI_ACCESS_TOKEN" \
--location "https://api.pulumi.com/api/stacks/org/project/stack/deployments/settings" \
-d '{
"gitHub":{
"pullRequestTemplate": true
}
}'

Pulumi Cloud Resource Provider

You can use Pulumi to manage and code review Deployment Settings and Review Stacks with the Pulumi Cloud Provider.

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

const deploymentSettings = new pulumiservice.DeploymentSettings("deploymentSettings", {
 organization: pulumi.getOrganization(),
 project: "your project",
 stack: "your stack",
 github: {
 deployCommits: true,
 previewPullRequests: true,
 pullRequestTemplate: true,
 repository: "pulumi/deployment-automation",
 },
 sourceContext: {
 git: {
 branch: "refs/heads/main",
 repoDir: "pulumi-pet-shop",
 },
 },
});

Collaborate in the Cloud

At Pulumi, our engineering team writes a ton of code. We have hundreds of repositories with programs managing thousands of stacks and tens of thousands of cloud resources. These tools and services power production workloads, internal tools, business intelligence and process, and more. And of course we use Pulumi to ship all of it. When you’re an engineer working in one of these repositories, making a code change is the easy part. The hard part is figuring out how to get a tight dev loop going—in particular, faithfully verifying your changes before merging and deploying them. Are there instructions in the README for running locally? A Docker Compose file? Or maybe standalone dev environments? Can I figure out what config and upstream stack references are required to stand up a fresh dev stack? And what about service dependencies? Pulumi makes it incredibly easy to build in the cloud and write prolific amounts of code, however, with that increase in development velocity comes a need to standardize the entire process by which we develop, test, review, and ship our code.

We’ve heard similar stories from hundreds of customers. From startup teams of five to enterprises of thousands, they’re all looking for the same thing - so we went ahead and built it. With Review Stacks and Pulumi Deployments, you can ship with greater velocity, confidence, and collaboration.

Check out these resources and get started today:

Review Stacks documentation
Learn more about Pulumi Deployments
Join us in the #pulumi-deployments community slack channel

🚀🚀🚀 Happy building! 🚀🚀🚀

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!

Managing credentials with Open ID Connect for Pulumi Deployments

Pat Gavlin — Fri, 06 Jan 2023 11:10:50 -0800

After launching Pulumi Deployments a few months ago and receiving a ton of community feedback (thank you!) today we are launching an integration with OpenID Connect (OIDC) to enable temporary credentials and granular access controls. We would like to thank GitHub user eriklz for creating the original request for this functionality.

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.

Setup

Calling the Deployments REST API

You can call the Deployments REST API and use OIDC instead of cloud secrets. Here is an example of how that might look:

Enabling OIDC for your Stack for Git Push to Deploy

In order to use the Git Push to Deploy and Click to Deploy features in the Pulumi Service console you will need to enable OIDC for your stack in the console. In order to enable it you will need to be an admin of your Pulumi organization.

Navigate to your stack in the Pulumi Console.
Open the stack’s “Settings” tab.
Choose the “Deploy” panel.
Under the “OpenID Connect” header, toggle to your cloud provider
Follow the cloud provider specific docs below

Viewing Deployment logs

Once OIDC is set up you will see a new step in your Deployment logs “Fetch credentials via OIDC”

Getting access to Pulumi Deployments

Pulumi Deployments 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
Pulumi Deployments examples repo
Pulumi Deployments documentation
Pulumi Deployments REST API documentation
Automation API examples

Please submit an issue in the Pulumi Service Requests repo if you have feature requests for the Pulumi Service or join our Slack channel(#pulumi-deployments) if you have questions.

🚀🚀🚀 Happy building! 🚀🚀🚀

From Terraform to Infrastructure as Software

Pat Gavlin — Fri, 02 Nov 2018 00:00:00 +0000

Here at Pulumi, we love programming the cloud using infrastructure as code. From the project’s outset, we’ve been inspired by technologies like Terraform, AWS CloudFormation, and Helm, and in fact leverage the Terraform Providers ecosystem, to support a broad range of clouds, including AWS, Azure, and Google Cloud.

Just recently, we extended this with first class support for Kubernetes. Pulumi delivers the same infrastructure as code workflows only using general purpose languages like JavaScript, TypeScript, Python, and Go, extending robust infrastructure provisioning with abstraction and reuse, highly productive tooling, and access to all the other things we already know and love about programming languages.

In this article, we will convert existing Terraform configuration to Pulumi TypeScript. By doing so, we’ll see how using general purpose programming languages can help you create simpler, more flexible infrastructure as code, with greater productivity and less repetition. The infrastructure we’ll be working with describes a load-balanced web server hosted by an AWS EC2 instance per availability zone with an option to allow SSH access. Of course, these same benefits would also accrue were we to target Azure, Google Cloud, or Kubernetes instead.

Starting from Terraform Configuration

The Terraform configuration we’ll be starting with is below. This configuration accepts a list of AZs and an optional public key as inputs and produces a (possibly empty) list of the web servers’ public IP addresses and the URL of the load-balanced web site as outputs. When a public key is provided, this configuration will enable SSH access to the virtual machines that serve the web site.

Let’s walk the example one step at a time – feel free to skip ahead if you’re a Terraform expert and just want to see how Pulumi is different.

First, we declare that availability_zones and public_key are parameterizable inputs:

variable "availability_zones" {}
variable "public_key" {
default = ""
}

And then we look up the latest AWS AMI for Ubuntu Trusty in our current region. This is what our web server will run when we get around to provisioning it later:

data "aws_ami" "ubuntu" {
 most_recent = true
 filter {
   name   = "name"
   values = ["ubuntu/images/hvm-ssd/ubuntu-trusty-14.04-amd64-server-*"]
 }
 filter {
   name   = "virtualization-type"
   values = ["hvm"]
 }
 owners = ["099720109477"] # Canonical
}

Next, we’ll create security groups that allow HTTP ingress on port 80 and, if a public key is available, SSH over port 22, in addition to allowing outbound Internet access. Notice that we are using the count property for the SSH rule to enable it conditionally:

resource "aws_security_group" "default" {
name_prefix = "example_sg"
}
resource "aws_security_group_rule" "allow_http" {
type = "ingress"
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
security_group_id = "${aws_security_group.default.id}"
}
resource "aws_security_group_rule" "allow_all_outbound" {
type = "egress"
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
security_group_id = "${aws_security_group.default.id}"
}
resource "aws_security_group_rule" "allow_ssh" {
 count = "${var.public_key == "" ? 0 : 1}"
 type = "ingress"
 from_port = 22
 to_port = 22
 protocol = "tcp"
 cidr_blocks = ["0.0.0.0/0"]
 security_group_id = "${aws_security_group.default.id}"
}

Now let’s actually create the web servers. This is where things get a little awkward in a DSL, because we want to conditionally attach the key_name, based on whether SSH access is enabled. This requires that we duplicate some configuration for the key and no-key code paths, in addition to splitting, transforming, and indexing into our list of AZs:

 resource "aws_key_pair" "default" {
 count = "${var.public_key == "" ? 0 : 1}"
 key_name_prefix = "default"
 public_key = "${var.public_key}"
}
resource "aws_instance" "web-server-key" {
 count = "${var.public_key == "" ? 0 : length(split(",", var.availability_zones))}"
 ami = "${data.aws_ami.ubuntu.id}"
 instance_type = "t2.micro"
 availability_zone = "${element(split(",", var.availability_zones), count.index)}"
 user_data = "${file("userdata.sh")}"
 security_groups = ["${aws_security_group.default.name}"]
 key_name = "${aws_key_pair.default.0.key_name}"
}
resource "aws_instance" "web-server-nokey" {
 count = "${var.public_key == "" ? length(split(",", var.availability_zones)) : 0}"
 ami = "${data.aws_ami.ubuntu.id}"
 instance_type = "t2.micro"
 availability_zone = "${element(split(",", var.availability_zones), count.index)}"
 user_data = "${file("userdata.sh")}"
 security_groups = ["${aws_security_group.default.name}"]
}

After creating the web servers, we will create and attach an ELB, so that traffic is spread across the AZs. This also requires the same conditional duplication for key and no-key configurations:

resource "aws_elb" "elb" {
name_prefix = "webelb"
availability_zones = ["${split(",", var.availability_zones)}"]
listener {
instance_port = 80
instance_protocol = "http"
lb_port = 80
lb_protocol = "http"
}
health_check {
healthy_threshold = 2
unhealthy_threshold = 2
timeout = 3
target = "HTTP:80/"
interval = 30
}
}
resource "aws_elb_attachment" "web-server-key" {
count = "${var.public_key == "" ? 0 : length(split(",", var.availability_zones))}"
elb = "${aws_elb.elb.id}"
instance = "${element(aws_instance.web-server-key.*.id, count.index)}"
}
resource "aws_elb_attachment" "web-server-nokey" {
count = "${var.public_key == "" ? length(split(",", var.availability_zones)) : 0}"
elb = "${aws_elb.elb.id}"
instance = "${element(aws_instance.web-server-nokey.*.id, count.index)}"
}

Finally, we’ll export the public instance IPs for SSH access (if enabled) and the ELB URL:

output "public_ips" {
 value = "${aws_instance.web-server-key.*.public_ip}"
}
output "url" {
 value = "http://${aws_elb.elb.dns_name}"
}

And that’s it. This program provisions an EC2 VM per AZ in your region of choice, behind a load balancer, with conditional SSH enablement.The full code is available here if you’d like to see it in one place.

Migrating to a General Purpose Language

Now let’s see how to migrate this program to using a general purpose language. There are several opportunities to simplify the program – most immediately apparent, using familiar if statements instead of the the awkward conditionals that use count variables.

We could just go ahead and convert the program by hand, however the tf2pulumi tool was designed to take a Terraform HCL program as input and perform the entire translation automatically for you. This is a great place to get started – and from there we can then refactor the resulting program gradually to leverage languages better.

As of Pulumi CLI v3.71.0, tf2pulumi has been replaced with pulumi convert --from terraform. Converting Full Terraform Programs to Pulumi blog has more details.

The first step is to create a Pulumi project. Download Pulumi here, and then run:

$ pulumi new aws-typescript
-n webservers -d "Pulumi Web Servers" -g -f

Run this from wherever your Terraform program resides. This will initialize and scaffold a minimal Pulumi TypeScript program targeting AWS in the pulumi subdirectory.

We’ll then install tf2pulumi, and run it, to generate the Pulumi TypeScript program in index.ts:

$ tf2pulumi

The full program created by this command can be found here. Notice that it looks structurally very similar to the Terraform HCL program above, except that it’s written in TypeScript instead. Even this rote translation has benefits – for example, open it in your favorite editor, and you’ll notice you get syntax highlighting, statement completion, and integrated documentation. But we’ll soon see that once we have this code in our favorite language, we can refactor it to leverage familiar programming languages more idiomatically, reducing a lot of boilerplate.

After the conversion is complete, we can create, configure, and update a Pulumi stack to create the resources described by the generated Pulumi program:

$ cd pulumi
$ npm install
$ pulumi stack init webservers-prod
$ pulumi config set aws:region us-west-2
$ pulumi config set availabilityZones "us-west-2a,us-west-2b,us-west-2c"
$ pulumi up

A Pulumi stack is an environment that can be configured and deployed to independently of all other stacks. Here we’ve created webservers-prod and set it to deploy into the us-west-2a, us-west-2b, and us-west-2c availability zones in AWS’s us-west-2 region. pulumi up will then show you a plan and then let you confirm it to deploy your resources:

After selecting “yes”, the update will proceed with interactive status updates:

Leveraging Programming Languages

This is great – we now have a working Pulumi program. Let’s now go about simplifying the generated code so that it is easier to read, understand, and maintain. We’ll only scratch the surface in this post, as many of the real benefits shine when you go beyond a single program and use reusable constructs like functions, classes, and packages, to cut down on copy and paste. But even some of the syntactic transformations we’ll make can provide a real boost to productivity.

First, notice that our package dependencies are just NPM packages. The full ecosystem of our language’s native package manager is available to us:

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

The first order of business is to place the list of configured availability zones into a local variable:

const availabilityZones = config.require("availabilityZones").split(",");

Because Pulumi programs are ordinary programs, we can use variables in the usual ways. Notice that we’ve not only defined a variable, but also split the string, so that we don’t need to do it on every usage within the file, using the standard JavaScript split function.

Terraform data sources are represented as function calls in our program. So, to fetch the Ubuntu AMI, we simply call the getAmi function, passing in the filters as parameters to it:

const ubuntuAmi = aws.getAmi({
 filters: [
 { name: "name", values: ["ubuntu/images/hvm-ssd/ubuntu-trusty-14.04-amd64-server-*"] },
 { name: "virtualization-type", values: ["hvm"] },
 ],
 mostRecent: true,
 owners: ["099720109477"], // Canonical
});

We already saw how the use of variables can save us from repeating ourselves over and over again, and again, we can use this to avoid repeating the 0.0.0.0/0 CIDR block everywhere:

const anyCidr = ["0.0.0.0/0"];
const webServerSg = new aws.ec2.SecurityGroup("default", {
 egress: [{ cidrBlocks: anyCidr, fromPort: 0, protocol: "-1", toPort: 0 }],
 ingress: [{ cidrBlocks: anyCidr, fromPort: 80, protocol: "tcp", toPort: 80 }],
});

Now we can change how we conditionally create the web server instances. This is where we’ll start to see the big wins, because we can use any of the familiar programming language control constructs, including for loops, case statements, if blocks, function calls, and even higher order list functions like map and filter.

In order to conditionally create a resource in Terraform, we had to set its count to either 0 or the desired AZ count. However, this affects any resources that depend on the conditional resource: the dependent resources either become conditional themselves or require complex interpolation expressions in order to ensure that the configuration does not reference any undefined properties. In our original Terraform configuration, the conditional creation of an AWS Key Pair forces us to declare our web servers twice: once with the key pair and once without.

resource "aws_key_pair" "default" {
count = "${var.public_key == "" ? 0 : 1}"
…
resource "aws_instance" "web-server-key" {
count = "${var.public_key == "" ? 0 : length(split(",", var.availability_zones))}"
…
resource "aws_elb_attachment" "web-server-key" {
count = "${var.public_key == "" ? 0 : length(split(",", var.availability_zones))}"
…
resource "aws_instance" "web-server-nokey" {
count = "${var.public_key == "" ? length(split(",", var.availability_zones)) : 0}"
…
resource "aws_elb_attachment" "web-server-nokey" {
count = "${var.public_key == "" ? length(split(",", var.availability_zones)) : 0}"
…

This is rather cumbersome. The syntactic transformation performed by tf2pulumi preserved this same structure to ensure the semantics of translation are identical, but we can now go back and clean it up considerably.

First, to conditionally allocate an EC2 KeyPair and to open port 22, we use an if statement:

let keyName: pulumi.Output<string> | undefined;
if (publicKey) {
 keyName = new aws.ec2.KeyPair("default", { publicKey }).id;
 new aws.ec2.SecurityGroupRule("allow_ssh", {
 type: "ingress",
 cidrBlocks: anyCidr,
 fromPort: 22,
 toPort: 22,
 protocol: "tcp",
 securityGroupId: webServerSg.id,
 });
}

The use of conditionals just works and interacts with planning just as you might expect, so that we always see the result of the conditional evaluation before we’ve decided to deploy anything.

Another subtle advantage is that we can just pass the webServerSg.id property – Pulumi understands the resource DAG, and the use of this property automatically forms an edge.

Now let’s create our web servers. We might use a for loop for this, and append each one to an array, however it’s just as easy to use the JavaScript map function to do this more declaratively:

const webServers: aws.ec2.Instance[] = availabilityZones.map(az =>
 new aws.ec2.Instance(`web-server-key-${az}`, {
 ami: ubuntuAmi.then(ami => ami.id),
 associatePublicIpAddress: publicKey !== "",
 availabilityZone: az,
 instanceType: "t2.micro",
 securityGroups: [ webServerSg.name ],
 userData: fs.readFileSync("userdata.sh", "utf-8"),
 keyName: keyName,
 }),
);

Interestingly, we’ve passed keyName to the constructor here, even though it might not have been defined (the JavaScript default value of undefined). Pulumi understands that this means “the absence of a value”, which is how we were able to simplify the web server provisioning so greatly. We also read in the userdata.sh file using standard JavaScript I/O functionality.

Now that we’ve simplified our configuration such that the web servers are declared once, we can simplify their interaction with the load balancer. We can just create the ELB last and pass it a list of all of our instances. We can also improve the reliability of configuration by ensuring that the ELB is associated with each availability zone in which we’ve created a web server:

const webServerElb = new aws.elasticloadbalancing.LoadBalancer("elb", {
 availabilityZones: webServers.map(instance => instance.availabilityZone),
 instances: webServers.map(instance => instance.id),
 healthCheck: {
 healthyThreshold: 2,
 interval: 30,
 target: "HTTP:80/",
 timeout: 3,
 unhealthyThreshold: 2,
 },
 listeners: [{
 instancePort: 80,
 instanceProtocol: "http",
 lbPort: 80,
 lbProtocol: "http",
 }],
});

Finally, the way we express outputs is by using standard JavaScript module exports:

export const publicIps = webServers.map(v => v.publicIp);
export const url = webServerElb.dnsName.apply(hostname => `http://${hostname}`);

And that’s it. After doing this refactoring, you can simply run pulumi up, and it will show you any diffs compared to your previous deployment, which you can choose to accept and deploy. The full code is available here.

Next Steps

In this post, we’ve applied general purpose programming languages to infrastructure as code to achieve more expressive and reusable programs, simplify our infrastructure’s readability and maintainability, and deliver a heightened level of productivity. Pulumi is open source and free to use – give it a try today!