Pulumi Blog: Components

How to Build an Internal Developer Platform: Strategy, Best Practices, and Self-Service Infrastructure

Mitch Gerdisch — Thu, 14 Aug 2025 05:13:02 +0200

Welcome to the first post in our IDP Best Practices series. In this guide, we’ll walk through the strategic foundations for designing an Internal Developer Platform that empowers developers without sacrificing governance, security, or operational control.

At Pulumi, we’ve worked with hundreds of teams facing the same core challenge: How do you give developers the infrastructure access they need, while maintaining the governance and security your organization requires?

That tension is at the heart of every IDP conversation. Teams want to move faster and innovate, but also need to stay compliant, control costs, and maintain operational stability.

The good news? You can do both, with a clear strategy and the right approach. This series shares proven best practices for designing, building, and scaling IDPs using Pulumi.

These lessons come from real-world implementations across industries and company sizes—and are built to grow with you.

Understanding the Platform Engineering Layers in Your Internal Developer Platform

When we work with customers on their platform strategy, we often start by referring to the “platform engineering layer cake.” Here is a quick walkthrough of each layer and how Pulumi IDP constructs fit this layer cake approach:

Layer 1: Infrastructure Layer - This is your raw cloud resources: VMs, databases, networks, storage. These are the fundamental building blocks that exist in AWS, Azure, GCP, and other cloud providers.

Layer 2: Platform Layer - This is where Pulumi Components live. Components take those raw infrastructure resources and package them into higher-level abstractions that encapsulate best practices, security policies, and organizational standards. For example, instead of manually configuring 15 different AWS resources to create a secure web application, you create a component that handles all that complexity and exposes just the configuration options that matter to your developers.

Layer 3: Developer Experience Layer - This is where Pulumi Templates and the Private Registry come into play. Templates provide ready-to-deploy patterns that developers can customize, while the private registry makes everything discoverable and manageable at scale.

In our workshop, we focused specifically on those top two layers because that’s where the transformation happens. This is where you turn raw infrastructure into something developers can actually use productively without becoming infrastructure experts themselves.

Here’s how this maps to what you’re actually building:

Infrastructure Layer → Raw Cloud Resources

Your foundation is still the same: AWS EC2 instances, Azure Virtual Networks, GCP Cloud Functions. Pulumi’s providers give you access to these resources using real programming languages instead of YAML or proprietary DSLs.

Platform Layer → Pulumi Components

This is where you create your reusable building blocks. A component might encapsulate:

A complete microservice infrastructure pattern (load balancer, auto-scaling group, database, monitoring)
A secure data pipeline (storage, processing, access controls, encryption)
A standardized Kubernetes application deployment (ingress, service, deployment, secrets management)

Components are written once in any supported language (TypeScript, Python, Go, .NET, Java) but can be consumed by teams using any of these languages. This is crucial. Your platform team might write components in Go, but your application teams can consume them in Python or TypeScript.

Developer Experience Layer → Templates + Private Registry

Templates are complete, deployable projects that use your components. They provide:

Getting started patterns: “Deploy a new microservice”
Reference architectures: “Deploy a three-tier web application”
Environment patterns: “Set up a complete dev/staging/prod pipeline”

The Private Registry is your distribution mechanism. It’s where components and templates become discoverable, versioned, and manageable. Developers don’t need to hunt through Git repositories or Slack channels to find the right building blocks. Everything is catalogued, documented, and accessible through familiar package management workflows.

IDP Example: Building a Web Application Platform Step-by-Step

Let’s make this concrete with an example from our workshops. Say you want to enable teams to deploy secure web applications:

Infrastructure Layer: You need an Application Load Balancer, EC2 Auto Scaling Group, RDS database, VPC with proper subnets, Security Groups, IAM roles, CloudWatch monitoring, and S3 bucket for static assets. That’s about 20+ individual AWS resources that need to be configured correctly and securely.

Platform Layer (Components): You create a WebApplication component that encapsulates all this complexity. Your component exposes simple configuration options like:

const app = new WebApplication("my-app", {
 instanceType: "t3.medium",
 minSize: 2,
 maxSize: 10,
 databaseSize: "small",
 environment: "production"
});

Behind the scenes, your component handles all the security configurations, networking setup, monitoring, and best practices. You publish this component to your private registry.

Developer Experience Layer (Templates): You create templates like:

web-app-starter: A simple web application using your WebApplication component
microservice-template: API service with database and monitoring
full-stack-template: Frontend, backend, and database in a complete environment

Developers can now run pulumi new web-app-starter and get a production-ready, secure web application in minutes instead of weeks. The template uses your component, which handles all the underlying infrastructure complexity.

This layered approach solves the core challenge we see every platform team struggling with: how do you provide developers with the infrastructure they need without creating operational bottlenecks or compromising security standards.

Why Internal Developer Platforms Matter in 2025 and Beyond

While DevOps brought us incredible advances in how we ship and maintain software, we’ve watched many organizations struggle with the unintended consequences: tool sprawl, Day 2 operational pain, and developers who are drowning in infrastructure complexity.

That’s why platform teams have emerged. You exist to solve these challenges by building tools and workflows that enable your internal customers (the developers) to provision infrastructure and deploy software without getting blocked. But here’s the thing I’ve learned from working with hundreds of platform teams: success isn’t just about the tools you choose. It’s about the strategy behind how you implement them.

5 Core Components of a Successful Internal Developer Platform

Through years of working with platform teams and analyzing what separates successful IDPs from those that struggle to gain adoption, we’ve identified five essential components that every platform strategy needs. These aren’t theoretical concepts. They’re battle-tested patterns that work across organizations of all sizes and industries.

1. Abstractions

Let me be clear about something: abstractions aren’t about dumbing down infrastructure for developers. The abstraction is really where you’re hiding the complexity of the underlying infrastructure from your end users, but you’re doing it intentionally to provide appropriate interfaces for different personas in your organization.

We’ve seen too many platform teams get this wrong by either over-abstracting (creating black boxes that developers can’t customize) or under-abstracting (exposing too much complexity). The sweet spot is creating component resources that encapsulate your infrastructure patterns and best practices into reusable building blocks that can be consumed across different programming languages and deployment scenarios, while still providing escape hatches when needed.

2. Blueprints

Blueprints are your templatized, well-architected patterns that developers can use to bootstrap their infrastructure. But here’s what I want you to understand about blueprints: they’re not just starting points that you throw over the wall to developers. They’re carefully designed patterns that embody your organizational best practices and architectural decisions.

When we see successful platform teams, their templates serve as both accelerators and guardrails. They give developers a fast path to production-ready infrastructure while ensuring that everything they deploy follows your organization’s standards. That’s the power of good blueprint design: speed and compliance working together, not against each other.

3. Workflows

Here’s where many platform teams get trapped: they try to build one workflow to rule them all. But in our experience working with organizations across every industry, you need to support multiple consumption patterns because you have multiple types of users. You need:

No-code workflows for users who want point-and-click deployment (think product managers or junior developers who just need to spin up a database)
Low-code workflows using tools like Pulumi YAML for configuration-driven infrastructure (perfect for developers who understand infrastructure but don’t want to write Go or TypeScript)
Full-code workflows for developers who need maximum flexibility and want to leverage the full power of general-purpose programming languages

The key insight? These aren’t three different platforms. They’re three different interfaces to the same underlying components and templates.

4. Security guardrails

This is probably the most important distinction we can share with you: you want to have guardrails, not gates. Too many platform teams create approval processes and manual checkpoints that completely undermine the self-service promise they’re trying to deliver.

Guardrails are different. They start with the best practices and security built into the reusable abstractions. But even the most secure solutions need a safety net. This safety net is policy-as-code that runs automatically, preventing violations before deployment happens. When we work with customers on implementing Pulumi CrossGuard, we’re not creating new friction. We’re embedding security, compliance, and cost controls directly into the deployment process. The developer gets immediate feedback, and you get the assurance that nothing goes to production without meeting your standards.

5. Self-service

Everything we’ve talked about so far builds toward this moment: enabling developers to provision and manage infrastructure independently. But self-service isn’t just about providing a UI. It’s about carefully orchestrating all the other components to create experiences that are both powerful and intuitive.

When we walked through the demo in our workshop, what you saw was the culmination of thoughtful platform design. Developers can discover available services, deploy infrastructure through whatever interface makes sense for them, and manage their resources over time, all without requiring tickets or manual intervention from platform teams. That’s the promise of a well-designed IDP: developer autonomy without operational chaos.

Put your IDP strategy into practice

Build reusable components, golden paths, and self-service workflows on Pulumi, and give developers autonomy while you keep governance and costs in check.

Get started

How to Implement Your IDP Strategy

Supporting Different Personas in Your Internal Developer Platform Design

One of the biggest mistakes we see platform teams make: they try to build for their most sophisticated users first. But here’s what I’ve learned from working with hundreds of organizations: you need to think about all your personas from day one.

In most organizations, you’re serving:

Infrastructure engineers who want full control and flexibility (they’ll use the full-code workflows)
Application developers who need infrastructure but prefer higher-level abstractions (perfect for low-code approaches)
Non-technical users who want simple, point-and-click deployment (your no-code users)

The breakthrough insight that separates successful platform teams from struggling ones is this: all these personas can be served by the same underlying components and templates, just consumed through different interfaces. You don’t need to build three different platforms—you need to build one platform with three different consumption models.

Why a Private Registry Is Key to IDP Adoption

Here’s something we always tell platform teams: if you don’t solve the discoverability problem, your beautiful components and templates will sit unused in Git repositories where no one can find them. That’s why the private registry isn’t just a nice-to-have. It’s the foundation that makes everything else work.

When you establish a private registry as your source of truth for components, templates, providers, and policies, you’re solving two critical problems at once. First, discoverability: developers can actually find and explore what’s available. Second, lifecycle management: you can see where each package is being used, track version drift, and understand the impact of changes before you make them.

The workflow is beautifully simple: you publish standardized building blocks with a single pulumi publish command, and developers discover and consume these assets through familiar package management workflows they already know.

Aligning Your IDP to Organizational Context and Services

One pattern we see in every successful IDP implementation is that the platform reflects how the organization actually works. Your developers don’t think in terms of individual stacks or resources. They think in terms of services, applications, and business functionality.

That’s why we built Pulumi Services - to let teams logically group stacks and ESC environments in ways that make sense to your organization. Pulumi Services improve organization by helping your team model infrastructure in a way that’s familiar - simplifying Day 2 operations by providing additional context like links to relevant dashboards, Slack channels and more. When something breaks at 2 AM, your on-call engineer needs to understand dependencies, track usage, and manage infrastructure in the context of the business services that are actually impacted.

How to Measure the Success of Your Internal Developer Platform

Here’s something that might surprise you: the most successful platform teams we work with don’t measure their success by how many cool features they’ve built. They measure success by the business outcomes they’re driving:

Reduced time-to-market through faster infrastructure provisioning (because at the end of the day, your platform exists to help the business move faster)
Improved developer productivity by eliminating infrastructure bottlenecks (happy developers ship more features)
Enhanced security posture through consistent policy enforcement (security that doesn’t slow people down is security that actually gets used)
Lower operational overhead through standardization and automation (because your platform team’s time is better spent on innovation than toil)

The numbers speak for themselves. We’ve worked with customers like Snowflake who reduced deployment times from one and a half weeks to less than a day. Starburst Data cut their infrastructure deployments from two weeks to just three hours. These aren’t vanity metrics. They’re business transformations.

IDP Strategy: 5 Key Steps to Build a Strong Foundation

If you’re just starting your IDP journey, here’s the roadmap we give to every platform team we work with:

Start with user research: Before you write a single line of code, go talk to your developers. Understand your different personas and their actual needs, not what you think they need. Do your users like to work from the command line? Do they prefer interacting with a UI?
Identify common patterns: Look for infrastructure patterns that get repeated across teams. These are your goldmine—the patterns that, once abstracted and templatized, will provide immediate value.
Begin with components: Build reusable infrastructure building blocks before you worry about fancy UIs or workflow orchestration. You need solid foundations before you can build the house.
Implement progressive disclosure: Give people simple interfaces for common use cases, but always provide escape hatches for complex scenarios. The moment your abstraction becomes a prison, developers will route around it.
Measure and iterate: Track adoption and gather feedback religiously. Your platform is only as good as its adoption rate, and adoption only happens when you’re solving real problems for real people.

The Future of IDPs and Platform Engineering

Trends come and go, but platform engineering is here to stay. It’s not just another tool or methodology. This is how modern organizations scale infrastructure to match the speed of innovation. The companies that win are the ones that treat their Internal Developer Platform (IDP) as a strategic foundation, not just a tool.

Your job isn’t just to manage infrastructure and choose the right tools - it’s to enable developers to move faster while keeping governance, security, and costs under control. Get that balance right, and your platform becomes a force multiplier across your entire engineering department.

The fastest way to get there? Focus on these five essential components:

Abstractions
Blueprints
Workflows
Security guardrails
Self-service

Together, they turn your IDP into more than just infrastructure automation, they create a platform that developers trust and your business relies on.

Ready to Build a Successful IDP that Scales?

Pulumi makes it easy to go from static IaC to dynamic, self-service infrastructure with real programming languages and built-in guardrails.

Explore Pulumi IDP or sign up for free to get started today.

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!

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.

Organizing AWS Accounts With Pulumi

Praneet Loke — Mon, 06 Feb 2023 00:00:00 +0000

In an enterprise organization, an IT self-service “vending machine” allows employees to quickly and easily request and receive access to pre-approved cloud resources. Behind the scenes, Pulumi programs may orchestrate any of the requisite resources. We will look at an example of using Pulumi to create an AWS child account, within an AWS Organization.

One might envision a developer requesting a new AWS account to be added entirely through a Pull Request in a git repository either for their own use or on behalf of a team. This scenario is not just for enterprises, however. Teams of any size should organize their AWS accounts using the least-privileged access principle.

Here’s the Organization structure we are looking to build with Pulumi. It just has one organizational unit (OU) with one member account under it to demonstrate how teams can construct the structure that works best for them or follow AWS’ recommendations on this topic. Depending on your team size you may want to keep this simple or you may need something that can handle multiple teams each with multiple accounts. The decision is yours.

For the above organization structure, we want the following operational model:

The user accounts for developers will be provisioned (either manually or automatically through SSO depending on your HR systems) in the root account. Developers will only be able to assume a specific role in the target accounts that have a trust boundary with the root account.
Developers will be added to a group and the group should be granted access to assume a role.
An IAM user meant for automation (eg. CI/CD pipelines) in the root account should have access to assume a role in the target account in order to manage resources. No developer should have access to assume the role meant for the automation user.
An org unit-level (OU) backup policy that backs-up resources tagged with a specific key/value pair.
An org unit-level (OU) tagging policy that enforces tag-casing and the default tags that resources should have.

The component resources mentioned in this post are for demonstration and to show you how you can use the expressiveness found only in the Pulumi programming model. Some details are omitted in this post for brevity. Please see the source repository for the complete source code. In order to modify the organization resources you’ll need credentials to an admin IAM user from your management account. Create an IAM user specifically to run this infrastructure app. These elevated credentials should not be used for anything else.

Once the member accounts have been created, in order to operate in those accounts using your preferred CI/CD service, we’ll create an automation user that will specifically have the permissions to assume a role in the member account. So you should use the credentials of that user for any other resources the team would want to deploy. For example, the team might want to deploy a new ECS cluster, along with Managed Redis instances and perhaps an RDS cluster too. These are resources specific to the team and what they want to use the account for.

If you are using one of the supported CI/CD services you might be able to use federated credentials using OIDC. So if you are going to use that auth mechanism, you can skip creation of the fixed automation user account since you will not need its credentials.

Organizational Unit (OU)

An org unit can represent anything. In our example it represents the development team. You could also have multiple OUs and even nest them to create sub-hierarchies, depending on your use-case.

The organizations module in the AWS provider package contains the resources we need in order to create an OU and an account.

// If you've already created an organization in your root account
// and don't want it to be managed by Pulumi then simply retrieve
// it using the `getOrganization` function.
const organization = aws.organizations.getOrganization({});

// Otherwise, create an organization and let Pulumi manage it.
// If you are going to create the organization using the following
// construction, you should remove the call to getOrganization above.
//
// const organization = new aws.organizations.Organization("");

const devOrgUnit = new aws.organizations.OrganizationalUnit("orgUnit", {
 parentId: organization.then((o) => o.roots[0].id),
 name: "Development",
});

const devAccount = new aws.organizations.Account(
 "devAccount",
 {
 name: "DeveloperAccount",
 parentId: devOrgUnit.id,
 email: devAccountEmailContact,
 // This role can be used by this Pulumi app to execute
 // an AssumeRole action on this new member account.
 // This role is automatically created in every new
 // account created in an Organization. The name
 // `OrganizationalAccountAccessRole` is the default
 // name. You may choose a different name.
 // https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html
 roleName: "OrganizationalAccountAccessRole",
 // IMPORTANT! Set this to `false` if you do not wish to have
 // accounts closed when the account resource is removed from
 // your Pulumi app.
 closeOnDeletion: true,
 },
 // This flag tells Pulumi to protect this resource from being deleted
 // during a `pulumi destroy` operation. It also means you need to
 // first unprotect it if you do wish to delete it using Pulumi.
 // https://www.pulumi.com/docs/concepts/options/protect/
 { protect: true }
);

An important note about the Account resource and destroying them. Notice how we set the closeOnDeletion to true. Closing accounts on deletion will only succeed if you have not exceeded the quotas set by AWS for account closure. So set that flag accordingly. If you expect to be closing many accounts frequently (perhaps for an ephemeral use-case), you may want to set the flag to false so you can close them manually or have some other sort of asynchronous automation do it for you. Otherwise, your Pulumi execution will fail when AWS returns an error code due to the quota being exceeded.

Developers’ Access

We’ll create an IAM group for developers and assign a group policy that allows its members to perform the sts:AssumeRole on any AWS account but only using a specific role.

const devGroup = new aws.iam.Group("developers", {
 name: "developers",
});

new aws.iam.GroupPolicy("developersGroupPolicy", {
 group: devGroup.name,
 policy: {
 Statement: [
 {
 Effect: "Allow",
 Action: "sts:AssumeRole",
 // This role will be created by the AccountPermissions component resource
 // introduced in the next section of this post.
 Resource: `arn:aws:iam::*:role/DeveloperRole`,
 },
 ],
 Version: "2012-10-17",
 },
});

Next, we’ll create the IAM user that we’ll use for automation purposes. Again, you don’t need to do this if you plan to use OIDC federation for your CI/CD service.

const automationUser = new aws.iam.User("automationUser", {
 name: "cicd-automation",
});

new aws.iam.UserPolicy("automationUserPolicy", {
 policy: {
 Statement: [
 {
 Effect: "Allow",
 Action: "sts:AssumeRole",
 // This role will be created by the AccountPermissions component resource
 // introduced in the next section of this post.
 Resource: `arn:aws:iam::*:role/AutomationRole`,
 },
 ],
 Version: "2012-10-17",
 },
 user: automationUser.name,
});

Member/Target Account Permissions

We’ve created the base infrastructure in our root (aka management) account. We now need to create roles in the target account that allows users in the management account to assume.

We’ll use a component resource to set up the necessary roles and policies in the target account. If you recall, when the target account was created, we specified a role name. That role name is the initial role that AWS creates on our behalf in the brand new account with admin privileges. The credentials we are using currently to execute our Pulumi app is assumed to be an admin user in the root account since we are dealing with highly-privileged operations here. We will need to create an explicit provider for our target account that can assume that automatically-created role.

const devAccountProvider = new aws.Provider("devAccountProvider", {
 allowedAccountIds: [devAccount.id],
 assumeRole: {
 roleArn: pulumi.interpolate`arn:aws:iam::${devAccount.id}:role/OrganizationalAccountAccessRole`,
 },
});

Now, whenever we want to modify resources in the target account in this app, we’ll use that provider. We’ll pass this provider to the component mentioned above, so that the roles and policies created by that component are performed using this provider instance. The component resource code is not included in this post for brevity. It provides a nice way to encapsulate the roles and policies we want to bootstrap our brand new account with. Of course, you can customize those roles and what permissions they get based on your use-case.

const devAccountPermissions = new AccountPermissions(
 "devAccountPermissions",
 {
 automationUser,
 managementAccountId: pulumi.Output.create(
 aws.getCallerIdentity().then((i) => i.accountId)
 ),
 // The prefix that will be used to name the child resources created by this component
 // since we expect to create a new instance of this component for every new member
 // account.
 resourceNamesPrefix: "dev"
 },
 { provider: devAccountProvider }
);

Backup Policies

Backup policies are strictly not required in order to create new member accounts in an OU. However, many teams have a requirement to have a backup policy for certain resources. Aside from the compliance requirement, it’s a good idea to ensure that your DBs, EBS volumes etc. are properly backed-up. AWS Backup is a managed backup service that allows you to define backup plans and create vaults in primary (where your resources reside) and a secondary (backup/copy region). AWS will execute your backup plans and create backups in the vaults.

We’ll once again use a component resource to encapsulate the creation of a backup vault in each of our member accounts. AWS recommends that we attach the backup policy to the organizational unit so that all member accounts inherit the policy implicitly.

AWS needs to know which resources to target to perform the backup. We provide that information using the selections property in the backup policy. The selections property allows you to specify tags that can be used as backup targets. In other words, compatible resources that have that tag will be targeted by this backup policy. In our example, the tag key is BackupType and the value is MONTHLY. This tag is optional, of course, since we don’t need every resource to have this tag; just the ones that need to be backed-up. You can enforce required tags too, which is a nice segue to our next topic.

const vault = new aws.backup.Vault(
 `backupVault-${accountName}`,
 // We rely on the vault name staying consistent across AWS accounts
 // for the purposes of the backup policy that is attached to the
 // organizational unit.
 { name: "Default" },
 { provider: accountProvider, parent: this }
);

// Create the IAM role in the target account that allows AWS Backup to execute backup plans.
const backupPolicyRole = new aws.iam.Role(
 `${accountName}BackupPolicyRole`,
 {
 // This name has to stay consistent across all member accounts
 // since we will reference this role in the actual backup policy.
 name: "MyMonthlyBackupIamRole",
 assumeRolePolicy: {
 Statement: [
 {
 Effect: "Allow",
 Action: "sts:AssumeRole",
 Principal: {
 Service: "backup.amazonaws.com",
 },
 },
 ],
 Version: "2012-10-17",
 },
 managedPolicyArns: [
 "arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForBackup",
 ],
 },
 { provider: accountProvider, parent: this }
);

The actual backup policy is a JSON document with a special syntax. In our example, the monthly plan looks like this:

Monthly_Backup_Plan: {
 regions: {
 "@@assign": this.primaryRegions,
 },
 rules: {
 Monthly: {
 schedule_expression: {
 "@@assign": "cron(0 5 1 * ? *)",
 },
 start_backup_window_minutes: { "@@assign": "480" },
 target_backup_vault_name: { "@@assign": "Default" },
 lifecycle: {
 move_to_cold_storage_after_days: {
 "@@assign": "30",
 },
 delete_after_days: { "@@assign": "365" },
 },
 copy_actions: backupVaultCopyAction,
 },
 },
 selections: {
 tags: {
 Backup_Assignment: {
 iam_role_arn: {
 "@@assign": `arn:aws:iam::$account:role/${this.monthlyBackupPolicyIamRoleName}`,
 },
 tag_key: { "@@assign": "BackupType" },
 tag_value: { "@@assign": ["MONTHLY"] },
 },
 },
 },
},

Tagging Policies

Similar to backup policies, tag policies are also not required to create member accounts in an OU. But it’s a good idea to define one. In keeping with our general theme here, we’ll encapsulate our tagging policy with yet another component resource so that we can easily include future org units. Similar to the backup policy syntax, the tag policy syntax uses JSON with some special placeholder variables.

Let’s take a look at the consumer point-of-view for this component. We want users of this component to pass in a list of allowed cost centers for a certain org unit. Say, if a team wants to have multiple org units and therefore different cost centers for each of them, this model allows those teams to use the TagPolicies component for each org unit separately and assign the allowed cost center values accordingly.

const tagPolicies = new TagPolicies("tagPolicies", {
 costCenters: [
 {
 // The component accepts an array of allowed cost center
 // values that can be used as values in tags.
 // This is just an example of how you can restrict what values
 // tags can be assigned.
 allowedCostCenters: ["Development", "Testing"],
 ou: devOrgUnit,
 },
 ],
 orgId: organization.then((o) => o.roots[0].id),
});

The tag policy for our example looks like this:

{
 type: "TAG_POLICY",
 content: JSON.stringify({
 tags: {
 CostCenter: {
 tag_value: {
 // The allowed cost center values that we passed
 // to the TagPolicy component as an arg.
 "@@assign": costCenter.allowedCostCenters,
 },
 },

 // Add tags that are enforceable only to the OU.
 Owner: {
 tag_key: {
 "@@assign": "Owner",
 // Don't allow any child policies from changing the key of this tag.
 "@@operators_allowed_for_child_policies": [
 "@@none",
 ],
 },
 },
 },
 }),
}

And that’s about it as far as setting up the simple org unit and member account structure shown at the beginning of this post. View the full source-code for the component resources in the pulumi/examples repository.

Here’s how the stack looks once the organizational unit and the development AWS account in it have been created.

Suppose there is a need to add a new AWS account for a test account in addition to the development account. We just need a new Account resource, the backup policy and the permissions for it.

const testAccount = new aws.organizations.Account(
 "testAccount",
 {
 name: "SharedTestAccount",
 parentId: devOrgUnit.id,
 email: testAccountEmailContact,
 roleName: initialRoleName,
 closeOnDeletion: true,
 },
 { protect: true }
);

const testAccountProvider = new aws.Provider("testAccountProvider", {
 allowedAccountIds: [testAccount.id],
 assumeRole: {
 roleArn: pulumi.interpolate`arn:aws:iam::${devAccount.id}:role/${initialRoleName}`,
 },
});

const testAccountPermissions = new AccountPermissions(
 "testAccountPermissions",
 {
 automationUser,
 managementAccountId: pulumi.Output.create(
 aws.getCallerIdentity().then((i) => i.accountId)
 ),
 resourceNamePrefix: "test",
 },
 { provider: testAccountProvider }
);

And with those additions, we get this preview:

This post demonstrates how you could use the Pulumi programming model to encapsulate and account for the hierarchical organization structure that your team desires or is required to have for any number of reasons. While an enterprise organization might be interested in this sort of a setup to ensure multiple teams in the organization operate in a similar way, smaller teams should also strongly consider organizing their AWS accounts in a way that enforces the principle of least privileged access. Especially, if you are looking to get SOC2 certified and need to ensure strict isolation of resources that hold any kind of real-world customer data.

Manage AWS accounts as code

Use Pulumi component resources to provision AWS Organizations units, member accounts, and least-privilege roles in a repeatable way. Build a self-service account structure your team can request and review in a pull request.

Learn more

Next Steps

There’s so much more you can do with AWS Organizations and Pulumi.

Learn about service control policies and how you can centrally control the maximum available permissions in a member account, for example.
These Pulumi features could be combined to provide a powerful self-service mechanism for your organization: Automation API, Policy-as-Code (similar in its principle to AWS SCPs but operates at the Pulumi resource-level so you can validate every resource created using Pulumi)
Best practices for your management account
Best practices for your member accounts

Introducing the Azure Static Website Component

Sean Holung — Tue, 11 Oct 2022 00:00:00 +0000

Deploying a static website often involves provisioning a number of pieces of infrastructure and stitching those pieces together in a way to make the site accessible to your users. A static website typically consists of HTML, CSS, and JavaScript files along with any other static assets the site might need to render such as PNG and SVG files for example. These files are then uploaded to a storage bucket where they can be served from. This post will demonstrate how to easily deploy your static website to Azure and make it available for public access.

Azure Static Website Component

Pulumi components enable us to create re-usable abstractions that can perform complex tasks all behind a simple interface the user can programmatically interact with. The Azure Static Website component looks to take all of the complexity of getting a static website deployed to Azure and simplify it down to just consuming a simple component and passing it a few input arguments. This component relieves the complexities of this process by allowing you to simply tell the component where your files are located and it will take care of all the rest.

This component does the following:

Provisions an Azure storage account
Uploads the website contents located in the specified directory
Optionally can configure a CDN, custom domain, and certs.

Using the component to deploy a static website

Let’s walk through a simple example of using this component to deploy a static website. Today, we are going to provision a storage account, upload the website contents, and wire it up to an Azure CDN.

In order to follow along with this example you will need to have the following:

Pulumi CLI installed on your machine
Access to an Azure account to provision the infrastructure
Static site to upload

See our getting started guide for information on how to configure Pulumi and Azure.

We will provision a number of pieces of infrastructure in Azure to enable serving our static website. The main ones are a Storage Account to contain all of our website files and a CDN. Let’s start by creating a new Pulumi project. First, create a new directory on your machine where the Pulumi project will live. A common pattern is to include the infrastructure configuration in a directory alongside the website you will be deploying. You can create a directory called infrastructure to house the Pulumi program or you can use another name if you prefer. This allows us to easily reference the location of the contents of your site as well as keeps your infrastructure code along-side your application. Pulumi supports multiple programming languages such as TypeScript, Python, Go, .NET, and even markup languages like YAML. Once you have created the directory, run the following command for your language of choice inside the directory:

pulumi new azure-typescript

pulumi new azure-python

pulumi new azure-csharp

pulumi new azure-go

pulumi new azure-yaml

There will be some prompts that appear asking you a few questions. Feel free to accept the defaults or change them to your desired preference. This command generated a new project and created a few files for you. You can copy the code examples below for the language you chose to use.

import * as pulumi from "@pulumi/pulumi";
import * as website from "@pulumi/azure-static-website";

const site = new website.Website("site", {
 sitePath: "../site", // replace with path containing website contents
 withCDN: true,
});

export const cdnURL = site;

import pulumi
import pulumi_azure_static_website as azure_static_website

site = azure_static_website.Website("site",
 site_path="../site", # replace with path containing website contents
 with_cdn=True)
pulumi.export("cdnURL", site.cdn_url)

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

return await Deployment.RunAsync(() =>
{
 var web = new AzureStaticWebsite.Website("web", new()
 {
 WithCDN = true,
 SitePath = "../site", // replace with path containing website contents
 });

 return new Dictionary<string, object?>
 {
 ["websiteURL"] = web.CdnURL,
 };
});

package main

import (
 "github.com/pulumi/pulumi-azure-static-website/sdk/go/azure-static-website"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 web, err := azure - static - website.NewWebsite(ctx, "web", &azure-static-website.WebsiteArgs{
 WithCDN: pulumi.Bool(true),
 SitePath: pulumi.String("../site"), // replace with path containing website contents
 })
 if err != nil {
 return err
 }
 ctx.Export("websiteURL", web.CdnURL)
 return nil
 })
}

name: az-website
runtime: yaml
description: A static website build with pulumi-azure-static-website.
resources:
 web:
 type: "azure-static-website:index:Website"
 properties:
 withCDN: true
 sitePath: "../site"
outputs:
 websiteURL: ${web.cdnURL}

This code creates a new instance of the Website component and sets a couple of properties. sitePath is the location where your website contents live. The sitePath specified should be the output location of your website’s build not the overall directory where your application lives. For example, if using a framework like React, the build output is usually placed in a directory called build. In addition, we set withCDN to true to let the component know that you would like to provision a CDN as well. It also exports the cdnURL property, which is the URL where the site can be accessed. That’s all that is needed and now we are ready to deploy!

You can now run pulumi up to deploy the site to Azure. This will first show a preview of the resources that will be provisioned. You can go ahead and accept by selecting yes.

In a few minutes your site will be provisioned and ready to access. Use the cdnURL that was output at the end of the provisioning to access the site!

As you can see, the Azure static website component made this task very easy. With just a few lines of code we were able to provision our site.

If you would like to learn more about Pulumi, here are some links you may find interesting:

Visit our Getting Started to quickly get up and running with Pulumi.
View the GitHub repo for the Azure static website component.
Visit our registry page to more components we have available for you to consume.
Check out our new templates that make it quick and easy to deploy common cloud architectures.

Create an AWS Static Website Fast with Angular and Pulumi

Sean Holung — Wed, 24 Aug 2022 00:00:00 +0000

In this blog post, we’re going to use some Angular framework components to assemble a static website and then use Pulumi and its AWS Static Website component to deploy it to AWS. The website is for a café called the Pulumi Café. It will contain two pages, one an About page and the other a Menu page, as well as some navigational pieces.

To follow this example, you need to have both Angular and Pulumi installed. (Here’s a link to the Pulumi installation instructions.) You’ll also need an AWS account.

What is Angular?

Angular is an open-source UI framework for building single-page client applications with HTML and TypeScript. Angular itself is written in TypeScript and its architecture follows the Model-View-Controller (MVC) design pattern.

What are Components in Angular?

In Angular, the basic building blocks of a website are called components. These are reusable structures that contain their own logic and functionality. For example, you could create a button as an Angular component and program it to have a particular look and a particular behavior. Then, you would reuse the button component wherever you need it in the website. The button could also be configurable meaning that, based on different properties, you could change its look and behavior.

A simple website, like the one we’ll be building in this post, is mainly created from a group of Angular components.

What is the AWS Static Website Component?

The AWS Static Website component from Pulumi makes it easy to deploy an AWS S3 static website and, optionally, add a CloudFront content distribution network (CDN). While you can use any of the programming languages Pulumi supports (TypeScript, JavaScript, Python, Go, .NET, Java, and YAML), we’ll be using TypeScript, since that is what the Angular framework uses.

The great advantage of the AWS Static Website component is that you can have a complete, functioning site in a few minutes. The component encapsulates all the complex logic that an AWS static website requires. Without the component, you would need to spend hours or even days writing and debugging code to get the same result.

If you’re interested in learning more about the component, read Deploy Static Websites to AWS using 10 lines of YAML.

The Angular Components

All the Angular components you need to build the website are available in the GitHub repository. The repository contains:

A component for the left navigation bar.
A component for the top navigation bar.
A component for the Home page.
A component for the Menu page.

We also use some components that come with the Angular framework.

Each of the components has a TypeScript file that contains the programming logic and an HTML file that describes how the component will render.

Building the Pulumi Café Website

Here are the instructions to build the website.

Clone the GitHub repository located here.
Run npm install to install the website’s node dependencies.

Deploy the Site with Pulumi

You’re now ready to set up Pulumi to deploy the site to AWS.

Create a directory named pulumi in the root of the project directory and then navigate to it with this command:
```
mkdir pulumi && cd pulumi
```
You’re now in the pulumi directory. Generate a Pulumi project file and create a Pulumi.yaml file with the following command. You will be asked a few questions from the prompt. Use angular-static-website for the project name and accept the suggested defaults for the remaining questions:
```
pulumi new aws-yaml
```

Modify the .yaml File

We need to add a few lines of code to the Pulumi.yaml file. In the resources section, the code references the AWS Static Website component and sets the sitePath property to the location of the dist build directory. We also want to know the URL of the site once it’s deployed. That’s what the outputs section does. The websiteURL parameter is one of the outputs that the AWS Static Website component provides. Replace the contents of Pulumi.yaml with the following code:

name: angular-static-website
runtime: yaml
description: Example of deploying Angular with Pulumi
resources:
 web:
 type: "aws-static-website:index:Website"
 properties:
 sitePath: "../dist/"
outputs:
 websiteURL: ${web.websiteURL}

The AWS Static Website component is the reason you only need a few lines of code to deploy the site. By using it, all the work of setting up AWS is done for you.

To deploy the website, type pulumi up. You’ll first see a preview of all the resources that will be created. Confirm that you want to proceed and Pulumi deploys the website to AWS.

It’s that simple. With just a few lines of code and one command you deployed your site. Navigate to the site and you’ll see the Home page for the café.

You can see the navigation components on the left-hand side. Click Menu to see the Menu page.

Manage Your Site with Pulumi

Along with making it simple to deploy your site, Pulumi also makes it easy to perform some management tasks. For example, If you want to take down the site, run pulumi destroy. You never have to worry that you’ll forget to remove some resource and continue to pay for it. Pulumi also keeps track of changes to website files, can generate resource graphs and give you complete information about the resources you’re using.

Learn More

If you want to learn more about Pulumi and the AWS Static Website component, here are a few links you might find interesting:

Along with the Deploy Static Websites to AWS using 10 lines of YAML blog post, take a look at the AWS Static Website reference page.
If you want to learn about other Pulumi components, the registry page catalogs them all.
If you want to view more examples of how to use Pulumi, go to the Pulumi examples repo.
If you want to delve deeper into Pulumi, the Getting Started guide is a good first step.
If you’re interested in learning more about Pulumi concepts, try the Concepts page.
If you want to learn more about Angular, see their Getting Started docs.

Deploy Static Websites to AWS using 10 lines of YAML

Sean Holung — Thu, 07 Jul 2022 00:00:00 +0000

The AWS Static Website component makes it easy to deploy an AWS S3 static website and, optionally, add a CloudFront content distribution network (CDN). While you can use any of the programming languages Pulumi supports (TypeScript, JavaScript, Python, Go, .NET, Java, and YAML), the component is particularly useful if you use YAML or JSON. With the AWS Static Website component, you’ll have a complete, functioning site in a few minutes. Without it, you can spend hours or even days to get the same result.

The component is designed to be simple to use and accessible to a broad range of developers. The only prerequisites are a basic knowledge of YAML or JSON, an AWS account, and an understanding of what a static website is. Even if you’re not used to thinking about infrastructure as code (IaC), you can use the component and let it handle the complexities that make setting up a website so time consuming.

You will need to have Pulumi on your machine to use the component because you run the pulumi up command to deploy the website. There’s a link to the installation instructions at the end of this article. You’ll also need an AWS account.

What the Component Does

The component deploys a static website to AWS and, optionally, a CloudFront CDN. You simply add a few lines of code, set a few configuration parameters, run pulumi up and let the component do the rest. The component sets up:

An Amazon S3 bucket
An Amazon CloudFront CDN (optional)
- An Amazon Route 53 DNS record
- An Amazon Certificate Manager SSL/TLS certificate

Some Examples

Let’s look at two examples of how to use the component. We’re going to use YAML in this post, but JSON is also supported as well.

Create a Website

This YAML code creates a basic static website.

name: react-static-website
runtime: yaml
description: Example of deploying React with Pulumi
resources:
 web:
 type: "aws-static-website:index:Website"
 properties:
 sitePath: "../my-website/build"
outputs:
 websiteURL: ${web.websiteURL}

This is the JSON equivalent of the code shown above.

{
 "name": "react-static-website",
 "runtime": "yaml",
 "description": "Example of deploying React with Pulumi",
 "resources": {
 "web": {
 "type": "aws-static-website:index:Website",
 "properties": {
 "sitePath": "../my-website/build"
 }
 }
 },
 "outputs": {
 "websiteURL": "${web.websiteURL}"
 }
}

This example code deploys a static React website but you can use the component with any other static website framework, such as Hugo. The only parameter that would change is the output directory specified in the sitePath property.

The first two lines of this example give the project a name and tell Pulumi that the code is YAML. The next line is simply a description of the project.

Next you allocate a resource. This is a Pulumi term. Resources are the fundamental units that make up your cloud infrastructure and Pulumi provides many resources that are ready for you to use. Here, you only need one: aws-static-website:Website, which is the AWS Static Website component. The resource has an input property, sitePath, which is the root directory that contains the website’s contents. Of course, you can use any path you want.

Finally, you’ll probably want to know the URL of your new site once it’s deployed. That’s what the outputs line does. websiteURL is one of the outputs that the component provides.

Get Started

To get started, go to the folder that contains your static website project. Then, follow these steps.

Create a directory named infrastructure alongside your website project directory with this command:
```
mkdir infrastructure && cd infrastructure
```
You’re now in the infrastructure directory. Generate a Pulumi.yaml file with this command:
```
pulumi new aws-yaml
```
Here’s an example of what the final directory structure looks like.
```
| react-project-dir
├── my-website
| ├── build
│ ├── index.html
│ ├── main.css
├── infrastructure
│ ├── Pulumi.yaml
```
Note: Pulumi will also add some other files to the infrastructure directory, such as a file that contains information specific to your Pulumi stack.

Copy the resources section and the outputs section from the example and add it to the end of the Pulumi.yaml file.

resources:
 web:
 type: "aws-static-website:index:Website"
 properties:
 sitePath: "../my-website/build"
outputs:
 websiteURL: ${web.websiteURL}

Deploy the Website

To deploy the website, type pulumi up. You’ll first see a preview of all the resources that will be created. You then confirm that you want to proceed and Pulumi deploys the website.

What You Gain

The entire example has 10 lines of YAML code. With this, you will get an S3 bucket provisioned with all of your website’s contents. If you looked at the preview screen when you ran pulumi up, you saw the many resources that actually had to be deployed to create the site. You never see any of that complexity. Here’s an example of what’s happening under the hood.

If you follow the View Live link, you will go to the Pulumi Service, where you can see all of the information available about a deployment and explore the resources that were deployed. For example, you can see a resource graph and a list of resources. Here’s an example of a resource graph.

After Pulumi deploys the website, it will display any outputs you specified which, in our example, is the URL of the site. as well as the number of resources created.

Input Properties

The AWS Static Website component has several input properties. Here are three of the most commonly used.

sitePath - the root directory that contains the website’s contents (required).
withCDN - sets a flag to provision a CloudFront CDN.
targetDomain - the domain that serves the content. A Route53 hosted zone must exist for this domain if you specify this option.

See the component’s reference page for the other properties this component supports.

Output Properties

The AWS Static Website component has several output properties. The one you’ll probably use the most is websiteURL, which is the URL to access the website. See the component’s reference page for the others.

Add a CloudFront CDN

To add a CloudFront CDN, you only need to add one more line of code.

name: react-static-website
runtime: yaml
description: Example of deploying React with Pulumi
resources:
 web:
 type: "aws-static-website:index:Website"
 properties:
 sitePath: "./my-website/build"
 withCDN: true
outputs:
 websiteURL: ${web.websiteURL}

All you have to do is add the line withCDN: true and the component sets up the CDN instance for you. Again, run pulumi up, confirm that you want to proceed, and Pulumi deploys the website. Here’s an example of what you’ll see.

And here’s the output.

More Pulumi Advantages

We’ve already seen how much Pulumi simplifies creating a website. Pulumi also keeps track of any changes you make to any of the website files. It makes those changes the next time you run pulumi up. Here’s an example screenshot. The changes are marked in the Plan column.

If you simply want to take an inventory of what’s changed, you can run pulumi up and not proceed with the confirmation. Alternatively, you can run pulumi preview.

If you want to take down the site, run pulumi destroy. Pulumi marks all the resources for deletion. It first previews the changes and, if you confirm, removes them from your AWS account. You don’t have to worry that you’ll forget to remove some resource and continue to pay for it. Here’s an example of what you’d see if you ran pulumi destroy on your AWS S3 static website.

Learn More

If you’re curious and want to learn more about Pulumi and the AWS Static Website component, here are a few links you might find interesting:

You can examine the GitHub repository that contains the code for the component.
If you want to quickly try out the component, this GitHub repo houses a complete React example project that you can clone.
If you want to learn about other Pulumi components, take a look at the registry page, which catalogs them all.
If you want to view more examples of how to use Pulumi, take a look at the Pulumi examples repo.
If you want to delve deeper into Pulumi, the Getting Started guide is a good first step.
If you’re interested in learning more about Pulumi concepts, try the Concepts page.

Install Pulumi

To install Pulumi for AWS, go to Before You Begin. There are instructions for macOS, Windows and Linux. You need to have an AWS account.

Pulumi Blog: Components

How to Build an Internal Developer Platform: Strategy, Best Practices, and Self-Service Infrastructure

Understanding the Platform Engineering Layers in Your Internal Developer Platform

Infrastructure Layer → Raw Cloud Resources

Platform Layer → Pulumi Components

Developer Experience Layer → Templates + Private Registry

IDP Example: Building a Web Application Platform Step-by-Step

Why Internal Developer Platforms Matter in 2025 and Beyond

5 Core Components of a Successful Internal Developer Platform

1. Abstractions

2. Blueprints

3. Workflows

4. Security guardrails

5. Self-service

How to Implement Your IDP Strategy

Supporting Different Personas in Your Internal Developer Platform Design

Why a Private Registry Is Key to IDP Adoption

Aligning Your IDP to Organizational Context and Services

How to Measure the Success of Your Internal Developer Platform

IDP Strategy: 5 Key Steps to Build a Strong Foundation

The Future of IDPs and Platform Engineering

Ready to Build a Successful IDP that Scales?

The Pulumi Go Provider SDK is Now Generally Available

Unlock the Full Potential of Your Cloud Ecosystem

Key Enhancements for Your Team

Defining and Testing a Custom Resource

Creating a Custom Resource in Minutes, Not Days

Confidence Through Comprehensive Testing

Standardize Infrastructure with Powerful Component Resources

Seamless Multi-Language Support and Sharing

Understanding Provider Schema

Get Started Today!

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

Understanding Pulumi Components

What’s New with Pulumi Components

How It Works

Creating Components

The PulumiPlugin.yaml File

Define an Entry Point

Sharing Components

Publishing to Git

Referencing Components Locally

Consuming Components Across Languages

See It In Action

Pro Tips

The Spectrum of Pulumi Components You Can Build

Conclusion

Organizing AWS Accounts With Pulumi

Organizational Unit (OU)

Developers’ Access

Member/Target Account Permissions

Backup Policies

Tagging Policies

Next Steps

Introducing the Azure Static Website Component

Azure Static Website Component

Using the component to deploy a static website

Create an AWS Static Website Fast with Angular and Pulumi

What is Angular?

What are Components in Angular?

What is the AWS Static Website Component?

The Angular Components

Building the Pulumi Café Website

Deploy the Site with Pulumi

Modify the .yaml File

Manage Your Site with Pulumi

Learn More

Deploy Static Websites to AWS using 10 lines of YAML

What the Component Does

Some Examples

Create a Website

Get Started

Deploy the Website

What You Gain

Input Properties

Output Properties

Add a CloudFront CDN

More Pulumi Advantages

Learn More

Install Pulumi