Generated banner for Pulumi Automation API
Generated logo for Pulumi Automation API

Pulumi Automation API

PulumiOfficialPublished by Pulumi

  • Skill
  • Tool integration
  • Cloud and DevOps
  • Apache-2.0
  • No issues found

From the author

Load this skill when a user asks how to run Pulumi programmatically, embed Pulumi in an application, orchestrate multiple stacks in code, build a self-service infrastructure portal, replace pulumi CLI shell scripts with code, or use the Pulumi Automation API (LocalWorkspace, createOrSelectStack, inline programs). Also load for questions about multi-stack sequencing, parallel deployments, or passing outputs between stacks via code.
— the description by Pulumi

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The Pulumi Automation API allows developers to embed Pulumi operations directly into applications, replacing CLI-based shell scripts with type-safe, programmatic control. It supports both local source projects and inline programs, enabling complex workflows like multi-stack orchestration, self-service infrastructure portals, and dynamic environment provisioning.

What it does

  • Orchestrates deployments across multiple Pulumi stacks with dependency management.
  • Embeds infrastructure provisioning logic directly into custom applications or services.
  • Replaces fragile Bash or Makefile scripts with robust, programmatic infrastructure code.
  • Enables the creation of self-service platforms and internal developer tools.
  • Supports parallel stack operations for independent infrastructure components.
  • Provides programmatic access to stack configuration and deployment outputs.

When to use it

  • When you need to build a custom infrastructure portal or internal developer platform.
  • When orchestrating complex, multi-stack dependencies that require custom sequencing.
  • When you need to provision infrastructure dynamically from within a SaaS application.
  • When you want to replace shell-based automation with a more maintainable, type-safe language.
  • When building CI/CD pipelines that require programmatic control over infrastructure state.

Advantages

  • Provides full programmatic control over the Pulumi lifecycle.
  • Enables language-agnostic orchestration between the controller and the infrastructure code.
  • Improves error handling and logging compared to standard CLI scripts.
  • Supports both local file-based projects and inline code definitions.
  • Facilitates the creation of reusable, self-service infrastructure components.

Usage examples

“How can I deploy multiple Pulumi stacks in a specific order using the Automation API?”
The agent provides a TypeScript example using a loop to iterate through an array of stack configurations, calling stack.up() sequentially to ensure dependency order.
“Can I use the Automation API to set stack configuration values programmatically?”
The agent demonstrates the use of stack.setConfig() to inject environment-specific values like regions or secrets before triggering the deployment.
“How do I run a Pulumi program without external files?”
The agent explains the 'Inline Source' pattern, showing how to define the infrastructure logic directly within the program function inside the createOrSelectStack call.
“How can I deploy independent Pulumi stacks in parallel?”
The agent provides a code snippet using Promise.all to map over a list of stacks and execute stack.up() concurrently for faster deployment times.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/pulumi/pulumi-automation-api/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip pulumi-automation-api.zip -d .agents/skills

Documentation by Pulumi

Pulumi Automation API

When to Use This Skill

Invoke this skill when:

  • Orchestrating deployments across multiple Pulumi stacks

  • Embedding Pulumi operations in custom applications

  • Building self-service infrastructure platforms

  • Replacing fragile Bash/Makefile orchestration scripts

  • Creating custom CLIs for infrastructure management

  • Building web applications that provision infrastructure

What is Automation API

Automation API provides programmatic access to Pulumi operations. Instead of running pulumi up from the CLI, you call functions in your code that perform the same operations.

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

// Create or select a stack
const stack = await automation.LocalWorkspace.createOrSelectStack({
    stackName: "dev",
    projectName: "my-project",
    program: async () => {
        // Your Pulumi program here
    },
});

// Run pulumi up programmatically
const upResult = await stack.up({ onOutput: console.log });
console.log(`Update summary: ${JSON.stringify(upResult.summary)}`);

When to Use Automation API

Good Use Cases

Multi-stack orchestration:

When you split infrastructure into multiple focused projects, Automation API helps offset the added complexity by orchestrating operations across stacks:

infrastructure → platform → application
     ↓              ↓            ↓
   (VPC)      (Kubernetes)   (Services)

Automation API ensures correct sequencing without manual intervention.

Self-service platforms:

Build internal tools where developers request infrastructure without learning Pulumi:

  • Web portals for environment provisioning

  • Slack bots that create/destroy resources

  • Custom CLIs tailored to your organization

Embedded infrastructure:

Applications that provision their own infrastructure:

  • SaaS platforms creating per-tenant resources

  • Testing frameworks spinning up test environments

  • CI/CD systems with dynamic infrastructure needs

Replacing fragile scripts:

If you have Bash scripts or Makefiles stitching together multiple pulumi commands, Automation API provides:

  • Proper error handling

  • Type safety

  • Programmatic access to outputs

When NOT to Use
  • Single project with standard deployment needs

  • When you don't need programmatic control over operations

Architecture Choices

Local Source vs Inline Source

Local Source - Pulumi program in separate files:

const stack = await automation.LocalWorkspace.createOrSelectStack({
    stackName: "dev",
    workDir: "./infrastructure",  // Points to existing Pulumi project
});

When to use:

  • Different teams maintain orchestrator vs Pulumi programs

  • Pulumi programs already exist

  • Want independent version control and release cycles

  • Platform team orchestrating application team's infrastructure

Inline Source - Pulumi program embedded in orchestrator:

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

const stack = await automation.LocalWorkspace.createOrSelectStack({
    stackName: "dev",
    projectName: "my-project",
    program: async () => {
        const bucket = new aws.s3.Bucket("my-bucket");
        return { bucketName: bucket.id };
    },
});

When to use:

  • Single team owns everything

  • Tight coupling between orchestration and infrastructure is desired

  • Distributing as compiled binary (no source files needed)

  • Simpler deployment artifact

Language Independence

The Automation API program can use a different language than the Pulumi programs it orchestrates:

Orchestrator (Go) → manages → Pulumi Program (TypeScript)

This enables platform teams to use their preferred language while application teams use theirs.

Common Patterns

Multi-Stack Orchestration

Deploy multiple stacks in dependency order:

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

async function deploy() {
    const stacks = [
        { name: "infrastructure", dir: "./infra" },
        { name: "platform", dir: "./platform" },
        { name: "application", dir: "./app" },
    ];

    for (const stackInfo of stacks) {
        console.log(`Deploying ${stackInfo.name}...`);

        const stack = await automation.LocalWorkspace.createOrSelectStack({
            stackName: "prod",
            workDir: stackInfo.dir,
        });

        await stack.up({ onOutput: console.log });
        console.log(`${stackInfo.name} deployed successfully`);
    }
}

async function destroy() {
    // Destroy in reverse order
    const stacks = [
        { name: "application", dir: "./app" },
        { name: "platform", dir: "./platform" },
        { name: "infrastructure", dir: "./infra" },
    ];

    for (const stackInfo of stacks) {
        console.log(`Destroying ${stackInfo.name}...`);

        const stack = await automation.LocalWorkspace.selectStack({
            stackName: "prod",
            workDir: stackInfo.dir,
        });

        await stack.destroy({ onOutput: console.log });
    }
}
Passing Configuration

Set stack configuration programmatically:

const stack = await automation.LocalWorkspace.createOrSelectStack({
    stackName: "dev",
    workDir: "./infrastructure",
});

// Set configuration values
await stack.setConfig("aws:region", { value: "us-west-2" });
await stack.setConfig("dbPassword", { value: "secret", secret: true });

// Then deploy
await stack.up();
Reading Outputs

Access stack outputs after deployment:

const upResult = await stack.up();

// Get all outputs
const outputs = await stack.outputs();
console.log(`VPC ID: ${outputs["vpcId"].value}`);

// Or from the up result
console.log(`Outputs: ${JSON.stringify(upResult.outputs)}`);
Error Handling

Handle deployment failures gracefully:

try {
    const result = await stack.up({ onOutput: console.log });

    if (result.summary.result === "failed") {
        console.error("Deployment failed");
        process.exit(1);
    }
} catch (error) {
    console.error(`Deployment error: ${error}`);
    throw error;
}
Parallel Stack Operations

When stacks are independent, deploy in parallel:

const independentStacks = [
    { name: "service-a", dir: "./service-a" },
    { name: "service-b", dir: "./service-b" },
    { name: "service-c", dir: "./service-c" },
];

await Promise.all(independentStacks.map(async (stackInfo) => {
    const stack = await automation.LocalWorkspace.createOrSelectStack({
        stackName: "prod",
        workDir: stackInfo.dir,
    });
    return stack.up({ onOutput: (msg) => console.log(`[${stackInfo.name}] ${msg}`) });
}));

Best Practices

Separate Configuration from Code

Externalize configuration into files or environment variables:

import * as fs from "fs";

interface DeployConfig {
    stacks: Array<{ name: string; dir: string; }>;
    environment: string;
}

const config: DeployConfig = JSON.parse(
    fs.readFileSync("./deploy-config.json", "utf-8")
);

for (const stackInfo of config.stacks) {
    const stack = await automation.LocalWorkspace.createOrSelectStack({
        stackName: config.environment,
        workDir: stackInfo.dir,
    });
    await stack.up();
}

This enables distributing compiled binaries without exposing source code.

Stream Output for Long Operations

Use onOutput callback for real-time feedback:

await stack.up({
    onOutput: (message) => {
        process.stdout.write(message);
        // Or send to logging system, websocket, etc.
    },
});

Quick Reference

ScenarioApproach
Existing Pulumi projectsLocal source with workDir
New embedded infrastructureInline source with program function
Different teamsLocal source for independence
Compiled binary distributionInline source or bundled local
Multi-stack dependenciesSequential deployment in order
Independent stacksParallel deployment with Promise.all
  • pulumi-best-practices: Code-level patterns for Pulumi programs

References

Files

agents/openai.yaml

interface:
  display_name: "Pulumi Automation API"
  short_description: "Orchestrate Pulumi stacks via Automation API"
  default_prompt: "Use $pulumi-automation-api to design or improve this Automation API workflow."

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Pulumi
Publisher
Pulumi (Official)
Source
pulumi/agent-skills · pulumi/skills/pulumi-automation-api · commit 82f222a
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Pulumi or Pulumi.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download pulumi-automation-api.zip