Pulumi Blog: Infrastructure as code

How to Test Infrastructure as Code

Alex Leventer — Tue, 30 Jun 2026 14:00:00 -0700

IaC testing means validating your infrastructure code the same way you test application software—unit tests with mocked cloud providers that run in milliseconds, integration tests that deploy and inspect real resources, and policy checks that enforce compliance rules on every preview and deploy. Together, these layers catch misconfigurations before they reach production.

Untested infrastructure code is a liability. A missing tag in a security group rule, an S3 bucket with public read access, a misconfigured IAM policy—any of these can slip through code review and land in production. Infrastructure bugs are often harder to debug than application bugs, because the feedback loop is slow (deploy, observe, destroy) and the blast radius is large (an outage, a security incident, a surprise AWS bill).

The good news: Pulumi is built on general-purpose programming languages, which means you can test infrastructure code with the exact same tools and frameworks you already use to test application code. No new language to learn. No separate toolchain. Just pytest, Mocha, or go test—pointing at your infrastructure program.

This guide walks through all three testing layers with complete, runnable examples.

Why should you test infrastructure as code?

The case for testing application code is well-established. The case for testing IaC is just as strong—arguably stronger, because the consequences of an undetected bug are more severe.

Catch misconfigurations before they deploy. A unit test that checks whether a security group allows SSH from 0.0.0.0/0 will catch that misconfiguration in milliseconds, before any cloud API call is made. The same test in CI catches it before the code is merged.

Prevent drift and outages. Integration tests that deploy to a staging environment and validate runtime behavior—does the HTTP endpoint return 200? does the database accept connections?—give you confidence that an infrastructure change doesn’t silently break a dependent service.

Refactor safely. Well-tested infrastructure code can be restructured, modularized, and upgraded without fear. When all your properties, tags, and security rules are asserted in tests, you know immediately if a refactor breaks a constraint.

Enforce security and compliance automatically. Policy as code lets you encode your organization’s security rules as executable tests. Mandatory policies block non-compliant deployments entirely; advisory policies surface warnings for human review. These rules run on every pulumi preview and pulumi up—not just at audit time.

Ship infrastructure at software speed. Teams that test IaC ship changes faster, with less fear. The CI pipeline becomes a confidence engine rather than a deployment gate.

The annual DORA State of DevOps research is consistently associated with a pattern among elite-performing engineering teams—those that deploy frequently and recover quickly from failures: comprehensive automated testing across the stack. Infrastructure is no longer exempt from that standard.

What types of IaC tests are there?

IaC testing mirrors the classic software test pyramid: a wide base of fast, cheap unit tests, a smaller layer of integration tests against real infrastructure, and policy checks that enforce rules throughout.

Layer	What it tests	Speed	Cost	Cloud credentials?
Unit tests	Resource properties, tags, security rules, naming conventions	Milliseconds	Free	No
Integration tests	Full stack lifecycle, runtime behavior, cross-resource dependencies	Minutes	Real cloud spend	Yes
Policy as code	Compliance rules, security baselines, organizational standards	Milliseconds	Free	No (runs at preview time)

graph TD
A["🔒 Policy as Code<br/>Compliance &amp; guardrails<br/>Runs at preview time<br/>Milliseconds · Free"] --> B
B["🧪 Integration Tests<br/>Real cloud deployments<br/>Full lifecycle validation<br/>Minutes · Cloud spend"] --> C
C["⚡ Unit Tests<br/>Mocked providers<br/>Property assertions<br/>Milliseconds · Free"]
style A fill:#8A3FFC,color:#fff,stroke:#6B2FD4
style B fill:#0EA5E9,color:#fff,stroke:#0284C7
style C fill:#10B981,color:#fff,stroke:#059669

Start with unit tests—they’re free, fast, and catch the most common mistakes. Add integration tests for critical paths (the deployment pipeline, data infrastructure, security-sensitive resources). Layer in policy as code for compliance requirements that must never regress.

How do you write unit tests for Pulumi?

Pulumi unit tests replace the communication channel between the Pulumi program and the cloud provider with mocks. When the program registers a resource (e.g., aws.ec2.SecurityGroup(...)), the mock intercepts the call, returns dummy state, and never makes a real cloud API call. Tests run in the same process, in the same language, using the same test runner you already use.

Setting up mocks

The import-order rule: You must set up mocks before importing your Pulumi program. If you import the program first, the Pulumi runtime initializes without mocks and will attempt real cloud calls.

# test_infra.py
import unittest
import pulumi

class MyMocks(pulumi.runtime.Mocks):
 def new_resource(self, args: pulumi.runtime.MockResourceArgs):
 # Return [id, state]. State keys must be camelCase.
 return [args.name + "_id", args.inputs]

 def call(self, args: pulumi.runtime.MockCallArgs):
 return {}

# Set mocks BEFORE importing the program
pulumi.runtime.set_mocks(MyMocks())
import infra # import program AFTER setting mocks

class TestInfra(unittest.TestCase):

 @pulumi.runtime.test
 def test_no_public_ssh(self):
 """Security group must not expose SSH to the public internet."""
 def check_security_group(args):
 ingress_rules = args[0]
 for rule in (ingress_rules or []):
 for cidr in (rule.get("cidrBlocks") or []):
 self.assertNotEqual(
 cidr, "0.0.0.0/0",
 "Security group must not expose port 22 to the internet."
 )
 return pulumi.Output.all(infra.group.ingress).apply(check_security_group)

 @pulumi.runtime.test
 def test_server_has_tags(self):
 """EC2 instance must have required tags."""
 def check_tags(args):
 tags = args[0]
 self.assertIn("Environment", tags, "Missing 'Environment' tag")
 self.assertIn("Name", tags, "Missing 'Name' tag")
 return pulumi.Output.all(infra.server.tags).apply(check_tags)

if __name__ == "__main__":
 unittest.main()

Run with: python -m unittest discover -v

// infra.test.ts
import * as pulumi from "@pulumi/pulumi";
import { expect } from "chai";

// Set mocks BEFORE dynamic import of the program
pulumi.runtime.setMocks(
 {
 newResource: (args: pulumi.runtime.MockResourceArgs): { id: string; state: any } => {
 // State keys must be camelCase
 return { id: `${args.name}-id`, state: args.inputs };
 },
 call: (args: pulumi.runtime.MockCallArgs) => ({ ...args.inputs }),
 },
 "my-project",
 "test",
 false // preview = false
);

describe("Infrastructure", function () {
 let infra: typeof import("./index");

 before(async function () {
 // Dynamic import AFTER setting mocks
 infra = await import("./index");
 });

 it("must not expose SSH to the internet", function (done) {
 pulumi.all([infra.group.ingress]).apply(([ingress]) => {
 for (const rule of ingress ?? []) {
 for (const cidr of rule.cidrBlocks ?? []) {
 expect(cidr).to.not.equal(
 "0.0.0.0/0",
 "Security group must not expose port 22 to the internet"
 );
 }
 }
 done();
 });
 });

 it("must have required tags", function (done) {
 pulumi.all([infra.server.tags]).apply(([tags]) => {
 expect(tags).to.include.keys("Environment", "Name");
 done();
 });
 });
});

Run with: mocha -r ts-node/register infra.test.ts

// infra_test.go
package infra_test

import (
 "testing"

 "github.com/pulumi/pulumi-aws/sdk/v6/go/aws/ec2"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
 "github.com/stretchr/testify/assert"
)

// MockResourceMonitor implements pulumi.ResourceMonitor for unit tests.
func TestNoPublicSSH(t *testing.T) {
 err := pulumi.RunErr(func(ctx *pulumi.Context) error {
 infra, err := NewInfra(ctx)
 assert.NoError(t, err)

 infra.Group.Ingress.ApplyT(func(rules []ec2.SecurityGroupIngress) error {
 for _, rule := range rules {
 for _, cidr := range rule.CidrBlocks {
 assert.NotEqual(t, "0.0.0.0/0", cidr,
 "Security group must not expose port 22 to the internet")
 }
 }
 return nil
 })
 return nil
 }, pulumi.WithMocks("my-project", "test", mocks{}))
 assert.NoError(t, err)
}

type mocks struct{}

func (mocks) NewResource(args pulumi.MockResourceArgs) (string, map[string]interface{}, error) {
 return args.Name + "_id", args.Inputs, nil
}
func (mocks) Call(args pulumi.MockCallArgs) (map[string]interface{}, error) {
 return args.Args, nil
}

Run with: go test ./... -v

// InfraTests.cs
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Pulumi;
using Pulumi.Testing;
using Xunit;

public class InfraTests
{
 [Fact]
 public async Task NoPublicSSH()
 {
 var resources = await Testing.RunAsync<MyStack>();

 var sg = resources.OfType<Pulumi.Aws.Ec2.SecurityGroup>().First();
 var ingress = await sg.Ingress.GetValueAsync();

 foreach (var rule in ingress)
 {
 foreach (var cidr in rule.CidrBlocks)
 {
 Assert.NotEqual("0.0.0.0/0", cidr);
 }
 }
 }

 [Fact]
 public async Task ServerHasRequiredTags()
 {
 var resources = await Testing.RunAsync<MyStack>();

 var server = resources.OfType<Pulumi.Aws.Ec2.Instance>().First();
 var tags = await server.Tags.GetValueAsync();

 Assert.True(tags.ContainsKey("Environment"), "Missing 'Environment' tag");
 Assert.True(tags.ContainsKey("Name"), "Missing 'Name' tag");
 }
}

Run with: dotnet test

// InfraTest.java
package myproject;

import com.pulumi.aws.ec2.Instance;
import com.pulumi.aws.ec2.SecurityGroup;
import com.pulumi.test.Mocks;
import com.pulumi.test.Mocks.CallArgs;
import com.pulumi.test.Mocks.ResourceArgs;
import com.pulumi.test.Mocks.ResourceResult;
import com.pulumi.test.PulumiTest;
import com.pulumi.test.TestOptions;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.Test;
import java.util.HashMap;
import java.util.Map;
import java.util.Optional;
import java.util.concurrent.CompletableFuture;
import static org.junit.jupiter.api.Assertions.*;

class InfraTest {

 // Implement Mocks to intercept resource creation. State keys must be camelCase.
 static class MyMocks implements Mocks {
 @Override
 public CompletableFuture<ResourceResult> newResourceAsync(ResourceArgs args) {
 var state = new HashMap<>(args.inputs);
 return CompletableFuture.completedFuture(
 ResourceResult.of(Optional.of(args.name + "_id"), state));
 }

 @Override
 public CompletableFuture<Map<String, Object>> callAsync(CallArgs args) {
 return CompletableFuture.completedFuture(Map.of());
 }
 }

 // PulumiTest.cleanup() must run after every test to reset the runtime state.
 @AfterEach
 void cleanup() {
 PulumiTest.cleanup();
 }

 @Test
 void serverHasRequiredTags() {
 var result = PulumiTest
 .withMocks(new MyMocks())
 .withOptions(TestOptions.builder()
 .projectName("project").stackName("stack").preview(false)
 .build())
 .runTest(ctx -> new Infra());

 var instance = result.resources().stream()
 .filter(r -> r instanceof Instance)
 .map(r -> (Instance) r)
 .findFirst()
 .orElseThrow(() -> new AssertionError("EC2 instance not found"));

 var tags = PulumiTest.extractValue(instance.tags())
 .orElseThrow(() -> new AssertionError("Tags must not be null"));
 assertTrue(tags.containsKey("Environment"), "Missing 'Environment' tag");
 assertTrue(tags.containsKey("Name"), "Missing 'Name' tag");
 }

 @Test
 void noPublicSshExposed() {
 var result = PulumiTest
 .withMocks(new MyMocks())
 .withOptions(TestOptions.builder()
 .projectName("project").stackName("stack").preview(false)
 .build())
 .runTest(ctx -> new Infra());

 var group = result.resources().stream()
 .filter(r -> r instanceof SecurityGroup)
 .map(r -> (SecurityGroup) r)
 .findFirst()
 .orElseThrow(() -> new AssertionError("Security group not found"));

 var rules = PulumiTest.extractValue(group.ingress());
 for (var rule : rules) {
 for (var cidr : rule.cidrBlocks()) {
 assertNotEquals("0.0.0.0/0", cidr,
 "Security group must not expose SSH to the internet");
 }
 }
 }
}

Run with: mvn test (JUnit 5)

The program under test

Both examples above test this program:

# infra.py
import pulumi
from pulumi_aws import ec2

group = ec2.SecurityGroup("web-secgrp",
 ingress=[{
 "protocol": "tcp",
 "from_port": 80,
 "to_port": 80,
 "cidrBlocks": ["0.0.0.0/0"],
 }],
)

server = ec2.Instance("web-server",
 instance_type="t2.micro",
 ami="ami-0b0ea68c435eb488d",
 vpc_security_group_ids=[group.id],
 tags={"Name": "web-server", "Environment": "dev"},
)

// index.ts
import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";

export const group = new aws.ec2.SecurityGroup("web-secgrp", {
 ingress: [{
 protocol: "tcp",
 fromPort: 80,
 toPort: 80,
 cidrBlocks: ["0.0.0.0/0"],
 }],
});

export const server = new aws.ec2.Instance("web-server", {
 instanceType: "t2.micro",
 ami: "ami-0b0ea68c435eb488d",
 vpcSecurityGroupIds: [group.id],
 tags: { Name: "web-server", Environment: "dev" },
});

// main.go
package infra_test

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

type Infra struct {
 Group *ec2.SecurityGroup
 Server *ec2.Instance
}

func NewInfra(ctx *pulumi.Context) (*Infra, error) {
 group, err := ec2.NewSecurityGroup(ctx, "web-secgrp", &ec2.SecurityGroupArgs{
 Ingress: ec2.SecurityGroupIngressArray{
 ec2.SecurityGroupIngressArgs{
 Protocol: pulumi.String("tcp"),
 FromPort: pulumi.Int(80),
 ToPort: pulumi.Int(80),
 CidrBlocks: pulumi.StringArray{pulumi.String("0.0.0.0/0")},
 },
 },
 })
 if err != nil {
 return nil, err
 }

 server, err := ec2.NewInstance(ctx, "web-server", &ec2.InstanceArgs{
 InstanceType: pulumi.String("t2.micro"),
 Ami: pulumi.String("ami-0b0ea68c435eb488d"),
 VpcSecurityGroupIds: pulumi.StringArray{group.ID()},
 Tags: pulumi.StringMap{
 "Name": pulumi.String("web-server"),
 "Environment": pulumi.String("dev"),
 },
 })
 if err != nil {
 return nil, err
 }

 return &Infra{Group: group, Server: server}, nil
}

// MyStack.cs
using Pulumi;
using Pulumi.Aws.Ec2;
using Pulumi.Aws.Ec2.Inputs;

public class MyStack : Stack
{
 public MyStack()
 {
 var group = new SecurityGroup("web-secgrp", new SecurityGroupArgs
 {
 Ingress = new[]
 {
 new SecurityGroupIngressArgs
 {
 Protocol = "tcp", FromPort = 80, ToPort = 80,
 CidrBlocks = new[] { "0.0.0.0/0" },
 },
 },
 });

 var server = new Instance("web-server", new InstanceArgs
 {
 InstanceType = "t2.micro",
 Ami = "ami-0b0ea68c435eb488d",
 VpcSecurityGroupIds = new[] { group.Id },
 Tags = new InputMap<string>
 {
 { "Name", "web-server" },
 { "Environment", "dev" },
 },
 });
 }
}

// Infra.java
package myproject;

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.aws.ec2.SecurityGroup;
import com.pulumi.aws.ec2.SecurityGroupArgs;
import com.pulumi.aws.ec2.Instance;
import com.pulumi.aws.ec2.InstanceArgs;
import com.pulumi.aws.ec2.inputs.SecurityGroupIngressArgs;
import java.util.List;
import java.util.Map;

public class Infra {
 public final SecurityGroup group;
 public final Instance server;

 public Infra() {
 this.group = new SecurityGroup("web-secgrp",
 SecurityGroupArgs.builder()
 .ingress(SecurityGroupIngressArgs.builder()
 .protocol("tcp")
 .fromPort(80)
 .toPort(80)
 .cidrBlocks("0.0.0.0/0")
 .build())
 .build());

 this.server = new Instance("web-server",
 InstanceArgs.builder()
 .instanceType("t2.micro")
 .ami("ami-0b0ea68c435eb488d")
 .vpcSecurityGroupIds(group.id().applyValue(List::of))
 .tags(Map.of("Name", "web-server", "Environment", "dev"))
 .build());
 }
}

Key detail: State property keys in the mock’s new_resource/newResource return value must be camelCase (cidrBlocks, not cidr_blocks), regardless of the language you’re writing in. This is how Pulumi serializes properties internally.

How do you run integration tests against real cloud resources?

Unit tests tell you whether your resource definitions are correct. Integration tests tell you whether your infrastructure actually works. Integration tests deploy real cloud resources, run assertions against them, and then destroy everything—giving you end-to-end confidence at the cost of actual cloud spend and time.

Using the Automation API

The Pulumi Automation API lets you drive pulumi up, pulumi destroy, and every other Pulumi CLI operation programmatically, from within a test. You define the stack inline (using a function that runs your Pulumi program) or point it at an existing project directory.

# test_integration.py
import pytest
import pulumi
import pulumi_aws as aws
from pulumi import automation as auto

def create_bucket_program():
 """The Pulumi program to deploy during the test."""
 bucket = aws.s3.Bucket("test-bucket",
 tags={"Environment": "test", "ManagedBy": "pulumi"},
 )
 pulumi.export("bucket_name", bucket.id)
 pulumi.export("bucket_arn", bucket.arn)

@pytest.fixture(scope="module")
def deployed_stack():
 """Deploy the stack for the test module and destroy it when done."""
 stack = auto.create_or_select_stack(
 stack_name="integration-test",
 project_name="bucket-test",
 program=create_bucket_program,
 )
 stack.set_config("aws:region", auto.ConfigValue(value="us-west-2"))

 # Install provider plugins
 stack.workspace.install_plugin("aws", "v7.34.0")

 # Deploy
 up_result = stack.up(on_output=print)

 yield up_result.outputs

 # Teardown: destroy everything after the test module completes
 stack.destroy(on_output=print)
 stack.workspace.remove_stack("integration-test")

def test_bucket_was_created(deployed_stack):
 """The S3 bucket should have been created with the expected name prefix."""
 bucket_name = deployed_stack["bucket_name"].value
 assert bucket_name.startswith("test-bucket"), f"Unexpected bucket name: {bucket_name}"

def test_bucket_has_tags(deployed_stack):
 """Verify the bucket was created with required tags (via AWS SDK)."""
 import boto3
 s3 = boto3.client("s3", region_name="us-west-2")
 bucket_name = deployed_stack["bucket_name"].value
 tagging = s3.get_bucket_tagging(Bucket=bucket_name)
 tag_map = {t["Key"]: t["Value"] for t in tagging["TagSet"]}
 assert tag_map.get("Environment") == "test"
 assert tag_map.get("ManagedBy") == "pulumi"

Run with: pytest test_integration.py -v

// integration.test.ts
import { LocalWorkspace, ConfigValue, UpResult } from "@pulumi/pulumi/automation";
import * as aws from "@pulumi/aws";
import * as pulumi from "@pulumi/pulumi";
import { expect } from "chai";

describe("S3 Bucket Integration", function () {
 this.timeout(300_000); // 5 min — real deploys take time

 let outputs: UpResult["outputs"];
 let stackName = "integration-test-ts";

 before(async function () {
 const stack = await LocalWorkspace.createOrSelectStack({
 stackName,
 projectName: "bucket-test",
 program: async () => {
 const bucket = new aws.s3.Bucket("test-bucket", {
 tags: { Environment: "test", ManagedBy: "pulumi" },
 });
 return {
 bucketName: bucket.id,
 bucketArn: bucket.arn,
 };
 },
 });

 await stack.setConfig("aws:region", { value: "us-west-2" });
 await stack.workspace.installPlugin("aws", "v7.34.0");

 const upResult = await stack.up({ onOutput: console.log });
 outputs = upResult.outputs;
 });

 after(async function () {
 const stack = await LocalWorkspace.selectStack({ stackName, projectName: "bucket-test", program: async () => {} });
 await stack.destroy({ onOutput: console.log });
 await stack.workspace.removeStack(stackName);
 });

 it("creates a bucket with the right name prefix", function () {
 const name = outputs["bucketName"].value as string;
 expect(name).to.match(/^test-bucket/);
 });
});

Run with: mocha -r ts-node/register integration.test.ts

// integration_test.go
package integration_test

import (
 "context"
 "fmt"
 "os"
 "testing"

 "github.com/pulumi/pulumi-aws/sdk/v6/go/aws/s3"
 "github.com/pulumi/pulumi/sdk/v3/go/auto"
 "github.com/pulumi/pulumi/sdk/v3/go/auto/optup"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
 "github.com/stretchr/testify/assert"
)

func TestBucketIntegration(t *testing.T) {
 ctx := context.Background()

 stack, err := auto.NewStackInlineSource(ctx, "integration-test", "bucket-test",
 func(ctx *pulumi.Context) error {
 bucket, err := s3.NewBucket(ctx, "test-bucket", &s3.BucketArgs{
 Tags: pulumi.StringMap{
 "Environment": pulumi.String("test"),
 "ManagedBy": pulumi.String("pulumi"),
 },
 })
 if err != nil {
 return err
 }
 ctx.Export("bucketName", bucket.ID())
 return nil
 },
 )
 assert.NoError(t, err)

 _ = stack.SetConfig(ctx, "aws:region", auto.ConfigValue{Value: "us-west-2"})
 upResult, err := stack.Up(ctx, optup.ProgressStreams(os.Stdout))
 assert.NoError(t, err)

 t.Cleanup(func() {
 _, _ = stack.Destroy(ctx)
 _ = stack.Workspace().RemoveStack(ctx, "integration-test")
 })

 name := fmt.Sprintf("%v", upResult.Outputs["bucketName"].Value)
 assert.Contains(t, name, "test-bucket")
}

Run with: go test ./... -v -timeout 10m

// IntegrationTests.cs
using System;
using System.Threading.Tasks;
using Pulumi.Automation;
using Xunit;

public class IntegrationTests : IAsyncLifetime
{
 private WorkspaceStack _stack = null!;
 private UpResult _upResult = null!;

 public async Task InitializeAsync()
 {
 var program = PulumiFn.Create(() =>
 {
 var bucket = new Pulumi.Aws.S3.Bucket("test-bucket", new()
 {
 Tags = new() { ["Environment"] = "test", ["ManagedBy"] = "pulumi" },
 });
 return new System.Collections.Generic.Dictionary<string, object?>
 {
 ["bucketName"] = bucket.Id,
 };
 });

 _stack = await LocalWorkspace.CreateOrSelectStackAsync(new InlineProgramArgs(
 projectName: "bucket-test",
 stackName: "integration-test",
 program: program
 ));

 await _stack.SetConfigAsync("aws:region", new ConfigValue("us-west-2"));
 _upResult = await _stack.UpAsync(new UpOptions { OnStandardOutput = Console.WriteLine });
 }

 public async Task DisposeAsync()
 {
 await _stack.DestroyAsync(new DestroyOptions { OnStandardOutput = Console.WriteLine });
 await _stack.Workspace.RemoveStackAsync("integration-test");
 }

 [Fact]
 public void BucketNameHasExpectedPrefix()
 {
 var name = _upResult.Outputs["bucketName"].Value.ToString();
 Assert.StartsWith("test-bucket", name);
 }
}

Run with: dotnet test

// IntegrationTest.java
package myproject;

import com.pulumi.Context;
import com.pulumi.automation.LocalWorkspace;
import com.pulumi.automation.UpOptions;
import com.pulumi.automation.DestroyOptions;
import com.pulumi.automation.ConfigValue;
import com.pulumi.automation.WorkspaceStack;
import org.junit.jupiter.api.*;
import java.util.Map;
import static org.junit.jupiter.api.Assertions.*;

@TestInstance(TestInstance.Lifecycle.PER_CLASS)
class IntegrationTest {

 private static final String PROJECT_NAME = "bucket_test_project";
 private static final String STACK_NAME = "integration-test";

 private WorkspaceStack stack;
 private Map<String, com.pulumi.automation.OutputValue> outputs;

 @BeforeAll
 void setUp() throws Exception {
 stack = LocalWorkspace.createOrSelectStack(PROJECT_NAME, STACK_NAME, (Context ctx) -> {
 var bucket = new com.pulumi.aws.s3.Bucket("test-bucket",
 com.pulumi.aws.s3.BucketArgs.builder()
 .tags(Map.of("Environment", "test", "ManagedBy", "pulumi"))
 .build());
 ctx.export("bucketName", bucket.id());
 });

 stack.workspace().installPlugin("aws", "v7.34.0");
 stack.setConfig("aws:region", new ConfigValue("us-west-2"));

 var upResult = stack.up(UpOptions.builder().onStandardOutput(System.out::println).build());
 outputs = upResult.outputs();
 }

 @AfterAll
 void tearDown() throws Exception {
 if (stack != null) {
 stack.destroy(DestroyOptions.builder().onStandardOutput(System.out::println).build());
 stack.workspace().removeStack(STACK_NAME);
 }
 }

 @Test
 void bucketNameHasExpectedPrefix() {
 var name = (String) outputs.get("bucketName").value();
 assertTrue(name.startsWith("test-bucket"), "Unexpected bucket name: " + name);
 }
}

Run with: mvn test

Using the Go integration framework

If you prefer Go-based integration tests, Pulumi ships a purpose-built Go test framework at github.com/pulumi/pulumi/pkg/v3/testing/integration. It handles the full create → validate → destroy lifecycle for any Pulumi program (written in any language), with an ExtraRuntimeValidation hook for assertions against deployed state.

func TestS3Website(t *testing.T) {
 integration.ProgramTest(t, &integration.ProgramTestOptions{
 Dir: path.Join("..", "my-s3-website"),
 Config: map[string]string{"aws:region": "us-west-2"},
 ExtraRuntimeValidation: func(t *testing.T, stack integration.RuntimeValidationStackInfo) {
 url := stack.Outputs["websiteUrl"].(string)
 resp, _ := http.Get("http://" + url)
 assert.Equal(t, 200, resp.StatusCode)
 },
 })
}

Best practice: Always destroy test stacks in a finally block or test teardown fixture. Leaked integration test stacks are a common cause of unexpected cloud spend.

How does policy as code complement IaC testing?

Unit and integration tests validate what your infrastructure does. Policy as code enforces what your infrastructure must conform to—security standards, tagging conventions, compliance requirements—and it runs automatically on every pulumi preview and pulumi up.

Pulumi Policies are currently supported in Python and TypeScript. You write policies in the same language as the rest of your stack, without learning a DSL. A mandatory policy blocks a deployment entirely when violated; an advisory policy surfaces a warning but allows the deploy to proceed.

# __main__.py in your policy pack directory
from pulumi_policy import (
 EnforcementLevel,
 PolicyPack,
 ReportViolation,
 ResourceValidationArgs,
 ResourceValidationPolicy,
)

REQUIRED_TAGS = {"Name", "Environment", "Owner"}

def require_tags(args: ResourceValidationArgs, report_violation: ReportViolation):
 if args.resource_type.startswith("aws:"):
 tags = args.props.get("tags") or {}
 missing = REQUIRED_TAGS - set(tags.keys())
 if missing:
 report_violation(
 f"Resource is missing required tags: {', '.join(sorted(missing))}"
 )

def no_public_s3(args: ResourceValidationArgs, report_violation: ReportViolation):
 if args.resource_type == "aws:s3/bucket:Bucket":
 if args.props.get("acl") in ("public-read", "public-read-write"):
 report_violation("S3 buckets must not have a public ACL.")

PolicyPack(
 name="aws-security-baseline",
 policies=[
 ResourceValidationPolicy(
 name="require-tags",
 description="All AWS resources must have Name, Environment, and Owner tags.",
 enforcement_level=EnforcementLevel.MANDATORY,
 validate=require_tags,
 ),
 ResourceValidationPolicy(
 name="no-public-s3",
 description="S3 buckets must not be publicly accessible via ACL.",
 enforcement_level=EnforcementLevel.MANDATORY,
 validate=no_public_s3,
 ),
 ],
)

// index.ts in your policy pack directory
import * as aws from "@pulumi/aws";
import { PolicyPack, validateResourceOfType } from "@pulumi/policy";

new PolicyPack("aws-security-baseline", {
 policies: [
 {
 name: "require-tags",
 description: "All EC2 instances must have Name, Environment, and Owner tags.",
 enforcementLevel: "mandatory",
 validateResource: validateResourceOfType(aws.ec2.Instance, (instance, args, reportViolation) => {
 const required = ["Name", "Environment", "Owner"];
 const tags = instance.tags || {};
 for (const tag of required) {
 if (!tags[tag]) {
 reportViolation(`Missing required tag: ${tag}`);
 }
 }
 }),
 },
 {
 name: "no-public-s3",
 description: "S3 buckets must not have a public ACL.",
 enforcementLevel: "mandatory",
 validateResource: validateResourceOfType(aws.s3.Bucket, (bucket, args, reportViolation) => {
 if (bucket.acl === "public-read" || bucket.acl === "public-read-write") {
 reportViolation("S3 bucket must not have a public ACL.");
 }
 }),
 },
 ],
});

Running a policy pack

# Scaffold a new policy pack from a template
mkdir my-policies && cd my-policies
pulumi policy new aws-typescript

# Run policy checks against a stack
pulumi preview --policy-pack ./my-policies
pulumi up --policy-pack ./my-policies

# Or publish to Pulumi Cloud and enforce organization-wide
pulumi policy publish

As Joe Duffy, Pulumi CEO, puts it: “The smartest agent in the world still needs guardrails, audit trails, and policy enforcement to be trusted with production systems at scale.”

Policy checks complement unit tests: unit tests verify your intent (“I wrote tags into this resource”), while policies enforce your standards (“all resources must have these tags, regardless of what any one developer intended”). For complex compliance environments, publish policies to Pulumi Cloud and assign them via policy groups to enforce them across the stacks or accounts you choose—including organization-wide.

How is testing IaC in Pulumi different from Terraform?

The fundamental difference is language cohesion. With Pulumi, you write infrastructure, tests, and policies all in the same general-purpose language. With Terraform, your infrastructure is HCL but your tests must be something else—either Go (Terratest) or a constrained HCL DSL (terraform test).

	Pulumi	Terratest	`terraform test` (≥ 1.6)
Language for tests	Same language as infra (Python, TypeScript, Go, C#, Java); YAML programs tested via Automation API from any of those languages	Always Go (regardless of infra language)	HCL DSL (`.tftest.hcl`)
Unit tests with mocks	Yes — `pulumi.runtime.set_mocks()`, no cloud credentials needed	No — no mock layer for cloud providers	Limited — `mock_provider` (v1.7+) is HCL-declarative, no programmatic logic
Integration testing	Automation API (any language) or Go framework	Full-featured but Go-only	Yes, via `command = apply` run blocks
Policy / guardrails	Pulumi Policies: Python or TypeScript, runs at preview time	External tools (checkov, tfsec, OPA/Rego — separate toolchain)	Sentinel (enterprise) or external
Execution speed	Unit: milliseconds; integration: depends on cloud	Minutes (real deployments by default)	Plan-only: fast; apply: minutes
Learning curve	Use existing language skills and test frameworks	Requires Go knowledge and understanding of `go test`	Low if you know HCL; limited expressiveness

Terratest is battle-tested and widely adopted, particularly for Terraform module testing. It offers deep integrations with AWS, GCP, Azure, and Kubernetes. Its limitation is that it has no mock layer for cloud providers, so most test suites deploy real infrastructure, which makes them slower and costlier to run on every commit.

terraform test has improved significantly in Terraform 1.6 and 1.7. The command = plan mode avoids real deployments, and mock_provider enables basic unit-like testing. But expressiveness is bounded by HCL’s declarative model—no general-purpose programming, no third-party assertion libraries, and a fixed set of run/assert test constructs.

With Pulumi, there’s no context switch. The same developer who writes the infrastructure writes the tests in the same language, using the same IDE, the same debugger, and the same CI pipeline. That cohesion is a productivity multiplier.

How to set up IaC testing with Pulumi

Follow these steps to add a complete test suite to a Pulumi project. The examples use Python, but the pattern is identical in TypeScript, Go, C#, or Java.

Step 1: Install Pulumi and choose a language SDK

# Install Pulumi CLI
curl -fsSL https://get.pulumi.com | sh

# Create a new project (or use an existing one)
pulumi new aws-python --name my-project --stack dev

Step 2: Add a test framework

# Python
pip install pytest pytest-asyncio

# TypeScript
npm install --save-dev mocha ts-node @types/mocha chai @types/chai

# Go uses the built-in testing package — no additional dependencies

Step 3: Implement the Mocks class

Create mocks.py (or equivalent) with your Mocks subclass. Keep it simple for unit tests: return [args.name + "_id", args.inputs] from new_resource.

Step 4: Write unit tests

Create test_infra.py in your project root. Import mocks first, then your program. Write test functions that use @pulumi.runtime.test and pulumi.Output.all(...).apply(...) to assert resource properties.

Step 5: Add integration tests

Create test_integration.py with a pytest fixture that creates a stack, calls stack.up(), yields outputs for assertions, and calls stack.destroy() in teardown. Point this at a dedicated test cloud account.

Step 6: Create a policy pack

mkdir policies && cd policies
pulumi policy new aws-python
# Edit __main__.py to add your rules

Step 7: Wire it all into CI

# .github/workflows/test.yml (GitHub Actions excerpt)
jobs:
 unit-tests:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - uses: pulumi/actions@v6
 - run: pip install -r requirements.txt
 - run: python -m pytest tests/unit/ -v

 integration-tests:
 runs-on: ubuntu-latest
 needs: unit-tests
 environment: staging
 steps:
 - uses: actions/checkout@v4
 - uses: pulumi/actions@v6
 - run: pip install -r requirements.txt
 - env:
 PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
 AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
 AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
 run: python -m pytest tests/integration/ -v --timeout=300

Frequently asked questions

What is infrastructure as code testing?

Infrastructure as code testing is the practice of writing automated checks that validate your IaC programs before they deploy to production. Just like application testing, it includes unit tests (fast, no cloud credentials, mock the provider), integration tests (real cloud deployments in ephemeral environments), and policy checks (rules that enforce compliance standards on every preview and deploy).

Can you unit test IaC without deploying to the cloud?

Yes. Pulumi’s mocking framework intercepts all cloud API calls and replaces them with in-process stubs. Unit tests run entirely in memory—no cloud credentials, no network calls, no cost. A suite of 50 unit tests runs in under a second. This is the primary reason to write unit tests: fast, free, deterministic feedback on every commit.

Do you need real cloud credentials to test Pulumi?

Only for integration tests. Unit tests use Pulumi’s mock runtime and require no cloud credentials at all. Policy checks also run without credentials at pulumi preview time. Integration tests that use the Automation API do need credentials—they deploy real resources—so they’re typically run in a CI stage with access to a dedicated test account, not on every PR.

What’s the difference between unit and integration tests for IaC?

Unit tests validate resource properties, configurations, and relationships using mocked cloud providers—they run in milliseconds with no cloud credentials. Integration tests deploy actual resources to a real cloud environment, validate runtime behavior (does the endpoint respond? does the database accept connections?), and then destroy everything. Unit tests are cheap and frequent; integration tests are slower, cost real cloud spend, and run less often.

How do you mock cloud resources in Pulumi?

Implement pulumi.runtime.Mocks (Python) or call pulumi.runtime.setMocks() (TypeScript/JavaScript) before importing your Pulumi program. The new_resource method receives every resource registration and returns a fake [id, state] pair. The call method handles data-source lookups. Set mocks with pulumi.runtime.set_mocks(MyMocks()) and then import your program—the runtime will route all resource registrations through your mock instead of making real API calls.

What test frameworks work with Pulumi?

Any language-native test framework works. For Python: pytest (recommended) or unittest. For TypeScript/JavaScript: Mocha, Jest, or Vitest. For Go: the standard testing package. For C#: NUnit or xUnit. For Java: JUnit. The @pulumi/pulumi/automation SDK and pulumi.automation module integrate naturally with all of them. YAML is Pulumi’s declarative configuration language; because it has no control flow or executable statements, you cannot write test logic in YAML itself. YAML programs are tested by pointing the Automation API from Python, TypeScript, Go, C#, or Java at the project directory and asserting on the stack outputs.

How do you test Pulumi in CI/CD?

Split your test suite into two CI stages. Stage 1 (unit tests): runs on every PR commit, no cloud credentials required, fast. Stage 2 (integration tests): runs on merge to main or on a schedule, requires cloud credentials for a dedicated test account, uses the Automation API to deploy ephemeral stacks. The Pulumi GitHub Actions integration simplifies credential injection and stack management in both stages.

Is policy as code the same as testing?

Policy as code is complementary to—but distinct from—testing. Tests validate what your program produces (resource A has property B); policies enforce what your resources must conform to (all resources must have tag X). Policies run automatically at preview time and block non-compliant deployments at deploy time. Together, they create defense in depth: tests verify intent, policies enforce standards regardless of intent.

How is Pulumi testing different from Terratest?

Terratest typically deploys real infrastructure—it has no mock layer for cloud providers—so most test runs provision actual cloud resources, incurring real cost and taking 5–30 minutes. Tests must be written in Go regardless of what language your infrastructure uses. Pulumi’s unit testing framework runs in milliseconds with no cloud credentials, uses your existing language and test runner, and provides true mock isolation. For integration testing, Pulumi’s Automation API offers a similar model to Terratest but in any language.

How do you tear down resources after integration tests?

In Python pytest, use a module-scoped fixture that yields after stack.up() and calls stack.destroy() in the teardown. In TypeScript Mocha, call stack.destroy() in an after() hook. In Go, use defer stack.Destroy(ctx, ...). Always use a try/finally pattern (or equivalent in your language) so teardown runs even when a test assertion fails. Pulumi Cloud also has built-in stack TTL and auto-destroy features for extra safety.

Where to go next

Testing IaC is not an all-or-nothing investment. Start by adding a handful of unit tests to your most critical stack—the one that manages your production VPC, your IAM roles, or your data infrastructure. Pick three to five properties that, if wrong, would cause an outage or a security incident. Write tests for those. Run them in CI. Expand from there.

When you’re ready to go deeper:

Testing overview — Pulumi’s full testing documentation
Unit testing guide — detailed mock API reference with Go and C# examples
Automation API integration testing — advanced patterns (multi-stack tests, config injection, parallel test execution)
Policy as code authoring — writing and publishing Pulumi Policies
Pulumi vs. Terraform — a full comparison of the two platforms

If you’re migrating from Terraform, the Pulumi conversion tool translates your existing HCL to Python, TypeScript, Go, C#, and more, including your test infrastructure. Your Terratest or terraform test suites can be ported to Pulumi’s native test runner—using your existing language—as part of the migration.

Get started with Pulumi for free →

Build a Governed Databricks Workspace with Pulumi

Pablo Seibelt — Thu, 25 Jun 2026 00:00:00 +0000

Platform teams responsible for Databricks often find themselves manually configuring clusters and notebooks for every new data science team. This manual overhead leads to inconsistent cluster policies, runaway costs from oversized instances, and security gaps in workspace operations. Without a standardized way to provision workspace-local resources, data platforms become a fragmented collection of bespoke environments that are impossible to govern at scale.

As Databricks usage grows across the enterprise, the lack of a governed workspace baseline becomes a major operational risk. Inconsistent policies lead to unpredictable billing and audit failures. Standardizing your Databricks environment with Pulumi ensures that every workspace starts with the correct cost controls, cluster policies, notebooks, and automated jobs, allowing your data teams to move faster without compromising governance.

What you’ll build

In this post, you will learn how to provision a governed Databricks workspace baseline using Pulumi. You will build:

Cluster policies to enforce instance types and cost controls.
Workspace notebooks to standardize workload locations.
Secret scopes and permissions to make access reviewable.
Automated jobs that run on policy-constrained compute.

By the end, you will have a reproducible workspace configuration that you can deploy to any new Databricks environment.

The Databricks management boundary

When managing Databricks with Pulumi, understand the boundary between account-level and workspace-level resources.

Account-level: Creating cloud prerequisites such as VPCs, subnets, IAM roles, and Azure resource groups uses the cloud provider for your target platform. On AWS and GCP, Databricks workspace creation and account-level identity use the Databricks provider’s account APIs, such as databricks.MwsWorkspaces; on Azure, the workspace itself is commonly managed with azure-native.
Workspace-level: Managing clusters, jobs, notebooks, permissions, and secret scopes within a specific workspace. This example uses the @pulumi/databricks provider against an Azure Databricks workspace URL, and the same workspace-resource pattern applies once your provider is configured for the target workspace.

For this tutorial, we’ll assume you have an existing Databricks workspace and want to manage the resources within it.

Configuring credentials with Pulumi ESC

Before writing code, we need to configure our credentials. Pulumi ESC (Environments, Secrets, and Configuration) manages these securely.

You can create an environment that maps Databricks credentials into Pulumi configuration for the Databricks provider:

values:
 databricks:
 host: "https://adb-123456789.0.azuredatabricks.net"
 token:
 fn::secret: databricks-token
 pulumiConfig:
 databricks:host: ${databricks.host}
 databricks:token: ${databricks.token}

Once configured, import this environment into your Pulumi stack. The Databricks provider reads configuration values such as databricks:host and databricks:token without requiring static secrets in stack config.

Defining your data infrastructure

The following Pulumi program in TypeScript sets up separate cluster policies for interactive and job compute, a governed shared cluster, a secret scope, explicit permissions, a notebook, and a scheduled job that runs on policy-constrained compute.

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

const interactivePolicy = new databricks.ClusterPolicy("interactive-fair-use", {
 name: "Interactive Fair Use Policy",
 definition: JSON.stringify({
 "dbus_per_hour": {
 "type": "range",
 "maxValue": 10,
 },
 "autotermination_minutes": {
 "type": "fixed",
 "value": 20,
 "hidden": true,
 },
 }),
});

const jobPolicy = new databricks.ClusterPolicy("job-fair-use", {
 name: "Job Fair Use Policy",
 definition: JSON.stringify({
 "dbus_per_hour": {
 "type": "range",
 "maxValue": 10,
 },
 }),
});

const sharedCluster = new databricks.Cluster("shared-cluster", {
 clusterName: "Shared Engineering Cluster",
 sparkVersion: "17.3.x-scala2.13",
 nodeTypeId: "Standard_DS3_v2",
 autoterminationMinutes: 20,
 numWorkers: 2,
 policyId: interactivePolicy.id,
});

const clusterPermissions = new databricks.Permissions("shared-cluster-permissions", {
 clusterId: sharedCluster.id,
 accessControls: [{
 groupName: "data-engineers",
 permissionLevel: "CAN_RESTART",
 }, {
 groupName: "analysts",
 permissionLevel: "CAN_ATTACH_TO",
 }],
});

const secretScope = new databricks.SecretScope("etl-secrets", {
 name: "etl-secrets",
});

const secretScopeAcl = new databricks.SecretAcl("etl-secrets-readers", {
 scope: secretScope.name,
 principal: "data-engineers",
 permission: "READ",
});

const etlNotebook = new databricks.Notebook("etl-notebook", {
 path: "/Shared/ETL/NightlyProcess",
 language: "PYTHON",
 contentBase64: Buffer.from("print('Running ETL process...')").toString("base64"),
});

const job = new databricks.Job("nightly-etl", {
 name: "Nightly ETL Job",
 tasks: [{
 taskKey: "etl-task",
 newCluster: {
 numWorkers: 2,
 sparkVersion: "17.3.x-scala2.13",
 nodeTypeId: "Standard_DS3_v2",
 policyId: jobPolicy.id,
 },
 notebookTask: {
 notebookPath: etlNotebook.path,
 },
 }],
 schedule: {
 quartzCronExpression: "0 0 2 * * ?",
 timezoneId: "UTC",
 },
});

This baseline covers the resources a platform team needs to standardize first:

Interactive cluster policy: caps DBU consumption and enforces auto-termination for shared interactive compute.
Job cluster policy: caps DBU consumption for ephemeral job compute without applying interactive auto-termination settings.
Shared cluster: gives teams a governed interactive compute target.
Secret scope and ACL: makes ETL secret access reviewable.
Cluster permissions: assigns group-level access to the shared cluster.
Notebook: stores the workload artifact in the workspace.
Job: schedules the notebook on policy-constrained compute.

Validation

After running pulumi up, you can validate your Databricks baseline:

Databricks UI: Navigate to the “Compute” section and verify that the interactive and job fair-use policies exist, with auto-termination fixed only on the interactive policy.
Cluster check: Confirm that the shared cluster references the interactive policy and uses the expected node type.
Permission check: Confirm that cluster and secret-scope permissions match the intended Databricks groups.
Notebook check: Confirm that /Shared/ETL/NightlyProcess exists in the workspace.
Job check: Go to the “Workflows” section and confirm that the “Nightly ETL Job” is scheduled and references the notebook.

Managing your Databricks workspace as code gives every team a governed, cost-aware baseline. Use Pulumi stacks to deploy the same cluster policies, permissions, secret scope, notebook, and job pattern to multiple workspaces with environment-specific configuration.

# Deploy to development
pulumi stack select dev
pulumi up

# Promote to production
pulumi stack select prod
pulumi up

This keeps production ETL jobs, cluster policies, secret scopes, and permission assignments aligned with development while still letting each stack bind to its own Databricks workspace and ESC environment.

Conclusion

Next, connect this workspace baseline to your CI/CD pipeline and promote it through Pulumi stacks so Databricks jobs, cluster policies, and permissions move through the same review path as application code. Start with the Databricks provider docs and Pulumi ESC for credential handling.

Why Choose Pulumi Over Terraform?

Pablo Seibelt — Tue, 02 Jun 2026 00:00:00 +0000

Terraform is a proven infrastructure as code tool with a large provider and module ecosystem. Many teams choose Pulumi when they want to keep that infrastructure as code model, but write and maintain infrastructure with general-purpose programming languages, familiar package managers, IDEs, testing, and software engineering patterns, while still understanding the refactoring tradeoffs in Terraform’s own module refactoring guidance.

Why choose Pulumi over Terraform? Pulumi’s language SDKs let teams define cloud infrastructure in TypeScript, Python, Go, C#, Java, or YAML while adding first-class workflows for refactoring with Pulumi aliases, secrets, protect, retainOnDelete, deleteBeforeReplace, replaceOnChanges, provider resources, Pulumi stacks, testing, and incremental migration with pulumi import. Pulumi does not remove every hard problem in cloud infrastructure, but it gives teams stronger tools for many day-to-day pain points.

Executive summary

Pulumi is often a better fit when infrastructure code needs to behave like application code: reviewed, tested, packaged, refactored, and shared across teams. The biggest advantages show up when teams need safer refactors, encrypted secret values, reusable components, clearer provider resources, and guardrails around destructive changes.

The tradeoff is important: Pulumi is still an infrastructure as code engine. Provider bugs, cloud API eventual consistency, drift, preview-time unknowns, and poorly designed abstractions still require engineering discipline. The advantage is not magic. The advantage is a stronger programming model and a more familiar developer workflow.

Need	Terraform pattern	Pulumi advantage	What still needs care
Languages and tooling	HCL plus Terraform-specific functions and expressions	Pulumi supports general-purpose languages, YAML, and now HCL natively, with the normal IDE, test, and package workflows for each	Teams still need code review and shared conventions
Refactoring	Moved blocks or state commands for resource identity changes	Pulumi aliases can map old resource identities to new ones during refactors	Aliases must model the old identity correctly
Secrets	Sensitive values can still require careful state and plan handling	Pulumi tracks secrets and encrypts secret values in state	Secrets are still available to code at runtime
Lifecycle safety	Lifecycle meta-arguments and plan review	Pulumi resource options such as protect, retainOnDelete, deleteBeforeReplace, and replaceOnChanges make intent explicit	Provider behavior and replacement semantics still matter
Environments	Workspaces or separate configurations	Pulumi stacks model environments with per-stack config, secrets, history, and outputs	Stack boundaries still need thoughtful design
Code reuse	Modules and HCL composition patterns	Pulumi components and packages use normal language abstractions	Over-abstracted components can become hard to use
Imports and migration	Import blocks, generated config, and state operations	`pulumi import` and migration tooling support gradual adoption	Imported code still needs review and cleanup
Terraform state	S3, Azure Blob, or Terraform Cloud backends	Pulumi Cloud can serve as a Terraform state backend with encrypted storage, locking, history, and RBAC, while you keep using the Terraform or OpenTofu CLI	State still needs a clean migration plan as resources move to Pulumi
Provider wiring	Provider inheritance and aliases inside modules	Explicit provider resources make multi-region and multi-account wiring visible in code review	Provider versions and bugs can still affect deployments
Testing	Validation, plan review, and external test harnesses	Pulumi programs can use normal unit and integration test frameworks	Tests complement previews, they do not replace them
Drift detection	Refresh and refresh-only plans, plus external scheduling	`pulumi refresh` reconciles state, and Pulumi Cloud adds scheduled drift detection and remediation on a configurable cadence	Detection still depends on provider behavior and a healthy state backend
Caveats	Declarative planning still has unknowns and drift	Pulumi improves the workflow around many pain points	It does not eliminate provider bugs or eventual consistency

Use programming languages and familiar tools

Terraform modules are powerful, but larger HCL codebases can require teams to maintain separate conventions for composition, validation, and reuse. Pulumi lets infrastructure teams use the features of whichever supported programming language they choose, such as classes, functions, types, loops, package managers, linters, and test frameworks.

Teams with HCL muscle memory are not left out, either. Pulumi now supports HCL natively as one of its languages, alongside Python, TypeScript, Go, C#, Java, and YAML. Part of a team can keep authoring in HCL while the project still benefits from Pulumi components, testing, and the same engine and package workflows as every other language.

For example, a platform team can wrap a standard storage pattern in a ComponentResource and share it like any other TypeScript abstraction:

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

interface WorkQueueArgs {
 visibilityTimeoutSeconds: number;
}

class WorkQueue extends pulumi.ComponentResource {
 public readonly queueUrl: pulumi.Output<string>;

 constructor(name: string, args: WorkQueueArgs, opts?: pulumi.ComponentResourceOptions) {
 super("platform:queue:WorkQueue", name, {}, opts);

 const queue = new aws.sqs.Queue(`${name}-queue`, {
 visibilityTimeoutSeconds: args.visibilityTimeoutSeconds,
 }, { parent: this });

 this.queueUrl = queue.url;
 this.registerOutputs({ queueUrl: this.queueUrl });
 }
}

const jobs = new WorkQueue("image-jobs", {
 visibilityTimeoutSeconds: 60,
});

Refactor infrastructure without surprise replacement

Renaming a resource, moving it into a component, or reorganizing a project should not automatically mean replacing production infrastructure. Pulumi aliases let you tell Pulumi how a resource used to be addressed, so refactors can preserve resource identity when the old and new resources represent the same cloud object.

const queue = new aws.sqs.Queue("app-jobs", {
 visibilityTimeoutSeconds: 60,
}, {
 aliases: [{ name: "jobs" }],
});

Aliases are not a substitute for review. They work when the old identity is modeled correctly, including details such as name, parent, type, project, and stack when those changed.

Handle secrets with encrypted configuration and secret outputs

Secrets are one of the most common places where infrastructure workflows become risky. Terraform has sensitive values and backend guidance, but teams still need to understand how plans, state, outputs, and backend access interact. Pulumi treats secrets as first-class values, encrypts them in state, and preserves secrecy as values flow through outputs.

const config = new pulumi.Config();
const dbPassword = config.requireSecret("dbPassword");

const passwordParameter = new aws.ssm.Parameter("db-password", {
 type: "SecureString",
 value: dbPassword,
});

This improves the default experience, but it’s not runtime isolation. In the TypeScript SDK, config.requireSecret("dbPassword") retrieves secret configuration, and your program can still access the decrypted value while it runs, so reviews, least privilege, and secret-provider choices still matter. If a value starts as a plain input instead of coming from requireSecret, pulumi.secret(...) can mark it as secret.

For secrets that shouldn’t live in stack config at all, Pulumi ESC (Environments, Secrets, and Configuration) centralizes them in environments that your stacks consume through config. ESC can pull secrets dynamically from external stores such as HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and 1Password, and mint short-lived OIDC credentials for AWS, Azure, and GCP. That lets you wire an environment into a Pulumi program instead of storing long-lived credentials in state.

Add safer lifecycle controls for destructive changes

Infrastructure mistakes are expensive when they replace or delete stateful resources. Pulumi gives teams explicit resource options for safety-sensitive intent, such as protect, retainOnDelete, deleteBeforeReplace, and replaceOnChanges.

const database = new aws.rds.Instance("orders-db", {
 instanceClass: "db.t4g.micro",
 allocatedStorage: 20,
 engine: "postgres",
 username: "app",
 password: dbPassword,
}, {
 protect: true,
 retainOnDelete: true,
});

These controls are guardrails, not guarantees. Provider bugs, cloud API eventual consistency, and replacement behavior still require preview review and operational judgment. replaceOnChanges applies to custom resources only, not component resources.

Model environments with stacks

Terraform workspaces can represent environments, but many teams eventually need stronger boundaries for configuration, secrets, history, and cross-environment outputs. Pulumi stacks make environment boundaries explicit and pair them with per-stack config and outputs.

const networking = new pulumi.StackReference("acme/networking/prod");
const vpcId = networking.requireOutput("vpcId");

const appSecurityGroup = new aws.ec2.SecurityGroup("app-sg", {
 vpcId,
 ingress: [{
 protocol: "tcp",
 fromPort: 443,
 toPort: 443,
 cidrBlocks: ["10.0.0.0/8"],
 }],
 egress: [{
 protocol: "-1",
 fromPort: 0,
 toPort: 0,
 cidrBlocks: ["0.0.0.0/0"],
 }],
});

Cross-stack references are cleaner than sharing an entire remote state file, but they are still dependencies. Keep stack outputs intentional and avoid turning one stack into a global variable bag.

Test infrastructure with normal language tooling

Because Pulumi programs are real programs, infrastructure testing can use familiar test runners and assertions. Teams can test component defaults, naming conventions, required tags, and policy assumptions before a deployment reaches production.

pulumi.runtime.setMocks({
 newResource: (args) => ({
 id: `${args.name}_id`,
 state: args.inputs,
 }),
 call: (args) => args.inputs,
});

Testing does not replace previews. It catches a different class of problems: broken abstractions, missing required inputs, invalid defaults, and regressions in shared components.

Wire providers explicitly

Provider configuration is another place where explicit code can reduce ambiguity. In Terraform, provider inheritance and aliases are often managed across module boundaries. In Pulumi, provider resources are normal resources that can be passed through resource options, which makes multi-region or multi-account deployments easier to follow in code review.

const west = new aws.Provider("west", {
 region: "us-west-2",
});

const east = new aws.Provider("east", {
 region: "us-east-1",
});

const primary = new aws.sqs.Queue("primary-jobs", {}, {
 provider: west,
});

const replica = new aws.sqs.Queue("replica-jobs", {}, {
 provider: east,
});

The provider object does not remove provider versioning or schema-change risk, but it makes provider wiring visible in the same language and review flow as the rest of the program.

Detect and reconcile drift

Infrastructure drifts when something changes outside your IaC tool: a hotfix in the console, another controller, or a manual break-glass change. Pulumi gives you first-class tools to find and fix it instead of leaving it to chance. pulumi refresh reconciles your state with what is actually running in the cloud, and pulumi preview --diff shows what the next update would change.

For teams that want this continuously, Pulumi Cloud adds scheduled drift detection and remediation that runs on a configurable cadence and can automatically remediate drift when it is detected. That turns finding and correcting out-of-band changes into a managed workflow rather than something a person has to remember to check.

Drift detection still depends on accurate provider behavior and a healthy state backend, so it complements review and operational discipline rather than replacing them.

Import and migrate incrementally

Teams rarely get to rebuild infrastructure from scratch. Pulumi supports incremental adoption with pulumi import, generated code, and Terraform interoperability paths. That makes it possible to start with one resource, one component, or one stack instead of forcing a big-bang migration.

Pulumi also supports interoperability paths for teams that need to bring existing Terraform assets forward over time, including Terraform provider access and migration workflows. That makes migration an engineering sequence, not an all-or-nothing rewrite.

const importedRepository = new aws.ecr.Repository("app", {
 name: "existing-app-repo",
}, {
 import: "existing-app-repo",
});

The CLI flow can also generate declarations with pulumi import. Generated code is a starting point, not a finished architecture. Review names, options, providers, secrets, and component boundaries before treating imported resources as production-ready Pulumi code.

You also don’t have to do it alone. Pulumi provides self-serve conversion tools and expert migration services, and for teams leaving HashiCorp, credits you can apply toward Pulumi to avoid paying for two tools at once, so budget and timing don’t have to block getting started.

Manage Terraform state in Pulumi Cloud

You don’t have to rewrite anything to start getting value from Pulumi. Pulumi Cloud can serve as a Terraform state backend, letting you store and manage Terraform state alongside your Pulumi stacks. Your team can keep using the Terraform or OpenTofu CLI for day-to-day operations while gaining encrypted state storage, update history, state locking, role-based access control, audit policies, and unified resource visibility through Pulumi Insights — with agentic infrastructure coding through Neo on top.

It uses Terraform’s standard remote backend, so you point the CLI at Pulumi Cloud without changing your infrastructure code:

terraform {
 backend "remote" {
 hostname = "api.pulumi.com"
 organization = "your-pulumi-org"

 workspaces {
 name = "_dev"
 }
 }
}

From there, Pulumi can also read outputs from that state, so a new Pulumi stack can consume Terraform-managed values such as VPC IDs and subnet IDs while you migrate one piece at a time. When you’re ready to bring resources fully across, pulumi import --from terraform reads a .tfstate file and generates matching declarations, and pulumi convert --from terraform translates the surrounding configuration into your chosen language.

Storing Terraform state in Pulumi Cloud keeps both tools pointed at one system of record, which is what makes a gradual, low-risk migration practical.

What Pulumi does not magically fix

Pulumi does not eliminate cloud API eventual consistency. A deployment can finish successfully while downstream reads, controllers, or other operators still see stale state for a short window. That is a property of the cloud control plane, not of the IaC tool.

Pulumi also does not eliminate provider bugs. If a provider has a schema issue, a bad default, or a flaky update path, Pulumi still has to ride that provider behavior. Drift will still happen when infrastructure changes outside Pulumi, too. The difference is that Pulumi gives you first-class tooling to detect and reconcile it, as covered in Detect and reconcile drift above — but the drift itself, and the discipline to act on it, do not disappear.

Pulumi does not eliminate preview-time unknowns either. Some values are not known until deployment, so the plan can still contain uncertainty. Bad project decomposition and side-effect-heavy deployment code remain risks too, which is why testing, clear stack boundaries, and disciplined component design still matter.

OpenTofu compatibility caveat

OpenTofu users face many of the same infrastructure-as-code concerns around state, providers, drift, secrets, lifecycle behavior, and migration planning. This post stays Terraform-focused because that is where most teams begin the Pulumi comparison, but the same Pulumi capabilities are relevant when evaluating OpenTofu alternatives or hybrid migration paths.

Pulumi can also work with Terraform provider ecosystems, including long-tail providers that may not have a native Pulumi package yet. Treat that as an interoperability path, not a promise that every Terraform or OpenTofu workflow maps one-for-one without design work.

Get started with Pulumi

If your team is evaluating infrastructure as code options, start with the workflow that creates the most leverage: write infrastructure in the language your team already uses, test shared components, protect critical resources, and migrate one stack at a time.

To go deeper, get started with Pulumi or read the Terraform migration guide.

Five Stacks Before Lunch: The Parallel Coding Playbook for Pulumi

Engin Diri — Tue, 02 Jun 2026 00:00:00 +0000

AI coding has two shapes right now. One agent in a loop, sequential work, you babysitting the chat window. Call that 2x. Most teams live here. Five agents in worktrees, parallel work, fresh-context review on every change. Call that 10x. The trick: 2x is mostly prompting, 10x is mostly plumbing.

The parallel coding playbook is a five-pattern setup for running multiple AI coding agents at the same time without them stepping on each other: an issue used as the spec, a plan/build/validate loop, parallel git worktrees, fresh-session review, and a self-healing layer. The whole thing targets application code. The interesting question, and the one I keep ending up at, is what changes when the five agents are touching infrastructure.

2x is prompting, 10x is plumbing

2x is one human, one agent, one repo, one branch. The agent writes, you review, you tell it to try again, it tries again. The bottleneck is your attention. Whatever the agent’s raw throughput, your reading speed sets the ceiling.

10x moves you out of the per-change loop and into the issue loop. You write five issues with sharp acceptance criteria, send each one to its own agent in its own worktree, and let them plan, build, and validate end-to-end. You read five PRs at lunch instead of pair-programming on one all morning.

Concurrent isolation does the work. And isolation is mostly an infrastructure problem.

The five pillars

The five pillars, in one sentence each.

Issue is the spec. The GitHub issue carries the acceptance criteria. The pull request is the artifact that gets validated. Input and output of every implementation are versioned, scoped, and reviewable on their own.
Plan, build, validate. Three stages, three artifacts. A markdown plan you can read in thirty seconds. A build that produces a diff. A validate step that checks the diff against the spec.
Parallel worktrees. Each agent runs in its own git worktree so concurrent changes never trample each other. One repo, five working trees, five branches.
Fresh-session review. A different agent, a different conversation, no shared context, reads the output and judges it. The reviewer never sees the writer’s chat. An agent reviewing its own output in the same context is theater.
Self-healing layer. When the same issue keeps coming back, fix the system that allowed it. Update the rules, the skills, the AGENTS.md. The agent gets better; the bug class disappears.

The application-code version of this playbook leans on ports, node_modules, and databases to get isolation right. The infrastructure version has a different toolbox.

What changes when the agents are touching infrastructure

Walk the pillars again, this time with a Pulumi shop in mind.

Issue is the spec. For application code, the spec describes behavior. For infrastructure, the spec is a Pulumi component contract plus a Pulumi Policies excerpt. “The resulting bucket is private, lives in eu-west-1, has SSE-KMS, and is tagged owner=team-x.” That sentence compiles to a typed component signature and three policy assertions. The agent does not get to interpret “looks right.” The acceptance criteria are deterministic, which is the whole reason this works.

Plan, build, validate. Pulumi already ships the validate step. pulumi preview produces a deterministic, machine-readable diff a second reviewer can judge without the conversation that produced it. The plan is a markdown doc the agent writes before touching code. The build is pulumi up --target against a review stack scoped to the resources the issue covers. The validate step is the preview output plus the Pulumi Policies verdict.

Parallel worktrees. Worktrees alone are not enough. Two worktrees pointing at the same Pulumi stack will fight over state on the first concurrent up. The unit of isolation for infrastructure is the stack, not the worktree. Each worktree gets its own ephemeral review stack and its own ESC environment for credentials. State branches with the work, credentials branch with the work, and the cloud account does not see five agents elbowing each other.

Fresh-session review. The hardest part of the application-code version is keeping the reviewer cold. For infrastructure, the substrate hands you the cold context. The pulumi preview JSON has no memory of the prompt that produced it. A separate agent reading it has the same starting point a human reviewer has: a diff, a stack name, a policy report. Pulumi Neo reasons over the state graph directly, so the reviewer grounds every claim in what the change actually does, not what the writer says it does. Reviewer quality still depends on how well your policies cover the stack, but the cold-context part comes built in.

Self-healing layer. Most Pulumi Policies rule messages today read like assertions. “S3 bucket has no encryption.” A self-healing layer needs them to read like instructions. “S3 bucket has no encryption. Set serverSideEncryptionConfiguration with SSE-KMS to fix.” That single rewrite is the difference between an agent flailing and an agent fixing the violation on the first try. When the same rule keeps tripping, the fix is upstream of the next pull request: in the rules, in the skills, in the policy itself.

The five catches, infra edition

Every parallelism story has a catch list. The application-code version lists port conflicts, node_modules sprawl, database conflicts, token blowouts, and PR pile-up. The infrastructure equivalents map almost one to one.

Port conflicts become stack-name collisions. Two agents naming their stack dev and racing each other into Pulumi Cloud. The fix is the same hash-the-path trick the app-code playbook uses: derive the stack name from pulumi.getProject() plus a hash of the worktree path. Resource names follow the same pattern. Collisions go away.

node_modules sprawl becomes provider plugin sprawl, mostly already solved. Three worktrees each pulling their own copy of pulumi-aws would add up fast, except Pulumi already shares plugins through a single cache at ~/.pulumi/plugins. Identical provider versions are reused across worktrees automatically. Per-worktree language SDKs (node_modules, venv) still need the usual care, but the provider layer is free.

Database conflicts become state conflicts. Two agents racing each other into pulumi up on the same stack is the same hazard as two agents writing to the same migrated database. The app-code playbook reaches for Neon branches or per-worktree SQLite files to isolate state. The infra answer is simpler: each worktree gets its own review stack. State branches with the work, by construction.

Token blowouts become cloud spend per ephemeral stack. The cost vector flips. For app code, the worry is LLM bills. For infrastructure, the worry is what your five agents just spun up in five review stacks. The mitigations are boring and they work. Use TTL stacks to tear review stacks down on a schedule. Avoid retainOnDelete on review-stack resources so the teardown actually frees them. Cap retries per spec. Watch the bill.

PR pile-up is the same problem. Five reviewed diffs are still five things waiting on the merge queue. The infra-flavored mitigations: stack-scoped reviewers (the human who owns the stack approves the change to it), the Pulumi Cloud audit log for grouping by stack and time, and auto-merge for the narrow class of changes where the preview diff is clean and every policy passes. That last one is where most of the throughput hides.

Where to start, this afternoon

Three steps, in order, on a stack with a small blast radius.

Write an AGENTS.md for the repo. Five paragraphs is enough. The component library, the stack naming convention, the policy rules, the review-stack TTL, and the one thing in this repo that bites every newcomer. Neo reads AGENTS.md natively, as do most coding agents. This file is the spec for how the agent should behave even before you write a spec for what it should build.
Cut a 24-hour review-stack TTL. Spin up a review stack on PR open, tear it down on PR close or after 24 hours, whichever comes first. This is the gate that turns “ephemeral” from a slogan into a line item that does not appear on next month’s bill.
Run three issues in parallel. Pick three open issues that touch unrelated resources. Spin up three worktrees, three review stacks, three ESC environments. Let each agent run end-to-end against its own stack. Then have a fourth agent read each preview JSON cold and produce a one-paragraph review. Read three PRs plus the reviewer’s summary at lunch.

That last step is the measurement. The first time you run it, half of the changes will fail validation. The second time, fewer. By the third time you will know whether your spec quality, your policies, and your stack hygiene are good enough to scale this to five, then ten, then to every issue tagged infra:fix.

If three issues finish cleanly, you have the substrate. If they do not, the gap is almost always in the spec or the policy rules, not the agent. Fix the spec, tighten the rule, run it again.

Five stacks before lunch

10x is five concurrent agents, working from five issues, against five stacks, behind five fresh-session reviews. The substrate is already there. Stacks isolate state. ESC isolates credentials. pulumi preview is the deterministic artifact a fresh reviewer can read cold. Pulumi Policies is the self-healing layer when you write the rule messages as instructions.

The remaining work is small and mostly wiring. Write the AGENTS.md. Cut the TTL. Pick three issues that touch unrelated resources. Read three PRs at lunch. Five stacks before the room empties out is a realistic Monday.

See how Pulumi Neo runs your stacks

Best AI Infrastructure Tools in 2026

Alex Leventer — Mon, 25 May 2026 00:00:00 +0000

“AI infrastructure tools” covers two distinct markets: infrastructure for AI (GPU clouds like CoreWeave, MLOps platforms like Weights & Biases) and AI for infrastructure (agentic platforms like Pulumi Neo that generate, deploy, and govern cloud resources for you). Most teams need tools from both categories, and picking the wrong one wastes budget and adoption goodwill.

The pressure to get this right is real. McKinsey research puts the productivity lift from generative AI in software development at 20–45%, which is great for application teams and a problem for platform teams trying to keep up with the resulting feature flow. Infrastructure investment is climbing on both fronts: more spend on the compute that trains and serves models, more spend on AI tools that manage everything else.

This guide covers both categories: the compute and MLOps stack in Part 1, and AI-powered infrastructure management in Part 2, where the more interesting product shift is happening.

AI infrastructure tools overview

Tools for building AI infrastructure

CoreWeave: GPU cloud built for AI workloads
Lambda Labs: straightforward GPU cloud for research and startups
Modal: serverless GPU compute
Weights & Biases: ML experiment tracking and model management
MLflow: open-source ML lifecycle platform
Hyperscaler AI platforms: AWS SageMaker, Google Vertex AI, Azure ML

AI-powered infrastructure management tools

Pulumi Neo: agentic AI with policy automation
Firefly AIaC: asset codification and IaC generation
env0 Cloud Compass: multi-IaC insights and analysis
Spacelift AI: run explanation and troubleshooting
Crossplane with Upbound: Kubernetes-native infrastructure
General-purpose code assistants: Copilot, Claude Code, Cursor, Gemini
AWS Application Composer: visual serverless builder

Quick picks

If you only have two minutes:

Enterprise compliance: Pulumi Neo. Executes changes (not only suggestions), ships with policy packs for CIS, HITRUST, NIST, and PCI DSS, and works with Terraform, CloudFormation, and resources created by hand.
Serious GPU compute: CoreWeave. Purpose-built for AI workloads, deep NVIDIA partnership, and prices that generally undercut the hyperscalers.
Best developer experience for ML: Modal. Decorate a Python function, get a GPU, pay by the second.
Open-source MLOps: MLflow. No vendor lock-in, runs anywhere, plays well with everything.

What is AI infrastructure?

The term covers two distinct categories that share almost no vendors.

Infrastructure for AI is the compute, storage, and orchestration that AI workloads run on. Training a large model is not a normal cloud workload: it wants thousands of GPUs talking to each other over fat, low-latency networks for weeks at a time. Inference is different again: lower latency, smarter batching, different hardware. General-purpose cloud was not designed for either case, which is why specialized GPU clouds and MLOps platforms exist.

AI-powered infrastructure management is the inverse: AI tools that manage cloud infrastructure. They generate infrastructure as code, run deployments, detect drift, and remediate policy violations. The pitch is that modern infrastructure (multi-cloud, containers, microservices, regulated workloads) has gotten too complex for humans to manage by hand and too varied for scripted automation to keep up with.

Most organizations end up needing both: somewhere to run their ML workloads, and something to keep the rest of the cloud sane.

Part 1: Tools for building AI infrastructure

These are the platforms you run AI and ML workloads on: GPU clouds for raw compute, MLOps platforms for the lifecycle around them.

CoreWeave

CoreWeave is the GPU cloud that broke out of the AI hype cycle into a real public company. They went public in 2025, signed a multi-billion-dollar capacity deal with OpenAI, and acquired Weights & Biases. Their thesis from day one was that AI workloads deserve infrastructure designed for AI workloads, not a GPU SKU bolted onto a general-purpose cloud.

License: Proprietary
Best for: Large-scale training and high-throughput inference; teams that need dedicated GPU capacity with first access to new NVIDIA hardware
Strengths: GPU infrastructure designed for AI; Kubernetes-native; direct NVIDIA partnership; handles distributed training at scale
Watch out for: Smaller global footprint than AWS/GCP/Azure; not a general-purpose cloud, so if you need RDS, S3, and a managed Kafka in the same provider, this isn’t it

Lambda Labs

Lambda has been the approachable GPU cloud for a long time. Environments come pre-configured with PyTorch and TensorFlow, and you can be running on an H100 in about as long as it takes to copy your SSH key.

License: Proprietary
Best for: Research teams, startups, and individual practitioners who want GPUs without a configuration tax
Strengths: Straightforward to start on; pre-configured deep learning environments; competitive on-demand pricing; strong learning resources
Watch out for: Smaller scale than CoreWeave or the hyperscalers; availability gets tight during demand spikes

Modal’s pitch is that you write a Python function, decorate it, and Modal handles the GPU. No capacity planning, no idle instances burning money overnight, no Dockerfile to maintain.

License: Proprietary
Best for: Variable ML workloads where reserved capacity would sit idle; data scientists who’d rather not learn Kubernetes
Strengths: Strong developer experience; serverless GPUs with automatic scaling; pay-per-second pricing; cold starts are fast for what they are
Watch out for: You give up infrastructure control. Not ideal for long training jobs that need reserved hardware or strict configuration requirements.

Weights & Biases

Weights & Biases is the de facto standard for ML experiment tracking and model management, integrated with essentially every framework and cloud you’d plausibly use. CoreWeave acquired the company in 2025, which has accelerated the joint roadmap but raised some neutrality questions for teams that prefer their tooling cloud-agnostic.

License: Proprietary with a free tier
Best for: ML teams that need shared experiment tracking, model versioning, and reporting
Strengths: Industry-leading experiment tracking and visualization; comprehensive model registry; strong team collaboration; broad integration surface
Watch out for: Costs scale quickly past the free tier; some teams self-host alternatives for data residency reasons

MLflow

MLflow is the leading open-source MLOps platform: experiment tracking, packaging, registry, and serving, with no lock-in. Originally built at Databricks, it’s now a broad open-source ecosystem with managed offerings from multiple vendors (including Databricks and the major clouds).

License: Apache 2.0
Best for: Teams that want MLOps without a vendor; or want the option to start managed and self-host later
Strengths: Open source; covers the full ML lifecycle; runs locally, on-prem, or managed; broad framework support
Watch out for: Self-hosting carries the usual operational tax; commercial alternatives have stronger collaboration UX out of the box

Hyperscaler AI platforms

The major clouds all sell end-to-end ML platforms. Each leads on the dimensions that line up with its parent cloud (Vertex for Google’s models and TPUs, SageMaker for AWS-native data pipelines, Azure ML for Microsoft-stack integration), but the wider integration with the rest of the cloud is the deciding factor.

AWS SageMaker: end-to-end ML on AWS, deeply integrated with S3 and Glue, with first-class connections to Lambda for serverless inference and to the rest of the AWS data stack. The default pick if your data already lives in AWS.
Google Vertex AI: Google’s ML stack, including TPUs for workloads that need them, plus access to Google’s foundation models. Strongest when paired with BigQuery.
Azure Machine Learning: the natural choice when the rest of your stack is Microsoft; first-party MLOps integrations across GitHub Actions, Azure DevOps, and Microsoft Fabric for downstream reporting. The right choice if you’re already an Azure shop with Microsoft compliance requirements.

The shared tradeoff: hyperscaler GPU compute typically runs 2–3x the per-hour price of specialized providers, and the platforms work best when you commit to them top to bottom. For organizations already inside one cloud, the unified billing and single support contract usually justifies the premium. For a new ML team starting from scratch, it rarely does.

Part 2: AI-powered infrastructure management tools

This is where the more interesting product shift is happening. Instead of running AI on infrastructure, these tools point AI at your infrastructure and let it do work. They’re a newer, AI-native layer on top of the broader infrastructure as code tooling landscape.

From code generation to agentic execution

Before the tool list, one distinction matters more than any feature comparison: whether the tool generates code or executes changes.

Code generation tools like GitHub Copilot suggest infrastructure code based on context. You review it, maybe edit it, run it yourself. The AI helps, but you’re still the one doing the work.

Agentic platforms generate the code and run it, with the guardrails you define. They understand your environment, handle multi-step workflows, and enforce policies on the way through. You describe the outcome; the platform makes it happen.

Capability	Code generation	Agentic execution
Generates infrastructure code	Yes	Yes
Understands infrastructure context	Limited	Deep
Executes changes	No	Yes
Handles multi-step workflows	No	Yes
Enforces policies automatically	No	Yes
Remediates drift and violations	No	Yes

Where you want to land on this spectrum is mostly a governance question, not a productivity one.

Pulumi Neo

Pulumi Neo is Pulumi’s agentic AI for infrastructure. The distinguishing claim is execution: Neo doesn’t only suggest a Terraform snippet, it figures out the right resources, generates the code, and runs the deployment inside whatever guardrails you’ve set.

License: Proprietary (Pulumi Cloud)
Best for: Platform engineering teams that want AI automation with real policy controls, especially in regulated industries

A few things that set it apart in practice:

Policy automation and compliance. Neo is integrated with Pulumi Insights and Governance, which ships pre-built policy packs for CIS benchmarks, HITRUST CSF, NIST SP 800-53, and PCI DSS. Detection and remediation run in the same loop: Neo finds a violation, generates a fix, and (subject to approvals) applies it. You can batch-remediate across stacks and accounts with prompts like “find and fix all unencrypted S3 buckets across our AWS accounts.”

Works with infrastructure you didn’t create with Pulumi. Neo’s governance applies to Pulumi-managed resources, Terraform state, CloudFormation stacks, and resources someone clicked together in the AWS console. That matters because the realistic adoption path is to point Neo at what you have, audit it, and gradually bring it under management, not to migrate everything first.

Progressive autonomy. Trust levels are configurable. Start with human approval for everything; loosen it for well-defined, low-risk operations as confidence builds; keep production and sensitive resources behind strict approvals. This is the part that tends to determine whether enterprises actually deploy agentic AI in anger, versus letting it sit as a sandbox toy.

IDE and CI/CD integration. The Pulumi MCP Server brings Neo into Cursor, Claude Code, Claude Desktop, Windsurf, and any other MCP-compatible client. The Pulumi Cloud UI is the home base for approvals, history, and remediation status. Neo also slots into CI/CD pipelines for pre-merge policy remediation.

Case studies:

Werner Enterprises reduced infrastructure provisioning time from 3 days to 4 hours using Pulumi.
Spear AI cut their Authority to Operate (ATO) timeline from an expected 1.5 years to roughly 3 months by using policy-as-code to evidence compliance controls for auditors.

Tradeoff to be honest about: Neo gets more valuable the deeper you are in the Pulumi ecosystem. If you’re running IaC, ESC, and policy packs already, Neo has a lot of context to draw on. If you’re kicking the tires, it’s still useful, but the differentiating capability (context-aware, policy-respecting agentic execution) is harder to feel.

Firefly AIaC

Firefly is an asset management platform with AI features bolted on top of a strong core. The core capability is asset codification: it discovers cloud resources you already have and generates the IaC for them.

License: Proprietary
Best for: Teams that need to codify existing cloud footprints or generate IaC from natural language

Strengths: solid asset discovery, multi-cloud coverage, natural-language IaC generation, drift detection with remediation hooks. Caveat: AI features here are supplementary to the asset management product, not the main event, and Firefly is less focused on agentic execution than on inventory and policy.

env0 Cloud Compass

env0’s Cloud Compass adds AI to env0’s IaC automation platform, focusing on analysis rather than autonomous execution.

License: Proprietary
Best for: Multi-IaC shops that want AI-generated PR summaries, drift explanations, and cost insights

Strengths: multi-tool support across Terraform, OpenTofu, Pulumi, and Terragrunt; AI-generated PR summaries; drift cause analysis; cost estimation. Caveat: this is analysis and explanation, not action: Cloud Compass complements an agentic tool rather than replacing one.

Spacelift AI

Spacelift’s AI work is focused on the post-run experience: explaining what happened in a deployment and helping troubleshoot failures.

License: Proprietary
Best for: GitOps shops that want AI assistance reading complex runs and diagnosing failed deployments

Strengths: AI-powered run explanation; troubleshooting guidance for failures; broad IaC tool support; mature CI/CD integration. Caveat: like Spacelift as a whole, this is observation and explanation, not generation or execution. Pair with something that writes the code.

Crossplane with Upbound

Crossplane brings Kubernetes-style declarative management to cloud resources. Upbound is the company that commercializes it, and is layering AI-native control-plane capabilities into the 2.0 generation.

License: Apache 2.0 (Crossplane); proprietary (Upbound)
Best for: Teams already deep in Kubernetes that want to manage cloud resources the same way

Strengths: Kubernetes-native model; native GitOps fit; very active OSS community; AI control-plane work emerging from Upbound. Caveat: the learning curve is real if you’re not already living in Kubernetes; the commercial AI features are still maturing.

General-purpose code assistants

General-purpose AI coding assistants are the tools your developers already have open: GitHub Copilot, Claude Code, Cursor, and Google’s Gemini and Antigravity. They write Terraform HCL, Pulumi programs, and CloudFormation templates competently, about as well as they write anything else.

License: Proprietary (subscription), varies by tool
Best for: Developers who want broad code assistance, including infrastructure code, inside their existing editor

Strengths: excellent line-by-line code completion; broad language support; first-class editor integration; trained on huge corpora. Caveat: no infrastructure context. They don’t know what’s in your account, what your policies are, or which subnet you should pick. Treat their IaC suggestions as first-pass scaffolding, not production output.

AWS Application Composer

Application Composer is AWS’s visual builder for serverless applications. Drag services onto a canvas, get a CloudFormation template out, with AI suggestions for service configuration along the way.

License: Proprietary (AWS, included)
Best for: Teams building AWS serverless apps who prefer a visual workflow

Strengths: visual development for serverless; direct AWS integration; AI suggestions for service configuration; emits CloudFormation. Caveat: AWS-only, CloudFormation-only, and best suited to serverless rather than general infrastructure.

Comparison tables

Infrastructure for AI

Tool	Category	Key strength	Limitation	Pricing	Best for
CoreWeave	GPU cloud	Purpose-built GPU infra, NVIDIA partnership	Not a general-purpose cloud	Per-GPU-hour	Large-scale AI training
Lambda Labs	GPU cloud	Approachable, pre-configured environments	Smaller scale	Per-GPU-hour	Research teams, startups
Modal	Serverless GPU	Developer experience, pay-per-second	Less infrastructure control	Pay-per-use	Variable ML workloads
Weights & Biases	MLOps	Industry-standard experiment tracking	Costs scale quickly	Free tier + paid	ML team collaboration
MLflow	MLOps	Open source, no lock-in	Self-hosting overhead	Free (self-hosted)	Flexible ML lifecycle
AWS SageMaker	Hyperscaler	AWS ecosystem integration	Higher cost, lock-in	Per-use	AWS-native orgs
Google Vertex AI	Hyperscaler	Google models, TPU access	Lock-in	Per-use	Google Cloud users
Azure ML	Hyperscaler	Microsoft integration, enterprise features	Lock-in	Per-use	Microsoft ecosystem

AI-powered infrastructure management

Tool	Approach	Key strength	Limitation	Pricing	Best for
Pulumi Neo	Agentic AI	Execution + policy automation	Best within Pulumi ecosystem	Pulumi Cloud tiers	Enterprise platform teams
Firefly AIaC	Asset management	Asset codification, IaC generation	AI is supplementary	Proprietary	Codifying existing infra
env0 Cloud Compass	Multi-IaC platform	Multi-tool support, PR analysis	Analysis, not execution	Proprietary	Multi-IaC environments
Spacelift AI	CI/CD platform	Run explanation, troubleshooting	Observation, not action	Proprietary	GitOps workflows
Crossplane / Upbound	Kubernetes-native	K8s patterns for infra	Requires K8s expertise	Open source + commercial	Kubernetes-native teams
Code assistants	Code assistant	Broad language support, IDE	No infrastructure context	Subscription	General code assistance
AWS Composer	Visual builder	Visual serverless development	AWS- and CFN-only	Included with AWS	AWS serverless apps

How to choose

There’s no universal best tool. Five questions sort the field quickly:

Cloud strategy. Multi-cloud means tools like Pulumi Neo, Firefly, env0, or Crossplane. Single-cloud commitment means hyperscaler-native tools may integrate more deeply (AWS Composer, SageMaker, and so on).
Team expertise. Programmers gravitate to tools that use real languages (Pulumi Neo, Pulumi IaC). Kubernetes teams find Crossplane natural; everyone else finds it steep. Teams that prefer visual workflows should look at AWS Composer or env0’s UI.
Compliance. Regulated industries (healthcare, finance, government) get the most value from tools with pre-built compliance packs and audit trails. Pulumi Neo’s CIS/HITRUST/NIST/PCI packs are the most direct fit. If preventative policy enforcement matters, prefer tools that block non-compliant deployments rather than flag them after the fact.
Existing footprint. Greenfield projects can use anything. Brownfield is where it gets interesting: Pulumi Neo works against Terraform, CloudFormation, and manually-created resources, which lets you adopt incrementally instead of migrating first. Mixed-IaC shops should also look at env0.
Budget. Open source first: MLflow for MLOps, Crossplane for Kubernetes-native infra. Open source is not free, though: self-hosting carries a real total cost of ownership in hosting, maintenance, and the expertise to operate it. Commercial tools (Pulumi Cloud, env0, Spacelift) fold that operational cost into the price, on top of support, SLAs, and the enterprise-tier features open source can lack.

Before adopting anything, get visibility into what you have today, pilot on staging where mistakes are cheap, and define success metrics up front: time to provision, policy violation rates, mean time to remediate. The best AI infrastructure tool is the one your team will actually use, which means meeting developers where they already work.

Key trends and outlook

From copilots to agents. “AI suggests code” and “AI runs the deploy” are different products with different governance implications. The teams getting value from agentic tools have figured out which tasks to delegate fully, which to keep human-in-the-loop, and which to leave alone.

Progressive autonomy. Enterprise adoption follows a predictable shape: visibility → recommendations → human-approved execution → autonomous execution for well-understood scenarios. Tools that support that graduation will see stronger enterprise traction than tools that force an all-or-nothing choice.

Policy as the control plane. As AI takes on more infrastructure tasks, policy frameworks become the primary control plane. Done well, policy becomes an enabler (guardrails that let you safely expand automation) rather than a brake on velocity.

MCP standardization. The Model Context Protocol is becoming the integration standard between AI assistants and infrastructure tools. The practical upshot is that the IDE is increasingly a viable surface for managing infrastructure, with AI mediating between natural language and the underlying APIs.

Consolidation. CoreWeave acquiring Weights & Biases and NVIDIA acquiring Run:ai both point toward integrated platforms across the AI infrastructure stack. For tool selection today, that’s an argument for picking vendors with clear strategic direction over point solutions likely to be acquired or out-competed.

Frequently asked questions

What is the best AI agent for cloud infrastructure management?

For enterprise governance plus true agentic capability, Pulumi Neo is currently the most complete offering: it executes changes (not just suggests them), integrates with pre-built compliance frameworks, and works with infrastructure regardless of how it was provisioned. For Kubernetes-native shops, Crossplane with Upbound’s emerging AI features is worth tracking.

How can I use generative AI to manage cloud infrastructure?

Start by identifying the repetitive, time-consuming infrastructure work in your team. The highest-value early use cases tend to be:

Code generation: write IaC from natural-language descriptions, then review.
Documentation: explain unfamiliar configurations and reduce onboarding time.
Troubleshooting: analyze logs, errors, and configs to suggest likely causes.
Security and compliance: scan for violations and generate fixes.
Full automation: for shops that want it, agentic platforms like Pulumi Neo execute provisioning workflows end-to-end with governance controls intact.

What is agentic AI for infrastructure?

Agentic AI for infrastructure means AI systems that autonomously execute infrastructure tasks, not just generate code suggestions. The difference from a code assistant is action: an agent understands your environment, respects your policies, and performs multi-step work (provisioning, configuration, security controls) within the boundaries you’ve defined.

How do AI agents improve DevOps workflows?

By automating the repetitive parts (provisioning, drift remediation, policy enforcement), reducing context-switching, and catching issues earlier. Teams that have rolled out agentic tools well report faster provisioning, fewer policy violations slipping into production, and quicker compliance remediation. The compounding effect (engineers freed for higher-value work as the agent absorbs the routine) is the actual point.

What’s the difference between AI code generation and agentic execution?

Code generation suggests IaC for a human to review and run. Agentic execution generates the code and runs it, with policy and governance enforced along the way. It’s the difference between a knowledgeable colleague who suggests an approach and a knowledgeable colleague who also ships the change with appropriate oversight.

Can AI generate Terraform or Pulumi programs?

Yes. Most general-purpose AI assistants (Copilot, Claude, Gemini, ChatGPT, Cursor) can produce Terraform HCL, Pulumi programs in TypeScript / Python / Go, and CloudFormation. Quality varies. Generic assistants lack environment context and will happily emit syntactically correct but operationally wrong code. Infrastructure-specific tools like Pulumi Neo generate code that’s aware of your existing resources, policies, and provider constraints.

Can AI help with infrastructure compliance and policy automation?

Yes, and this is one of the highest-leverage uses of AI in infrastructure. Tools like Pulumi Neo detect policy violations across your footprint (including resources created outside IaC), generate compliant remediation, and apply it with the approvals you require. Pre-built frameworks for CIS, HITRUST, NIST, and PCI DSS shorten what would otherwise be a long manual compliance project.

Are AI infrastructure tools secure for enterprise use?

Enterprise-grade ones are. Look for RBAC, full audit logging of AI actions, preventative policy enforcement (not just detection), and human-in-the-loop approvals for sensitive operations. SOC 2, data residency options, and configurable autonomy levels are table stakes. The risk to avoid is wiring a consumer AI assistant directly into a production cloud account without those controls.

How do I choose between different AI infrastructure tools?

Match the tool to your context: existing clouds and IaC, team skills, compliance requirements, budget. Enterprise platform teams with governance needs should evaluate Pulumi Neo first. MLOps-focused teams should look at Weights & Biases or MLflow. For general code assistance inside the editor, a general-purpose assistant like Copilot, Cursor, or Gemini is the default. Most organizations end up with more than one: a code assistant for daily development and an agentic platform for production infrastructure.

What are the best tools for machine learning infrastructure?

For GPU compute, CoreWeave leads at scale, Modal wins for variable workloads and developer experience, and the hyperscalers are the default pick if you’re already inside one of them. For experiment tracking and model management, Weights & Biases is the leading commercial platform; MLflow is the leading open-source one. Most teams pick on the deploy model and pricing fit rather than capability gap. For the cloud infrastructure underneath the ML workloads, the same infrastructure management story applies: Pulumi Neo can provision and govern ML infrastructure the same way it handles everything else.

Conclusion

Two categories, two problems. GPU clouds and MLOps platforms (CoreWeave, Lambda, Modal, hyperscaler trio, W&B, MLflow) solve the compute and lifecycle problem for running AI workloads. AI-powered infrastructure tools (Neo, Firefly, env0, Spacelift, Crossplane, code assistants, Composer) solve the management problem for everything else.

For GPU workloads, the choice mostly comes down to scale and where you already are. For infrastructure management, the real question is how much you actually want AI to do. Code assistants help you write IaC faster, but you’re still running it. Agentic platforms like Pulumi Neo execute changes and enforce policy on the way through, with the guardrails you control.

The pattern from teams getting real value: treat AI as a force multiplier on routine work (provisioning, drift, compliance) and keep human judgment in the loop for the architecture and the edge cases.

If you want to see agentic infrastructure management running against real resources, start with Pulumi Neo.

Seven Rules for Building an AI-Native Software Factory

Ewan Dawson — Thu, 21 May 2026 06:00:00 -0700

Ewan Dawson is CTO of Compostable AI, where five engineers run an AI-native software factory: nineteen clients, custom AWS deployments, most of them shipped within a day of contract signing. This article is adapted from his recent Pulumi webinar, and covers rules in more depth than we had time for on stage.

For the past twenty years, I’ve viewed software development as a craft. The best engineers drew on decades of experience to get every function right.

But two years into the agentic AI revolution, I realised software is going to look more like a factory than a craft. The economics have changed. We can’t treat code as bespoke anymore. To scale, we have to think industrial — use the tools to ship more value with fewer engineers.

I joined Compostable AI soon after it was founded 2.5 years ago, and I built the engineering org AI-native from day one. The technology has come a long way since then, and so has my understanding of what AI-native actually means. Here are seven rules I keep coming back to.

An AI software factory is a software operation where autonomous agents write and ship most of the code. The engineers stop writing it by hand and spend their time deciding what gets built and talking to customers. The rules below are our rules for building and running an AI-native software factory.

1. Transform, don’t enhance

Going AI-native isn’t an upgrade to your existing process. If you treat AI as a way to hand your developers smarter tools, you leave most of the value on the table. You get the leverage by rebuilding how you write software — and the culture and processes around it.

I know that’s a tall order for a large, mature engineering org. My advice: start small. Pick one team or one business area and run it as a fully AI-native function. Take what you learn and roll it out from there. And do the political work early, especially with your Governance, Risk, and Compliance function. Get GRC on your side early. Otherwise AI becomes a compliance fight instead of a structural advantage.

Don’t bolt AI onto your existing workflow. Redesign the workflow around what agents can do.

Most of the leverage in this technology comes from rebuilding around it. The tool change is the small part.

2. Remove the problem, don’t solve it

Going AI-native flips which problems are hard and which are easy. The right move often isn’t to engineer a solution. It’s to reframe the problem so it goes away.

Here’s an example. Serving multiple clients with agents writing the code, blast radius wasn’t a hypothetical. One bad agent run could trash a customer’s database, or leak one client’s data into another’s. Our instinct was to build a secure multi-tenant sandbox with guardrails, approvals, rollback. But every version we tried still had agents loose in a shared environment, one bug away from making one customer’s data visible to another’s. So we removed the problem: every client gets two dedicated AWS accounts, one for production and one “digital twin” staging account. Agents iterate on staging until the work checks out. Only then does it ship to production. We have nineteen accounts now, one per client.

Managing nineteen AWS accounts with five engineers used to be an administrative nightmare. When code is cheap, infrastructure-as-code tools like AWS Control Tower and Pulumi make it the easier path.

Remove the problem before you try to solve it.

It’s cheaper to reframe the problem than to engineer your way through it.

3. Pick tools your agents can drive

Removing problems is the process side. The other side is tooling. If you want an automated factory, your tech stack has to be something agents can drive. This overlaps a lot with tools that have great developer experience. If a tool has a robust API plus a clean CLI, agents can drive it. If it’s heavy click-ops around a web UI, agents stop there.

We didn’t get there first try. Our first IaC tool worked fine when we had a couple of clients. As we added more, accounts drifted, deployments slowed, retries got complicated. We needed something built for where we were heading.

I went looking, and Pulumi fit. We express infrastructure as type-safe code — TypeScript, in our case, rather than HCL — and agents are good at writing it. Pair that with Pulumi Neo — pre-loaded with domain-specific Pulumi skills — and we ship infrastructure that follows best practices. One of my colleagues put it: “The scary thing about Neo is it just seems to know everything about what we do.” Pulumi IaC plus Pulumi ESC for configuration beats stitching tools together. And TypeScript lets us build higher-level abstractions that keep the AWS account fleet tractable.

“I don’t actually care if it’s HCL or TypeScript, as long as my software development agents can write it. And they do a better job with TypeScript than HCL.”

Tools have to share your AI-native mindset. If they don’t integrate deeply, the human becomes the glue.

If part of your stack still requires a human to click through a web UI to provision an account, your agents stop there.

4. Don’t let one agent do everything

When I first started with agents, I reached for a god prompt: one massive system prompt meant to guide a single agent through the whole software lifecycle. It didn’t work. Agents struggle when you give them multiple goals. The writer is lenient on its own work — it won’t catch what it just shipped. You don’t want it reviewing the code, checking for security flaws, or hunting bugs.

We get better results from a constellation of specialized agents, each handling one part of the line. Pulumi Neo handles infrastructure. Alongside it sit agents specialized in:

Code implementation
Code review and testing
Security auditing
Internal standards compliance
Documentation updates

Tasks pass down the line. Clean code comes out the other end, with almost no human involved.

Don’t let any agent mark its own homework. Specialize by job.

Treat agents the way you’d treat a team. The one who writes the code shouldn’t be the one signing it off.

5. Measure human hours per unit of value

Once we had agents writing and agents reviewing, throughput went up — but the bottleneck moved past the PR. Engineering hours were still the most expensive thing in the building, so my core metric is human hours per unit of value produced. Minimize that.

That means hunting for every step that still goes through a person — especially the mid-pipeline steps between ideation and production. Automate the human touchpoints along that line, and the factory runs 24/7.

Pushing automation this hard also forces good engineering. A chaotic, undocumented process is impossible to automate. Good engineering is still good engineering, AI or not. Agents won’t fix a weak process.

Measure human hours per unit of value. Treat every one as a bottleneck to remove.

You can’t automate what you can’t describe. Every human in the pipeline marks a piece that hasn’t been described yet.

6. Design for convergence, not one-shot correctness

Even with the human touchpoints removed, the agents don’t ship right the first try. Once you embrace the factory pipeline, you stop needing them to. We design for convergence instead — a system that lands on the right answer through automated iteration.

The loop we run looks like this:

Refinement: agents iterate on the Product Requirements Document until the problem is clear.
Planning: agents draft multiple technical approaches, and evaluation agents pick the best one.
Implementation: coding agents write the software.
Review: specialized checking agents look for bugs, API misuse, and security flaws.

If the checkers find a problem, they hand it back to the implementation agent. The loop repeats until the tests pass and the agents agree on a clean PR. Once it converges, we merge and deploy to staging.

Two things have to be true. You need a way to evaluate the output. Without that, you don’t know when to stop. And the loop has to converge — each pass has to get closer. A checker that fails every PR for a different reason isn’t helping — it just keeps the work going in circles. The feedback has to narrow the search, not widen it.

Once it converges, the question moves on. How cheap can we make it? Lower the time to PR, reduce token count, drop the overall cost. The optimization never really ends.

Don’t aim for one-shot correctness. Design for convergence.

It doesn’t matter how many tries it takes, as long as the loop closes without a human in it. Get convergence first. The optimization comes after.

7. Run the factory in the cloud, not on a laptop

Even a converged factory has to live somewhere. Try running a fully automated factory on individual developers’ laptops, and it falls apart. Laptops are highly trusted machines. Put autonomous agents on them and your security posture drops, fast. And the factory has to run 24/7. Events come from elsewhere — PR comments, Slack threads, errors in test environments.

Cloud also kills configuration drift across a dozen developer machines. The same prompts run against different model versions, and env vars sit half-set on half the laptops. The thing you’re trying to optimize lives in different states across the team. Cloud isn’t just where the factory runs; it’s the only place a team can iterate on it together. Keep everything in one place — AWS, Pulumi Cloud, GitHub. The specific stack matters less than the principle of one place.

And the part that matters most: the factory keeps running, testing, and deploying long after we’ve closed our laptops and gone to sleep — the dark factory pattern, where the line keeps producing with the lights off.

Build the factory somewhere you can work on it — not just somewhere it can run.

A factory scattered across laptops can’t be improved as a system. Cloud keeps it in one shape, 24/7, and lets the team iterate together.

How to build an AI-native software factory

There’s no single blueprint for how to build a software factory, but these seven rules are the software factory model we run at Compostable AI: transform the workflow rather than bolt AI onto it, remove problems instead of engineering around them, pick tools your agents can drive, split work across specialized agents, measure human hours per unit of value, design for convergence over one-shot correctness, and run the factory in the cloud so it operates 24/7.

Closing thought

I’ve shipped more code in the last two years than I did in the fifteen before that. Most of it in languages I couldn’t write by hand. And that’s after a stretch in leadership where I wrote almost none.

If you’re where I was two years ago: don’t ask how AI fits into what you already do. The factory is built one rule at a time, and it’s not a template — it’s the practice of finding where you’re taking advantage of the new economics and where you’re not, where your practices still need an update. The leverage is in finding these places and improving them.

Frequently asked questions

What is a software factory?

A software factory runs software delivery as a repeatable industrial process instead of hand-crafting each feature, the way a physical factory turns out products on a line. The idea predates AI. An AI-native software factory is the version where agents do most of the building and the engineers steer.

How is a software factory different from traditional software development?

Traditional development treats code as a craft, each function written and reviewed by hand. A software factory treats software delivery as an industrial process: agents handle the writing and checking through an automated, converging loop, and the expensive human hours move to defining the work and deciding what to build. The goal is to minimize human hours per unit of value shipped.

How do you keep AI agents from breaking things across customers?

Rather than build a shared multi-tenant sandbox, Compostable AI removes the problem: every client gets two dedicated AWS accounts, one for production and a “digital twin” staging account. Agents iterate on staging until the work checks out, and only then does it ship to production. Infrastructure-as-code tools like AWS Control Tower and Pulumi make running that account fleet tractable for a small team.

What tools does an AI-native software factory need?

Tools your agents can actually drive, anything with a solid API and a clean CLI, rather than click-ops around a web UI. Compostable AI expresses infrastructure as type-safe TypeScript with Pulumi, pairs it with Pulumi Neo for domain-specific infrastructure skills, and uses Pulumi ESC for configuration. If part of your stack still requires a human to click through a UI, your agents stop there.

Watch the original Pulumi webinar. Read the Compostable AI case study, and learn more about Compostable AI and Pulumi Neo.

The Dark Factory Pattern for Infrastructure: Running Pulumi Lights-Out

Engin Diri — Tue, 05 May 2026 00:00:00 +0000

The original dark factory was Fanuc’s robotics plant in Oshino, Japan, where the lights are off because nobody is on the floor. Robots build robots. Parts move through the line for weeks at a time without a person walking past them.

The same pattern is now showing up in software. Three engineers at StrongDM shipped roughly 32,000 lines of production code without writing or reviewing any of it. Stripe’s “Minions” agent system merges over a thousand pull requests every week. In January, Dan Shapiro of Glowforge published a five-level autonomy ladder that landed cleanly enough to become the shorthand most people now use, and BCG put out a piece calling it the dark software factory.

Almost every public writeup so far is about application code. The harder question is what this looks like for infrastructure.

What a dark factory actually is

Shapiro’s ladder is the cleanest framing I’ve seen. He borrows it from the SAE’s self-driving levels, and it fits surprisingly well:

Level	What it is	Driving analogy
0	Spicy autocomplete	Stick shift; you do everything.
1	Coding intern (boilerplate)	Cruise control.
2	Junior developer (interactive pair)	One hand on the wheel.
3	AI writes the majority; you review every PR	Eyes still on the road.
4	Spec-driven; agent runs unattended for hours; you review later	Sleeping at the wheel, you can still wake up.
5	Dark factory; no human review of code before production	No steering wheel at all.

Most teams are at level 2 or 3. A few of the more aggressive ones are at 4. Level 5 is the experiment. Most teams won’t get there safely, and probably shouldn’t try to. The interesting design question is what has to be true for level 5 to be safe at all, and that question gets sharper when the thing being shipped is infrastructure.

A dark factory is not a coding harness. A harness is the framework an agent runs inside; the dark factory is the surrounding system that makes a harness’s output mergeable without a human reading the diff. Copilot and Cursor sit at the other end: interactive, the human stays in the loop on every keystroke. The dark factory takes the human out of the per-change loop entirely and puts them at the top, writing the spec and the acceptance criteria.

The wall between generator and validator

Strip the dark factory down to its layers and there are four of them.

flowchart LR
A[Inputs<br/>Humans] --> B[Code Generation<br/>Autonomous]
B --> C[Validation<br/>Autonomous, isolated]
C -->|pass| D[Merge & Deploy<br/>Autonomous + existing CI/CD]
C -->|fail| B
A -.->|holdout scenarios<br/>generator never sees these| C

The single most important rule is that Code Generation and Validation must be completely isolated. The generator never sees the acceptance scenarios. A separate evaluator does, and it judges the generator’s output against scenarios the generator could not have memorized.

The reason is sycophancy. LLMs are too eager to agree with their own prior turns and too willing to declare victory on something they just produced. Without isolation, the same model that wrote the change is the one telling you it’s fine. The practical concern is direct: a test stored in the same codebase as the implementation will get lazily rewritten to match the code, not the other way around. It isn’t malice; it’s the agent doing exactly what it was asked, badly. The wall is what stops that.

StrongDM’s pattern for this is holdout scenarios: plain-English BDD acceptance tests stored where the generator cannot reach them. Each scenario runs three times against an ephemeral deployment, two of three must pass, and the overall pass rate has to clear 90% before the change moves forward. If the generator fails, it gets a one-line failure message (“SQL Injection Detection failed: endpoint returned 500”), not the scenario text. It cannot game the test.

Without that wall, you don’t have a quality gate. You have theater.

Why infrastructure is the harder version

Application code factories can lean on tests, linters, and type checkers. Infrastructure adds blast radius, drift, secrets, irreversible actions, and multi-region state. A code dark factory shipping a broken UI causes a bad user experience. An infrastructure dark factory shipping a broken IAM policy ends in a postmortem.

A few things make this manageable on Pulumi specifically.

The orchestrator does not need to be invented. The Pulumi Automation API is the engine as an SDK in Python, TypeScript, Go, .NET, Java, or YAML, which is the same surface a dark factory orchestrator runs on. Credentials don’t have to be long-lived: ESC and OIDC issue short-lived ones per run, so the agent never sees a static secret.

Policy doesn’t have to be probabilistic: CrossGuard enforces deterministic rules at preview time. Execution doesn’t have to happen on a laptop: Pulumi Cloud Deployments runs pulumi up inside a governed runner with audit logs and approval rules already wired. And the reasoning layer doesn’t have to start from scratch: Pulumi Neo is grounded in your state graph and ships with three modes (Auto, Balanced, Review) that line up cleanly with Shapiro’s levels 5, 4, and 3.

That doesn’t make Pulumi a dark factory by itself. It means the parts that an application-code factory has to build from scratch are pieces a Pulumi shop already has: a credential broker, a policy engine, a governed runner, a state-aware reasoning layer, an audit trail.

And one more piece nobody talks about: pulumi preview produces a clean, deterministic validation artifact, and CrossGuard evaluates that artifact without ever seeing the conversation that produced the program. That’s the same context-free judgment the holdout pattern depends on, applied at the policy layer instead of the acceptance-test layer. For infrastructure, half the wall is already built.

The interesting work is the part that nobody ships in a box.

The interesting work

What no platform ships for you is the wall: the holdout scenarios for infrastructure, the isolated evaluator that runs them, and the agreement on which stacks are even allowed to run lights-out.

The happy-path orchestrator is small. It pulls a spec, runs preview, hands the preview to an isolated evaluator (with its own credentials and its own access to the cloud, no access to the generator’s prompt or output), and branches on the verdict. Auto mode runs up immediately. Balanced mode submits a deployment that requires approval. Review mode opens a PR for a human. Every branch records a stack version traceable in the audit log. Retries, observability, secret rotation, and the rest of the production-grade plumbing add up to real code, but the shape is small.

The wall is the part that takes a week to get right. You write five plain-English scenarios for one stack (“after pulumi up, the bucket is private, has SSE-KMS, lives in eu-west-1, and is tagged owner=team-x”) and a janky evaluator that runs preview and up against an ephemeral copy, queries the cloud, and asks a separate model whether the resulting state satisfies the scenario. Triple-run, 90% pass gate. Then you watch it for a few weeks before you let anything auto-apply.

A four-phase rollout

This is the same path the application-code factories walked, with the gates tightened.

Phase 1: better context, this afternoon

Write an AGENTS.md for your most active stack repo. Pulumi Neo reads it natively, as do most coding agents. While you’re there, look at your CrossGuard rules and rewrite the error messages as instructions. Not “S3 bucket has no encryption” but “S3 bucket has no encryption. Set serverSideEncryptionConfiguration with SSE-KMS to fix.” That single change is the difference between an agent flailing and an agent fixing the policy violation on the first try. Wire pulumi preview as a build-before-push gate so PRs don’t show up just to fail CI.

Phase 2: spec-driven with holdouts, this week

Pick one stack with a small blast radius. A review-stack lifecycle is ideal. Write five plain-English holdout scenarios for it and the janky evaluator above. Humans still approve every PR. Don’t auto-merge yet. You’re earning the data, not declaring trust.

Phase 3: take the human out of the merge

Only after the three measurable gates hold over twenty PRs (scenario pass rate above 90%, false positive rate below 5%, human override rate below 10%) flip auto-apply on for that one stack. Add a weekly drift sweep that goes through the same scenario gate as everything else.

Phase 4: lights out

Expand the auto-apply flag to every stack with strong scenario numbers. Wire your issue tracker so tickets tagged infra:fix flow through the pipeline. Mock the cloud APIs that are slow or flaky enough to make scenario evaluation expensive. At this point the orchestrator is configuration, not architecture.

What could go wrong

None of these have clean fixes. The mitigations below reduce risk; they don’t eliminate it. Any team running level 5 should expect to eat one or two of these in the first year.

The validator approves a bad change. This is the obvious one. The standard mitigation is layered: triple-run each scenario with a 2-of-3 threshold, a 90% gate over the run set, a human audit of the first fifty auto-applied changes, and your existing policies still run after the validator says yes.

The agent gets a destroy permission it shouldn’t have. There’s a class of operations that should not sit in the autonomous loop yet: dropping a database, deleting a hosted zone, rotating a root key, anything that crosses a regulated data boundary. Scope what each agent identity can do at the credential layer, require human approval for anything destructive, and start every stack at Review mode. Tag changes, security-group adjustments, and instance resizes can run autonomously today. Release-branch cuts and config promotions can probably run by next quarter. The destructive class earns its way in over months.

You need all three of those layers. Approvals without policy means anything a human approves in a hurry ships. Policy without approvals means a sufficiently clever spec eventually finds the gap. Both without a human kill switch means an incident at 3 a.m. has nobody to escalate to.

Costs blow up. Cap retries at three per spec, alert on token spend per run, and remember that StrongDM reported roughly $1,000 per day per engineer-equivalent. That’s still cheaper than a salary, but only if you put the cap in place before you find out.

Where to start

Most of what a dark factory needs already exists in any reasonably mature platform. Whatever you have for state, policy, credentials, audit, and a deployment runner is the substrate. The interesting work is not building the factory. It’s the wall: the holdout scenarios that make the gap between “the model says it’s fine” and “the system is actually fine” mean something.

For most teams, Phase 1 alone is the win. Full Level 5 may stay out of reach indefinitely, and that’s fine. The path itself forces useful work: clearer specs, named bottlenecks, the deterministic gates humans had been running in their heads.

Write an AGENTS.md and five holdout scenarios for one stack this week. That’s enough to get a real signal on whether the pattern fits your team. The rest of the path is the same problem the application-code factories have already worked through, with the gates set tighter.

Agent Sprawl Is Here. Your IaC Platform Is the Answer.

Engin Diri — Wed, 22 Apr 2026 00:00:00 +0000

Somewhere in your company right now, a developer is building an AI agent. Maybe it’s a release agent that cuts tags when tests pass. Maybe it’s a cost agent that shuts down idle EC2 overnight. It’s running, it’s in production, and there’s a decent chance the platform team doesn’t know it exists.

This isn’t a thought experiment. OutSystems just surveyed 1,900 IT leaders and the numbers are rough: 96% of enterprises run AI agents in production today, 94% say the sprawl is becoming a real security problem, and only 12% have any central way to manage it. Twelve percent. You can read the full report here.

The real question is where those agents run. Inside the platform you’ve already built, or somewhere off to the side where nobody on the platform team can see them.

The new platform tension

Platform teams have always had two jobs that pull in opposite directions. Let developers ship without waiting on a ticket. Keep the infrastructure coherent while they do. Golden paths, review stacks, a catalog of components that don’t fight each other.

Agents break the second half of that deal.

A developer with a sharp prompt can spin up an SRE agent that watches a queue, a release agent that cuts tags when the test suite goes green, or a cost agent that kills idle infra at 2 a.m. That’s useful. It’s also running on your production cloud account, using credentials you never provisioned, writing to systems you never approved, and the only audit trail is whatever the developer remembered to log. The Salesforce 2026 Connectivity Benchmark pegs the average enterprise at twelve agents today, projected to grow 67% over the next two years. Most teams aren’t ready for one, let alone twenty.

This is the same shape as every sprawl problem before it. I wrote about the last one in How Secrets Sprawl Is Slowing You Down, and the pattern keeps repeating. When something useful gets cheap, it proliferates. When it proliferates without structure, it becomes a liability.

The clock is also ticking on the compliance side. The EU AI Act’s high-risk obligations kick in on 2 August 2026. Colorado’s AI Act goes live on 30 June 2026 after last year’s delay. A folder of unreviewed agent scripts isn’t going to hold up against either of those.

Three ways to respond (only one of them works)

There are roughly three paths from here.

Do nothing. Accept the sprawl and hope nothing catches fire. This is the default, and it’s also how you end up explaining to an auditor why some finance agent moved data between three systems last Thursday and nobody remembers which prompt triggered it.

Mandate centralization. Tell developers every agent has to be registered and approved before it runs. This sounds responsible on a slide, and it falls apart inside a sprint. Developers route around friction. If the official path takes a week and the unofficial path takes an afternoon, the unofficial path wins, and you’ve just pushed the sprawl underground where you can’t see it anymore.

Make the platform the obvious path. Build the thing developers actually want to use. A place where an agent inherits the guardrails, credentials, policies, and audit trail by default, because that’s what’s on offer. Adoption becomes a side effect of shipping something good.

Option three is the only one that scales. It’s also the one where most platform teams look at their existing stack and assume they need to build a pile of new scaffolding. I don’t think they do, and the rest of this post is why.

The seven things an AI agent needs from your platform

An agent needs seven concrete things from the platform it runs on. Each one maps to a Pulumi primitive you already own.

1. A trustworthy context lake

Agents are only as good as the context they can reason over. Drop a generic LLM into your cloud account and you’ll get plausible-sounding nonsense, because the model has never seen your environment. What you actually need is a grounded source of truth: what resources exist, how they relate, which stack owns what, which version is running where.

Pulumi state is already that. Your program graph, your stack outputs, your resource metadata, all of it adds up to a structured record of what you’ve actually deployed. Pulumi Neo reasons directly over that graph, which is why it can tell you why a deployment drifted instead of guessing. I wrote the long version of that argument there. Short version: you already have the context lake. Point agents at it.

2. Pre-cleared integrations

An agent that needs to touch five systems shouldn’t need five separate credential dances. That’s where credential sprawl starts. Every agent gets a long-lived key, every key ends up in somebody’s .env, and every rotation turns into an incident.

The Pulumi surface here is the 200+ providers plus Pulumi ESC handling dynamic credentials through OIDC. An agent doesn’t ask for an AWS access key. It asks ESC for a short-lived, scoped token bound to the environment it’s allowed to operate in, and the token expires when the task ends. No static keys, no rotation pain, no awkward postmortem about how something got committed to GitHub. The ESC patterns I walked through in the Claude skills post work just as well for an autonomous agent as they do for a human developer, which is really the whole point.

3. Governed actions

There’s a real difference between “an agent can see your infrastructure” and “an agent can change your infrastructure.” The second one is where you actually need structure. Pulumi Deployments gives you that structure: defined workflows, controlled triggers, running inside your Pulumi Cloud boundary instead of whatever environment the developer happened to spin up. The Automation API lets you build higher-order orchestration on the same primitives your developers already use.

The framing I keep coming back to goes like this. An agent shouldn’t call pulumi up directly. It should submit an action to a governed pipeline that runs pulumi up on its behalf, inside an environment you control, with a log trail and the guardrails already in place. Same effect, very different threat model.

4. Deterministic policy

Real governance lives outside the prompt. “Please don’t delete production” is a wish written into a system prompt, not an enforced control. And when an agent overrides your intent to do what it thought you meant, it’s behaving exactly the way the technology was designed to behave.

Pulumi Policies is the answer the IaC community landed on years ago: policy as code, written in a real programming language, evaluated deterministically at preview and update time. Disallow production RDS deletions. Require encryption at rest. Block S3 buckets with public ACLs. An agent running through Pulumi hits those gates whether it “wants” to or not, because the gates live in the pipeline and not in the prompt. This is the pillar most teams underweight, and it’s the first one most auditors ask about.

5. An audit trail

When something goes wrong at 3 a.m. (and with enough agents running, something will), you need answers fast. What changed, who changed it, and why. Not just “which agent,” but which version of which agent, triggered by what event, authorized by which policy, touching which resources.

Pulumi Cloud’s activity log, the stack update history, and ESC audit logs already capture all of that. Every update is versioned. Every secret access is logged. Every policy evaluation is recorded. When an agent submits a change through your Pulumi pipeline, it inherits that audit surface for free. The alternative is reconstructing an incident from a mix of Slack messages, container logs, and developer memory, which is roughly the state most teams without a platform are in today.

6. A review process

Not every agent action should wait for a human. But agents do need a promotion path, the same way new platform components do. Experimental, then reviewed, then trusted, then autonomous. That’s exactly what pulumi preview, review stacks, and Deployments PR workflows already model for human contributors. An agent that wants to make a change should have to submit it the same way a junior engineer would. As a diff, with a plan, against a preview environment, until it earns the trust to skip steps.

This connects back to the pattern I laid out in Golden Paths: Infrastructure Components and Templates. Golden paths were never only for humans. They’re just paths, and agents can walk them too.

7. Human-in-the-loop approval

The last pillar is the one that keeps the other six honest. Some decisions shouldn’t be automated, full stop. Production rollbacks outside business hours. Destructive changes above a certain blast-radius threshold. Anything that touches a regulated data boundary. For those cases, you want a forced human checkpoint that the agent can’t route around.

Pulumi Deployments approvals already play that role for human changes. Pulumi Neo’s review steps add the AI-aware version: a structured plan, a diff, a named approver, and a record of what they decided and why. I walked through what this looks like in practice in Self-Verifying AI Agents. Short version: an agent that proposes is much safer than an agent that commits.

Why IaC is the natural substrate for this

Step back from the seven pillars and look at what they have in common. Context, integrations, governed actions, deterministic policy, audit, review, approval. None of those are new problems that AI agents invented. They’re the problems infrastructure-as-code has been quietly solving for a decade, for human developers.

Every meaningful agent action ends up being a change, whether that’s to infrastructure, configuration, secrets, or state. IaC is the one layer in your stack that already treats change as the unit of work. Plan, preview, apply, record. If you want governance for agents and you don’t want to build it twice, the most efficient move is to route agent changes through the same substrate your humans already use.

I made the same point from a different angle in Token Efficiency vs Cognitive Efficiency: Choosing IaC for AI Agents. An IaC platform that models your world as a graph of typed resources is a much better reasoning surface for an agent than a stack of YAML or a bash script somebody wrote on a Friday. The structure is what makes it work.

What this means for the platform engineer

There’s a narrative floating around that AI is going to make platform engineers less relevant. I haven’t seen it hold up against an actual production environment. Every stat I’ve looked at points the other way. Gartner expects 70% of enterprises to deploy agentic AI as part of IT infrastructure and operations by 2029, up from less than 5% in 2025. LangChain’s State of Agent Engineering report already has 57% of teams running agents in production today. And Gartner projects that 80% of large software engineering orgs will have a platform team by end of 2026, up from 45% in 2022. More agents means more changes, more changes means more blast radius, and more blast radius means more need for the thing platform teams are uniquely equipped to provide.

Your classic responsibilities haven’t gone anywhere either. Golden paths, service catalogs, CI/CD, on-call rotations, all of that is still yours. Agents are an additional layer that needs the same discipline. The upside is that if your platform already runs on a mature IaC surface, you’re extending a muscle you’ve been building for years instead of growing a new one.

The developer-facing side matters too. A developer building an agent needs to know what’s available to them, needs templates that work on the first try, and needs to see what teammates have already built so they don’t start from a blank page. That’s the territory the Claude skills post and IDP Strategy: Self-Service Infrastructure That Balances Autonomy With Control cover. That’s the experience layer that makes developers actually choose your platform instead of routing around it. You need both sides working at once. The governance your security team cares about, and the experience your developers will actually reach for.

Close the window

The agents your developers are shipping this week are going to outlive the experiment that started them. Some of them will become critical. At least one will cause an incident. At least one will eventually show up in an audit. All of them are going to be easier to govern if they were built on your platform from day one than if you try to wrap policy around them later.

If you want the longer view on where this is going, AI Predictions for 2026: A DevOps Engineer’s Guide is the companion piece. If you want the developer-facing version of the grounding argument, Grounded AI is what to read next.

Either way, here’s where I land. The substrate for agent governance is already running in your stack. You’ve been pointing it at human changes for years. Now point it at the agents too.

See how Pulumi Neo governs agent actions

Introducing the pulumi policy analyze Command for Existing Stacks

Fraser Waters — Fri, 03 Apr 2026 00:00:00 +0000

You can now run policy packs against your existing stack state without running your Pulumi program or making provider calls. The new pulumi policy analyze command evaluates your current infrastructure against local policy packs directly, turning policy validation into a fast, repeatable check.

Why this command matters

Policy authoring and policy updates usually involve an iteration loop:

Make a policy change.
Run a policy check.
Inspect violations or remediations.
Repeat until the policy behavior matches intent.

Before this command, that loop often depended on pulumi preview or pulumi up, which can be heavier than you need when your goal is validating policy logic against known state.

With pulumi policy analyze, you can evaluate your current stack state directly and quickly.

Basic usage

At minimum, provide a policy pack path and optionally a stack:

pulumi policy analyze \
 --policy-pack ./policy-pack \
 --stack dev

You can also pass a config file for each policy pack:

pulumi policy analyze \
 --policy-pack ./policy-pack \
 --policy-pack-config ./policy-config.dev.json \
 --stack dev

If any mandatory policy violations are found, the command exits non-zero.

If remediation policies fire, those changes are reported in output, but stack state is not modified.

Testing new policy packs as a developer

For policy pack development, this command is useful as a tight local feedback loop:

Pick a representative stack (dev, staging, or a fixture stack).
Run pulumi policy analyze against that stack after each policy change.
Use the output to verify mandatory, advisory, and remediation behavior.
Repeat before publishing the policy pack or attaching it to broader policy groups.

Two output modes are especially useful:

--diff for a concise, human-readable view while iterating locally.
--json for structured output that can be consumed in scripts and CI.

Using it in AI and agent workflows

This command is also a good primitive for AI-assisted policy workflows.

Because pulumi policy analyze can emit JSON and a clear process exit code, agents can use it for deterministic policy evaluation steps:

Propose or edit policy rules.
Run pulumi policy analyze --json against target stacks.
Parse violations and remediation signals.
Suggest policy fixes, config adjustments, or targeted infrastructure changes.
Re-run analysis until mandatory violations are resolved.

For example, an agent tasked with fixing a policy violation can run pulumi policy analyze --json to get a structured list of violations, identify which resources are non-compliant, generate targeted infrastructure changes, then re-run analysis to confirm the violations are resolved, all without triggering a full preview on each iteration. The same loop works for policy authoring: an agent can propose a new policy rule, test it against several representative stacks, and surface unintended violations before the rule is published.

This works well for automation because the command doesn’t execute your Pulumi program or make provider calls, so there are no side effects or runtime variance between runs. The JSON output and non-zero exit code on failure give agents a clear pass/fail contract to build on.

Try it out

pulumi policy analyze is available in Pulumi v3.229.0.

If you are authoring or tuning policy packs, start by running this command against a known stack in your environment. It is a quick way to validate policy behavior before rollout.

For implementation details, see the merged PR: pulumi/pulumi#22250.

Get started with policy as code

Now in Public Preview: Store Terraform State in Pulumi Cloud

Claire Gaestel — Thu, 05 Mar 2026 00:00:00 +0000

Platform engineering teams managing infrastructure across Terraform and Pulumi now have a way to unify state management without rewriting a single line of HCL. Starting today, Pulumi Cloud can serve as a Terraform state backend, letting you store and manage Terraform state alongside your Pulumi stacks. Your team continues using the Terraform or OpenTofu CLI for day-to-day operations while gaining the benefits of Pulumi Cloud: AI-powered infrastructure management with Pulumi Neo — our infrastructure agent — encrypted state storage, update history, state locking, role-based access control, audit policies, and unified resource visibility through Insights.

This feature is now available in public preview.

Why this matters

Most organizations adopting Pulumi are not starting from scratch. They have years of Terraform deployments spread across teams, and migrating everything to a new IaC tool overnight is not realistic. We have heard from customers who are excited about the power of Pulumi Cloud but have had to manage migration projects before they can fully benefit from centralized visibility and governance.

The Terraform state backend in Pulumi Cloud changes that equation. Instead of requiring a full code conversion before teams see value, you can migrate your state in minutes and immediately unlock Pulumi Cloud capabilities for your existing Terraform infrastructure — including Neo, Pulumi’s AI infrastructure agent. Once your Terraform state is in Pulumi Cloud, Neo can reason about those resources the same way it does for Pulumi IaC stacks: finding resources, troubleshooting issues, understanding dependencies, and writing infrastructure code PRs. Teams that prefer Terraform can keep using it, while platform engineers get a single AI-powered control plane across the entire infrastructure estate.

What you get

When you store Terraform state in Pulumi Cloud, your Terraform-managed resources get the following added functionality:

Agentic infrastructure with Neo. Neo, Pulumi’s AI infrastructure agent, works across your entire cloud footprint — Terraform and Pulumi IaC alike. Once your Terraform state is in Pulumi Cloud, you can ask Neo to find resources across both tools, trace dependencies that span Terraform and Pulumi stacks, troubleshoot configuration issues, and generate new infrastructure code informed by your existing resources. This means platform teams get a single AI-powered interface regardless of which IaC tool manages each piece of infrastructure.

Encrypted state with update history. State is encrypted in transit and at rest. Every change is tracked as a versioned checkpoint visible in the stack activity tab, giving you full rollback capability. This is a common concern for teams currently storing state in S3 buckets.

Automatic state locking. Pulumi Cloud prevents concurrent Terraform operations from corrupting state, without requiring you to configure DynamoDB tables or other external locking mechanisms.

Role-based access control. Control who can read or modify each stack using teams and RBAC, applying the same access policies you use for Pulumi stacks.

Unified resource visibility. View Terraform-managed resources alongside Pulumi-managed resources in Resource Search. Each Terraform resource appears in the console using a pulumi:terraform:<tf-type> naming convention, so you can search and filter using the attribute names you already know.

Audit policies. Run audit (detective) policy packs against your Terraform-managed stacks, including Pulumi’s pre-built compliance packs for CIS, PCI, and more. Pulumi Cloud performs a best-effort schema mapping from Terraform resource shapes to Pulumi provider equivalents, so existing policy packs work without modification in most cases.

Stack outputs and references. Terraform root module outputs are automatically mapped to Pulumi stack outputs, making them available via stack references and the pulumi-stacks ESC provider. This is useful for sharing foundational infrastructure like VPC IDs or DNS zones between Terraform and Pulumi stacks, and for incremental migrations where legacy infrastructure stays in Terraform while new stacks are written in Pulumi.

How it works

Pulumi Cloud implements the Terraform remote backend API. You point the Terraform CLI at Pulumi Cloud using the standard backend "remote" configuration block, and no changes to your Terraform code or workflow are required.

Each Terraform workspace maps to a Pulumi stack. The workspace name follows the convention <project>_<stack>. For example, networking_prod creates a stack named prod in the networking project.

Get started

Migration from S3, Azure Blob, GCS, local backends, or HCP Terraform (Terraform Cloud) takes minutes and is documented in the Terraform state backend guide. From S3, Azure Blob, GCS, or local state, back up your state, update your backend block to point to Pulumi Cloud, set TF_TOKEN_api_pulumi_com, and run terraform init -migrate-state. From HCP Terraform, export state manually and push it to Pulumi Cloud.

Each Terraform resource stored in Pulumi Cloud counts as a resource under management, the same as a Pulumi-managed resource. See the pricing page for details.

Store Terraform State in Pulumi Cloud

If you have questions or feedback, join us in the Pulumi Community Slack or open an issue on GitHub.

Token Efficiency vs Cognitive Efficiency: Choosing IaC for AI Agents

Engin Diri — Tue, 03 Mar 2026 00:00:00 +0000

When an AI agent writes infrastructure code, two things matter: how compact the output is (token efficiency) and how well the model actually reasons about what it’s writing (cognitive efficiency). HCL produces fewer tokens for the same resource. But does that make it the better choice when agents need to refactor, debug, and iterate? We ran a benchmark across Claude Opus 4.6 and GPT-5.2-Codex to find out.

These two goals pull in opposite directions

You might assume that the language producing fewer tokens is also the one models reason about best. Research into LLM-driven infrastructure generation suggests otherwise.

Where HCL wins on tokens

HCL is declarative and minimal. It requires no imports, no runtime constructs, and no language scaffolding. For simple infrastructure generation, HCL leads to fewer tokens and lower generation cost.

For a straightforward resource definition, HCL gets straight to the point:

resource "aws_s3_bucket" "example" {
 bucket = "my-bucket"
}

Compare that with the Pulumi TypeScript equivalent:

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

const bucket = new aws.s3.Bucket("example", {
 bucket: "my-bucket",
});

The HCL version requires fewer tokens. No import statement, no variable declaration, no constructor syntax. For single-shot generation of simple resources, that compactness matters. But the picture changes once you account for deployability and refactoring.

What the data shows

HCL’s token advantage is real for simple generation. But agents don’t just generate once. They validate, repair failures, and refactor. We built a benchmark that measures the full cycle: an open-source tool that sends identical prompts to Claude Opus 4.6 (claude-opus-4-6) and OpenAI GPT-5.2-Codex (gpt-5.2-codex), requesting both Terraform HCL and Pulumi TypeScript for the same AWS infrastructure (VPC with public and private subnets across 2 AZs, an EC2 instance with security groups for SSH and HTTP, and an RDS PostgreSQL instance with a security group allowing port 5432 only from the EC2 security group, plus all networking: internet gateway, NAT gateway, route tables, and associations). We measured token consumption, cost, and deployability across two scenarios: initial generation and refactoring into reusable components.

Methodology: Temperature 0, 5 runs per combination, randomized execution order. Each generated output goes through a three-stage validation pipeline: formatting (terraform fmt for HCL, prettier for TypeScript), static analysis (terraform validate for HCL, tsc --noEmit for TypeScript), and provider-level validation (terraform plan for HCL, pulumi preview for TypeScript). Both plan and preview check against real AWS provider schemas without creating resources, making their pass rates comparable across formats. If plan/preview fails, the benchmark feeds the error back to the model for one self-repair attempt. At temperature 0, Claude Opus 4.6 produced near-identical outputs across runs (sd=0-4 tokens). GPT-5.2-Codex showed more natural variation (sd=130-165 tokens). With 5 runs per combination the results are directional, not statistically conclusive. Costs are estimates based on published pricing as of 2026-02-22. Full methodology and reproducible code:

github.com/dirien/iac-token-benchmark

Scenario 1: Generation

HCL uses fewer tokens for generation:

Provider	Format	Output tokens (mean)	LOC (mean)	Cost (mean)	Plan/Preview pass	Repairs needed
Claude Opus 4.6	Terraform	2,007	212	$0.051	5/5	0/5
Claude Opus 4.6	Pulumi TS	2,555	200	$0.065	5/5	0/5
GPT-5.2-Codex	Terraform	1,565	110	$0.022	2/5	2/5
GPT-5.2-Codex	Pulumi TS	2,322	147	$0.033	0/5	5/5

HCL produces 21-33% fewer output tokens across both models. For simple resource generation, this translates directly to lower cost. Pulumi TypeScript uses more tokens for fewer lines of code because imports, type annotations, and constructor syntax add tokens without adding functional lines.

The Plan/Preview column tells a more complete story. Claude Opus 4.6 produced deployable code on the first pass for both formats: 5/5 for Terraform and 5/5 for Pulumi. Neither needed repairs. GPT-5.2-Codex struggled with both formats, but Terraform fared slightly better (2/5 vs 0/5).

Scenario 2: Refactoring into reusable components

We took each model’s generation output and asked it to refactor the code into a reusable module or component with parameterized environment name, instance sizes, and availability zone count.

Provider	Format	Output tokens (mean)	LOC (mean)	Cost (mean)	Plan/Preview pass
Claude Opus 4.6	Pulumi TS	2,720	218	$0.082	5/5
Claude Opus 4.6	Terraform	3,379	345	$0.095	5/5
GPT-5.2-Codex	Pulumi TS	2,477	248	$0.038	4/5
GPT-5.2-Codex	Terraform	1,356	119	$0.021	0/5

This is where the results get interesting. Opus + Pulumi refactoring used 20% fewer tokens, cost 14% less, and passed pulumi preview on every run (5/5) with zero repairs. Opus + Terraform also ended up at 5/5 for terraform plan, but it needed repair cycles to get there. The benchmark run log tells the story:

# Pulumi refactoring: runs 29-33, sequential, no gaps = zero repairs
✓ [29/40] anthropic/pulumi-ts/refactor run 1 — 2721 tokens, $0.0817
✓ [30/40] anthropic/pulumi-ts/refactor run 2 — 2721 tokens, $0.0817
✓ [31/40] anthropic/pulumi-ts/refactor run 3 — 2721 tokens, $0.0817
✓ [32/40] anthropic/pulumi-ts/refactor run 4 — 2721 tokens, $0.0817
✓ [33/40] anthropic/pulumi-ts/refactor run 5 — 2714 tokens, $0.0816

# Terraform refactoring: 34→36→38→40→42, every run skips a number = every run triggered self-repair
✓ [34/40] anthropic/terraform/refactor run 1 — 3388 tokens, $0.0956
✓ [36/40] anthropic/terraform/refactor run 2 — 3339 tokens, $0.0944
✓ [38/40] anthropic/terraform/refactor run 3 — 3390 tokens, $0.0957
✓ [40/40] anthropic/terraform/refactor run 4 — 3388 tokens, $0.0956
✓ [42/40] anthropic/terraform/refactor run 5 — 3388 tokens, $0.0956

The skipped numbers (35, 37, 39, 41) are self-repair turns where the model received terraform plan errors and regenerated the code. Each repair consumed additional tokens that do not show up in the first-generation cost but do show up in the total pipeline cost.

GPT-5.2-Codex tells a different story. Both formats needed repair on every run, but what happened after repair is what matters:

# Codex + Terraform refactoring: repaired, but still failed plan (0/5 deployable)
terraform run 1 turn 2: plan_valid=False tokens=1559
terraform run 2 turn 2: plan_valid=False tokens=1165
terraform run 3 turn 2: plan_valid=False tokens=1068
terraform run 4 turn 2: plan_valid=False tokens=1134
terraform run 5 turn 2: plan_valid=False tokens=1101

# Codex + Pulumi refactoring: repaired, and preview passed (4/5 deployable)
pulumi-ts run 1 turn 2: plan_valid=True tokens=2246
pulumi-ts run 2 turn 2: plan_valid=True tokens=2567
pulumi-ts run 3 turn 2: plan_valid=True tokens=2187
pulumi-ts run 4 turn 2: plan_valid=True tokens=2531
pulumi-ts run 5 turn 2: plan_valid=False tokens=2647

Codex + Terraform used fewer tokens but produced zero deployable refactored code after repair. Codex + Pulumi used more tokens but recovered to deployable code 4 out of 5 times. TypeScript’s type errors gave the model enough information to fix the problems. HCL’s plan errors did not.

Total pipeline cost

This is the number that matters for production agent workflows. It includes generation, any self-repair cycles, and refactoring:

Provider	Format	Total tokens (mean)	Total cost (mean)
Claude Opus 4.6	Pulumi TS	8,183	$0.146
Claude Opus 4.6	Terraform	14,669	$0.249
GPT-5.2-Codex	Terraform	8,723	$0.084
GPT-5.2-Codex	Pulumi TS	15,211	$0.138

Opus + Pulumi had the lowest total pipeline cost at $0.146, 41% cheaper than Opus + Terraform at $0.249. The difference comes entirely from repair cycles: Pulumi needed zero repairs across both scenarios, while Terraform refactoring triggered self-repair on every run.

With Codex, Terraform had the lower pipeline cost ($0.084 vs $0.138), driven by its smaller token output. But Codex + Terraform produced zero deployable refactored code (0/5 plan pass), while Codex + Pulumi produced deployable code 4 out of 5 times.

What this means

HCL uses fewer tokens per generation. For single-shot resource creation, HCL’s compactness saves 21-33% on output tokens. That advantage is consistent across both models.
Pulumi produces deployable refactored code more reliably. With Opus, Pulumi refactoring passed preview 5/5 with zero repairs. Codex + Pulumi passed 4/5. Codex + Terraform passed 0/5.
Total pipeline cost favors Pulumi with Opus. Opus + Pulumi cost 41% less than Opus + Terraform across the full pipeline ($0.146 vs $0.249), because Terraform refactoring needed repair cycles that Pulumi did not.
The tradeoff depends on your model and workflow. Codex + Terraform is cheapest on raw tokens but produces no deployable refactored code. Codex + Pulumi costs more per token but actually deploys. Opus + Pulumi is the best of both: fewer refactoring tokens and zero repairs.

Why Pulumi refactoring deploys cleaner

The TerraFormer project identified what they call the correctness-congruence gap: LLMs generate configurations that look valid but fail to match the user’s architectural intent. An error taxonomy study cataloged the same pattern across models. A survey of LLMs for IaC found the gap between syntax validity and architectural correctness widens with infrastructure complexity.

Refactoring is where this gap bites hardest. Turning a flat resource list into a parameterized, reusable module requires the model to restructure dependencies, introduce variables, and compose abstractions. With Pulumi, the model can use TypeScript’s standard refactoring patterns: extract a class, add typed constructor parameters, compose functions. These are patterns it has practiced across millions of repositories during training. With HCL, the same refactoring requires count, for_each, dynamic blocks, and module variable plumbing, domain-specific constructs that have far less representation in training data.

Our benchmark confirms this directly. Opus produced 2,720 tokens for Pulumi refactoring versus 3,379 for Terraform, a 20% reduction, and every Pulumi run passed pulumi preview without repair. The Terraform refactoring runs all triggered self-repair because the restructured HCL modules had issues that terraform plan caught.

Training data distribution makes this structural. LLMs have far more TypeScript than HCL in their corpora. A model refactoring TypeScript draws on patterns from the entire open-source ecosystem. A model refactoring HCL modules has a much smaller pool. Since general-purpose languages dominate new code production, this gap will widen over time.

Tooling can close the gap further. The Pulumi MCP server gives AI agents direct access to resource schemas at generation time. A tool like get-resource returns every property, type, and required field for a given cloud resource. The agent does not have to guess from what it memorized during training. It can look up the correct schema before writing a single line of code.

This changes the workflow from “generate, fail, read error, retry” to “look up schema, generate correctly.” Agent skills push this further by encoding working Pulumi idioms as structured prompts, so the model starts from a known-good baseline. Terraform has no equivalent to this MCP-based schema lookup. That difference matters more with every iteration.

Where the industry is heading

One way to think about IaC language choice is through the lens of AI engineering maturity levels. At Level 3 (agentic coding), agents generate infrastructure from prompts. HCL’s 21-33% token savings on generation matters here. At Levels 4-5, agents iterate on specifications, refactor code, and maintain systems over time. Our benchmark shows this is where Pulumi pulls ahead: 41% lower total pipeline cost with Opus, and more deployable refactored output with both models.

The industry is moving toward Levels 4-5. Agents are taking on refactoring, feature flags, environment parameterization. 43% of DevOps teams need four or more deployment iterations before infrastructure is production-ready. The first-generation token advantage HCL holds applies to the task that is shrinking as a share of agent workloads. The refactoring and deployability advantages that Pulumi offers apply to the tasks that are growing.

Choosing based on your workflow

If your agents primarily generate well-scoped resource definitions, HCL saves 21-33% on output tokens. That advantage is real and consistent.

If your agents need deployable output on the first pass (which avoids repair costs entirely), our data shows Opus + Pulumi is the strongest combination: 5/5 plan/preview pass for both generation and refactoring, zero repairs, lowest total pipeline cost.

If your agents evolve infrastructure over time through refactoring and modularizing, Pulumi produced deployable refactored code more reliably across both models we tested (5/5 and 4/5 vs 5/5 and 0/5 for Terraform).

Pulumi covers the full iteration loop, from generation through repair to refactoring, using the same language patterns and tooling that models already know.

Get started

Ready to explore how AI agents work with Pulumi? Check out Pulumi AI to see LLM-powered infrastructure generation in action, or get started with Pulumi’s documentation.

Join the conversation in the Pulumi Community Slack or Pulumi Community Discussions.

New in Pulumi IaC: `onError` Resource Hook

Tom Harding — Mon, 23 Feb 2026 00:00:00 +0000

You can now control what happens when a resource fails during create, update, or delete—retry with backoff, fail fast, or handle errors in custom code. Last year, Pulumi IaC introduced the resource hooks feature, allowing you to run custom code at different points in the lifecycle of resources. Today we’re adding the onError hook so you can react when operations fail.

Recovering from errors

When a Pulumi program encounters an error while creating, updating, or deleting a resource, the operation halts and the error is reported back. Sometimes that’s not what we want—errors can be intermittent or temporary. If you’ve hit transient failures or resource-not-ready errors, the onError hook can help.

A common case is resource readiness: creating resources that depend on DNS propagation or the readiness of other servers. The program can fail simply because it ran too soon. Instead of failing, we can wait and retry. The example below shows how:

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

const notStartedRetryHook = new pulumi.ErrorHook(
 "retry-when-not-started",
 async (args) => {
 const latestError = args.errors[0] ?? "";

 if (!latestError.includes("resource has not yet started")) {
 return false; // do not retry, this is another type of error
 }

 await new Promise((resolve) => setTimeout(resolve, 5000));
 return true; // retry
 },
);

const res = new MyResource("res", {}, {
 hooks: {
 onError: [notStartedRetryHook],
 },
});

import time

import pulumi


def retry_when_not_started(args: pulumi.ErrorHookArgs) -> bool:
 latest_error = args.errors[0] if args.errors else ""

 if "resource has not yet started" not in latest_error:
 return False # do not retry, this is another type of error

 time.sleep(5)
 return True # retry


not_started_retry_hook = pulumi.ErrorHook(
 "retry-when-not-started",
 retry_when_not_started,
)

res = MyResource(
 "res",
 opts=pulumi.ResourceOptions(
 hooks=pulumi.ResourceHookBinding(
 on_error=[not_started_retry_hook],
 ),
 ),
)

package main

import (
 "strings"
 "time"

 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 hook, err := ctx.RegisterErrorHook(
 "retry-when-not-started",
 func(args *pulumi.ErrorHookArgs) (bool, error) {
 latest := ""
 if len(args.Errors) > 0 {
 latest = args.Errors[0]
 }

 if !strings.Contains(latest, "resource has not yet started") {
 return false, nil // do not retry, this is another type of error
 }

 time.Sleep(5 * time.Second)
 return true, nil // retry
 },
 )
 if err != nil {
 return err
 }

 _, err = NewMyResource(ctx, "res", &MyResourceArgs{}, pulumi.ResourceHooks(&pulumi.ResourceHookBinding{
 OnError: []*pulumi.ErrorHook{hook},
 }))
 if err != nil {
 return err
 }

 return nil
 })
}

using System;
using System.Threading;
using System.Threading.Tasks;
using Pulumi;

class ErrorHookStack : Stack
{
 public ErrorHookStack()
 {
 var retryHook = new ErrorHook(
 "retry-when-not-started",
 async (args, cancellationToken) =>
 {
 var latestError = args.Errors.Count > 0 ? args.Errors[0] : "";

 if (!latestError.Contains("resource has not yet started"))
 {
 return false; // do not retry, this is another type of error
 }

 await Task.Delay(TimeSpan.FromSeconds(5), cancellationToken);
 return true; // retry
 });

 var res = new MyResource("res", new MyResourceArgs(), new CustomResourceOptions
 {
 Hooks = new ResourceHookBinding
 {
 OnError = { retryHook },
 },
 });
 }
}

Each time the operation fails, the hook receives the new error plus all previous attempts’ errors (newest first). The hook returns true or false to tell Pulumi whether to retry. If you return false, the program fails as normal with the most recent error. With that information, you can implement many failure models:

Use the number of errors to implement backoff—for example, wait one second on the first failure, two seconds on the second, and so on.
For known-intermittent resources, always retry once before failing.
Inspect error text to retry only for specific conditions (as in the example) and fail fast for others.

The callback runs in your language of choice, so you have full control over how failures are handled.

Next steps

This feature is fully supported in our Node, Python, Go, and .NET SDKs as of v3.219.0. For more information, see the hooks documentation.

Java and YAML do not support resource hooks.

Thanks for reading, and feel free to reach out with any questions via GitHub, X, or our Community Slack.

New in Pulumi IaC: `replacementTrigger` Resource Option

Tom Harding — Thu, 22 Jan 2026 00:00:00 +0000

Pulumi IaC gives us a declarative interface to updates. When we perform an update, Pulumi calculates the difference between your currently deployed infrastructure and what is being proposed, then deploys only what is required to migrate from the old state to the new state. Normally, this is exactly what we want: we minimize the amount of work required to perform the update, and don’t recreate anything unnecessarily. However, every now and then, we want to override this behavior.

Recently, we talked about the new replaceWith option, which allows us to tell Pulumi that any replacement of one resource should always trigger a replacement of another (for example, if the database is replaced, we should replace our application server). Today, we’re going to take this idea one step further and talk about another new feature that gives us even more control over this process: replacement triggers.

Forcing replacements

Let’s imagine we have a resource that, upon creation, generates some private keys. If that’s all the resource does, it probably isn’t ever going to change as far as Pulumi’s concerned: we wanted the resource before, and we want it after, so there is no change and no need to replace the resource that is already live. Now, let’s imagine that we want to cycle these private keys every month. How do we tell Pulumi that, if this update happens more than two weeks after the last time this resource was created, we want to recreate it?

As another example, perhaps we want to replace a resource every time some external version number is bumped. Let’s imagine a documentation server may need to be replaced every time a new version of an API is made available. We could use the --replace flag each time, but this process is error-prone to do manually, and would incur a maintenance burden to automate.

Defining replacement triggers

In essence, a replacement trigger is just a value attached to the resource as metadata. However, whenever this value changes between updates, it will trigger a replace operation on the given resource, regardless of whether anything else has changed.

Let’s take our previous example: we want something to be replaced every month. With replacement triggers, we can solve this by representing the current year and month as a string:

...

const today = new Date()

const keyManager = new KeyManagerResource("key-manager", {}, {
 replacementTrigger: today.getMonth() + '-' + today.getFullYear()
});

...

...
from datetime import datetime

today = datetime.now()
trigger = f"{today.month}-{today.year}"

key_manager = KeyManagerResource("key-manager", {},
 opts=pulumi.ResourceOptions(replacement_trigger=trigger))

...

...

today := time.Now()
trigger := fmt.Sprintf("%d-%d", int(today.Month()), today.Year())

keyManager, err := NewKeyManagerResource(ctx, "key-manager", &KeyManagerResourceArgs{},
 pulumi.ReplacementTrigger(pulumi.Any(trigger)))

...

...

var today = LocalDate.now();
var trigger = String.format("%d-%d", today.getMonthValue(), today.getYear())

var keyManager = new KeyManagerResource("key-manager",
 KeyManagerResourceArgs.Empty,
 CustomResourceOptions.builder()
 .replacementTrigger(Output.of(trigger))
 .build());

...

...

var today = DateTime.Now;
var trigger = $"{today.Month}-{today.Year}";

var keyManager = new KeyManagerResource("key-manager", new KeyManagerResourceArgs(),
 new CustomResourceOptions
 {
 ReplacementTrigger = Output.Create(trigger)
 });

...

When we run this update for the first time, the replacement trigger will be persisted to the Pulumi state. Each time we run an update, we’ll re-calculate the date string, and compare it against the current string. Finally, when we run the update again next month, and the date string no longer matches, our key-manager will be replaced and our new keys will be generated!

Next steps

This feature is fully supported across all our SDKs as of v3.215.0. For more information about resource options, see the resource options documentation.

Thanks for reading, and feel free to reach out with any questions via GitHub, X, or our Community Slack.

Introducing the Stash Resource in Pulumi IaC

Fraser Waters — Mon, 12 Jan 2026 00:00:00 +0000

We’re excited to announce the Stash resource, a new built-in Pulumi resource that lets you save arbitrary values directly to your stack’s state. Whether you need to capture a computed result, record who first deployed your infrastructure, or persist configuration that should remain stable across updates, Stash provides a simpler and more ergonomic solution.

Why Stash?

Infrastructure code often produces values that need to persist beyond a single deployment. Maybe you’re generating a random identifier that should stay consistent, tracking which team member initially set up a stack, or recording a timestamp from the first deployment. Previously, you’d need workarounds like external storage, custom resources, or careful state manipulation.

The Stash resource helps with that. It takes an input value, stores it in your stack’s state, and makes it available as an output property. The output property preserves the original value even when the input changes in subsequent deployments, making Stash perfect for “first-run” scenarios where you want to capture and preserve a value from the initial deployment.

Using Stash

Creating a Stash is straightforward. Here’s how you’d capture the username of whoever first deploys the stack (using Node.js):

import * as pulumi from "@pulumi/pulumi";
import * as os from "os"; // Node.js built-in module

const firstDeployer = new pulumi.Stash("firstDeployer", {
 input: os.userInfo().username,
});

export const originalDeployer = firstDeployer.output;

The first time this runs, both input and output will show the current user. On subsequent deployments by different users, input will update to show the new user, but output will continue returning the original deployer’s name.

Stash supports any value type—strings, numbers, objects, arrays, and nested structures. It also respects secret annotations, so if you stash a secret value, it stays encrypted in your state.

When to replace

Since Stash preserves the original value by design, updating the stored value requires a replacement. You have several options:

Use --target-replace during pulumi up:

pulumi up --target-replace urn:pulumi:dev::my-project::pulumi:index:Stash::firstDeployer

Run pulumi state taint to mark the resource for replacement:

pulumi state taint urn:pulumi:dev::my-project::pulumi:index:Stash::firstDeployer

Use the replacementTrigger resource option to automate replacements based on value changes:

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

const remoteConfig = fetch("https://example.com/my-service").then(response => response.json())

const myStash = new pulumi.Stash("myStash",
 {
 input: os.userInfo().username,
 }, {
 replacementTrigger: remoteConfig.someValue,
 }
);

export const stashedValue = myStash.output;

With replacementTrigger, when remoteConfig.someValue changes, the Stash resource will be replaced and the new input value will be captured.

Learn more

The Stash resource is available now in Pulumi v3.208.0 and later across all supported languages. Check out the Stash documentation for detailed examples in TypeScript, Python, Go, C#, and YAML.

We’d love to hear how you’re using Stash and any feedback you have on it! Share your use cases in our Community Slack or open an issue if you see any on pulumi/pulumi.

Happy hacking!

Pulumi for All Your IaC — Including Terraform and HCL

Joe Duffy — Thu, 18 Dec 2025 14:00:00 -0800

We work with thousands of customers who prefer Pulumi due to our modern approach to infrastructure that delivers faster time to market with built-in security and compliance. Yet we know many organizations have years of investments into tools like Terraform. At the same time, HashiCorp customers are increasingly telling us about their frustrations post-IBM acquisition: rate increases, loss of open source heritage, overnight rug-pull of CDKTF, … and the hits just keep on coming. Today, we’re excited to announce three new ways Pulumi is enabling customers of HashiCorp, an IBM Company, who want a better, open source friendly, modern solution for their IaC to choose Pulumi. First, Pulumi Cloud will support Terraform and OpenTofu, so you can continue using any Terraform or Pulumi CLI and language with the complete Pulumi Cloud product, including our infrastructure engineering AI agent, Neo. Second, Pulumi’s own open source IaC tool will support HCL natively as one of its many languages, alongside the industry’s best languages including Python, TypeScript, Go, C#, Java, and YAML. Pulumi is multi-language at its core and many organizations are diverse and polyglot—these new capabilities truly make Pulumi the most universal IaC platform with the broadest support. Third, we’re offering flexible financing to make it easy to depart HashiCorp for Pulumi.

The TL;DR

Pulumi Cloud now manages Terraform/OpenTofu with full visibility, governance, and agentic AI included. Pulumi IaC now speaks HCL alongside general purpose languages and YAML. And we’ll cover your costs until your HashiCorp contract ends.

Terraform/OpenTofu in Pulumi Cloud

Pulumi has always been two things: Pulumi IaC, the multi-language, open source infrastructure as code technology, and Pulumi Cloud, our commercial platform that includes infrastructure state management and visibility, our AI agent Neo, secrets management, policy as code, governance, and much more. You can think of it like Git (the tool) versus GitHub (the SaaS).

Historically, we required that you choose Pulumi IaC to benefit from Pulumi Cloud but over time we’ve been moving away from that, such as with our AI and governance features: you point us at any cloud accounts, and we’ll help you make sense of and tame them, regardless of how the accounts’ resources were deployed (Pulumi, CDK, Terraform, … even manual point and click). Today, we are taking that one step further and letting you run Terraform, OpenTofu, or Pulumi IaC as your tool of choice, while still benefitting from Pulumi Cloud’s full suite of capabilities.

The great thing about this is that even if you choose Terraform or OpenTofu IaC on the client, you will still benefit from all of the capabilities of our server, from AI to governance to visibility and more. Terraform statefiles and workspaces will show up effectively the same way Pulumi stacks do, and you’ll get full visibility of who is changing what and when including diffs and logs.

Why would we do such a thing? As we’ve worked with larger and larger companies in our journey to thousands of customers, we’ve seen that there’s significant Terraform out there in the world. Even if a team’s long-term objective is to migrate to 100% Pulumi – reaping the many benefits of modern IaC, like faster time to market by catering better to a polyglot world of developers, infrastructure experts, security engineers, and AI/ML teams – that transition doesn’t happen overnight. Many teams legitimately want a mix of IaC tools. Ensuring all infrastructure is fully automated, secured, and managed is a more righteous outcome to focus on rather than debating one’s choice of IaC tool or language. There are many paths you can take, and now Pulumi can be your one platform to stay on top of all of it and drive towards this outcome.

Support for Terraform/OpenTofu state is in private beta and we are beginning to work with customers directly as we get it ready for prime time. We anticipate general availability in Q1 2026.

HCL Language Support in Pulumi IaC

At Pulumi, we love our languages. We now support six – depending on how you count: Python, TypeScript, Go, any .NET language (like C#), and any JVM language (like Java itself), and even YAML. Having this broad array of languages is a massive unlock: you suddenly get access to the full ecosystem of tooling and expertise around these languages, including rich syntax (for loops, if statements, functions), IDEs, testing frameworks, true sharing and reuse, and ensuring that LLMs deeply understand your IaC. This choice of language is then married with the best of declarative IaC, so you still get the belts and suspenders safety of a desired state IaC tool.

But we work with customers all the time where some of the team is more comfortable with and/or genuinely prefers HCL. The HCL language was purpose-built for IaC through Terraform and, now, OpenTofu and is easy for simple use cases. We actually shipped YAML support two years ago because it’s an industry standard and we kept hearing about simpler use cases where you didn’t need a full blown language (especially e.g. when code-generating IaC or supporting simple developer self-service CI/CD pipelines where a handful of lines of YAML do the trick). But despite that, there’s a ton of muscle memory with HCL in the IaC community.

We are not dogmatic about languages, we love all of them. The L in HCL and YAML stands for “language” and we’ve always had a “come one, come all” mindset. As soon as we see enough market demand for a given language, we will add it. Well, that time has come for HCL.

The good news is that this is not a bolt on. Just like any of the other Pulumi languages, you have full access to the entirety of the Pulumi ecosystem, including thousands of providers. Thanks to our Terraform bridge, if there’s a Terraform provider out there, it just works. This is explicitly not meant to be a lift-and-shift migration option – we have many other techniques for that, including the new Terraform support in Pulumi Cloud – but is instead for teammates who are more comfortable with or prefer HCL over general-purpose languages, but still want to leverage the more modern Pulumi IaC engine with its advanced multi-language capabilities.

HCL support also integrates with Pulumi’s multi-language technology in a deep way, so that you can author modules in one language and consume them from another. This will let, for example, platform teams author complex components in, say, Go – with the rich facilities offered by the language – and then expose them to teammates who consume them in HCL (or vice versa!)

Similar to Terraform support in Pulumi Cloud, HCL is currently in private beta and we will work with customers directly to ensure it meets our quality standards, with a goal of general availability in Q1 2026.

Builds on Existing Coexist/Convert Capabilities

These two new technical capabilities augment an existing array of tools that make it easy for you to choose Pulumi as your IaC platform of choice, even in organizations with hybrid client-side IaC tools, and languages may be general-purpose, HCL, or a mixture thereof.

Pulumi IaC supports using any Terraform provider. Many of them are available pre-built in the Pulumi Registry, however, in the event one isn’t pre-published, you can generate one on demand using the “Any Terraform Provider”. Pulumi doesn’t use the Terraform engine, but rather it leverages the resource schemas and create, read, update, and delete methods in them.

We have numerous migration tools. The first is Neo, our infrastructure engineering agent, who has Terraform-specific skills to migrate code and state. Neo leverages a number of building blocks that you can use directly instead. That includes the pulumi convert --from terraform command which understands how to convert Terraform/OpenTofu HCL or CDKTF code into a Pulumi language of your choosing, preserving code structure including migrating modules to Pulumi components. We also support directly importing resources from your cloud accounts directly, either at the CLI or visually in Pulumi Cloud. Read more about migration here.

You can deploy Terraform modules straight off the shelf from your favorite Pulumi language. That works as well for any supported Pulumi language, including HCL, and it shows up as though the underlying module resources were managed natively in Pulumi. This ensures if your team has a collection of battle tested best practices encoded as Terraform modules, and either plan to keep some Terraform or even migrate eventually, you don’t need to migrate right away.

Finally, you can reference Terraform state outputs from Pulumi programs and configurations. Using this you could, for example, keep your network defined in Terraform and define a layer of higher level infrastructure that consumes VPC and subnet IDs from that lower-layer network workspace. This can be useful if there’s short- or long-term coexistence between Terraform and Pulumi IaC programs, such as during an ongoing migration effort or in a hybrid team.

Pulumi Covered Until Your HashiCorp, an IBM Company, Renewal

Even with the new technical capabilities above, we realize many customers already have HashiCorp contracts that may have them locked into a single vendor. The last thing we want is for you to have to pay for two IaC solutions for a period of time. Additionally, we want to ensure that the transition is as smooth as possible and your team is set up for long-term success.

To make it easier to say yes to Pulumi, we are offering three things:

Escape hatch for your current contract. We know paying for two IaC solutions at once is a non-starter, so we’re letting you apply credits purchased from HashiCorp towards your Pulumi usage until your next renewal, avoiding double pay.
Free IaC modernization workshop. Our professional services cloud architects will host a free IaC modernization workshop to review where you’re at with your IaC already and share best practices of how to adopt the Pulumi platform at scale we’ve learned from working with world-class organizations like BMW, NVIDIA, and Supabase. You will leave this session trained up and equipped to succeed with the next phase of your IaC journey.
Return on investment (ROI) calculation. We will show you how the move to Pulumi will not only be spend-neutral thanks to the escape hatch, but how much value and savings you should expect to see, given our experience helping innovators like Snowflake accelerate their time to market – going from code to cloud in weeks to hours.

These ensure there’s no financial penalty for switching, a very clear ROI, and no learning curve. We have always been proud to work with customers of all sizes in all industries, so these offers are available to you whether you’re a Global 2000, startup, or somewhere in between.

Why Snowflake, BMW, and Wiz Switched to Pulumi

We’ve worked with thousands of companies over 8+ years to build what we view as the most innovative infrastructure as code platform on the market. We’re biased, of course, but our customers range from innovative startups, to established public technology companies, to Global 2000, and everywhere in between, and they tell us this all of the time.

For example:

Snowflake radically improved time to market on their path to IPO. “When we demonstrated to people that what used to take a week and a half now, with Pulumi, took under a day, they were shocked.”
Lemonade switched from Terraform to Pulumi so they could embed business logic into infrastructure, share and reuse logic, and scale their lean ops team to support a much larger group of developers. “We’re not limited to one-size-fits-all configurations, but can actually implement environment-specific customizations for our infrastructure.”
BMW was able to establish a center of infrastructure excellence that they call CodeCraft, standardizing all infrastructure delivery, and scaling to support 10,000+ developers.
Supabase was able to scale to meet the heightened demands and pace of AI, saying that “the infrastructure team acts as groundkeepers of our Pulumi practices, not gatekeepers, but promoters for the entire org."
Wiz manages over 1 million resources, tens of thousands Kubernetes clusters, and hundreds of data centers, with over 100,000 daily updates.

Here’s why:

Language choice. Especially with the addition of Terraform/OpenTofu support, and HCL language support natively in Pulumi IaC, the Pulumi platform truly is the most universal IaC platform available. It democratizes access to infrastructure across the entire organization which often has very varied and diverse skillsets. By embracing general-purpose languages, it allows engineering teams to apply rigor to how they manage infrastructure, improving productivity – translating directly to time to market – robustness, and standards compliance.

AI native. We’ve been infusing AI into our platform for over three years now, culminating in the release of our infrastructure engineering agent, Neo. Neo is like Claude Code for your infrastructure and allows you to automate short- and long-horizon infrastructure tasks, like spinning up and scaling infrastructure, upgrading clusters, getting compliant, reducing cloud waste, and so much more. Neo works over any infrastructure no matter how it was provisioned.

Standard enterprise capabilities and controls. Regardless of language or IaC tool choice, you still get one central standardized set of capabilities and controls. This ensures you have one “mission control” from which to standardize, secure, and govern your entire cloud estate, regardless of what client-side tool choice (or even in the presence of click-ops).

Full visibility of what’s happening, when, where, and why. The Pulumi platform always gives you total visibility into your cloud estate so you can quickly understand what is going on. This helps you wrap your hands around your cloud and chart a course to 100% IaC, the table stakes nirvana many organizations are trying to get to, and the choice of language is one small part.

The final point isn’t even a technical one, but we hear it from our customers all the time:

Customer love as our #1 company value. Our first company value is “when the customer is successful, we are too” – and we live it and breathe it daily. I just visited a new customer to review how the project is going yesterday and their head of cloud infrastructure and EVP of product were in the room and both went out of their way to express gratitude for how our team really showed up to help get them on the right track. We don’t view customers as a transaction, we view it as a lifetime partnership, and treat our customers with the respect they deserve. We won’t sleep at night until you’re on the cloud path that you envisioned when selecting Pulumi.

To learn more about our product capabilities, visit these pages:

Get Started Today

If you’d like to join the private beta waitlist for the new Terraform/OpenTofu and HCL capabilities, or take advantage of the financial flexibility options, please get in touch.

We will work with you closely on a three-step process to adopt Pulumi: First, the modernization workshop; then a rapid proof of value; and finally an adoption plan that avoids you double paying Pulumi and HashiCorp.

If you’d like to try Pulumi on your own immediately, you can sign up for Pulumi Cloud here, or go through our open source IaC getting started tutorial here.

We can’t wait to earn the right to work together.

From 'Works on My Machine' to Production-Ready: Building AI Agents with Amazon Bedrock AgentCore

Engin Diri — Mon, 15 Dec 2025 00:00:00 +0200

Every developer building AI agents knows the gap between a working prototype and production deployment. Your fraud detection agent works perfectly on your laptop, but how do you deploy it with proper authentication, memory persistence, observability, and guardrails? This post walks through a complete journey from local development to production-ready AI agents using Amazon Bedrock AgentCore, the Strands SDK, and Pulumi.

TL;DR: This post shows how to deploy AI agents from local prototype to production using:

Strands SDK for agent development
Amazon Bedrock AgentCore for managed runtime with Firecracker isolation
AgentCore Memory for short-term and long-term context
MCP Gateway for secure tool integration with OAuth2
Pulumi for infrastructure as code

Complete code: GitHub

The Challenge: Bridging the Gap

Building AI agents is getting easier. Tools like the Strands Agents SDK let you create functional agents in just a few lines of code. Production deployment introduces challenges:

Stateless to Stateful: How does your agent remember previous conversations?
Single-tenant to Multi-tenant: How do you isolate different users’ data?
Implicit Trust to Zero Trust: How do you authenticate requests and enforce boundaries?
Console Logs to Observability: How do you trace requests across distributed systems?
Ad-hoc Tools to Managed Services: How do you expose tools securely at scale?

The approach is progressive: start simple, add complexity only when needed, and use infrastructure as code to make it reproducible.

Agents Beyond Chat: Event-Driven AI

When most people think of AI agents, they imagine chatbots: interactive systems responding to user questions. But many production agents never interact with end users directly. Instead, they’re triggered by event streams: Kafka topics, SQS queues, webhook callbacks, or scheduled jobs.

Our fraud detection agent is a prime example. It doesn’t wait for customers to ask questions. It’s triggered automatically when the payment processing system detects a new transaction. The “user” is another system, and the “conversation” is a structured event payload.

This event-driven pattern is becoming the new stack for AI agents. As Kai Waehner describes in his analysis of agentic AI with Kafka and Flink:

“Protocols like A2A and MCP are essential for standardizing agent behavior and communication. But without an event-driven substrate like Kafka and a stream-native runtime like Flink, these agents remain stuck in isolated interactions.”

The emerging architecture looks like this:

In production, you might use Amazon MSK (Managed Kafka), Amazon SQS, or EventBridge to deliver transaction events to your agent. The agent processes each event autonomously, takes action (blocking cards, creating tickets), and publishes results back to another topic.

What We’re Building: A Fraud Detection Agent

Our demo is a fraud detection agent that:

Receives transaction alerts with user ID, amount, merchant, and location
Gathers context from tools (user profiles, transaction history)
Analyzes for fraud patterns (impossible travel, velocity attacks, amount anomalies)
Takes protective action (blocking cards) when fraud is detected

We’ll build this progressively:

Stage	What Changes	Key Additions
Local Development	Running on your laptop	Strands SDK, Claude Opus 4.5, mock tools
First Deployment	Running in AgentCore	Containerized, Firecracker isolation, guardrails
Production-Ready	Full enterprise features	Memory, MCP Gateway, X-Ray observability

Local Development with Strands SDK

The Strands Agents SDK is an open-source framework from AWS that takes a model-driven approach to agent development. Instead of hardcoding complex workflows, you let the LLM reason about tool usage autonomously.

Here’s our complete local agent in about 30 lines:

# agent.py
from strands import Agent
from strands.models import BedrockModel
from tools import get_user_profile, get_recent_transactions, block_credit_card

# Configure Bedrock model with cross-region inference for Claude Opus 4.5
# Note: Cross-region inference may have different pricing than single-region
bedrock_model = BedrockModel(
 model_id="us.anthropic.claude-opus-4-5-20251101-v1:0",
 region_name="us-east-1",
)

# Define the Fraud Detection Agent
fraud_agent = Agent(
 model=bedrock_model,
 tools=[get_user_profile, get_recent_transactions, block_credit_card],
 system_prompt="""
 You are a Senior Fraud Analyst Agent at a financial institution.
 Your mission is to protect customers from fraudulent transactions in real-time.

 When you receive a transaction alert:
 1. Gather context by checking the user's profile and recent transaction history.
 2. Analyze the transaction for fraud indicators:
 - Impossible travel: Can the user physically be at the new location?
 - Unusual amounts: Is this significantly larger than typical spending?
 - High-risk merchants: Electronics stores, gift cards, wire transfers.
 - Geographic anomalies: Transactions far from home location.
 3. Make a decision:
 - If fraud indicators are present, BLOCK the card immediately.
 - If the transaction appears legitimate, allow it to proceed.
 4. Document your reasoning clearly.

 Prioritize customer protection. When in doubt, block the card.
 """,
)

Tools are simple Python functions decorated with @tool:

from strands import tool

@tool
def get_user_profile(user_id: str) -> dict:
 """Get user profile including home location and account status."""
 return {
 "user_id": user_id,
 "name": "John Doe",
 "home_location": "London, UK",
 "account_status": "active",
 }

@tool
def block_credit_card(user_id: str, reason: str) -> dict:
 """Block a user's credit card and create a fraud ticket."""
 return {
 "status": "blocked",
 "ticket_id": f"FRAUD-{user_id}-001",
 "message": f"Card blocked for user {user_id}: {reason}",
 }

Running the Local Demo

Here’s how we simulate an incoming transaction event:

# demo_simulation.py
from agent import fraud_agent

# The "Trigger" Event (Simulated Payload from Kafka/SQS)
new_transaction_event = """
ALERT: New Transaction Attempt
User ID: user_123
Amount: $2000
Merchant: Electronics Store
Location: Tokyo, Japan
Time: 09:15
"""

def run_demo():
 print("--- INCOMING EVENT STREAM ---")
 print(new_transaction_event)
 print("--- AGENT ACTIVATED ---")

 # Run the agent - processes the event autonomously
 result = fraud_agent(new_transaction_event)

 print("--- ANALYSIS COMPLETE ---")

if __name__ == "__main__":
 run_demo()

When we run this, the agent autonomously gathers context, analyzes the transaction, and takes action:

$ python demo_simulation.py
--- INCOMING EVENT STREAM ---
ALERT: New Transaction Attempt
User ID: user_123
Amount: $2000
Merchant: Electronics Store
Location: Tokyo, Japan
Time: 09:15
-----------------------------------
AGENT ACTIVATED. Analyzing...
Tool #1: get_user_profile
Tool #2: get_recent_transactions
## 🚨 FRAUD ANALYSIS REPORT
**Customer:** John Doe (user_123)
### Analysis:
#### 1. ❌ IMPOSSIBLE TRAVEL DETECTED
- **Last Transaction:** 09:00 in **London, UK**
- **Current Transaction:** 09:15 in **Tokyo, Japan**
- **Time Elapsed:** 15 minutes
- **Distance:** ~9,500 km (5,900 miles)
- **Minimum Flight Time:** ~12 hours
**Verdict:** It is physically impossible for John Doe to travel from London
to Tokyo in 15 minutes. This is a critical fraud indicator.
#### 2. ⚠️ HIGH-RISK MERCHANT
- Electronics stores are frequently targeted for fraud due to high resale value
#### 3. ⚠️ HIGH-VALUE TRANSACTION
- $2,000 at an electronics store represents a substantial purchase
### Decision: 🛑 BLOCK CARD IMMEDIATELY
Tool #3: block_credit_card
## ✅ ACTION COMPLETED
| Action | Status |
|--------|--------|
| Card Blocked | ✅ Confirmed |
| Ticket ID | TICKET-999 |
--- ANALYSIS COMPLETE ---

Notice how the agent reasoned about the event using tools and took autonomous action. This works great for development, but it lacks everything needed for production: authentication, persistence, isolation, monitoring, and governance.

First Deployment with AgentCore Runtime

Our local prototype works, but where do you actually run it? Lambda times out after 15 minutes. ECS and Kubernetes add operational overhead. And AI agents have different requirements than typical microservices: they reason through multi-step workflows, sometimes taking minutes to analyze a complex fraud case. You need something built for this workload.

Amazon Bedrock AgentCore fills this gap. It’s a managed runtime specifically designed for AI agents, with support for tasks running up to 8 hours. No timeout workarounds, no cluster management.

The security model is particularly relevant for fraud detection. AgentCore runs each session in a dedicated microVM using AWS Firecracker (the same isolation technology behind Lambda). When your agent processes one customer’s transactions, it’s completely isolated from other sessions. No shared memory, no cross-tenant contamination.

The deployment model is straightforward: containerize your agent and point AgentCore at the image. It works with Strands, LangGraph, CrewAI, or custom code. The same agent we built locally runs unchanged. We just wrap it in FastAPI and add a Dockerfile.

Cold Start and Latency

For fraud detection, latency matters. AgentCore’s Firecracker microVMs introduce a cold start penalty on the first invocation, typically 2-5 seconds to spin up the container. Subsequent invocations within the same session are fast (sub-second overhead beyond model inference time).

For real-time fraud detection, this cold start is acceptable because:

The LLM reasoning itself takes 5-15 seconds for complex analysis
Most production deployments use session pooling to keep warm instances available
The alternative (always-on containers) trades latency for cost

If sub-second total latency is critical, consider Lambda for simple rule-based checks and reserve AgentCore for complex reasoning that justifies the cold start overhead.

Containerizing the Agent

First, we wrap our agent in a FastAPI endpoint:

# agent.py (production version)
from fastapi import FastAPI, Request
from strands import Agent
from strands.models import BedrockModel
import os

app = FastAPI()

bedrock_model = BedrockModel(
 model_id="us.anthropic.claude-opus-4-5-20251101-v1:0",
 region_name="us-east-1",
 guardrail_id=os.environ.get("BEDROCK_GUARDRAIL_ID"),
 guardrail_version=os.environ.get("BEDROCK_GUARDRAIL_VERSION"),
 guardrail_trace="enabled",
)

fraud_agent = Agent(
 model=bedrock_model,
 tools=[get_user_profile, get_recent_transactions, block_credit_card],
 system_prompt="...",
)

@app.post("/invocations")
async def invoke(request: Request):
 body = await request.json()
 prompt = body.get("input", {}).get("prompt", "")
 result = fraud_agent(prompt)
 return {"output": {"message": str(result)}}

Adding Guardrails

Amazon Bedrock Guardrails help ensure your agent stays on task. We configure content filters and topic restrictions using Pulumi:

fraud_detection_guardrail = bedrock.Guardrail(
 "fraud-detection-guardrail",
 name="fraud-detection-guardrail",
 description="Ensure agent only handles fraud detection tasks",
 blocked_input_messaging="This request is outside the scope of fraud detection.",
 blocked_outputs_messaging="This response was blocked.",
 content_policy_config=bedrock.GuardrailContentPolicyConfigArgs(
 filters_configs=[
 bedrock.GuardrailContentPolicyConfigFiltersConfigArgs(
 type="SEXUAL", input_strength="HIGH", output_strength="HIGH",
 ),
 bedrock.GuardrailContentPolicyConfigFiltersConfigArgs(
 type="VIOLENCE", input_strength="HIGH", output_strength="HIGH",
 ),
 bedrock.GuardrailContentPolicyConfigFiltersConfigArgs(
 type="PROMPT_ATTACK", input_strength="HIGH", output_strength="NONE",
 ),
 # ... additional filters
 ],
 ),
 topic_policy_config=bedrock.GuardrailTopicPolicyConfigArgs(
 topics_configs=[
 bedrock.GuardrailTopicPolicyConfigTopicsConfigArgs(
 name="entertainment-media",
 type="DENY",
 definition="Questions about movies, TV shows, celebrities...",
 examples=["What is LOTR?", "Tell me about Star Wars"],
 ),
 bedrock.GuardrailTopicPolicyConfigTopicsConfigArgs(
 name="general-assistance",
 type="DENY",
 definition="Requests for coding help, math problems...",
 examples=["Write me a poem", "Help me with Python code"],
 ),
 ],
 ),
)

Deploying with Pulumi

The infrastructure is straightforward: ECR repository, IAM roles, and AgentCore Runtime:

# Create ECR repository
repo = ecr.Repository(
 "strands-agent-repo",
 name="fraud-detection-agent",
 force_delete=True,
)

# Build and push Docker image
image = docker.Image(
 "strands-agent-image",
 image_name=repo.repository_url.apply(lambda url: f"{url}:latest"),
 build=docker.DockerBuildArgs(
 context="../fraud-detection-agent",
 platform="linux/arm64",
 ),
 registry=docker.RegistryArgs(
 server=repo.repository_url,
 username=auth_token.user_name,
 password=auth_token.password,
 ),
)

# Deploy AgentCore Runtime
agent_runtime = bedrock.AgentcoreAgentRuntime(
 "fraud-detection-agent-runtime",
 agent_runtime_name="fraud_detection_agent",
 description="Fraud Detection Agent with Guardrails",
 role_arn=agent_role.arn,
 agent_runtime_artifact=bedrock.AgentcoreAgentRuntimeAgentRuntimeArtifactArgs(
 container_configuration=bedrock.AgentcoreAgentRuntimeAgentRuntimeArtifactContainerConfigurationArgs(
 container_uri=image.image_name,
 ),
 ),
 network_configuration=bedrock.AgentcoreAgentRuntimeNetworkConfigurationArgs(
 network_mode="PUBLIC",
 ),
 environment_variables={
 "BEDROCK_GUARDRAIL_ID": fraud_detection_guardrail.guardrail_id,
 "BEDROCK_GUARDRAIL_VERSION": fraud_detection_guardrail.version,
 },
)

Testing the Basic Deployment

After pulumi up, we can invoke the deployed agent via the AWS SDK:

# invoke_agent.py
import boto3
import json

def invoke_agent(agent_runtime_arn: str, prompt: str) -> dict:
 client = boto3.client("bedrock-agentcore", region_name="us-east-1")

 response = client.invoke_agent_runtime(
 agentRuntimeArn=agent_runtime_arn,
 runtimeSessionId="session_abc123...",
 payload=json.dumps({"input": {"prompt": prompt}}),
 qualifier="DEFAULT",
 )

 return json.loads(response["response"].read())

Running the same fraud scenario against the deployed agent:

$ ./test.sh
Selecting Pulumi stack 'dev'...
Getting agent runtime ARN from Pulumi...
Agent Runtime ARN: arn:aws:bedrock-agentcore:us-east-1:052848974346:runtime/fraud_detection_agent-W7zFZT3Vcn
Invoking agent with fraud detection alert...
========================================
Sending prompt to agent...
Prompt: ALERT: New Transaction Attempt
User ID: user_123
Amount: $2000
Merchant: Electronics Store
Location: Tokyo, Japan
Time: 09:15
--------------------------------------------------
Agent Response:
{
"output": {
"message": {
"role": "assistant",
"content": [
{
"text": "**Analysis:** Impossible travel confirmed. User was in London at 09:00
and this transaction attempted in Tokyo at 09:15. Physically impossible.
Combined with high-risk merchant and $2000 amount, this is fraudulent.
Card blocked (TICKET-999)."
}
]
},
"timestamp": "2025-12-15T04:17:48.762738+00:00",
"model": "fraud-detection-agent"
}
}

The agent now runs in a managed, isolated environment with guardrails. Next, we add memory and external tool integration.

Production-Ready: Memory and MCP Gateway

Our basic deployment handles individual transactions, but fraud detection in the real world requires context. If a customer’s card was blocked five minutes ago, the agent shouldn’t try to block it again. If there’s a pattern of suspicious activity over the past week, the agent should factor that into its analysis.

This is where AgentCore Memory and the MCP Gateway come in.

AgentCore Memory: Short-term and Long-term

Memory in AgentCore works at two levels. Short-term memory stores raw conversation events within a session. If the agent blocks a card in one message, it remembers this in subsequent messages during the same session.

Long-term memory is more interesting. It uses semantic extraction to persist facts across sessions. The system runs your conversations through a smaller model (we use Claude Haiku) to extract key facts, then stores those facts in a namespace you define. When a new session starts, the agent can query for relevant facts about that user. Even if the customer calls back tomorrow, the agent knows their card was blocked yesterday.

Here’s how we configure the memory infrastructure:

# Create AgentCore Memory with 30-day event expiry
fraud_detection_memory = bedrock.AgentcoreMemory(
 "fraud-detection-memory",
 name="fraud_detection_memory",
 description="Memory for fraud detection agent",
 event_expiry_duration=30, # Events expire after 30 days
 memory_execution_role_arn=memory_execution_role.arn,
)

# Custom semantic extraction for fraud-related facts
FRAUD_EXTRACTION_PROMPT = """
Extract key fraud-related facts from this conversation about the user. Focus on:
1. Credit card status (blocked/active, ticket IDs if blocked)
2. Fraud alerts and patterns detected for this user
3. Transaction history patterns (locations, amounts, frequencies)
4. User profile details relevant to fraud detection
5. Previous fraud investigations and their outcomes

Format as concise facts that can help identify fraud patterns across sessions.
"""

# Create long-term memory strategy
fraud_semantic_strategy = bedrock.AgentcoreMemoryStrategy(
 "fraud-semantic-strategy",
 name="fraud_semantic_extraction",
 memory_id=fraud_detection_memory.id,
 type="CUSTOM",
 namespaces=["/fraud-detection/users/{actorId}"],
 configuration={
 "type": "SEMANTIC_OVERRIDE",
 "extraction": {
 "append_to_prompt": FRAUD_EXTRACTION_PROMPT,
 "model_id": "us.anthropic.claude-3-5-haiku-20241022-v1:0",
 },
 "consolidation": {
 "model_id": "us.anthropic.claude-3-5-haiku-20241022-v1:0",
 },
 },
)

The namespace pattern /fraud-detection/users/{actorId} ensures each user’s facts are isolated. Claude Haiku handles the extraction efficiently, keeping costs low while maintaining accuracy.

Long-term memory extraction is asynchronous. Plan for a 20-40 second delay between storing conversations and having facts available for retrieval. Use short-term memory for immediate needs while long-term memories are being processed.

In the agent code, we integrate memory using Strands hooks:

from bedrock_agentcore.memory import MemoryClient

memory_client = MemoryClient(region_name="us-east-1")

# Retrieve long-term facts before processing
memories = memory_client.retrieve_memories(
 memory_id=memory_id,
 namespace=f"/fraud-detection/users/{actor_id}",
 query=f"fraud detection facts for user {actor_id}"
)

# Store conversation after processing
memory_client.create_event(
 memory_id=memory_id,
 actor_id=actor_id,
 session_id=session_id,
 messages=[
 (user_message, "USER"),
 (assistant_message, "ASSISTANT")
 ]
)

MCP Gateway: Tool Integration at Scale

The tools we’ve used so far are baked into the agent container. That works for simple cases, but what happens when you have dozens of tools across multiple teams? Or when a tool needs to call an external service that requires its own authentication?

The Model Context Protocol (MCP) is an open standard for AI systems to communicate with tools. AgentCore Gateway provides a managed MCP endpoint that handles authentication (JWT inbound, OAuth2 outbound) and lets agents discover tools using natural language queries rather than knowing exact tool names.

We deploy an MCP server for risk scoring with three tools:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("Fraud Risk Scoring Server")

@mcp.tool()
def calculate_risk_score(user_id: str, amount: float, merchant: str, location: str) -> dict:
 """Calculate comprehensive fraud risk score (0-100)."""
 # Risk calculation logic
 return {
 "risk_score": 75,
 "factors": ["amount_anomaly", "high_risk_merchant"],
 "recommendation": "BLOCK"
 }

@mcp.tool()
def get_fraud_indicators(user_id: str) -> dict:
 """Get known fraud indicators for a user."""
 return {
 "indicators": ["velocity_alert", "device_inconsistency"],
 "severity": "HIGH"
 }

@mcp.tool()
def check_merchant_reputation(merchant_name: str) -> dict:
 """Check merchant risk rating and fraud history."""
 return {
 "risk_rating": "HIGH",
 "fraud_reports": 47,
 "chargeback_rate": 0.15
 }

The Gateway infrastructure requires careful attention to authentication. We use two separate Cognito user pools to handle the dual authentication flow:

Inbound authentication (Agent → Gateway): The agent authenticates to the Gateway using JWT tokens from the first Cognito pool. This ensures only authorized agents can discover and call tools.

# Gateway with MCP protocol and semantic search
agentcore_gateway = bedrock.AgentcoreGateway(
 "fraud-detection-gateway",
 name="fraud-detection-mcp-gateway",
 description="Gateway for fraud detection MCP tools",
 role_arn=gateway_role.arn,
 authorizer_type="CUSTOM_JWT",
 authorizer_configuration={
 "customJwtAuthorizer": {
 "discoveryUrl": gateway_discovery_url,
 "allowedClients": [gateway_app_client.id],
 },
 },
 protocol_type="MCP",
 protocol_configuration={
 "mcp": {
 "supportedVersions": ["2025-03-26"],
 "searchType": "SEMANTIC",
 "instructions": "Gateway for fraud detection risk scoring tools.",
 },
 },
)

The searchType: "SEMANTIC" configuration enables natural language tool discovery. Instead of the agent needing to know exact tool names, it can query for “tools that check merchant risk” and the Gateway returns relevant matches.

Outbound authentication (Gateway → MCP Server): When the Gateway calls the MCP server, it needs its own credentials. The OAuth2 Credential Provider manages this second authentication layer:

# OAuth2 Credential Provider for Gateway -> MCP Server auth
oauth2_credential_provider = bedrock.AgentcoreOauth2CredentialProvider(
 "mcp-runtime-oauth2-provider",
 name="fraud-mcp-runtime-oauth2",
 credential_provider_vendor="CustomOauth2",
 oauth2_provider_config={
 "customOauth2ProviderConfig": {
 "oauthDiscovery": {"discoveryUrl": mcp_runtime_discovery_url},
 "clientId": mcp_runtime_app_client.id,
 "clientSecret": mcp_runtime_app_client.client_secret,
 },
 },
)

Connecting the pieces: Finally, we create a Gateway Target. This links the Gateway to the MCP server endpoint. It also specifies which credential provider to use for outbound calls:

# Connect Gateway to MCP Server
gateway_target = bedrock.AgentcoreGatewayTarget(
 "mcp-risk-server-target",
 name="mcp-risk-server-target",
 gateway_identifier=agentcore_gateway.gateway_id,
 target_configuration={
 "mcp": {"mcpServer": {"endpoint": mcp_server_endpoint_url}},
 },
 credential_provider_configuration={
 "oauth": {
 "providerArn": oauth2_credential_provider.credential_provider_arn,
 "scopes": [mcp_runtime_scope_string],
 },
 },
)

This three-part configuration (Gateway, Credential Provider, Target) separates concerns cleanly: the Gateway handles inbound auth and protocol translation, the Credential Provider manages outbound secrets, and the Target defines routing.

Observability with X-Ray and OpenTelemetry

Production systems need observability. We configure CloudWatch Logs for application logs and X-Ray for distributed tracing:

# Agent application logs
agent_log_group = cloudwatch.LogGroup(
 "agent-runtime-log-group",
 name=pulumi.Output.concat(
 "/aws/vendedlogs/bedrock-agentcore/", agent_runtime.agent_runtime_id
 ),
 retention_in_days=30,
)

agent_logs_delivery = cloudwatch.LogDelivery(
 "agent-logs-delivery",
 delivery_source_name=agent_logs_delivery_source.name,
 delivery_destination_arn=agent_logs_delivery_destination.arn,
)

# X-Ray traces
agent_traces_delivery_destination = cloudwatch.LogDeliveryDestination(
 "agent-traces-delivery-destination",
 name="fraud-agent-traces-dest",
 delivery_destination_type="XRAY",
)

agent_traces_delivery = cloudwatch.LogDelivery(
 "agent-traces-delivery",
 delivery_source_name=agent_traces_delivery_source.name,
 delivery_destination_arn=agent_traces_delivery_destination.arn,
)

In the container, we use AWS Distro for OpenTelemetry for auto-instrumentation:

CMD ["uv", "run", "opentelemetry-instrument", "uvicorn", "agent:app", "--host", "0.0.0.0", "--port", "8080"]

This gives us end-to-end tracing across agent invocations, memory operations, and Gateway calls with zero code changes.

AWS has announced that X-Ray SDKs will be deprecated in favor of OpenTelemetry by February 2027. Using ADOT from the start ensures your observability stack is future-proof.

Running the Demo

Deploy the Infrastructure

cd advanced-bedrock-deployment/infra
uv sync
uv run pulumi up

This deploys approximately 40 AWS resources including:

ECR repositories for agent and MCP server
AgentCore Memory with semantic extraction strategy
Two Cognito user pools for authentication
AgentCore Gateway with MCP protocol
CloudWatch log groups and X-Ray trace delivery
IAM roles and policies

Test Short-term Memory

./test.sh demo

This runs 5 scenarios in the same session, demonstrating short-term memory:

======================================================================
FRAUD DETECTION DEMO - SHORT-TERM MEMORY (Same Session)
======================================================================
SCENARIO 1: John Doe - Impossible Travel Detection
Expected: FRAUD - impossible travel from London to Tokyo in 15 minutes
Actor ID: user_123
Session ID: session_cf171803eb324a2aa9ac456b3013fe45...
----------------------------------------------------------------------
Agent Response:
{
"output": {
"message": {
"text": "**FRAUD CONFIRMED - CARD BLOCKED**
| Finding | Details |
|---------|---------|
| **User** | John Doe |
| **Ticket** | TICKET-123-999 |
| **Fraud Type** | Impossible Travel + Spending Anomaly |
**Analysis:** Transaction in Tokyo 15 minutes after London purchase
is physically impossible. The $2,000 amount is 10x the user's typical
spending range ($50-200). Card blocked immediately."
},
"memory_enabled": true,
"long_term_facts_retrieved": 3
}
}
======================================================================
SCENARIO 3: John Doe - Follow-up Transaction (Short-term Memory Test)
Expected: FRAUD - card should already be blocked (SHORT-TERM MEMORY)
Actor ID: user_123
Session ID: session_cf171803eb324a2aa9ac456b3013fe45... (SAME SESSION!)
----------------------------------------------------------------------
Agent Response:
{
"output": {
"message": {
"text": "**Card for user_123 (John Doe) is ALREADY BLOCKED
(Ticket: TICKET-123-999). No further action needed.**
This appears to be another fraudulent attempt on an already-compromised
account. The card was previously blocked due to impossible travel fraud.
The current transaction follows the same pattern: Gift Card Kiosk
purchases are a common fraud tactic for converting stolen card access
to untraceable value."
},
"memory_enabled": true,
"long_term_facts_retrieved": 3
}
}
======================================================================
SHORT-TERM MEMORY DEMO SUMMARY
======================================================================
[OK] John Doe - Impossible Travel Detection
[OK] Jane Smith - Normal Transaction
[OK] John Doe - Follow-up Transaction (Short-term Memory Test)
[OK] Alice Chen - Impossible Travel Detection
[OK] Jane Smith - Second Normal Transaction

The agent remembers within the same session that John’s card is already blocked, so there’s no need to block it twice.

Test Long-term Memory

./test.sh longterm-fresh

This demonstrates cross-session memory with two phases:

======================================================================
PHASE 1: INITIAL FRAUD DETECTION
These interactions create long-term memory facts about users.
======================================================================
SCENARIO: John Doe - Initial Fraud (Card Blocked)
Session ID: session_xyz789... (NEW SESSION)
→ Card blocked, fact stored to long-term memory
======================================================================
WAITING FOR LONG-TERM MEMORY EXTRACTION...
The semantic strategy needs time to process conversations into facts.
Waiting 30 seconds...
======================================================================
======================================================================
PHASE 2: NEW SESSIONS - LONG-TERM MEMORY RETRIEVAL
These are COMPLETELY NEW sessions. The agent should remember
fraud-related facts about users from Phase 1.
======================================================================
SCENARIO: John Doe - NEW SESSION (Long-term Memory Test)
Session ID: session_new456... (DIFFERENT SESSION!)
----------------------------------------------------------------------
Agent Response:
{
"output": {
"message": "CARD ALREADY BLOCKED. According to my records,
this user's card was previously blocked due to fraud.
Ticket FRAUD-user_123-001 exists from a previous investigation.
The card remains blocked.",
"memory_enabled": true,
"long_term_facts_retrieved": 2
}
}

Even in a completely new session, the agent retrieves facts from long-term memory and knows John’s card was blocked yesterday.

Test MCP Gateway

./test.sh gateway-fresh

This runs 6 diverse fraud scenarios using both local tools and MCP Gateway tools:

======================================================================
LOADING MCP GATEWAY CONFIGURATION...
======================================================================
Gateway URL: https://fraud-detection-mcp-gateway-xxx.gateway.bedrock-agentcore.us-east-1.amazonaws.com/mcp
Token Endpoint: https://fraud-gateway-xxx.auth.us-east-1.amazoncognito.com/oauth2/token
Scope: fraud-detection-gateway/invoke
MCP Gateway configuration loaded successfully!
======================================================================
FRAUD DETECTION DEMO - MCP GATEWAY INTEGRATION
======================================================================
LOCAL TOOLS:
- get_user_profile: User details and home location
- get_recent_transactions: Last known transaction
- block_credit_card: Block card and create ticket
MCP GATEWAY TOOLS (via Risk Scoring Service):
- calculate_risk_score: Fraud risk score 0-100
- get_fraud_indicators: Known fraud indicators
- check_merchant_reputation: Merchant risk rating
======================================================================
SCENARIO 1: HIGH-RISK MERCHANT - Jane at CryptoExchange123
MCP Gateway: ENABLED
----------------------------------------------------------------------
Agent Response:
{
"output": {
"message": {
"text": "**✅ CARD BLOCKED** - Ticket: TICKET-456-999
**Summary:** Jane Smith's card blocked due to a $5,000 crypto exchange
transaction that is 10x her typical spend and outside her normal merchant
categories. Location matched home, but amount and merchant anomalies
indicate likely fraud or compromised credentials."
},
"mcp_gateway_enabled": true,
"mcp_tools_count": 4
}
}
======================================================================
SCENARIO 5: COMBINED SIGNALS - Alice's Multi-Factor Fraud
MCP Gateway: ENABLED
----------------------------------------------------------------------
Agent Response:
{
"output": {
"message": {
"text": "## 🚨 FRAUD CONFIRMED - CARD BLOCKED
**User:** Alice Chen (user_321)
**Ticket ID:** TICKET-321-999
**Fraud Indicators Detected:**
| Factor | Finding |
|--------|---------|
| ⛔ Impossible Travel | Singapore (10:00) → Los Angeles (11:30) = 90 min |
| ⛔ Amount Anomaly | $2,500 vs typical $50-300 (8x+ normal) |
| ⛔ Merchant Mismatch | Cash advance vs usual food/retail |
| ⛔ High-Risk Merchant | QuickCashAdvance (cash advance services) |
**Action Taken:** Card blocked immediately. This transaction exhibits
classic signs of stolen card credentials being used for rapid cash extraction."
},
"mcp_gateway_enabled": true,
"mcp_tools_count": 4
}
}
======================================================================
MCP GATEWAY DEMO SUMMARY
======================================================================
[OK] 1. HIGH-RISK MERCHANT - Jane at CryptoExchange123
Gateway: YES (4 tools)
[OK] 2. VELOCITY ATTACK - Bob's Rapid Transactions
Gateway: YES (4 tools)
[OK] 3. AMOUNT ANOMALY - Alice's Large Purchase
Gateway: YES (4 tools)
[OK] 4. KNOWN FRAUD PATTERNS - John's Indicator Check
Gateway: YES (4 tools)
[OK] 5. COMBINED SIGNALS - Alice's Multi-Factor Fraud
Gateway: YES (4 tools)
[OK] 6. CLEAN TRANSACTION - Jane's Normal Purchase
Gateway: YES (4 tools)

The MCP Gateway tools provide additional context (merchant reputation, risk scores, fraud indicators) that helps the agent make better decisions.

Architecture Summary

Here’s the complete architecture:

Key Takeaways

Event-driven first: Production agents are triggered by Kafka, SQS, or webhooks, not chat interfaces
Start simple: Build with Strands SDK locally, add AgentCore complexity only when needed
Guardrails early: Content filtering and topic restrictions prevent prompt injection
Memory has two levels: Short-term (session) and long-term (semantic extraction across sessions)
MCP for tools at scale: Gateway handles auth and discovery; you focus on tool logic
Observability required: X-Ray + CloudWatch are essential for debugging distributed AI
IaC for reproducibility: Pulumi deploys 40+ resources with proper dependencies

Cost Considerations

When evaluating AgentCore for production, consider these cost factors:

AgentCore Runtime charges per session-second. For fraud detection agents that typically run 10-30 seconds per transaction, this is cost-effective compared to maintaining always-on ECS containers. However, if your agents process thousands of transactions per second, the per-session costs add up. Consider batching or using Lambda for simple, fast agents.

Model costs dominate most deployments. Claude Opus 4.5 (used for reasoning) costs significantly more than Claude Haiku (used for memory extraction). We deliberately use Haiku for semantic extraction to keep memory costs low while maintaining accuracy. For high-volume production, consider whether Haiku or even smaller models could handle your primary reasoning.

Memory and Gateway have their own pricing tiers. AgentCore Memory charges for storage and retrieval operations. The Gateway adds overhead for OAuth2 token management and routing. For simple agents that don’t need cross-session memory or external tools, skip these components entirely.

Cognito user pools for authentication have a free tier (50,000 MAU) that covers most development and moderate production workloads. Beyond that, costs scale with active users.

Start with a basic deployment and add Memory/Gateway only when you have a clear need. The infrastructure cost savings of skipping unnecessary components often exceed the engineering cost of adding them later.

Conclusion

The fraud detection agent in this post grew from 30 lines of local Python to a production deployment with guardrails, dual-layer memory, MCP Gateway integration, and full observability, all defined as infrastructure as code.

The gap between prototype and production doesn’t have to be a chasm. AgentCore provides the managed runtime, Pulumi makes it reproducible, and the progressive approach lets you add complexity only when your use case demands it.

Get Started with Pulumi

Use Pulumi's open-source SDK to create, deploy, and manage infrastructure on any cloud.

The Superintelligence Flywheel: Infrastructure for the AI Era

Joe Duffy — Thu, 11 Dec 2025 00:00:00 +0000

We’ve been in the infrastructure business for nearly a decade, and we’ve never been more excited about, or in awe of, the scale we are seeing as the industry pursues superintelligence. We are now hitting a tipping point that requires entirely different approaches to managing and scaling infrastructure in this new era.

What do we mean by superintelligence? Superintelligence means AI systems that operate with genuine autonomy—planning, reasoning, executing, adapting—at scale, on the path toward human-level and eventually superhuman intelligence. The infrastructure needed to accomplish this is greater than anything we’ve ever seen. Jensen Huang projects $600 billion in AI infrastructure spending this year, scaling to $3-4 trillion by decade’s end. Stargate committed $500 billion to AI infrastructure in the U.S. Microsoft, Meta, and Google are each spending $70-90 billion annually on datacenters. AWS just activated Project Rainier, a data center scaling to one million custom Trainium chips for Anthropic’s frontier models.

Superintelligence is driving the biggest, fastest infrastructure scaling period in the history of computing. This is exciting but comes with challenges: all of that infrastructure has to be managed, secured, scaled, made compliant, and cost effective. Legacy infrastructure tools weren’t built for this reality—they add friction that slows progress or breaks it altogether.

This reveals an important insight:

The infrastructure required to build superintelligence demands superintelligence for infrastructure.

The systems being built today for superintelligence are already straining human platform teams to their limits and yet we’re still only just getting started. To succeed, we will have no choice but to use AI itself to help us manage the infrastructure scaling ahead on the path to superintelligence.

Superintelligence demands more infrastructure, which demands superintelligent approaches to managing and scaling that infrastructure, which leads to faster progress towards superintelligence.

We call this the superintelligence flywheel.

The Flywheel Defined

The superintelligence flywheel describes a self-reinforcing cycle between two forces:

Superintelligence Infrastructure: The massively distributed compute, storage, networking, and orchestration systems required to train and serve frontier AI models.

Infrastructure Superintelligence: AI systems capable of managing infrastructure with increasing autonomy. These systems handle the full spectrum of infrastructure automation, from provisioning to securing to evolving and scaling entire environments.

These reinforce one another. As AI infrastructure grows more complex, human teams will increasingly use AI to manage it. This affects all of us: frontier labs, technology innovators, and enterprises modernizing their products and workforces with an AI-first mindset. Infrastructure agents are simply a requirement for all of us in this new world.

The flywheel accelerates.

The Technical Reality

Frontier labs have the most extreme requirements, but everybody else is somewhere on the curve. You don’t have to be training GPT-5 to feel this pressure. If you’re deploying fine-tuned models, running inference at scale, or just trying to keep up with AI-assisted developers shipping faster—you’re on the same curve, just earlier. To stay competitive and innovative in this new era, access to infrastructure needs to be democratized and inherently automation- and experimentation-friendly.

This can be seen most vividly with frontier lab-scale infrastructure challenges:

Training starts with data preparation. Petabytes of data turns into trillions of curated tokens across thousands of CPU cores. Pre-training runs massive GPU clusters hot for months, at a scale where hardware failures are statistical certainties. Checkpoint management, gradient synchronization, and fault-tolerant scheduling become first-order concerns. Fine-tuning and reinforcement learning add even more coordination complexity: synthetic data generation, AI judges, multiple model copies running simultaneously in tightly coupled loops, hundreds of experiment variants, infrastructure that scales elastically as experiments converge or diverge.

Inference means serving models to an ever-elastic sea of users across massive GPU fleets, many clouds, and distributed globally. ChatGPT, for instance, handles over 2.5 billion queries per day with sub-second time-to-first-token expectations. Traffic patterns shift by geography, time, and viral adoption, and the software must be ready to react. The difference between good and poor GPU utilization at this scale can make or break the user experience and the bank.

These examples share three properties that break traditional infrastructure approaches:

Massive scale: Thousands or millions of coordinated resources with complex architectures across multiple regions and cloud providers.
Extreme dynamism: Infrastructure that must spin up, reallocate, and tear down continuously based on job requirements, spot pricing, capacity availability, and failures.
Velocity beyond human capacity: Infrastructure changes that occur faster than human operators can review, approve, and execute manually, often initiated by AI agents.

Of course, even smaller scale examples share these challenges. Whether you’re using AWS SageMaker or Google Vertex AI to fine-tune models for your enterprise, building out your data engineering function to train custom models, or moving your first ML workloads to production—these infrastructure demands become relevant as you scale.

AI-assisted software development tools are making engineers dramatically more productive. Developers are shipping more code than ever before. But unlike software engineering, legacy infrastructure practices lack inherent guardrails to enable AI-assisted infrastructure engineering: linters, static analysis, testing frameworks, canaries, staged rollouts. The tooling that worked when humans were the limiting factor won’t work when AI agents are generating and deploying infrastructure code at machine speed.

Infrastructure Fungibility: The Holy Grail

Instead of treating each use case as a special snowflake, the holy grail is infrastructure fungibility across many clouds. In this world, infrastructure is dynamically allocated based on availability, demand, and data locality. Inference gets served based on current user demand. Experiments get capacity when it’s available. Long-horizon training runs on whatever’s left over.

This is extraordinarily difficult. But without it, the costs compound: researchers waiting for capacity, GPU-hours sitting idle between workloads, time delays that let competitors ship first. At frontier scale, even small inefficiencies translate to tens of millions of dollars.

This level of dynamism can’t be managed by humans watching dashboards and approving PRs. The infrastructure itself needs to become intelligent—capable of planning, executing, and adapting without waiting for human operators.

The frontier labs building this have learned through direct experience. They have historically had to work around legacy infrastructure tools and slow-moving DevOps teams, taking matters into their own hands. As one infrastructure lead put it: “There are thirty people in the world that know how to do this right now.” It is time for this knowledge to spread faster, in the hands of platform teams, because everyone building with AI is running into some version of the same problem.

Towards a Superintelligence Platform

There are two foundations that form a cohesive superintelligence platform:

Foundation #1: Pulumi as the Infrastructure Automation Substrate

We built Pulumi on three principles that are well-suited to the unique challenges of this era:

Infrastructure as code must be actual code. Domain-specific languages and static configuration formats create a ceiling. Instead, standing on the shoulders of giants with real programming languages provides type systems, conditionals, loops, abstractions, package management, testing frameworks, and more. These capabilities facilitate scale. Just as importantly, your team already knows Python, TypeScript, and Go—why force them to learn yet another proprietary DSL and context-switch constantly between application code and infrastructure configuration?

But there’s a deeper reason this matters now. LLMs have been trained on billions of lines of Python, TypeScript, and Go, and deeply understand how to code correctly. Infrastructure in real programming languages becomes infrastructure that AI systems can reason about, generate correctly, and modify safely. We call this an “LLM-sympathetic architecture”: by projecting cloud infrastructure into code space, LLMs can manipulate infrastructure through coding, something they are already superb at which ensures it can be done repeatably and correctly.

One substrate across all of the clouds. Every cloud, every SaaS provider. Frontier labs run training jobs wherever capacity exists: AWS, Azure, Google Cloud, Oracle Cloud, CoreWeave, Lambda Labs. GPU availability is the constraint; cloud provider preference is now secondary.

A single lab may prefer to train on CoreWeave, overflow to AWS when spot capacity becomes available, and tap Google Cloud when the reservations in other cloud providers are used up. Inference deployments span every region where users exist, across whichever providers offer the best latency and cost characteristics.

Infrastructure platforms that aren’t inherently multi-cloud simply can’t serve these requirements, forcing teams to adopt many fragmented tools and workflows. A platform for the superintelligence era simply must treat multi-cloud as a given with unified resource management, policy enforcement, and state tracking across all providers.

Agent-ready architecture. Human-in-the-loop infrastructure management doesn’t scale to the velocity of the new era. The path forward is progressive autonomy: AI agents that operate infrastructure with increasing independence, bounded by human-defined policies and guardrails.

This requires platforms designed for agent interaction from the ground up, with APIs agents can invoke, state they can reason about, policies that define boundaries, audit trails that maintain accountability. The infrastructure platform becomes the substrate on which agents operate. Infrastructure as code, it turns out, is already very good at this thanks to its declarative core.

Foundation #2: Neo as the Agentic Layer

If managing superintelligence scale infrastructure requires AI agents that can handle infrastructure automation, the critical question is: what should those agents look like?

Neo is our answer. Neo is an AI agent that operates infrastructure like a senior platform engineer, built on top of Pulumi’s foundation. Because Pulumi already provides the guardrails that software engineering takes for granted—previews, policy enforcement, state tracking—Neo can handle infrastructure tasks automatically while validating changes before they hit production.

Uniquely enabled by infrastructure as code. Neo operates on infrastructure code, not opaque configurations or cloud APIs directly. Even for resources not yet managed by Pulumi, Neo seamlessly imports them under code management before making changes. Every action flows through version control, policy checks, and state tracking. This ensures the underlying LLM’s coding smarts apply to infrastructure changes.

Built for progressive autonomy. Organizations configure Neo’s independence by environment and task type. Dev environments might permit fully autonomous operation—daily waste cleanup, weekly drift reconciliation—while production changes may require human approval. When Neo encounters unexpected state or errors, it can self-diagnose or loop in a human for assistance as needed. As confidence builds, the autonomy boundary expands, towards full autonomy.

Inherently understands and respects guardrails. The same velocity that creates opportunity creates risk. An agent that can provision 1,000 resources can also misconfigure 1,000 resources. Pulumi’s infrastructure as code foundation provides the safety mechanisms software engineering takes for granted: previews before deployment, policy as code enforcement, audit trails, human-in-the-loop approvals, and organizational best practices encoded in components. Just as you wouldn’t ship code without version control, you shouldn’t let AI manage infrastructure without these guardrails.

Agentically automate anything: Give Neo a prompt like “Provision a PyTorch training environment for LoRA fine-tuning on GKE with 50 A100s using Nvidia’s GPU Operator and Kueue—then run a smoke test.” Neo generates the project, previews changes, provisions everything, verifies it works. Days become minutes. It’s not just for new infrastructure: one customer used Neo to tackle 300,000+ policy violations—work they estimated would take years is now done in weeks.

Frontier models plus infrastructure smarts: Neo builds on a mixture of frontier models while incorporating nearly a decade of infrastructure expertise. Neo benefits from Pulumi’s nearly one billion deployments, hundreds of thousands of AI interactions and known-to-be-working code examples, and many petabytes of semantically-understood, anonymized infrastructure metadata. This foundation is something that no other company in the world has at their disposal.

Pulumi + Neo: The Superintelligence Platform

Pulumi without Neo is already a powerful infrastructure platform—but one that still requires human operators for every change. Neo without Pulumi would never be production-ready, as it would lack the cloud-to-code projection and guardrails that make Neo so good. Together, humans define intent and policy, and intelligent agents handle execution with autonomy.

This is the foundation for setting the superintelligence flywheel in motion.

Evidence at Scale

The flywheel isn’t theoretical. We’re facilitating it daily with thousands of customers:

Hyper-scale: Wiz manages over one million cloud resources across tens of thousands of Kubernetes clusters in hundreds of data centers across every cloud provider imaginable. They do hundreds of thousands of updates daily across thousands of Kubernetes clusters, leading to 5x faster customer onboarding and entering new markets in days rather than months. They treat infrastructure provisioning as just another service in their distributed system.

Infrastructure democratization: Supabase achieved the infrastructure velocity needed to keep up with the AI era’s demand for their own product, empowering 20x more teammates to scale infrastructure in TypeScript, the same language as their application code, rather than proprietary DSLs that nobody understood. New regions deploy in about a week, with 43,000 new databases daily and 100,000+ API calls per second. According to their platform team, now thanks to Pulumi, “the infrastructure team acts as groundkeepers, not gatekeepers.”

Frontier science: We manage infrastructure for organizations including NVIDIA and multiple frontier labs building the models that will define the next decade. The scale requirements for these workloads exceed any we’ve ever seen and are only getting bigger. Just as many customers democratize infrastructure for their developers, we’re seeing frontier labs use Pulumi to accelerate getting science into production with self-service infrastructure for AI researchers.

The Superintelligence Flywheel is in Motion

AI is driving the largest infrastructure buildout in history—whether you’re training frontier models or deploying your first ML workloads to production. That complexity demands intelligent agents. Organizations that embrace this—building infrastructure for AI while using AI for infrastructure—will define the next era of computing.

The superintelligence flywheel is spinning fast, and it’s only going to get faster from here.

Pulumi provides the infrastructure platform for the superintelligence era: infrastructure as code in general-purpose languages, unified multi-cloud management, and Neo for progressive infrastructure autonomy.

Pulumi Neo ・ Superintelligence Infrastructure ・ Case Studies ・ Contact

New in Pulumi IaC: `replaceWith` Resource Option

Tom Harding — Tue, 09 Dec 2025 00:00:00 +0000

The magic of Pulumi is that we rarely have to worry about the fine details of how our deployment and infrastructure management works, allowing us to focus instead on what we want. If our program declares an S3 bucket, Pulumi handles creation, updates, and deletion automatically.

Most of the time, this is exactly what we want. However, some use cases require finer-grained control over resource dependencies. Today, we’re introducing the replaceWith resource option, a new feature that gives you explicit control over replacement dependencies between resources.

Custom resource dependencies

When replacing a resource, the Pulumi engine walks the dependency graph to determine what else needs replacement. However, the answer isn’t always obvious:

Some dependencies aren’t obvious at the infrastructure level. For example, restarting a database server may require restarting its consumers to reconnect.
Provider-specific challenges exist. You might not be able to update a subnet’s properties while resources are using it, even without an observable dependency. Any subnet change must be accompanied by changes to all its consumers to avoid errors.
Application-level dependencies may exist beyond infrastructure. If two services maintain open connections in the application layer, replacing one should trigger replacement of the other.

Declaring our own dependencies

The replaceWith resource option makes these dependencies explicit in your code. Similar to deletedWith, passing references to other resources via replaceWith defines a relationship: when any target resource is replaced, the source is also replaced. This has some interesting implications:

We can define a number of resources that all replaceWith each other, and so any change to any member of the group will trigger an update to all the others.
Relationships are transitive: organizing resources hierarchically where children replaceWith their parents means any ancestor change triggers replacement of all descendants.

In code

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

const database = new aws.rds.Instance("app-db", { /* ... */ });

// The database location is provided to this instance
// by other means, so there is not an explicit dependency
// linking the two.
const app = new aws.ec2.Instance("app-service", { /* ... */ }, {
 // Here, we explicitly tie the two together: if the
 // database is upgraded, for example, we will need to
 // restart the application instance to ensure that
 // a connection is re-established.
 replaceWith: [database],
});

import pulumi
import pulumi_aws as aws

database = aws.rds.Instance('app-db', {})

# The database location is provided to this instance
# by other means, so there is not an explicit dependency
# linking the two.
application = aws.ec2.Instance('app-service', {},
 # Here, we explicitly tie the two together: if the
 # database is upgraded, for example, we will need to
 # restart the application instance to ensure that
 # a connection is re-established.
 opts=pulumi.ResourceOptions(replace_with=[database])
)

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

database, err := rds.NewInstance(ctx, "app-db", &rds.InstanceArgs{ ... })
if err != nil {
 return err
}

// The database location is provided to this instance
// by other means, so there is not an explicit dependency
// linking the two.
application, err := ec2.NewInstance(ctx, "app-service", &ec2.InstanceArgs{ ... },
 // Here, we explicitly tie the two together; if the
 // database is upgraded, for example, we will need to
 // restart the application instance to ensure that
 // a connection is re-established.
 pulumi.ReplaceWith([]pulumi.Resource{database}))
if err != nil {
 return err
}

using Pulumi;
using Aws = Pulumi.Aws;

var database = new Aws.Rds.Instance("app-db", new() { ... });

// The database location is provided to this instance
// by other means, so there is not an explicit dependency
// linking the two.
var application = new Aws.Ec2.Instance("app-service", new() { ... }, new CustomResourceOptions
{
 // Here, we explicitly tie the two together; if the
 // database is upgraded, for example, we will need to
 // restart the application instance to ensure that
 // a connection is re-established.
 ReplaceWith = new[]
 {
 database,
 },
});

import com.pulumi.aws.ec2.Instance;
import com.pulumi.aws.ec2.InstanceArgs;
import com.pulumi.resources.CustomResourceOptions;

var database = new com.pulumi.aws.rds.Instance("app-db",
 com.pulumi.aws.rds.InstanceArgs.builder()
 .build());

// The database location is provided to this instance
// by other means, so there is not an explicit dependency
// linking the two.
var application = new Instance("app-service",
 InstanceArgs.builder()
 .build(),
 // Here, we explicitly tie the two together; if the
 // database is upgraded, for example, we will need to
 // restart the application instance to ensure that
 // a connection is re-established.
 CustomResourceOptions.builder()
 .replaceWith(database)
 .build());

resources:
 database:
 type: aws:rds:Instance
 properties:
 # ...
 # The database location is provided to this instance
 # by other means, so there is not an explicit dependency
 # linking the two.
 application:
 type: aws:ec2:Instance
 properties:
 # ...
 options:
 # Here, we explicitly tie the two together: if the
 # database is upgraded, for example, we will need to
 # restart the application instance to ensure that
 # a connection is re-established.
 replaceWith:
 - ${database}

Of course, this is a simple example, but hopefully it illustrates the point: we now have a way to make implicit dependencies between resources more explicit within our programs, and provide hints to Pulumi as to which services depend on others.

Next steps

This feature is supported as of Pulumi v3.207.0, and is now available within the Go, Python, NodeJS, and Java SDKs, with C# and YAML coming soon. Thanks for reading, and feel free to reach out with any questions via GitHub, X, or our Community Slack.

Future of the Cloud: 10 Trends Shaping 2026 and Beyond

Sara Huddleston — Thu, 04 Dec 2025 07:56:40 +0000

In 2026, several trends will dominate cloud computing, driving innovation, efficiency, and scalability. From Infrastructure as Code (IaC) to AI/ML, platform engineering to multi-cloud and hybrid strategies, and security practices, let’s explore the 10 biggest emerging trends.

On This Article

1. Cloud Will Become a Business Necessity by 2028
2. Hyperscalers Accelerate AI-Driven Cloud Expansion
3. Hybrid and Multi-Cloud to Drive Innovation
4. Enterprises Rebuild Their Cloud Foundations to Operationalize AI
5. IaC Drives Scalable Cloud, Multi-Cloud, and AI Operations
6. DevSecOps Evolves Into AI-Integrated Security
7. Platform Engineering and Internal Developer Platforms
8. AIOps Matures Into a Cloud Operations Standard
9. Kubernetes Dominance and Increased Complexity
10. AI Code Assistants in the Enterprise
The Future of Cloud: Reinvented for an AI-First Decade

1. Cloud Will Become a Business Necessity by 2028

According to Gartner, by 2028 the cloud will be the key driver for business innovation, and estimates that over 95% of new digital workloads will be deployed on cloud-native platforms.

The future of cloud computing. Credit: Gartner

According to McKinsey & Company’s “In search of cloud value” report:

Cloud value is driven by innovation, worth 5x more than cost savings.
EBITDA uplift of 20–30% by 2030 for high-performing organizations.
Asia leads in projected cloud value, followed by the US and Europe.
High-ROI organizations excel by aligning cloud strategy with business priorities, building strong cloud foundations, and using modern operating models.

Teams succeeding in this transition increasingly use Infrastructure as Code, automation, and unified governance frameworks like Pulumi Insights + Policies to operationalize this value.

2. Hyperscalers Accelerate AI-Driven Cloud Expansion

Hyperscalers are making the largest infrastructure investments in cloud history — nearly all centered on AI workloads, inference, and high-performance compute.

AWS has integrated Anthropic’s Claude 3 and Claude 4 models into Amazon Bedrock for enterprise LLM workflows. “Claude Opus 4 and Claude Sonnet 4 are available today in Amazon Bedrock, enabling customers to build agents with stronger reasoning, memory, and tool use.” — AWS, May 2025
Microsoft Azure revenue rose 33% year-over-year in Q3 (ended March 31), outperforming estimates of ~29.7%. AI contributed 16 percentage points to this growth, up from 13 points in the prior quarter. “Microsoft is on track to invest approximately $80 billion to build out AI-enabled datacenters to train AI models and deploy AI and cloud-based applications around the world,” said Brad Smith, the Microsoft Vice Chair and President.
Google Cloud is committing $25 billion over two years for data center and AI infrastructure expansion across the PJM grid, with total capital expenditure for 2025 ranging from $75–85 billion. “As our CEO has said, in these early days of a very transformative technology, the risks of under-investing are dramatically higher than the risks of over-investing,” said Eunice Huang, Head of AI and Emerging Tech Policy.
Oracle anticipates 15–20% cloud revenue growth in FY 2026–2027 attributable to AI infrastructure demand, tied to its partnership in the Stargate initiative.

As hyperscalers integrate AI deeper into their service layers, engineering teams must adapt with IaC-driven automation, reusable patterns, and policy controls to deploy cloud and AI infrastructure consistently. See how organizations deploy AWS infrastructure at the speed of AI with Pulumi and Pulumi Policies.

3. Hybrid and Multi-Cloud to Drive Innovation

Hybrid and multi-cloud strategies are now mainstream:

Hybrid cloud will grow from $130B to $310–330B by 2030 (ResearchAndMarkets).
87% of enterprises run workloads across multiple clouds (Mordor Intelligence).
Gartner predicts that 40% of enterprises will adopt hybrid compute architectures in mission-critical workflows by 2028 (up from 8%).

Credit: Cloud Worldwide Service, Forbes

As AI and regulatory requirements grow, organizations must deploy workloads across AWS, Azure, Google Cloud, on-prem, and edge — while maintaining consistent security, compliance, and configuration.

Modern cloud teams use:

Infrastructure as Code for consistent multi-cloud provisioning and environment standardization, forming the backbone of AI infrastructure orchestration
Reusable components and internal platforms to define scalable architecture patterns and accelerate delivery across Kubernetes, AI/ML pipelines, and hybrid environments
Policy-driven guardrails to maintain cost, security, and compliance across environments, supporting cloud governance automation and modern cloud cost governance

Pulumi enables all three through its multi-cloud IaC model, Pulumi Policies, and internal developer platform capabilities.

4. Enterprises Rebuild Their Cloud Foundations to Operationalize AI

While hyperscalers are transforming the global cloud platform, enterprises face a different challenge: adapting their own cloud foundations to support AI at scale. Organizations are moving beyond prototypes and integrating AI into core products, internal workflows, and customer-facing systems, requiring new levels of automation, governance, and AI infrastructure orchestration.

According to Gartner, global AI infrastructure spending is expected to surpass $2 trillion in 2026. IDC predicts that by 2027, more than 50% of enterprises will use AI agents to drive core workflows, which requires scalable, secure, and automated cloud architectures to support model execution and orchestration.

To enable this transition, enterprises are investing in:

GPU provisioning and orchestration, data pipelines, vector databases, feature stores, and LLM infrastructure needed for real-time AI workloads.
Data pipelines, vector databases, and feature stores needed for real-time AI workloads
Model-serving infrastructure, including gateways, inference routers, and autoscaling layers
Strong identity, secrets, and access controls as AI systems increase security exposure
Automation through Infrastructure as Code to ensure reproducibility and reduce drift
Policy-driven governance to secure cost, compliance, and architectural consistency

As AI becomes deeply embedded across engineering organizations, teams are increasingly using software engineering approaches such as Infrastructure as Code, reusable components, platform engineering, and policy automation to standardize how AI infrastructure is deployed, scaled, and secured across clouds.

To support this shift, Pulumi’s perspective on Superintelligence Infrastructure explains why AI workloads, from pre-training to inference at massive scale, require dynamic infrastructure orchestration rather than static configuration.

Pulumi users increasingly rely on:

Pulumi IaC for standardized AI infrastructure
Pulumi ESC to manage all secrets and configuration at scale
Pulumi Insights for visibility and misconfiguration analysis
Pulumi Policies for AI-specific guardrails in code, cost detection, and to provide automated compliance protections

5. IaC Drives Scalable Cloud, Multi-Cloud, and AI Operations

As cloud environments expand and AI workloads demand highly dynamic infrastructure, Infrastructure as Code (IaC) is becoming the foundation for scaling reliably across all environments. Organizations are increasingly adopting IaC in general-purpose languages to unify development and infrastructure workflows, reduce configuration drift, and deliver cloud resources at speed.

Modern Infrastructure as Code is advancing far beyond simple provisioning:

Standardizing multi-cloud and hybrid patterns so teams can deploy consistently across AWS, Azure, Google Cloud, on-prem, and edge environments.
Integrating seamlessly with cloud providers and third-party services, including data platforms and messaging systems like CockroachDB, Confluent Cloud, and Kafka.
Providing deeper validation and type-safety, ensuring parameters, dependencies, and security controls are correct before deployment.
Improving cloud resource efficiency and visibility with tools like Pulumi Insights Discovery.
Embedding security and compliance through Policy as Code, enforcing guardrails, cost controls, and regulatory requirements automatically, enabling truly policy-driven cloud management.
Enabling intelligent automation, from unit and integration tests to auto-remediation policies and policy-driven approvals.
Incorporating AI-driven optimization and insights, helping teams detect misconfigurations, analyze usage patterns, and generate infrastructure updates with tools like Pulumi Neo and Pulumi Policies.

As organizations scale both traditional cloud workloads and AI-driven systems, IaC has become critical for achieving secure, repeatable, and high-velocity operations across every environment.

6. DevSecOps Evolves Into AI-Integrated Security

As AI becomes embedded across cloud-native systems, DevSecOps is entering a new era. Gartner predicts that by 2028, over 50% of enterprises will use AI security platforms to protect their AI investments. Below are the 3 key predictions for the future of DevSecOps:

AI-driven security automation: Teams will increasingly rely on AI to detect threats, enforce policies, and generate secure infrastructure patches. See Pulumi’s capabilities in AI-powered remediation.
More focus on secrets management: With AI systems accessing more sensitive data, secure secret storage will be essential. Pulumi ESC helps teams centralize and govern credentials, keys, and tokens safely.
Greater cross-team collaboration: Dev, Sec, and Ops workflows will converge under shared frameworks: IaC, policy automation, runtime scanning, and GitOps.

As organizations increase their use of AI across cloud-native systems, the need for tightly aligned security, governance, and cloud governance automation becomes even more urgent. At the Gartner Data & Analytics Summit in Sydney, Carlie Idoine, VP Analyst at Gartner, emphasized this growing dependency:

"[AI]… it doesn’t deliver value on its own – AI needs to be tightly aligned with data, analytics, and governance to enable intelligent, adaptive decisions and actions across the organization."

This perspective mirrors what we’re seeing across modern DevSecOps practices: AI can amplify security, but only when paired with strong foundations in secrets management, governance, and cross-team collaboration.

7. Platform Engineering & Internal Developer Platforms (IDPs)

According to Gartner, by 2026, 80% of large software engineering organizations will establish platform engineering teams as internal providers of reusable services, components, and tools for application delivery. Platform engineering will ultimately solve the central problem of cooperation between software developers and operators.

Mid-size to large companies will begin or continue to invest in implementing platform engineering practices, with large tech companies as first adopters. They will provide Internal Developer Platforms (IDP) to elevate the Developer Experience (DX, sometimes referred to as DE or DevEx), helping them work faster, like abstracting the complexities of configuring, testing, and validation, deploying infrastructure, and scanning their code for security.

Internal developer platform-in-a-box. Credit: Pulumi

IDPs are reshaping how developers interact with cloud infrastructure, bringing together platform engineering, automation, and emerging AI platform engineering practices.

8. AIOps Matures into a Cloud Operations Standard

AIOps is becoming mainstream, helping teams predict failures, auto-scale infrastructure, and resolve incidents with minimal manual effort. As AI and automation continue to evolve, the fusion of these technologies will enable organizations to achieve unprecedented levels of efficiency and scalability.

Proactive Operations: AI-powered tools will assist teams in foreseeing issues with greater accuracy, minimizing downtime, and reducing the firefighting nature of incident management. These tools will automatically detect anomalies, optimize performance, and trigger remediation actions.
Intelligent Automation: Routine operational tasks like patching, monitoring, and resource scaling will be fully automated. AI-driven decision-making will allow for smarter resource allocation and optimization, dynamically adjusting infrastructure and workloads in response to real-time demands and predictions.
Data-Driven Insights: AIOps will analyze vast amounts of operational data and provide actionable insights, enabling teams to focus on high-impact tasks such as improving system architecture and user experience. The AI-powered insights will also inform better strategic decisions, helping teams to continuously evolve their DevOps practices.
Collaboration Across Teams: AIOps will bridge the gap between DevOps, SecOps, and IT operations by bridging monitoring and automation. Cross-team collaboration will improve as AI systems consolidate and interpret data from various departments, allowing for a more cohesive approach to system management.

AIOps features include observability, automation, and real-time analytics to bridge DevOps, SRE, and IT operations.

9. Kubernetes Dominance and Increased Complexity

Kubernetes will continue its ascent in 2026. According to Research & Markets, the global Kubernetes market was valued at USD 2.3 billion in 2024 and is projected to reach USD 8.2 billion by 2030, with a CAGR of 23.8% over the forecast period.

The CNCF Annual Survey shows AI/ML workloads rapidly moving onto Kubernetes — including batch pipelines, model experimentation, real-time inference, and data preprocessing — even as only 41% of ML/AI developers are cloud-native today. This shift is accelerating as teams need flexible GPU scheduling, distributed pipelines, and portable execution environments.

Kubernetes is also evolving in response to AI demands. Inference workloads, powered by LLMs and GPUs, now require low-latency execution closer to the user. This shift is pushing organizations to build intelligent orchestration layers that schedule AI pipelines across edge and core clusters, often leveraging Kubernetes as the common control plane for AI cluster orchestration.

As we move into 2026, three patterns are becoming clear:

Kubernetes is evolving to support AI through GPU-aware scheduling, Kubernetes GPU scheduling optimizations, and more advanced workload orchestration.
Governance and consistency matter more than ever, as teams struggle to secure and manage multi-cluster, multi-cloud environments.
Platform engineering is essential, providing curated patterns and automation rather than raw YAML to reduce cognitive load.

Kubernetes will remain a strategic foundation — but operating it effectively now depends on robust automation, strong security controls, and standardized delivery models that scale across clouds, clusters, and AI pipelines.

10. AI Code Assistants in the Enterprise

AI-powered coding assistants like GitHub Copilot, Claude Code, Cursor, and others are rapidly becoming part of modern software development.

By 2027, the use of AI assistants will dramatically increase developer velocity to meet functional business requirements for 70% of new digital solutions in production (source: IDC).

The value of AI code assistants. Credit: Gartner

According to Gartner, by 2028, 75% of enterprise software engineers will use dedicated AI code assistants, and 63% of organizations are currently piloting, deploying or beginning to use AI code assistants.

As enterprise adoption of AI assistants increases, expectations are rising: they must not only generate code but also understand the state of infrastructure, configurations, and security posture. That means being able to answer questions about environments, surface misconfigurations, or act directly on infrastructure.

One of the newest developments is the release of Pulumi Agent Skills, a collection of infrastructure expertise packaged for use in AI coding assistants. These skills teach tools such as Claude Code, Cursor, or Gemini CLI to reason about Pulumi projects, reducing hallucination and improving outputs based on real infrastructure conventions and practices.

Combined with infrastructure access via tools like Pulumi’s Remote MCP Server, teams can build secure, AI-driven workflows where assistants provide insights and Pulumi Neo safely executes actions with previews, policies, and orchestration.

AI code assistants are no longer experimental; they’re fast becoming a competitive advantage in cloud software development.

The Future of Cloud: Reinvented for an AI-First Decade

Cloud infrastructure is entering its most transformative era since the rise of Kubernetes. The trends shaping 2026 reveal a clear pattern: AI is no longer a workload — it’s becoming the organizing principle of cloud strategy.

AI-native cloud architectures that require elastic compute, GPU orchestration, fast data access, and governance built into every layer
Infrastructure as Code as the operational backbone, standardizing deployments across AI, cloud, and hybrid environments
Platform engineering and IDPs to enable self-service, gold-standard patterns, and automated guardrails
Security integrated into every pipeline, with AI-assisted threat detection, strong secrets management, and policy-driven compliance
AIOps and intelligent automation are becoming standard for scaling modern cloud systems
Kubernetes evolving for AI, driving new orchestration patterns across edge, core, and inference clusters
Multi-cloud and hybrid ecosystems accelerating to support interoperability, resilience, and global workload placement

Taken together, these shifts point to a new model of cloud operations that is intelligent, automated, policy-aware, and built on software engineering principles rather than manual configuration.

Organizations that invest now in modern IaC, unified governance, reusable components, and policy frameworks — all core capabilities of the Pulumi Cloud platform — will be positioned to lead in an AI-first world. The gap between teams that modernize and those that do not will widen rapidly in 2026 and beyond.

Try Pulumi for Free

Pulumi Kubernetes Operator v2.3.0: Preview Mode and Structured Configuration

Eron Wright — Tue, 25 Nov 2025 00:00:00 +0000

We’re excited to announce the release of Pulumi Kubernetes Operator v2.3.0, introducing two powerful capabilities that enhance GitOps workflows: preview mode for validating infrastructure changes before deployment, and structured configuration support for managing complex data types. Building on the success of the v2.0 GA release, this update addresses long-standing community requests while maintaining full backwards compatibility. These features enable safer, more sophisticated infrastructure management patterns for platform engineering teams.

Preview mode: Validate infrastructure changes before deployment

Preview mode enables you to run Pulumi stacks in dry-run fashion, allowing you to visualize what infrastructure changes would occur without actually applying them. This capability is essential for GitOps workflows that require validation gates and incremental rollouts.

By adding preview: true to your Stack specification, the operator runs pulumi preview instead of pulumi up. The Stack’s Ready condition indicates preview success, and you get full status including preview links, standard output, and program outputs—all without making actual infrastructure changes.

This unlocks sophisticated workflow patterns:

Multiple Stacks for what-if analysis: Create several Stack resources pointing to the same Pulumi stack, with all-but-one operating in preview mode to compare different configurations
Branch validation: Preview changes from feature branches before merging to production
Tick-tock rollout patterns: Toggle the preview flag on and off with external verification steps between each deployment phase

Here’s a simple example showing a production stack alongside its preview counterpart:

# Production stack
apiVersion: pulumi.com/v1
kind: Stack
metadata:
 name: my-infrastructure
spec:
 stack: org/project/prod
 projectRepo: https://github.com/example/infra
 branch: main
---
# Preview stack - same Pulumi stack, preview mode
apiVersion: pulumi.com/v1
kind: Stack
metadata:
 name: my-infrastructure-preview
spec:
 stack: org/project/prod
 projectRepo: https://github.com/example/infra
 branch: feature-branch
 preview: true # Only runs pulumi preview

Preview mode closes issue #16, one of our longest-standing feature requests.

Structured configuration: Native support for complex data types

Configuration management takes a significant step forward with native support for complex data types. Previously limited to string values, Stack configuration now supports objects, arrays, numbers, and booleans as first-class citizens.

This enhancement addresses the reality that complex environments require rich configuration. You can now express sophisticated configuration structures inline in your Stack manifests or load them from ConfigMaps with automatic JSON parsing—all using Kubernetes-native patterns.

The implementation leverages Pulumi CLI’s JSON configuration support (available in v3.202.0+) with automatic version detection. If your workspace uses an earlier CLI version, you’ll receive clear guidance to upgrade. Existing string-only configurations continue to work without modification, ensuring full backwards compatibility.

Here’s an example of inline structured configuration:

apiVersion: pulumi.com/v1
kind: Stack
metadata:
 name: my-app
spec:
 stack: org/app/prod
 projectRepo: https://github.com/example/app
 branch: main
 config:
 # String values (existing behavior)
 environment: "production"

 # Objects (NEW)
 database:
 host: "db.example.com"
 port: 5432
 ssl: true

 # Arrays (NEW)
 regions: ["us-west-2", "us-east-1", "eu-west-1"]

 # Numbers and booleans (NEW)
 maxConnections: 100
 enableCaching: true

You can also reference ConfigMaps for more complex scenarios:

apiVersion: v1
kind: ConfigMap
metadata:
 name: app-settings
data:
 database.json: |
 {
 "host": "db.example.com",
 "port": 5432,
 "maxConnections": 100
 }
---
apiVersion: pulumi.com/v1
kind: Stack
metadata:
 name: my-app
spec:
 stack: org/app/prod
 projectRepo: https://github.com/example/app
 branch: main
 configRefs:
 database:
 name: app-settings
 key: database.json
 json: true # Parse as JSON

Note that Secrets are not a supported source of structured configuration values.

Structured configuration closes issue #258 and issue #872, addressing long-standing configuration management needs from the community.

Bug fixes and reliability improvements

This release includes several fixes that improve operational reliability:

Stack name validation: Added validation to limit Stack names to 42 characters, preventing resource naming conflicts (#899)
secretsProvider fix: The secretsProvider parameter now properly applies when creating new stacks (#935)
Helm chart fix: Resolved YAML parsing errors for podLabels containing special characters like colons (#1014)
Stack deletion: Stack deletion is no longer blocked when prerequisite stacks are missing, enabling proper cleanup workflows (#751)
Update TTL: Completed Update objects now respect the ttlAfterCompleted setting for automatic garbage collection (#960)

Upgrading to v2.3.0

This release includes updates to the Custom Resource Definitions (CRDs) to support the new features. If you’re using Helm, you’ll need to manually apply the updated CRDs before upgrading, as Helm v3 does not automatically upgrade CRDs:

# Apply updated CRDs
kubectl apply --server-side -k 'github.com/pulumi/pulumi-kubernetes-operator//operator/config/crd?ref=v2.3.0'

# Upgrade via Helm
helm upgrade pulumi-kubernetes-operator \
 oci://ghcr.io/pulumi/helm-charts/pulumi-kubernetes-operator \
 --version 2.3.0 \
 -n pulumi-kubernetes-operator

If you’re using the quickstart YAML installation method, the CRDs will update automatically when you apply the new manifest.

All changes are backwards compatible—existing Stack resources work without modification. For structured configuration support, ensure your workspace pods use Pulumi CLI v3.202.0 or later; the operator provides automatic version detection with clear upgrade guidance when needed.

Get started today

The v2.3.0 release enhances the Pulumi Kubernetes Operator with safer deployment workflows and more flexible configuration management. Preview mode enables validation-first GitOps patterns, while structured configuration simplifies complex multi-environment setups.

Get started with the Pulumi Kubernetes Operator in our documentation, or view the complete v2.3.0 release notes on GitHub. Join the conversation in the Pulumi Community Slack #kubernetes channel—we’d love to hear how these features impact your workflows.

All Pulumi CLI flags are now supported as environment variables

Tom Harding — Fri, 21 Nov 2025 00:00:00 +0000

With the release of Pulumi v3.208.0, all CLI flags can now be configured as environment variables. This addresses a common friction point of having to remember the same flags across multiple commands and of ensuring that your entire team uses consistent CLI options.

Use cases

An example use case might be that you want to always refresh state before operations, or re-run programs during refresh and destroy (using --run-program). But remembering to add --refresh every time is tedious.

Another example is you’re working on a specific subset of your infrastructure and need to pass the same --target or --exclude flags repeatedly across multiple operations.

You’re working in a CI environment where you want to skip interactive prompts and previews. That means adding --yes and --skip-preview to every single command in your pipeline.

The usual workaround, if there is no env var already, is writing wrapper scripts or shell aliases, but these become another thing to maintain and share across your team.

How it works

Any CLI flag can now be set as an environment variable. The naming convention is straightforward: prefix the flag name with PULUMI_OPTION_, and convert dashes to underscores.

For example:

export PULUMI_OPTION_REFRESH=true

Target specific resources without repeating flags:

export PULUMI_OPTION_TARGET=foo,bar
# Equivalent to: --target foo --target bar

This works for any flag the CLI accepts. The environment variable takes precedence if you don’t explicitly pass the flag on the command line.

Using with direnv for project-level defaults

This becomes particularly useful when combined with tools like direnv. You can define project-specific CLI defaults in a .envrc file at the root of your project:

# Enable very verbose logging for debugging purposes
export PULUMI_OPTION_VERBOSE=3

# Always refresh before any Pulumi operation
export PULUMI_OPTION_REFRESH=true

# Skip previews and any dialogs or user prompts
export PULUMI_OPTION_YES=true
export PULUMI_OPTION_SKIP_PREVIEW=true

Now, running direnv allow . in this directory means that, whenever we access this directory, these options will be automatically applied to all commands that we run until we leave the directory!

Wrapping up

We hope that this change makes Pulumi much easier to configure across a range of different environments, and gives you another tool for managing operation defaults across your team. Thanks for reading, and feel free to share any feedback on GitHub, X, or our Community Slack.

Beyond YAML in Kubernetes: The 2026 Automation Era

Sara Huddleston — Wed, 12 Nov 2025 07:09:46 +0000

Kubernetes continues to evolve, powering not only applications but entire AI and ML systems across clouds, edges, and enterprises. By 2026, DevOps engineers, SREs, cloud engineers, and platform teams face growing pressure to deliver faster, smarter, and more secure infrastructure at scale.

Kubernetes automation is entering a new era where infrastructure as code, policy enforcement, and AI-driven orchestration work together to manage cloud environments intelligently.

Pulumi’s 2025 advancements, including Pulumi Kubernetes Operator 2.0 GA, new Kubernetes best practices playbooks, Pulumi Neo for AI assisted infrastructure management, and Policy Automation, set the foundation for a new era of Kubernetes automation that extends across every role involved in managing modern infrastructure.

In this Kubernetes article:

Why Kubernetes Needs to Go Beyond YAML

The article Kubernetes Best Practices I Wish I Had Known Before highlights a key challenge: relying solely on YAML as the source of truth for Kubernetes is no longer sustainable. Clusters are dynamic, environments multiply, and static YAML files cannot keep up with the complexity of modern infrastructure.

Teams across disciplines face similar challenges:

Multi-cluster and hybrid-cloud sprawl
Inefficient manual configuration and drift
Lack of policy enforcement and governance at scale
Secrets scattered across systems

Pulumi addresses these challenges by introducing general-purpose programming languages such as TypeScript, Python, Go, C#, and Java into Kubernetes management. This approach enables teams to define, test, and share reusable infrastructure code, bridging the gap between declarative manifests and modern software engineering practices.

Learn more: Pulumi Kubernetes documentation

The 2026 Convergence of AI, Platforms, and Policy in Kubernetes

The CNCF State of Cloud Native Development Q3 2025 report shows that more than half of DevOps professionals and nearly a third of all developers now identify as cloud native. Adoption of hybrid and multi-cloud architectures continues to grow, while AI and ML workloads are becoming first-class citizens in Kubernetes environments. The report notes that 41% of professional ML and AI developers are cloud native, confirming that Kubernetes has become a foundational technology for building intelligent, scalable systems.

This trend highlights how the next generation of Kubernetes operations is evolving. Teams need unified platforms that simplify AI-driven workloads, automatically enforce governance, and reduce operational complexity across environments. Pulumi already delivers this through an integrated platform that brings automation, security, and developer productivity together in one place.

Pulumi’s platform provides a complete foundation for intelligent infrastructure management that extends from development to production.

Pulumi Neo adds AI-assisted infrastructure management that turns natural language into production-ready Kubernetes and cloud code.
Pulumi IDP enables engineering and platform teams to build self-service environments that abstract complexity for developers while maintaining consistency and control.
Pulumi Policies brings continuous compliance and policy enforcement directly into the delivery workflow.
Pulumi ESC secures credentials, API keys, and sensitive configurations across Kubernetes and cloud environments.

Together, these capabilities form a unified automation and governance layer for Kubernetes and cloud native systems.

The result is a model where infrastructure, policy, and developer experience work together to power secure, scalable, and AI-ready platforms that meet the needs of engineering teams of every size and discipline, from application development to security and cloud operations.

The 2026 Shift: AI-Assisted Kubernetes Operations

The next phase of Kubernetes management will be AI-driven, context-aware, and self-healing. Infrastructure will not only follow instructions but also understand intent. This is the vision behind Pulumi Neo, an AI Infrastructure Agent designed to help teams automate complex systems.

Pulumi Neo can interpret natural-language requests such as “deploy a GPU-backed EKS cluster with three node groups,” generate infrastructure code that adheres to organizational policies, and continuously refine that code as environments change.

AI-powered observability and decision-making. According to the CNCF Annual Survey, 93% of organizations already use or plan to adopt AI-driven monitoring and predictive analysis for Kubernetes environments. The goal is to identify performance and reliability issues before they affect users. Pulumi Policies assists to get clean and stay clean, while Neo extends this capability by acting on those insights, transforming detected issues into actionable infrastructure updates that teams can validate or deploy.
ML and GPU workloads on Kubernetes. As organizations expand AI and ML pipelines across clusters, automation and cost efficiency become critical (FinOps Foundation). Pulumi Insights is an intelligent infrastructure management service that helps you discover, understand, manage, and improve your infrastructure. Insights improves security, compliance, and efficiency through AI-powered asset and compliance management.
Unifying DevOps, SRE, and MLOps workflows. The convergence of software and model delivery continues to accelerate (TechRadar). Pulumi’s code-based approach, combined with Neo’s agentic reasoning, creates a unified workflow for infrastructure, applications, and AI systems.

Additional insights and demonstrations:

Kubernetes and Pulumi Neo together represent a future of autonomous infrastructure management, where AI assists teams in deploying, maintaining, and improving their environments intelligently and securely.

Operator-First: Kubernetes Deploys Your Cloud

The Pulumi Kubernetes Operator 2.0 GA introduced a Kubernetes-native approach to infrastructure management. Each Pulumi stack becomes a Kubernetes Custom Resource, allowing Kubernetes itself to execute Pulumi programs written in any supported language. This enables:

Management of AWS, Azure, and GCP infrastructure from within the cluster
Integration with GitOps systems such as Argo CD and Flux
Continuous reconciliation and drift detection through Pulumi’s state and policy engine

With the new Pulumi Kubernetes Operator 2.3, the operator gets even more production-ready features:

Faster and more resilient stack updates through improved workspace lifecycle management
Support for multi-namespace and multi-tenant deployments
Better visibility with enhanced events, status reporting, and error surfacing
Performance improvements for large-scale environments and parallel stack operations

Documentation: Using the Pulumi Kubernetes Operator

Intelligent Infrastructure Across Every Cloud

Kubernetes has become the control plane for everything from application deployments to AI and ML workloads across clouds and environments. Engineering teams are running clusters on Amazon EKS, Microsoft AKS, and Google GKE while also managing edge, hybrid, and on-premises environments. Pulumi extends Kubernetes automation across all of them, unifying clusters, workloads, and cloud resources under a consistent model of infrastructure as code.

With Pulumi, teams can use familiar programming languages to define Kubernetes resources, cloud infrastructure, and policies together. This approach provides a single workflow for managing compute, networking, storage, and identity across multiple clouds without relying on brittle YAML templates. It enables consistent provisioning, policy enforcement, and automation across every cluster and environment.

By treating Kubernetes as the universal control plane for cloud infrastructure, Pulumi gives teams a scalable foundation that adapts to any workload and environment. The result is an intelligent, multi-cloud Kubernetes infrastructure that combines the flexibility of cloud providers with the reliability of modern automation.

Bring Your YAML and Helm, Then Evolve

Teams do not need to start from scratch. Pulumi supports importing existing YAML manifests and Helm charts to help organizations adopt a code-first approach incrementally. Many teams begin by wrapping existing manifests in Pulumi code, then refactor them into reusable components that enforce best practices and compliance policies.

This hybrid approach enables modernization without disrupting existing CI/CD pipelines or team workflows.

Begin Your Kubernetes Automation Journey

For teams preparing for the next phase of Kubernetes management in 2026:

Get Started with Kubernetes to create your first Pulumi program.
Add the Pulumi Kubernetes Operator to enable infrastructure deployments from within your clusters.
Integrate GitOps workflows with Argo CD, Flux, or Jenkins X.
Apply policy guardrails to enforce security and compliance automatically.
Refactor infrastructure into reusable components for consistent, scalable operations.

Agentic Workflows for Production-ready Kubernetes

Experience Kubernetes automation in practice. See how agentic workflows power production-ready Kubernetes by automating GitOps operations, managing environments, and reducing manual effort in this on-demand workshop.

Watch Agentic Workflows for Production-ready Kubernetes to learn how to:

Provision and manage clusters across clouds using general-purpose programming languages
Multi-cloud Kubernetes infrastructure management
Fleet management with GitOps (Argo CD)
Reduce YAML complexity while maintaining reliability and speed

Watch On Demand.

Final Thoughts

Kubernetes in 2026 and beyond is not just for platform engineers. It is for DevOps professionals, SREs, and cloud teams, big and small, responsible for maintaining infrastructure security, reliability, and performance. Pulumi unifies infrastructure as code, secrets management, policy governance, and AI automation into a single platform, enabling every team to adopt an intelligent, code-driven approach to Kubernetes that scales across workloads, clouds, and the AI-driven future.

Try Pulumi for Free

Grounded AI: Why Neo Knows Your Infrastructure

Engin Diri — Fri, 24 Oct 2025 00:00:00 +0000

Ask a generic LLM to “fix my broken deployment,” and you’ll get generic advice. Ask Pulumi Neo the same question, and you’ll get a fix plan grounded in your actual infrastructure state.

The difference isn’t about better prompts or newer models. It’s about what the AI actually knows. Generic LLMs have been trained on the internet. Neo has been trained on your infrastructure.

This distinction matters more than you’d think.

The grounding problem

Most AI tools treat infrastructure like a text generation problem. You describe what you want, the model produces code, and you hope it works.

This approach fails more often than it succeeds because the AI has no connection to your actual infrastructure. It doesn’t know what resources you’ve already deployed, what dependencies exist, or what policies you need to follow. It’s generating code from patterns it learned on the internet, not from understanding your environment.

Pulumi Neo takes a different approach. It’s trained on your infrastructure context: your programs, your state, your resource relationships. When you ask Neo about drift, it doesn’t guess. It queries your actual deployment history. When it suggests a fix, it reasons from your program graph, not generic examples.

Neo doesn’t just autocomplete code. It understands state, resources, dependencies, and cloud behavior. When something fails, Neo explains why, not just what.

This is what makes it grounded AI: it’s anchored to the reality of your infrastructure, not floating in a sea of internet-trained probabilities.

What makes Neo different

The foundation matters more than you’d think.

Traditional AI tools fail in DevOps because they operate in a vacuum. Ask a generic LLM to “fix my broken deployment,” and you’ll get generic advice that ignores your specific infrastructure, your state, your constraints.

The difference with systems like Pulumi Neo comes down to what powers them: not just data, but context.

Think of it this way: a data lake is a massive repository of information sitting inert, waiting to be queried. A context lake is something else entirely. It’s a structured repository that aggregates knowledge about your domain and feeds it to AI systems.

A context lake contains things that matter:

Your infrastructure programs, resource definitions, API schemas, service dependencies. In Pulumi’s case, this includes your program graph, component models, stack configurations.

Real-time metrics, deployment history, drift detection, policy violations. The live pulse of your infrastructure as it actually runs in production.

Ownership information, compliance policies, access controls, quality signals. The organizational context that determines what changes are safe, who can make them, and why they matter.

Pulumi’s approach builds on this principle. Your infrastructure programs, state files, resource metadata, policy definitions. All of this becomes queryable context. Neo doesn’t hallucinate solutions because it’s grounded in your actual infrastructure. It knows what you’ve deployed, how resources relate to each other, what dependencies exist, what’s drifted.

This is the architectural shift that makes AI-powered DevOps actually work. AI agents are only as effective as the context they can access and the guardrails you have in place to keep them in check. You’re not just automating actions anymore. You’re automating understanding.

Grounded reasoning in practice

Early DevOps automated actions. Modern AI agents automate decisions. But grounded AI does something different: it automates understanding.

When you combine observability data, infrastructure-as-code programs, and deployment history into a context lake, the AI doesn’t just predict what might happen. It reasons about what is happening based on your actual infrastructure state.

Neo can watch infrastructure drift, identify whether it stems from a manual change or a misconfigured resource, and generate a fix plan that maps back to your Pulumi program. That feedback isn’t guesswork. It’s grounded in the same infrastructure metadata developers already use. The context lake ensures Neo isn’t making probabilistic predictions. It’s reasoning from your specific infrastructure truth.

This is what separates grounded AI from generic LLMs. Neo doesn’t just automate deployment. It understands the intent behind it.

The human layer stays critical

Grounded AI doesn’t replace engineering judgment. Every engineer who’s tried to prompt a generic LLM to “write a Pulumi program for me” knows how quickly hallucinations creep in. You still need human context: the judgment to choose the right platform, the discipline to model dependencies, the awareness of compliance and cost.

That’s where grounded AI like Neo fits best. It’s not a chatbot for infrastructure. It’s an extension of your own reasoning.

Neo learns from the same program graph and state data you already manage, drawing from a continuously updated context lake of your infrastructure reality. Its recommendations stay grounded in your environment, not floating in a generic prompt window trained on the public internet.

The opportunity isn’t about replacing engineers. It’s about creating smarter feedback loops between human expertise and AI that actually understands your infrastructure.

What grounded AI enables

The first generation of DevOps automated deployment. Grounded AI automates understanding.

Infrastructure becomes queryable. AI-powered observability correlates incidents before they cascade. CI/CD becomes continuous reasoning rather than continuous execution. Platform teams spend less time fighting YAML and more time guiding systems that reason alongside them.

The context lake architecture makes this possible. Instead of static documentation and scattered tribal knowledge, your infrastructure context becomes something AI agents can actually query and reason over.

Grounded AI won’t replace engineers. But it will change what engineering means: less time translating intent into YAML, more time reasoning about systems at a higher level.

Try it yourself

Want to see what infrastructure cognition looks like in practice? Get started with Neo and ask it about your infrastructure. Watch it reason through drift detection, generate fix plans, or explain complex resource relationships in plain English. For a wider survey of the category, see our guide to the best AI infrastructure tools.

Neo is available today for teams using Pulumi Cloud. The cognitive layer isn’t coming. It’s already here.

Day 2 Operations: Drift Detection and Remediation

Mitch Gerdisch — Fri, 24 Oct 2025 00:00:00 +0000

Welcome to the fourth post in our IDP Best Practices series. Today we’re diving into the world of drift detection and remediation, those critical day 2 operations that keep your infrastructure aligned with its intended configuration long after the initial deployment.

You’ve built a beautiful platform with robust guardrails, comprehensive templates, and well-defined golden paths. Your developers are productive, deployments are smooth, and everything seems perfect. Then reality hits. An on-call engineer makes an emergency change through the AWS console during a 3 AM incident. A team member tweaks a security group rule to debug a connection issue and forgets to revert it. Auto-scaling adjusts capacity based on load patterns. Before you know it, your actual infrastructure has quietly diverged from what your code describes.

This post continues our journey through the IDP Best Practices series. We’ve covered strategy and self-service infrastructure, built golden paths with components and templates, and established deployment guardrails through policy as code. Now we’re tackling what happens after deployment when the real world starts making changes to your carefully crafted infrastructure.

Series roadmap:

How to Build an Internal Developer Platform: Strategy, Best Practices, and Self-Service Infrastructure
Build Golden Paths with Infrastructure Components and Templates
Deployment Guardrails with Policy as Code
Day 2 Operations: Drift Detection and Remediation (you are here)
Extend Your IDP for AI Applications: GPUs, Models, and Cost Controls
Next-Gen IDPs: How to Modernize Legacy Infrastructure with Pulumi

The Reality of Infrastructure Drift

Let me paint you a picture that might feel uncomfortably familiar. It’s Saturday afternoon, and you’re enjoying a barbecue with friends when your phone buzzes with that dreaded alert: production is down. You rush to your laptop, but you’re not on the corporate VPN. The AWS console is accessible, but you can’t reach the application itself to properly diagnose the issue.

Faced with a growing incident and impatient stakeholders, you make a quick decision. You modify the security group directly in the console, temporarily allowing access from anywhere (0.0.0.0/0) just so you can get in and fix the problem. Twenty minutes later, the issue is resolved, everyone’s relieved, and you return to your barbecue. That temporary security group change? It stays there, a silent time bomb waiting to be discovered in your next security audit.

This scenario plays out in organizations every day. Your infrastructure has now drifted from its intended state, and it will continue drifting, accumulating more changes, until someone or something notices and fixes it. Each untracked change increases the gap between what you think you have and what actually exists in production.

Understanding the Prevention vs. Detection Paradigm

When building a robust platform, you need to think in layers of defense. Your first instinct might be to prevent all drift from happening in the first place, and that’s absolutely the right starting point. But prevention alone isn’t enough in the messy reality of production operations.

Prevention: The First Line of Defense

Prevention is what we’ve been building throughout this series. You establish code reviews where teammates scrutinize infrastructure changes before they go live. You implement automated testing that validates configurations before deployment. You deploy CrossGuard policies that act as guardrails, blocking misconfigurations before they can cause damage. You create standardized components that encode best practices, making it easier to do the right thing than the wrong thing.

These preventative measures work brilliantly for changes that flow through your normal IaC pipeline. They catch typos, enforce standards, and maintain consistency across your infrastructure. But they have a critical blind spot: they can’t see changes that bypass your pipeline entirely.

Detection and Remediation: The Safety Net

This is where drift detection enters the picture. Think of it as continuous verification, constantly comparing what should exist with what actually exists. While prevention blocks most issues at the gate, detection catches everything that finds another way in.

What kinds of changes slip past prevention? Emergency modifications made during incidents when there’s no time for a proper code review. Console changes made by well-meaning engineers debugging production issues. External factors you can’t control, like AWS changing service limits or deprecating API endpoints. Even accidental modifications by team members who thought they were in the staging environment.

The truth is, no matter how robust your preventative controls, you need detective controls to maintain infrastructure integrity. Prevention and detection work together, creating a comprehensive defense against infrastructure chaos.

What Is Infrastructure Drift?

Infrastructure drift sounds technical, but the concept is surprisingly simple. Drift occurs when your actual infrastructure state doesn’t match your declared state in code. It’s the gap between intention and reality, between what you coded and what’s actually running.

To understand drift properly, you need to grasp three distinct states that Pulumi manages. First, there’s the desired state, which is what your Pulumi program declares in code. This is your intention, your blueprint for how things should be. Then there’s the current state, stored in Pulumi’s state file, which tracks what Pulumi believes exists based on its last interaction with your cloud provider. Finally, there’s the actual state, the ground truth of what really exists in your cloud provider right now.

The journey to drift typically follows a predictable pattern. You start by running pulumi up to deploy your resources, and everything is in perfect harmony. Pulumi creates the resources, records their configuration in its state file, and all three states align perfectly. Time passes, and your resources continue running in the cloud, serving traffic and doing their job.

Then someone makes a manual change. Maybe they modify a resource directly in the console, or an external system alters a configuration. Suddenly, your actual state has diverged from both your current state (what Pulumi thinks exists) and your desired state (what your code says should exist). You now have drift, and it will persist until you detect and address it.

Pulumi’s Drift Detection and Remediation Workflow

Pulumi provides a complete workflow for handling drift that’s both powerful and surprisingly straightforward. Rather than treating drift as an exceptional case, Pulumi makes it a routine part of infrastructure management.

1. Drift Detection with `pulumi refresh`

The foundation of drift detection is the pulumi refresh command. When you run this command, Pulumi springs into action, querying your cloud providers to discover the actual state of your resources. It then compares this reality against what it has recorded in its state file:

# Run drift detection
pulumi refresh --preview-only

# This command:
# 1. Reads your current Pulumi state
# 2. Queries cloud providers for actual resource configurations
# 3. Identifies any differences
# 4. Reports what has drifted

The --preview-only flag is particularly useful here. It shows you exactly what’s drifted without making any changes to your state file. You get a clear report of the differences, allowing you to review and understand the drift before deciding how to handle it.

2. State Reconciliation with `pulumi refresh`

After reviewing the drift, you face a decision. If the changes are legitimate and should be preserved, you can update your state file to match reality:

# Update state file to match cloud reality
pulumi refresh

# This command:
# 1. Detects drift (as above)
# 2. Updates state file to match actual cloud state
# 3. Prepares for remediation via pulumi up

This reconciliation step is crucial. It acknowledges the current reality and updates Pulumi’s understanding of your infrastructure without making any actual changes to your resources. You’re essentially telling Pulumi, “This is what actually exists right now.”

3. Drift Remediation with `pulumi up`

With your state file now reflecting reality, you can use pulumi up to remediate the drift. This command compares the updated state against your code and determines what changes are needed to restore your infrastructure to its intended configuration:

# Remediate drift - restore to desired state
pulumi up

# This command:
# 1. Compares updated state with your Pulumi program
# 2. Identifies required changes
# 3. Applies changes to restore infrastructure

This three-step dance of detect, reconcile, and remediate gives you complete control over how you handle drift. You can review changes, decide whether to keep or revert them, and ensure your infrastructure returns to its intended state.

Automating Drift Detection with Pulumi Deployments

Running pulumi refresh manually works great for small teams and simple infrastructures, but it doesn’t scale. As your platform grows to dozens or hundreds of stacks across multiple environments, manual drift detection becomes impossible. This is where Pulumi Deployments transforms drift detection from a manual chore into an automated safeguard.

Setting Up Automated Drift Detection

The journey to automated drift detection starts with connecting your infrastructure code to Pulumi’s deployment system. Let’s walk through the setup process.

Step 1: Configure Deployment Settings

Your first step is connecting Pulumi to your source control system using Deployment Settings. This integration allows Pulumi to access your infrastructure code and run automated operations:

Pulumi offers native integrations with all major version control systems. If you’re using GitHub, you get full app integration with PR previews, making it easy to see the impact of changes before merging. GitLab users enjoy similar functionality with merge request automation. For other Git providers or self-hosted solutions, you can use raw Git integration with direct repository access using credentials.

Step 2: Create Drift Detection Schedules

With your source control connected, you can now configure automated drift detection to run on whatever schedule makes sense for your organization. Some teams check hourly for production environments, while others might run daily checks for development stacks:

For environments where you’re confident in your automation, you can take it a step further and enable automatic remediation:

With auto-remediation enabled, Pulumi not only detects drift but automatically runs pulumi up to restore your infrastructure to its intended state. This is powerful but should be used carefully, especially in production environments.

Step 3: Configure Webhooks for Notifications

Detecting drift is only valuable if the right people know about it. Pulumi’s webhook system ensures your team stays informed when drift occurs:

You can route notifications wherever your team actually pays attention. Send alerts directly to Slack channels where your ops team congregates. Push notifications to Microsoft Teams if that’s your collaboration platform. Use custom webhooks to integrate with PagerDuty, Datadog, or any other monitoring system. You can even use deployment triggers to automatically run dependent stacks when drift is detected and fixed.

Handling Common Drift Scenarios

Every organization faces similar drift scenarios. Understanding how to handle these common cases will prepare you for real-world operations.

Scenario 1: Emergency Hotfix

The most common drift scenario occurs during incidents. Someone makes an emergency change to fix production, and now you need to decide whether to keep or revert that change:

# 1. Acknowledge the drift
pulumi refresh --stack production

# 2. Review the changes
pulumi preview --stack production

# 3. Either incorporate or revert
# Option A: Accept the change
pulumi refresh --stack production --yes

# Option B: Revert to code
pulumi up --stack production --yes

The key here is having a clear process. First, acknowledge the drift by running refresh to update your state. Then review the changes carefully. Finally, make an explicit decision: either accept the change by updating your code to match, or revert it by running pulumi up to restore the original configuration.

Scenario 2: Legitimate External Changes

Not all drift is bad. Auto-scaling groups adjust capacity based on load. Managed services update configurations automatically. Some changes are legitimate and should be preserved:

// Mark resources that can change externally
const autoScalingGroup = new aws.autoscaling.Group("app-asg", {
 minSize: 2,
 maxSize: 10,
 // ... other config
}, {
 ignoreChanges: ["desiredCapacity"] // Ignore scaling changes
});

The ignoreChanges option tells Pulumi to ignore specific properties when detecting drift. Use it for fields that legitimately change outside your control, like auto-scaling capacity or last-modified timestamps.

Scenario 3: Configuration Drift

Sometimes drift occurs in configuration values rather than resource structure. IP allowlists, feature flags, and environment-specific settings often drift. Handle these with Pulumi’s configuration system:

# Use Pulumi's configuration system
config = pulumi.Config()
allowed_ips = config.get_object("allowed_ips") or ["10.0.0.0/8"]

security_group = aws.ec2.SecurityGroup("app-sg",
 ingress=[{
 "from_port": 443,
 "to_port": 443,
 "protocol": "tcp",
 "cidr_blocks": allowed_ips # Managed via configuration
 }]
)

By externalizing configuration values, you make them easier to update without code changes. This pattern works particularly well for values that change frequently or differ between environments.

The Value of Automated Drift Detection

After implementing drift detection for hundreds of stacks, patterns emerge that tell a compelling story about its value. The transformation begins subtly but grows profound as teams discover what they’ve been missing.

The first change most organizations notice is in their security posture. Where once unauthorized changes might lurk undetected for weeks, only surfacing during quarterly audits or worse, during incident investigations, now they’re caught within minutes. Security teams who previously dreaded audit season find themselves with continuous compliance data at their fingertips. Every change, whether legitimate or not, creates an audit trail that transforms compliance reporting from a scrambling fire drill into a routine export of already-collected data.

As teams settle into this new reality, operational improvements become apparent. Incidents that used to take hours to diagnose now resolve in minutes because engineers can immediately check whether drift contributed to the problem. One team reported that their mean time to recovery dropped by 40% simply because they could eliminate drift as a cause within seconds rather than spending hours manually comparing configurations. Change management, once a bureaucratic nightmare of spreadsheets and approval chains, transforms into an automated system where every modification is tracked, timestamped, and traceable to its source.

Then come the unexpected discoveries. Drift detection becomes a cost optimization tool that nobody anticipated. It uncovers orphaned resources spinning away forgotten in some corner of your cloud account, created during a debugging session six months ago. It catches that instance someone manually upgraded to a larger size during a performance investigation and forgot to downsize. One organization discovered they were spending $15,000 monthly on resources that weren’t even supposed to exist, all caught by their drift detection system in its first week of operation.

Perhaps most importantly, drift detection changes how teams work. Engineers stop wasting time on manual infrastructure audits. Debugging accelerates when you have clear reports showing exactly what changed and when. The constant anxiety about whether production matches your code disappears, replaced by confidence that any discrepancies will be caught and reported immediately. Teams report feeling more empowered to move quickly, knowing they have a safety net that will catch configuration drift before it causes problems.

The cumulative effect is transformative. Organizations running drift detection report not just fewer incidents and lower costs, but a fundamental shift in how they think about infrastructure management. It becomes proactive rather than reactive, confident rather than anxious, automated rather than manual. What starts as a simple scheduled check evolves into a cornerstone of operational excellence.

Getting Started with Drift Detection

Ready to implement drift detection for your IDP? Here’s a practical action plan that you can execute today.

Quick Start Checklist

Begin with the simplest possible drift detection: a manual check on your production stack. Run pulumi refresh --preview-only --stack production to see if you have any existing drift. This takes just 15 minutes and often reveals surprising discrepancies.

Next, invest 30 minutes in setting up automated detection. Configure Pulumi Deployments, create an hourly detection schedule for your most critical stack, and set up Slack notifications so you’ll know immediately when drift occurs.

Spend the next week monitoring and learning. Review the drift patterns that emerge. Identify common causes. Are certain resources drifting repeatedly? Are changes happening at predictable times? Document which changes are legitimate and which represent problems.

After a week of observation, you’re ready to implement remediation. Start with non-production environments where mistakes have lower impact. Enable auto-remediation gradually, monitoring success rates and adjusting your configuration based on what you learn.

Finally, optimize and scale your drift detection. Adjust schedules based on the patterns you’ve observed. Implement custom workflows for complex scenarios. Expand coverage to all your environments and stacks. What starts as a simple check becomes a comprehensive system protecting your entire infrastructure.

Conclusion: Day 2 Operations as a Competitive Advantage

Drift detection and remediation represent more than just good hygiene; they’re competitive advantages in a world where infrastructure complexity keeps growing.

Teams with robust day 2 operations move faster because they have confidence in their infrastructure state. They recover quickly from incidents because they can immediately identify what changed. They maintain security without slowing development by automatically detecting and reverting unauthorized modifications. Most importantly, they scale operations without scaling headcount, automating work that would otherwise require armies of engineers manually checking infrastructure.

The math is compelling. A single undetected security group change could lead to a breach costing millions. One overlooked configuration drift might cause hours of downtime. Yet implementing comprehensive drift detection takes just hours of setup and minutes of ongoing maintenance. The ROI is immediate and substantial.

Our IDP journey continues with “Extend Your IDP for AI Applications: GPUs, Models, and Cost Controls”. As AI workloads become central to modern applications, we’ll explore how to adapt your platform for machine learning workflows. You’ll learn about GPU orchestration, model deployment pipelines, and the unique cost management challenges that AI infrastructure presents.

But don’t wait for the next post to get started with drift detection. Even a simple hourly check can prevent major incidents. Set up basic detection today, and your future self will thank you the next time you’re debugging a production issue at 3 AM. More importantly, your on-call team will appreciate not having to debug issues caused by accumulated drift that could have been prevented.

Ready to implement drift detection? Start your free Pulumi Cloud trial and set up your first drift detection schedule in minutes. No credit card required.

Backstage vs Pulumi IDP: Why Infrastructure-First Wins!

Engin Diri — Wed, 13 Aug 2025 00:00:00 +0000

Developers are losing days every month to infrastructure bottlenecks, compliance hurdles, and inconsistent environments. Platform engineering promised to fix that, yet too many platforms fail before they deliver real impact.

In this comparison of Backstage vs Pulumi IDP, we’ll explore why choosing the right architectural approach matters more than the tool itself.

Quick comparison: Backstage vs Pulumi IDP

Backstage is an open-source developer portal framework from Spotify that focuses on service catalogs and documentation. It requires significant setup time (12-18 months) and ongoing maintenance (3-5 FTEs).

Pulumi IDP is an infrastructure-first internal developer platform that embeds governance, cost control, and security from day one. It can be deployed in hours with minimal ongoing maintenance.

The problem isn’t whether you choose Backstage or Pulumi IDP. The real question is: Will your platform treat infrastructure as a first-class concern, or as an afterthought?

According to Gartner, 80% of large enterprises will deploy internal developer platforms within the next two years. But without a strong infrastructure foundation, those platforms risk becoming expensive, hard-to-maintain bottlenecks instead of accelerators.

Why platform engineering efforts fail: Common mistakes

Platform teams consistently make four critical mistakes:

Neglecting Infrastructure Foundations
Over-focusing on the developer portal experience while letting infrastructure governance and scalability lag behind.
Ignoring Cost Efficiency
Prioritizing productivity at the expense of cloud cost management.
Example: One company considered giving every developer their own cluster, a scaling nightmare both technically and financially.
Treating Security & Governance as Add-Ons
Bolting on compliance after launch leads to constant firefighting and security debt.
Building for Yesterday’s Architecture
Designing general-purpose platforms that can’t keep up with Kubernetes-native workloads.

Portal-first vs infrastructure-first platform engineering

There are two dominant approaches:

Portal-First typified by Backstage, which starts with developer experience and service catalogs.
Infrastructure-First exemplified by Pulumi IDP, which builds the platform foundation around scalable, policy-driven infrastructure.

Platform Engineering Feature	Backstage (Portal-First)	Pulumi IDP (Infrastructure-First)
Primary Focus	Developer portal & catalog	Scalable, policy-driven infrastructure
Setup Time	12-18 months	Hours
Maintenance	3-5 FTE ongoing	Minimal ongoing overhead
Infra Provisioning	Requires separate tooling	Built-in
Cost Awareness	Depends on infra layer	Native
Security & Governance	Add-on	Built-in from day one

Backstage: The portal-first platform engineering approach

Backstage is an open-source framework for building developer portals. Originally built by Spotify, it excels at unifying tools, services, and documentation.

Strengths

Mature Ecosystem with over 1,200 integrations and a large community.
Excellent Service Catalog providing centralized metadata, ownership, and discovery.
Docs-as-Code that keeps documentation close to the codebase.
Self-Service Templates that standardize scaffolding for new projects.

Challenges

High Maintenance Overhead requiring 3-5 FTEs just to keep it running in large orgs.
Complex Setup with Yarn version headaches, TypeScript complexity, plugin upkeep.
Infra as an Afterthought that lacks built-in provisioning, often pushing infra concerns down the road.
Hidden Costs resulting in multi-million dollar TCO over three years for a 300-dev team when factoring in staffing and infra complexity.

Pulumi IDP: the infrastructure-first platform engineering approach

Pulumi IDP brings Infrastructure Platform Engineering (IPE) to the forefront by embedding scalable, secure, cost-aware infrastructure into the platform from day one.

Strengths

Infrastructure as a First-Class Concern with built-in multitenancy, isolation, and governance.
Efficiency & Cost Awareness through golden paths and reusable components optimized from the start.
Policy-Driven by Design that enforces security, compliance, and cost policies automatically.
Cloud-Native Ready ideal for ephemeral workloads, Kubernetes, and multi-cloud.

Considerations

Newer Platform with a smaller plugin ecosystem than Backstage’s.
Infra-Heavy Focus that’s best fit for infra-intensive orgs; overpowered if you only need a catalog and docs.

Real-world platform engineering outcomes: Backstage vs Pulumi IDP

Pulumi IDP Adoption: CLEAR leveraged Pulumi IDP’s prebuilt capabilities instead of building infra automation from scratch, speeding up delivery while keeping governance tight.

Backstage vs Pulumi IDP decision guide

When to choose Backstage

Choose Backstage for platform engineering if you:

Have a dedicated platform team with strong React/TypeScript skills
Primarily need service cataloging and documentation
Already have robust infrastructure provisioning and governance tools
Have 18+ months and budget for ongoing maintenance (3-5 FTEs)

When to choose Pulumi IDP

Choose Pulumi IDP for platform engineering if you:

Need infrastructure governance from day one
Want cost management and policy automation built in
Must scale efficiently across Kubernetes and multi-cloud
Prefer to avoid building everything from scratch
Need to deploy quickly (hours vs months)

The shift to infrastructure platform engineering (IPE)

Platform engineering isn’t failing because the idea is flawed. It’s failing because too many efforts start with the portal and leave infrastructure for later.

Infrastructure Platform Engineering flips that model, ensuring the platform’s foundation is:

Hybrid approaches are also possible. Pulumi offers a Backstage plugin so teams can pair Backstage’s portal features with Pulumi IDP’s infrastructure power.

Bottom line: infrastructure-first wins for platform engineering

If your platform is slow, costly, or hard to govern, it’s not a developer problem. It’s an infrastructure problem. Treating infrastructure as a first-class concern from day one isn’t optional. It’s the difference between a platform that scales and one that stalls.

Frequently asked questions

What is the main difference between Backstage and Pulumi IDP?

Backstage is a portal-first developer platform that focuses on service catalogs and documentation, requiring separate tools for infrastructure provisioning. Pulumi IDP is an infrastructure-first platform that embeds governance, cost control, and infrastructure automation from the start.

How long does it take to implement Backstage vs Pulumi IDP?

Backstage typically requires 12-18 months for full implementation with ongoing maintenance by 3-5 FTEs. Pulumi IDP can be deployed in hours with minimal ongoing maintenance overhead.

Can I use Backstage and Pulumi IDP together?

Yes, Pulumi offers a Backstage plugin that allows teams to combine Backstage’s portal features with Pulumi IDP’s infrastructure capabilities for a hybrid approach.

What are the costs of running Backstage vs Pulumi IDP?

Backstage’s TCO for a 300-developer team can reach multiple millions over three years when factoring in staffing and infrastructure complexity. Pulumi IDP has lower operational costs due to built-in automation and minimal maintenance requirements.

Which platform is better for Kubernetes environments?

Pulumi IDP is purpose-built for cloud-native and Kubernetes environments with built-in support for ephemeral workloads and multi-cloud deployments. Backstage requires additional tooling for Kubernetes infrastructure management.

Learn more about Pulumi IDP and how infrastructure-first platform engineering avoids common failure patterns.

Resource hooks

Will Jones — Mon, 30 Jun 2025 00:00:00 +0000

Pulumi programs are declarative, allowing you to specify the desired state of your infrastructure while Pulumi figures out the rest. But what about the times where you want to be more involved in what Pulumi is doing? Resource hooks are one of our most requested features, and from Pulumi 3.182.0 we’re excited to announce that you’ll be able to use them to run arbitrary code at any point in Pulumi’s resource lifecycle!

When you run pulumi up, Pulumi runs your program and works out the set of create, update and delete operations required to realise the state it describes. Hooks allow you to attach custom callbacks to these operations, enabling you to execute custom behaviour before or after they occur. You might want to set up an SSH tunnel to a bastion host before Pulumi attempts to create or update a virtual machine or database; or you may wish to send metrics to your data warehouse whenever Pulumi updates certain resources or properties. Hooks allow you to do all this and more – as with everything else in Pulumi, you are free to make use of the full power of your favourite programming language.

Hooks in action

Let’s check out the use case of opening a tunnel to a remote host before running a command. For this we’ll use a contrived example where we use the socat command to open a local TCP port that forwards to a remote host. Here we’ll open localhost:1234 and forward it to example.com:80. We’ll then use Pulumi’s command provider to invoke curl to make a request to that local port, which will be forwarded to the remote host. To start with, let’s write the program without hooks:

import * as command from "@pulumi/command"

export = async () => {
 const curl = "curl -H'Host: example.com' localhost:1234"

 const cmd = new command.local.Command("curl", {
 create: curl,
 update: curl,
 delete: curl,
 triggers: [new Date().toString()],
 })

 return {
 stdout: cmd.stdout,
 }
}

import * as command from "@pulumi/command"

export = async () => {
 const curl = "curl -H'Host: example.com' localhost:1234"

 const cmd = new command.local.Command("curl", {
 create: curl,
 update: curl,
 delete: curl,
 triggers: [new Date().toString()],
 })

 return {
 stdout: cmd.stdout,
 }
}

import datetime
import pulumi
import pulumi_command

curl = "curl -H'Host: example.com' localhost:1234"

cmd = pulumi_command.local.Command("curl",
 create=curl,
 update=curl,
 delete=curl,
 triggers=[str(datetime.datetime.now())],
)

pulumi.export("stdout", cmd.stdout)

package main

import (
 "time"

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

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 curl := "curl -H'Host: example.com' localhost:1234"

 cmd, err := local.NewCommand(ctx, "curl", &local.CommandArgs{
 Create: pulumi.String(curl),
 Update: pulumi.String(curl),
 Delete: pulumi.String(curl),
 Triggers: pulumi.StringArray{pulumi.String(time.Now().String())},
 })
 if err != nil {
 return err
 }

 ctx.Export("stdout", cmd.Stdout)

 return nil
 })
}

using System.Threading.Tasks;

using Pulumi;
using Pulumi.Command.Local;

class Program
{
 static Task<int> Main() => Deployment.RunAsync<MyStack>();
}

class MyStack : Stack
{
 public MyStack()
 {
 var curl = "curl -H'Host: example.com' localhost:1234";

 var cmd = new Command("curl", new CommandArgs
 {
 Create = curl,
 Update = curl,
 Delete = curl,
 Triggers = { System.DateTime.Now.ToString() },
 });

 return new Dictionary<string, object?>
 {
 ["stdout"] = cmd.Stdout,
 };
 }
}

We set up a local Command that will run the same curl command whether it is being created, updated, or deleted. For the purposes of illustration, we also set the triggers property to the current date and time, so that the command will always be run when we run pulumi up. Let’s now do just that:

pulumi up

Assuming we have nothing running on port 1234, we’ll get an error such as the following:

Updating (...)
View in Browser (Ctrl+O): https://app.pulumi.com/...
Type Name Status Info
pulumi:pulumi:Stack resource-hooks **failed** 1 error; 9 messages
++ └─ command:local:Command curl **creating failed** [diff: ]; 1 error
Diagnostics:
command:local:Command (curl):
error: exit status 7: running "curl -H'Host: example.com' localhost:1234":
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (7) Failed to connect to localhost port 1234 after 0 ms: Could not connect to server

As expected, nothing is listening on port 1234, so curl fails with an error. Previously, we might have fixed this by using a wrapper around our Pulumi program, such as the Automation API. With resource hooks, however, the solution is at our fingertips! We’ll hook into the Command resource’s lifecycle to open a tunnel before any operation is run, and to close it afterwards:

import * as child_process from "child_process"
import * as command from "@pulumi/command"
import * as pulumi from "@pulumi/pulumi"

export = async () => {
 let tunnel

 const beforeHook = new pulumi.ResourceHook("before", async args => {
 console.log("Opening tunnel")

 tunnel = child_process.spawn(
 "socat",
 [
 "TCP-LISTEN:1234,fork",
 "TCP:example.com:80",
 ],
 { detached: true }
 )

 console.log(`Tunnel opened: ${tunnel?.pid}`)
 })

 const afterHook = new pulumi.ResourceHook("after", async args => {
 console.log(`Closing tunnel: ${tunnel?.pid}`)
 tunnel?.kill("SIGKILL")
 })

 const curl = "curl -H'Host: example.com' localhost:1234"

 const cmd = new command.local.Command("curl", {
 create: curl,
 update: curl,
 delete: curl,
 triggers: [new Date().toString()],
 }, {
 hooks: {
 beforeCreate: [beforeHook],
 afterCreate: [afterHook],
 beforeUpdate: [beforeHook],
 afterUpdate: [afterHook],
 beforeDelete: [beforeHook],
 afterDelete: [afterHook],
 },
 })

 return {
 stdout: cmd.stdout,
 }
}

import * as child_process from "child_process"
import * as command from "@pulumi/command"
import * as pulumi from "@pulumi/pulumi"

export = async () => {
 let tunnel: child_process.ChildProcessWithoutNullStreams | undefined

 const beforeHook = new pulumi.ResourceHook("before", async args => {
 console.log("Opening tunnel")

 tunnel = child_process.spawn(
 "socat",
 [
 "TCP-LISTEN:1234,fork",
 "TCP:example.com:80",
 ],
 { detached: true }
 )

 console.log(`Tunnel opened: ${tunnel?.pid}`)
 })

 const afterHook = new pulumi.ResourceHook("after", async args => {
 console.log(`Closing tunnel: ${tunnel?.pid}`)
 tunnel?.kill("SIGKILL")
 })

 const curl = "curl -H'Host: example.com' localhost:1234"

 const cmd = new command.local.Command("curl", {
 create: curl,
 update: curl,
 delete: curl,
 triggers: [new Date().toString()],
 }, {
 hooks: {
 beforeCreate: [beforeHook],
 afterCreate: [afterHook],
 beforeUpdate: [beforeHook],
 afterUpdate: [afterHook],
 beforeDelete: [beforeHook],
 afterDelete: [afterHook],
 },
 })

 return {
 stdout: cmd.stdout,
 }
}

import datetime
import subprocess
import pulumi
import pulumi_command

tunnel = None

def before(args: pulumi.ResourceHookArgs):
 global tunnel
 pulumi.log.info("Opening tunnel")
 tunnel = subprocess.Popen(
 ["socat", "TCP-LISTEN:1234,fork", "TCP:example.com:80"],
 )
 pulumi.log.info(f"Tunnel opened: {tunnel.pid}")


before_hook = pulumi.ResourceHook("before", before)

def after(args: pulumi.ResourceHookArgs):
 global tunnel
 if tunnel:
 pulumi.log.info(f"Closing tunnel: {tunnel.pid}")
 tunnel.terminate()
 tunnel.wait()
 tunnel = None

after_hook = pulumi.ResourceHook("after", after)

curl = "curl -H'Host: example.com' localhost:1234"

cmd = pulumi_command.local.Command(
 "curl",
 create=curl,
 update=curl,
 delete=curl,
 triggers=[str(datetime.datetime.now())],
 opts=pulumi.ResourceOptions(
 hooks=pulumi.ResourceHookBinding(
 before_create=[before_hook],
 after_create=[after_hook],
 before_update=[before_hook],
 after_update=[after_hook],
 before_delete=[before_hook],
 after_delete=[after_hook],
 )
 ),
)

pulumi.export("stdout", cmd.stdout)

package main

import (
 "fmt"
 "os/exec"
 "time"

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

var tunnel *exec.Cmd

func before(args *pulumi.ResourceHookArgs) error {
 fmt.Println("Opening tunnel")
 tunnel = exec.Command("socat", "TCP-LISTEN:1234,fork", "TCP:example.com:80")
 err := tunnel.Start()
 if err != nil {
 return fmt.Errorf("failed to start tunnel: %w", err)
 }
 fmt.Printf("Tunnel opened: %d\n", tunnel.Process.Pid)
 return nil
}

func after(args *pulumi.ResourceHookArgs) error {
 if tunnel != nil && tunnel.Process != nil {
 fmt.Printf("Closing tunnel: %d", tunnel.Process.Pid)
 if err := tunnel.Process.Kill(); err != nil {
 return err
 }
 tunnel.Wait()
 tunnel = nil
 }
 return nil
}

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 beforeHook, err := ctx.RegisterResourceHook("before", before, nil)
 if err != nil {
 return err
 }
 afterHook, err := ctx.RegisterResourceHook("after", after, nil)
 if err != nil {
 return err
 }

 curlCmd := "curl -H'Host: example.com' localhost:1234"

 cmd, err := local.NewCommand(ctx, "curl", &local.CommandArgs{
 Create: pulumi.String(curlCmd),
 Update: pulumi.String(curlCmd),
 Delete: pulumi.String(curlCmd),
 Triggers: pulumi.Array{pulumi.String(fmt.Sprintf("%d", time.Now().Unix()))},
 }, pulumi.ResourceHooks(&pulumi.ResourceHookBinding{
 BeforeCreate: []*pulumi.ResourceHook{beforeHook},
 AfterCreate: []*pulumi.ResourceHook{afterHook},
 BeforeUpdate: []*pulumi.ResourceHook{beforeHook},
 AfterUpdate: []*pulumi.ResourceHook{afterHook},
 BeforeDelete: []*pulumi.ResourceHook{beforeHook},
 AfterDelete: []*pulumi.ResourceHook{afterHook},
 }),
 )
 if err != nil {
 return err
 }

 ctx.Export("stdout", cmd.Stdout)

 return nil
 })
}

using System.Diagnostics;
using System.Threading.Tasks;

using Pulumi;
using Pulumi.Command.Local;

class Program
{
 static Task<int> Main() => Deployment.RunAsync<MyStack>();
}

class MyStack : Stack
{
 public MyStack()
 {
 Process? tunnel = null;

 var beforeHook = new ResourceHook("before", async (args, cancellationToken) =>
 {
 System.Console.WriteLine("Opening tunnel");

 tunnel = Process.Start(new ProcessStartInfo
 {
 FileName = "socat",
 Arguments = "TCP-LISTEN:1234,fork TCP:example.com:80",
 UseShellExecute = false,
 CreateNoWindow = true,
 });

 System.Console.WriteLine($"Tunnel opened: {tunnel?.Id}");
 });

 var afterHook = new ResourceHook("after", async (args, cancellationToken) =>
 {
 System.Console.WriteLine($"Closing tunnel: {tunnel?.Id}");
 tunnel?.Kill();
 });

 var curl = "curl -H'Host: example.com' localhost:1234";

 var cmd = new Command("curl", new CommandArgs
 {
 Create = curl,
 Update = curl,
 Delete = curl,
 Triggers = { System.DateTime.Now.ToString() },
 }, new CustomResourceOptions
 {
 Hooks =
 {
 BeforeCreate = { beforeHook },
 AfterCreate = { afterHook },
 BeforeUpdate = { beforeHook },
 AfterUpdate = { afterHook },
 BeforeDelete = { beforeHook },
 AfterDelete = { afterHook },
 }
 });

 return new Dictionary<string, object?>
 {
 ["stdout"] = cmd.Stdout,
 };
 }
}

When we run pulumi up now, the hooks will be invoked before and after the relevant operation. Since our previous operation failed, we should expect to see a hooked create on our first run:

pulumi up

Updating (...)
View in Browser (Ctrl+O): https://app.pulumi.com/...
Type Name Status Info
+ pulumi:pulumi:Stack resource-hooks created (3s) 3 messages
+ └─ command:local:Command curl created (0.66s)
Diagnostics:
pulumi:pulumi:Stack (resource-hooks):
Opening tunnel
Tunnel opened: 2131167
Closing tunnel: 2131167
Outputs:
stdout: "<!doctype html>\n<html>\n<head>\n <title>Example Domain</title>\n\n <meta charset=\"utf-8\" />\n <meta http-equiv=\"Content-type\" content=\"text/html; charset=utf-8\" />\n <meta name=\"viewport\" content=\"width=device-width, initial-scale=1\" />\n <style type=\"text/css\">\n body {\n background-color: #f0f0f2;\n margin: 0;\n padding: 0;\n font-family: -apple-system, system-ui, BlinkMacSystemFont, \"Segoe UI\", \"Open Sans\", \"Helvetica Neue\", Helvetica, Arial, sans-serif;\n \n }\n div {\n width: 600px;\n margin: 5em auto;\n padding: 2em;\n background-color: #fdfdff;\n border-radius: 0.5em;\n box-shadow: 2px 3px 7px 2px rgba(0,0,0,0.02);\n }\n a:link, a:visited {\n color: #38488f;\n text-decoration: none;\n }\n @media (max-width: 700px) {\n div {\n margin: 0 auto;\n width: auto;\n }\n }\n </style> \n</head>\n\n<body>\n<div>\n <h1>Example Domain</h1>\n <p>This domain is for use in illustrative examples in documents. You may use this\n domain in literature without prior coordination or asking for permission.</p>\n <p><a href=\"https://www.iana.org/domains/example\">More information...</a></p>\n</div>\n</body>\n</html>"
Resources:
+ 2 created
Duration: 5s

Success! The tunnel was opened before our create operation and our stack output contains the HTML of the page at example.com.

Another example: application health checks

Let’s tackle a more realistic scenario where hooks can be useful. We’ll take the how-to guide for creating an EC2 web server and add resource hooks to health check the web server before allowing Pulumi to mark the deployment as complete. In this way, we know that when Pulumi is finished, the application is up and ready to go!

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

export = async () => {
 // Define the instance's user data script to set up a simple HTTP server that
 // serves some static content. We'll try to fetch the health.json in a
 // lifecycle hook later on to check whether or not the server is up and running.
 const userData = `#!/bin/bash
echo "Hello, World!" > index.html
echo '{"ok": true}' > health.json
nohup python -m SimpleHTTPServer 80 &`

 // Define a resource hook that will run after create and update and not return
 // until the health check passes.
 const afterHook = new pulumi.ResourceHook("after", async args => {
 // Since this is an after hook, we'll have access to the new outputs of the
 // resource.
 const outputs = args.newOutputs

 // Attempt to fetch health.json from the instance's public endpoint, backing
 // off linearly if it is not yet available.
 const maxRetries = 30
 for (let i = 0; i < maxRetries; i++) {
 try {
 const response = await fetch(`http://${outputs.publicDns}/health.json`)
 if (response.ok) {
 const data = await response.json()
 console.log(`Health check passed: ${JSON.stringify(data)}`)
 return
 }
 } catch (error) {
 console.log(`Health check attempt ${i + 1} failed`)
 }

 await new Promise(resolve => setTimeout(resolve, (i + 1) * 1000))
 }
 })

 // Set up the resources needed to run the web server, as outlined in the
 // how-to guide linked above.

 const instanceType = "t2.micro"
 const ami = aws.ec2.getAmiOutput({
 filters: [{
 name: "name",
 values: ["amzn2-ami-hvm-*"],
 }],
 // Amazon owns this AMI so we'll use their owner ID.
 owners: ["137112412989"],
 mostRecent: true,
 })

 const group = new aws.ec2.SecurityGroup("webserver-secgrp", {
 ingress: [
 { protocol: "tcp", fromPort: 22, toPort: 22, cidrBlocks: ["0.0.0.0/0"] },
 { protocol: "tcp", fromPort: 80, toPort: 80, cidrBlocks: ["0.0.0.0/0"] },
 ],
 })

 const server = new aws.ec2.Instance("webserver-www", {
 instanceType,
 vpcSecurityGroupIds: [group.id],
 ami: ami.id,
 userData,
 }, {
 hooks: {
 afterCreate: [afterHook],
 afterUpdate: [afterHook],
 },
 })

 return {
 publicDns: server.publicDns,
 publicIp: server.publicIp,
 }
}

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

export = async () => {
 // Define the instance's user data script to set up a simple HTTP server that
 // serves some static content. We'll try to fetch the health.json in a
 // lifecycle hook later on to check whether or not the server is up and running.
 const userData = `#!/bin/bash
echo "Hello, World!" > index.html
echo '{"ok": true}' > health.json
nohup python -m SimpleHTTPServer 80 &`

 // Define a resource hook that will run after create and update and not return
 // until the health check passes.
 const afterHook = new pulumi.ResourceHook("after", async args => {
 // Since this is an after hook, we'll have access to the new outputs of the
 // resource.
 const outputs = args.newOutputs as aws.ec2.InstanceState

 // Attempt to fetch health.json from the instance's public endpoint, backing
 // off linearly if it is not yet available.
 const maxRetries = 30
 for (let i = 0; i < maxRetries; i++) {
 try {
 const response = await fetch(`http://${outputs.publicDns}/health.json`)
 if (response.ok) {
 const data = await response.json()
 console.log(`Health check passed: ${JSON.stringify(data)}`)
 return
 }
 } catch (error) {
 console.log(`Health check attempt ${i + 1} failed`)
 }

 await new Promise(resolve => setTimeout(resolve, (i + 1) * 1000))
 }
 })

 // Set up the resources needed to run the web server, as outlined in the
 // how-to guide linked above.

 const instanceType = "t2.micro"
 const ami = aws.ec2.getAmiOutput({
 filters: [{
 name: "name",
 values: ["amzn2-ami-hvm-*"],
 }],
 // Amazon owns this AMI so we'll use their owner ID.
 owners: ["137112412989"],
 mostRecent: true,
 })

 const group = new aws.ec2.SecurityGroup("webserver-secgrp", {
 ingress: [
 { protocol: "tcp", fromPort: 22, toPort: 22, cidrBlocks: ["0.0.0.0/0"] },
 { protocol: "tcp", fromPort: 80, toPort: 80, cidrBlocks: ["0.0.0.0/0"] },
 ],
 })

 const server = new aws.ec2.Instance("webserver-www", {
 instanceType,
 vpcSecurityGroupIds: [group.id],
 ami: ami.id,
 userData,
 }, {
 hooks: {
 afterCreate: [afterHook],
 afterUpdate: [afterHook],
 },
 })

 return {
 publicDns: server.publicDns,
 publicIp: server.publicIp,
 }
}

import json
import time

import pulumi
import requests
from pulumi_aws import ec2

# Define the instance's user data script to set up a simple HTTP server that
# serves some static content. We'll try to fetch the health.json in a
# lifecycle hook later on to check whether or not the server is up and running.
user_data = """#!/bin/bash
echo "Hello, World!" > index.html
echo '{"ok": true}' > health.json
nohup python -m SimpleHTTPServer 80 &"""


# Define a resource hook that will run after create and update and not return
# until the health check passes.
def health_check(args: pulumi.ResourceHookArgs):
 # Since this is an after hook, we'll have access to the new outputs of the
 # resource.
 outputs = args.new_outputs

 # Attempt to fetch health.json from the instance's public endpoint, backing
 # off linearly if it is not yet available.
 max_retries = 30
 for i in range(max_retries):
 try:
 response = requests.get(
 f"http://{outputs['publicDns']}/health.json", timeout=10
 )
 if response.status_code == 200:
 data = response.json()
 print(f"Health check passed: {json.dumps(data)}")
 return
 except Exception as error:
 print(f"Health check attempt {i + 1} failed: {error}")

 # Linear backoff - wait (i + 1) seconds before next attempt
 time.sleep(i + 1)


instance_type = "t2.micro"

ami = ec2.get_ami_output(
 filters=[
 {
 "name": "name",
 "values": ["amzn2-ami-hvm-*"],
 }
 ],
 # Amazon owns this AMI so we'll use their owner ID.
 owners=["137112412989"],
 most_recent=True,
)

group = ec2.SecurityGroup(
 "webserver-secgrp",
 ingress=[
 {
 "protocol": "tcp",
 "from_port": 22,
 "to_port": 22,
 "cidr_blocks": ["0.0.0.0/0"],
 },
 {
 "protocol": "tcp",
 "from_port": 80,
 "to_port": 80,
 "cidr_blocks": ["0.0.0.0/0"],
 },
 ],
)

server = ec2.Instance(
 "webserver-www",
 instance_type=instance_type,
 vpc_security_group_ids=[group.id],
 ami=ami.id,
 user_data=user_data,
 opts=pulumi.ResourceOptions(
 hooks=pulumi.ResourceHookBinding(
 after_create=[health_check],
 after_update=[health_check],
 ),
 ),
)

package main

import (
 "encoding/json"
 "fmt"
 "net/http"
 "time"

 "github.com/pulumi/pulumi-aws/sdk/v6/go/aws/ec2"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

// Define a resource hook that will run after create and update and not return
// until the health check passes.
func healthCheck(args *pulumi.ResourceHookArgs) error {
 // Since this is an after hook, we'll have access to the new outputs of the
 // resource.
 publicDns := args.NewOutputs["publicDns"].StringValue()

 // Attempt to fetch health.json from the instance's public endpoint, backing
 // off linearly if it is not yet available.
 maxRetries := 30
 for i := 0; i < maxRetries; i++ {
 url := fmt.Sprintf("http://%s/health.json", publicDns)

 client := &http.Client{
 Timeout: 10 * time.Second,
 }

 resp, err := client.Get(url)
 if err == nil && resp.StatusCode == 200 {
 var data map[string]interface{}
 if err := json.NewDecoder(resp.Body).Decode(&data); err == nil {
 resp.Body.Close()
 dataJSON, _ := json.Marshal(data)
 fmt.Printf("Health check passed: %s\n", string(dataJSON))
 return nil
 }
 resp.Body.Close()
 }

 if resp != nil {
 resp.Body.Close()
 }

 fmt.Printf("Health check attempt %d failed: %v\n", i+1, err)

 // Linear backoff - wait (i + 1) seconds before next attempt
 time.Sleep(time.Duration(i+1) * time.Second)
 }

 return fmt.Errorf("health check failed after %d attempts", maxRetries)
}

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 // Define the instance's user data script to set up a simple HTTP server
 // that serves some static content. We'll try to fetch the health.json
 // in a lifecycle hook later on to check whether or not the server is up
 // and running.
 userData := `#!/bin/bash
echo "Hello, World!" > index.html
echo '{"ok": true}' > health.json
nohup python -m SimpleHTTPServer 80 &`

 instanceType := "t2.micro"

 ami, err := ec2.LookupAmi(ctx, &ec2.LookupAmiArgs{
 Filters: []ec2.GetAmiFilter{
 {
 Name: "name",
 Values: []string{"amzn2-ami-hvm-*"},
 },
 },
 // Amazon owns this AMI so we'll use their owner ID.
 Owners: []string{"137112412989"},
 MostRecent: pulumi.BoolRef(true),
 })
 if err != nil {
 return err
 }

 group, err := ec2.NewSecurityGroup(ctx, "webserver-secgrp", &ec2.SecurityGroupArgs{
 Ingress: ec2.SecurityGroupIngressArray{
 &ec2.SecurityGroupIngressArgs{
 Protocol: pulumi.String("tcp"),
 FromPort: pulumi.Int(22),
 ToPort: pulumi.Int(22),
 CidrBlocks: pulumi.StringArray{pulumi.String("0.0.0.0/0")},
 },
 &ec2.SecurityGroupIngressArgs{
 Protocol: pulumi.String("tcp"),
 FromPort: pulumi.Int(80),
 ToPort: pulumi.Int(80),
 CidrBlocks: pulumi.StringArray{pulumi.String("0.0.0.0/0")},
 },
 },
 })
 if err != nil {
 return err
 }

 hook, err := ctx.RegisterResourceHook("health-check", healthCheck, nil)
 if err != nil {
 return err
 }

 server, err := ec2.NewInstance(ctx, "webserver-www", &ec2.InstanceArgs{
 InstanceType: pulumi.String(instanceType),
 VpcSecurityGroupIds: pulumi.StringArray{group.ID()},
 Ami: pulumi.String(ami.Id),
 UserData: pulumi.String(userData),
 }, pulumi.ResourceHooks(&pulumi.ResourceHookBinding{
 AfterCreate: []*pulumi.ResourceHook{hook},
 AfterUpdate: []*pulumi.ResourceHook{hook},
 }))
 if err != nil {
 return err
 }

 ctx.Export("publicDns", server.PublicDns)
 ctx.Export("publicIp", server.PublicIp)

 return nil
 })
}

using System;

using System.Threading.Tasks;
using Pulumi;

using Pulumi.Aws.Ec2;
using Pulumi.Aws.Ec2.Inputs;
using Pulumi.Command.Local;
using System.Diagnostics;
using System.Collections.Generic;

class Program
{
 static Task<int> Main() => Deployment.RunAsync<MyStack>();
}

class MyStack : Stack
{
 public MyStack()
 {
 // Define the instance's user data script to set up a simple HTTP server that
 // serves some static content. We'll try to fetch the health.json in a
 // lifecycle hook later on to check whether or not the server is up and running.
 var userData = @"#!/bin/bash
echo ""Hello, World!"" > index.html
echo '{""ok"": true}' > health.json
nohup python -m SimpleHTTPServer 80 &";

 // Define a resource hook that will run after create and update and not return
 // until the health check passes.
 var afterHook = new ResourceHook("after", async (args, cancellationToken) =>
 {
 // Since this is an after hook, we'll have access to the new outputs of the
 // resource.
 var outputs = args.NewOutputs

 // Attempt to fetch health.json from the instance's public endpoint, backing
 // off linearly if it is not yet available.
 const int maxRetries = 30;
 for (var i = 0; i < maxRetries; i++)
 {
 try
 {
 using var client = new HttpClient();
 var response = await client.GetAsync($"http://{outputs?["publicDns"]}/health.json");
 if (response.IsSuccessStatusCode)
 {
 var data = await response.Content.ReadAsStringAsync();
 Console.WriteLine($"Health check passed: {data}");
 return;
 }
 }
 catch (Exception)
 {
 Console.WriteLine($"Health check attempt {i + 1} failed");
 }

 await Task.Delay((i + 1) * 1000);
 }
 });

 // Set up the resources needed to run the web server, as outlined in the
 // how-to guide linked above.

 var instanceType = "t2.micro";
 var ami = GetAmi.Invoke(new GetAmiArgs
 {
 Filters =
 {
 new GetAmiFilterArgs
 {
 Name = "name",
 Values = { "amzn2-ami-hvm-*" },
 },
 },
 Owners = { "137112412989" }, // Amazon owns this AMI so we'll use their owner ID.
 MostRecent = true,
 });

 var group = new SecurityGroup("webserver-secgrp", new SecurityGroupArgs
 {
 Ingress =
 {
 new SecurityGroupIngressArgs
 {
 Protocol = "tcp",
 FromPort = 22,
 ToPort = 22,
 CidrBlocks = { "0.0.0.0/0" },
 },
 new SecurityGroupIngressArgs
 {
 Protocol = "tcp",
 FromPort = 80,
 ToPort = 80,
 CidrBlocks = { "0.0.0.0/0" },
 },
 },
 });

 var server = new Instance("webserver-www", new InstanceArgs
 {
 InstanceType = instanceType,
 VpcSecurityGroupIds = { group.Id },
 Ami = ami.Apply(a => a.Id),
 UserData = userData,
 }, new CustomResourceOptions
 {
 Hooks =
 {
 AfterCreate = { afterHook },
 AfterUpdate = { afterHook },
 }
 });

 // Export the public DNS and IP of the server.
 this.PublicDns = server.PublicDns;
 this.PublicIp = server.PublicIp;
 }

 [Output]
 public Output<string> PublicDns { get; private set; }

 [Output]
 public Output<string> PublicIp { get; private set; }
}

Thanks to our hooks, pulumi up will now wait until the web server is up and running before marking the deployment as complete. We can see this in action thanks to our logging output:

pulumi up

Updating (...)

View in Browser (Ctrl+O): https://app.pulumi.com/...

 Type Name Status Info
 + pulumi:pulumi:Stack resource-hooks created (79s) 6 messages
 + ├─ aws:ec2:SecurityGroup webserver-secgrp created (3s)
 + └─ aws:ec2:Instance webserver-www created (67s)

Diagnostics:
 pulumi:pulumi:Stack (resource-hooks):
 Health check attempt 1 failed
 Health check attempt 2 failed
 Health check attempt 3 failed
 Health check attempt 4 failed
 Health check attempt 5 failed
 Health check passed: {"ok":true}

Outputs:
 publicHostName: "ec2-XXX-YYY-ZZZ-WWW.us-west-2.compute.amazonaws.com"
 publicIp : "XXX.YYY.ZZZ.WWW"

Resources:
 + 3 created

Duration: 1m21s

And indeed, a command such as curl http://ec2-XXX-YYY-ZZZ-WWW.us-west-2.compute.amazonaws.com/health.json returns {"ok":true} immediately, without us having to wait for the web server to start up after the pulumi up command completes!

Where can we go from here?

Resource hooks are a powerful new feature that allow you to run custom code at any point in the resource lifecycle. This opens up a wide range of possibilities, such as:

Custom application health checks after creating or updating resources
Collecting logs or metrics when your Pulumi resources change
Running custom scripts such as database migrations as part of your Pulumi workflow.

Resource hooks require Pulumi to run your program. For refresh and destroy operations, this means you must use the --run-program flag for hooks to work. Read the full documentation on resource hooks to learn more.

Share any issues with your experience with us on GitHub, X, or our Community Slack.

Most Effective Infrastructure as Code (IaC) Tools

Asaf Ashirov — Thu, 26 Jun 2025 00:00:00 +0000

Infrastructure as Code (IaC) has evolved beyond simple automation into a fundamental shift toward applying software engineering practices to infrastructure management. In 2025, leading organizations aren’t just provisioning infrastructure—they’re treating it as software, complete with testing, version control, code reviews, and continuous integration.

As infrastructure complexity grows, teams increasingly seek approaches that provide the same developer productivity tools they use for application development. While template-based and domain-specific language approaches serve many use cases effectively, teams with complex requirements or programming backgrounds often find that general-purpose programming languages offer advantages in testing, abstraction, and collaboration.

This comprehensive guide examines the most effective infrastructure as code tools available today, providing detailed analysis of core IaC platforms, complementary tools, and related technologies through the lens of software engineering best practices. Whether you’re starting fresh with IaC or evaluating alternatives to overcome limitations in your current toolchain, we’ll help you navigate this complex landscape and choose solutions that truly bring software engineering to infrastructure.

What is Infrastructure as Code?

Infrastructure as Code (IaC) is an approach to automating the provisioning and management of infrastructure using software engineering principles, approaches, and tools. Rather than manually configuring servers, networks, and cloud resources through user interfaces or command-line tools, IaC enables you to define your entire infrastructure declaratively through code.

This approach brings the same benefits that have revolutionized software development—version control, automated testing, code reviews, and CI/CD pipelines—to infrastructure management.

What Are Infrastructure as Code Tools?

Infrastructure as Code tools are platforms and frameworks that enable you to define, provision, and manage infrastructure resources through code rather than manual processes. These tools translate your infrastructure definitions into API calls that create, modify, or destroy cloud resources across various providers.

The most effective IaC tools share several key characteristics:

Goal-state focus: Define your desired infrastructure outcome, whether through declarative syntax (like YAML/JSON templates) or imperative languages that express declarative intent
Multi-cloud support: Work across different cloud providers and services
State management: Track the current state of your infrastructure
Preview capabilities: Show what changes will be made before applying them
Idempotency: Safe to run multiple times with consistent results

Why Infrastructure as Code Tools Are Essential

The shift to IaC tools addresses fundamental challenges that manual infrastructure management cannot solve at scale:

Accelerates Deployment Velocity: Teams can provision complex multi-cloud architectures in minutes instead of weeks. This speed enables faster time-to-market and more frequent, reliable deployments.

Enables True Collaboration: Infrastructure becomes code that teams can review, test, and approve together. This collaborative approach reduces errors and ensures knowledge sharing across the organization.

Eliminates Configuration Drift: Manual changes lead to inconsistencies between environments. IaC ensures your production, staging, and development environments remain identical, eliminating the notorious “works on my machine” syndrome for infrastructure.

Provides Cost Control: Automated provisioning and deprovisioning prevents resource sprawl. Teams can easily track infrastructure costs, set budget alerts, and optimize resource usage across environments.

Ensures Compliance and Security: Codified security policies and compliance requirements are automatically enforced across all deployments. Audit trails become automatic, and policy violations are caught before deployment.

Guarantees Business Continuity: Complete infrastructure definitions stored in version control enable rapid disaster recovery. Organizations can reconstruct entire environments from code, minimizing downtime and data loss.

Infrastructure as Code Tools Overview

This guide covers the following infrastructure as code tools and platforms:

10 Most Used IaC Tools in 2025

Pulumi IaC - Modern IaC with general-purpose programming languages
Terraform - BSL-licensed IaC from HashiCorp that uses the HCL domain-specific language
AWS CDK - Cloud Development Kit for AWS
AWS CloudFormation - Native AWS integration
Azure Resource Manager (ARM) - Native Azure JSON templates
Azure Bicep - Azure-native domain-specific language that compiles to ARM
Google Cloud Infrastructure Manager - Terraform-based solution for Google Cloud
Kubernetes YAML - Native Kubernetes resource definitions
Crossplane - Kubernetes as universal control plane
OpenTofu - Open-source Terraform alternative

Configuration Management Tools

Chef - Configuration management and compliance automation
Puppet - Configuration management and compliance automation
Salt - Configuration management and remote execution

Application and Platform Management Tools

Kubernetes - Container orchestration platform

Security and Compliance Tools

Pulumi ESC - Configuration and secrets management platform
Pulumi Insights - Cloud resource search, analytics, and compliance platform
Snyk - Developer security platform with IaC scanning
Wiz - Comprehensive cloud security platform
HashiCorp Sentinel - Policy-as-code framework for Terraform
Checkov - Static analysis for IaC security
TFLint - Terraform linting and validation

Infrastructure Automation and Management Platforms

Pulumi Cloud - Managed service for Pulumi IaC with enterprise features
HashiCorp Cloud Platform - Enterprise SaaS platform for Terraform management and automation
Spacelift - Automation platform for IaC workflows (not an IaC tool itself)
Env0 - Governance and automation platform for existing IaC tools

Core Infrastructure as Code Tools

1. Pulumi

License: Apache 2.0
Best For: Teams who want flexible, language-agnostic IaC for infrastructure and operations

Pulumi IaC represents a modern approach to infrastructure as code, fundamentally changing how teams approach infrastructure by enabling the use of general-purpose programming languages like Python, TypeScript, Go, C#, and Java, plus YAML for simpler configurations. Unlike tools that force teams to learn proprietary domain-specific languages (DSLs), Pulumi leverages familiar languages and software engineering practices, providing unprecedented flexibility, powerful abstractions, and seamless integration with existing development workflows.

Pulumi’s approach combines the best of both imperative and declarative paradigms: you use imperative programming languages to define your desired infrastructure state, but the Pulumi engine processes this declaratively to determine what changes are needed to achieve your intended outcome.

Key Features:

Universal language support: Use Python, TypeScript, Go, C#, Java, or YAML configurations—no new DSL to learn
Any cloud, any architecture: Deploy to AWS, Azure, Google Cloud, Kubernetes, and 100+ other providers
Real programming constructs: Leverage loops, conditionals, functions, classes, packages, and third-party libraries
Superior developer experience: Full IDE support with IntelliSense, debugging, and refactoring
Built-in testing: Unit and integration testing for infrastructure code
Policy as Code: Enforce compliance and security policies with CrossGuard
Component ecosystem: Rich library of reusable infrastructure components

Universal Language Code Examples:

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

// Create a VPC with automatic subnets
const vpc = new awsx.ec2.Vpc("main-vpc", {
 cidrBlock: "10.0.0.0/16",
 numberOfAvailabilityZones: 2,
});

// Create an ECS cluster
const cluster = new aws.ecs.Cluster("app-cluster");

// Create an Application Load Balancer
const alb = new awsx.elasticloadbalancingv2.ApplicationLoadBalancer("app-alb", {
 vpcId: vpc.vpcId,
 subnetIds: vpc.publicSubnetIds,
});

// Deploy a containerized application
const service = new awsx.ecs.FargateService("app-service", {
 cluster: cluster.arn,
 taskDefinitionArgs: {
 container: {
 image: "nginx:latest",
 memory: 128,
 ports: [{
 containerPort: 80,
 targetGroup: alb.defaultTargetGroup,
 }],
 },
 },
});

export const vpcId = vpc.vpcId;
export const serviceUrl = alb.loadBalancer.dnsName;

import pulumi
import pulumi_aws as aws
import pulumi_awsx as awsx

# Create a VPC with automatic subnets
vpc = awsx.ec2.Vpc("main-vpc",
 cidr_block="10.0.0.0/16",
 number_of_availability_zones=2)

# Create an ECS cluster
cluster = aws.ecs.Cluster("app-cluster")

# Create an Application Load Balancer
alb = awsx.elasticloadbalancingv2.ApplicationLoadBalancer("app-alb",
 vpc_id=vpc.vpc_id,
 subnet_ids=vpc.public_subnet_ids)

# Deploy a containerized application
service = awsx.ecs.FargateService("app-service",
 cluster=cluster.arn,
 task_definition_args=awsx.ecs.FargateServiceTaskDefinitionArgs(
 container=awsx.ecs.TaskDefinitionContainerDefinitionArgs(
 image="nginx:latest",
 memory=128,
 ports=[awsx.ecs.TaskDefinitionPortMappingArgs(
 container_port=80,
 target_group=alb.default_target_group
 )]
 )
 ))

pulumi.export("vpc_id", vpc.vpc_id)
pulumi.export("service_url", alb.load_balancer.dns_name)

package main

import (
 "github.com/pulumi/pulumi-aws/sdk/v6/go/aws/ecs"
 "github.com/pulumi/pulumi-awsx/sdk/v2/go/awsx/ec2"
 "github.com/pulumi/pulumi-awsx/sdk/v2/go/awsx/elasticloadbalancingv2"
 awsxecs "github.com/pulumi/pulumi-awsx/sdk/v2/go/awsx/ecs"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 // Create a VPC with automatic subnets
 vpc, err := ec2.NewVpc(ctx, "main-vpc", &ec2.VpcArgs{
 CidrBlock: pulumi.String("10.0.0.0/16"),
 NumberOfAvailabilityZones: pulumi.Int(2),
 })
 if err != nil {
 return err
 }

 // Create an ECS cluster
 cluster, err := ecs.NewCluster(ctx, "app-cluster", nil)
 if err != nil {
 return err
 }

 // Create an Application Load Balancer
 alb, err := elasticloadbalancingv2.NewApplicationLoadBalancer(ctx, "app-alb", &elasticloadbalancingv2.ApplicationLoadBalancerArgs{
 VpcId: vpc.VpcId,
 SubnetIds: vpc.PublicSubnetIds,
 })
 if err != nil {
 return err
 }

 // Deploy a containerized application
 _, err = awsxecs.NewFargateService(ctx, "app-service", &awsxecs.FargateServiceArgs{
 Cluster: cluster.Arn,
 TaskDefinitionArgs: &awsxecs.FargateServiceTaskDefinitionArgs{
 Container: &awsxecs.TaskDefinitionContainerDefinitionArgs{
 Image: pulumi.String("nginx:latest"),
 Memory: pulumi.Int(128),
 Ports: awsxecs.TaskDefinitionPortMappingArray{
 &awsxecs.TaskDefinitionPortMappingArgs{
 ContainerPort: pulumi.Int(80),
 TargetGroup: alb.DefaultTargetGroup,
 },
 },
 },
 },
 })
 if err != nil {
 return err
 }

 ctx.Export("vpcId", vpc.VpcId)
 ctx.Export("serviceUrl", alb.LoadBalancer.DnsName())
 return nil
 })
}

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

return await Deployment.RunAsync(() =>
{
 // Create a VPC with automatic subnets
 var vpc = new Awsx.Ec2.Vpc("main-vpc", new()
 {
 CidrBlock = "10.0.0.0/16",
 NumberOfAvailabilityZones = 2,
 });

 // Create an ECS cluster
 var cluster = new Aws.Ecs.Cluster("app-cluster");

 // Create an Application Load Balancer
 var alb = new Awsx.ElasticLoadBalancingV2.ApplicationLoadBalancer("app-alb", new()
 {
 VpcId = vpc.VpcId,
 SubnetIds = vpc.PublicSubnetIds,
 });

 // Deploy a containerized application
 var service = new Awsx.Ecs.FargateService("app-service", new()
 {
 Cluster = cluster.Arn,
 TaskDefinitionArgs = new Awsx.Ecs.Inputs.FargateServiceTaskDefinitionArgs
 {
 Container = new Awsx.Ecs.Inputs.TaskDefinitionContainerDefinitionArgs
 {
 Image = "nginx:latest",
 Memory = 128,
 Ports = new[]
 {
 new Awsx.Ecs.Inputs.TaskDefinitionPortMappingArgs
 {
 ContainerPort = 80,
 TargetGroup = alb.DefaultTargetGroup,
 },
 },
 },
 },
 });

 return new Dictionary<string, object?>
 {
 ["vpcId"] = vpc.VpcId,
 ["serviceUrl"] = alb.LoadBalancer.Apply(lb => lb.DnsName),
 };
});

name: aws-ecs-example
runtime: yaml
description: An example that deploys an ECS Fargate service with load balancer

resources:
 # Create a VPC with automatic subnets
 main-vpc:
 type: awsx:ec2:Vpc
 properties:
 cidrBlock: "10.0.0.0/16"
 numberOfAvailabilityZones: 2

 # Create an ECS cluster
 app-cluster:
 type: aws:ecs:Cluster

 # Create an Application Load Balancer
 app-alb:
 type: awsx:elasticloadbalancingv2:ApplicationLoadBalancer
 properties:
 vpcId: ${main-vpc.vpcId}
 subnetIds: ${main-vpc.publicSubnetIds}

 # Deploy a containerized application
 app-service:
 type: awsx:ecs:FargateService
 properties:
 cluster: ${app-cluster.arn}
 taskDefinitionArgs:
 container:
 image: "nginx:latest"
 memory: 128
 ports:
 - containerPort: 80
 targetGroup: ${app-alb.defaultTargetGroup}

outputs:
 vpcId: ${main-vpc.vpcId}
 serviceUrl: ${app-alb.loadBalancer.dnsName}

Key Features:

General-purpose language support: Use Python, TypeScript, Go, C#, Java, or YAML without learning new DSLs
Software engineering practices: Full IDE support, comprehensive testing frameworks, debugging capabilities
Multi-cloud flexibility: Native cloud provider SDKs with same-day feature access across 150+ providers
Incremental adoption: Migration tools and state integration for gradual transitions
Open source licensing: Apache 2.0 ensures long-term freedom and flexibility

Considerations:

Learning curve: Teams new to programming may prefer template-based approaches initially
Ecosystem maturity: Smaller community compared to more established tools like Terraform
Tool complexity: Advanced features may require more setup than simpler template systems

Organizations like Unity, Snowflake, and Starburst have reported significant productivity improvements (80-90% deployment time reductions) when adopting programming language-based approaches. These improvements typically occur when transitioning from manual processes or basic template systems to automated approaches with comprehensive testing, IDE integration, and code reusability. Results vary based on starting point, team expertise, infrastructure complexity, and specific use cases.

Ready to get started? Experience Pulumi’s programming language approach and see how familiar languages can transform your infrastructure management with comprehensive testing, powerful abstractions, and seamless multi-cloud support.

2. Terraform

License: Business Source License (BSL) 1.1 (Not Open Source)
Best For: Teams with existing Terraform expertise and established workflows

Terraform uses HashiCorp Configuration Language (HCL) to define infrastructure across multiple cloud providers. However, its 2023 licensing change to BSL (no longer open source) and inherent limitations with domain-specific languages create challenges for teams requiring advanced software engineering practices.

Key Features:

Extensive provider ecosystem: Largest collection of community-maintained providers covering virtually every cloud service
Established workflows: Mature plan-and-apply process with extensive tooling and CI/CD integrations
Community and resources: Vast ecosystem of modules, extensive documentation, training materials, and community support
Enterprise adoption: Widely adopted in enterprises with established processes and expertise
Module ecosystem: Rich collection of reusable Terraform modules for common patterns

When Terraform Works Well:

Teams with existing HCL expertise and Terraform investments
Infrastructure patterns that fit well within HCL’s declarative model
Teams comfortable with template-based approaches

Considerations for Complex Scenarios:

Language constraints: HCL’s domain-specific nature can require workarounds for complex logic compared to general-purpose programming languages
Testing approach: Primarily supports integration testing; teams needing comprehensive unit testing may require additional tooling
IDE experience: While improving, HCL tooling provides less comprehensive support than mature programming language ecosystems
State management: Requires manual backend configuration and locking setup for team collaboration

Code Example:

data "aws_availability_zones" "available" {}

resource "aws_vpc" "main" {
 cidr_block = "10.0.0.0/16"

 tags = {
 Name = "main-vpc"
 }
}

resource "aws_subnet" "public" {
 count = 2
 vpc_id = aws_vpc.main.id
 cidr_block = "10.0.${count.index + 1}.0/24"
 availability_zone = data.aws_availability_zones.available.names[count.index]

 tags = {
 Name = "public-subnet-${count.index + 1}"
 }
}

3. AWS Cloud Development Kit (CDK)

License: Apache 2.0
Best For: AWS-focused teams who prefer programming languages over templates

AWS CDK allows you to define AWS infrastructure using familiar programming languages, synthesizing CloudFormation templates for deployment while providing higher-level abstractions. CDK addresses many limitations of traditional template-based approaches by enabling general-purpose programming languages.

Key Features:

General-purpose programming languages: TypeScript, Python, Java, C#, JavaScript support with full IDE integration (Go available in Developer Preview)
AWS-optimized constructs: High-level components encapsulating AWS best practices
Type safety: Compile-time checking and IntelliSense support
CloudFormation reliability: Built on AWS’s proven deployment engine

Notable Limitations:

AWS-only ecosystem: Locked into single cloud provider, limiting multi-cloud strategies
CloudFormation constraints: Inherits template size limits and deployment restrictions
Vendor lock-in: Deep AWS integration makes migration to other clouds challenging
Limited cross-cloud consistency: Teams need different tools and approaches for multi-cloud deployments

CDK represents a significant improvement over CloudFormation templates but constrains organizations to AWS-only infrastructure strategies.

Code Example:

import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as ecs from 'aws-cdk-lib/aws-ecs';
import { Construct } from 'constructs';

export class MyStack extends cdk.Stack {
 constructor(scope: Construct, id: string, props?: cdk.StackProps) {
 super(scope, id, props);

 const vpc = new ec2.Vpc(this, 'MyVpc', {
 maxAzs: 2
 });

 const cluster = new ecs.Cluster(this, 'MyCluster', {
 vpc: vpc
 });

 const taskDefinition = new ecs.FargateTaskDefinition(this, 'TaskDef', {
 memoryLimitMiB: 512,
 cpu: 256
 });

 taskDefinition.addContainer('web', {
 image: ecs.ContainerImage.fromRegistry('nginx:latest'),
 portMappings: [{ containerPort: 80 }]
 });

 new ecs.FargateService(this, 'MyService', {
 cluster: cluster,
 taskDefinition: taskDefinition
 });
 }
}

4. AWS CloudFormation

License: Proprietary (AWS Service)
Best For: AWS-only deployments requiring deep service integration

AWS CloudFormation provides the foundation for infrastructure as code on AWS, offering native integration with all AWS services and deep platform-specific features.

Pulumi Integration: Pulumi provides native AWS providers that offer the same comprehensive AWS service coverage as CloudFormation, with the added benefit of using general-purpose programming languages. You can also import existing CloudFormation stacks into Pulumi for gradual migration or hybrid management approaches.

Key Features:

AWS-native: First-party support for all AWS services
JSON/YAML templates: Declarative resource definitions
Stack management: Organized resource grouping and lifecycle management
Change sets: Preview infrastructure changes before deployment
Service integration: Deep integration with other AWS services

Code Example:

AWSTemplateFormatVersion: '2010-09-09'
Resources:
 MyVPC:
 Type: AWS::EC2::VPC
 Properties:
 CidrBlock: 10.0.0.0/16
 EnableDnsHostnames: true
 Tags:
 - Key: Name
 Value: MyVPC

 MySubnet:
 Type: AWS::EC2::Subnet
 Properties:
 VpcId: !Ref MyVPC
 CidrBlock: 10.0.1.0/24
 AvailabilityZone: !Select [0, !GetAZs '']

5. Azure Resource Manager (ARM)

License: Proprietary (Microsoft Service)
Best For: Azure-native deployments requiring comprehensive platform integration

Azure Resource Manager provides the foundational infrastructure as code solution for Microsoft Azure, offering complete support for Azure services through JSON-based ARM templates. As Azure’s native IaC solution, ARM templates provide the most comprehensive coverage of Azure services and features.

Pulumi Integration: Pulumi’s native Azure providers offer equivalent comprehensive Azure service coverage with general-purpose programming languages. ARM templates can be imported into Pulumi, and you can reference ARM deployments from Pulumi programs for hybrid scenarios.

Key Features:

Azure-native: Complete Azure service coverage with first-party support
JSON templates: Declarative resource definitions in JSON format
Resource groups: Logical organization of related resources
Deployment modes: Complete or incremental deployment options
Comprehensive integration: Deep integration with Azure services and features

Code Example:

{
 "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
 "contentVersion": "1.0.0.0",
 "resources": [
 {
 "type": "Microsoft.Storage/storageAccounts",
 "apiVersion": "2023-01-01",
 "name": "mystorageaccount",
 "location": "[resourceGroup().location]",
 "sku": {
 "name": "Standard_LRS"
 },
 "kind": "StorageV2"
 }
 ]
}

6. Azure Bicep

License: MIT
Best For: Azure deployments requiring improved readability and developer experience

Azure Bicep is a domain-specific language (DSL) that simplifies Azure Resource Manager template authoring. Bicep files compile transparently to ARM templates, providing all the capabilities of ARM with significantly improved syntax and developer experience.

Key Features:

Simplified syntax: Clean, readable syntax compared to JSON ARM templates
ARM compilation: Compiles to ARM templates for deployment, ensuring full compatibility
Type safety: Strong typing and IntelliSense support in development environments
Modular design: Support for modules and code reuse across projects
Azure-native: Complete Azure service coverage through ARM template compilation

Code Example:

@description('Storage Account type')
@allowed([
 'Standard_LRS'
 'Standard_GRS'
 'Standard_ZRS'
 'Premium_LRS'
])
param storageAccountType string = 'Standard_LRS'

@description('Location for the storage account.')
param location string = resourceGroup().location

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
 name: 'mystorageaccount'
 location: location
 sku: {
 name: storageAccountType
 }
 kind: 'StorageV2'
 properties: {}
}

7. Google Cloud Infrastructure Manager

License: Proprietary (Google Service)
Best For: Google Cloud Platform deployments using Terraform

Google Cloud Infrastructure Manager automates the deployment and management of Google Cloud infrastructure resources using Terraform configurations, representing Google’s modern approach to infrastructure as code. Infrastructure Manager replaces Google Cloud Deployment Manager, which will reach end of support on December 31, 2025.

Key Features:

Terraform-based: Uses standard Terraform configurations declaratively
Automated workflows: Handles Terraform init, validate, and apply operations
Version control integration: Supports Git repositories and Cloud Storage
Deployment tracking: Comprehensive metadata storage and logging
Multiple Terraform versions: Flexibility in Terraform version selection
Cloud Build integration: Leverages Google Cloud Build for execution environment
Migration path: Provides upgrade path from legacy Cloud Deployment Manager

Code Example:

# main.tf - Terraform configuration for Infrastructure Manager
resource "google_compute_instance" "vm_instance" {
 name = "my-vm"
 machine_type = "e2-medium"
 zone = "us-central1-a"

 boot_disk {
 initialize_params {
 image = "debian-cloud/debian-11"
 }
 }

 network_interface {
 network = "default"
 access_config {
 // Ephemeral public IP
 }
 }

 metadata = {
 startup-script = "echo Hello from Infrastructure Manager!"
 }
}

output "instance_ip" {
 value = google_compute_instance.vm_instance.network_interface[0].access_config[0].nat_ip
}

8. Kubernetes YAML

License: Apache 2.0
Best For: Teams managing container-native applications and cloud-native infrastructure

Kubernetes YAML manifests represent one of the most widely adopted forms of infrastructure as code, enabling teams to define, version, and manage containerized applications and their supporting infrastructure through declarative configuration files.

Key Features:

Declarative configuration: Define desired state through human-readable YAML files
Native Kubernetes integration: Direct integration with Kubernetes API without additional tools
GitOps compatibility: Version control YAML files for automated deployment workflows
Resource relationships: Define dependencies and relationships between Kubernetes resources
Extensive ecosystem: Rich ecosystem of operators and custom resources extending functionality

Code Example:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: web-app
 labels:
 app: web-app
spec:
 replicas: 3
 selector:
 matchLabels:
 app: web-app
 template:
 metadata:
 labels:
 app: web-app
 spec:
 containers:
 - name: web-app
 image: nginx:1.21
 ports:
 - containerPort: 80
 resources:
 requests:
 memory: "64Mi"
 cpu: "250m"
 limits:
 memory: "128Mi"
 cpu: "500m"
---
apiVersion: v1
kind: Service
metadata:
 name: web-app-service
spec:
 selector:
 app: web-app
 ports:
 - port: 80
 targetPort: 80
 type: LoadBalancer

9. Crossplane

License: Apache 2.0
Best For: Kubernetes-first organizations managing multi-cloud infrastructure

Crossplane is a Cloud-Native Framework for Platform Engineering that extends Kubernetes to help organizations build custom infrastructure management platforms, allowing teams to provision and manage cloud resources using Kubernetes APIs and patterns.

Pulumi Integration: Pulumi offers the Pulumi Kubernetes Operator (PKO) that provides similar Kubernetes-native infrastructure management capabilities, plus support for YAML-based definitions. Teams can also use Pulumi programs to provision the underlying infrastructure that Crossplane manages, creating layered infrastructure management approaches.

Key Features:

Kubernetes-native: Uses CRDs and standard Kubernetes patterns
Composite resources: Create higher-level infrastructure abstractions
GitOps compatibility: Seamless integration with GitOps workflows
Multi-cloud support: Provision resources across cloud providers
Policy integration: Leverage Kubernetes RBAC and admission controllers

Code Example:

apiVersion: ec2.aws.crossplane.io/v1alpha1
kind: VPC
metadata:
 name: sample-vpc
spec:
 cidrBlock: 10.0.0.0/16
 region: us-east-1
 tags:
 Name: sample-vpc
 providerConfigRef:
 name: aws-provider-config

10. OpenTofu

License: Mozilla Public License 2.0
Best For: Teams seeking an open-source Terraform alternative with community governance

OpenTofu emerged as a fork of Terraform v1.5.x following HashiCorp’s license change, maintained by the Linux Foundation. It provides full compatibility with Terraform while ensuring long-term open-source availability under MPL 2.0 licensing.

Key Features:

True open source: MPL 2.0 license with community governance via Linux Foundation ensuring long-term accessibility
Terraform compatibility: Drop-in replacement maintaining existing workflows, modules, and provider ecosystem
Community-driven development: Transparent roadmap, open contribution process, and vendor-neutral governance
License certainty: Removes concerns about future licensing restrictions for commercial use

When OpenTofu Makes Sense:

Organizations requiring guaranteed open-source licensing for compliance or philosophical reasons
Teams with significant Terraform investments wanting to avoid vendor lock-in
Environments where community governance and transparency are priorities
Projects needing long-term license stability

Architectural Considerations: As a Terraform fork, OpenTofu inherits the same architectural approach, which means teams evaluating it should consider whether HCL-based infrastructure definition meets their long-term needs for testing, IDE integration, and developer productivity, or whether a programming language-based approach might better serve complex scenarios.

Code Example:

resource "aws_instance" "web" {
 ami = "ami-0c55b159cbfafe1d0"
 instance_type = "t3.micro"

 tags = {
 Name = "HelloWorld"
 }
}

output "instance_ip" {
 value = aws_instance.web.public_ip
}

Ansible

License: GPL v3
Best For: Configuration management with some infrastructure provisioning capabilities

Ansible is primarily a configuration management tool, not a pure Infrastructure as Code tool. While Ansible can provision some cloud resources, its core strength lies in configuring and managing software on existing systems rather than comprehensive infrastructure provisioning.

Ansible provides configuration management and limited infrastructure provisioning through its agentless architecture and simple YAML-based playbooks.

Pulumi Integration: Rather than competing with Ansible, Pulumi complements it perfectly. Use Pulumi for infrastructure provisioning and Ansible for configuration management. Pulumi’s Command provider can execute Ansible playbooks as part of your infrastructure deployment, and many Pulumi customers use both tools together for comprehensive infrastructure automation. See example: Deploy WordPress to AWS using Pulumi and Ansible.

Key Features:

Agentless architecture: No software installation required on target systems
YAML playbooks: Human-readable automation definitions
Idempotent operations: Safe to run multiple times
Large module library: Extensive built-in functionality for various systems
Push-based execution: Centralized control and execution

Code Example:

---
- name: Provision AWS infrastructure
 hosts: localhost
 tasks:
 - name: Create VPC
 amazon.aws.ec2_vpc_net:
 name: ansible-vpc
 cidr_block: 10.0.0.0/16
 region: us-east-1
 tags:
 Environment: production
 register: vpc

 - name: Create subnet
 amazon.aws.ec2_vpc_subnet:
 vpc_id: "{{ vpc.vpc.id }}"
 cidr: 10.0.1.0/24
 region: us-east-1
 tags:
 Name: ansible-subnet

Chef

License: Apache 2.0
Best For: Complex configuration management scenarios requiring programmable logic

Chef is a configuration management tool, not an Infrastructure as Code tool. Chef focuses on configuring and maintaining software, services, and system settings on existing infrastructure rather than provisioning cloud resources.

Chef provides configuration management and system automation using Ruby-based recipes and cookbooks, offering powerful programmability for complex configuration scenarios.

Key Features:

Ruby DSL: Full programming language for configuration logic
Agent-based architecture: Continuous compliance and drift detection
Cookbook ecosystem: Reusable configuration patterns and community recipes
Test Kitchen: Infrastructure testing and validation framework
Enterprise features: Advanced reporting and compliance capabilities

Code Example:

# cookbook/recipes/default.rb
package 'nginx' do
 action :install
end

service 'nginx' do
 action [:enable, :start]
end

template '/etc/nginx/sites-available/default' do
 source 'default.erb'
 owner 'root'
 group 'root'
 mode '0644'
 notifies :restart, 'service[nginx]'
end

Puppet

License: Apache 2.0
Best For: Enterprise environments requiring strong governance and compliance

Puppet is a configuration management tool, not an Infrastructure as Code tool. Puppet specializes in maintaining desired configuration state on existing systems and ensuring compliance, rather than provisioning cloud infrastructure.

Puppet offers enterprise-grade configuration management with a focus on compliance, governance, and declarative system state management.

Key Features:

Declarative language: Puppet DSL for describing desired system state
Compliance reporting: Built-in governance and audit capabilities
Forge marketplace: Community modules and enterprise content
Enterprise support: Professional services and enterprise features
Continuous enforcement: Ongoing configuration compliance monitoring

Code Example:

# manifests/webserver.pp
class webserver {
 package { 'nginx':
 ensure => installed,
 }

 service { 'nginx':
 ensure => running,
 enable => true,
 require => Package['nginx'],
 }

 file { '/var/www/html/index.html':
 ensure => file,
 content => '<h1>Hello from Puppet!</h1>',
 owner => 'www-data',
 group => 'www-data',
 mode => '0644',
 }
}

Salt

License: Apache 2.0
Best For: Python-oriented teams requiring high-performance configuration management

Salt is primarily a configuration management and remote execution tool, not a pure Infrastructure as Code tool. While Salt can manage some infrastructure components, its primary focus is on configuring systems and executing commands across large infrastructures.

Salt provides fast, scalable configuration management and remote execution using Python, designed for high-performance system automation at scale.

Key Features:

Python-based: Leverage the Python ecosystem and libraries
High performance: Fast execution across large infrastructures
Event-driven automation: Reactive automation and orchestration
Pillar data system: Secure, hierarchical data management
Flexible communication: Support for various communication patterns

Code Example:

# /srv/salt/webserver.sls
nginx:
 pkg.installed: []
 service.running:
 - enable: True
 - require:
 - pkg: nginx

/var/www/html/index.html:
 file.managed:
 - source: salt://files/index.html
 - user: www-data
 - group: www-data
 - mode: 644

Infrastructure as Code Tools

Kubernetes - Container Orchestration Platform

License: Apache 2.0
Best For: Container-native infrastructure and application management

While primarily a container orchestration platform, Kubernetes itself serves as an infrastructure as code tool through its declarative YAML manifests and API-driven resource management.

Key Features:

Declarative configuration: YAML-based resource definitions
API-driven: RESTful API for all resource operations
Self-healing: Automatic recovery and reconciliation
Extensible: Custom resources and controllers
GitOps compatible: Works seamlessly with Git-based workflows

Code Example:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
spec:
 replicas: 3
 selector:
 matchLabels:
 app: nginx
 template:
 metadata:
 labels:
 app: nginx
 spec:
 containers:
 - name: nginx
 image: nginx:1.21
 ports:
 - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
 name: nginx-service
spec:
 selector:
 app: nginx
 ports:
 - port: 80
 targetPort: 80
 type: LoadBalancer

Infrastructure as Code Security and Compliance Tools

While the tools above focus on provisioning and managing infrastructure, a complete IaC ecosystem includes security scanning and compliance tools. These tools complement your primary IaC tool by providing security analysis, policy enforcement, and compliance checking:

Security Scanning Tools

Snyk - License: Proprietary
Leading developer security platform that includes comprehensive infrastructure as code scanning alongside container and application security. Provides real-time vulnerability detection, compliance checking, and automated remediation guidance. Integrates with popular development tools and CI/CD pipelines with extensive enterprise adoption.

Wiz - License: Proprietary
Comprehensive cloud security platform that includes infrastructure as code scanning capabilities. Provides vulnerability management, compliance monitoring, and security posture assessment across cloud environments. Offers integration with development workflows and supports multiple IaC formats with strong enterprise presence.

Checkov - License: Apache 2.0
Popular open-source static analysis tool for infrastructure as code that scans cloud infrastructure configurations for security and compliance issues. Supports Terraform, CloudFormation, Kubernetes, Helm, ARM templates, and more. Integrates with CI/CD pipelines and provides over 1000+ built-in policies covering CIS benchmarks, PCI DSS, and GDPR compliance.

Linting and Validation Tools

TFLint - License: MPL 2.0
Terraform linter focused on possible errors, best practices, and security issues in Terraform configurations. Provides pluggable rule sets for cloud providers (AWS, Azure, GCP) and helps enforce coding standards, detect deprecated syntax, and prevent common configuration errors.

These security tools integrate into CI/CD pipelines alongside your chosen IaC tool to provide comprehensive security coverage throughout the infrastructure lifecycle.

Pulumi ESC

License: Apache 2.0 (Open Source) / Proprietary (SaaS)
Best For: Teams needing centralized configuration and secrets management across environments and tools

Pulumi ESC (Environments, Secrets, and Configuration) is a comprehensive platform for managing configuration data, secrets, and environment variables across your entire infrastructure and application stack. ESC provides a single source of truth for configuration that works with any infrastructure tool, not just Pulumi.

Key Features:

Universal configuration management: Works with any infrastructure tool, CI/CD system, or application
Hierarchical environments: Compose configuration from multiple sources with inheritance and overrides
Dynamic secrets: Integration with cloud providers for short-lived credentials and just-in-time access
Policy-based access control: Fine-grained permissions and audit logging for configuration access
Multiple consumption methods: CLI, REST API, SDK integration, and direct cloud provider integration
GitOps workflows: Version control integration with pull request-based configuration management

Code Example:

# Production environment configuration
values:
 app:
 name: myapp
 version: ${fn.fromJSON(aws.ecr.getAuthorizationToken).password}
 database:
 connectionString: ${pulumi.database.connectionString}
imports:
 - shared/common
 - aws/production

Pulumi Insights

License: Proprietary (SaaS)
Best For: Organizations needing comprehensive cloud resource visibility, search, and compliance monitoring

Pulumi Insights provides cloud resource search, analytics, and compliance capabilities across your entire multi-cloud infrastructure, regardless of how resources were provisioned. It offers a unified view of your cloud resources with powerful search, cost analysis, and policy enforcement.

Key Features:

Universal cloud inventory: Discover and catalog resources across AWS, Azure, Google Cloud, and Kubernetes
Advanced search and analytics: Query resources by tags, properties, relationships, and compliance status
Cost optimization insights: Resource cost analysis, trends, and optimization recommendations
Compliance monitoring: Continuous policy evaluation and drift detection across all cloud resources
Resource relationships: Understand dependencies and relationships between cloud resources
Integration with any IaC tool: Works with resources created by Pulumi, Terraform, CloudFormation, or manually

Use Cases:

Cloud governance: Ensure compliance with organizational policies and industry standards
Cost management: Identify unused resources and optimization opportunities
Security auditing: Track resource configurations and detect security misconfigurations
Multi-cloud visibility: Single pane of glass for resources across different cloud providers

Infrastructure Automation and Management Platforms

While the above tools focus on defining and provisioning infrastructure, several platforms provide automation, orchestration, and management capabilities that work with Infrastructure as Code tools. Important: These are not IaC tools themselves, but rather automation platforms that rely on underlying IaC tools.

IaC Automation Platforms

Pulumi Cloud Best For: Teams using Pulumi IaC who need enterprise-grade collaboration, security, and governance

Pulumi Cloud is the smartest and easiest way to automate, secure, and manage everything you run in the cloud. It serves as the managed service companion to Pulumi’s open-source infrastructure as code tool, providing enterprise capabilities that extend beyond basic IaC functionality.

The relationship between Pulumi IaC and Pulumi Cloud follows a Git/GitHub model: Pulumi IaC is like Git (fully open source and functional on its own), while Pulumi Cloud is like GitHub (a managed service that makes the open-source tool much easier to use securely at scale with teams).

Key Features:

Managed state backend: Secure, scalable state management with transactional protocols
Team collaboration: Full audit logs, RBAC, and identity provider integration
Centralized secrets management: Pulumi ESC for configuration and secrets across environments
Cloud inventory and insights: Pulumi Insights for search, compliance, and drift detection
Remote deployments: CI/CD integrations and automated workflows
Policy enforcement: Built-in security and compliance policy as code
Multi-product platform: Integrated IaC, secrets management, and cloud insights

Pulumi IaC works with or without Pulumi Cloud - you can use DIY backends (S3, Azure Blob, etc.) or the managed service. However, Pulumi Cloud becomes the default experience when you install the Pulumi CLI, providing instant collaboration capabilities without the overhead of building and maintaining your own infrastructure management platform.

HashiCorp Cloud Platform (HCP) - License: Proprietary (SaaS)
Best For: Organizations standardizing on HashiCorp tools across infrastructure and security lifecycle management

HashiCorp Cloud Platform (HCP) is an enterprise-grade SaaS platform that provides unified lifecycle management for infrastructure and security operations. HCP Terraform (formerly Terraform Cloud) serves as the managed service for Terraform/OpenTofu workflows, while the broader platform integrates multiple HashiCorp tools.

Key Features:

HCP Terraform management: Workspace organization, remote execution, and state management for Terraform
Infrastructure lifecycle automation: Continuous validation, drift detection, and module lifecycle management
Private VCS access: Secure integration with private version control repositories
Policy enforcement: Sentinel policy-as-code framework for compliance and governance
Integrated security services: HCP Vault for secrets management, HCP Consul for service networking
Enterprise access controls: RBAC, SAML SSO integration, and fine-grained permissions
Module and image management: HCP Packer for automated machine/container image creation

HCP focuses specifically on HashiCorp tool integration and provides a comprehensive platform for organizations that have standardized on the HashiCorp ecosystem for infrastructure and security operations.

Spacelift - Spacelift is not an Infrastructure as Code tool—it’s an automation and workflow platform that relies on other IaC tools like Terraform, OpenTofu, Pulumi, CloudFormation, and Kubernetes. Spacelift provides CI/CD pipelines, policy enforcement, and collaboration features for teams using these underlying IaC tools.

Env0 - Env0 is not an Infrastructure as Code tool—it’s an automation platform that provides workflow management, governance, and collaboration features for existing IaC tools like Terraform, OpenTofu, and Terragrunt. It adds CI/CD pipelines, cost management, and policy enforcement on top of these tools.

Atlantis - An open-source tool that provides GitOps-style workflows for Terraform and OpenTofu by automatically running terraform plan and apply operations via pull request automation.

Development Environment Tools

Vagrant - Vagrant is not an Infrastructure as Code tool—it’s a development environment management tool that creates and configures lightweight, reproducible virtual development environments. While it can provision VMs, its focus is on local development environments rather than cloud infrastructure provisioning.

Docker Compose - While not an IaC tool, Docker Compose defines multi-container applications and can be used alongside IaC tools for application deployment after infrastructure provisioning.

These platforms and tools serve important roles in the infrastructure automation ecosystem but should not be confused with Infrastructure as Code tools themselves. They enhance and orchestrate the work of actual IaC tools rather than replacing them.

The Future of Infrastructure as Code

The infrastructure as code landscape is rapidly evolving toward software engineering maturity, with several transformative trends reshaping how organizations approach infrastructure:

Software Engineering Convergence: The most significant trend is the convergence of infrastructure and software engineering practices. Organizations are moving away from limited DSLs toward full programming languages that enable testing, debugging, refactoring, and other software engineering best practices. This shift enables infrastructure teams to leverage the same tools, skills, and methodologies that have proven successful in application development.

Real-Time Cloud Integration: Native cloud provider SDK integration is becoming the standard, replacing community-maintained providers that lag behind new cloud features. Organizations expect same-day access to new cloud services without waiting weeks or months for provider updates.

Comprehensive Testing Paradigms: Infrastructure testing is evolving beyond basic integration tests to include unit testing, property-based testing, and continuous validation. Teams are applying test-driven development principles to infrastructure, catching issues before deployment rather than discovering them in production.

Internal Developer Platform Evolution: Organizations are building sophisticated Internal Developer Platforms that provide self-service infrastructure capabilities while maintaining governance and compliance. These platforms leverage infrastructure as code tools to create standardized, reusable components that accelerate development velocity.

AI-Enhanced Development: Integration of AI tools to help generate, optimize, and troubleshoot infrastructure code, with particular strength in environments that use familiar programming languages where AI assistance is most mature. Emerging technologies like Model Context Protocol (MCP) and AI prompt templates are beginning to enable more sophisticated AI-infrastructure interactions.

These trends favor tools that embrace software engineering principles from the ground up, rather than attempting to retrofit programming capabilities onto template-based or DSL-limited approaches.

Migration and Adoption Strategies

Organizations don’t need to choose between maintaining existing infrastructure and adopting modern IaC approaches. Proven migration strategies enable gradual adoption while preserving operational stability.

Incremental Adoption Approaches

Team-by-Team Migration: Start with new projects or specific teams, allowing gradual skill development and process refinement. Teams can maintain existing infrastructure while building new capabilities with modern tools.

Project-by-Project Transition: Migrate individual applications or services incrementally, enabling teams to learn and optimize approaches before expanding scope.

Hybrid Operations: Use state integration and import tools to reference existing infrastructure while building new components with modern IaC tools.

Proven Migration Timelines

Real-world migrations demonstrate that adoption can be remarkably fast with proper tooling:

Atlassian Bitbucket: Complete Terraform to Pulumi migration in 2 days using automated conversion tools. This rapid migration was enabled by existing Python expertise on the team, well-structured Terraform code, and straightforward infrastructure patterns that converted cleanly.
Enterprise migrations: Typical team migrations complete in weeks, not months, depending on infrastructure complexity and team preparation
Learning curve: Teams with programming experience adapt to language-based IaC approaches within days, while those new to programming may require additional training time

Migration Tools and Resources

Automated Conversion: Tools like tf2pulumi and pulumi convert automatically translate existing infrastructure definitions, preserving logic and structure while upgrading to modern approaches.

State Integration: Import existing cloud resources and reference Terraform state during transition periods, enabling zero-downtime migrations.

Training and Support: Comprehensive documentation, tutorials, and community resources accelerate team onboarding and reduce migration risks.

Best Practices for Successful Adoption

Start with pilot projects to build confidence and establish patterns
Leverage automated migration tools to reduce manual conversion effort
Maintain state integration during transition periods for operational continuity
Invest in team training to maximize productivity gains from modern approaches
Establish testing practices early to realize reliability and quality benefits

The key insight: migration to modern IaC approaches is a technical upgrade, not a complete rebuild. Organizations can preserve existing investments while gaining access to superior tooling and practices.

Frequently Asked Questions

Which IaC tool should I choose for AWS?

For teams wanting programming languages: Pulumi IaC and AWS CDK both offer excellent developer experiences with general-purpose programming languages. Pulumi provides multi-cloud flexibility, while CDK offers deep AWS-native integration.

For AWS-only deployments: CloudFormation provides the deepest native AWS service support and direct integration with AWS services.

For Terraform ecosystem users: OpenTofu provides open-source licensing with Terraform compatibility, while Terraform offers extensive community resources and established workflows.

Is Terraform still worth learning in 2025?

Terraform remains a valuable skill and viable choice for many scenarios, though teams should consider their specific needs and long-term goals:

When Terraform Makes Sense:

Teams building on existing Terraform infrastructure and expertise
Organizations with successful Terraform workflows and established processes
Projects that benefit from Terraform’s extensive module ecosystem
Teams comfortable with HCL and template-based approaches

When to Consider Alternatives:

Teams wanting comprehensive testing capabilities (unit, property, integration testing)
Organizations requiring full IDE support with debugging and refactoring
Projects needing complex programmatic logic or extensive code reuse
Teams with strong programming backgrounds who prefer familiar languages

Key Considerations:

Licensing: Terraform’s Business Source License may create restrictions for some commercial scenarios
Ecosystem: Terraform has the largest provider ecosystem and community resources
Learning investment: Consider whether learning HCL aligns with your team’s skill development goals
Migration options: Tools exist for migrating between different IaC platforms when needs change

The choice often depends on team background, infrastructure complexity, and development workflow preferences rather than one approach being universally superior.

How do I get started with infrastructure as code?

Choose Based on Your Team Profile:

Programming-oriented teams: Consider Pulumi IaC for familiar languages with full IDE support, testing frameworks, and multi-cloud flexibility
Template-oriented teams: OpenTofu or Terraform offer extensive community resources, established workflows, and broad ecosystem support
Cloud-specific teams: Native tools (AWS CDK/CloudFormation, Azure ARM/Bicep, Google Cloud Infrastructure Manager) provide deep platform integration
Kubernetes-focused teams: Consider Crossplane or Pulumi Kubernetes Operator for container-native approaches

Getting Started Steps:

Start small: Begin with simple projects like deploying a single application or basic infrastructure
Use examples: Leverage existing templates, tutorials, and community examples to accelerate learning
Plan for growth: Consider how your tool choice will scale with team size and infrastructure complexity
Experiment: Most tools offer free tiers or trials - try multiple approaches with simple projects to find what fits your team best

What’s the difference between configuration management and infrastructure provisioning?

Infrastructure provisioning (Pulumi IaC, Terraform, CloudFormation) creates and manages cloud resources like VMs, networks, and databases
Configuration management (Ansible, Chef, Puppet) configures and maintains software on existing systems
Many modern tools do both, with Pulumi IaC and Ansible offering comprehensive capabilities across both domains

Can I use multiple IaC tools together?

Absolutely! Many organizations use complementary tools for different aspects of infrastructure management:

Pulumi + Configuration Management:

Pulumi + Ansible: Infrastructure provisioning + server configuration (example)
Pulumi + Chef/Puppet: Cloud resources + complex configuration management

Pulumi + Native Cloud Tools:

Reference existing CloudFormation/ARM deployments from Pulumi programs
Import CloudFormation/ARM resources into Pulumi for gradual migration
Use Pulumi alongside CDK for different parts of AWS infrastructure

Pulumi + Kubernetes:

Pulumi Kubernetes Operator (PKO) for GitOps workflows
Pulumi + Crossplane for layered infrastructure management
Pulumi + security scanners like Checkov or Terrascan for compliance

Terraform + Pulumi Coexistence:

Use Terraform for base infrastructure and Pulumi for Internal Developer Platforms (IDPs)
Reference existing Terraform state from Pulumi programs during gradual migration
Manage different infrastructure layers with different tools based on team expertise

Pulumi IaC is designed for heterogeneous environments where multiple tools may be in use. For example, you can manage existing Terraform or CloudFormation resources with Pulumi, either using both tools in tandem or for temporary management while migrating to native Pulumi IaC code. Other Pulumi tools, like Pulumi IDP, also enable you to manage IaC self-service workflows like other tools on this list. See what’s possible when migrating to Pulumi.

Which tool has the best learning resources?

Pulumi: Excellent documentation with examples in multiple languages, comprehensive tutorials
Terraform/OpenTofu: Extensive community content, many courses and books available
AWS CDK: Outstanding official documentation with workshops and examples
Kubernetes: Vast ecosystem but steeper learning curve

How important is open-source licensing for IaC tools?

Very important for long-term strategy:

Apache 2.0 (Pulumi, CDK) offers maximum flexibility
MPL 2.0 (OpenTofu) ensures open-source availability
BSL (Terraform) restricts commercial competitors
Proprietary (CloudFormation, ARM) ties you to specific vendors

Choose open-source tools like Pulumi or OpenTofu to avoid vendor lock-in.

What about security and compliance?

All major IaC tools support security best practices:

Built-in policy engines: Pulumi CrossGuard, AWS Config, Azure Policy
Third-party scanners: Checkov, KICS, Terrascan work with all tools
Compliance frameworks: Most tools support SOC 2, PCI DSS, CIS benchmarks
Secret management: Integration with Vault, AWS Secrets Manager, Azure Key Vault

Pulumi offers the most comprehensive built-in security features with CrossGuard policy as code.

Can I migrate from one IaC tool to another?

Yes, and many organizations are successfully migrating to overcome limitations in their current tools. Migration tools and proven approaches exist:

Proven Migration Success Stories:

Atlassian Bitbucket: Completed migration from Terraform to Pulumi’s Python-based IaC in just 2 days using migration tools
Starburst: Achieved 112x faster deployments after incrementally migrating from Terraform
Multiple organizations: Report 80-90% deployment time reductions after moving to programming language-based approaches

Available Migration Tools:

Pulumi: Offers pulumi convert for importing from Terraform, ARM, and CloudFormation with state integration
Terraformer: Can import existing cloud resources into Terraform/OpenTofu
CDK Migrate: Helps move from CloudFormation to CDK
Manual migration: Always possible by recreating resources in the new tool

Migration Strategies:

Incremental adoption: Migrate team-by-team or project-by-project without disruption
State integration: Reference existing infrastructure during transition periods
Zero downtime: Tools like Pulumi enable seamless migration without service interruption

The key is choosing tools that provide comprehensive migration support and incremental adoption paths rather than requiring “rip and replace” approaches.

Conclusion: The Evolution of Infrastructure as Code

The infrastructure as code landscape in 2025 reflects a maturing field where different approaches serve different organizational needs and team preferences. The evolution from manual processes to automated infrastructure has branched into multiple viable paths, each with distinct advantages.

The Spectrum of Approaches:

Template-based tools like Terraform and OpenTofu continue to serve teams effectively, particularly those comfortable with declarative configuration and established HCL workflows. Cloud-native solutions provide deep platform integration for single-cloud strategies. Programming language-based approaches offer familiar development experiences for teams seeking comprehensive testing, IDE integration, and code reusability.

Evidence of Success Across Approaches:

Organizations achieve significant improvements regardless of their chosen path—the key is selecting tools that align with team expertise and infrastructure requirements. Understanding what DevOps is and platform engineering concepts helps inform these decisions. Success stories span the entire ecosystem, from Terraform’s widespread enterprise adoption to programming language approaches enabling dramatic productivity gains at companies like Unity, Snowflake, and Starburst.

Choosing Your Path:

The most successful organizations focus on key decision criteria:

Team background: Match tools to existing skills and preferred development approaches
Infrastructure complexity: Consider testing, abstraction, and maintainability needs
Organizational constraints: Factor in licensing, governance, and compliance requirements
Growth trajectory: Plan for how needs may evolve with scale and team expansion
Integration requirements: Ensure compatibility with existing workflows and toolchains

The Future of Infrastructure:

The industry continues evolving toward treating infrastructure as software, but this transformation takes many forms. Organizations exploring serverless architectures and container strategies particularly benefit from programmable infrastructure approaches. Whether through enhanced DSLs, visual design tools, programming languages, or hybrid approaches, the goal remains consistent: enabling teams to manage infrastructure with the same reliability, collaboration, and velocity they expect from modern software development.

For teams ready to embrace programming language-based infrastructure as code, Get started with Pulumi to experience how familiar languages and software engineering practices can transform infrastructure management with comprehensive testing, powerful abstractions, and seamless multi-cloud support.

New: Use Terraform Modules in Pulumi Without Conversion

Anton Tayanovskyy — Mon, 23 Jun 2025 00:00:00 +0000

Today, we’re excited to announce a major advancement in Pulumi’s mission to make modern infrastructure as code accessible to every developer: direct support for executing Terraform modules. This new capability addresses one of the most significant challenges our users face when migrating from Terraform to Pulumi—complex projects with extensive module dependencies.

The Path to Modern Infrastructure as Code

At Pulumi, we believe the ideal infrastructure as code experience leverages the full power of modern programming languages, AI-assisted development, and cloud-native tooling. Our vision is that every team should be able to write infrastructure code in their preferred language—TypeScript, Python, Go, C#, or Java—with full IntelliSense, testing capabilities, and AI-powered assistance.

However, we also understand the reality that many organizations have invested years building extensive Terraform module estates. These modules often contain critical business logic, compliance configurations, and battle-tested patterns that teams can’t always rewrite overnight.

This new capability bridges that gap, giving you the best of both worlds: the ability to start new projects in Pulumi immediately while preserving your existing Terraform modules until you’re ready to migrate them.

Strategic Migration Approach

Here’s how we recommend teams approach this transition:

Phase 1: New Projects in Pulumi Start all new infrastructure projects in Pulumi to immediately gain the benefits of modern IaC—better developer experience, AI assistance, and cloud-native tooling.

Phase 2: Incremental Module Migration Use the new Terraform module support to bring existing modules into Pulumi projects without rewriting them. This gives you immediate access to Pulumi Cloud’s state management, deployment workflows, and team collaboration features across all your IaC.

Phase 3: Full Migration (When Ready) Gradually migrate your Terraform modules to native Pulumi components as time and resources permit. With AI-assisted development tools making this easier than ever, you can modernize at your own pace.

This approach eliminates the “big bang” migration risk while ensuring you’re not stuck with legacy tooling for new projects.

What This Means for Your Team

This isn’t just a technical feature—it’s a strategic enabler for teams looking to modernize their infrastructure practices. Here’s what this announcement means:

For Terraform Users: You can now migrate to Pulumi incrementally, keeping your existing modules intact while gaining access to Pulumi’s powerful programming language features, better state management, and enhanced developer experience.

For Platform Teams: You can standardize on Pulumi for new infrastructure while seamlessly incorporating existing Terraform modules, reducing migration risk and accelerating adoption.

For DevOps Engineers: You get the best of both worlds—the reliability of proven Terraform modules with Pulumi’s superior tooling, testing capabilities, and deployment workflows.

How It Works

The new feature consists of three key components:

1. Direct Module Execution

The pulumi package add terraform-module command now supports modules from Terraform and OpenTofu registries, as well as locally managed modules. This is powered by our new terraform-module provider, which orchestrates Terraform execution while maintaining the full Pulumi lifecycle.

2. Enhanced Conversion Support

Our pulumi convert --from terraform tool now supports a special annotation // @pulumi-terraform-module <pulumi-package-name> that tells the converter to execute modules directly rather than attempting to translate them. This preserves your existing module logic while enabling Pulumi’s benefits.

3. Configuration Synchronization

Pulumi providers now expose helper methods like awsProvider.terraformConfig() to keep configuration consistent between Pulumi and Terraform providers, eliminating the need to maintain duplicate configuration.

Real-World Impact

Let me walk you through a practical example that demonstrates the power of this integration.

First, install the latest version of the Pulumi CLI (v3.178.0 or later is required) and create a new Pulumi project using pulumi new $language such as pulumi new typescript.

Setting Up a VPC Module

Next, add a Terraform module to your Pulumi project:

$ pulumi package add terraform-module terraform-aws-modules/vpc/aws 6.0.0 vpcmod
Successfully generated a Nodejs SDK for the vpcmod package at /Users/anton/tmp/2025-06-23/blog/sdks/vpcmod

$ pulumi package add terraform-module terraform-aws-modules/vpc/aws 6.0.0 vpcmod

Successfully generated a Python SDK for the vpcmod package at /workdir/vpcmod

Resolved 13 packages in 111ms
 Built pulumi-vpcmod @ file:///workdir/sdks/vpcmod
Prepared 4 packages in 297ms
Installed 4 packages in 1ms
 + arpeggio==2.0.2
 + attrs==25.3.0
 + parver==0.5
 + pulumi-vpcmod==6.0.0 (from file:///workdir/sdks/vpcmod)

You can then import the SDK in your Python code with:

 import pulumi_vpcmod as vpcmod

$ pulumi package add terraform-module terraform-aws-modules/vpc/aws 6.0.0 vpcmod

Using Terraform CLI for schema inference
Successfully generated a Go SDK for the vpcmod package at /workdir/sdks/vpcmod
Go mod file updated to use local sdk for vpcmod
To use this package, import github.com/pulumi/pulumi-terraform-module/sdks/go/vpcmod/v6/vpcmod
Added package "vpcmod" to Pulumi.yaml

$ pulumi package add terraform-module terraform-aws-modules/vpc/aws 6.0.0 vpcmod

Using Terraform CLI for schema inference
Successfully generated a .NET SDK for the vpcmod package at /workdir/sdks/vpcmod

Reference `sdks\vpcmod\Pulumi.Vpcmod.csproj` added to the project.
You also need to add the following to your .csproj file of the program:

 <DefaultItemExcludes>$(DefaultItemExcludes);sdks/**/*.cs</DefaultItemExcludes>

You can then use the SDK in your .NET code with:

 using Pulumi.Vpcmod;

Added package "vpcmod" to Pulumi.yaml

$ pulumi package add terraform-module terraform-aws-modules/vpc/aws 6.0.0 vpcmod

Using Terraform CLI for schema inference
Successfully generated a Java SDK for the vpcmod package at /workdir/sdks/vpcmod

To use this SDK in your Java project, complete the following steps:

1. Copy the contents of the generated SDK to your Java project:
 cp -r /workdir/sdks/vpcmod/src/* /workdir/src

2. Add the SDK's dependencies to your Java project's build configuration.
 If you are using Maven, add the following dependencies to your pom.xml:

 <dependencies>
 <dependency>
 <groupId>com.google.code.findbugs</groupId>
 <artifactId>jsr305</artifactId>
 <version>3.0.2</version>
 </dependency>
 <dependency>
 <groupId>com.google.code.gson</groupId>
 <artifactId>gson</artifactId>
 <version>2.8.9</version>
 </dependency>
 </dependencies>

Added package "vpcmod" to Pulumi.yaml

$ pulumi package add terraform-module terraform-aws-modules/vpc/aws 6.0.0 vpcmod

Added package "vpcmod" to Pulumi.yaml

Pulumi automatically generates a local SDK with full support for your language:

$ ls sdks/vpcmod
README.md index.ts node_modules provider.ts tsconfig.json utilities.ts
bin module.ts package.json scripts types

$ ls sdks/vpcmod
build pulumi_vpcmod pulumi_vpcmod.egg-info setup.py

$ ls sdks/vpcmod
go.mod vpcmod

$ ls sdks/vpcmod
Inputs Provider.cs README.md
logo.png pulumi-plugin.json Utilities.cs
Module.cs Pulumi.Vpcmod.csproj version.txt

$ ls sdks/vpcmod
README.md src

$ ls sdks/vpcmod
vpcmod-6.0.0.yaml

Pulumi automatically links the generated SDK into your project.

Using the Module in Your Code

Now you can use the module with full IntelliSense support:

import * as pulumi from "@pulumi/pulumi";
import * as vpcmod from '@pulumi/vpcmod';

const vpc = new vpcmod.Module("test-vpc", {
 azs: ["us-west-2a", "us-west-2b"],
 name: `test-vpc-${pulumi.getStack()}`,
 cidr: "10.0.0.0/16",
 public_subnets: [
 "10.0.1.0/24",
 "10.0.2.0/24",
 ],
 private_subnets: [
 "10.0.3.0/24",
 "10.0.4.0/24",
 ],
 enable_nat_gateway: true,
 single_nat_gateway: true,
});

export const publicSubnets = vpc.public_subnets;
export const privateSubnets = vpc.private_subnets;

import pulumi
import pulumi_aws as aws
import pulumi_vpcmod as vpcmod

aws_provider = aws.Provider("awsprovider", region="us-east-1")

vpcmod_provider = vpcmod.Provider("vpcprovider", aws=aws_provider.terraform_config().result)

vpc = vpcmod.Module(
 "test-vpc",
 azs=["us-west-2a", "us-west-2b"],
 name=f"test-vpc{pulumi.get_stack()}",
 cidr="10.0.0.0/16",
 public_subnets=[
 "10.0.1.0/24",
 "10.0.2.0/24",
 ],
 private_subnets=[
 "10.0.3.0/24",
 "10.0.4.0/24",
 ],
 enable_nat_gateway=True,
 single_nat_gateway=True,
)

pulumi.export("publicSubnets", vpc.public_subnets)
pulumi.export("privateSubnets", vpc.private_subnets)

package main

import (
 "fmt"

 "github.com/pulumi/pulumi-terraform-module/sdks/go/vpcmod/v6/vpcmod"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func run(ctx *pulumi.Context) error {
 stack := ctx.Stack()

 vpc, err := vpcmod.NewModule(ctx, "test-vpc", &vpcmod.ModuleArgs{
 Azs: pulumi.StringArray{
 pulumi.String("us-west-2a"),
 pulumi.String("us-west-2b"),
 },
 Name: pulumi.String(fmt.Sprintf("test-vpc-%s", stack)),
 Cidr: pulumi.String("10.0.0.0/16"),
 Public_subnets: pulumi.StringArray{
 pulumi.String("10.0.1.0/24"),
 pulumi.String("10.0.2.0/24"),
 },
 Private_subnets: pulumi.StringArray{
 pulumi.String("10.0.3.0/24"),
 pulumi.String("10.0.4.0/24"),
 },
 Enable_nat_gateway: pulumi.Bool(true),
 Single_nat_gateway: pulumi.Bool(true),
 })
 if err != nil {
 return err
 }

 ctx.Export("publicSubnets", vpc.Public_subnets)
 ctx.Export("privateSubnets", vpc.Private_subnets)

 return nil
}

func main() {
 pulumi.Run(run)
}

using System.Collections.Generic;
using Pulumi;
using Vpc = Pulumi.Vpcmod;

return await Deployment.RunAsync(() =>
{
 var vpc = new Vpc.Module("test-vpc", new Vpc.ModuleArgs
 {
 Azs = new string [] {
 "us-west-2a",
 "us-west-2b",
 },
 Cidr = "10.0.0.0/16",
 Public_subnets = new string[] {
 "10.0.1.0/24",
 "10.0.2.0/24"
 },
 Private_subnets = new string[] {
 "10.0.1.0/24",
 "10.0.2.0/24"
 },
 Enable_nat_gateway=true,
 Single_nat_gateway=true
 });

 return new Dictionary<string, object?>
 {
 ["publicSubnets"] = vpc.Public_subnets,
 ["privateSubnets"] = vpc.Private_subnets
 };
});

package myproject;

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.core.Output;
import com.pulumi.deployment.Deployment;
import com.pulumi.vpcmod.Module;
import com.pulumi.vpcmod.ModuleArgs;

public class App {

 public static void main(String[] args) {
 Pulumi.run(ctx -> {
 final var stackName = Deployment.getInstance().getStackName();

 final var vpc = new Module("test-vpc", ModuleArgs.builder()
 .name("test-vpc-"+stackName)
 .azs("us-west-2a", "us-west-2b")
 .cidr("10.0.0.0/16")
 .public_subnets("10.0.1.0/24", "10.0.2.0/24")
 .private_subnets("10.0.3.0/24", "10.0.4.0/24")
 .enable_nat_gateway(true)
 .single_nat_gateway(true)
 .build());

 ctx.export("publicSubnets", vpc.public_subnets());
 ctx.export("privateSubnets", vpc.private_subnets());
 });
 }
}

name: my-program

runtime: yaml

resources:
 vpc:
 type: vpcmod:index:Module
 properties:
 azs:
 - us-west-2a
 - us-west-2b
 name: test-vpc-${pulumi.stack}
 cidr: 10.0.0.0/16
 public_subnets:
 - 10.0.1.0/24
 - 10.0.2.0/24
 private_subnets:
 - 10.0.3.0/24
 - 10.0.4.0/24
 enable_nat_gateway: true
 single_nat_gateway: true

outputs:
 publicSubnets: ${vpc.public_subnets}
 privateSubnets: ${vpc.private_subnets}

packages:
 vpcmod:
 source: terraform-module
 version: 0.1.7
 parameters:
 - terraform-aws-modules/vpc/aws
 - 6.0.0
 - vpcmod

Seamless Deployment

When you run pulumi up, Pulumi orchestrates the Terraform module execution while providing its signature preview and deployment experience:

Previewing update (dev)

View in Browser (Ctrl+O): https://app.pulumi.com/anton-pulumi-corp/anton-blog/dev/previews/5851682a-a3e3-4f47-a50e-3d7b4f4e6c34

 Type Name Plan
 + pulumi:pulumi:Stack anton-blog-dev create
 + └─ vpcmod:index:Module test-vpc create
 + ├─ vpcmod:tf:aws_route_table_association module.test-vpc.aws_route_table_association.private[0] create
 + ├─ vpcmod:tf:aws_subnet module.test-vpc.aws_subnet.private[1] create
 + ├─ vpcmod:tf:aws_route_table_association module.test-vpc.aws_route_table_association.public[1] create
 + ├─ vpcmod:tf:aws_subnet module.test-vpc.aws_subnet.private[0] create
 + ├─ vpcmod:tf:aws_route_table module.test-vpc.aws_route_table.private[0] create
 + ├─ vpcmod:tf:aws_subnet module.test-vpc.aws_subnet.public[1] create
 + ├─ vpcmod:tf:aws_nat_gateway module.test-vpc.aws_nat_gateway.this[0] create
 + ├─ vpcmod:tf:aws_route module.test-vpc.aws_route.public_internet_gateway[0] create
 + ├─ vpcmod:tf:aws_route module.test-vpc.aws_route.private_nat_gateway[0] create
 + ├─ vpcmod:tf:aws_default_network_acl module.test-vpc.aws_default_network_acl.this[0] create
 + ├─ vpcmod:tf:aws_default_route_table module.test-vpc.aws_default_route_table.default[0] create
 + ├─ vpcmod:tf:aws_subnet module.test-vpc.aws_subnet.public[0] create
 + ├─ vpcmod:tf:aws_internet_gateway module.test-vpc.aws_internet_gateway.this[0] create
 + ├─ vpcmod:tf:aws_vpc module.test-vpc.aws_vpc.this[0] create
 + ├─ vpcmod:tf:aws_default_security_group module.test-vpc.aws_default_security_group.this[0] create
 + ├─ vpcmod:tf:aws_route_table module.test-vpc.aws_route_table.public[0] create
 + ├─ vpcmod:tf:aws_eip module.test-vpc.aws_eip.nat[0] create
 + ├─ vpcmod:tf:aws_route_table_association module.test-vpc.aws_route_table_association.public[0] create
 + └─ vpcmod:tf:aws_route_table_association module.test-vpc.aws_route_table_association.private[1] create

Resources:
 + 21 to create

The infrastructure deploys successfully, and the Terraform state is automatically stored securely in Pulumi Cloud with full secret encryption support.

Migration Made Simple

For teams starting with existing Terraform code, the migration process is straightforward. Simply annotate your modules with a special comment:

// @pulumi-terraform-module vpcmod
module "my-vpc" {
 source = "terraform-aws-modules/vpc/aws"
 version = "6.0.0"
 azs = ["us-west-2a", "us-west-2b"]
 name = "test-vpc-123"
 public_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
 private_subnets = ["10.0.3.0/24", "10.0.4.0/24"]
 enable_nat_gateway = true
 single_nat_gateway = true
}

Then run the conversion (replace typescript with your language of choice):

pulumi convert --from terraform --language typescript --out my-pulumi-project

The resulting project is ready to deploy with full Pulumi functionality.

Configuration Management

One of the key benefits is seamless configuration management. Instead of maintaining separate configurations for Pulumi and Terraform providers, you can reuse your existing Pulumi provider configuration:

const awsProvider = new aws.Provider("awsprovider", {
 region: "us-west-2",
 // more configuration
});

// Pass the AWS configuration to your VPC module provider
const vpcmodProvider = new vpcmod.Provider("vpcprovider", {
 "aws": awsProvider.terraformConfig().result
});

// Use the VPC module provider in your Module
const vpc = new vpcmod.Module("test-vpc", {...},
 {provider: vpcmodProvider}
);

import pulumi
import pulumi_aws as aws
import pulumi_vpcmod as vpcmod

aws_provider = aws.Provider("awsprovider", region="us-west-2")

# Pass the AWS configuration to your VPC module provider
vpcmod_provider = vpcmod.Provider("vpcprovider", aws=aws_provider.terraform_config().result)

# Use the VPC module provider in your Module
vpc = vpcmod.Module("test-vpc", ..., opts=pulumi.ResourceOptions(provider=vpcmod_provider))

func run(ctx *pulumi.Context) error {
 stack := ctx.Stack()

 awsProvider, err := aws.NewProvider(ctx, "awsprovider", &aws.ProviderArgs{
 Region: pulumi.String("us-west-2"),
 })
 if err != nil {
 return err
 }

 awsProviderTfConfig, err := awsProvider.TerraformConfig(ctx)
 if err != nil {
 return err
 }

 // Pass the AWS configuration to your VPC module provider
 vpcProvider, err := vpcmod.NewProvider(ctx, "vpcprovider", &vpcmod.ProviderArgs{
 Aws: awsProviderTfConfig.Result(),
 })
 if err != nil {
 return err
 }

 // Use the VPC module provider in your Module
 vpc, err := vpcmod.NewModule(ctx, "test-vpc", &vpcmod.ModuleArgs{...}, pulumi.Provider(vpcProvider))
 if err != nil {
 return err
 }

 ctx.Export("publicSubnets", vpc.Public_subnets)
 ctx.Export("privateSubnets", vpc.Private_subnets)

 return nil
}

This demonstrates how Terraform modules integrate seamlessly with existing Pulumi programs, allowing you to compose infrastructure components naturally.

What’s Supported

The integration provides comprehensive support for Pulumi’s core features:

Full Lifecycle Management: Preview, update, refresh, and destroy operations work exactly as expected
Resource Visibility: The entire resource tree is visible in Pulumi’s UI and CLI
Type Safety: Generated TypeScript interfaces provide IntelliSense and compile-time checking
Secret Management: First-class support for Pulumi’s secret encryption
Provider Configuration: Full control over Terraform provider settings

Current Limitations

As with any new technology integration, there are some current limitations to be aware of:

Transforms resource options are not supported
Targeted operations like pulumi up --target are not available
The protect resource option is not supported
Dependent resources may have limited support in some scenarios

Looking Ahead

This release represents a significant milestone in our journey to make infrastructure as code accessible to every developer. We’re already working on the next phase, which includes:

Enhanced state import capabilities for seamless Terraform-to-Pulumi migrations
Improved type inference for complex module schemas
Expanded support for additional Terraform features

The Path Forward

While this capability enables you to preserve your existing Terraform modules, we encourage teams to view this as a stepping stone rather than a final destination. The full benefits of modern infrastructure as code—including AI-assisted development, advanced testing capabilities, and seamless integration with modern development workflows—are best realized with native Pulumi components.

With AI developer tools making code conversion easier than ever, we’re committed to helping teams migrate their Terraform modules to native Pulumi when they’re ready. This capability ensures you can start your modernization journey today without being blocked by existing technical debt.

Get Started Today

The Terraform module support is available immediately. Install the latest Pulumi CLI and try it out with your existing Terraform modules. We’ve prepared comprehensive examples showcasing real-world scenarios, from simple VPC deployments to complex multi-module architectures.

For detailed documentation on using Terraform modules in Pulumi, including advanced configuration options, troubleshooting guides, and best practices, see our comprehensive guide.

If you encounter any issues or have suggestions for improvement, please open an issue or reach out in our Community Slack. Your feedback is invaluable as we continue to evolve this capability.

This release embodies our commitment to meeting developers where they are while providing a clear path forward to modern infrastructure practices. We’re excited to see how teams use this capability to accelerate their infrastructure modernization journey.

From Configuration Chaos to Programming Languages

Daniel Ward — Tue, 03 Jun 2025 00:00:00 +0000

This post is based on our video interview with Daniel Ward, a Software Developer/Consultant at Lean TECHniques and Microsoft MVP. Daniel shares his strategies for moving teams from configuration chaos to programming languages for infrastructure, including the 10% rule for change, viral adoption, and why Pulumi beats YAML for complex systems. Watch the video below or read on. - Adam Gordon Bell

Imagine your infrastructure codebase has evolved from a few files to thousands of lines across dozens of configuration files. Your team spends hours deciphering CloudFormation templates, your AWS CDK deployments take 30+ minutes, and introducing any change becomes a multi-day effort. This is the reality many organizations face when their infrastructure-as-code approach outgrows their tooling.

As a consultant and developer who helps organizations improve their software delivery processes, I’ve seen firsthand how the right technologies—specifically using actual programming languages like C#—can transform infrastructure management instead of forcing teams to use declarative configuration files.

My Background: Coaching Teams Through Technical Transformation

My background is primarily as a .NET developer—I’m now a Microsoft MVP in my first year—though I work with TypeScript and other languages as needed. About six years ago, I moved into consulting, or what we call “coaching” at Lean Techniques.

The idea isn’t just to write code for clients or tell them what to do and leave. Our goal is that once we leave, they don’t need us anymore. We’re essentially trying to put ourselves out of a job.

Organizations bring me in for various reasons—from implementing automated testing after costly failures to migrating from mainframes to the cloud. Sometimes it’s about product delivery challenges, like month-long sprints that never complete on time.

It’s about bringing places up to a modern standard. As we say at Lean Techniques, turning IT from a cost center into a competitive advantage.

If you’re ready to move from sprawling configuration files to code-centric infrastructure, here are eight practical steps to guide you:

1. Follow the 10% Rule for Sustainable Change

One of my guiding principles comes from Gerald Weinberg’s book “The Secrets of Consulting”: the 10% rule. When entering a new team or organization, don’t try to improve more than 10% at a time.

There are a few reasons for this. One is that you can actually end up making the client look bad. If you improve everything at once, their boss might ask why this consultant fixed everything in six months when the team couldn’t fix it in five years.

But there’s a deeper reason related to social dynamics. Any social group, in programming or outside of work—if you come in new and try to change how the group works before familiarizing yourself with it, people will be resistant. They’ll ask “Who do you think you are? You just got here!” And they’re right—you could be wrong about some things. You have to understand how they work to understand what the problems are.

This applies directly to introducing new technologies like infrastructure as code. Rather than overhauling everything at once, I recommend starting small.

If a place is completely new to infrastructure as code, I’ll tell them to start small. None of their engineers know how to do this yet, and I’m not going to do all the work for them and leave, because then none of their engineers will know how to maintain it.

2. Quantify the Cost of Inaction to Overcome Resistance

Even with a measured approach, resistance is inevitable. I’ve experienced teams that are exceptionally open to improvement, often coming from difficult situations and eager for change. I’ve also worked with teams that resist most suggestions, where engineers feel the consultant was forced upon them by management.

It’s always easier if you can do pull-based versus push-based change—where the team has asked for your help instead of the manager telling them “I’m inflicting this help on you.”

For those looking to influence change within their organization, I’ve found that influencing upper-level management comes down to numbers. They deal with too many teams to get into specifics—they want numbers. If you can show how many hours your team spends each week manually pushing code or waiting on another team, and multiply that by engineer salaries, you’re showing how much money is being wasted.

This approach is far more effective than what can come across as “Here’s a new tool I want to play with”—an anti-pattern that reinforces the stereotype of technical people just wanting to use new technologies.

3. Build Consensus with Nemawashi Conversations

I’ve found a Japanese concept called “nemawashi” (literally “turning the roots”) provides another effective approach to organizational change:

Before introducing an idea to a manager or the whole team, individually go to every person on the team first and get their thoughts. If most people respond positively, you can then approach the decision-maker saying, “Everyone on the team wants this—what do you think?”

This isn’t just about collecting checkmarks but genuinely gathering feedback. If you’re getting pushback from every single person, maybe it’s not as great an idea as you thought. Either way, you learn something from it.

4. Drive Viral Adoption Through Early Wins

Rather than forcing change on resistant teams, I prefer what I call “viral adoption”:

We try to work with teams that ask for our help instead of being pushed onto teams. People are way less resistant if you can show them you’re making their job easier. We work with one team who wants our help, make them really effective, and then other teams notice: “How come they’re releasing so many times a week? How do they have so few defects? How is their pipeline so fast?”

This success creates natural curiosity, leading other teams to either request similar help or study and adopt the successful team’s practices. Either way, I’m happy that things are improving.

5. Align Dev and Ops with Infrastructure as Code

When it comes to infrastructure as code specifically, I’ve noticed it’s becoming table stakes for many organizations, though implementation quality varies widely.

It’s hard to have actual continuous delivery without infrastructure as code. Without it, developers can’t define their own infrastructure and have to wait on another team to do it. By continuous, I mean teams should be able to deploy every 30 minutes if they want. If you have to wait one to three business days for the operations team to create your resources, that’s not continuous.

Resistance to infrastructure as code typically comes from two directions:

From developers: “I already have my plate full—now I have to learn cloud and deployment too?”
From operations: “That’s my job—I don’t want to lose it.”

I see this as a win-win opportunity for both sides. For operations teams, the job shifts from mundane tasks like “create a lambda for me” or “replace this code bundle” to more creative platform engineering work. For developers, the benefit is clear: no more waiting on operations to proceed with their work.

6. Invest in Platform Engineering for Reusable Components

Platform engineering has emerged as a solution to these challenges. Instead of every team reinventing solutions for common needs like logging, monitoring, or deployment pipelines, platform teams create standardized, reusable components.

It seems wasteful if every single team has to manage their own side of the Splunk instance or Dynatrace. These are solved problems that every team needs. A platform team can look across the organization, see what can be standardized, and remove those problems from individual teams.

This approach is particularly powerful with tools like Pulumi, which allows creating reusable component resources for common patterns: “It’s very common for teams to create a Lambda-backed API Gateway or a Lambda hooked up to SQS. These are super common things, so here’s a component resource for that so you don’t have to write it yourself.”

The key difference in mindset is that platform teams aren’t enforcing rules—they’re building tools that make developers’ lives easier. Instead of saying “You must do logging this way,” it’s “Here’s an endpoint you can use—you’re good to go.”

7. Avoid YAML Pitfalls: Embrace Programming Languages

One of my pain points is the limitations of configuration languages like YAML for complex infrastructure. I recently gave a presentation about a GitHub Actions workflow that grew to over 1,000 lines, calling shared actions that call other shared actions, making it nearly impossible to understand what’s happening.

I couldn’t use breakpoints or the normal libraries I would use. I’ve seen a 69,000-line YAML file for Prometheus and Kubernetes—that’s an auto-generated example, but even a thousand lines calling several other files is too much.

The fundamental issue is abstraction. Programming languages allow loops, conditionals, and functions to remove repetition and build larger structures. Configuration languages often lack these capabilities, leading to copy-pasting and unmanageable growth.

With declarative approaches, you end up using a lot of magic strings. It’s easy to forget one when you change values. The tooling is also an issue—I’m familiar with IDEs and libraries for programming languages, but the equivalent tools for YAML just aren’t as mature.

8. Choose Pulumi for Flexible, Code-First IaC

When comparing infrastructure-as-code options, I see three major players: AWS CDK, Terraform, and Pulumi. While AWS CDK offers similar capabilities to Pulumi for AWS resources, it relies on CloudFormation under the hood:

CloudFormation is just a black box—it’s proprietary. If something goes wrong, you have to hope someone’s already asked about it on GitHub. When deployments take 15-30 minutes, there’s not much you can do—it’s just how CloudFormation works.

Compared to Terraform, which uses HCL (HashiCorp Configuration Language), Pulumi offers the flexibility of actual programming languages:

There’s nothing wrong with declarative approaches in some cases, but at a certain point—when you have big systems and chunks of resources you want to share between teams—it becomes more cumbersome than helpful. That’s why Terraform is working on their own CDK now.

What sets Pulumi apart is its flexibility: Even if you have platform teams who aren’t developers and want to set standards, they can use YAML with Pulumi and then transform those component resources into other languages for dev teams to use. You get the best of all worlds.

Start Small, Think Big: Small Changes, Big Impact

Whether you’re introducing infrastructure as code or any significant technical change, my advice remains consistent: start small, focus on solving real problems, and let success spread naturally.

By understanding the human elements of change—the 10% rule, nemawashi, and viral adoption—you can transform resistance into enthusiasm. And by choosing tools like Pulumi that bridge the gap between developers and operations, you can create infrastructure that’s both powerful and maintainable.

I’m currently writing a blog series on Pulumi at daninacan.com. I also speak at conferences occasionally, so check out my speaking page if you’re interested.

Ready to escape configuration chaos? Start small, focus on solving real problems, and get started with Pulumi to leverage the full power of programming languages for infrastructure. Join our community Slack to connect with engineers making the same transformation.

Platform Engineering Buffet at SEITENBAU

Nico Thomas — Tue, 27 May 2025 00:00:00 +0000

This post is based on my video interview with Nico Thomas, a platform engineer at SEITENBAU. In this article, Nico shares how he and his team built a flexible, reusable platform to support 20+ diverse projects using Pulumi. Watch the video below or read on for Nico’s take on building an infrastructure buffet. - Adam Gordon Bell

Imagine your company isn’t Spotify with one product pipeline, but 20 independent government projects running on Ansible-provisioned VMs—some on Kubernetes, some delivered into other customer data centers, some operated by clients themselves. Each team is building its own CI/CD, secrets management, and integrations. You’re left with a million reinvented wheels.

That was the situation my team and I faced at SEITENBAU, a German software company specializing in custom development for both public and private sectors. Unlike the typical platform engineering stories—where teams build infrastructure for a single product with multiple microservices—we had a fundamentally different challenge: How do you build a platform that serves dozens of completely independent projects, each with their own technology choices, deployment targets, and operational models?

The answer? Stop trying to force everyone onto the same plate. Instead, build a buffet.

The Buffet Philosophy

Think of a traditional platform as a set menu—also known as prix fixe—where everyone gets the same courses, prepared the same way, in the same order. But what if your diners include vegans, carnivores, and people with various dietary restrictions? What if some want a quick snack while others need a seven-course meal?

That was exactly the situation we faced. We had:

Government projects that needed to run on-premises due to data sovereignty requirements.
Modern cloud-native applications leveraging Kubernetes and GitOps.
Legacy systems still operating on virtual machines managed with Ansible.
Projects we ran as managed services and others we simply delivered to customers.
Teams using various CI/CD tools, artifact repositories, and deployment strategies.

A one-size-fits-all platform would have been a disaster. Instead, my team built a platform offering a rich selection of pre-configured, production-ready components. Teams could mix and match according to their specific needs, creating their own unique infrastructure combinations.

The Challenge: Beyond Microservices

Most platform engineering resources assume you’re building infrastructure for a single product – Spotify’s Backstage, for example. But what happens when you’re dealing with over 20 completely independent projects, each with distinct requirements?

Each project is distinct, featuring its own:

Technology stack (Java predominates, but we support various frameworks and languages).
Infrastructure requirements (cloud, on-premises, or hybrid setups).
Security and compliance constraints.
Operational models (managed by us, the client, or jointly).
Release cadences and deployment strategies.

Initially, this diversity seemed chaotic, but we quickly noticed that underneath these variations, common patterns emerged. Every project consistently required source control, CI/CD pipelines, artifact storage, secrets management, and deployment targets. The critical realization was that we didn’t need to standardize what teams chose—we needed to standardize how they connected these building blocks.

That’s where Pulumi became essential. Its flexibility allowed us to construct an infrastructure buffet that genuinely accommodated the diverse appetites and needs of every team.

Building the Kitchen: Architecture with Pulumi

Behind every great buffet is a well-organized kitchen. For our infrastructure, that kitchen is powered by Pulumi and Python, orchestrating a complex web of infrastructure services, configurations, and deployments. Using Pulumi together with Python has proven extremely valuable—it makes our day-to-day tasks easier to maintain and understand.

The Multi-Stack Approach

Rather than creating a single monolithic infrastructure program, we adopted a modular approach with multiple Pulumi stacks. This decision was essential for managing complexity and empowering team autonomy.

Our architecture comprises several specialized Pulumi programs:

GitLab System: Manages installations and configurations of GitLab.
Project Configuration: Sets up team-specific GitLab groups, CI/CD runners, and agents.
Cluster Management: Provisions Kubernetes clusters complete with standard add-ons.
VM Infrastructure: Manages traditional VM-based deployments utilizing Ansible.
Platform Services: Configures shared services such as artifact repositories and identity providers.

Each program can maintain multiple stacks (dev, staging, prod), allowing us to manage various environments independently while leveraging shared infrastructure code.

From Ingredients to Ready-Made Dishes: Reusable Components

The real magic happens in our component library. Just as a buffet offers complete dishes rather than raw ingredients, we’ve built high-level components that encapsulate complex infrastructure patterns.

Example: The Kubernetes Storage Component

Consider our Longhorn storage component. Instead of requiring teams to understand Helm charts, storage classes, and snapshot configurations, they simply declare they need persistent storage.

The component handles all the complexity: installing Longhorn, configuring appropriate replication for test vs. production environments, setting up snapshot classes, and integrating with our internal certificate authority.

Two Years Later: The Buffet is Open

After two years of running this platform in production, we’ve learned what works and what we’d do differently.

Building a platform for diverse, independent projects requires a different mindset than traditional platform engineering. Instead of forcing standardization, we’ve embraced flexibility while maintaining consistency where it matters.

The buffet approach—powered by Pulumi’s flexibility and Python’s expressiveness—has allowed us to serve 20+ different projects efficiently while giving teams the autonomy they need. It’s not about having one perfect dish; it’s about having a kitchen flexible enough to satisfy everyone.

If you’re facing similar challenges with diverse project requirements, consider building a buffet instead of a prix fixe menu. Your teams will thank you for it.

Want to build your own infrastructure buffet? Get started with Pulumi and join our community Slack to connect with engineers solving similar challenges.

Pulumi Updates, Explained: AI-Powered Features in Pulumi CLI

Artur Laksberg — Thu, 22 May 2025 00:00:00 +0000

Note: This post discusses Pulumi Copilot, which Pulumi Neo has replaced. Learn about Neo →

We’re excited to announce the new AI capabilities for Pulumi CLI powered by Pulumi Copilot that translate complex infrastructure changes into clear, human-readable explanations and help resolve deployment errors with actionable guidance. Enable these preview features with the --copilot flag.

At Pulumi, we’re committed to helping you deploy infrastructure efficiently and with minimal friction. Anyone who has worked with cloud infrastructure knows the frustration of sifting through large previews with numerous changes and the difficulty of interpreting cryptic error messages from cloud provider APIs when deployments fail.

There are two key challenges we’ve identified:

Understanding Preview Changes: Reviewing raw update previews can be overwhelming, especially for complex deployments with many resources. It’s difficult to quickly grasp the full scope and impact of pending infrastructure changes.
Interpreting Error Messages: When deployments fail, cloud providers often return error messages that, while comprehensive, bury the core issue within extensive diagnostics, requiring specialized expertise to interpret and address.

Our latest CLI update introduces AI capabilities that tackle both issues. Let’s explore how these new features improve your infrastructure management workflow.

Update Explanation

To address the first challenge above, we’ve introduced a new “explain” menu item in the CLI. When running pulumi preview or pulumi up with the --copilot flag, you’ll see this option in the interactive menu:

In this screenshot, you can see the standard Pulumi update preview showing an AWS VPC with multiple subnets, route tables, and gateways that need to be updated. The interactive menu at the bottom shows the new “explain” option with a sparkle emoji, indicating the AI-powered feature. When selected, this tool analyzes and provides a clear summary of all changes in your pending infrastructure update:

In this example, the AI explanation immediately identifies that this is a “VPC Renaming Operation - Tag Updates Only” and explains that the update is simply changing tags across all components. It clearly states this is a “safe, non-disruptive change that only affects resource labels.”

This explanation serves as a valuable sanity check before deployment. It presents a plain-language summary of exactly what changes will occur, helping you verify that the planned modifications align with your intentions. This visibility is particularly valuable when managing complex infrastructure with many resources, as it helps identify unexpected changes or potential drift between your code and deployed resources. The system also proactively flags potential issues such as security vulnerabilities or destructive updates that might impact your production environment.

Diagnostics Summarization

For the second challenge, when infrastructure deployments fail, cloud providers often return error messages that are technically accurate but difficult to decipher without specialized knowledge. Consider the following scenario where a Go-based Docker image build fails with vendoring issues:

In this example, the standard Go build process failed with a cryptic error about inconsistent vendoring. While the raw output does contain the necessary information, it’s buried within extensive build logs. Our AI-powered Copilot diagnostics immediately identifies the problem and provides a clear, actionable solution: “Docker image update failed due to inconsistent vendoring. Sync vendor with ‘go mod vendor’.”

This clear explanation identifies root causes and provides actionable guidance, transforming dense technical output into concise explanations. It reduces time to resolution by pinpointing both the problem and the exact command needed to fix it, eliminating the need to search through documentation or guess.

Getting Started

The AI-powered features are currently in preview. You can enable them by adding the --copilot flag to your Pulumi CLI commands:

pulumi preview --copilot
pulumi up --copilot

These features require Pulumi CLI version v3.171.0 or greater and the Pulumi Cloud backend. Organization administrators must enable Pulumi Copilot by navigating to Settings > Access Management > Pulumi Copilot in the Pulumi Cloud console.

During this preview period, we’re focused on:

Refining explanations based on user feedback
Adding new capabilities like suggesting fixes for common errors
Improving performance to ensure minimal impact on command execution time

We will continue to monitor usage patterns and incorporate your feedback before enabling these features by default.

We’re excited to see how these AI-powered insights enhance your infrastructure deployment workflow! Please share your experiences with us:

Connect with us in the Pulumi Community Slack
Open an issue on GitHub
Learn more about Pulumi Copilot

Try this today, Get Started with Pulumi for free

Your input will directly influence how we evolve these features from preview to general availability.

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!

New in Pulumi IaC: Support for skipping a resource

Tom Harding — Wed, 14 May 2025 00:00:00 +0000

Managing large-scale infrastructure can be challenging, especially when you need to perform operations on specific subsets of your resources. Pulumi’s stack operations like pulumi up and pulumi destroy are powerful for deploying and tearing down environments, but sometimes you need more fine-grained control over which resources are affected.

Today, we’re excited to announce a highly requested feature that will save you time and reduce complexity in your workflows: the ability to exclude specific resources from stack operations using the new --exclude and --exclude-dependents flags.

These new flags complement the existing --target functionality, giving you powerful options whether you want to focus on a small subset of resources or exclude just a few from larger operations. No more workarounds or custom scripts to achieve selective deployments!

The challenge: partial operations on large stacks

When managing infrastructure at scale, you often want to operate on most—but not all—resources in your stack. For example:

Deploying all resources except a database that requires a maintenance window
Refreshing most resources while skipping those with known differences
Updating production infrastructure while leaving critical services untouched
Testing changes to most components while preserving test data in development

Pulumi already has the --target flag to specify which resources to include in an operation. This works well when you want to target a small number of resources, but becomes unwieldy when you want to operate on most of your stack while excluding only a few resources.

The solution: introducing `--exclude` and `--exclude-dependents`

Our new --exclude flag solves this problem by letting you specify which resources to omit from stack operations. When paired with --exclude-dependents, you can also exclude all child resources of the specified resources, making it easy to exclude entire branches of your resource tree.

These flags are now available for all major stack operations:

pulumi up --exclude <URN>::resource-to-skip
pulumi preview --exclude <URN>::resource-to-skip
pulumi refresh --exclude <URN>::resource-to-skip
pulumi destroy --exclude <URN>::resource-to-skip

Each of these commands can also use the --exclude-dependents flag to exclude child resources.

An example: selective deployment of blog content

Let’s imagine you’re managing a static blog website with Pulumi. As part of your deployment, you have multiple HTML pages you’d like to deploy:

...

for (const file in await glob('posts/**/*.html')) {
 new aws.s3.BucketObject(`post-${file}`, {
 source: new pulumi.asset.FileAsset(file),
 ...
 })
}

...

...

for (const file in await glob('posts/**/*.html')) {
 new aws.s3.BucketObject(`post-${file}`, {
 source: new pulumi.asset.FileAsset(file),
 ...
 })
}

...

...

for file in glob("posts/**/*.html"):
 aws.s3.BucketObject(file,
 source = pulumi.FileAsset(file),
 ....
 )

...

...

files, err := filepath.Glob("posts/**/*.html")
if err != nil { return err }

for _, file := range files {
 _, err := s3.NewBucketObject(ctx, file, &s3.BucketObjectArgs{
 Source: pulumi.FileAsset(file),
 ...
 })

 if err != nil { return err }
}

...

...

var files = Directory.GetFiles("posts", "*.html");

foreach (var file in files)
{
 var bucketObject = new BucketObjectv2(file, new BucketObjectv2Args
 {
 Source = new FileAsset(file),
 ...
 });
}

...

This works well, but what if we have a list of draft articles that we don’t want to include in the deployment? We can optimistically assume we’ve finished more articles than we’ve started, so using --target to specify every article, as well as supporting resources (CSS, JavaScript, ownership controls, et cetera), would quickly become unmanageable.

pulumi up --target <URN>::style.css --target <URN>::post-hello.html ...

With the --exclude flag, this becomes much more manageable:

pulumi up --exclude <URN>::post-draft-1.html --exclude <URN>::post-draft-2.html ...

With this command, everything not specified using an --exclude tag will be included in the up operation, and thus we can avoid the hassle of naming every resource that isn’t a draft.

Next step: a draft group

This is fine for a personal blog site, but can still become unmanageable when we’re dealing with multiple authors, each with multiple drafts. In this case, we might want to group our drafts under a common parent:

...

// A parent component for all drafts
const drafts = new pulumi.ComponentResource('ComponentResource', 'drafts')

for (const file in await glob('drafts/**/*.html')) {
 new aws.s3.BucketObject(`draft-${file}`, {
 source: new pulumi.asset.FileAsset(`drafts/${file}`),
 ...
 }, { parent: drafts })
}

...

...

// A parent component for all drafts
const drafts: pulumi.ComponentResource =
 new pulumi.ComponentResource('ComponentResource', 'drafts')

for (const file in await glob('drafts/**/*.html')) {
 new aws.s3.BucketObject(`draft-${file}`, {
 source: new pulumi.asset.FileAsset(`drafts/${file}`),
 ...
 }, { parent: drafts })
}

...

...

# A parent component for all drafts
drafts = pulumi.ComponentResource(t="ComponentResource", name="drafts")

for file_path in glob("posts/**/*.html"):
 aws.s3.BucketObject(file_path,
 source = pulumi.FileAsset(file_path),
 opts = pulumi.ResourceOptions(parent = drafts),
 ....
 )

...


drafts := &DraftGroupComponent{}
err = ctx.RegisterComponentResource("ComponentResource", "drafts", drafts)
if err != nil { return err }

...

files, err := filepath.Glob("posts/*.html")
if err != nil { return err }

for _, file := range files {
 _, err := s3.NewBucketObject(ctx, file, &s3.BucketObjectArgs{
 Key: pulumi.String(file),
 ...
}, pulumi.Parent(drafts))

 if err != nil { return err }
}

...


public class MyComponentResource : ComponentResource { ... }

...

var files = Directory.GetFiles("posts", "*.html");
var drafts = new MyComponentResource("drafts");

foreach (var file in files)
{
 var bucketObject = new BucketObjectv2(file, new BucketObjectv2Args
 {
 Source = new FileAsset(file),
 ...
 }, new CustomResourceOptions
 {
 Parent = drafts
 });
}

...

In this setup, we now have a parent resource for all drafts. Using --exclude-dependents, we can now exclude everything under this parent resource without having to enumerate all of them individually:

pulumi up --exclude <URN>::ComponentResource::drafts --exclude-dependents

This command will exclude all drafts from the up operation, regardless of how many we have or how they’re named. We now have a nice, scalable way to manage our drafts across production and development environments!

Next steps

With these flags now available in Pulumi CLI v3.158.0., expect to see them introduced in the automation APIs and GitHub action soon. Thanks for reading, and feel free to share any feedback on GitHub, X, or our Community Slack.

Go from Cloud to Code in Minutes with Visual Import

Pulumi Insights Team — Thu, 08 May 2025 14:41:53 -0500

Note: This post discusses Pulumi Copilot, which Pulumi Neo has replaced. Learn about Neo →

Pulumi is excited to announce the release of Visual Import, a new feature that transforms the way platform teams onboard existing cloud infrastructure into Pulumi. With Visual Import, you can discover unmanaged cloud resources across your organization, organize them into logical units, and instantly generate high-quality Pulumi code—with AI enhancements built in.

Visual Import is now available for all Team, Enterprise and Business Critical customers with Pulumi Insights enabled.

Modern Infrastructure, Codified Faster

One of the biggest challenges platform teams face when adopting infrastructure as code is migrating existing cloud deployments. Legacy scripts, manual configurations, and scattered resource ownership all slow down progress. Visual Import solves this by making the journey from cloud to code seamless and intuitive.

Instead of manually digging through consoles and writing boilerplate code by hand, Visual Import enables teams to:

Discover all cloud resources—across any number of accounts—via Pulumi Insights.
Select and group resources into meaningful stacks, services, or projects.
Generate production-ready Pulumi code in your language of choice.
Enhance that code using Pulumi Copilot, which refines formatting, naming, references, and documentation.
Integrate with your development workflows by downloading, editing, and importing Pulumi code into your existing repositories.

Whether you’re modernizing infrastructure, unifying multi-account environments, or enabling developers to adopt infrastructure as code more easily, Visual Import gives you a fast, repeatable onramp to scalable, consistent cloud management.

How It Works

Visual Import is a guided three-step workflow within the Pulumi Cloud Console:

Select Resources: Use powerful filters and grouping tools to find the resources you want to codify. Whether you’re capturing a full service or just a few related components, Visual Import gives you visibility and precision.
Review References: Automatically discover and select dependent resources—ensuring your code captures the right context and connectivity between infrastructure elements.
Generate Code: Choose your preferred language and preview or download fully-formed Pulumi code. You can refine it manually or invoke Pulumi Copilot to improve naming, structure, and comments.

Throughout the workflow, you maintain full control. Select what you need, tweak it as required, and integrate on your terms. You can find full documentation and usage details in the Visual Import docs.

Key Benefits

Accelerated Migration

Visual Import dramatically shortens the time it takes to transition existing cloud infrastructure into a managed, version-controlled state. What previously required weeks of manual discovery, scripting, and trial-and-error can now be accomplished in a matter of hours.

Whether you’re consolidating legacy environments, auditing infrastructure before a cloud cost review, or preparing for a compliance milestone, Visual Import automates much of the busywork—so your team can focus on what matters.

Increased Developer Productivity

Manually transitioning existing infrastructure to code often pulls developers away from their primary focus—building and improving services. By automating code generation and applying intelligent AI enhancements, Visual Import lets teams spend less time writing boilerplate code and fighting resource drift, and more time shipping meaningful changes.

Pulumi Copilot adds a layer of polish that typically requires hands-on review and iteration, saving your team valuable time while helping new contributors write clear, consistent infrastructure code from the start.

Consistent, Reliable Infrastructure

Unifying your cloud environments under a single IaC framework brings consistency, accountability, and repeatability to operations. Pulumi’s typed IaC model makes configurations explicit and auditable, while policies and CI/CD integrations enforce best practices from the start.

By codifying your infrastructure, you reduce the risk of configuration drift, simplify onboarding, and ensure reproducibility across staging and production.

From Insights to IaC—Seamlessly

Visual Import builds on Pulumi Insights, providing a natural path from discovery to codification. If you’re already using Insights to monitor and visualize your infrastructure, you can now convert those resources into managed, versioned code in just a few clicks.

And with built-in support for dependency analysis and cross-account visibility, you can finally treat your entire infrastructure portfolio as a single, coherent system—even if it wasn’t built that way.

Leverage the Full Power of Pulumi Cloud

Once resources are in code, you can take full advantage of Pulumi Cloud’s full suite of features: define and enforce policies with CrossGuard, gain visibility into your entire infrastructure through Pulumi Insights, manage state with ESC’s secrets management, and automate workflows through Pulumi Deployments. Together, these features turn your infrastructure into a governed, observable, and continuously deployable system built for modern cloud operations.

Try It Today

Visual Import is now available in the Pulumi Cloud Console for Team, Enterprise and Business Critical users. If you’re ready to modernize your infrastructure and empower your teams with a fast path to Infrastructure as Code, there’s no better place to start.

How We Used Pulumi to Safely Migrate Oso's Global Infrastructure

Shaun Verch — Mon, 05 May 2025 00:00:00 +0000

Infrastructure as Code (IaC) tools such as Pulumi can provide enormous amounts of leverage, but they must be used correctly to also provide safety. One of our main jobs as infrastructure engineers is to not break things, so leverage without safety is useless. If something is safe, we can change things easily without even thinking about it. If it isn’t, we’ll be up until 2 a.m. fixing what we broke.

At Oso, we recently had to do a large infrastructure migration and learned three key principles that make a huge difference in using Pulumi for safe migrations. First, understand how it’s even possible to safely change your infrastructure independently of Pulumi. Second, write reusable and predictable Pulumi code. Finally, refactor your Pulumi code to your new version using zero-diff refactors.

Osoʼs Migration

Oso provides Authorization as a Service, so every application decision must first query Oso. This means that if Oso goes down, our customers will also go down. We can’t afford a moment of downtime.

However, we’re also growing quickly, and one of the side effects of growth is that architectural decisions that worked for us in the past quickly reach their expiration date. One example of this is when we hit a scaling limit and needed to quickly migrate from Amazon ECS Fargate to ECS on our own self-managed EC2 instances.

We can’t overstate the Pandora’s box of complexity this opened up for us. From the lifecycle of our data to our deployment orchestration, this touched nearly every part of our stack. On top of this, because performance and data locality are critical for us, we are deployed globally in 12 different regions. We need to be extremely careful to do this correctly.

How the Migration Actually Worked

The most important thing to realize when using an infrastructure tool like Pulumi is that ultimately you’re dealing with real resources. It doesn’t matter how cleverly you refactor your Pulumi code; if something gets deleted that isn’t supposed to be deleted, or if at any point a critical component is missing, there will be an outage.

At Oso, we were already using a Route 53 Traffic Policy to do latency-based per-region routing, so Route 53 was a convenient tool for us in this migration. The plan was to create an entirely new Oso infrastructure and include it in our traffic policy, but send 0% of our traffic to it. Then, we could run tests ourselves directly against the new infrastructure and gradually ramp up traffic until we were fully migrated.

That is the first big lesson we took away from this. If we didn’t have a point in our infrastructure where we could easily reroute customer traffic from one place to the other, this transition would have been impossible without downtime.

Writing Reusable Pulumi Code

The holy grail of infrastructure development is to achieve what we already have in application development: code reuse. Besides the benefit of reducing the burden of maintaining more code, it also reduces risk because we can concentrate our testing in one place and benefit from using code that has already been proven.

In Osoʼs case, because our migration involved creating a copy of our entire infrastructure with the new changes, code reuse was vital. Even the smallest reusable component meant fewer new bugs and less time fixing bugs we had already fixed in the old infrastructure.

In Pulumi, you can use the import and function system of the underlying programming language, so that part of managing libraries is not an issue. The real challenge lies in how to actually write the business logic of libraries in Pulumi because writing Pulumi code is not like writing normal code.

Take a look at this example of creating an ECS service:


let service = new aws.ecs.Serice("api",{ });

This line of code might seem trivial, but a lot is happening here, and it’s important to understand Pulumi’s programming model on a deeper level to know how to work with it properly.

The first thing to note is the first argument: api. This is the logical resource name in Pulumi. The subsequent arguments are more about how to actually create the resource, and we wonʼt talk about that here. This logical resource is how Pulumi identifies this resource in the internal state.

The internal state is the core of the Pulumi engine. It maps the “logical resource name" we provide to the actual resource that Pulumi either created or plans to create. The code example above, at some point deep inside the Pulumi engine, turns into something that roughly looks like this:

{
 "aws:ecs:Service": {
 "api": {...},
 ...
 },
 ...
}

This is the key to understanding why writing Pulumi code is not like writing normal code. There is one “state namespace” per Pulumi execution, which effectively means that there is one global object that we are adding resources to. So the new aws.ecs.Service function call wasn’t just creating a service object that we can pass around; it was registering the service with the global list of resources we plan to deploy.

After we understand that calls to the Pulumi library have side effects on this global state, we can start to write better Pulumi libraries. For example, say we have this function call:

deployWebStack("app",true,false,"enabled");

Do you know which resources this will create? Is it safe to call deployWebStack again with the same arguments? What would happen if we deleted this line of code? These are all the familiar perils of global state, and something we must proactively contend with to write a good Pulumi library.

Here are some rules that we recommend:

DO use Pulumi Component Resources in libraries that create resources.
- This encourages a more declarative object-based approach to resources, which fits better with Pulumi’s model and also causes these objects to show up in the Pulumi output.
Do NOT conditionally create resources inside library functions.
- If the function is called, all the resources should be created, and if it is not, the resources should not be created. Conditionals should be at the top level, because that’s where you are deciding what is deployed in a particular region or component.
Do NOT check the current infrastructure state inside library functions.
- This should be passed in as arguments; otherwise, the library function will have non-deterministic behavior.
Do NOT attempt to implement idempotent resource creation functions.
- See the previous rule. The only way to implement a function that creates a resource only if it hasn’t been created yet is to check if it has been created, leading to non-determinism.
DO write functional code as inputs to resources.
- You can still write normal code in some cases, as long as it doesn’t call into Pulumi. For example, the code that generates the list of environment variables for an app can be a normal function.
DO have a strategy for resource naming.
- Because any function might register new resources, and because you may even have naming conflicts on the cloud provider side, having a coherent strategy for naming resources is helpful. We don’t have anything prescriptive here, because it’s really a matter of preferences and specific situations.
DO favor assigning resources to named objects and variables over getter functions.
- Rather than implementing a function or some kind of “getter” to refer to another resource, save that resource object in a variable at some scope where it can be referenced by the other resources that need it. This can even be in the global scope to match the reality that all the resources end up in one resource namespace in the end.

There’s a lot of advice here, but it really all comes down to keeping in mind what Pulumi is actually doing with your code and remembering that calls into the Pulumi library are actually registering resources in the global state.

Infrastructure Snapshot Testing for Zero Diff Refactors

Now that we know what we want to change in our infrastructure, and we know how to write our Pulumi code in a reusable way, we’re faced with a familiar software engineering challenge: How can we safely refactor our existing code to get to where we want to be? To answer this question, we can step back from the Pulumi specifics for a moment and think about refactoring in general.

One method that is amazing for refactoring code is Snapshot Testing. With Snapshot Testing, you run the legacy code that you want to change, save the output, and create a unit test around that. Then, when you make a code change, you can detect if your code changes result in any unintended changes in behavior.

We can imitate this with Pulumi by taking advantage of the fact that we can see a preview of the changes Pulumi will make before we deploy them. While we don’t have direct access to Pulumi’s internal data model in the code itself to make this “snapshot,” the preview can give us this comparison. If we make changes to our infrastructure, as long as pulumi preview shows no changes, we are 100% sure that the refactor we made is safe and won’t cause any issues. Because of this, we at Oso internally call this method a “zero diff refactor.”

This is a relatively simple concept, but it is necessary to make this migration possible. In our original infrastructure, most of our resources were deployed in one monolithic Pulumi project, and resources were created at the top level rather than in libraries. The 12-region deployment also made running Pulumi on this project very slow, and we wanted a clean separation between the old and new infrastructure. Using snapshot testing to refactor allowed us to build and reuse our in-house infrastructure libraries with 100% confidence and let us focus on the parts that held the real risk.

Conclusion

This migration did not go smoothly. We constantly found problems and unexpected assumptions that our code was making about the underlying infrastructure.

But no one outside Oso noticed. We had a clear migration plan, factored out common Pulumi code, and used zero-diff refactors. Putting this all together meant we could benefit from the leverage that Pulumi has the potential to provide. This allowed us to make major changes with confidence that they wouldn’t break our system.

In the early days of Oso, people were often surprised by how much we were able to accomplish with such a small core team of engineers. Part of the secret to this is using the tools we have available to gain maximum leverage, but this isn’t the entire story. Knowing how to use them safely allows us to actually benefit from that leverage in practice.

If you’re interested in exploring Pulumi further, here are several ways to get involved:

Discover how Pulumi Crosswalk for AWS simplifies “day one” tasks in our AWS guide
Register for one of our upcoming workshops
But most importantly, try Pulumi today!

AI-Assisted Infrastructure as Code with Pulumi's Model Context Protocol Server

Mikhail Shilkov — Tue, 08 Apr 2025 00:00:00 +0000

Note: This post discusses Pulumi Copilot, which Pulumi Neo has replaced. Learn about Neo →

Infrastructure as Code (IaC) has revolutionized how we manage cloud resources, but navigating complex cloud provider APIs, writing boilerplate code, and iterating through deployment cycles can still be time-consuming. Pulumi offers a fantastic developer experience using familiar programming languages. But what if we could make it even faster and more intuitive by integrating powerful AI assistants directly into the development loop?

This is where the Pulumi Model Context Protocol (MCP) Server integration shines. MCP is a specification that allows language models (like the AI in your coding assistant) to interact with external tools and data sources in a structured way. By connecting AI-powered code assistants with Pulumi’s CLI and registry via MCP, we can bring real-time resource information and infrastructure management directly into the development environment, dramatically reducing friction and accelerating workflows.

Several AI coding assistants like GitHub Copilot, Anthropic’s Claude Code, Windsurf and others are rapidly evolving; this post will use Cursor (an AI-first code editor) to demonstrate a real-world example of this synergy in action.

Setting up the Pulumi MCP Integration in Cursor

Before diving in, you typically need to configure your AI assistant to communicate with the Pulumi MCP server. For Cursor, you can do so by clicking the following button:

The assistant can now leverage Pulumi tools seamlessly. These tools are specific actions enabled by the MCP server—like searching the Pulumi Registry or running a pulumi command—allowing the assistant to gather information or interact with your Pulumi project.

For detailed setup instructions for Cursor, Claude Code, Windsurf, Claude Desktop, and other AI assistants, see the Pulumi MCP Server documentation.

The Goal: Provisioning an AKS Cluster

Our objective for this walkthrough is to provision a temporary Azure Kubernetes Service (AKS) cluster for a short experiment using Pulumi and TypeScript. We need the cluster created with minimal fuss and its kubeconfig exported for access.

The Traditional Approach

The conventional method for this task involves significant context switching: searching Azure and Pulumi documentation in a browser, writing code in an editor, running commands (pulumi preview, pulumi up) in a terminal, and manually correlating information between these different environments. This process can be slow, requires deep knowledge recall (or constant lookups), and is prone to errors during the manual translation from documentation to code.

The AI Assistant + Pulumi MCP Approach

Let’s walk through how the same task unfolds much more efficiently using an AI assistant integrated with Pulumi MCP.

Understanding the AI Assistant + Tool Interaction

Before detailing the steps, it’s helpful to understand the user interface flow when the AI assistant uses integrated tools like those provided by the Pulumi MCP integration. Typically:

The developer provides a prompt or instruction in the chat interface within their editor.
The AI assistant analyzes the request and determines that it needs specific information (like resource properties) or needs to perform an action (like running pulumi preview).
The assistant indicates it will use a specific tool (e.g., pulumi_registry_listResources, pulumi_cli_preview). This often appears as a distinct UI element in the chat, showing the tool name and parameters being used.
The tool executes via the MCP server, interacting with the Pulumi CLI or registry as needed.
The output or result from the tool (e.g., registry listings, preview results, deployment errors) is displayed directly in the chat interface.
The AI assistant processes this output and uses it to continue the task – either by generating code, providing an answer, or deciding on the next step (like suggesting a fix for an error).

This tight loop keeps the developer focused within their editor environment, minimizing disruptions.

Step-by-Step Walkthrough

Here’s how the AKS provisioning task played out:

The Request

The developer starts with a natural language request to the AI assistant within the editor:

“I have an empty Pulumi project with TypeScript. Please edit the program to provision an AKS cluster for me. It’s a temporary AKS cluster that I need for a short experiment, so I don’t need any particular configuration of it. Just export its kubeconfig when you are done. Please use the tools to lookup resource information and to run pulumi preview to make sure your code works. When done, run pulumi up for me.”

AI-Powered Resource Discovery

Instead of the developer manually searching docs, the AI assistant leverages the MCP integration.

The AI assistant first queries the Pulumi Registry via MCP to list resources within the Azure Native provider’s containerservice module (using the pulumi_registry_listResources tool). This immediately identified ManagedCluster as the relevant resource.
The AI assistant then requests detailed information specifically for ManagedCluster (using pulumi_registry_getResource), directly retrieving its required properties, descriptions, and structure without leaving the editor.

AI Code Generation & Editing

Using the information retrieved from the Pulumi Registry, the assistant generated the necessary TypeScript code. It defined the ManagedCluster resource with a basic configuration and used its code editing capabilities to insert the code directly into the developer’s index.ts file.

Integrated Validation

Before attempting a potentially time-consuming deployment, the assistant ran pulumi preview using the integrated CLI tool (pulumi_cli_preview). The preview output appeared directly in the chat.

The preview succeeded, showing the resources that would be created. The assistant then proceeded to run pulumi up using the integrated CLI tool (pulumi_cli_up). However, the deployment flagged an error: an incorrect attempt to interpolate a Pulumi Output<string> directly into a resource property.

AI-Assisted Debugging & Iteration

The assistant analyzed the error message from the tool:

It identified the incorrect string interpolation and proposed a fix (using pulumi.interpolate), applying it via the editing tool.
Self-correction: The first fix inadvertently introduced a circular dependency (caught by linters integrated into the editor and surfaced to the assistant). The assistant recognized this and further refined the code by removing the problematic property, correctly relying on Azure’s default behavior.
Another attempt to deploy using pulumi up failed, this time surfacing an Azure API error: the provided SSH key format was invalid.

Collaborative Problem Solving & Tooling

The developer, seeing the SSH key error, suggested using the Pulumi TLS package to generate a valid key dynamically.

The assistant used the integrated terminal tool to execute npm install @pulumi/tls.
It then edited the index.ts file again, incorporating the tls.PrivateKey resource and correctly using its publicKeyOpenssh output for the ManagedCluster’s Linux profile.

Successful Deployment

The subsequent pulumi preview showed the correct plan (including the new TLS key resource). The assistant then executed pulumi up, which completed successfully. The success message and resource summary appeared in the chat.

Accessing Outputs

Finally, retrieving the kubeconfig was trivial. The assistant used the stack output tool (pulumi_cli_stack_output kubeconfig) to fetch and display the configuration directly.

Why This Changes the Game

Integrating AI assistants with the Pulumi Model Context Protocol offers tangible benefits:

Reduced Context Switching: The entire workflow – discovery, coding, validation, deployment, debugging, output retrieval – happens primarily inside the editor. No more juggling browser tabs and terminal windows.
Accelerated Discovery: MCP integration provides immediate, context-aware access to Pulumi resource schemas and documentation snippets.
Faster Coding: AI generates boilerplate and resource definitions quickly based on registry data and natural language requests.
Tighter Feedback Loop: pulumi preview and pulumi up results are instantly available within the coding environment, enabling rapid iteration.
Intelligent Assistance & Collaboration: The AI assists with debugging complex errors, incorporates developer suggestions, and leverages integrated tooling effectively.

Conclusion

The synergy between AI coding assistants and the Pulumi Model Context Protocol (MCP) integration creates a remarkably efficient environment for Infrastructure as Code development. By bringing cloud resource knowledge, code generation, and the Pulumi CLI workflow directly into the editor, developers can build, deploy, and iterate on their infrastructure faster and with significantly less friction.

Whether you use Cursor, Copilot, Claude Code, Windsurf, or another emerging AI tool, integrating it with the Pulumi MCP server offers a glimpse into the future of streamlined, intelligent IaC development, ultimately boosting productivity and improving the overall developer experience.

Improved refresh and destroy experience for Pulumi IaC

Will Jones — Wed, 02 Apr 2025 00:00:00 +0000

Pulumi enables teams to manage their infrastructure using the programming languages and tools they are already familiar with, supporting use cases such as complex authentication workflows, dynamically configured resources, and more.

In this post we’re excited to announce an improvement to the pulumi refresh and pulumi destroy commands: the --run-program flag! This new feature makes Pulumi even more powerful for teams with complex infrastructure workflows.

This enhancement is particularly valuable for teams working with short-lived credentials, dynamic resources, or any workflow where your code needs to run to establish the right context. Whether you’re using OIDC-based authentication, dynamically fetching credentials from a secrets manager, or working with dynamic providers, the --run-program flag ensures your infrastructure operations have the context they need to succeed.

The pulumi refresh and pulumi destroy commands sit alongside pulumi up and support refreshing and destroying resources in your stack. While refresh and destroy take into account updated configuration (such as that specified in your Pulumi.<stack>.yaml), they have historically not taken into account changes in your code. For stacks which depend on code to update credentials for a provider, or to determine which resources to create, this can break or hamper the use of refresh and destroy. Well, no more! As of the latest release of Pulumi (v3.160.0), the pulumi refresh and pulumi destroy commands now support the --run-program flag, which allows you to run your program before refreshing or destroying your stack.

We plan to make running your program the default behavior for refresh and destroy operations eventually. We’re introducing this as an opt-in flag first to ensure a smooth transition. For more details and to provide feedback, please see our RFC on making program execution the default behavior.

Let’s see it in action

We are writing a Pulumi program to deploy infrastructure to AWS. Our organization’s platform team provides us with a library that we can use to dynamically fetch appropriate AWS credentials for our stack. We use this to retrieve some values and set up an explicit AWS provider (1, 2, 3):

import * as orgConfig from "@org/config";
import * as aws from "@pulumi/aws";

export = async () => {
 const awsConfig = await orgConfig.getAWSConfig({
 project: pulumi.getProject(),
 stack: pulumi.getStack(),
 });

 const provider = new aws.Provider("provider", {
 accessKey: awsConfig.accessKey,
 secretKey: awsConfig.secretKey,
 token: awsConfig.securityToken,
 region: awsConfig.region,
 });

 const bucket = new aws.s3.Bucket("bucket", { ... }, { provider });
};

import * as orgConfig from "@org/config";
import * as aws from "@pulumi/aws";

export = async () => {
 const awsConfig = await orgConfig.getAWSConfig({
 project: pulumi.getProject(),
 stack: pulumi.getStack(),
 });

 const provider = new aws.Provider("provider", {
 accessKey: awsConfig.accessKey,
 secretKey: awsConfig.secretKey,
 token: awsConfig.securityToken,
 region: awsConfig.region,
 });

 const bucket = new aws.s3.Bucket("bucket", { ... }, { provider });
};

import org_config
import pulumi
import pulumi_aws as aws

aws_config = org_config.get_aws_config(
 project=pulumi.get_project(),
 stack=pulumi.get_stack(),
)

provider = aws.Provider("provider",
 access_key=aws_config.access_key,
 secret_key=aws_config.secret_key,
 token=aws_config.security_token,
 region=aws_config.region,
)

bucket = aws.s3.Bucket("bucket", ... , opts=pulumi.ResourceOptions(provider=provider))

package main

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

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 awsConfig, err := config.GetAWSConfig(ctx)
 if err != nil {
 return err
 }

 provider, err := aws.NewProvider(ctx, "provider", &s3.ProviderArgs{
 AccessKey: awsConfig.AccessKey,
 SecretKey: awsConfig.SecretKey,
 Token: awsConfig.SecurityToken,
 Region: awsConfig.Region,
 })
 if err != nil {
 return err
 }

 bucket, err := s3.NewBucket(ctx, "bucket", &s3.BucketArgs{ ... }, pulumi.Provider(provider))
 if err != nil {
 return err
 }

 return nil
 })
}

package app;

import com.org.AwsConfig;
import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.aws.Provider;
import com.pulumi.aws.ProviderArgs;
import com.pulumi.aws.s3.Bucket;
import com.pulumi.aws.s3.BucketArgs;

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

 public static void stack(Context ctx) {
 final var awsConfig = AwsConfig.getAWSConfig(ctx.projectName(), ctx.stackName());

 final var provider = new Provider("provider", ProviderArgs.builder()
 .accessKey(awsConfig.accessKey())
 .secretKey(awsConfig.secretKey())
 .token(awsConfig.securityToken())
 .region(awsConfig.region())
 .build());

 final var bucket = new Bucket("bucket", BucketArgs.builder().....build(),
 pulumi.CustomResourceOptions.builder().provider(provider).build());
 }
}

using System.Threading.Tasks;

using Org.Config;
using Pulumi;

class Program
{
 static Task<int> Main() => Deployment.RunAsync<MyStack>();
}

class MyStack : Stack
{
 public MyStack()
 {
 var awsConfig = GetAwsConfig(
 project: Deployment.Instance.ProjectName,
 stack: Deployment.Instance.StackName
 );

 var provider = new Pulumi.Aws.Provider("provider", new Pulumi.Aws.ProviderArgs
 {
 AccessKey = awsConfig.AccessKey,
 SecretKey = awsConfig.SecretKey,
 Token = awsConfig.SecurityToken,
 Region = awsConfig.Region,
 });

 var bucket = new Pulumi.Aws.S3.Bucket("bucket", new Pulumi.Aws.S3.BucketArgs {
 ...
 }, new Pulumi.ResourceOptions {
 Provider = provider
 });
 }
}

We run pulumi up and everything works as we expect – our program grabs the appropriate tokens and sets up our S3 bucket.

A few days, weeks, months, or even years later, we find that some tweaks have been made to the bucket in the AWS console. Before we update and re-run our program, we want to refresh Pulumi’s state so that it picks up the current properties of the bucket. We run pulumi refresh and, after waiting a while… it fails! What has gone wrong?

The issue is that our program needs to run to fetch the latest credentials using our platform team’s library. However, pulumi refresh doesn’t run our program by default. To fix this, we can use the new --run-program flag:

pulumi refresh --run-program

This time, Pulumi will run our program before refreshing the state of our stack. As a result, our program will fetch the latest credentials using the library provided by our platform team, and everything will work as expected! If in a few months we need to clean up our stack, pulumi destroy also accepts the new option:

pulumi destroy --run-program

What’s next?

Running the program for all Pulumi operations paves the way for several other highly-requested features. Top of our list is lifecycle hooks – the ability to run arbitrary program code at various points in the lifecycle of a Pulumi resource.

As mentioned earlier, we plan to make the behavior of --run-program the default in a future release. This means that Pulumi will automatically run your program before refresh and destroy operations, without requiring the flag. For more details and to provide feedback, please see our RFC on making program execution the default behavior for refresh and destroy.

Share any issues with your experience with us on GitHub, X, or our Community Slack.

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:

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.

Why Choose Pulumi Cloud Over DIY Backends?

Aaron Kao — Wed, 19 Mar 2025 09:00:00 -0700

Note: This post discusses Pulumi Copilot, which Pulumi Neo has replaced. Learn about Neo →

Pulumi Cloud empowers engineers to automate, secure, and manage modern infrastructure platforms.

Many companies are building internal developer platforms or modern infrastructure platforms to provide developer self-service while maintaining security and compliance. Companies adopt Pulumi IaC so they can apply software engineering practices to their infrastructure scaling problems and because it is fully open source with a strong community and public roadmap.

At Pulumi, we’re committed to open source—always have been; always will be. Pulumi IaC is entirely open source (Apache 2.0 license), meaning you can adopt and extend it however you like. If you’re new to Pulumi, the open source edition is an excellent way to start modernizing your infrastructure. But as your organization grows and the complexity of your environment increases, you may find yourself devoting significant time to rolling your own enterprise IaC backend features.

That’s why we built Pulumi Cloud—to help you avoid building and maintaining these capabilities from scratch while ensuring you can automate, secure, and manage your infrastructure at scale. Pulumi Cloud provides enterprise capabilities that make it easier to build modern infrastructure platforms. Companies receive increasing value from Pulumi Cloud as their organization and their infrastructure platforms grow in size and complexity.

As companies expand or platform engineering mandates become more expansive, challenges arise around collaboration, security, governance, and scaling. Some questions that need answering include:

How do teams collaborate?
How do you securely manage infrastructure state?
How do you enable self-service infrastructure?
How do you adhere to IT security standards?
How do you enforce governance policies?
How do you protect sensitive data?
How do you enforce least privileged access across the organization?
How do you maintain uptime or get support for your architecture?
How do you manage the cost and complexity of multi-cloud environments?

If some of these questions apply to you or your team, learn more about Pulumi Cloud below to understand when it makes sense to transition to a paid Pulumi offering.

What drives the most value in Pulumi Cloud?

The most frequent business values that our existing customers experience with Pulumi Cloud relate to speed, scale, security, and savings.

Speed

There are speed benefits that customers typically experience across three areas: the infrastructure platform, developer productivity, and operations. Pulumi Cloud simplifies building and running complex infrastructure automation workflows through the Automation API. It also makes it easy to componentize best practices that can be easily shared and distributed through a centralized repository.

Pulumi Cloud streamlines the software delivery pipeline with Pulumi Deployments and a wide range of 3rd party CI/CD integrations.

Pulumi Cloud provides Pulumi Insights, offering search, analytics, and AI-driven insights over your infrastructure. With Insights, you can instantly search for critical information - such as finding MySQL databases on end-of-life versions across all your cloud assets, reducing the operational time it takes to find needles in haystacks.

Scale

Part of building an infrastructure platform is so your organization can scale and make it easy to onboard new developers. Pulumi Cloud integrates seamlessly with various identity providers like Azure ActiveDirectory, Okta, G Suite, or any SAML/SSO provider, offering deep support for role-based access control (RBAC) and SCIM for automatic synchronization and revocation of access based on identity provider groups. Audit logs keep track of developer activity within an organization, recording what actions were taken, when, and by whom.

Pulumi Cloud also makes it easy to build developer portals for developer self-service. Organization Templates can provide a centralized repository for cloud components, best practices and configurations. The New Project Wizard also provides a gallery interface to pick a template and easily walk through configuration and deployment of the infrastructure.

Security

Another reason your organization is investing in an infrastructure platform is so that security and compliance can be automated as infrastructure is self-serviced. Your platform must prevent infrastructure deployments that violate security, reliability, cost, or compliance policies. Pulumi Cloud, through Pulumi CrossGuard, provides out-of-the-box support for common security and compliance policies, ensuring PCIDSS, ISO27001, SOC2, and CIS compliance for cloud applications and infrastructure.

For applications being built across the organization, securing sensitive information like database passwords, cloud credentials, and API keys is paramount. Secrets can inadvertently end up in insecurely stored state files, leading to potential breaches. Pulumi Cloud, however, encrypts all data in transit and at rest, utilizing hardware security module (HSM) based encryption. Read the Pulumi Cloud Security Whitepaper for more information.

Pulumi Cloud further enhances security with Pulumi ESC, a centralized secrets management and orchestration service. This service pulls and syncs secrets from various stores like HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, and 1Password, making it easy to adopt dynamic, short-lived secrets on demand. Secrets can be accessed via CLI, API, Kubernetes operator, the Pulumi Cloud UI, and in-code with TypeScript/JavaScript, Python, and Go SDKs. Pulumi ESC leverages the same identity, RBAC, Teams, SAML/SCIM, OIDC, and scoped access tokens used by Pulumi IaC, ensuring that secrets management complies with enterprise security policies.

Savings

Building a platform and managing cloud infrastructure demands considerable time and energy. As discussed above, Pulumi Insights X-Rays your entire cloud footprint, so you can observe, plan, and drive changes across your infrastructure. With this total visibility, Pulumi Insights helps you reduce waste by showing you usage information and identifying potentially stale infrastructure, which can lead to substantial cost savings.

You can also have a conversation with Pulumi Copilot about your infrastructure in natural language and get answers to operational questions that would take hours to piece together from other sources.

Why not build your own enterprise features on top of Pulumi IaC open source?

Build vs buy is a question of opportunity cost. Should you and your team build and operate your own enterprise backend service that engineers at Pulumi have already built to handle the needs and scale of the world’s biggest companies? Or is their time better spent focused on building a modern infrastructure platform that will increase development velocity across the company and drive business growth?

Maintenance costs

When you build and operate your own enterprise backend, you’ll need to dedicate one full-time engineer for every team of ten - that’s nearly 10% of your engineering expense. Running a backend requires maintenance, updates, and troubleshooting. Outages and incidents can lead to significant financial losses. Pulumi Cloud, as a fully managed service, frees up your team’s time from the operational and maintenance burdens of managing an IaC backend.

Operational reliability and availability

One of the primary functions of the enterprise backend is managing state. State management involves managing concurrency controls, preventing state corruption, ensuring backup and recovery, maintaining high availability of the state service, and providing consistent visibility across all managed resources; this is easy to get wrong. Manual human intervention is frequently required to recover and repair state files, a process that is time-consuming, can create or prolong outages, and carries significant risk.

Security and compliance

Building your own enterprise backend also requires you to design and manage the service to adhere to numerous IT security standards, including SOC 1/SSAE 16/ISAE 3402, SOC 2, SOC 3, FISMA, FedRAMP, DOD SRG Levels 2 and 4, PCI DSS Level 1, EU Model Clauses, ISO 9001 / ISO 27001 / ISO 27017 / ISO 27018, ITAR, IRAP, FIPS 140-2, MLPS Level 3, and MTCS. This involves a manual assessment and validation process for each standard, which can be time-consuming and complex.

Customer support

You will also be giving up 12x5 or 24x7 customer support, which helps ensure your organization receives immediate assistance with any architectural, cloud-related, or Pulumi best-practices issues. Pulumi also has an experienced group of Solutions Architects and Customer Success Architects that have experience scaling infrastructure as code and building modern infrastructure platforms.

Conclusion

Pulumi Cloud is an enterprise-ready solution that comes with less risk and less maintenance costs than the DIY approach. With Pulumi Cloud, you get a fully managed service that automates deployments, ensures compliance, and offers comprehensive security features out-of-the-box. You’ll get a clear understanding of the product roadmap as well as talented engineers supporting your architecture and use cases.

Pulumi Cloud gives you the platform to automate, secure, and manage your modern infrastructure platform so your company can choose to focus on innovation and growth.

Try Pulumi Cloud for free and see how it can accelerate your infrastructure automation. Sign up today and start building with Pulumi Cloud.

A Recipe for a Better AI-based Code Generator

Artur Laksberg — Tue, 07 Jan 2025 20:00:00 -0500

Note: This post discusses Pulumi Copilot, which Pulumi Neo has replaced. Learn about Neo →

When asked about his research process, Anthony Bourdain would describe how he’d blend his formal culinary training with deep dives into local food culture - from market stalls to family recipes. Modern AI code generation follows a similar path: it can’t just rely on what it knows - it must tap into continuously evolving, domain-specific knowledge bases. Just as Bourdain would combine his classical French training with techniques learned from local kitchens, AI code generators blend their built-in knowledge with retrieved code snippets and type definitions to generate code that accurately represents the user’s intent.

This fusion of base knowledge with contextual understanding is especially valuable for Infrastructure as Code (IaC), where rapidly evolving cloud providers and libraries make manual development challenging, traditional debugging cycles impractical, and errors catastrophically expensive.

The role of IaC won’t diminish in the age of AI - if anything, it will become even more central as systems grow increasingly complex and automated. Trustworthy code generators will be a key ingredient in the recipe for modern infrastructure management.

In this post, we share how we developed code generation for Pulumi and what we learned, based on both our production IaC generator powering Pulumi AI and Pulumi Copilot, as well as features and approaches we’re still exploring.

Using RAG for code generation

Pulumi supports over 120 providers, including major cloud providers such as AWS, Azure, Google Cloud, and Kubernetes, as well as many other services and platforms. New providers are continuously added, and existing providers change as their capabilities grow.

Our goal is to generate the most accurate code for every provider - code that is not only correct but also reflects their latest capabilities.

LLMs are great at generating code however they are limited to what they have learned before their knowledge cutoff date. This means that the latest changes in the providers will not be reflected in the generated code. This also could lead to hallucinations when the model struggles to answer a question that requires up to date knowledge.

To help us solve this, we rely on the technique known as the Retrieval Augmented Generation (RAG). RAG helps code generation by integrating information retrieved from external data sources. In Pulumi, we call this data source the Registry - it’s the database we maintain that contains type schema and usage information for every provider.

At a high level, using RAG involves the following steps:

Analyze user’s question.
Look up the pertinent information from the Registry.
Format that information in a system prompt that LLM can understand.
Make the LLM call asking it to generate the code using the additional information in the prompt.

There is lot of fascinating details here, so let’s dig in!

The anatomy of Pulumi Copilot RAG

Before going into the details, let’s consider a simple yet essential insight: an effective dataset for RAG must meet two key requirements:

It must contain the necessary information.
The information must be easily searchable.

Let’s take a sample user query:

“Generate code for S3 Bucket”

To fulfil the request, the system needs to intuit the following:

The cloud provider. This can be determined based on the fact that S3 is a common storage solution in AWS, and possibly the fact that the user’s organization has stated AWS as their preferred cloud provider.
The programming language. This information can again come directly from the organizational preferences, or from the user’s prior conversations.
The information about the type (or types) that must be created - its name and schema, the package it is in, and the capabilities it supports. Some of this information comes from the built-in LLM knowledge, supported and augmented by the Registry.

Putting it all together, we can now expand the original user query into the following prompt that is going to guide the code generation:

“Generate TypeScript code for S3 Bucket, the AWS resource defined in package @pulumi/aws, type aws.s3.Bucket with its schema defined as follows: …

While we had to rely on some guesswork to come up with this prompt, fortunately this process can be iterative - if we don’t get all of it right the first time, we can try again with additional information that will help us refine the results. This is an important point we return to later in the post.

Assessing search quality using recall and precision

To assess how effective the RAG is, we need to first understand the two fundamental concepts used in the information retrieval systems: the recall and the precision. Imagine that you’re looking for apple pie recipes in one of Jamie Oliver’s cookbooks. The book has a recipe for a classic American apple pie, a Dutch apple pie and a modern take on a French apple tart. Due to the book’s narrative approach with the recipes woven into the stories and context, you’ve managed to retrieve only the first two recipes but missed the French apple tart. Having retrieved 2 ouf 3 relevant documents, you have achieved a 67% recall.

Because you were looking for the word “pie”, you also retrieved a recipe for a Shepherd’s pie, which, while delicious, does not qualify as an apple pie. Another document that came up was a fish pie - a classic British dish that does not contain apples or even a pastry crust. Since only 2 of your 4 retrieved documents can be legitimately classified as apple pies, you have achieved a 50% precision.

Now let’s formalize this a bit. Recall measures the ratio of the relevant documents retrieved to the total number of relevant documents in RAG dataset:

$$Recall = \frac{N(Retrieved \cap Relevant)}{N(Relevant)}$$

Where

$N(Retrieved \cap Relevant)$ is the number of documents that are both retrieved and relevant.
$N(Relevant)$ is the total number of relevant documents in the database.

Good recall means that many documents relevant to the query were retrieved.

Precision is the ratio of the relevant documents retrieved to the total number of retrieved documents:

$$Precision = \frac{N(Retrieved \cap Relevant)}{N(Retrieved)}$$

Where $N(Retrieved)$ is the total number of documents that were retrieved.

High precision means that many of the retrieved documents were relevant.

Naturally, we want to maximize both the recall and the precision. It’s been said that high recall is essential to ensure relevant content is available to the code generator while precision is the parameter you want to optimize for to avoid hallucinations.

Practical concerns

Precision and recall are essential in understanding the information retrieval quality, but they are quite hard to measure in practice. Unlike a cookbook, Pulumi registry contains thousands of ever changing documents, and evaluating how many of them are relevant for every user-submitted query is impractical. This makes recall evaluation for live traffic next to impossible. Things are a little easier with precision, where we’re dealing with a small number of documents, but even that metric requires a non-trivial evaluation of relevance, which needs an LLM call or a human judge.

Fortunately, other metrics that often can effectively estimate retrieval quality have been developed. We have found a metric that can predict, with some degree of accuracy, whether the generated code will successfully compile. For this metric, we compare the tokens present in the LLM-produced prompt with the number of tokens present in the generated code. (By token here we understand a compiler token - an identifier such as the name of a class, method or a field and not a traditional LLM token concept), Intuitively, if a token present in the prompt also appears in the generated program, it can be assumed that the token contributed to the generated program. Tokens in the generated program that were not part of the prompt are not necessarily wrong but they are less trusted (they can come from the LLM built-in knowledge or were guessed)

$$prompt \ coverage = \frac{N(\text{Tokens in prompt} \cap \text{Tokens in code})}{N(\text{Tokens in code})}$$

Prompt coverage is a metric we can observe in production, and it’s one of several metrics we use when updating providers to ensure we haven’t regressed the quality of the RAG.

Semantic search with vector embeddings

Semantic search is based on the conceptual similarity of the term you’re looking for with the elements in the data store. For example, searching for “dumplings” can return terms like pierogi and gyoza - words with different spelling but both representing different types of filled dough preparations.

A common way to determine the similarity between the two strings is to first turn these strings into vector embeddings - arrays of floating point values representing the semantic meaning of each string - and then calculate the cosine similarity between the two vectors, which is the cosine of the angle between the vectors. Various methods of producing vector embeddings are fascinating but we will not cover them here in depth.

For Pulumi code generation we are using the OpenAI’s Ada-002 embedding model which at this moment represents a good balance between performance and cost.

Producing vector embeddings from the user query is the standard approach in this situation. However, for Pulumi code generator we added a little twist - to increase the odds of getting more relevant information from the Registry (i.e. to increase the recall) we first make an LLM call to generate a small set of relevant search terms that will produce an array of vector embeddings.

Getting vector embeddings from user query

We then use the array of vector embeddings to retrieve the set of relevant documents from the Registry.

Full text vs semantic search

While semantic search is essential for any modern information retrieval system, we should not forget simple and effective methods for text search already exist. The “S3 Bucket” part of the user search happens to be easily searchable using traditional text search operations (such as SQL LIKE operator).

To be effective, our RAG must be able to handle queries that require semantic understanding (such as “simple storage service in AWS”) as well as the traditional text search to support situations where the user knows exactly what they are looking for. To that end, the industry has adopted an approach known as the “hybrid search”, in which the results of full-text search and semantic search are combined to provide the final result.

For each of these search terms we generate a query that combines the full text search with the semantic search. The resulting documents are then evaluated based on the following criteria:

Dense score: Vector similarity using cosine distance between query embedding and stored embeddings
Sparse score: Text search relevance according to the full-using algorithm (PostgreSQL full-text search in our case)

Both the dense and the sparse scores contribute to the final score that is used to sort the documents. Even though the final score is the average of the two in our current implementation, it would not be correct to say that they have the same weight, or the influence on the end result. This is so because the normalization of the scores must take into account their distribution in the real-world queries and calculating that is quite complex.

Boosting the influence of one score relative to the other is an area we’re actively exploring, and achieving the optimal result depends highly on what parameters we decide to optimize for - high quality code, time to result and so on.

Finally, we apply the rank-based scoring technique in which the results are penalized based on their position in the ranking. This creates separation between results that might have similar initial scores and gives preference to results that appear earlier in the ranking.

Pruning the results

Our Pulumi code generator employs a two-phase document selection strategy. The first phase casts a wide net, gathering all potentially relevant documentation to maximize recall. The second phase applies precision-focused filtering to distill this collection down to the most pertinent documents.

This filtering step serves two purposes. First, it prevents LLM hallucinations that arise from similarly-named types across different providers. Second, it optimizes performance by keeping prompts concise - a critical consideration given that larger prompts increase both latency and computational costs, even when within context window constraints.

Through empirical testing with the Pulumi Registry search, we’ve established these baseline parameters: a maximum of 10 documents per query term selected by relevance score, and a 20K token ceiling for prompts. While these parameters have yielded good results in practice, they are likely not optimal for all scenarios. We continue to iterate on these values through ongoing experimentation.

Prompt generation

We’re now ready to create the system prompt for the code generation LLM call! We’ve already discussed some of the elements needed to build the effective prompt - the original user query, the search terms and the vector embeddings that produce the set of documents that will guide the code generation process.

There is another element that goes into the prompt - a concise set of instructions produced by an LLM call based on the original user’s query. The approach when the output of one prompt is used as input for another is known as “prompt chaining”, and we used it to provide step-by-step instructions to the code generator. For our query, this set of instructions can look as follows:

Create an S3 bucket using Pulumi in TypeScript using the following steps:

Import the necessary Pulumi AWS package.

Define a new S3 bucket resource with basic configuration.

Export the bucket name as an output.

Composition of the system prompt for code generation

Finally, we use the resulting prompt to call the LLM and ask it to generate the code. We’re done!

Self-debugging

Unfortunately, this isn’t always the final step of the process. Despite our best efforts, the code produced by the LLM will not always be correct.

At this point, it’s worth pondering what “correct code” means. The generated program might have the following problems:

It might be syntactically or semantically incorrect, i.e. it might not compile or fail to typecheck.
It might fail at runtime - for example by referring to a non-existing resource, a region and so on.
It might run “successfully” but not do what the user intended - either because the user did not express themselves clearly or because the request was misunderstood.
Finally, the code might run and do exactly what the user wants, but lead to an undesired outcome, for example loss of an asset, or a security vulnerability.

Solutions to many of these problems go well beyond the domain of code generation.

However, the first of these problems can be addressed by the approach known as “self-debugging”.

We observed that many generated TypeScript programs that fail to typecheck contain only a few errors, and asking the LLM to fix these errors often produces a valid program. While this approach is still experimental, we see promising results where getting to a correct program requires only 1-2 iterations of self-debugging. The biggest challenge with this approach is doing it in real-time. The user is staring at the screen waiting for an answer, so latency is a major concern.

Monitoring these typechecking errors in production can also provide valuable insight into the quality of the data used by the RAG and even suggest specific solutions. For example, failure to typecheck a member-access expression is a likely indicator of a missing type schema (a recall problem) or a “wrong” schema brought in by an irrelevant document (a precision problem).

Self-debugging can also be extended to include the pulumi preview command, which is a “dry run” operation before the actual deployment and can detect many real or potential problems such as destructive actions, incorrect configurations that cannot be detected at compile time, dependency conflicts, and policy violations.

From kitchen to table: testing what works

The landscape of LLM-based code generation is moving fast, and we need to keep learning and adapting as we go. But with all this rapid technological change, it’s crucial to ground our decisions in real numbers. We need to make sure each new advancement actually makes things better, both in our test environments and out in the real world.

The probabilistic nature of LLM-based code generation means we can’t rely solely on pre-production testing. Instead, we adopt multiple layers of quality control working together. Here’s what we’ve learned works best:

Building confidence through testing

Our testing strategy combines several approaches:

Systematic experimentation: We run “what-if” scenarios against various test datasets to understand how the system behaves under different conditions.
Local evaluation pipeline: While local testing has its limitations, it helps catch obvious issues early in development. We evaluate the performance of the code generator and run the code through the typechecker.
Deterministic generation: We set the LLM temperature to 0 to ensure consistent outputs. For code generation, consistency and repeatability matters more than creative variations.

Monitoring quality in production

We track several key metrics to ensure the system performs well:

RAG effectiveness: We measure prompt coverage to evaluate how well our retrieval system performs.
Code quality indicators: We track the percentage of generated code that successfully typechecks for all supported languages along with how this metric responds to system changes.
User feedback: Every “thumbs down” report gets analyzed to identify patterns and potential improvements. This direct user feedback has been invaluable in refining our system.

Wrapping up

Building an effective AI-powered code generator requires carefully balancing multiple concerns: the raw capabilities of LLMs with retrieved contextual knowledge, semantic search with traditional text matching, and thorough testing with real-world scenarios.

Our experience has taught us that success lies in treating code generation like a delicate soufflé - it requires precise measurements, careful monitoring, and constant refinement of technique. The key ingredients are:

A robust RAG system with well-tuned recall and precision.
End-to-end testing and monitoring across development and production.
Self-debugging capabilities to handle common issues like type checking errors.

As we continue to evolve Pulumi’s code generation capabilities, we’re excited about expanding our self-debugging features and further refining our RAG implementation.

We invite you to try these capabilities in your own projects and share your experiences. Your feedback helps us continue improving and advancing the state of AI-assisted infrastructure development.

Top 15 Python Tools for DevOps

Adam Gordon Bell — Mon, 06 Jan 2025 00:23:24 -0500

Have you ever had one of those moments: Elasticsearch is crashing, logs are filling up too fast, or a deployment needs data from three different APIs. The big enterprise solutions aren’t quite right, and your team estimates six months to build something proper. But you know that with Python and a few choice libraries, you could hack something together by tomorrow.

Let's build a little web dashboard in Python.

That’s where Python really shines. It lets you be the scrappy problem-solver who can travel up and down the stack. But Python isn’t just for quick fixes. The same language that helps you hack tomorrow’s solution can also build your company’s long-term infrastructure.

This guide covers both ends of that spectrum. I’ll show you python packages for “we need it yesterday” moments, and then move into solutions that can grow with your team. And along the way I’ll build a little example service monitor and package capturer to demonstrate the python packages I’m covering. I’ll wrap it in a CLI, in a web dashboard and deploy it to AWS, all while staying in Python.

So here’s my list of Python libraries for DevOps work, starting from #15 to the most important last at number #1.

Dashboards / monitoring

Let’s start with building web dashboards. Long-term, it’s usually better if there’s an off-the-shelf tool for that specific dashboard you need. But if you can create a quick visual on a Django endpoint, you can move on to the next issue.

15 and 14. Django and Flask: (Django, Flask) While tools like Grafana excel at metrics visualization, sometimes you need custom dashboards that integrate with internal systems. These frameworks let you build dashboards to track and visualize various aspects of your systems. I find Django a great fit here.
13. Prometheus: (prometheus-client) This library is a versatile tool for metrics. Want to expose custom metrics to Prometheus? Use the client to create counters, gauges, or histograms. Need to pull data from a weird API and expose it as metrics? Write a quick exporter that fetches from your API every few minutes and translates the responses into Prometheus metrics.

from flask import Flask, render_template_string
import requests

app = Flask(__name__)

@app.route("/")
def index():
 try:
 response = requests.get("https://www.githubstatus.com/api/v2/status.json", timeout=5)
 if response.status_code == 200:
 data = response.json()
 status = data["status"]["indicator"]
 description = data["status"]["description"]
 else:
 status = "critical"
 description = "Unable to reach GitHub API"
 except Exception as e:
 status = "critical"
 description = f"Error: {e}"

 color = {
 "none": "bg-green-500",
 "minor": "bg-yellow-500",
 "major": "bg-red-500",
 "critical": "bg-red-700",
 }.get(status, "bg-gray-500")

 return render_template_string(
 """
 ...
 """,
 color=color,
 description=description,
 )

Code for a simple Dashboard

You might also like:

Task scheduling and orchestration

Sometimes you need to run things on a schedule. And while I love cron, sometimes you need more. Maybe you need to coordinate multiple tasks, handle retries, or manage complex job dependencies. Here’s where Python can help:

12. Schedule: (schedule) When cron is too heavy but you need more than a bash script. I use it for quick automation tasks like “check this API every hour and alert if something’s wrong.” It runs in your Python process - no system configuration needed.
11. RQ (Redis Queue): (rq) Perfect for local development queues. Need to prototype a GitHub webhook handler that’ll eventually use SQS? With Redis in Docker and RQ, you can have a working queue in minutes. No AWS needed until production.
10. Airflow: (airflow) The big gun of scheduling. Yes, it’s complex, but sometimes you need that power. I’ve seen teams replace entire ETL systems with a few Airflow DAGs. When you need to coordinate multiple steps, handle failures gracefully, and have everything visible in a nice UI, it delivers.

def schedule_url_checks():
 for url in urls.values():
 schedule.every(30).seconds.do(lambda url=url: check_url_status(url))

def run_scheduler():
 while True:
 schedule.run_pending()
 time.sleep(1)

if __name__ == "__main__":
 schedule_url_checks()
 threading.Thread(target=run_scheduler, daemon=True).start()

Adding Schedule to our code, so we can request in the background.

Network analysis and security

When your network issues go beyond what tcpdump can tell you, or when you need to automate security checks, Python is here to help:

9. Scapy: (scapy) The Python alternative to Wireshark for programmatic network traffic analysis. Need to figure out why your microservices aren’t talking to each other? Want to check your load balancer? Use it to capture and analyze packets with a few lines of code.
8. Bandit: (bandit) Security scanning for your CI pipeline. Point it at your Python codebase and it’ll flag common issues like hardcoded credentials or unsafe deserialization.

def packet_callback(packet):
 global packet_stats
 packet_stats["total_packets"] += 1
 if packet.haslayer("HTTPRequest"):
 packet_stats["http_requests"] += 1

def start_packet_sniffer():
 sniff(prn=packet_callback, store=False, timeout=60) # Capture packets every 60 seconds

if __name__ == "__main__":
 threading.Thread(target=start_packet_sniffer, daemon=True).start()

Adding packet sniffing to our code, mainly just because we can.

Containerization and cloud interaction

Sometimes you need more control over your containers than Dockerfiles can provide. Maybe you need to dynamically build images based on environment variables, or automate container management:

7. Docker SDK for Python: (docker-py) When you need to automate Docker operations programmatically. I use it to clean up old containers and images, check container health, and build images dynamically from configuration files. More powerful than chaining Docker CLI commands.
6. Dagger: (dagger-io) Write container build logic in Python instead of Dockerfiles. Need to build multiple similar containers with slight variations? Want to pull in files from different sources based on environment? It lets you programmatically define container contents and build steps. (Bonus: this same code can later be used in CI/CD pipelines.)

import dagger

async def main():
 # Connect to the Dagger Engine
 async with dagger.Connection() as client:
 container = (
 client.container()
 .from_("python:3.11-slim")
 .with_exec(["python", "-c", "print('Hello from Dagger!')"])
 )

 # Execute the container and get the output
 output = await container.stdout()
 print(output)

if __name__ == "__main__":
 import asyncio
 asyncio.run(main())

Using Dagger makes it easy to stay in Python while building containers.

Building command-line tools

Let's build a CLI version of our service status dashboard in Python.

Every useful script eventually needs to become a proper tool. When your team starts asking “can I use that script too?” it’s time to enhance your CLI skills:

5/4. Click/Typer: (Click, Typer) Turn your quick scripts into proper CLI tools. Instead of remembering python cleanup.py --older-than 7 --dry-run, you get tab completion, help text, and proper argument handling. Typer is particularly nice if you’re using modern Python - it uses type hints to build the CLI interface.
3. Rich: (rich) Make your terminal output actually readable. Need to display tables of data? Want progress bars for long-running tasks? Rich makes it easy to build user-friendly CLIs. I use it to turn wall-of-text logs into colored, formatted output that helps spot problems quickly.

2. The essential toolkit

The foundation of any DevOps tooling consists of these essential libraries:

Requests (requests) - For making HTTP requests
Pytest (pytest) - For testing your code
logging (Python logging) - For structured logging
YAML/JSON/TOML parsers (PyYAML, json, toml) - For config file handling

While not flashy, these libraries form the backbone of every tool I build. And so I update my little tool to have some tests, some logging and store the api status urls in a toml file.

Now, #1 and it’s IaC time. I can get my dashboard onto AWS in a lambda using Pulumi.

# Build and push the Docker image to ECR
image = awsx.ecr.Image("app-server-image",
 repository_url=repository.repository_url,
 context="..",
 dockerfile="Dockerfile",
 platform="linux/amd64"
)

Push my Image to ECR

1. Pulumi

While most tools in this list excel at quick solutions, infrastructure demands a more robust approach. This is where Pulumi stands apart. It’s not just another scrappy tool—it’s an enterprise-grade Infrastructure as Code platform that happens to harness Python’s power and flexibility.

With support for real Python code instead of configuration languages, you can define, deploy, and manage your cloud resources using familiar programming concepts and practices.

With Pulumi, you get:

Complete programming language support for using loops, functions, and classes in your infrastructure code
Infrastructure testing capabilities to validate your deployments before they go live
Container deployment solutions for managing Docker images and Lambda functions
Rich AWS integration for comprehensive cloud resource management
Infrastructure automation to streamline your deployment workflows

# Create a Lambda function
lambda_function = aws.lambda_.Function("custom-lambda",
 name="custom-lambda",
 package_type="Image",
 image_uri=image.image_uri,
 role=lambda_role.arn,
 timeout=30,
 memory_size=512,
 environment={
 "variables": {
 "FLASK_ENV": "production"
 }
 }
)

Start it up in a Lambda

Bringing it all together

Dashboard is still pretty basic, but now it's on AWS with a little Python infrastructure code.

Here’s where Python excels - combining these tools to solve real problems. For example:

Need a dashboard for infrastructure costs? Combine Flask with the AWS SDK and Pulumi Insights.
Want to automate container cleanup? Mix Docker SDK with Schedule for regular maintenance.
Building a custom GitHub webhook processor? Use Flask to receive webhooks, RQ for asynchronous handling, and Rich for readable logs.

Start simple (maybe just a script with Requests and PyYAML), then gradually add more tools as needed. That’s the beauty of Python in DevOps - you can start small and grow your solution naturally.

The art of getting things done

The tools I’ve covered span the full spectrum of DevOps needs—from quick scripts to enterprise-grade solutions. Python’s versatility makes it uniquely suited for both ends of this spectrum:

For urgent needs, tools like Schedule, Rich, and Click let you rapidly prototype solutions.
For long-term infrastructure, Pulumi and Airflow provide the robustness needed for production systems.
For everything in between, Python’s extensive library ecosystem helps you gradually evolve quick fixes into mature tools.

The key is knowing when to use each tool.

AI Engineering Lessons from Building Pulumi Copilot

Artur Laksberg — Thu, 12 Dec 2024 13:56:13 -0500

Note: This post discusses Pulumi Copilot, which Pulumi Neo has replaced. Learn about Neo →

Building AI-powered developer tools comes with unique challenges, and now that we’ve launched our REST API, we want to share some lessons we’ve learned building Pulumi Copilot, an AI assistant for cloud infrastructure.

One of the big challenges was determining what ‘working’ really meant. So when a message landed in our feedback channel after months of rigorous testing - ‘Your tool doesn’t know anything!’ - it caused some mild panic. We’d just made some changes, so we braced for the worst. But our evals were still looking strong, so what was going on?

The user was attempting to force-delete a stack that still contained resources. But when we dug deeper, we found something fascinating: Copilot had confidently suggested a ‘–force’ flag, which would have been a logical solution… except this flag doesn’t exist in Pulumi. Our AI was hallucinating exactly what the user wanted. But this wasn’t just a bug - it was the first of many insights that would reshape how we approach AI-powered tools.

To understand how we got here - and why this “error” actually taught us something valuable about our product - let’s start with the core challenge we faced: balancing traditional software engineering with this new world of prompt engineering.

Engineering for Reality: Prompt Engineering vs Software Engineering

When building LLM-powered applications, it’s tempting to throw every task at the model. Modern LLMs can generate code, format text, and create clickable links. But this approach carries hidden costs.

Working on Copilot taught us a key lesson: let the LLM do what it does best and use good old imperative code for everything else.

Take a seemingly simple feature: listing a user’s Pulumi stacks with clickable links based on data from a backend API. Our first implementation used a complex prompt instructing the LLM to construct URLs in the format app.pulumi.com/org/project/stack. The prompt explained the format, provided examples, and asked the LLM to generate these links from JSON data it had.

It worked - almost all of the time. But we were seeing occasional malformed URLs and more importantly, this was burning input tokens (and money) on a complicated prompt that made AI construct strings that could be deterministically generated.

The solution was straightforward: generate the full links in the backend service and include them directly in the context. The LLM then needs no instructions on how to create them. Simple stuff, but it gave faster responses and perfect URLs at a lower cost.

When you find yourself writing elaborate prompts to handle structured data transformations, stop and ask: Could traditional code do this better? Could this be decomposed so that the LLM does less?

To validate this approach, we tested Copilot ourselves to see what worked.

Copilot in Action: Real-World Dogfooding

The internal testing phase taught us invaluable lessons about how people would actually use the tool. We watched our team try Copilot in their daily work, and three common use cases emerged:

Debugging Deployments: LLMs clearly excel at summarization. One of the first questions our internal users asked was, ‘Why did my latest infrastructure deployment fail?’ Using Copilot to extract a clear natural language explanation requests like these has been a clear win.

Understanding Complex Infrastructure: Copilot helped our engineers gain insights into Pulumi’s own infrastructure. Asking, ‘How many resources are in production?’ ‘What expensive compute is running’ or ‘What version are the EKS clusters in EU?" shows the value of allowing users to express infrastructure questions in natural language.

Generating Code: One of the first queries logged was, ‘I want a static website on AWS behind a CloudFront CDN.’ Another came from a Solutions Engineer, tasked with demonstrating Pulumi’s CrossGuard policy engine to a prospect, asking Copilot to generate policy code.

These early experiences showed the value of Copilot. But they also revealed the need for a systematic approach to handling diverse user queries. This led to the development of what we call skills.

Skillful Slicing: Modular Mastery

As Copilot grew, we broke it into smaller pieces we call skills. Each skill does one specific job. The Insights skill handles queries about resource usage and configuration (“How many S3 buckets do I have?”), the Cloud Skill interacts with the Pulumi Service API to manage infrastructure (“Show me my stacks.”), the Code Skill generates Pulumi code snippets (“Write a Typescript program…”), and the Docs Skill retrieves information from Pulumi documentation (“How do I use update plans?”).

When you ask Copilot something, it figures out what you need and picks the right skill for the job – like a manager deciding which expert to send your question to. This function-calling approach, orchestrated by a component we call the “outer loop,” allows Copilot to access and process information beyond its internal knowledge base.

Fortunately, Pulumi Cloud already exposes a rich API - in fact, this is what powers the Pulumi Console and the Pulumi CLI - so all we had to do is to build a skill that maps the user query to the appropriate Pulumi Cloud REST API. A question like “Show me my stacks” translates into the List Stacks API call. A question like ‘Show me my untagged EC2 instances’ is a bit more complex but it breaks down into clear components - resource type (EC2), filter condition (untagged) - that route to the Insights skill. This mapping helped us handle the many ways users phrase the same technical request.

Refining this routing system revealed another opportunity: streamlining the Debug button workflow.

Debug Dispatch

Originally, when a user clicked ‘Debug with Copilot’, the system would send a text query like “Analyze this update and explain any errors.” Copilot would then:

Determines the user wants to analyze an update
Identifies which API to call
Calls the API
Summarize the result

Having the LLM figure out what the user wants is the right approach in general, but in this case, we already know the user’s intent - they clicked a debug button. So, we can directly call the analysis API to get the results and use the LLM solely for what it does best: summarizing technical output into clear, actionable explanations.

This is another small win for the “Software Engineering over Prompt Engineering” approach. Traditional code handles the predictable parts, while AI focuses on the human-facing explanations.

But while minimizing the LLM workload helped with efficiency, we soon faced an even trickier challenge: the deceptive polish of AI-generated outputs.

The Illusion of Correctness

Large language models excel at generating well-structured, grammatically correct output. They make neat tables, tell good stories, and generally sound confident. That’s what makes them dangerous because this polished presentation can mask underlying flaws in the information itself, creating a false sense of confidence for users.

One of our early testers, Pablo, a data engineer at Pulumi, encountered this firsthand. He posed a query to Pulumi Copilot, asking for a summary of resources within a specific project. The response he received was impeccably formatted, neatly categorizing resources by type and providing counts for each. It looked right, and for us humans sometimes looking right carries a lot of weight.

However, a closer inspection revealed the numbers were way off. Copilot had asked for the wrong data and then summarized it beautifully - but incorrectly. This highlighted our next challenge: how do you systematically test a system that can be confidently wrong while sounding completely right?

Testing the Untestable: Validating LLM Outputs

When testing traditional code, we expect consistent, predictable outputs. With LLMs, even correct answers can vary. Here’s how we tackle this challenge.

Our first approach was simple: keyword checks. For example, when testing the update analysis feature, we checked if the LLM’s response included the word “security” and described the error. This worked for straightforward cases but broke down quickly. Take a question like, “How many Lambdas am I running?” The LLM might give the right numbers but skip the word “running,” failing the test even though the answer was correct.

These early failures revealed the limitations of keyword-based validation and underscored the need for a more nuanced approach. Inspired by platforms like LangSmith and Promptfoo, we began leveraging LLMs themselves as evaluators. For deterministic tasks, simple keyword checks suffice, but for more complex scenarios—like assessing whether a response answers a specific question—we rely on an “LLM Judge.” This approach balances efficiency and flexibility, reserving LLM evaluation for cases where it truly adds value. The test suite now integrates both methods, running against every code change to validate response content, accuracy, and format.

The eval suite keeps getting more robust, which means that when new AI models drop, we can quickly catch any weirdness before it hits production. The generative AI space moves crazy fast and the code changes a lot, but the evals are a safety net - catching hallucinations, maintaining quality, and making sure we don’t ship anything that’ll annoy our users.

So, while hallucinations are now much rarer, what about that one with the --force flag? Yes, it’s “just another bug,” but it taught us something fascinating about these AI errors.

You might also like:

LLMs think like humans (sort of)

The --force hallucination wasn’t totally wrong - it was revealing what users intuitively expect from the CLI, and the LLM accidentally showed us what was missing. Force deletion is a common pattern across developer tools, and the LLM, trained on vast amounts of documentation and code, simply reflects these established conventions.

This has fundamentally changed how we view hallucinations. While the team works constantly to minimize them – and our eval work means they happen way less frequently – some of them are clearly product signals. The LLM, in this light, becomes an unexpected source of user research, drawing on its training across thousands of developer tools and experiences.

This insight is one of the key lessons of building Copilot:

Minimize LLM Usage: Let traditional code handle deterministic tasks, reserve LLMs for natural language work
Decompose into Skills: Break complex tasks into modular units that combine LLM and traditional code appropriately
Test Rigorously: Use multiple validation approaches, including LLMs testing LLMs
Learn from Hallucinations: Sometimes incorrect outputs reveal user expectations
Learn from Users Continuously: User interactions improve our AI systems - from training better skills to catching hallucinations and revealing product opportunities.

These lessons helped shape our latest release: the Pulumi Copilot REST API, now available in preview. You can integrate these same capabilities and skills into your own tools and workflows. Whether you’re building CLI extensions, chat integrations, or automated deployment checks, the API provides a contextual understanding of Copilot. Try it out.

We can’t wait to see what you build!

Infrastructure as Code: The Hidden Cost of Doing It Yourself

Aaron Kao — Tue, 10 Dec 2024 09:00:00 -0800

Note: This post discusses Pulumi Copilot, which Pulumi Neo has replaced. Learn about Neo →

Infrastructure as Code (IaC) has revolutionized how cloud resources are managed, allowing for more efficient, scalable, and repeatable deployments. We designed Pulumi IaC to let you program cloud infrastructure using familiar programming languages like TypeScript, JavaScript, Python, Go, .NET, Java, and YAML. This approach not only simplifies the process but also integrates seamlessly with existing development tools and ecosystems (e.g., IDEs, standard unit test frameworks, integration test). You can define infrastructure with code, often in just one line, for serverless, Kubernetes, AI/ML, databases, and more. You can also preview changes before deploying unlike many other IaC solutions. Pulumi IaC is fully open source with a public roadmap. We value working with the community to shape the product through feedback and contributions.

What is Pulumi Cloud?

Infrastructure as Code tools like Pulumi require systems for coordinating deployments, which include concurrency control, state management, and security. For the purposes of this post, let’s refer to these systems as IaC backends. There are several options for managing these backends: you can either handle them yourself, which we’ll call DIY, or you can leverage Pulumi Cloud, available as a SaaS or self-hosted solution. With Pulumi Cloud, you gain access to a comprehensive infrastructure management platform designed to handle everything running in the cloud. This platform automates your IaC deployments, centralizes secrets management and orchestration to manage secrets sprawl effectively, and employs AI to oversee infrastructure assets and ensure compliance. On the other hand, with a DIY approach, you have the flexibility to build everything Pulumi Cloud offers or opt for a more minimalistic setup tailored to your organization’s specific needs. Both options are well-supported by Pulumi, but there are distinct advantages to choosing Pulumi Cloud over the DIY method, which we’ll explore further.

Costs and Complexities of DIY Backends

Building and maintaining your own Infrastructure as Code backend involves a significant engineering and operational commitment. On the engineering front, you face security and compliance challenges, as well as the need to develop features that ensure enterprise readiness. Operationally, the backend must be highly available and reliable, and it should facilitate easy onboarding for the rest of the organization when the time comes. Beyond these immediate concerns, there are also hidden personnel costs associated with running your own backend. Let’s break down some of those hidden costs.

Materialize reduced costs and accelerated time to market by making developer onboarding 75% faster.

“Pulumi lets us manage multi-cluster Kubernetes infrastructure efficiently, all in one stack. It has hugely benefited productivity and our service’s reliability. Without Pulumi, we know that scaling and maintaining Materialize would be much harder for the team.”

–— Paul Hemberger, Engineering Manager for Materialize’s cloud team

Learn more

Operational Excellence

One of the primary functions of IaC backends is managing state. State management involves managing concurrency controls, preventing state corruption, ensuring backup and recovery, maintaining high availability of the state service, and providing consistent visibility across all managed resources; this is easy to get wrong. For instance, an incorrect Git merge of your state can result in outages, as evidenced by Spotify speaking publicly about accidentally deleting two-thirds of their production Kubernetes clusters due to a faulty state merge.

Pulumi Cloud offers total visibility into changes within your organization, allowing you to track who is deploying what, when, and where, down to the individual cloud infrastructure properties being changed and the source commits triggering them. If issues arise and you need to revert to a prior known state, Pulumi Cloud’s transactional state checkpointing protocol ensures automatic recovery from failures, and failures are common with transient cloud and networking issues. In contrast, DIY backends require manual human intervention to recover and repair state files, a process that is time-consuming, extends outages, and carries significant risk. Pulumi Cloud also automatically backs up and replicates your state checkpoints, facilitating easy recovery for audits or rollbacks, potentially preventing outages or meeting audit standards.

Managing your infrastructure with IaC demands considerable time and energy. Pulumi Cloud provides Pulumi Insights, offering search, analytics, and AI-driven insights over your infrastructure. If you’re using a DIY backend, you’ll need to build your own search clusters and grep systems. With Insights, you can instantly search for critical information - such as finding MySQL databases on end-of-life versions across all your cloud assets. You can also have a conversation with Pulumi Copilot about your infrastructure in plain English and get answers to operational questions that would take hours to piece together from other sources.

With this total visibility, Pulumi Insights helps you reduce waste by showing you usage information and identifying potentially stale infrastructure, which can lead to substantial cost savings.

When you build and operate your own IaC backend, you’ll need to dedicate one full-time engineer for every team of ten - that’s nearly 10% of your engineering expense. Pulumi Cloud, as a fully managed service, frees up your team’s time from the operational and maintenance burdens of managing an IaC backend.

Unity reduced deployment times by 80%, from weeks to hours, significantly improving their time to market.

“Terraform relies on HCL and lacks support for concepts like classes, objects and inheritance. An equivalent deployment would take more lines of code while yielding IaC that is less reusable.”

Learn more

Security and Compliance

IaC backends are mission-critical components that require robust security measures to protect the backend service, cloud assets, and applications running on the infrastructure.

At the backend service layer, you must design and manage the service to adhere to numerous IT security standards, including SOC 1/SSAE 16/ISAE 3402, SOC 2, SOC 3, FISMA, FedRAMP, DOD SRG Levels 2 and 4, PCI DSS Level 1, EU Model Clauses, ISO 9001 / ISO 27001 / ISO 27017 / ISO 27018, ITAR, IRAP, FIPS 140-2, MLPS Level 3, and MTCS. This involves a manual assessment and validation process for each standard, which can be time-consuming and complex.

Pulumi, as an Amazon Web Services Advanced Partner, undergoes a thorough review and certification of its security and compliance practices by the AWS team. Pulumi Cloud operates on AWS infrastructure, which is designed and managed in alignment with security best practices and all the aforementioned IT security standards. This infrastructure does not require or have access to personally identifiable information (PII), making it suitable for managing applications that require HIPAA and ISO 27018 compliance. Pulumi also conducts annual penetration testing of Pulumi Cloud and maintains active SOC 2 Type II compliance.

Access control at the backend service layer is crucial for enforcing least privilege access. Pulumi Cloud integrates seamlessly with various identity providers like Azure ActiveDirectory, Okta, G Suite, or any SAML/SSO provider, offering deep support for role-based access control (RBAC) and SCIM for automatic synchronization and revocation of access based on identity provider groups. This fine-grained control over state access is a significant advantage over DIY backends, where all access control mechanisms would need to be built from scratch. Audit logs play a vital role in tracking user activity within an organization, recording what actions were taken, when, and by whom. Pulumi’s audit logs are immutable, capturing the UNIX timestamp of events, the user who invoked the action, the event itself, and the source IP of the call. This level of auditing ensures that the activities of organization members are attributable, enhancing security and compliance.

At the cloud asset layer, you and your team need to prevent infrastructure deployments that violate policies related to security, reliability, cost, or compliance. Pulumi Cloud, through Pulumi CrossGuard, provides out-of-the-box support for common security and compliance policies, ensuring PCIDSS, ISO27001, SOC2, and CIS compliance for cloud applications and infrastructure. Such organization-wide enforcement and specific policy support are not readily available with DIY backends.

At the application layer, securing sensitive information like database passwords, cloud credentials, and API keys is paramount. Secrets can inadvertently end up in insecurely stored state files, leading to potential breaches, as highlighted by a Sysdig article where an attacker exploited a manually managed state file to gain control over an entire AWS account. Pulumi Cloud, however, encrypts all data in transit and at rest, utilizing hardware security module (HSM) based encryption. It also avoids capturing cloud credentials, instead relying on client-side authentication, as detailed in the Pulumi Cloud Security Whitepaper.

Pulumi Cloud further enhances security with Pulumi ESC, a centralized secrets management and orchestration service. This service allows for pulling and syncing secrets from various stores like HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, and 1Password, making it easy to adopt dynamic, short-lived secrets on demand. Pulumi ESC leverages the same identity, RBAC, Teams, SAML/SCIM, OIDC, and scoped access tokens used for Pulumi IaC, ensuring that secrets management complies with enterprise security policies. Every access or change to secrets or configuration values is logged for auditing, providing a secure and auditable environment for you and your team to access secrets via CLI, API, Kubernetes operator, the Pulumi Cloud UI, and in-code with TypeScript/JavaScript, Python, and Go SDKs. With a DIY backend, you have to manage integration and access controls with individual secrets stores, with potential secrets sprawl and operational overhead.

Tetrate uses Pulumi ESC to stop secrets sprawl and attain compliance more efficiently.

“With Pulumi ESC, our developers get dynamic AWS and Azure credentials on-demand. Onboarding new developers is quick and secure, with no more manually filling in .env templates.”

–— Liam White, Platform Lead

Learn more

Organizational Scaling

As your organization grows, you need an IaC backend that scales with the organization and makes it easy to onboard new teams. Pulumi IaC brings your development, infrastructure and security teams together. Your infrastructure teams can define and manage common infrastructure across the organization, collaborate with security teams to establish security and compliance guardrails, and enable easy self-service of infrastructure through custom developer platforms or shared infrastructure libraries. Teams that prefer not to program can use YAML, while those who do can leverage Python, TypeScript, Golang, or C# to define organization-wide components.

You might also like:

With Pulumi IaC, your teams can tackle the growing complexity of modern architectures using familiar software engineering principles. Programming languages offer loops, conditional logic, class inheritance, and object-oriented design, allowing your organization to craft more sophisticated infrastructure compared to legacy IaC tools.

When you’re scaling your organization, you’ll need an IaC backend that makes team onboarding efficient. DIY backends often involve ad-hoc onboarding with bespoke identity solutions, requiring custom documentation and training to troubleshoot unique problems. This can slow down onboarding and reduce end-user productivity. Additionally, DIY backends place the internal support burden on your team, requiring them to assist users in navigating the system.

In contrast, Pulumi Cloud offers standardized, well-documented capabilities and integrates seamlessly with identity systems, leading to efficient onboarding and increased productivity for new employees. Pulumi Cloud provides 12x5 or 24x7 support, ensuring your organization receives immediate assistance with any architectural, cloud-related, or Pulumi best-practices issues. Furthermore, Pulumi Cloud includes built-in RBAC, simplifying the onboarding and scaling of new users.

BMW Group used Pulumi to build a scalable and resilient hybrid cloud implementation that could handle more than eleven thousand developers.

“When we started to use Terraform to deploy our first cloud services with AWS, it didn’t scale quickly enough for our needs. With Pulumi we’re really speeding up development. We can use any language instead of some special language like HCL and by automating policies, we have compliant and secure systems from the beginning.”

–— Jan-Peter Alten, DevOps Engineer

Learn more

Conclusion

When you choose between managing your own backend and using Pulumi Cloud, you need to carefully consider all the costs. You’ll face substantial operational costs with DIY backends, requiring dedicated engineering resources for maintenance, updates, and troubleshooting. Outages and incidents can lead to significant financial losses, as demonstrated by real-world examples where improper state management resulted in major service disruptions. The cost of setup and maintenance for a DIY backend is not just financial but also involves the time and effort of your team, which could otherwise be focused on core business activities.

Moreover, the cost of an engineer dedicated to managing the backend can be nearly 10% of your engineering budget, a significant investment for any organization. Figuring it out on your own adds to the complexity and potential for errors, increasing the risk of costly mistakes. Invisible excess waste in terms of unused or underutilized infrastructure can also accumulate, leading to unnecessary expenses.

When it comes to scaling, the cost of onboarding new teams or users onto a DIY system can be high due to the need for custom documentation, training, and support. Security is another critical area where the costs can escalate, with the need to comply with numerous IT security standards, manage access control, and ensure robust secrets management.

We built Pulumi Cloud as a fully managed service to address these concerns by providing a platform that automates deployments, ensures compliance, and offers comprehensive security features out-of-the-box. You’ll reduce your operational burden, minimize your risk of outages, and make scaling and onboarding easier, ultimately leading to cost savings and increased productivity. By choosing Pulumi Cloud, your organization can focus on innovation and growth rather than the intricacies of IaC backend management. You get to optimize your infrastructure without the overhead of running your own DIY solution.

Next Steps

Each unique variable in your environment –— cloud providers, languages, team structure, business objective, etc. –— makes realizing the full benefits of Pulumi Cloud different for each organization.

Our newly launched program called Immersion Days, is a customizable, half-day event designed to expand Pulumi’s impact across your organization.

The program has 3 key components:

Strategic Leadership Engagement: Address key business challenges like security posture, cost optimization, and developer productivity.
Architectural Review: Evaluate and refine platform engineering projects to enhance efficiency and scalability.
Hands-On Workshops: Equip your engineering teams with practical Pulumi skills through interactive technical sessions.

This program will help strengthen executive buy-in for your infrastructure initiatives while showcasing Pulumi’s value to your peer engineering teams.

If this sounds valuable, let’s discuss tailoring the agenda to fit your organization’s priorities.

Meta image credit: ESO/L. Calçada

Pulumi for AWS: Automate, Secure, and Manage Your Cloud

Aaron Kao — Mon, 02 Dec 2024 09:00:00 +0000

Note: This post discusses Pulumi Copilot, which Pulumi Neo has replaced. Learn about Neo →

Pulumi is excited to be at AWS re:Invent this week, where we’re showcasing our broad and deep support for AWS across all our products. From automating infrastructure with Pulumi IaC to securing secrets with Pulumi ESC to managing cloud assets with Pulumi Insights, Pulumi makes AWS a competitive advantage. Whether you’re a developer, DevOps pro, or platform engineer, Pulumi delivers the tools you need to build and manage modern cloud applications with ease.

Stop by the Pulumi re:Invent booth #370 this week to chat with experts on the Pulumi team. If you can’t make it to re:Invent, join our workshop, Accelerating Platform Engineering with Pulumi on AWS, on December 11, 2024, to see how Pulumi can enhance your cloud operations on AWS.

Why Pulumi for AWS?

Pulumi empowers your organization to automate AWS cloud infrastructure through code, tame secrets sprawl through centralized secrets management, and manage cloud assets and compliance with the help of AI. Pulumi encourages infrastructure, platform, development, DevOps, and security teams to collaborate and accelerates time to market with greater control and minimized risk.

Pulumi will speed up your deployments and time to value, providing you with an approach to open source and community that gives stability and choice. It will also increase your productivity and velocity through better tooling. Lastly, Pulumi uses software engineering to tackle the scale of an infinite combination of cloud architectures. Read more about why engineers and developers switch to Pulumi.

Pulumi for AWS Over the Years

Pulumi was founded back in 2017 to tackle the mounting challenges of modern cloud applications, which have grown increasingly intricate, spanning multiple environments and relying on numerous cloud resources and SaaS services. This complexity creates significant challenges for managing infrastructure. Legacy tools are designed for “two virtual machines with a database” and not thousands or millions of resources across many clouds and accounts. Teams waste time wrestling with excessive YAML configurations, resorting to copy-paste solutions, or using limited domain-specific languages (DSLs) that fail to scale effectively.

The fragmentation between development, infrastructure, and security teams only compounds these challenges. Pulumi’s founding vision addresses these pain points by enabling teams to build and manage cloud infrastructure through infrastructure as code using familiar programming languages and tools. Pulumi Infrastructure as Code (IaC) was launched with strong support of the AWS cloud. We wanted to be the best way for you to manage and scale your AWS infrastructure through code. Over the years, we launched many AWS-specific features to simplify how to manage AWS infrastructure at scale.

Well-Architected AWS Best Practices as a Component

One of the first innovations made for AWS was Pulumi Crosswalk for AWS, a collection of libraries that automatically use well-architected best practices to make common infrastructure-as-code tasks in AWS easier and more secure. Released in 2019, Crosswalk for AWS supports “day one” tasks, such as creating your initial container-based workloads, using Amazon Elastic Container Service (ECS) – including Fargate or Kubernetes (EKS) – and creating serverless workloads using Amazon API Gateway and AWS Lambda. Secure and cost-conscious defaults are chosen so that simple programs automatically use best practices for the underlying infrastructure, enabling better productivity with confidence.

Crosswalk for AWS also supports “day two and beyond” tasks, such as scaling your workload, securing and integrating it with your existing infrastructure, and going to production in multiple complex environments. This includes Amazon Virtual Private Cloud (VPC) for network isolation, AWS Auto Scaling for dynamic scaling, and AWS Identity and Access Management (IAM) for securing your infrastructure.

Earlier this month at KubeCon 2024, we launched the Pulumi Elastic Kubernetes Service (EKS) Provider v3.0.0, which is one of the Crosswalk libraries that makes Kubernetes management on AWS even easier. This release simplifies multi-cluster deployments, improves resource handling, and offers enhanced compatibility with the latest AWS EKS features.

AWS Policies as Code

We released Pulumi CrossGuard to enforce your organization’s cloud governance — security, compliance, cost controls, and more. This enables Policy as Code within your organization so that you can define guardrails for your infrastructure, ensuring engineers are following best practices and putting security first. CrossGuard helps your organization prevent mistakes before they occur and respond rapidly to any incidents.

Building Controls Planes

Many AWS customers build internal developer platforms (IDP) for developers to self-service infrastructure. In 2020, Pulumi Automation API was created to help automate infrastructure for these IDP control planes. Automation API exposes the full power of infrastructure as code through a programmatic interface, instead of through CLI commands, and it lets you use the Pulumi engine as an SDK, enabling you to create software that can create, update, configure, and destroy infrastructure dynamically. This enables you to use Pulumi to build IDPs that are custom-tailored to your team, organization, or customers.

AWS CDK for Pulumi

In 2022, Pulumi brought the ability to use AWS Cloud Development Kit (CDK) constructs from within a Pulumi deployment. For users already using AWS CDK, this provides Pulumi as a new option for orchestrating deployments in place of CloudFormation, offering improved deployment speed and integration with the full set of features of the Pulumi Platform. Even better, you can also now combine AWS CDK and Pulumi resources in a single Pulumi infrastructure as code project - passing outputs from Pulumi resources into AWS CDK constructs, and outputs from AWS CDK constructs into Pulumi resources.

AWS Cloud Development Kit (CDK) on Pulumi is now generally available. This powerful integration includes full support for CDK features like assets, custom resources, aspects, and context values/methods. It provides access to the full ecosystem of over 1,200 CDK Construct libraries, and it also supports all 180+ Pulumi providers, allowing for CDK applications to include resources outside of AWS.

Cloud Control API

In 2021, AWS launched Cloud Control API as a standard set of APIs to Create, Read, Update, Delete, and List (CRUDL) resources across hundreds of AWS Services. Pulumi supported that launch with a native provider called the Pulumi Cloud Control Provider, formerly known as AWS Native. The provider is now generally available, enabling day 1 support for new AWS resources, seamless compatibility with Pulumi IaC projects that currently use the Pulumi AWS provider, and extended support for third-party resources.

Beyond Pulumi IaC

Over the last few years, our customers have shared a clear message: IaC alone is insufficient. The complexities of modern cloud environments demand more than just IaC to manage cloud resources, improve security, and ensure compliance. In response, Pulumi’s offerings have expanded into a comprehensive suite of tools that go beyond IaC.

Pulumi Insights: Intelligent Cloud Management

The complexities of modern cloud environments create significant challenges in making sense of the millions of resources and resource updates per month, across hundreds of clouds, regions, and accounts. Identifying cost saving opportunities is difficult amidst soaring cloud expenditures, and maintaining compliance and security is mission critical because errors can cause catastrophic damage.

Pulumi Insights empowers organizations to tackle cloud complexity by delivering visibility, actionable insights, and AI-assisted optimization for their infrastructure. With Pulumi Insights, companies can scan and sync their entire AWS resource inventory – including resources not managed with Pulumi IaC – ensuring a complete picture of their cloud assets. This Account Discovery capability is now in public preview.

Compliance checks can also be run against standards such as PCI DSS, ISO 27001, and CIS benchmarks, helping maintain regulatory compliance and mitigate risks. The AI-powered Pulumi Copilot provides an interactive assistant to gain visibility into a team’s activity, discover cost saving opportunities, get compliant, and debug cloud failures. Pulumi Insights enables companies to discover, understand, manage, and improve their cloud infrastructure on their journey towards intelligent infrastructure management.

Pulumi ESC: Centralized Secrets Management

Cloud complexity creates significant challenges in managing sensitive credentials, API keys, and configurations across development, testing, and production environments. As organizations scale, they often face issues of secrets and configuration sprawl, duplication of secrets, and too many long-lived static secrets. None of the existing secrets management solutions adequately address these challenges, exposing enterprises to errors that can lead to security breaches, unintended exposure of sensitive data, and unauthorized access to critical resources.

Pulumi ESC addresses these challenges by offering seamless two-way integration – both pull and sync – with AWS Secrets Manager and other popular secrets stores, as well as the capability to consume secrets securely across any application, tool, and CI/CD platform. Developers gain easy, secure access to secrets via CLI, API, Kubernetes operators, and SDKs – eliminating the need for .env files and reducing the security risks associated with them. Additionally, Pulumi ESC can issue dynamic, short-lived AWS authentication tokens on demand via OpenID Connect (OIDC), reducing the risks that come with long-lived access tokens, while RBAC, versioning, and a detailed audit log let you trust (and prove) your secrets are secure.

Try Pulumi Cloud Today

Check out the Pulumi roadmap for upcoming features, let us know your feature requests by creating an issue on GitHub, connect with the Pulumi community on Slack, and if you haven’t yet, sign-up for Pulumi Cloud to get access to our full suite of products – Pulumi IaC, Pulumi ESC, and Pulumi Insights – so you can automate, secure, and manage everything you run in the cloud.

Meta image credit: ESO/M. Zamani

Pulumi + uv: Fast Python Package and Project Management

Adam Gordon Bell — Wed, 27 Nov 2024 12:43:45 +0100

Continuing our work to bring the best of modern Python to Infrastructure as Code, we are excited to announce built-in support for uv in Pulumi. uv is an extremely fast Python package manager that can install dependencies up to 100x faster than traditional tools, providing one of the fastest ways to manage your Python dependencies and virtual environments.

Why uv?

Listen in on this discussion between Adam Gordon Bell and Julien Poissonnier as they discuss Pulumi + uv and why uv is so fast!

uv brings several key advantages to your Python development workflow:

Blazing Fast Performance: Written in Rust, uv can install packages 10-100x faster than pip
Reliable Dependency Resolution: Advanced resolution algorithm ensures consistent environments
Drop-in Replacement: Works seamlessly with existing requirements.txt and pyproject.toml files
Built-in Virtual Environment Management: Simplified environment handling out of the box

Using uv in Pulumi

To use uv to manage your Python virtual environment and dependencies, set the toolchain option to uv in your Pulumi.yaml file:

name: uv-goes-brrrr
runtime:
 name: python
 options:
 toolchain: uv
 virtualenv: .venv

If you have uv installed, you can run pulumi new python and select uv as the toolchain to use for installing dependencies and running the program.

You can find more information on how to use uv in Pulumi in our Python documentation.

DevSecOps Game-Changer: Security Automation That Delivers Business Results

Sara Huddleston — Thu, 21 Nov 2024 07:16:30 +0000

Organizations are under constant pressure to deliver new products and features faster than ever. But speed alone isn’t enough—businesses must also navigate the complex challenges of ensuring security and managing infrastructure costs effectively.

Enter DevSecOps - the strategic integration of security practices into the DevOps workflow. By automating security processes, organizations can achieve improved speed, scalability, and business impact, all while ensuring security remains a priority.

Tivity Health, a leading health and fitness solutions provider, has embraced this DevSecOps approach using Pulumi, a modern infrastructure as code (IaC) platform. During PulumiUP 2024, David Giambruno, Tivity Health’s VP of Engineering and DevOps, shared how, by leveraging Pulumi, he led the transformation that continuously drives remarkable results in speed, cost savings, and security.

On this article:

The Beginning: From Data Center to the Cloud

Tivity Health’s journey began with a strategic decision to transition from a traditional data center environment to a cloud-native architecture. Rather than opting for a “lift and shift” approach, they made the bold choice to go directly to a cloud-native model, embracing the principles of DevSecOps along the way.

The need to automate infrastructure deployment and management was fundamental. Giambruno explained, “If you can’t automate it, we don’t need it.” This philosophy drove the team to seek out a solution that would not only streamline their operations but also empower their developers to focus on building innovative products for their customers.

Embracing Pulumi: The Power of Automation, Productivity, and Security

Tivity Health’s search for the right tool led them to Pulumi, a unified platform for all the infrastructure needs that allows teams to use general programming languages, such as TypeScript, Python, Java, and Go, to define and manage their cloud infrastructure. Giambruno and his team immediately recognized Pulumi’s ability to deliver on their key requirements:

Automation: Pulumi’s infrastructure as code (IaC) approach enabled Tivity Health to automate the deployment and management of its cloud environments, reducing the time and effort required for these tasks.
Productivity: using Pulumi’s general-purpose programming languages allowed developers to define, deploy, and manage infrastructure within their existing tools.
Security: Pulumi’s security features allowed Tivity Health to integrate security practices into its infrastructure deployment processes, reducing the risk of security breaches and ensuring compliance.
Cost Optimization: Pulumi’s ability to automate the spin-up and teardown of cloud environments on demand has led to significant cost reductions for Tivity Health.

Giambruno describes Pulumi as a “three-dimensional” tool, offering a versatile set of capabilities that have been instrumental in transforming Tivity Health’s operations. “The ability to use those dimensions in lots of different ways to do the automation is what really makes a difference to the teams,” he says.

Driving Business Impact Through Security Automation

By adopting Pulumi and DevSecOps automation, Tivity Health realized significant business benefits:

Speed and Agility: By automating its infrastructure deployment and management processes, Tivity Health has dramatically reduced the time required to spin up new environments or change existing ones. “We run it through automation and boom, it’s out, it’s done,” Giambruno says. This newfound speed and agility have empowered Tivity Health’s developers to focus on building products and features rather than getting bogged down in infrastructure-related tasks.
Cost Optimization: Tivity Health’s cloud-native approach and Pulumi’s automation capabilities have resulted in significant cost savings. The company estimates that its annual cloud spend has decreased from $9.5 million in its data center days to just $2 million—a staggering 79% reduction. These cost savings have allowed Tivity Health to redirect resources towards more strategic initiatives that drive business growth.
Improved Security and Compliance: Tivity Health’s DevSecOps strategy, anchored by Pulumi, has strengthened its security posture and compliance efforts. By integrating security directly into its infrastructure workflows, Tivity Health has improved its security posture. Automation ensures that security measures are enforced consistently across their cloud environments, reducing risks and improving compliance.

Fostering DevOps Culture Through Cross-Functional Collaboration

Using Pulumi provided more than technical benefits. It also enabled better collaboration between the development, security, and operations teams. By providing a common language and framework for infrastructure management, Pulumi has helped break down silos and align these traditionally disparate groups towards a shared goal of delivering secure, high-quality products faster.

Lessons Learned: Navigating the Cultural Shift

Transitioning to DevSecOps and cloud-native practices required a cultural shift at Tivity Health. Giambrono acknowledges that this cultural shift was not without its challenges. He emphasizes the importance of addressing the human element of change, offering the following advice for organizations embarking on a similar journey:

Start with a proof of concepts: Giambruno recommends beginning with a small-scale proof of concepts to demonstrate the capabilities and benefits of the new technologies and processes to help alleviate fears and build confidence among team members.
Empower developers and make them feel safe: By involving developers in the process and ensuring they feel comfortable with the new tools and workflows, Tivity Health gained user buy-in and overall support for the new DevSecOps approach.
Secure buy-in from business and financial stakeholders: Address the concerns of business and financial stakeholders early on, such as the impact on costs and the ability to deliver tangible results. This is crucial for securing the necessary support and resources.
Celebrate successes and build momentum: Giambruno highlights the importance of celebrating the team’s achievements along the way, even when there are bumps on the road, as this helps build enthusiasm and keep the momentum going.

The Future of DevSecOps and Pulumi at Tivity Health

As Tivity Health continues to refine its DevSecOps strategy, Giambruno is optimistic about the future. He envisions a world where the company’s ability to deploy new products and features rapidly will give Tivity Health a significant competitive edge, allowing it to better serve its customers and drive business growth.

Looking ahead, Giambruno is particularly enthusiastic about the potential of Pulumi’s AI-powered capabilities, which he believes will further streamline and optimize the company’s infrastructure management processes. “I’m super looking forward to the tests we’re going to do, like when we acquire someone and then taking them in, ‘Borg-ing’ them into our automation and seeing how much we can take out of their operating cost as fast as possible,” he says.

Tivity Health’s journey with Pulumi is a powerful example of how the right tool, DevSecOps strategy, and automation can drive tangible business results. By focusing on automation, security, and collaboration, organizations can achieve faster, cheaper, and better cloud deployments—putting them on the path to long-term success in an increasingly competitive, cloud-native world.

To learn more about Pulumi and how it can transform your software development and infrastructure management:

Get started with Pulumi Tutorials
Attend an upcoming workshop
Try out the Pulumi Neo code assistant to accelerate your infrastructure as code journey

Unified and Programmatic Approach to Infrastructure Management at BMW Using Pulumi

Sara Huddleston — Thu, 03 Oct 2024 09:52:10 +0000

In the ever-evolving world of automotive technology, BMW has been at the forefront of innovation, seamlessly integrating software into the heart of their vehicles. As cars become increasingly complex, with a growing emphasis on connectivity, over-the-air upgrades, and brand-specific user experiences, the need for a robust and scalable software development approach has become paramount.

Enter the BMW Software Factory, a platform that aims to empower the company’s developers and provide them with a superior development experience. At the core of this initiative is the adoption of Pulumi, a modern infrastructure as code (IaC) solution that has transformed the way BMW manages its software ecosystem.

On this article:

The Challenges of a Sprawling Software Landscape

BMW’s software journey has been a testament to the exponential growth of automotive technology. What started with simple engine controllers has evolved into a complex network of electronic control units (ECUs) scattered throughout the vehicle. As the software footprint continues to expand, BMW recognized the need for a unified and efficient approach to software development and deployment.

The company’s initial efforts involved introducing a platform called “Code Craft,” which provided a comprehensive stack of services to support the software development lifecycle. This stack included a GitHub Enterprise application for source code management, a Gerrit system for Android-based developments, a continuous integration (CI) pipeline, artifact stores, build caching, and various other tools and services.

However, as the demand for software-driven features grew, the complexity of managing this sprawling ecosystem became increasingly challenging. BMW found itself grappling with the need to scale its infrastructure, navigate network limitations across multiple data centers, and adapt to the ever-changing landscape of cloud computing.

The Evolution of BMW’s Software Development Toolchain

BMW’s journey to streamline its software development process has been gradual and iterative. The company’s initial approach involved using Ansible for deployment and a custom-built deployment scripting solution for its OpenShift cluster.

As the complexity of the platform increased, BMW turned to Helm and Kubernetes to manage its containerized services. However, as the company ventured into the public cloud, the limitations of these tools became apparent. The team recognized the need for a more comprehensive and scalable solution to manage their infrastructure as code.

At this critical juncture, BMW discovered Pulumi. This modern IaC solution offered a unique advantage – the ability to leverage a full-fledged programming language, Python, to define and manage their infrastructure. This shift proved to be a game-changer, allowing BMW to leverage its expertise in Python and benefit from the rich ecosystem of libraries and tools available in the Python community.

Embracing Pulumi: Streamlining Infrastructure Management

BMW’s adoption of Pulumi was a strategic move that aimed to address the growing complexity of its software ecosystem. By transitioning from a patchwork of tools to a unified IaC solution, the company was able to streamline its infrastructure management and improve developer productivity.

Shared Modules: Promoting Reusability and Best Practices

One of BMW’s key initiatives was developing a shared modules library, which allowed the team to abstract the complexity of various infrastructure components, such as databases, and provide a consistent and user-friendly interface for their developers.

By leveraging Pulumi’s Python bindings, BMW was able to create reusable modules that encapsulated best practices and sensible defaults, making it easier for developers to provision and manage infrastructure resources. BMW used Pydantic, a data validation library, to define schema-based configurations for its infrastructure. These were then integrated into its IDEs, providing developers with auto-completion and validation support.
This approach not only accelerated the development process but also ensured that the infrastructure deployed across the organization adhered to consistent security and compliance standards.

Transformation Features: Protecting Legacy Services

As part of their software factory, BMW also faced the challenge of integrating legacy services that did not natively support modern authentication and authorization mechanisms, such as OpenID Connect (OIDC).
To address this, BMW leveraged Pulumi’s transformation features to seamlessly inject an OAuth2 proxy into their deployments, providing a secure and consistent way to protect these services without requiring extensive modifications to the underlying applications.
By encapsulating this functionality within a shared module, BMW was able to apply the OAuth2 proxy to multiple services, ensuring a consistent and secure access control layer across their software ecosystem.

Policy Enforcement: Ensuring Compliance and Security

One key benefit of Pulumi’s IaC approach is the ability to define and enforce policies across the organization, ensuring that infrastructure deployments adhere to security and compliance standards. BMW has leveraged Pulumi’s policy-as-code capabilities to implement mandatory checks, such as ensuring that all S3 buckets are encrypted at rest, preventing the deployment of non-compliant resources.

By integrating these policy checks into their deployment workflows, BMW has shifted security and compliance concerns to the left, addressing issues early in the development process and reducing the risk of costly post-deployment remediations.

The Benefits of Pulumi: Accelerating Development and Improving Maintainability

BMW’s adoption of Pulumi has yielded significant benefits, transforming the way the company approaches software development and infrastructure management.

Accelerated Development with Shared Modules

The implementation of shared modules has been a game-changer for BMW. It allows developers to leverage pre-built and tested infrastructure components without having to reinvent the wheel. This has resulted in a significant acceleration of the development process, as teams can focus on building their applications rather than grappling with the complexities of infrastructure provisioning.

Improved Maintainability and Consistency

By centralizing infrastructure management within the shared modules, BMW has ensured that best practices and security standards are consistently applied across the organization. This has not only improved the overall maintainability of the software ecosystem but has also reduced the risk of security and compliance violations.

Leveraging Python’s Ecosystem

BMW’s decision to leverage Pulumi’s Python bindings has been a strategic advantage, as the company was able to tap into the rich ecosystem of Python libraries and tools. This has enabled the team to seamlessly integrate Pulumi with their existing Python-based toolchain, including dependency management, testing frameworks, and code quality tools, further enhancing the development experience.

Streamlined Cloud Migration

As BMW continues to expand its use of public cloud services, Pulumi has played a crucial role in simplifying the migration process. By providing a consistent IaC approach across on-premises and cloud environments, Pulumi has enabled BMW to manage its infrastructure in a unified manner, reducing the complexity and overhead associated with multi-cloud deployments.

The Future of BMW’s Software Factory: Embracing the Cloud

Looking ahead, BMW’s Software Factory is poised to take the next step in its evolution, with plans to transition away from the self-hosted backend and embrace cloud-native services. This strategic move aims to further improve developer productivity and reduce the internal effort required to maintain the underlying infrastructure.

By leveraging the expertise and reliability of cloud service providers, BMW can focus on delivering innovative software features to their customers while the cloud providers handle the operational aspects of running the necessary services.

As BMW continues to push the boundaries of automotive software, Pulumi’s role in its Software Factory will only become more crucial. By providing a scalable and flexible IaC solution, Pulumi empowers BMW’s developers to innovate with confidence and be secure in the knowledge that their infrastructure is managed consistently and in alignment with the company’s security and compliance standards.

Conclusion: Unlocking the Future of Automotive Software

BMW’s journey with Pulumi in the Software Factory showcases the power of modern IaC solutions in navigating the complexities of the automotive software landscape. By embracing a unified and programmatic approach to infrastructure management, BMW has accelerated development, improved maintainability, and ensured compliance across its sprawling software ecosystem.

As the automotive industry continues to evolve, with cars becoming increasingly software-driven, the lessons learned by BMW can serve as a blueprint for other organizations looking to streamline their software development and deployment processes. By leveraging the capabilities of Pulumi and other cutting-edge technologies, the future of automotive software is poised to be more efficient, secure, and responsive to the ever-changing needs of both manufacturers and consumers.

To learn more about Pulumi and how it can transform your software development and infrastructure management:

Get started with Pulumi Tutorials
Attend an upcoming workshop
Try out the Pulumi Neo code assistant to accelerate your infrastructure as code journey

Pulumi - Automate, Secure, and Manage Everything You Run in the Cloud

Joe Duffy — Wed, 18 Sep 2024 09:00:00 +0000

Note: This post discusses Pulumi Copilot, which Pulumi Neo has replaced. Learn about Neo →

At our fourth annual PulumiUP conference, we unveiled a new vision for Pulumi, going beyond infrastructure as code to a comprehensive product suite. Pulumi’s platform now consists of three core products: Pulumi IaC is open source infrastructure as code in any programming language; Pulumi ESC is centralized secrets management that scales; and Pulumi Insights delivers instant visibility, intelligence, and control over all of your infrastructure. Each product can be adopted independently but is better together. In this post, we will share more about how Pulumi is your trusted partner to automate, secure, and manage everything you run in the cloud.

Pulumi - One Unified Platform For All Your Infrastructure Needs

The Pulumi platform solves a broad set of problems that engineering leaders face in the modern cloud era. This spans cloud automation, security, and management, which aligns to our three products: Pulumi IaC, Pulumi ESC, and Pulumi Insights. Our unified approach ensures developers, infrastructure experts, and security teams can collaborate closely and ship faster with high confidence.

In addition to our three products, Pulumi’s platform incorporates three core capabilities that span the entire product suite. Pulumi CrossGuard is our policy as code engine which ensures security, compliance, and best practices; Pulumi Deployments is our deployment workflow technology that lets us orchestrate infrastructure-oriented tasks; and Pulumi Copilot is our generative AI technology that deeply understands the cloud and infrastructure management and operations.

You can see this visually depicted here:

We’ve now worked with 3,000 customers to help with their cloud journey and have listened to and solved the problems we regularly hear about. That includes Nvidia who is at the forefront of the AI revolution as well as BMW who is reimagining their entire engineering mindset in a cloud-first world, both leveraging Pulumi. Unity Games now ships 5x faster from code to cloud, and Tivity Health saved 71% of their cloud spend, automating everything and saving $6.5M annually.

Now let’s dive into the three products and what we announced at PulumiUP:

Pulumi IaC - Infrastructure as Code in Any Programming Language

Pulumi IaC is our flagship open source technology, and it powers virtually everything we do, even the new products. We have seen accelerated adoption of Pulumi IaC. We’ve had over 100M downloads, are about to crack 21K GitHub stars (give us a star and bump us over!), and have seen 167% the contributions of Terraform this past month and 300% of OpenTofu. Not only is Pulumi the most powerful IaC technology, it is becoming more popular and vibrant too.

We are always improving Pulumi IaC and today is no different. We launched a number of new and exciting IaC features. That includes using any Terraform provider, beyond the nearly 200 providers that Pulumi already supports. We also shipped a new Pulumi VS Code Extension that enables rich debugging and easier editing of your IaC programs. Pulumi Copilot can now diagnose and fix your IaC errors. And finally, we’ve improved our Kubernetes support with powerful controls over await logic for more robust cloud native deployments. And we’re not slowing down anytime soon.

Pulumi is open source, of course, but works best with Pulumi Cloud, the easiest, most secure, and most reliable way to adopt Pulumi IaC. Starburst saved 100 days per year by moving from DIY state management to Pulumi Cloud. By using Pulumi Cloud, you also gain access to the other products in this post. Try IaC now and choose the option that suits you best.

Pulumi ESC - Centralized Secrets Management and Orchestration that Scales

Pulumi ESC is a new approach to secrets and configuration management that is scalable, secure automatically with easy dynamic credentials, and tames sprawl with engineering best practices. ESC is not just a feature of our IaC product — it can be adopted entirely independently of it for application and infrastructure secrets. We initially launched ESC in preview nearly a year ago, and since then have had hundreds of customers and thousands of users try it out – many at production scale – who have given us amazing feedback. We are excited to announce that ESC is generally available.

Being generally available is a big deal to us, and means it is ready for robust and secure enterprise-grade workloads. New capabilities available at GA include a new projects system which lets you group your environments into familiar hierarchies. We have added versioning, tagging, and pinning, so that you can institute more robust change management practices. ESC can manage encrypted secrets directly, but we have always supported pulling secrets from other secret stores, like AWS Secrets Manager, Azure KeyVault, Google Secret Manager, and HashiCorp Vault. We have now added 1Password to the list. We now also support secrets sync, which lets you still edit your secrets straight from Pulumi ESC, but have them automatically mirrored back to the backing secrets store. Flexible webhooks now support custom workflows triggered by environment changes. The new Pulumi VS Code Extension helps you edit your environments in code. We’ve launched application SDKs for Node.js, Python, and Go, as well as a Kubernetes Operator to inject secrets into Kubernetes workloads.

We aim for you to “fall into the pit of success” with security, so that it is built-in and automatic, and ESC is a major enabler of that. Try out ESC now, or read more in the launch post.

Pulumi Insights - Visibility, Intelligence, and Controls Over All Infrastructure

Pulumi Insights already delivers visibility, intelligence, and controls over your infrastructure resources. We began with Insights a year and a half ago as a collection of IaC features. We added resource search with structured and natural language search syntax, to help you find your IaC infrastructure no matter where it is running. We added the ability to export your infrastructure data and slice and dice it from data tools like Snowflake. We also added new dashboards to help visualize your infrastructure at scale.

The big news with Pulumi Insights 2.0 is that we’re bringing these capabilities to all of your cloud infrastructure, no matter where it is, and no matter how it was created. You point Pulumi at your cloud accounts for any of nearly 200 supported clouds, and you get an instant asset inventory of everything you have. This is true even for resources created by Terraform, CloudFormation, Azure Resource Manager, cloud CLIs and SDKs, or even by clicking in your cloud console. An improved resource view gives you pivot-table-like capabilities so you can understand everything you have, and new graph visualizations with inferred dependencies help you to make sense of how things relate. Search and Pulumi Copilot work over discovered cloud resources, letting you explore and ask questions interactively. Pulumi Insights leverages Pulumi CrossGuard, our policy as code technology, and can tap into any existing IaC policies to find issues pertaining to security, compliance, cost, and best practices. Pulumi’s compliance-ready policy packs just work. Insights can also leverage CrossGuard’s ability to automate remediations so that Insights not only tells you about your issues, but helps you fix them with the click of a button. Finally, Insights is better together with Pulumi IaC, and enables you to migrate any resources in the cloud to Pulumi IaC – improving the robustness and built-in security of your operations – with a fully interactive import experience.

This marks the start of an ambitious long-term vision for Pulumi Insights. Some of what was announced is actively shipping while other pieces will ship in the coming weeks. Learn more in the launch blog and, get started with Pulumi Insights 2.0.

Thank You

I am incredibly thankful to our community, 3,000 customers, and the partners and speakers who made PulumiUP 2024 a reality. Your feedback and continued belief in Pulumi has fueled the innovations we’re shipping today and into the future.

All of the talks are streaming live here and will be up on YouTube afterwards.

We can’t wait to hear what you think about the new vision for Pulumi’s platform as well as the new IaC, ESC, and Insights capabilities announced at PulumiUP 2024. As always, you can try Pulumi for free here.

Happy cloud spelunking.

-Joe

PulumiUP 2024: Dive Into the Future of Cloud, Platform Engineering, and AI/ML

Sara Huddleston — Wed, 11 Sep 2024 07:04:40 +0000

PulumiUP 2024 is just around the corner! It will be held on September 18th, starting at 8 AM PT | 15:00 UTC +0, and with over 5,500 engineers from all over the world already registered, this is shaping up to be the must-attend event for cloud professionals, platform engineers, and AI/ML enthusiasts alike. From entry-level engineers to tech executives, this event brings together professionals from companies of all sizes to explore the latest innovations and best practices in Cloud and IaC, Platform Engineering & DevOps, and AI/ML.

If you haven’t registered yet, now’s the time! Start building your schedule today, select the talks you want to watch live and on-demand and add them to your schedule.

PulumiUP at Glance

Main Track: Keynote, Cloud Culture Talks, and More

In the Main Track, you’ll hear directly from the Pulumi leadership team about exciting product innovations. Don’t miss the Cloud Culture talks focused on the human side of technology and collaboration.

Keynote and New Product Announcements - Joe Duffy (Co-founder and CEO), Luke Hoban (CTO), and other key Pulumi leaders will unveil new products and innovations shaping the next wave of cloud development. Expect to see live demos showcasing how these tools can revolutionize your workflows, from cloud infrastructure to security automation.
"Why Care About Building a Cloud Center of Excellence?" - Alex Radu (VP Product & Marketing Manager, Public Cloud, J.P. Morgan) discusses why building a Cloud Center of Excellence is essential for long-term cloud strategy success.
"What Is ‘HugOps’ and Why Is It Important?" - Rees Pozzi (Senior Platform Engineer, Kainos) explores the meaning and importance of “HugOps,” a practice promoting empathy and collaboration in the tech world but also by all those impacted by it.

AI/ML Track Highlights

Panel: AI for Cloud Development

AI is transforming how we approach development and infrastructure, and PulumiUP offers an incredible lineup of talks and panels on the topic.

"Data Privacy Challenges with Large Language Models" - Aditi Godbole (Data Science, AI & ML Leader, SAP) will address the critical question of managing data privacy, addressing LLM basics, AI data privacy fundamentals, and specific privacy issues in LLMs.
"Pulumi Powered AI/ML on Kubernetes" - Jason Smith (App Modernization Specialist, Google Cloud) will show you how to serve an open-source LLM with a RAG on Kubernetes and set up a Kubernetes environment for AI/ML workloads with Pulumi.
"AI Tools for Developers" - Jim Clark (Principal Software Engineer, Docker) will explore how Tools can enhance the capabilities of AI assistants and show how the combination of AI, Tools, and containerized runtimes, can enhance interactions between developers and their tools.
"The AI Governance Challenge" - Patty O’Callaghan (Technical Director, Charles River) will explore the complexities of AI governance and how to navigate them.
Panel Discussion: “AI for Cloud Development” - Luke Hoban (CTO, Pulumi), Phillip Carter (Principal Product Manager, Honeycomb), Giri Sreenivas (CPO, Docker), Clare Liguori (Senior Principal Software Engineer, AWS) and Meagan Cojocar (Principal Product Manager, Pulumi) will provide diverse perspectives on how AI is shaping cloud infrastructure.

Platform Engineering and DevOps Track Highlights

Panel: Secrets and Policies—Automating Cybersecurity

The Platform Engineering & DevOps track at PulumiUP is perfect for anyone looking to automate infrastructure, secure their systems, and scale their environments with ease. This track features talks and panels on cutting-edge technologies and practices.

"Moving Mountains: How IaC Unlocks Massive Refactoring Possibilities" - Shaun Verch (Infrastructure Engineer, Oso) will show you how infrastructure as code can transform large-scale refactoring projects.
"Using Pulumi to Empower Kubernetes Fleet Management" - Blake Romano (Senior Software Engineer, Imagine Learning) will show you how Imagine Learning leverages Pulumi to manage a fleet of Kubernetes clusters and other platform resources quickly and reliably, and how it revolutionized their workflow.
"Streamline Your Infrastructure Deployment with GitOps and Pulumi Operator" - Sam Cogan (Solutions Architect & Azure MVP, WTW) will highlight how you can define your infrastructure in Git, and have Pulumi automatically reconcile it into deployed infrastructure.
"Is This a Platform? Platform Engineering Before PMF" - Jk Jensen (Team Lead, Staff Software Engineer, MystenLabs) will share how they built their service platform around Pulumi to help engineers and researchers move from prototypes to deployed environments, enabling their teams to iterate more quickly and develop an increasing number of systems without additional complexity.
"Security Automation—Faster. Cheaper. Better." - David Giambruno (VP of Engineering and DevOps, Tivity Health) and Joe Duffy (Founder/CEO, Pulumi) will discuss security automation and how these efforts impacted speed and agility, cost optimization and improved security and compliance.
"Meet Devs Where They Are: Why IaC Must Be Real Code" - Jeremy Adams (Head of Ecosystems, Dagger) will present why real code (that teams already use for applications) is essential for both IaC and CI/CD pipelines, and to meet modern DevOps best practices.
"Security of IaC Pipelines and Infrastructure Governance With Policies-As-Code" - Marina Novikova (Senior Partner Solutions Architect, AWS) and Andy Taylor (Senior Networking Specialist/ Solutions Architect, AWS) will explore security best practices for IaC pipelines and infrastructure governance using policies-as-code, cover best practices for handling sensitive information like access keys, tokens and encryption keys, and scaling and automating your DevSecOps.
Panel Discussion: “Secrets and Policies—Automating Cybersecurity” - Arun Loganathan (Senior Product Manager, Pulumi), Maya Kaczorowski (PM of Security), Jason Meller (VP, Product, 1Password), and Ofir Cohen (CTO, Container Security, Wiz) will explore the intersection of innovation and security, offering insights into how AI is reshaping the threat landscape and how organizations can stay ahead.

Cloud and IaC Track Highlights

Panel: Infrastructure as Code - Can we do better?

The Cloud and IaC track is ideal for those wanting to deepen their understanding of infrastructure as code and its impact on modern cloud computing. Learn from industry pioneers and see where the future of IaC is headed.

"From CDK to Pulumi: Evolution of SST" - Dax Raad (Founding Engineer, SST) and Jay V (Founder, SST) will share insights into the early development of their product, initially built on AWS Cloud Development Kit (CDK), the challenges they encountered and the groundbreaking decision to transition to Pulumi.
"Unified Software Development at BMW Software Factory with Pulumi" - Jan-Peter Alten (Expert Software Engineer, DevOps, BMW Group) will showcase how BMW uses Pulumi to unify their software development processes, resulting in an increase in developer productivity, streamlined infrastructure management, and enhanced scalability, security, and compliance across their complex software ecosystem.
"Stacking Accounts: Multi-Account Deployments in a Single Stack for Monitoring, Management, and More" - Denis Willett (Software Engineer, North Carolina Institute for Climate Studies) will explain how they use Pulumi for managing 60+PB of environmental data across AWS, GCP, and Azure and leverage multi-account deployments in a single stack via the Pulumi Automation API.
"Industrialize the Configuration of Your GitHub Repositories With IaC" - Alexandre Nédélec (Software Engineer, Avanade) will live code using the GitHub, Azure native, and Azure AD Pulumi providers to create a GitHub repository and configure its pipeline to deploy to Azure using OpenID Connect.
Panel Discussion: “Infrastructure as Code — Can We Do Better?” - Joe Duffy (Co-Founder and CEO, Pulumi), Brian Grant (CTO, Stealth), Elad Ben-Israel (Co-Founder and CEO, Winglang), Adam Jacob (Co-Founder and CEO, System Initiative), and Luke Hoban (CTO, Pulumi) will discuss the past, the present, and the future of Infrastructure as Code and the overall infrastructure technologies.

Workshops and Hands-On Learning

Want to get hands-on experience? Our live workshops are designed to deepen your understanding of trending topics, Pulumi, and its applications.

"Managing Team Secrets with 1Password & Pulumi ESC" on September 25, led by Phil Johnston (1Password) and Diana Esteves (Pulumi).
"Securing IaC Pipelines in Regulated Industries" on September 26, led by Josh Kodroff (Pulumi) and Marina Novikova (AWS).
"Deploy Tailscale infrastructure in AWS with Pulumi" on October 15, led by Diana Esteves (Pulumi) and Lee Briggs (Tailscale).
"Observability as Code for AI Apps with New Relic and Pulumi" on October 30, led by Diana Esteves (Pulumi) and Harry Kimpel (New Relic).

Amazing Partners and Sponsors

Thank you to our amazing customers, sponsors, and partners for supporting PulumiUP!

AWS The world’s most comprehensive and broadly adopted cloud, offering over 200 fully featured services from data centers globally.
Google Cloud Help developers build quickly, securely, and cost effectively with the next generation of modern infrastructure designed to meet specific workload and industry needs.
New Relic Data for engineers to monitor, debug, and improve their entire stack.
Docker Accelerate how you build, share, and run applications.
1Password Streamline how you manage SSH keys, API tokens, and other infrastructure secrets throughout the entire software development life cycle.
Tailscale Make creating software-defined networks easy: securely connecting users, services, and devices.
Pinecone Build remarkable GenAI applications fast, with lower cost, better performance, and greater ease of use at any scale.
Wiz Secure everything you build and run in the cloud.
Honeycomb Observability that helps solve problems you couldn’t before.
Mysten Labs Building critical infrastructure to enable a more decentralized internet.
Imagine Learning Empowering educators to inspire breakthrough moments in every student’s unique learning journey with digital-first, K–12 education solutions.
Dagger Powerful, programmable open source CI/CD engine that runs your pipelines in containers.
Oso Authorization as a service.

Build Your Schedule Now

With so many compelling topics across AI/ML, Platform Engineering, DevOps, and Cloud and IaC, now is the time to build your PulumiUP schedule. Select the sessions that match your goals and interests to maximize your experience. Plus, you’ll receive a link to watch your chosen panel discussions and tech talks on-demand!

Haven’t registered yet? It’s not too late! Join 5,500 engineers worldwide in this groundbreaking event and gain the insights you need to drive innovation at your company. Register now->

We can’t wait to see you there!

Why Switch to Pulumi for Infrastructure as Code?

Aaron Kao — Tue, 23 Jul 2024 19:47:50 -0700

Note: This post discusses Pulumi Copilot, which Pulumi Neo has replaced. Learn about Neo →

The cloud promised to revolutionize your business.

Faster innovation. Lower costs. Unlimited scalability.

But for many companies, that promise remains frustratingly out of reach. Instead of accelerating product development, infrastructure has become a bottleneck. You and your team (DevOps, platform, or infrastructure engineering teams) are bogged down by:

Clunky tools and manual processes
Provisioning a simple test environment takes days
Rolling out updates across regions takes weeks
The combinations of modern cloud architectures seems infinite

You know there has to be a better way. A way to truly harness the power of the cloud and turn it into your competitive advantage.

But how?

Enter Pulumi – the open source infrastructure as code (IaC) platform that gives 10x better scale, productivity, and time to value for thousands of companies worldwide.

So why should you switch to Pulumi? How is it different from other infrastructure as code tools? This post should answer all those questions.

What is Pulumi?

Pulumi is an infrastructure as code platform that allows you to manage and scale infrastructure, configurations, policies, and secrets with programming languages. Pulumi facilitates clear collaboration across your infrastructure, development, and security teams.

Pulumi’s approach is better.

10x Better. Pulumi takes a unique and 10x better approach to infrastructure as code by empowering you with the familiar languages and tools you love for application development. While modern programming languages have evolved to provide powerful features like AI copilots, Intellisense, linting tools, testing frameworks, and CICD pipelines, infrastructure management has lagged behind, relying on rigid scripting languages and error-prone manual processes. Pulumi bridges this gap by allowing you to use industry-standard programming languages to manage infrastructure with the same level of sophistication and tooling you enjoy for application development. Pulumi embraces the change and direction the industry is going, so you never fall behind with your IaC tooling.

Powering the Next Wave. Pulumi is at the forefront of the industry. It helps you embrace the latest practices (e.g., Platform Engineering, GitOps) and builds the latest technologies (e.g., AI Copilots) into the core user experience. It also helps you build and manage new technology paradigms (e.g., AI workloads, LLMs, internal developer platforms).

Powerful Automations. Another unique approach is that Pulumi makes it easy to automate and scale modern cloud architectures. In the last decade, the industry has moved from monolithic to microservices architectures, which operate as distributed systems over shared infrastructure platforms, to achieve greater resilience, team agility, flexible scaling, and modular codebases. The cloud's programmability, infinite elasticity, and on-demand nature made it easy to spin up micro-sized services tailored to business demands, facilitated by technologies like containers, Kubernetes, and serverless. Pulumi empowers you to apply software engineering to manage infrastructure of this modern and immense scale.

AI-Powered. Pulumi builds AI into the core infrastructure management experience. Pulumi combines the power of large language models with semantic understanding of the cloud to unlock greater insights and controls over managing cloud infrastructure. Pulumi leverages the familiar GPT experience you know, love, and use daily, so you can find and take action on any resource in your cloud environments.

Ok, but why does this matter enough for me to switch?

Only you can answer that question, but there are some compelling reasons to adopt the platform trusted by hundreds of thousands of developers.

Faster Time to Value. Your company moved to the cloud to increase innovation and reduce costs. However, getting infrastructure to developers is a frequent bottleneck for you which can slow down prototyping new products or shipping new features. Spinning up new development or testing environments takes days and rolling out production updates across many regions can take weeks. The existing tools don’t allow you to set security and compliance guardrails and enable easy self-service of infrastructure.

Pulumi will speed up your deployments and time to value.

Open Platform Commitment. Some platforms, such as Terraform, have altered their licensing and introduced uncertainty. They are no longer true open source, and they tie their previously open source software to their commercial services. The lack of an open source approach fragments the community and introduces proprietary constraints to cloud infrastructure.

Pulumi provides you with an approach to open source and community that provides stability and choice.

Increased Productivity. You expect your tools and workflows to keep up with the industry: AI copilots, Intellisense, linting tools, testing frameworks, and CICD pipelines. But most of these innovations are just for building applications and services and not for infrastructure, configurations, policies, and secrets. Existing infrastructure tools are fraught with bad UX, rigid scripting languages, and error prone manual processes.

Pulumi will increase your productivity and velocity through better tooling.

Infinite Scale. Modern cloud architectures are distributed systems that are microservices that are dynamic and ephemeral in nature. The number of infrastructure resource types and the configurable input properties is staggering. You face the daunting task of how to combine these resources to solve their unique problems. Without software engineering, managing these modern distributed systems is fruitlessly manual.

Pulumi uses software engineering to tackle the scale of infinite combinations.

Customers of Pulumi frequently experience 100% productivity increases, 99% time saved, and 10x acceleration when using Pulumi compared to what they were using before.

Frequently Asked Questions - Why Pulumi?

Here are some frequently asked questions about why you should choose Pulumi based on the following use cases and alternatives:

Why Pulumi, by use case?
- Why Pulumi for Internal Developer Platforms?
- Why Pulumi for AI Workloads?
Why is Pulumi better than the alternatives?
How can I switch to Pulumi?

Why Pulumi, by use case?

There are many different use cases for why you might use Pulumi: infrastructure CICD, modern applications, internal developer platforms, AI/ML workloads, and infrastructure modernization. Below are more details on two popular use cases.

Why Pulumi for Internal Developer Platforms?

You and your team may build internal developer platforms (IDPs) to maximize the use of the cloud at scale across the company while being secure and compliant, so your development teams can ship faster. There are a number of components/layers that are considered basic requirements when building an internal developer platform. The layers are as follows:

Developer Control Plane. Curated experiences that empower developers by meeting them at their level of expertise, whether it's an abstracted developer portal, custom CLI, or shared IaC templates.
Integration & Delivery. Automations to version control, test, trace, and deploy all infrastructure from resources, configurations, environments, and secrets as well as orchestration automations to manage provisioning workflows.
Monitoring & Logging. Components to log, monitor, and observe all infrastructure for greater operational control as well as optimize against unnecessary costs.
Security & Identity. Security and compliance guardrails that regulate every piece of infrastructure from policies to fine-grained access controls to secrets.
Resources. Providers that support modern cloud architectures such as Kubernetes, containers, serverless, generative AI, machine learning, data lakes, hybrid cloud/on-premises, and more.

This diagram illustrates the different layers of an internal developer platform:

Most solutions struggle to keep up with the requirements of each layer. Many of the alternative solutions can’t handle the scale of resources you need to manage, find it difficult to tie infrastructure automation directly into your core business, have leaky secrets, and enforce compliance and security incompletely.

Pulumi is a platform engineering solution that enables you to build a bridge to your developers and empower them to leverage the cloud with security, scalability, repeatability, and consistency. It provides the building blocks for each of the five layers.

Developer Control Plane. Pulumi is the simplest and most intuitive way to manage cloud infrastructure because of its ability to use standard programming languages, including YAML. This removes the friction to the basic requirements of managing cloud infrastructure well. Pulumi Automation API makes it simple to code any user interface for a developer portal / CLI. Pulumi also provides private templates that integrate with developer portals like AWS Proton and Backstage.
Integration & Delivery. Pulumi Automation API can embed IaC programs directly in applications, resulting in 10x greater management of resources per engineer. Pulumi can take advantage of all existing testing frameworks supported by the selected programming language.
Monitoring & Logging. Pulumi Insights adds advanced search, analytics, and AI to any cloud infrastructure, giving unique insights into cloud usage and cost optimizations. Pulumi partners with leading observability solutions making it easy to manage monitoring and logging resources through IaC.
Security & Identity. Pulumi CrossGuard provides policy as code with auto-remediation. Pulumi ESC makes it easy to manage secrets and configurations for every environment. Access to each cloud resource and secret can be granularly controlled and audited.
Resources. Pulumi supports modern cloud architectures such as Kubernetes, containers, serverless, generative AI, machine learning, data lakes, hybrid cloud/on-premises, and more. Pulumi makes it simple to create components that abstract away the complexity of managing thousands of resources across hundreds of distinct clouds.

Pulumi is purpose built to make all aspects of platform engineering vastly simpler.

Why Pulumi for AI Workloads?

Your company may be using AI to increase innovation and reduce costs. AI gives them the ability to design richer and more intuitive interfaces for their products and/or services to connect better with their customers. The hardest part of AI is at times not the AI pieces but the cloud infrastructure parts: how to provision and manage the infrastructure that AI workloads run on (e.g., compute and networking) and depend on (e.g., databases and storage).

There are many layers to building and managing AI applications: model training, data pipelines, backend services, frontend applications.

Pulumi provides an abstraction across all the different layers of the AI stack (web framework, LLM, containers, databases, secrets, policies, configurations, etc) as a simple Python library. Through this abstraction you can manage stacks of AI infrastructure as code.

Pulumi makes it trivial to take local AI development to production in the cloud.

Why is Pulumi better than the alternatives?

There are many different tools you can use to manage infrastructure. However, Pulumi provides you with a more productive authoring experience and more powerful automations that will allow you to ship faster and manage the infinite scale of cloud infrastructure. Read on for how Pulumi compares to specific options: clickops, Terraform, CDK, and IDP services.

Why Pulumi vs. clickops?

Manually provisioning and managing infrastructure for production via the cloud console (i.e., clickops) is a bad idea. There isn’t repeatability or consistency which leads to errors, and that can lead to downtime or worse, security breaches. That is why infrastructure as code was invented as a way to have a single source of truth for all infrastructure with changes 100% automated.

If you don’t believe this, just ask any cloud or devops subreddit, Slack group, or Discord server.

Why Pulumi vs. Terraform?

Pulumi and Terraform are both infrastructure as code (IaC) platforms, however they have fundamental differences in how they approach your needs of infrastructure management. First, here are the similarities.

Both Pulumi and Terraform include the ability to create, deploy, and manage infrastructure as code on any cloud. Both Terraform and Pulumi follow a desired state infrastructure as code model, where the IaC code represents the desired state of the infrastructure. The deployment engine compares this desired state with the current state of the stack and determines the necessary actions, such as creating, updating, or deleting resources. Both Terraform and Pulumi support many cloud providers, including AWS, Azure, and Google Cloud, plus other services like CloudFlare, Digital Ocean, and more.

However, beyond the basics of infrastructure as code there are significant differences that affect productivity, scalability, and collaboration.

Increased Productivity. As discussed at the beginning, Pulumi’s promise is to build in all the latest advancements in both the developer and operations experience. When you write Pulumi code, you now have AI copilots that can pair program with you, IDEs that have autocompletion and Intellisense squiggles, powerful libraries of low level and abstract functions, testing frameworks, code review tools, automated release controls via CICD pipelines, and great software packaging tools. When it comes to managing infrastructure with Pulumi, you also have Pulumi Copilot which combines the best generative AI models available in the industry today with access to your data and actions within Pulumi Cloud. Pulumi Copilot incorporates the context of where you are in the Pulumi Cloud console to easily answer questions about “this stack” or “the latest update” as well as automating cloud tasks. Terraform, on the other hand, has built a proprietary ecosystem that doesn’t tap into the latest advancements of how code is written or how infrastructure is managed.
Greater Scalability. Pulumi embraces software engineering as a way to solve and manage the exponentially increasing complexity of modern architectures. Programming languages with their loops, conditional logic, class inheritance, object orientedness allows engineers to design more complex and sophisticated infrastructure compared to using HCL. Pulumi also allows you to build custom workflows atop infrastructure programs, giving rise to event-driven automations or internal developer portals that provide self-service.
Better Collaboration. Pulumi makes it easy to prototype new products and quickly ship them into production because it is easier for the platform, development, and security teams to collaborate. You (platform engineering and devops teams) can define and manage common infrastructure across the company, work with the security teams to set security and compliance guardrails, and enable easy self-service of infrastructure whether through custom developer platforms or shared infrastructure libraries. To define common company-wide components, if you don’t want to program can use use YAML; if you do, you can use Python, TypeScript, Golang, C#, etc. These components can be consumed by the development team in their own IaC program in any programming language with the development tools they already know. It's easy to start with YAML and move to other languages when more power is desired. With Terraform, you must understand and use HCL. It is difficult to build self-service infrastructure platforms because it lacks the programmability and ability to apply software engineering. It's just harder to bring together platform, development, and security teams and empower them with tools that work. Whereas Pulumi unblocks infrastructure as the bottleneck for software delivery.

Why Pulumi vs. AWS Cloud Development Kit (CDK)?

Pulumi and CDK are similar in that both allow you to use programming languages to write infrastructure as code. However, there are some key differences:

No Vendor Lock-In. CDK supports only AWS, whereas Pulumi supports over 150 cloud and SaaS providers, with more being added all the time. CDK depends on CloudFormation as the deployment engine; it shares many of the same benefits and limitations as CloudFormation (see Pulumi vs. CloudFormation)
Execution > Translation. Pulumi and CDK support similar programming languages but differ fundamentally in their deployment approaches. Pulumi's engine directly understands these languages and communicates with cloud providers. In contrast, CDK transpiles code into AWS Cloud Assembly, an intermediate format consisting of CloudFormation templates and other assets, before deployment via CloudFormation. This difference impacts your development speed and correctness. CDK's approach can lead to slower deployments and delayed error discovery, potentially hours into the process since the errors aren’t caught during compile time. Additionally, you need expertise in both CloudFormation and CDK for effective debugging and successful deployments, whereas Pulumi's direct approach simplifies this process.
Versatility. CDK and Pulumi both support automated testing, but Pulumi offers more versatile options. While both allow unit testing, Pulumi's deep integration between language and runtime enables fast, offline tests (in-memory) with mocked cloud provider calls. In contrast, CDK only permits assertions against synthesized CloudFormation templates and lacks offline testing capabilities. This makes Pulumi's testing approach more comprehensive and flexible than CDK's.

Why Pulumi vs. 3rd party internal developer portal providers?

There are many third party providers of internal developer portals (think Port, Cortex, Backstage). Some are services and others are open source software. These providers are similar in that they offer simple developer portals that are a single part of a greater infrastructure management platform.

As discussed earlier, internal developer platforms have five layers: developer control plane, integration & delivery, monitoring & logging, resources management, and security & identity. Most of these providers offer easy to use GUI consoles, simple CICD integrations, comprehensive suite of monitoring & logging, and some form of role-based access controls. However, they lack the infrastructure as code fundamentals and automation capabilities that Pulumi has, which enable you to build powerful customizations through software engineering. Many of these solutions also lack strong secrets management and policy enforcement capabilities that are critical for production and enterprise deployments.

That said, if you need an off the shelf solution, then one of these services or software might be a good choice for you. Some of these solutions can integrate with Pulumi, and if your needs become more complex, you can always switch to Pulumi later.

Have a particular Pulumi vs X comparison that you need thoughts on? Feel free to join the Pulumi Community Slack if you have quick technical questions, or talk to a Solutions Architect if you need more detailed consultation about your specific architecture.

How can I switch to Pulumi?

Switching to Pulumi doesn’t have to be intimidating. We’ve done this with thousands of customers before, and we can guide you through it.

We provide self-service conversion tools that allow you to Import infrastructure no matter how it was provisioned, click-ops included. You can also use tools to convert your HashiCorp Terraform, AWS CloudFormation, Azure Resource Manager (ARM) templates, or Kubernetes YAML.

Self-service Tool Guide

If you need help, we have a team of cloud experts who can answer your questions, give you a demo, or roll up their sleeves to get your migration done.

Contact Expert Services

We have done lots of migrations from all types of infrastructure as code tools, and we are happy to help you think through how to make switching to Pulumi as easy as possible.

Switch to Pulumi

Meta image credit: ESO/M. Kornmesser