Pulumi Blog: Platform teams

The Pulumi Go Provider SDK is Now Generally Available

Eron Wright — Tue, 20 May 2025 00:00:00 +0000

At Pulumi, we are committed to accelerating your cloud infrastructure journey by eliminating barriers between your teams and the tools they need. Today, we’re thrilled to announce a game-changing milestone that puts unprecedented power in your hands: the v1.0.0 release of the Pulumi Go Provider SDK!

Unlock the Full Potential of Your Cloud Ecosystem

The Pulumi Go Provider SDK v1.0 is a transformative framework that enables you to integrate any service, tool, or API into your infrastructure as code workflows. After extensive development since 2022 and battle-testing with enterprise customers, this framework is now stable and production-ready for your most critical infrastructure needs.

Pulumi has worked diligently to bring this SDK to maturity, incorporating feedback from enterprise users and leveraging it internally to build production providers like the Docker Build Provider. With v1.0.0, building robust, multi-language Pulumi providers is more accessible than ever.

Key Enhancements for Your Team

The Pulumi Go Provider SDK delivers capabilities that benefit everyone from platform engineers to DevOps professionals:

Go 1.24 Support: Utilize the latest language features and performance improvements
Intuitive Provider Builder API: A fluent, developer-friendly API that eliminates boilerplate and accelerates provider development
Functional-Style Components: Create reusable infrastructure building blocks with a natural, functional programming style
Enterprise-Grade Testing Framework: Ensure reliability with comprehensive testing capabilities for both resources and components

For a complete technical overview, see our comprehensive Pulumi Go Provider SDK documentation.

Defining and Testing a Custom Resource

Creating a Custom Resource in Minutes, Not Days

Let’s see how the SDK transforms the provider development experience. Using the infer package, you define your resource types using straightforward Go structs:

func main() {
 p.RunProvider("greetings", "0.1.0", provider())
}

func provider() p.Provider {
 p, _ := infer.NewProviderBuilder().
 WithResources(
 infer.Resource(&HelloWorld{}),
 ).
 Build()
 return p
}

// Each resource has a controlling struct.
type HelloWorld struct{}

// Each resource has in input struct, defining what arguments it accepts.
type HelloWorldArgs struct {
 Name string `pulumi:"name"`
 Loud *bool `pulumi:"loud,optional"`
}

// Each resource has a state, describing the fields that exist on the created resource.
type HelloWorldState struct {
 HelloWorldArgs
 Message string `pulumi:"message"`
}

func (l *HelloWorldState) Annotate(a infer.Annotator) {
 a.Describe(&l, "A Hello World resource")
 a.Describe(&l.Name, "Who to say hello to.")
 a.SetDefault(&l.Name, "user-")
 a.Describe(&l.Loud, "Indicates whether to give a LOUD greeting.")
 a.Describe(&l.Message, "The greeting message.")
}

You then implement the necessary methods for the resource’s lifecycle with surprising simplicity:

// All resources must implement Create at a minimum.
func (HelloWorld) Create(
 ctx context.Context, name string, input HelloWorldArgs, preview bool,
) (string, HelloWorldState, error) {
 state := HelloWorldState{HelloWorldArgs: input}
 if preview {
 return name, state, nil
 }
 state.Message = fmt.Sprintf("Hello, %s", input.Name)
 if input.Loud != nil && *input.Loud {
 state.Message = strings.ToUpper(state.Message)
 }
 return name, state, nil
}

This minimal code creates a fully-functional resource that your teams can use in their infrastructure code! The SDK handles all the complex gRPC communication with the Pulumi engine and automatically generates the necessary schema for multi-language support.

For detailed step-by-step instructions on building your own provider, check out our Build a Provider guide.

Confidence Through Comprehensive Testing

One of the biggest challenges with custom infrastructure providers is ensuring they’re reliable. The SDK’s built-in testing framework solves this with targeted capabilities:

Lifecycle Testing: Verify your resources’ CRUD operations function correctly
Component Testing: Validate complex resource compositions with mock capabilities
Integration Testing: Ensure your provider works seamlessly with the Pulumi ecosystem

Here’s how easy it is to test your custom resource:

func TestHelloWorldLifecycle(t *testing.T) {
 server, err := integration.NewServer(t.Context(), "greetings", semver.Version{Minor: 1},
 integration.WithProvider(provider()),
 )
 require.NoError(t, err)

 // Test the lifecycle methods of the HelloWorld resource.
 integration.LifeCycleTest{
 Resource: "pkg:index:HelloWorld",
 Create: integration.Operation{
 Inputs: property.NewMap(map[string]property.Value{
 "name": property.New("tester"),
 "loud", property.New(true),
 }),
 Hook: func(inputs, output property.Map) {
 message := output.Get("message").AsString()
 assert.Equal(t, "Hello, tester", message)
 },
 },
 }.Run(t, server)
}

For more information, see Pulumi Go Provider SDK.

Standardize Infrastructure with Powerful Component Resources

Beyond simple resources, providers can also define Component Resources. Components are higher-level abstractions that encapsulate multiple child resources working together to implement a specific capability. They are perfect for codifying organizational standards and best practices into reusable (cross-language!) building blocks.

The Pulumi Go Provider SDK introduces support for defining components using a functional style, similar to how you might define a local component within a single program. This provides a streamlined way to build components. Here’s an example using the functional style:

func provider() p.Provider {
 p, _ := infer.NewProviderBuilder().
 WithComponents(
 infer.ComponentF(NewRandomLogin),
 ).
 Build()
 return p
}

type RandomLoginArgs struct {
 Prefix pulumi.StringInput `pulumi:"prefix"`
}

type RandomLogin struct {
 pulumi.ResourceState
 RandomLoginArgs

 Username pulumi.StringOutput `pulumi:"username"`
 Password pulumi.StringOutput `pulumi:"password"`
}

func NewRandomLogin(ctx *pulumi.Context, name string, args RandomLoginArgs, opts ...pulumi.ResourceOption) (*RandomLogin, error) {
 comp := &RandomLogin{}
 err := ctx.RegisterComponentResource(p.GetTypeToken(ctx), name, comp, opts...)
 if err != nil {
 return nil, err
 }

 username, err := random.NewRandomPet(ctx, name+"-username", &random.RandomPetArgs{
 Prefix: args.Prefix,
 }, pulumi.Parent(comp))
 if err != nil {
 return nil, err
 }
 comp.Username = username.ID().ToStringOutput()

 password, err := random.NewRandomPassword(ctx, name+"-password", &random.RandomPasswordArgs{
 Length: pulumi.Int(12),
 }, pulumi.Parent(comp))
 if err != nil {
 return nil, err
 }
 comp.Password = password.Result

 return comp, nil
}

func (l *RandomLogin) Annotate(a infer.Annotator) {
 a.Describe(&l, "Generate a random login credential (a username and password).")
 a.Describe(&l.Prefix, "An optional prefix for the generated username.")
 a.SetDefault(&l.Prefix, "user-")
}

For a deep dive into creating component resources, see our comprehensive Build a Component guide.

And testing components is equally straightforward:

func TestRandomLogin(t *testing.T) {
 provider, err := provider()
 require.NoError(t, err)
 server, err := integration.NewServer(t.Context(),
 "random-login",
 semver.Version{Minor: 1},
 integration.WithProvider(provider),
 integration.WithMocks(&integration.MockResourceMonitor{
 NewResourceF: func(args integration.MockResourceArgs) (string, property.Map, error) {
 switch {
 case args.TypeToken == "random:index/randomPet:RandomPet" && args.Name == "login-username":
 assert.Equal(t, "foo", args.Inputs.Get("prefix").AsString())
 return "user", property.Map{}, nil

 case args.TypeToken == "random:index/randomPassword:RandomPassword" && args.Name == "login-password":
 assert.Equal(t, 12.0, args.Inputs.Get("length").AsNumber())
 return args.Name, property.NewMap(map[string]property.Value{
 "result": property.New("12345").WithSecret(true),
 }), nil

 return "", property.Map{}, nil
 },
 }),
 )
 require.NoError(t, err)

 // test the "random-login:RandomLogin" component
 resp, err := server.Construct(p.ConstructRequest{
 Urn: "urn:pulumi:stack::project::random-login:index:RandomLogin::login",
 Inputs: property.NewMap(map[string]property.Value{
 "prefix": property.New("foo"),
 }),
 })
 require.NoError(t, err)

 require.Equal(t, property.NewMap(map[string]property.Value{
 "username": property.New("user"),
 "password": property.New("12345").WithSecret(true),
 }), resp.State)
}

For more information about component resources, see the blog post Announcing the Next-Generation of Pulumi Components: Enabling Infrastructure Abstractions.

A major advantage of using the Pulumi Go Provider SDK is that your provider, once written in Go, can be used in any Pulumi program, in any supported language (TypeScript, Python, Go, .NET, Java, or YAML). The SDK’s automatic schema generation takes care of creating the necessary language-specific SDKs, enabling cross-language consumption without manual effort.

Packaging and publishing your provider for others to use, whether within your organization or publicly, is a key step. Follow our Publishing Packages guide for detailed instructions on distributing your custom provider.

Understanding Provider Schema

The SDK automatically generates a schema for your provider based on the Go types and annotations you define. This schema describes the resources, their inputs and outputs, and documentation. For more details on how schema generation works and how to customize it, check out our Schema documentation.

Get Started Today!

The release of the Pulumi Go Provider SDK represents a significant step forward in simplifying and accelerating the development of Pulumi providers. By focusing on a code-first approach, automatic schema generation, and providing a robust testing framework, we are empowering engineers to integrate Pulumi with virtually any service or tool.

We encourage you to explore the Pulumi Go Provider SDK, build your own integrations, and contribute to the growing ecosystem of Pulumi providers. Start with our Extending Pulumi overview documentation to get a complete picture of the possibilities.

Explore our documentation on Extending Pulumi
Review examples in the GitHub repository
Learn how to build a provider with our step-by-step guide
Identify your first integration - what custom service would provide the most value to your team?
Join our community in the Pulumi Community Slack to learn from others building custom providers
Share your feedback with us on the in Slack or by opening an issue in the pulumi/pulumi-go-provider GitHub repository.

Happy building!

Pulumi Private Registry: The Source of Truth for Golden Paths

Pulumi IDP Team — Wed, 07 May 2025 00:00:00 +0000

As part of the Pulumi IDP announcement at PulumiUP, we introduced the Pulumi Private Registry. For years, we’ve worked with organizations that have built their own internal developer platforms on top of Pulumi. During that time, we identified what we believe is the best method for creating flexible golden paths – a bottom-up approach that utilizes a central source of truth to drive golden paths. Thanks to Pulumi Private Registry, this approach has never been simpler.

Codified Security and Compliance

Platform teams use Pulumi’s components and templates to standardize how resources and programs are shaped and provisioned. They use Pulumi ESC to automatically import secret dependencies and lease short-term credentials. They incorporate Pulumi CrossGuard policy as code to ensure that provisioned infrastructure remains compliant even when customized by developers. Publishing and consuming packages through the private registry guarantees platform teams can achieve the consistency, security, and compliance their business needs without sacrificing the flexibility their developers need.

Streamlined Publishing

The CLI publishing workflow prioritizes ergonomics, making it easy to use. Publishing a package is as simple as running a single CLI command, ensuring seamless integration in local or automated workflows. It supports publishing packages from public or private git repositories, package versioning, multiple organizations, and custom README paths.

Simplified Discovery

Once published, developers can discover standardized and compliant components and templates from a developer-friendly, centralized location – helping teams streamline infrastructure provisioning and avoid shadow workflows. Developers also get immediate context thanks to automatically generated API docs and READMEs.

Free Day 2 Context

Day 2 operations – maintaining, extending, and decommissioning infrastructure – comprise the bulk of the infrastructure lifecycle effort. Yet these tasks often feel like flying blind. Pulumi IDP takes a bottom-up approach, driving building block publishing, discovery, and consumption through the Private Registry. This also provides usage insights out of the box, enabling platform engineers to see where components are used and which versions are in play, making it easier to plan upgrades and safely decommission outdated packages.

Get Started Today

Pulumi IDP, including the Pulumi Private Registry, is now available in Public Preview for all users. Sign up for a free account to get started, learn more about Pulumi IDP, or start publishing packages to your private registry.

Announcing Pulumi IDP: Platform Engineering Accelerated

Pulumi IDP Team — Tue, 06 May 2025 00:00:00 +0000

Today, we’re excited to introduce Pulumi IDP (Internal Developer Platform), the latest evolution of the Pulumi Cloud Platform, designed to help organizations automate, secure, and manage everything they run in the cloud.

Get Started with Pulumi IDP

For the past eight years, we’ve helped organizations simplify the deployment and management of their infrastructure. Pulumi launched at the height of DevOps, bringing general-purpose programming languages to infrastructure as code (IaC) at a time when application teams were often manually deploying their own infrastructure. Users were instantly hooked on the ability to leverage familiar programming paradigms to manage their infrastructure.

As we evolved, we introduced additional products to meet the needs of an expanding user base. We launched Pulumi Components to increase standardization and reuse across any programming language. We launched Pulumi CrossGuard to codify policy as code and ensure compliance at scale. And last fall, we made Pulumi ESC and Pulumi Insights generally available to help tame secret sprawl and better manage all your cloud infrastructure.

At the same time that Pulumi was evolving, so too was the industry. DevOps ushered in a new way of shipping and maintaining software, but for many organizations, it brought about tool sprawl and Day 2 pain. These lessons learned, along with others, have led to the emergence of platform engineering and platform teams, which build tools and workflows that enable their internal users to provision infrastructure and deploy software.

Platform Teams

The goal and promise of platform teams are to understand the needs of their users, creating scalable workflows to provision and maintain secure, compliant, and reliable infrastructure through Internal Developer Platforms without being blocked by other teams or having to maintain it themselves.

However, Platform teams have faced a harsh reality – offering flexible golden paths that account for security, compliance, and maintainability is inherently difficult. Most platform teams – especially in enterprises – must also build for multiple personas with varying consumption methods, from writing their own IaC code to point-and-click deployments.

Without establishing a foundation of standardized, reusable primitives that can be consumed in multiple ways, platform teams will stay trapped in a cycle of trying to build everything for everyone.

Pulumi IDP

Pulumi IDP is a bottom-up framework that integrates with the entire Pulumi product suite, enabling platform teams to build and manage self-service workflows based on codified golden paths. We have launched a suite of new features and invested in existing ones to make the Day 0 through Day 2 experience of operating infrastructure seamless.

Day 0: Establish a source of truth for standardized infrastructure building blocks that can be consumed in any workflow.
Day 1: Provision infrastructure through flexible workflows based on standardized building blocks.
Day 2: Establish context, gain insights, and perform operational tasks.

Private Registry as the Source of Truth

The foundation of Pulumi IDP is the Pulumi Private Registry, the source of truth for private components, templates, providers, and policies.

Pulumi has long focused on enabling organizations to author reusable infrastructure building blocks. We recently introduced the latest generation of Pulumi components for encapsulating and reusing resources across programming languages. Reusable packages offer tremendous benefits, but significant pain points have also emerged:

Discoverability: Once authored, teams often store packages in Git, but in most organizations, especially enterprises, they quickly become invisible. If no one can find packages, they won’t reuse them, and teams will write one-off solutions instead.
Lifecycle Management: Organizations that are able to drive discovery and adoption encounter Day 2 issues, such as a lack of usage insights, performing updates, and more.

The Pulumi Private Registry was built to solve these issues and more. With a single pulumi publish command, platform engineers can ensure their standardized building blocks are discoverable from a central location. Their end-users can discover the packages available, explore README files, consume automatically generated API documentation, and learn about installing and using the package.

Driving standardized component and template utilization through the registry also provides valuable usage insights for lifecycle management. Platform engineers can see where each package or template is used and at which version – critical for assessing the impact of changes and tracking version drift.

Flexible Self-Service Workflows

To ensure that users can consume packages and templates ergonomically, we’re introducing new flexible workflow tools to meet the needs of any persona.

Platform teams can exhaust themselves with designing, codifying, and publishing standardized patterns, but if they are not easily consumable, they won’t be used. Platform teams are often tasked with accommodating a spectrum of personas, ranging from users who want to scaffold infrastructure through components to non-technical users who want to point and click to deploy from a template. Each of their needs is valid, but the adage “designing for everyone means designing for no one” can quickly take effect.

With Pulumi IDP’s bottom-up approach, this isn’t an issue. The same standardized, secure, and compliant packages and templates published in a private registry are the same ones that power self-service workflows.

No-Code

In no-code workflows, users can instantly create and deploy Pulumi programs without worrying about the underlying IaC code or stack configuration. The no-code workflow is built on Pulumi organization templates and stores stack config in Pulumi ESC, eliminating the need to write to a VCS like GitHub or GitLab. By storing config in Pulumi ESC, developers can also edit config on-demand and instantly redeploy.

Low-Code

Users often need to compose their own Pulumi programs, but platform engineering teams want to ensure they use approved components. With the new Pulumi Private registry and the latest generation of Pulumi components, that’s never been easier.

Platform engineers can author and publish components in any language. Users can then discover the available components through the private registry, add them as dependencies in a Pulumi YAML program, and deploy the infrastructure.

Full-Code

In some organizations, platform engineers want to offer application teams a starting point without dictating how they deploy infrastructure. Templates are now available from the Pulumi CLI to facilitate a local workflow. Application developers can scaffold infrastructure using the same templates available from the private registry directly from the convenience of their terminal.

For instances where a Pulumi program is written from scratch, the suite of Pulumi IaC languages is always nearby, with the ability to easily incorporate components to accelerate development.

Organizational Context through Services

After you define and deploy infrastructure, you need to manage it, and that’s easier when it reflects your organization’s context. To make this possible, we’re introducing Pulumi Services.

Services enable teams to logically group stacks, environments, and resources, creating representations that are familiar within their organization. The service’s entities can live anywhere in Pulumi – across IaC and ESC projects or in different Insights Accounts.

Services also support properties – metadata that adds important context to a service, such as links to observability dashboards, Slack channels, and more.

A New Era for Platform Teams

Ready to accelerate your platform engineering journey? Get started with Pulumi IDP today and explore our comprehensive documentation to learn how to build self-service infrastructure workflows, establish golden paths, and boost developer productivity. Join the growing community of platform engineers who are transforming how their organizations deliver and manage cloud infrastructure at scale.

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

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

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

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

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

Understanding Pulumi Components

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

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

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

What’s New with Pulumi Components

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

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

How It Works

Creating Components

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

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

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

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

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

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

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

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

 this.bucketName = this.bucket.id;

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

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

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

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

 args = args or SecureBucketArgs()

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

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

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

 self.bucket_name = bucket.id

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

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

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

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

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

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

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

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

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

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

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

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

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

 BucketName = bucket.Id;

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

package components

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

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

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

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

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

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

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

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

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

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

package io.mikhail.components;

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

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

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

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

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

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

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

 this.bucketName = bucket.id();

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

package io.mikhail.components;

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

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

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

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

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

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

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

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

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

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

 private SecureBucketArgs() {}

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

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

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

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

 outputs:
 bucketName: ${bucket.id}

The PulumiPlugin.yaml File

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

runtime: nodejs

runtime: python

runtime: dotnet

runtime: go

runtime: java

runtime: yaml

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

Define an Entry Point

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

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

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

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

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

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

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

package main

import (
 "context"

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

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

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

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

using System.Threading.Tasks;

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

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

package com.example.components;

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

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

No separate entry point is required for YAML.

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

Publishing to Git

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

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

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

Under the hood, Pulumi:

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

Referencing Components Locally

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

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

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

Consuming Components Across Languages

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

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

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

export const bucketName = secureBucket.bucketName;

import pulumi
from myorg_secure_s3_component import SecureBucket

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

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

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

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

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

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

package main

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

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

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

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

package mypackage;

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

import java.util.Map;

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

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

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

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

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

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

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

outputs:
 bucketName: ${secureBucket.bucketName}

See It In Action

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

Build reusable infrastructure components

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

Get started

Pro Tips

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

The Spectrum of Pulumi Components You Can Build

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

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

Conclusion

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

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

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