Pulumi Blog: Providers

Pulumi AWS Provider 7.0: Multi-Region Support, IAM Role Chaining, and S3 Resource Simplification

Cory Hall — Tue, 05 Aug 2025 09:00:00 -0400

Pulumi AWS provider 7.0 is here with powerful new capabilities that simplify and scale infrastructure as code on AWS. As the most widely used provider in the Pulumi ecosystem, it offers access to the full surface area of the upstream Terraform AWS Provider in Pulumi projects in all supported languages, like TypeScript, Python, Go, C#, Java, and YAML.

The 7.0 release brings fixes and improvements to the provider, including several breaking changes as part of the major version release.

What’s New in Pulumi AWS Provider 7.0

Multi-Region AWS Deployments with a Single Provider

Previously the Pulumi AWS provider each provider configuration could target a single AWS region. This meant that users would need to create a separate provider configuration for each region they wanted to deploy resources to. As the number of providers configured in an application grew, it could sometimes lead to increased memory usage.

With the 7.0 release, the AWS provider now supports multiple regions with a single provider. Each resource now has a region input property that allows the user to specify the region at the resource level, while still utilizing the same provider.

Some key highlights of this feature include:

Single provider configuration: This reduces the need to load multiple instances of the AWS provider, lowering memory usage.
Region input property: The region input property is added to all resources (except global resources)
Resource import enhancements: A new @<regionID> suffix allows importing resources from different regions

This example shows how to use the new region input property to configure cross-region VPC peering.

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

const provider = new aws.Provider("provider", {region: "us-east-1"});
const mainVpc = new aws.ec2.Vpc("mainVpc", {cidrBlock: "10.0.0.0/16"}, {
 provider: provider,
});
const peerVpc = new aws.ec2.Vpc("peerVpc", {cidrBlock: "10.1.0.0/16"}, {
 provider: provider,
});
const peerConnection = new aws.ec2.VpcPeeringConnection("peerConnection", {
 vpcId: mainVpc.id,
 peerVpcId: peerVpc.id,
 peerRegion: "us-west-2",
 autoAccept: false,
}, {
 provider: provider,
});
const peerAcceptor = new aws.ec2.VpcPeeringConnectionAccepter("peerAcceptor", {
 region: "us-west-2",
 vpcPeeringConnectionId: peerConnection.id,
 autoAccept: true,
}, {
 provider: provider,
});

import pulumi
import pulumi_aws as aws

provider = aws.Provider("provider", region="us-east-1")
main_vpc = aws.ec2.Vpc("mainVpc", cidr_block="10.0.0.0/16",
opts = pulumi.ResourceOptions(provider=provider))
peer_vpc = aws.ec2.Vpc("peerVpc", cidr_block="10.1.0.0/16",
opts = pulumi.ResourceOptions(provider=provider))
peer_connection = aws.ec2.VpcPeeringConnection("peerConnection",
 vpc_id=main_vpc.id,
 peer_vpc_id=peer_vpc.id,
 peer_region="us-west-2",
 auto_accept=False,
 opts = pulumi.ResourceOptions(provider=provider))
peer_acceptor = aws.ec2.VpcPeeringConnectionAccepter("peerAcceptor",
 region="us-west-2",
 vpc_peering_connection_id=peer_connection.id,
 auto_accept=True,
 opts = pulumi.ResourceOptions(provider=provider))

package main

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

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 provider, err := aws.NewProvider(ctx, "provider", &aws.ProviderArgs{
 Region: pulumi.String("us-east-1"),
 })
 if err != nil {
 return err
 }
 mainVpc, err := ec2.NewVpc(ctx, "mainVpc", &ec2.VpcArgs{
 CidrBlock: pulumi.String("10.0.0.0/16"),
 }, pulumi.Provider(provider))
 if err != nil {
 return err
 }
 peerVpc, err := ec2.NewVpc(ctx, "peerVpc", &ec2.VpcArgs{
 CidrBlock: pulumi.String("10.1.0.0/16"),
 }, pulumi.Provider(provider))
 if err != nil {
 return err
 }
 peerConnection, err := ec2.NewVpcPeeringConnection(ctx, "peerConnection", &ec2.VpcPeeringConnectionArgs{
 VpcId: mainVpc.ID(),
 PeerVpcId: peerVpc.ID(),
 PeerRegion: pulumi.String("us-west-2"),
 AutoAccept: pulumi.Bool(false),
 }, pulumi.Provider(provider))
 if err != nil {
 return err
 }
 _, err = ec2.NewVpcPeeringConnectionAccepter(ctx, "peerAcceptor", &ec2.VpcPeeringConnectionAccepterArgs{
 Region: pulumi.String("us-west-2"),
 VpcPeeringConnectionId: peerConnection.ID(),
 AutoAccept: pulumi.Bool(true),
 }, pulumi.Provider(provider))
 if err != nil {
 return err
 }
 return nil
 })
}

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

return await Deployment.RunAsync(() =>
{
 var provider = new Aws.Provider("provider", new()
 {
 Region = "us-east-1",
 });

 var mainVpc = new Aws.Ec2.Vpc("mainVpc", new()
 {
 CidrBlock = "10.0.0.0/16",
 }, new CustomResourceOptions
 {
 Provider = provider,
 });

 var peerVpc = new Aws.Ec2.Vpc("peerVpc", new()
 {
 CidrBlock = "10.1.0.0/16",
 }, new CustomResourceOptions
 {
 Provider = provider,
 });

 var peerConnection = new Aws.Ec2.VpcPeeringConnection("peerConnection", new()
 {
 VpcId = mainVpc.Id,
 PeerVpcId = peerVpc.Id,
 PeerRegion = "us-west-2",
 AutoAccept = false,
 }, new CustomResourceOptions
 {
 Provider = provider,
 });

 var peerAcceptor = new Aws.Ec2.VpcPeeringConnectionAccepter("peerAcceptor", new()
 {
 Region = "us-west-2",
 VpcPeeringConnectionId = peerConnection.Id,
 AutoAccept = true,
 }, new CustomResourceOptions
 {
 Provider = provider,
 });

});

package generated_program;

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.core.Output;
import com.pulumi.aws.Provider;
import com.pulumi.aws.ProviderArgs;
import com.pulumi.aws.ec2.Vpc;
import com.pulumi.aws.ec2.VpcArgs;
import com.pulumi.aws.ec2.VpcPeeringConnection;
import com.pulumi.aws.ec2.VpcPeeringConnectionArgs;
import com.pulumi.aws.ec2.VpcPeeringConnectionAccepter;
import com.pulumi.aws.ec2.VpcPeeringConnectionAccepterArgs;
import com.pulumi.resources.CustomResourceOptions;
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 provider = new Provider("provider", ProviderArgs.builder()
 .region("us-east-1")
 .build());

 var mainVpc = new Vpc("mainVpc", VpcArgs.builder()
 .cidrBlock("10.0.0.0/16")
 .build(), CustomResourceOptions.builder()
 .provider(provider)
 .build());

 var peerVpc = new Vpc("peerVpc", VpcArgs.builder()
 .cidrBlock("10.1.0.0/16")
 .build(), CustomResourceOptions.builder()
 .provider(provider)
 .build());

 var peerConnection = new VpcPeeringConnection("peerConnection", VpcPeeringConnectionArgs.builder()
 .vpcId(mainVpc.id())
 .peerVpcId(peerVpc.id())
 .peerRegion("us-west-2")
 .autoAccept(false)
 .build(), CustomResourceOptions.builder()
 .provider(provider)
 .build());

 var peerAcceptor = new VpcPeeringConnectionAccepter("peerAcceptor", VpcPeeringConnectionAccepterArgs.builder()
 .region("us-west-2")
 .vpcPeeringConnectionId(peerConnection.id())
 .autoAccept(true)
 .build(), CustomResourceOptions.builder()
 .provider(provider)
 .build());

 }
}

name: cross-region-peering
runtime: yaml

resources:
 provider:
 type: pulumi:providers:aws
 properties:
 region: us-east-1
 mainVpc:
 type: aws:ec2:Vpc
 properties:
 cidrBlock: 10.0.0.0/16
 options:
 provider: ${provider}
 peerVpc:
 type: aws:ec2:Vpc
 properties:
 cidrBlock: 10.1.0.0/16
 options:
 provider: ${provider}
 peerConnection:
 type: aws:ec2:VpcPeeringConnection
 properties:
 vpcId: ${mainVpc.id}
 peerVpcId: ${peerVpc.id}
 peerRegion: us-west-2
 autoAccept: false
 options:
 provider: ${provider}
 peerAcceptor:
 type: aws:ec2:VpcPeeringConnectionAccepter
 properties:
 region: us-west-2
 vpcPeeringConnectionId: ${peerConnection.id}
 autoAccept: true
 options:
 provider: ${provider}

See the Enhanced Region Support guide for more details.

IAM Role Chaining for Secure AWS IaC Workflows

One of the most requested features, IAM role chaining, is now supported. This allows the Pulumi AWS Provider to assume multiple IAM roles in sequence to obtain credentials, streamlining secure AWS access across accounts and teams.

To assume a role with role chaining, you can now do the following:

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

const provider = new aws.Provider("provider", {assumeRoles: [
 {
 roleArn: "arn:aws:iam::123456789012:role/INITIAL_ROLE_NAME",
 },
 {
 roleArn: "arn:aws:iam::123456789012:role/FINAL_ROLE_NAME",
 },
]});

import pulumi
import pulumi_aws as aws

provider = aws.Provider("provider", assume_roles=[
 {
 "role_arn": "arn:aws:iam::123456789012:role/INITIAL_ROLE_NAME",
 },
 {
 "role_arn": "arn:aws:iam::123456789012:role/FINAL_ROLE_NAME",
 },
])

package main

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

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 _, err := aws.NewProvider(ctx, "provider", &aws.ProviderArgs{
 AssumeRoles: aws.ProviderAssumeRoleArray{
 &aws.ProviderAssumeRoleArgs{
 RoleArn: pulumi.String("arn:aws:iam::123456789012:role/INITIAL_ROLE_NAME"),
 },
 &aws.ProviderAssumeRoleArgs{
 RoleArn: pulumi.String("arn:aws:iam::123456789012:role/FINAL_ROLE_NAME"),
 },
 },
 })
 if err != nil {
 return err
 }
 return nil
 })
}

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

return await Deployment.RunAsync(() =>
{
 var provider = new Aws.Provider("provider", new()
 {
 AssumeRoles = new[]
 {
 new Aws.Inputs.ProviderAssumeRoleArgs
 {
 RoleArn = "arn:aws:iam::123456789012:role/INITIAL_ROLE_NAME",
 },
 new Aws.Inputs.ProviderAssumeRoleArgs
 {
 RoleArn = "arn:aws:iam::123456789012:role/FINAL_ROLE_NAME",
 },
 },
 });

});

package generated_program;

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.core.Output;
import com.pulumi.aws.Provider;
import com.pulumi.aws.ProviderArgs;
import com.pulumi.aws.inputs.ProviderAssumeRoleArgs;
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 provider = new Provider("provider", ProviderArgs.builder()
 .assumeRoles(
 ProviderAssumeRoleArgs.builder()
 .roleArn("arn:aws:iam::123456789012:role/INITIAL_ROLE")
 .build(),
 ProviderAssumeRoleArgs.builder()
 .roleArn("arn:aws:iam::123456789012:role/FINAL_ROLE")
 .build())
 .build());

 }
}

name: example
runtime: yaml
resources:
 provider:
 type: pulumi:providers:aws
 properties:
 assumeRoles:
 - roleArn: arn:aws:iam::123456789012:role/INITIAL_ROLE_NAME
 - roleArn: arn:aws:iam::123456789012:role/FINAL_ROLE_NAME

With this configuration the provider will use the INITIAL_ROLE to assume the FINAL_ROLE which will then be used as the credentials for the provider.

Simplified S3 Bucket Resource Model

In v6 of the Pulumi AWS Provider the S3 Bucket and BucketV2 resources represented different resource implementations. BucketV2 represented the latest version of the upstream Terraform resource, while Bucket was a separate resource maintained by Pulumi to keep backwards compatibility with the v4 release of the upstream Terraform Provider.

In v7 we are taking the first step in unifying these two resources by moving the S3 Bucket resource to the latest upstream implementation. As a result, in v7 both Bucket and BucketV2 will represent the latest version of the upstream Terraform S3 Bucket resource. As part of this work BucketV2 has been deprecated and will be removed in v8 of the Pulumi AWS Provider.

We have also introduced new S3 Bucket configuration resources that are alternatives to their V2 counterparts. The V2 versions will be removed in v8 of the Pulumi AWS Provider.

BucketAccelerateConfigurationV2 => BucketAccelerateConfiguration
BucketRequestPaymentConfigurationV2 => BucketRequestPaymentConfiguration
BucketAclV2 => BucketAcl
BucketCorsConfigurationV2 => BucketCorsConfiguration
BucketLifecycleConfigurationV2 => BucketLifecycleConfiguration
BucketLoggingV2 => BucketLogging
BucketObjectLockConfigurationV2 => BucketObjectLockConfiguration
BucketServerSideEncryptionConfigurationV2 => BucketServerSideEncryptionConfiguration
BucketVersioningV2 => BucketVersioning
BucketWebsiteConfigurationV2 => BucketWebsiteConfiguration

See the Migration Guide for more details on this change.

Upstream Improvements and Breaking Changes

Pulumi AWS 7.0 includes all improvements and bug fixes from the upstream (terraform-provider-aws) versions from 6.0.0 to 6.3.0. It also contains a number of upstream breaking changes. Please refer to the changelog to navigate the entire list.

Migration Guide

You can see a full list of changes and learn more about migrating your existing programs in our Migration Guide.

Getting Started with Pulumi AWS 7.0

Pulumi makes it easy to define, deploy, and manage modern AWS infrastructure with code:

Use your favorite languages: TypeScript, Python, Go, C#, Java, YAML
Explore the Pulumi AWS Provider repro
Check out the API reference docs

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 Command Provider 1.0 Release

Thomas Kappler — Mon, 01 Jul 2024 10:00:00 -0700

Today, we’re happy to announce the 1.0 release of the Pulumi Command provider. This release marks the provider’s official transition from preview status to general availability (GA). Since its first preview release in late 2021, thousands of Pulumi users incorporated the Command package into their cloud infrastructure projects to help manage local and remote command execution and filesystem operations. In fact, the Command provider is already our ninth-most popular provider, so it’s time to make things official!

The Pulumi Command Provider enables you to execute commands and scripts either locally or remotely as part of the Pulumi resource model, enabling stateful command execution. It also has convenient support for copying assets via SSH. Being able to run arbitrary commands opens up a wide variety of scenarios and integrations with other tools and systems.

Some of the provider’s popular uses include:

Running a command locally after creating a resource, to register it with an external service
Running a command locally before deleting a resource, to deregister it with an external service
Running a command on a remote host immediately after creating it
Copying a file to a remote host after creating it (potentially as a script to be executed afterwards)
As a simple alternative to some use cases for Dynamic Providers, by running appropriate commands in the different stages of the Pulumi life cycle.

Here’s a simple example of running an arbitrary command when another resource changes: once an AWS Lambda function is deployed, we call it and it responds with a message that is custom to the current Pulumi stack. In a real-world scenario, we could wait for a number of other resources to be deployed as well, and have the Lambda perform registration or initialization of services.

import * as aws from "@pulumi/aws";
import { local } from "@pulumi/command";
import { getStack } from "@pulumi/pulumi";

const f = new aws.lambda.CallbackFunction("f", {
 publish: true,
 callback: async (ev: any) => {
 return `Stack ${ev.stackName} is deployed!`;
 }
});

const invoke = new local.Command("execf", {
 create: `aws lambda invoke --function-name "$FN" --payload '{"stackName": "${getStack()}"}' --cli-binary-format raw-in-base64-out out.txt >/dev/null && cat out.txt | tr -d '"' && rm out.txt`,
 environment: {
 FN: f.qualifiedArn,
 AWS_REGION: aws.config.region!,
 AWS_PAGER: "",
 },
}, { dependsOn: f })

export const output = invoke.stdout;

import pulumi
import json
import pulumi_aws as aws
import pulumi_command as command

lambda_role = aws.iam.Role("lambdaRole", assume_role_policy=json.dumps({
 "Version": "2012-10-17",
 "Statement": [{
 "Action": "sts:AssumeRole",
 "Effect": "Allow",
 "Principal": {
 "Service": "lambda.amazonaws.com",
 },
 }],
}))

lambda_function = aws.lambda_.Function("lambdaFunction",
 name="f",
 publish=True,
 role=lambda_role.arn,
 handler="index.handler",
 runtime=aws.lambda_.Runtime.NODE_JS20D_X,
 code=pulumi.FileArchive("./handler"))

aws_config = pulumi.Config("aws")
aws_region = aws_config.require("region")

invoke_command = command.local.Command("invokeCommand",
 create=f"aws lambda invoke --function-name \"$FN\" --payload '{{\"stackName\": \"{pulumi.get_stack()}\"}}' --cli-binary-format raw-in-base64-out out.txt >/dev/null && cat out.txt | tr -d '\"' && rm out.txt",
 environment={
 "FN": lambda_function.arn,
 "AWS_REGION": aws_region,
 "AWS_PAGER": "",
 },
 opts = pulumi.ResourceOptions(depends_on=[lambda_function]))

pulumi.export("output", invoke_command.stdout)

package main

import (
 "encoding/json"
 "fmt"

 "github.com/pulumi/pulumi-aws/sdk/v6/go/aws/iam"
 "github.com/pulumi/pulumi-aws/sdk/v6/go/aws/lambda"
 "github.com/pulumi/pulumi-command/sdk/go/command/local"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi/config"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 awsConfig := config.New(ctx, "aws")
 awsRegion := awsConfig.Require("region")

 tmpJSON0, err := json.Marshal(map[string]interface{}{
 "Version": "2012-10-17",
 "Statement": []map[string]interface{}{
 {
 "Action": "sts:AssumeRole",
 "Effect": "Allow",
 "Principal": map[string]interface{}{
 "Service": "lambda.amazonaws.com",
 },
 },
 },
 })
 if err != nil {
 return err
 }
 json0 := string(tmpJSON0)
 lambdaRole, err := iam.NewRole(ctx, "lambdaRole", &iam.RoleArgs{
 AssumeRolePolicy: pulumi.String(json0),
 })
 if err != nil {
 return err
 }
 lambdaFunction, err := lambda.NewFunction(ctx, "lambdaFunction", &lambda.FunctionArgs{
 Name: pulumi.String("f"),
 Publish: pulumi.Bool(true),
 Role: lambdaRole.Arn,
 Handler: pulumi.String("index.handler"),
 Runtime: pulumi.String(lambda.RuntimeNodeJS20dX),
 Code: pulumi.NewFileArchive("./handler"),
 })
 if err != nil {
 return err
 }
 invokeCommand, err := local.NewCommand(ctx, "invokeCommand", &local.CommandArgs{
 Create: pulumi.String(fmt.Sprintf("aws lambda invoke --function-name \"$FN\" --payload '{\"stackName\": \"%v\"}' --cli-binary-format raw-in-base64-out out.txt >/dev/null && cat out.txt | tr -d '\"' && rm out.txt", ctx.Stack())),
 Environment: pulumi.StringMap{
 "FN": lambdaFunction.Arn,
 "AWS_REGION": pulumi.String(awsRegion),
 "AWS_PAGER": pulumi.String(""),
 },
 }, pulumi.DependsOn([]pulumi.Resource{
 lambdaFunction,
 }))
 if err != nil {
 return err
 }
 ctx.Export("output", invokeCommand.Stdout)
 return nil
 })
}

using System.Collections.Generic;
using System.Text.Json;
using Pulumi;
using Aws = Pulumi.Aws;
using Command = Pulumi.Command;

return await Deployment.RunAsync(() =>
{
 var awsConfig = new Config("aws");

 var lambdaRole = new Aws.Iam.Role("lambdaRole", new()
 {
 AssumeRolePolicy = JsonSerializer.Serialize(new Dictionary<string, object?>
 {
 ["Version"] = "2012-10-17",
 ["Statement"] = new[]
 {
 new Dictionary<string, object?>
 {
 ["Action"] = "sts:AssumeRole",
 ["Effect"] = "Allow",
 ["Principal"] = new Dictionary<string, object?>
 {
 ["Service"] = "lambda.amazonaws.com",
 },
 },
 },
 }),
 });

 var lambdaFunction = new Aws.Lambda.Function("lambdaFunction", new()
 {
 Name = "f",
 Publish = true,
 Role = lambdaRole.Arn,
 Handler = "index.handler",
 Runtime = Aws.Lambda.Runtime.NodeJS20dX,
 Code = new FileArchive("./handler"),
 });

 var invokeCommand = new Command.Local.Command("invokeCommand", new()
 {
 Create = $"aws lambda invoke --function-name \"$FN\" --payload '{{\"stackName\": \"{Deployment.Instance.StackName}\"}}' --cli-binary-format raw-in-base64-out out.txt >/dev/null && cat out.txt | tr -d '\"' && rm out.txt",
 Environment =
 {
 { "FN", lambdaFunction.Arn },
 { "AWS_REGION", awsConfig.Require("region") },
 { "AWS_PAGER", "" },
 },
 }, new CustomResourceOptions
 {
 DependsOn =
 {
 lambdaFunction,
 },
 });

 return new Dictionary<string, object?>
 {
 ["output"] = invokeCommand.Stdout,
 };
});

package generated_program;

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.aws.iam.Role;
import com.pulumi.aws.iam.RoleArgs;
import com.pulumi.aws.lambda.Function;
import com.pulumi.aws.lambda.FunctionArgs;
import com.pulumi.command.local.Command;
import com.pulumi.command.local.CommandArgs;
import static com.pulumi.codegen.internal.Serialization.*;
import com.pulumi.resources.CustomResourceOptions;
import com.pulumi.asset.FileArchive;
import java.util.Map;

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

 public static void stack(Context ctx) {
 var awsConfig = ctx.config("aws");
 var awsRegion = awsConfig.require("region");

 var lambdaRole = new Role("lambdaRole", RoleArgs.builder()
 .assumeRolePolicy(serializeJson(
 jsonObject(
 jsonProperty("Version", "2012-10-17"),
 jsonProperty("Statement", jsonArray(jsonObject(
 jsonProperty("Action", "sts:AssumeRole"),
 jsonProperty("Effect", "Allow"),
 jsonProperty("Principal", jsonObject(
 jsonProperty("Service", "lambda.amazonaws.com")))))))))
 .build());

 var lambdaFunction = new Function("lambdaFunction", FunctionArgs.builder()
 .name("f")
 .publish(true)
 .role(lambdaRole.arn())
 .handler("index.handler")
 .runtime("nodejs20.x")
 .code(new FileArchive("./handler"))
 .build());

 var lambdaInvokeOut = lambdaFunction.arn().applyValue(arn -> {
 var invokeCommand = new Command("invokeCommand", CommandArgs.builder()
 .create(String.format(
 "aws lambda invoke --function-name \"$FN\" --payload '{\"stackName\": \"%s\"}' --cli-binary-format raw-in-base64-out out.txt >/dev/null && cat out.txt | tr -d '\"' && rm out.txt",
 ctx.stackName()))
 .environment(Map.ofEntries(
 Map.entry("FN", arn),
 Map.entry("AWS_REGION", awsRegion),
 Map.entry("AWS_PAGER", "")))
 .build(),
 CustomResourceOptions.builder()
 .dependsOn(lambdaFunction)
 .build());

 return invokeCommand.stdout();
 });

 ctx.export("output", lambdaInvokeOut);
 }
}


resources:
 lambdaRole:
 type: aws:iam:Role
 properties:
 assumeRolePolicy:
 fn::toJSON:
 Version: "2012-10-17"
 Statement:
 - Action: sts:AssumeRole
 Effect: Allow
 Principal:
 Service: lambda.amazonaws.com

 lambdaFunction:
 type: aws:lambda:Function
 properties:
 name: f
 publish: true
 role: ${lambdaRole.arn}
 handler: index.handler
 runtime: "nodejs20.x"
 code:
 fn::fileArchive: ./handler

 invokeCommand:
 type: command:local:Command
 properties:
 create: 'aws lambda invoke --function-name "$FN" --payload ''{"stackName": "${pulumi.stack}"}'' --cli-binary-format raw-in-base64-out out.txt >/dev/null && cat out.txt | tr -d ''"'' && rm out.txt'
 environment:
 FN: ${lambdaFunction.arn}
 AWS_REGION: ${aws:region}
 AWS_PAGER: ""
 options:
 dependsOn:
 - ${lambdaFunction}

outputs:
 output: ${invokeCommand.stdout}

What’s new

The 1.0 release of the Command provider marks a stable API for the 1.x series. Rather than simply putting a “v1” label on the existing provider, we also used this opportunity to enhance it with some previously requested capabilities to provide a more complete set of capabilities.

The API documentation in the Pulumi registry has examples in all Pulumi languages and is expanded.
Capturing stdout and stderr of commands can now be switched off, which is useful when they might contain secrets or are very noisy.
Environment handling for remote commands has better error handling and is better documented.
The CopyFile resource is superseded by the new CopyToRemote resource. It can copy whole directories in addition to individual files. The source of the copy is now a Pulumi asset or archive which provides full interoperability with the Pulumi ecosystem. The use of assets and archives also makes Pulumi run copy operations only if the source has changed. For an easy transition, the previous CopyFile resource will remain available with a deprecation notice until the next major version.

Here’s an example of copying a directory to a remote host. For brevity, the remote server is assumed to exist, but it could also be provisioned in the same Pulumi program.

import * as pulumi from "@pulumi/pulumi";
import { remote, types } from "@pulumi/command";
import * as fs from "fs";
import * as os from "os";
import * as path from "path";

export = async () => {
 const config = new pulumi.Config();

 // Get the private key to connect to the server. If a key is
 // provided, use it, otherwise default to the standard id_rsa SSH key.
 const privateKeyBase64 = config.get("privateKeyBase64");
 const privateKey = privateKeyBase64 ?
 Buffer.from(privateKeyBase64, 'base64').toString('ascii') :
 fs.readFileSync(path.join(os.homedir(), ".ssh", "id_rsa")).toString("utf8");

 const serverPublicIp = config.require("serverPublicIp");
 const userName = config.require("userName");

 // The configuration of our SSH connection to the instance.
 const connection: types.input.remote.ConnectionArgs = {
 host: serverPublicIp,
 user: userName,
 privateKey: privateKey,
 };

 // Set up source and target of the remote copy.
 const from = config.require("payload")!;
 const archive = new pulumi.asset.FileArchive(from);
 const to = config.require("destDir")!;

 // Copy the files to the remote.
 const copy = new remote.CopyToRemote("copy", {
 connection,
 source: archive,
 remotePath: to,
 });

 // Verify that the expected files were copied to the remote.
 // We want to run this after each copy, i.e., when something changed,
 // so we use the asset to be copied as a trigger.
 const find = new remote.Command("ls", {
 connection,
 create: `find ${to}/${from} | sort`,
 triggers: [archive],
 }, { dependsOn: copy });

 return {
 remoteContents: find.stdout
 }
}

import pulumi
import pulumi_command as command

config = pulumi.Config()

server_public_ip = config.require("serverPublicIp")
user_name = config.require("userName")
private_key = config.require("privateKey")
payload = config.require("payload")
dest_dir = config.require("destDir")

archive = pulumi.FileArchive(payload)

# The configuration of our SSH connection to the instance.
conn = command.remote.ConnectionArgs(
 host = server_public_ip,
 user = user_name,
 privateKey = private_key,
)

# Copy the files to the remote.
copy = command.remote.CopyToRemote("copy",
 connection=conn,
 source=archive,
 destination=dest_dir)

# Verify that the expected files were copied to the remote.
# We want to run this after each copy, i.e., when something changed,
# so we use the asset to be copied as a trigger.
find = command.remote.Command("find",
 connection=conn,
 create=f"find {dest_dir}/{payload} | sort",
 triggers=[archive],
 opts = pulumi.ResourceOptions(depends_on=[copy]))

pulumi.export("remoteContents", find.stdout)

package main

import (
 "fmt"

 "github.com/pulumi/pulumi-command/sdk/go/command/remote"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi/config"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 cfg := config.New(ctx, "")
 serverPublicIp := cfg.Require("serverPublicIp")
 userName := cfg.Require("userName")
 privateKey := cfg.Require("privateKey")
 payload := cfg.Require("payload")
 destDir := cfg.Require("destDir")

 archive := pulumi.NewFileArchive(payload)

 conn := remote.ConnectionArgs{
 Host: pulumi.String(serverPublicIp),
 User: pulumi.String(userName),
 PrivateKey: pulumi.String(privateKey),
 }

 copy, err := remote.NewCopyToRemote(ctx, "copy", &remote.CopyToRemoteArgs{
 Connection: conn,
 Source: archive,
 })
 if err != nil {
 return err
 }

 find, err := remote.NewCommand(ctx, "find", &remote.CommandArgs{
 Connection: conn,
 Create: pulumi.String(fmt.Sprintf("find %v/%v | sort", destDir, payload)),
 Triggers: pulumi.Array{
 archive,
 },
 }, pulumi.DependsOn([]pulumi.Resource{
 copy,
 }))
 if err != nil {
 return err
 }

 ctx.Export("remoteContents", find.Stdout)
 return nil
 })
}

using System.Collections.Generic;
using Pulumi;
using Command = Pulumi.Command;

return await Deployment.RunAsync(() =>
{
 var config = new Config();
 var serverPublicIp = config.Require("serverPublicIp");
 var userName = config.Require("userName");
 var privateKey = config.Require("privateKey");
 var payload = config.Require("payload");
 var destDir = config.Require("destDir");

 var archive = new FileArchive(payload);

 // The configuration of our SSH connection to the instance.
 var conn = new Command.Remote.Inputs.ConnectionArgs
 {
 Host = serverPublicIp,
 User = userName,
 PrivateKey = privateKey,
 };

 // Copy the files to the remote.
 var copy = new Command.Remote.CopyToRemote("copy", new()
 {
 Connection = conn,
 Source = archive,
 });

 // Verify that the expected files were copied to the remote.
 // We want to run this after each copy, i.e., when something changed,
 // so we use the asset to be copied as a trigger.
 var find = new Command.Remote.Command("find", new()
 {
 Connection = conn,
 Create = $"find {destDir}/{payload} | sort",
 Triggers = new[]
 {
 archive,
 },
 }, new CustomResourceOptions
 {
 DependsOn =
 {
 copy,
 },
 });

 return new Dictionary<string, object?>
 {
 ["remoteContents"] = find.Stdout,
 };
});

package generated_program;

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.core.Output;
import com.pulumi.command.remote.Command;
import com.pulumi.command.remote.CommandArgs;
import com.pulumi.command.remote.CopyToRemote;
import com.pulumi.command.remote.inputs.*;
import com.pulumi.resources.CustomResourceOptions;
import com.pulumi.asset.FileArchive;
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) {
 final var config = ctx.config();
 final var serverPublicIp = config.require("serverPublicIp");
 final var userName = config.require("userName");
 final var privateKey = config.require("privateKey");
 final var payload = config.require("payload");
 final var destDir = config.require("destDir");

 final var archive = new FileArchive(payload);

 // The configuration of our SSH connection to the instance.
 final var conn = ConnectionArgs.builder()
 .host(serverPublicIp)
 .user(userName)
 .privateKey(privateKey)
 .build();

 // Copy the files to the remote.
 var copy = new CopyToRemote("copy", CopyToRemoteArgs.builder()
 .connection(conn)
 .source(archive)
 .destination(destDir)
 .build());

 // Verify that the expected files were copied to the remote.
 // We want to run this after each copy, i.e., when something changed,
 // so we use the asset to be copied as a trigger.
 var find = new Command("find", CommandArgs.builder()
 .connection(conn)
 .create(String.format("find %s/%s | sort", destDir,payload))
 .triggers(archive)
 .build(), CustomResourceOptions.builder()
 .dependsOn(copy)
 .build());

 ctx.export("remoteContents", find.stdout());
 }
}


resources:
 # Copy the files to the remote.
 copy:
 type: command:remote:CopyToRemote
 properties:
 connection: ${conn}
 source: ${archive}
 remotePath: ${destDir}

 # Verify that the expected files were copied to the remote.
 # We want to run this after each copy, i.e., when something changed,
 # so we use the asset to be copied as a trigger.
 find:
 type: command:remote:Command
 properties:
 connection: ${conn}
 create: find ${destDir}/${payload} | sort
 triggers:
 - ${archive}
 options:
 dependsOn:
 - ${copy}

config:
 serverPublicIp:
 type: string
 userName:
 type: string
 privateKey:
 type: string
 payload:
 type: string
 destDir:
 type: string

variables:
 # The source directory or archive to copy.
 archive:
 fn::fileArchive: ${payload}
 # The configuration of our SSH connection to the instance.
 conn:
 host: ${serverPublicIp}
 user: ${userName}
 privateKey: ${privateKey}

outputs:
 remoteContents: ${find.stdout}

Getting started

If you’re currently using one of the v0 pre-release versions of the Command provider, you don’t need to make any changes to your existing code. However, the enhanced functionality of copying assets and archives is only available in the new CopyToRemote resource. If you’re using CopyFile, you should consider migrating to the new resource after the upgrade to 1.0.

Enjoy the new features, and we’re looking forward to seeing what you build with the Command provider!

Pinecone Provider Now Available for Pulumi

Engin Diri — Tue, 16 Jan 2024 00:00:00 +0000

Hello, Pulumi Pinecone Provider! 👋

The Pinecone integration with Pulumi offers a native way to manage Pinecone indexes, including the newly-announced serverless indexes. Utilize any of Pulumi’s supported languages to effortlessly create, update, and remove your Pinecone indexes. This integration facilitates the application of Infrastructure as Code principles, helping you to work even more efficiently. Furthermore, this gives you the benefit of tapping into Pulumi’s wide range of providers, offering you a diverse and powerful set of tools to enhance your development work.

What is Pinecone? 🧐

Pinecone is a fully managed vector database with an easy-to-use API that allows you to build and deploy high-performance AI applications. Applications involving large language models, generative AI, and semantic search require a vector database to store and retrieve vector embeddings. Vector embeddings enable AI applications to gain a deeper understanding of the data and maintain a long-term memory to draw upon.

The backbone of Pinecone is the vector index. A vector index allows you to store and retrieve vector embeddings. What makes Pinecone indexes so powerful is their low latency for billions of vectors.

Pinecone is now extending its lead as the technology and market leader by completely re-inventing the vector database. This groundbreaking serverless vector database lets companies add unlimited knowledge to their GenAI apps at 10-100x lower cost to enable developers to deliver remarkably better, commercially viable, differentiated AI applications.

A key advantage of this true-serverless experience is its cost-effectiveness, achieved through a “pay for what you use” pricing strategy.

Getting Started 🤖

Using the Pinecone Provider for Pulumi is as easy as it can be. You can install the Pinecone Provider following the documentation for the Pinecone Provider in the Pulumi Registry or by using dedicated starter templates.

The starter templates are specially designed for you to bootstrap a Pulumi program with a Pinecone index. Once you have your bootstrap program, you can use this as a starting point to create your own Pinecone Serverless indexes.

Deploying a Pinecone Serverless Index

pulumi new pinecone-<language>

Will create a new Pulumi project with a Pinecone serverless index. Let’s take a look at the Typescript example:

pulumi new pinecone-typescript

This will create a new Pulumi project and all the necessary files to deploy a Pinecone index. The index.ts file contains the following code:

import * as pulumi from "@pulumi/pulumi";
import * as pinecone from "@pinecone-database/pulumi";

const myPineconeIndex = new pinecone.PineconeIndex("my-pinecone-index", {
 name: "my-pinecone-index",
 metric: pinecone.IndexMetric.Cosine,
 spec: {
 serverless: {
 cloud: pinecone.ServerlessSpecCloud.Aws,
 region: "us-west-2",
 },
 },
});
export const output = {
 value: myPineconeIndex.host,
};

In this code, we define a new Pinecone Serverless index with the name my-pinecone-index and we use cosine as the distance metric and define the index to be serverless and to be deployed in the us-west-2 region of AWS.

To deploy this example, you need to set your Pinecone API key as an environment variable:

export PINECONE_API_KEY="xxxxx-xxxx-xxxx-xxxx-xxxxx"

Then you can run the following Pulumi command to deploy the example:

pulumi up

You will get a preview of the changes that will be applied to your Pinecone account. If you are happy with the changes, you can confirm them by typing yes. This will create the Pinecone index and output the host name of the index to use in your application.

pulumi up
Previewing update (dev)

 Type Name Plan
 + pulumi:pulumi:Stack pinecone-ts-dev create
 + └─ pinecone:index:PineconeIndex my-pinecone-index create

Outputs:
 output: {
 value: output<string>
 }

Resources:
 + 2 to create

Do you want to perform this update? yes
Updating (dev)

 Type Name Status
 + pulumi:pulumi:Stack pinecone-ts-dev created (6s)
 + └─ pinecone:index:PineconeIndex my-pinecone-index created (3s)

Outputs:
 output: {
 value: "my-pinecone-index-t2khngi.svc.apw5-4e34-81fa.pinecone.io"
 }

Resources:
 + 2 created

Duration: 8s

Have a look into your Pinecone console, and you should see the newly created serverless index there, ready to use.

Deleting a Pinecone Index

Deleting a Pinecone index is as simple as creating one. You can delete a Pinecone Serverless index by simply running following command:

pulumi destroy

This will delete the Pinecone index for you.

Be aware that this will also delete all the data stored in the index.

Programmatically Creating a Pulumi Pinecone Provider

By default, Pulumi will use the default provider configuration for the Pinecone provider. However, there may be situations where you need to use a different configuration. In that case, programmatically creating an explicit Pinecone provider with its own configuration is how to meet that requirement. You might also need to create one or more explicit Pinecone providers if you needed to deploy indexes in multiple Pinecone accounts, for example.

Here is an example on how to programmatically create a Pinecone provider and then pass the provider when creating an index.

const myPineconeProvider = new pinecone.Provider("my-pinecone-provider", {
 APIKey: "my-pinecone-api-key",
});

const myPineconeIndex = new pinecone.PineconeIndex("my-pinecone-index", {
 name: "my-pinecone-index",
 metric: pinecone.IndexMetric.Cosine,
 spec: {
 serverless: {
 cloud: pinecone.ServerlessSpecCloud.Aws,
 region: "us-west-2",
 },
 },
}, {
 provider: myPineconeProvider,
});

Conclusion 💡

As shown in this blog post, the Pinecone Provider for Pulumi allows you to seamlessly integrate and manage your Pinecone indexes—including the new serverless indexes—using any Pulumi-supported language. This enables platform engineers and developers to maintain easily manageable and reproducible infrastructure as code for their AI applications that use Pinecone indexes.

As always, we welcome your feedback and contributions in the Pulumi Community Slack, GitHub repository, and Pulumi Community Discussions.

New to Pulumi? Signing up is easy and free. Get started today!

Happy AI building!

Announcing 6.0 of the Pulumi AWS Provider

Mikhail Shilkov — Tue, 29 Aug 2023 09:00:00 -0400

We are excited to announce 6.0 of the Pulumi AWS provider. The AWS provider is the most heavily used provider across the entire Pulumi ecosystem, and offers access to the full surface area of the upstream Terraform AWS Provider in Pulumi projects in all supported languages. The 6.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.

This blog post walks you through the list of notable changes in the new major version.

Join Pulumi on Thursday, September 7, 2023 for a live workshop on getting started with infrastructure as code on AWS, which will feature the new AWS 6.0 provider.

Terraform Plugin Framework Support

More and more Terraform resources are migrating to the Terraform Plugin Framework. We are excited to announce that 6.0 supports all resources implemented with both the new Terraform Plugin SDK and the legacy Terraform Plugin Framework technologies. This means that you get access to the entire API of the upstream provider.

New Resources and Functions

Since the previous major release of 5.0, we have shipped 57 additional minor and patch releases, enabling you to keep up with the latest and greatest enhancements. The new major version of the AWS provider brings 56 new resources and 23 new functions. Additions include resources for Audit Manager, Chime, Fin Space, Global Accelerator, Open Search, Quicksight, Resource Explorer, Route53, Transfer, and many other AWS services.

You can see a full list of new resources and functions in Release Notes.

SDK Size Optimization

The AWS provider contains more than 1,200 resources with over 12,000 properties between them. As a result, it’s expected that the SDK size of the provider has grown to be fairly large. With that in mind, we invested in some key areas to reduce the size of generated files. Depending on the runtime, the SDK is now up to 90% smaller than it used to be in v5 of the provider!

One particular optimization is related to wafv2 resources, that were particularly difficult to use in Pulumi AWS v5 (issue one, two, three). The new release includes a refactored wafv2 module which uses recursive types. Using recursive types allowed us to remove a lot of excess generated code.

Smaller SDK sizes mean faster downloads, snappier experience with editors and code completion tools, less time needed for pulumi preview and pulumi up operations, and smaller binaries, all of which contribute to a streamlined developer experience for Pulumi users.

Upstream Breaking Changes

Pulumi AWS 6.0 ships all improvements and bug fixes of upstream versions from 5.0.0 to 5.11.0. It also contains a number of upstream breaking changes. Please refer to the changelog to navigate the entire list.

Fixes for Highly Upvoted Issues

The new release ships fixes for many highly upvoted issues along with Pulumi-specific enhancements. This includes resolving constant diff from wafv2 with no changes and unexpected behavior of defaultTags that have been fixed and are available in the new release.

MaxItemsOne and Deprecations

The 6.0 release removes several deprecated resources. All of those resources were replaced with newer versions containing a more logical organization of modules and resource names. The removed resources have been deprecated for years, so it’s unlikely that you were still using them. But in case you do, we applied automatic aliases to make migration as straightforward as possible.

We also shipped a few, small breaking changes to properties that may allow one or many items. We aligned those with the capabilities of the upstream provider and the AWS services ensure Pulumi users can access the full capabilities of the AWS platform.

Migration Guide

You can see a full list of changes and learn more about migrating your existing programs in our Migration Guide.

Get Started Today

You can browse our API reference docs with inline examples or explore the Pulumi AWS Provider repository to get started today! And don’t forget to register for the live workshop on September 7, 2023 to see AWS 6.0 in action!

Pulumi Kubernetes 4.0: Even More Kubernetes-Native

Levi Blackstone — Wed, 19 Jul 2023 16:00:00 -0400

Since the very earliest days of the Pulumi project, Kubernetes has been a core part of the Pulumi platform. The initial Pulumi Kubernetes provider supported the entire API surface area of the Kubernetes platform, derived directly and automatically from the Kubernetes OpenAPI specifications, and available to all of Pulumi’s familiar programming languages. Since then, we have offered day one support for every new Kubernetes version, added support for Helm, YAML, Kustomize and CRDs, added tools for converting to Pulumi (kube2pulumi and crd2pulumi) and delivered the Pulumi Kubernetes Operator. During that same time, Kubernetes usage has continued to expand within the ecosystem and among Pulumi users, with the Kubernetes provider growing from the fourth most used to the second most used provider on the platform.

We are excited to release the next major version of our Kubernetes provider - Pulumi Kubernetes 4.0.

Join us for a free, on-demand webinar with Pulumi and the CNCF to learn how to use Pulumi’s Kubernetes Provider and other open-source tools to build internal developer platforms. Register →

Pulumi Kubernetes 4.0 uses Kubernetes Server-Side Apply by default, supports upserting on all resources, and enables new Patch resources for every resource type in the provider. It also brings improved diffs, removes dependence on kubectl annotations, and provides simpler access to outputs in the Python, Go and Java SDKs, supporting any self-hosted or managed Kubernetes cluster with version 1.13 or newer.

Together, these additions make Pulumi’s support for Kubernetes even more Kubernetes-native, allowing the best of both worlds between Kubernetes’ flexible resource model and Pulumi’s robust desired state infrastructure as code model, all while using your favorite languages (TypeScript, Python, Go, .NET and Java) to define and manage your Kubernetes Infrastructure. Pulumi programs that need to manage Kubernetes resources that are also modified by other systems (external controllers, managed Kubernetes service control planes, kubectl or other IaC solutions) can faithfully represent the modifications they want to make to existing resources within the Pulumi resource lifecycle. Pulumi accurately detects any differences between the current state of resources in the cluster, and the desired state specified by Pulumi IaC.

Server-Side Apply, Upserts and Patch Resources

Kubernetes Server-side Apply (SSA) mode is now default in the v4 provider. SSA mode enables several useful new features: Kubernetes resources can be safely managed by more than one controller. Any conflicting fields will produce a detailed error message which avoids accidentally overriding changes made by other controllers. Resources can be “upserted”; in other words, create the resource if it does not exist, or apply the specified configuration to an existing resource. Patch resources add a new way to manage shared Kubernetes resources. Patch resources can be used to make targeted changes, and do not require the entire resource to be specified. This is a convenient way to update shared resources; a common example is resources that are provisioned by the cloud provider rather than as part of the Pulumi stack. Deleting a Patch resource undoes the patched change, but does not remove the shared Kubernetes resource. See the SSA how-to guide for more details and usage examples for SSA mode.

Note: Users may opt into the previous default Client-side Apply (CSA) mode by setting the enableServerSideApply provider configuration to “false”.

In this example, we define a ConfigMap as an upsert which will create the resource if it doesn’t exist.

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

const example = new kubernetes.core.v1.ConfigMap("example", {
 metadata: {
 annotations: {
 "pulumi.com/patchForce": "true",
 },
 name: "example",
 },
 data: {
 foo: "bar",
 },
});

import pulumi
import pulumi_kubernetes as kubernetes

example = kubernetes.core.v1.ConfigMap(
 "example",
 metadata=kubernetes.meta.v1.ObjectMetaArgs(
 annotations={
 "pulumi.com/patchForce": "true",
 },
 name="example",
 ),
 data={
 "foo": "bar",
 })

package main

import (
 corev1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/core/v1"
 metav1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/meta/v1"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 _, err = corev1.NewConfigMap(ctx, "example", &corev1.ConfigMapArgs{
 Metadata: &metav1.ObjectMetaArgs{
 Annotations: pulumi.StringMap{
 "pulumi.com/patchForce": pulumi.String("true"),
 },
 Name: pulumi.String("example"),
 },
 Data: pulumi.StringMap{
 "foo": pulumi.String("bar"),
 },
 })
 if err != nil {
 return err
 }
 return nil
 })
}

using System.Collections.Generic;
using Pulumi;
using Kubernetes = Pulumi.Kubernetes;

return await Deployment.RunAsync(() =>
{
 var example = new Kubernetes.Core.V1.ConfigMap("example", new()
 {
 Metadata = new Kubernetes.Types.Inputs.Meta.V1.ObjectMetaArgs
 {
 Annotations =
 {
 { "pulumi.com/patchForce", "true" },
 },
 Name = "example",
 },
 Data =
 {
 { "foo", "bar" },
 },
 });
});

package generated_program;

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.core.Output;
import com.pulumi.kubernetes;
import com.pulumi.kubernetes.core_v1.ConfigMap;
import com.pulumi.kubernetes.core_v1.ConfigMapArgs;
import com.pulumi.kubernetes.meta_v1.inputs.ObjectMetaArgs;
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 example = new ConfigMap("example", ConfigMapArgs.builder()
 .metadata(ObjectMetaArgs.builder()
 .annotations(Map.of("pulumi.com/patchForce", "true"))
 .name("example")
 .build())
 .data(Map.of("foo", "bar"))
 .build());

 }
}

resources:
 example:
 type: kubernetes:core/v1:ConfigMap
 properties:
 metadata:
 annotations:
 pulumi.com/patchForce: "true"
 name: example
 data:
 foo: bar

Improved diff experience

The process for calculating what changes a provider needs to make to achieve the desired state is called “diffing”. This is a complex process that accounts for the current and previous state of the Pulumi program (the “inputs”), the stack’s state/checkpoint, and the actual current state of any resources managed by the provider. A major challenge of this process is detecting “drift”, where resources have been changed by something other than the Pulumi stack so that these changes are not reflected in Pulumi’s view of the world. The Server-side Apply (SSA) support available in v3.x versions does detect resource drift, but the implementation was slow for larger stacks. The v4 provider now detects resource drift in both Client-side Apply and Server-side Apply by running a refresh operation. This brings the behavior in line with other providers, and offers consistent performance that scales well to larger stacks.

As part of this work, we removed the use of the kubectl.kubernetes.io/last-applied-configuration annotation, which was previously used by the provider to track input values for Kubernetes resources. This change addresses many longstanding issues caused by the use of this annotation, including challenges working with resources that were modified by tools other than kubectl.

Migrating to Kubernetes 4.0

You can migrate your existing Pulumi Kubernetes projects to 4.0 today, or start a new project targeting 4.0 with any of the Pulumi templates.

For users migrating to 4.0, check out the v4 Provider Migration Guide with full details of the additional changes in this release.

Getting Started

Try Infrastructure as Code for Kubernetes by following this quick getting started guide.

Join us for a free, on-demand webinar with Pulumi and the CNCF to learn how to use Pulumi’s Kubernetes Provider and other open-source tools to build internal developer platforms.Register →

Azure Native Provider 2.0: Streamlined, Expanded, and More Powerful than Ever

Monica Rodriguez — Wed, 14 Jun 2023 14:00:00 -0400

Update: this content was updated on July 11 2023 to reflect the general availability of the 2.0 release.

We are thrilled to announce the release of the Pulumi Azure Native Provider 2.0, a significant upgrade to Pulumi’s native provider for Microsoft Azure. The Azure Native provider offers the most complete support for Azure possible - with same day access to the entire surface area of the Azure features from Azure Resource Manager. Every property of each module is always represented in the SDKs. The 2.0 release brings a host of exciting features and improvements for performance and usability that will enhance your experience with managing Azure resources and empower you to build robust and scalable cloud infrastructure more efficiently.

At Pulumi, we understand the importance of keeping up with the ever-evolving cloud landscape. The Pulumi Azure Native Provider 2.0 represents our commitment to providing you with the best tools to harness the full power of Microsoft Azure. With automatic generation from Azure API specs, we are able to provide you with same-day access to the entire Azure API surface including all available properties. Let’s dive into some of the key enhancements in this release!

Join Pulumi, Azure, and GitHub on Tuesday, September 19, 2023 for a live workshop on getting started with infrastructure as code on azure. You’ll learn how to use the Azure Native Provider and set up an automated deployment workflow through GitHub.

Reduced SDK Size for Faster Development

We’ve listened to your feedback and have made significant optimizations to the Azure Native Provider SDKs. With careful fine-tuning and restructuring, we have achieved a significant decrease in size of over 50% for SDKs with multi-versioned modules. This improvement translates into faster development times, reduced resource consumption, and an overall smoother experience when working with the provider.

So, how did we accomplish this? For starters, we’ve removed all deprecated Azure API modules up to the 2.0 release date. The bigger impact was made by identifying and removing all forward-compatible module versions. That is to say we’ve excluded any redundant versions and kept only the versions that introduce breaking changes. Where these versions are not the current latest and new default, they remain available as explicit versions.

You may be wondering about the significance between explicit and default versions. Well, when Azure releases new features they often create a new version of a service API. These versions are named using dates such as “2021-01-02” or “2022-05-08-preview”. There’s many versions of each module in the SDK, so we pick a version of each module for the top-level default. To learn more about module versions, visit the Azure Native Version Guide.

Refreshed Default Module Versions

In the latest release, we have refreshed the default module versions to align with the latest Azure API versions from Microsoft. With our continued commitment to same-day access to Azure API surface, you always have access to the most up-to-date features and capabilities offered by Azure services. By leveraging the latest module versions, you can take advantage of the latest and most desired features directly from Azure while building your infrastructure with Pulumi.

If you would like to upgrade to 2.x, but continue using the same Azure API version that was used in your 1.x, you can do that by specifying the compatible explicit version available in the 2.x provider. Shown below are examples of how that change might look.

- import { EventSubscription } from "@pulumi/azure-native/eventgrid";
+ import { EventSubscription } from "@pulumi/azure-native/eventgrid/v20200601";

- from pulumi_azure_native import eventgrid
+ from pulumi_azure_native.eventgrid import v20200601 as eventgrid20200601

- using EventGrid = Pulumi.AzureNative.EventGrid;
+ using EventGrid20200601 = Pulumi.AzureNative.EventGrid.V20200601;

- import eventgrid "github.com/pulumi/pulumi-azure-native-sdk/eventgrid/v2"
+ import eventgrid20200601 "github.com/pulumi/pulumi-azure-native-sdk/eventgrid/v2/v20200601”

- type: azure-native:eventgrid:Topic
+ type: azure-native:eventgrid/v20200601:Topic

Expanded Top-Level Default Module Coverage

We’re excited to expand our top-level default version coverage by 226 resources, 274 functions, and 5526 input properties in this release, bringing the total to 1,637, 2,015, and 30,652 respectively. With this extensive collection of modules at your disposal, you can easily provision and manage the full range of Azure services using Pulumi. Whether you’re working with virtual machines, databases, networking, or any other Azure service, the Azure Native Provider has you covered.

Resolved Title Case Inconsistency

For a consistent and predictable experience across the provider, we have resolved an issue with title case inconsistencies across resources and functions. All previous resource names have been aliased, and do not require any changes to the Pulumi program. However, functions that have a corrected name will need to be updated. This enhancement ensures a unified and predictable experience while working across resource types, making it easier for you to navigate and understand the provider’s capabilities.

Simplified User Assigned Identity Inputs

We have simplified the representation of user assigned identity inputs by recognizing them as string arrays. This change provides a more intuitive and clear approach when configuring user assigned identities for your Azure modules. You can now reference these as UserAssignedIdentities: [exampleUserAssignedIdentity.id] without jumping through any hoops.

import * as resources from "@pulumi/azure-native/resources";
import * as managedidentity from "@pulumi/azure-native/managedidentity";
import * as storage from "@pulumi/azure-native/storage";

// Create a resource group
const resourceGroup = new resources.ResourceGroup("my-resource-group");

// Create a user-assigned managed identity
const userAssignedIdentity = new managedidentity.UserAssignedIdentity("my-user-assigned-identity", {
 resourceGroupName: resourceGroup.name,
});

// Create a storage account that references the user-assigned managed identity
const storageAccount = new storage.StorageAccount("mystorageaccount", {
 resourceGroupName: resourceGroup.name,
 kind: "StorageV2",
 location: resourceGroup.location,
 identity: {
 type: "UserAssigned",
 userAssignedIdentities: [userAssignedIdentity.id],
 },
 sku: {
 name: "Standard_LRS",
 },
});

Before this change, the identity block would need to use an apply as follows:

user_assigned_identity.id.apply(lambda id: {id: {}})

Migrating from 1.x to 2.x

We recommend you update to the latest version of Azure Native 1.x prior to moving to 2.x. This will enable you to address existing deprecations and see the recommended substitutions ahead of the major version upgrade. Head over to the migration guide which outlines the necessary steps to update your existing Pulumi projects and ensuring a smooth migration experience.

Current users of the Pulumi Azure Classic Provider can follow the classic to native migration guide to take advantage of all the latest and greatest features available in Pulumi the Azure Native Provider.

While you can immediately start leveraging the improved performance, you may need to make some changes in order to continue using specific Azure API module versions or user assigned identity inputs. Use the Pulumi Azure Native Provider documentation within your IDE to determine the explicit API version that is available and fully compatible with your existing deployment.

The Pulumi Azure Native Provider 2.0 is available today for Pulumi programs using TypeScript, Python, .NET, and Go. To learn more about the Pulumi Azure Native Provider 2.0 and explore its capabilities, check out our updated documentation and resources. We value your feedback and encourage you to reach out in community slack or open an issue for any questions or suggestions.

Try out the Pulumi Azure Native Provider 2.0 today and take the next step in your journey with infrastructure as code on Microsoft Azure!

Getting Started

Try Infrastructure as Code on Azure by following this quick getting started guide.

Fast Docker Image Builds with Pulumi

Monica Rodriguez — Wed, 08 Mar 2023 14:00:00 -0800

How do I speed up Docker image builds with Pulumi? Use BuildKit (the default since Docker 23), enable a registry or layer cache so repeated builds reuse work, write a multi-stage Dockerfile so production images skip build-time dependencies, and reach for the dedicated Docker Build provider when you need buildx features like multi-platform images, build secrets, or Docker Build Cloud. With these techniques together, repeat builds in a Pulumi program commonly drop from minutes to seconds.

TL;DR

BuildKit is the default in current Docker releases and in the Pulumi Docker providers — you generally do not need to opt in.
Cache your layers somewhere persistent. A registry cache (cacheFrom / cacheTo) is what makes CI builds fast across runners and contributors.
Multi-stage Dockerfiles are the single biggest win for image size and rebuild speed when you have a compile or bundle step.
Use pulumi/docker-build for new projects. It exposes the full buildx surface (multi-platform, secrets, multiple cache backends, Docker Build Cloud).
Use pulumi/docker v4+ if you already depend on it — its docker.Image resource also rebuilds only on context change and supports BuildKit and registry caching.

What actually moves the needle

The numbers below are representative of what teams report from a typical Node.js or Python web app (single Dockerfile, ~300 MB final image). Your mileage varies with project size, network, and runner specs — treat this as a directional comparison, not a benchmark suite.

Configuration	Cold build	Repeat build (no source change)	Repeat build (small source change)
Legacy builder, no caching	minutes	minutes	minutes
BuildKit, local layer cache only	minutes	seconds (cache hit)	tens of seconds
BuildKit + multi-stage Dockerfile	minutes	seconds (cache hit)	tens of seconds
BuildKit + multi-stage + registry cache (`cacheFrom`/`cacheTo`)	minutes (first run)	seconds (cache hit)	seconds–tens of seconds, even on a fresh CI runner
`docker-build` provider with buildx + Docker Build Cloud	under 2 min	seconds (cache hit)	seconds

The headline pattern: each row past the first is dominated by what the build can skip, not by raw CPU. Pulumi’s job is to wire those caches up declaratively so they keep working across every pulumi up.

How does Pulumi build Docker images?

Pulumi has two providers for image builds, and which one you should use depends on how new your project is.

The Docker provider (pulumi/docker) is the original. Its docker.Image resource can build a local context and push to any registry as part of a Pulumi deployment, alongside resources for containers, networks, and volumes. Since v4 it rebuilds only when the build context changes and uses BuildKit by default.
The Docker Build provider (pulumi/docker-build) is a newer, dedicated provider focused exclusively on image builds. It exposes Docker’s buildx interface, so you get multi-platform builds, multiple cache backends, build secrets, and Docker Build Cloud as first-class features.

For new projects, prefer docker-build. For existing programs that already use docker.Image, you do not have to migrate — docker.Image continues to receive the speed and caching improvements covered below.

Why are my Docker builds slow?

Three things make Docker builds slow in practice, and Pulumi addresses each one declaratively.

No cache, or the wrong cache. A fresh CI runner has no local Docker layers. Without a remote cache, every build reinstalls every dependency.
Cache busting on noise. If your Dockerfile copies package.json and the rest of your source in the same step, every source change invalidates the dependency-install layer. Order layers from least-changing to most-changing.
Building dev tooling into the production image. Compilers, linters, and test frameworks have no business in a runtime image. Multi-stage builds let you discard them.

How do I enable BuildKit and registry caching in Pulumi?

BuildKit has been the default builder since Docker 23 and is the default in both Pulumi providers. The piece you usually have to configure is where the cache lives — local disk on a developer laptop is fine, but for CI you almost always want a registry cache so layers persist across runners.

With the Docker Build provider (recommended)

import * as docker_build from "@pulumi/docker-build";

const image = new docker_build.Image("my-image", {
 tags: ["docker.io/pulumibot/demo-image:latest"],
 context: { location: "./app" },
 dockerfile: { location: "./app/Dockerfile" },
 platforms: [
 "linux/amd64",
 "linux/arm64",
 ],
 cacheFrom: [{ registry: { ref: "docker.io/pulumibot/demo-image:cache" } }],
 cacheTo: [{ registry: { ref: "docker.io/pulumibot/demo-image:cache", mode: "max" } }],
 push: true,
});

cacheFrom and cacheTo together are the important pair: the first run populates the cache, every later run on any machine pulls it. mode: "max" exports cache for every layer, not just the final ones.

With the Docker provider (`docker.Image`)

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

const image = new docker.Image("my-image", {
 imageName: "docker.io/pulumibot/demo-image:latest",
 build: {
 context: "app",
 dockerfile: "Dockerfile",
 platform: "linux/amd64",
 cacheFrom: {
 images: ["docker.io/pulumibot/demo-image:cache-base"],
 },
 },
});

The docker.Image resource accepts a list of cache images via cacheFrom.images. Tag a previous build with a stable cache tag (for example, :cache-base) and reference it here so subsequent builds reuse its layers.

How do I write a Dockerfile that builds fast?

The Dockerfile matters at least as much as the Pulumi code wrapping it. Two patterns do most of the work.

Order layers least-volatile first. Copy lockfiles and run dependency installs before copying source code. That way changing a .ts file does not bust the npm ci layer.

# Dependencies — only invalidates when lockfiles change
COPY package.json package-lock.json ./
RUN npm ci

# Source — changes constantly, but the dependency layer above survives
COPY . .
RUN npm run build

Use multi-stage builds to drop tooling. Compile in a fat image, copy the artifact into a slim one. The runtime image stays small and the build stage gets cached independently.

FROM node:20 AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-slim AS runtime
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
CMD ["node", "dist/server.js"]

When you combine multi-stage with a registry cache (cacheTo mode max), CI runs on fresh machines reuse both stages — the row in the table above where small source changes finish in 10–30 seconds.

How do I build multi-platform images with Pulumi?

Use the docker-build provider and pass a list to platforms. BuildKit will build all variants in parallel and push a manifest list, so a single tag serves whatever architecture the puller needs.

const image = new docker_build.Image("api", {
 tags: ["ghcr.io/example/api:latest"],
 context: { location: "./api" },
 platforms: [
 "linux/amd64",
 "linux/arm64",
 ],
 push: true,
});

If you are still on docker.Image, the build.platform field accepts a single target (for example, "linux/amd64"); for true multi-arch manifests, prefer docker-build.

How do I see Docker build output in Pulumi?

Filtered Docker build and push logs render directly in pulumi up output for both providers, so you can debug a failing layer without leaving your Pulumi run. With the Docker Build provider, structured progress shows per-stage timing — useful when you are trying to figure out which layer is the slow one.

How do I migrate an older `docker.Image` program?

If you are upgrading from a pre-v4 program, pulumi-docker v4 reshaped the docker.Image resource and renamed several supporting types, but does not manage backend state, so updating the package version and adjusting types is generally enough. The full migration guide lives in the v4.0.0 release notes.

If you are starting fresh or want the full BuildKit feature set, install pulumi-docker-build instead and follow the Docker Build provider getting started guide.

Getting started

Docker Build provider — recommended for new projects.
Docker provider — the original, including docker.Image, containers, and networks.
Introducing the Docker Build provider — deeper dive on buildx, secrets, and Docker Build Cloud.

The cheapest performance win in most Pulumi programs is wiring up a registry cache and a multi-stage Dockerfile. Start there, then reach for buildx features as the project grows.

Node.js Native Binary Compilation Using vercel/pkg

Daniel Bradley — Tue, 13 Sep 2022 00:00:00 +0000

In Pulumi’s engineering department, we often build and distribute tools as native binaries to avoid the need for additional dependencies on user machines. Most of these tools are written in Go, which has good support for building self-contained binaries that target modern operating systems.

While other Pulumi-supported languages like Node.js, Python, and .NET require additional runtime dependencies, it’s possible to bundle dependencies with the program. In this article, we’ll show you how to do that for a Node.js program.

This is a problem that can be solved using vercel/pkg command line tool. Here’s the summary from their readme.

This command line interface enables you to package your Node.js project into an executable that can be run even on devices without Node.js installed.

Let’s take a look at how to use pkg and some issues we encountered on the way.

Setting up `pkg`

1 - Install

pkg is distributed as an npm package which can be installed into your “devDependencies” using:

npm install -D pkg

yarn add -D pkg

or run without installing with npx:

npx pkg [args]

2 - Set `bin` in `package.json`

pkg will use the bin field from your package.json to find the entry point so you just have to specify a path to the directory containing your package.json.

{
 "name": "my-program"
 "bin": "bin/index.js",
 ...
}

If no target is specified, then a set of defaults will be chosen for you. If the output path is not specified, pkg will infer the name from the package.json “name” field and write to the current working directory.

3 - Execute

The main inputs that pkg needs is:

The entry point to your program for packaging
The target machine to build for
The output path to write the finished binary

Here’s an example of building the project in the current directory using node v18 for macOS ARM architectures:

# pkg [options] <input>
# -t, --targets comma-separated list of targets
# -o, --output output file name or template for several files
pkg -t node18-macos-arm64 -o bin/my-program .

It’s possible to specify multiple targets in a comma-separated list to build them all at the same time, but it does come with the limitation where the output file names follow a fixed pattern. Instead, we chose to just run the pkg command multiple times with different arguments from our makefile in parallel as this fits with our existing workflows well.

Issues encountered

“Inspector Not Available”

As soon as we started executing the provider we started seeing some interesting warnings printed to the console stating “Inspector is not available” (here’s our tracking issue and some pkg discussion). This is because we use the Node.js Inspector API as part of our automatic closure serialization, however this is not available by default when packaging with pkg.

pkg provides an option to fix this by building your own base image with custom Node.js flags set to enable debugging. However, on investigation, these issues were caused by the Pulumi Typescript SDK creating and caching an inspector instance at the point of being imported even though we never actually call this code in our plugin. Therefore, we opted to make this eager singleton creation to be lazy – only created on first use, as we’re not using in our providers at this time.

Unrunnable MacOS ARM binaries

When trying to use the binaries produced by our CI, we found that the binaries weren’t runnable on MacOS ARM architectures - and were forcibly killed by the operating system.

This led me down quite a bit of a rabbit hole investigating signing of binaries, but it was actually resolved by simply installing the ‘ldid’ tool on our linux CI environments. The ldid source is available via git.saurik.com/ldid and binaries are available from various sources. Our solution was to use the “Install Ldid” GitHub Action to install the ldid binary and add it to the PATH in our CI workflow. My learning here is that sometimes reading the warnings in logs more carefully can save you lots of time!

Static Binaries

One adjustment to our configuration came from a community contribution by @afreakk where the provider was being used in a nixos environment. Nixos adds the requirement for all binaries to be static rather than dynamic - so there’s no requirement for the operating system to dynamically map link functions from system libraries at runtime. Statically compiled programs sometimes result in a larger size, but avoid any possible issues with different versions of the libraries it depends on.

To resolve this issue, it’s as simple as changing the ‘linux’ targets to ‘linuxstatic’. E.g. node18-linux-amd64 becomes node18-linuxstatic-amd64.

Build infrastructure with Node.js

Pulumi lets you define, deploy, and manage cloud infrastructure using TypeScript and JavaScript, with the same npm packages and tooling you already rely on. Start building your first stack in Pulumi Cloud.

Get started

Multi-platform builds with a makefile

We use makefiles to build our providers, so here’s a brief outline of how we build for multiple platforms using GNU Make.

# Set the correct pkg TARGET for each binary we build
# when building for linux-amd64, set the pkg target to node18-linuxstatic-x64
bin/linux-amd64/my-program: TARGET := node18-linuxstatic-x64
# output binary file ^ ^ variable ^ pkg target
bin/linux-arm64/my-program: TARGET := node18-linuxstatic-arm64
bin/darwin-amd64/my-program: TARGET := node18-macos-x64
bin/darwin-arm64/my-program: TARGET := node18-macos-arm64
bin/windows-amd64/my-program.exe: TARGET := node18-win-x64

# Wildcard rule to build any of binary outputs
# "To build any bin file, ensure node_modules are up to date..."
bin/%: node_modules
 # "... then run pkg for actual output name & target"
 yarn run pkg . --target ${TARGET} --output $@
 # "TARGET" is the variable defined above, depending on the output
 # "$@" is the current makefile target - e.g. 'bin/linux-amd64/my-program'

# Running `make bins` will build all the listed outputs
bins: bin/linux-amd64/my-program
bins: bin/linux-arm64/my-program
bins: bin/darwin-amd64/my-program
bins: bin/darwin-arm64/my-program
bins: bin/windows-amd64/my-program.exe

# Let Make know that `bins` doesn't really exist (is phony) - it's just a helpful shortcut
.PHONY: bins

In summary the above code does the following:

Define each output file we need
- Set the correct pkg TARGET for each output
Define a rule for building any binary output:
- Ensure module_modules are up-to-date (this is another make target not shown here).
- Run pkg with the $TARGET set in (1) and the name of the current output ($@).
Define bins “phony target” which builds all listed bins.

You might also like:

Recap

I hope this gives you a good overview of the vercel/pkg tool and how you can use it to create standalone programs using Node.js.

Historical Note

We used to do a similar process using the nexe project, but there’s been no releases since 2017 and therefore no support for newer versions of Node.js and we therefore consider this package as unmaintained at this point in time.

Pulumi Blog: Providers

Pulumi AWS Provider 7.0: Multi-Region Support, IAM Role Chaining, and S3 Resource Simplification

What’s New in Pulumi AWS Provider 7.0

Multi-Region AWS Deployments with a Single Provider

IAM Role Chaining for Secure AWS IaC Workflows

Simplified S3 Bucket Resource Model

Upstream Improvements and Breaking Changes

Migration Guide

Getting Started with Pulumi AWS 7.0

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

Full List of New Providers

Pulumi Command Provider 1.0 Release

What’s new

Getting started

Pinecone Provider Now Available for Pulumi

Hello, Pulumi Pinecone Provider! 👋

What is Pinecone? 🧐

Getting Started 🤖

Deploying a Pinecone Serverless Index

Deleting a Pinecone Index

Programmatically Creating a Pulumi Pinecone Provider

Conclusion 💡

Announcing 6.0 of the Pulumi AWS Provider

Terraform Plugin Framework Support

New Resources and Functions

SDK Size Optimization

Upstream Breaking Changes

Fixes for Highly Upvoted Issues

MaxItemsOne and Deprecations

Migration Guide

Get Started Today

Pulumi Kubernetes 4.0: Even More Kubernetes-Native

Server-Side Apply, Upserts and Patch Resources

Improved diff experience

Migrating to Kubernetes 4.0

Getting Started

Azure Native Provider 2.0: Streamlined, Expanded, and More Powerful than Ever

Reduced SDK Size for Faster Development

Refreshed Default Module Versions

Expanded Top-Level Default Module Coverage

Resolved Title Case Inconsistency

Simplified User Assigned Identity Inputs

Migrating from 1.x to 2.x

Getting Started

Fast Docker Image Builds with Pulumi

TL;DR

What actually moves the needle

How does Pulumi build Docker images?

Why are my Docker builds slow?

How do I enable BuildKit and registry caching in Pulumi?

With the Docker Build provider (recommended)

With the Docker provider (docker.Image)

How do I write a Dockerfile that builds fast?

How do I build multi-platform images with Pulumi?

How do I see Docker build output in Pulumi?

How do I migrate an older docker.Image program?

Getting started

Node.js Native Binary Compilation Using vercel/pkg

Setting up pkg

1 - Install

2 - Set bin in package.json

3 - Execute

Issues encountered

“Inspector Not Available”

Unrunnable MacOS ARM binaries

Static Binaries

Multi-platform builds with a makefile

Recap

Historical Note

With the Docker provider (`docker.Image`)

How do I migrate an older `docker.Image` program?

Setting up `pkg`

2 - Set `bin` in `package.json`