{"id":"pulumi","kind":"sdk","name":"Pulumi","slug":"pulumi","description":"Infrastructure as code SDKs in familiar programming languages.","vendor":"Pulumi","languages":["typescript","javascript","nodejs","python","go","csharp","java"],"categories":["infrastructure","devtools"],"homepage":"https://www.pulumi.com","docsUrl":"https://www.pulumi.com/docs/","githubUrl":"https://github.com/pulumi/pulumi","packages":[{"registry":"npm","name":"@pulumi/pulumi","url":"https://www.npmjs.com/package/@pulumi/pulumi"},{"registry":"pypi","name":"pulumi","url":"https://pypi.org/project/pulumi/"}],"tags":["iac"],"skills":[{"name":"pulumi-best-practices","url":"https://skills.sh/pulumi/agent-skills/pulumi-best-practices","install":"npx skills add pulumi/agent-skills","sdk":"pulumi","key":"pulumi/pulumi-best-practices","description":"Load when the user is writing, reviewing, or debugging Pulumi TypeScript/Python programs; asks about Output<T> or apply() usage; wants to create ComponentResource classes; needs to refactor resources without destroying them (aliases); is setting up secrets or config; or is configuring a pulumi preview/up CI workflow. Also load for questions about resource dependency order, parent/child resource relationships, or pulumi.interpolate.","hasContent":true,"content":"---\nname: pulumi-best-practices\nversion: 1.0.0\ndescription: Load when the user is writing, reviewing, or debugging Pulumi TypeScript/Python programs; asks about Output<T> or apply() usage; wants to create ComponentResource classes; needs to refactor resources without destroying them (aliases); is setting up secrets or config; or is configuring a pulumi preview/up CI workflow. Also load for questions about resource dependency order, parent/child resource relationships, or pulumi.interpolate.\n---\n\n# Pulumi Best Practices\n\n## When to Use This Skill\n\nInvoke this skill when:\n\n- Writing new Pulumi programs or components\n- Reviewing Pulumi code for correctness\n- Refactoring existing Pulumi infrastructure\n- Debugging resource dependency issues\n- Setting up configuration and secrets\n\n## Practices\n\n### 1. Never Create Resources Inside `apply()`\n\n**Why**: Resources created inside `apply()` don't appear in `pulumi preview`, making changes unpredictable. Pulumi cannot properly track dependencies, leading to race conditions and deployment failures.\n\n**Detection signals**:\n\n- `new aws.` or other resource constructors inside `.apply()` callbacks\n- Resource creation inside `pulumi.all([...]).apply()`\n- Dynamic resource counts determined at runtime inside apply\n\n**Wrong**:\n\n```typescript\nconst bucket = new aws.s3.Bucket(\"bucket\");\n\nbucket.id.apply(bucketId => {\n    // WRONG: This resource won't appear in preview\n    new aws.s3.BucketObject(\"object\", {\n        bucket: bucketId,\n        content: \"hello\",\n    });\n});\n```\n\n**Right**:\n\n```typescript\nconst bucket = new aws.s3.Bucket(\"bucket\");\n\n// Pass the output directly - Pulumi handles the dependency\nconst object = new aws.s3.BucketObject(\"object\", {\n    bucket: bucket.id,  // Output<string> works here\n    content: \"hello\",\n});\n```\n\n**When apply is appropriate**:\n\n- Transforming output values for use in tags, names, or computed strings\n- Logging or debugging (not resource creation)\n- Conditional logic that affects resource properties, not resource existence\n\n**Reference**: https://www.pulumi.com/docs/concepts/inputs-outputs/\n\n---\n\n### 2. Pass Outputs Directly as Inputs\n\n**Why**: Pulumi builds a directed acyclic graph (DAG) based on input/output relationships. Passing outputs directly ensures correct creation order. Unwrapping values manually breaks the dependency chain, causing resources to deploy in wrong order or reference values that don't exist yet.\n\n**Detection signals**:\n\n- Variables extracted from `.apply()` used later as resource inputs\n- `await` on output values outside of apply\n- String concatenation with outputs instead of `pulumi.interpolate`\n\n**Wrong**:\n\n```typescript\nconst vpc = new aws.ec2.Vpc(\"vpc\", { cidrBlock: \"10.0.0.0/16\" });\n\n// WRONG: Extracting the value breaks the dependency chain\nlet vpcId: string;\nvpc.id.apply(id => { vpcId = id; });\n\nconst subnet = new aws.ec2.Subnet(\"subnet\", {\n    vpcId: vpcId,  // May be undefined, no tracked dependency\n    cidrBlock: \"10.0.1.0/24\",\n});\n```\n\n**Right**:\n\n```typescript\nconst vpc = new aws.ec2.Vpc(\"vpc\", { cidrBlock: \"10.0.0.0/16\" });\n\nconst subnet = new aws.ec2.Subnet(\"subnet\", {\n    vpcId: vpc.id,  // Pass the Output directly\n    cidrBlock: \"10.0.1.0/24\",\n});\n```\n\n**For string interpolation**:\n\n```typescript\n// WRONG\nconst name = bucket.id.apply(id => `prefix-${id}-suffix`);\n\n// RIGHT - use pulumi.interpolate for template literals\nconst name = pulumi.interpolate`prefix-${bucket.id}-suffix`;\n\n// RIGHT - use pulumi.concat for simple concatenation\nconst name = pulumi.concat(\"prefix-\", bucket.id, \"-suffix\");\n```\n\n**Reference**: https://www.pulumi.com/docs/concepts/inputs-outputs/\n\n---\n\n### 3. Use Components for Related Resources\n\n**Why**: ComponentResource classes group related resources into reusable, logical units. Without components, your resource graph is flat, making it hard to understand which resources belong together, reuse patterns across stacks, or reason about your infrastructure at a higher level.\n\n**Detection signals**:\n\n- Multiple related resources created at top level without grouping\n- Repeated resource patterns across stacks that should be abstracted\n- Hard to understand resource relationships from the Pulumi console\n\n**Wrong**:\n\n```typescript\n// Flat structure - no logical grouping, hard to reuse\nconst bucket = new aws.s3.Bucket(\"app-bucket\");\nconst bucketPolicy = new aws.s3.BucketPolicy(\"app-bucket-policy\", {\n    bucket: bucket.id,\n    policy: policyDoc,\n});\nconst originAccessIdentity = new aws.cloudfront.OriginAccessIdentity(\"app-oai\");\nconst distribution = new aws.cloudfront.Distribution(\"app-cdn\", { /* ... */ });\n```\n\n**Right**:\n\n```typescript\ninterface StaticSiteArgs {\n    domain: string;\n    content: pulumi.asset.AssetArchive;\n}\n\nclass StaticSite extends pulumi.ComponentResource {\n    public readonly url: pulumi.Output<string>;\n\n    constructor(name: string, args: StaticSiteArgs, opts?: pulumi.ComponentResourceOptions) {\n        super(\"myorg:components:StaticSite\", name, args, opts);\n\n        // Resources created here - see practice 4 for parent setup\n        const bucket = new aws.s3.Bucket(`${name}-bucket`, {}, { parent: this });\n        // ...\n\n        this.url = distribution.domainName;\n        this.registerOutputs({ url: this.url });\n    }\n}\n\n// Reusable across stacks\nconst site = new StaticSite(\"marketing\", {\n    domain: \"marketing.example.com\",\n    content: new pulumi.asset.FileArchive(\"./dist\"),\n});\n```\n\n**Component best practices**:\n\n- Use a consistent type URN pattern: `organization:module:ComponentName`\n- Call `registerOutputs()` at the end of the constructor\n- Expose outputs as class properties for consumers\n- Accept `ComponentResourceOptions` to allow callers to set providers, aliases, etc.\n\nFor in-depth component authoring guidance (args design, multi-language support, testing, distribution), use skill `pulumi-component`.\n\n**Reference**: https://www.pulumi.com/docs/concepts/resources/components/\n\n---\n\n### 4. Always Set `parent: this` in Components\n\n**Why**: When you create resources inside a ComponentResource without setting `parent: this`, those resources appear at the root level of your stack's state. This breaks the logical hierarchy, makes the Pulumi console hard to navigate, and can cause issues with aliases and refactoring. The parent relationship is what makes the component actually group its children.\n\n**Detection signals**:\n\n- ComponentResource classes that don't pass `{ parent: this }` to child resources\n- Resources inside a component appearing at root level in the console\n- Unexpected behavior when adding aliases to components\n\n**Wrong**:\n\n```typescript\nclass MyComponent extends pulumi.ComponentResource {\n    constructor(name: string, opts?: pulumi.ComponentResourceOptions) {\n        super(\"myorg:components:MyComponent\", name, {}, opts);\n\n        // WRONG: No parent set - this bucket appears at root level\n        const bucket = new aws.s3.Bucket(`${name}-bucket`);\n    }\n}\n```\n\n**Right**:\n\n```typescript\nclass MyComponent extends pulumi.ComponentResource {\n    constructor(name: string, opts?: pulumi.ComponentResourceOptions) {\n        super(\"myorg:components:MyComponent\", name, {}, opts);\n\n        // RIGHT: Parent establishes hierarchy\n        const bucket = new aws.s3.Bucket(`${name}-bucket`, {}, {\n            parent: this\n        });\n\n        const policy = new aws.s3.BucketPolicy(`${name}-policy`, {\n            bucket: bucket.id,\n            policy: policyDoc,\n        }, {\n            parent: this\n        });\n    }\n}\n```\n\n**What parent: this provides**:\n\n- Resources appear nested under the component in Pulumi console\n- Deleting the component deletes all children\n- Aliases on the component automatically apply to children\n- Clear ownership in state files\n\n**Reference**: https://www.pulumi.com/docs/concepts/resources/components/\n\n---\n\n### 5. Encrypt Secrets from Day One\n\n**Why**: Secrets marked with `--secret` are encrypted in state files, masked in CLI output, and tracked through transformations. Starting with plaintext config and converting later requires credential rotation, reference updates, and audit of leaked values in logs and state history.\n\n**Detection signals**:\n\n- Passwords, API keys, tokens stored as plain config\n- Connection strings with embedded credentials\n- Private keys or certificates in plaintext\n\n**Wrong**:\n\n```bash\n# Plaintext - will be visible in state and logs\npulumi config set databasePassword hunter2\npulumi config set apiKey sk-1234567890\n```\n\n**Right**:\n\n```bash\n# Encrypted from the start\npulumi config set --secret databasePassword hunter2\npulumi config set --secret apiKey sk-1234567890\n```\n\n**In code**:\n\n```typescript\nconst config = new pulumi.Config();\n\n// This retrieves a secret - the value stays encrypted\nconst dbPassword = config.requireSecret(\"databasePassword\");\n\n// Creating outputs from secrets preserves secrecy\nconst connectionString = pulumi.interpolate`postgres://user:${dbPassword}@host/db`;\n// connectionString is also a secret Output\n\n// Explicitly mark values as secret\nconst computed = pulumi.secret(someValue);\n```\n\n**Use Pulumi ESC for centralized secrets**:\n\n```yaml\n# Pulumi.yaml\nenvironment:\n  - production-secrets  # Pull from ESC environment\n```\n\n```bash\n# ESC manages secrets centrally across stacks\nesc env set production-secrets db.password --secret \"hunter2\"\n```\n\n**What qualifies as a secret**:\n\n- Passwords and passphrases\n- API keys and tokens\n- Private keys and certificates\n- Connection strings with credentials\n- OAuth client secrets\n- Encryption keys\n\n**References**:\n\n- https://www.pulumi.com/docs/concepts/secrets/\n- https://www.pulumi.com/docs/esc/\n\n---\n\n### 6. Use Aliases When Refactoring\n\n**Why**: Renaming resources, moving them into components, or changing parents causes Pulumi to see them as new resources. Without aliases, refactoring destroys and recreates resources, potentially causing downtime or data loss. Aliases preserve resource identity through refactors.\n\n**Detection signals**:\n\n- Resource rename without alias\n- Moving resource into or out of a ComponentResource\n- Changing the parent of a resource\n- Preview shows delete+create when update was intended\n\n**Wrong**:\n\n```typescript\n// Before: resource named \"my-bucket\"\nconst bucket = new aws.s3.Bucket(\"my-bucket\");\n\n// After: renamed without alias - DESTROYS THE BUCKET\nconst bucket = new aws.s3.Bucket(\"application-bucket\");\n```\n\n**Right**:\n\n```typescript\n// After: renamed with alias - preserves the existing bucket\nconst bucket = new aws.s3.Bucket(\"application-bucket\", {}, {\n    aliases: [{ name: \"my-bucket\" }],\n});\n```\n\n**Moving into a component**:\n\n```typescript\n// Before: top-level resource\nconst bucket = new aws.s3.Bucket(\"my-bucket\");\n\n// After: inside a component - needs alias with old parent\nclass MyComponent extends pulumi.ComponentResource {\n    constructor(name: string, opts?: pulumi.ComponentResourceOptions) {\n        super(\"myorg:components:MyComponent\", name, {}, opts);\n\n        const bucket = new aws.s3.Bucket(\"bucket\", {}, {\n            parent: this,\n            aliases: [{\n                name: \"my-bucket\",\n                parent: pulumi.rootStackResource,  // Was at root\n            }],\n        });\n    }\n}\n```\n\n**Alias types**:\n\n```typescript\n// Simple name change\naliases: [{ name: \"old-name\" }]\n\n// Parent change\naliases: [{ name: \"resource-name\", parent: oldParent }]\n\n// Full URN (when you know the exact previous URN)\naliases: [\"urn:pulumi:stack::project::aws:s3/bucket:Bucket::old-name\"]\n```\n\n**Lifecycle**:\n\n1. Add alias during refactor\n2. Run `pulumi up` on all stacks\n3. Remove alias after all stacks updated (optional, but keeps code clean)\n\n**Reference**: https://www.pulumi.com/docs/iac/concepts/resources/options/aliases/\n\n---\n\n### 7. Preview Before Every Deployment\n\n**Why**: `pulumi preview` shows exactly what will be created, updated, or destroyed. Surprises in production come from skipping preview. A resource showing \"replace\" when you expected \"update\" means imminent destruction and recreation.\n\n**Detection signals**:\n\n- Running `pulumi up --yes` interactively without reviewing changes\n- No preview step anywhere in the CI/CD workflow for a given change\n- Preview output not reviewed before merge or deployment approval\n\n**Wrong**:\n\n```bash\n# Deploying blind\npulumi up --yes\n```\n\n**Right**:\n\n```bash\n# Always preview first\npulumi preview\n\n# Review the output, then deploy\npulumi up\n```\n\n**What to look for in preview**:\n\n- `+ create` - New resource will be created\n- `~ update` - Existing resource will be modified in place\n- `- delete` - Resource will be destroyed\n- `+-replace` - Resource will be destroyed and recreated (potential downtime)\n- `~+-replace` - Resource will be updated, then replaced\n\n**Warning signs**:\n\n- Unexpected `replace` operations (check for immutable property changes)\n- Resources being deleted that shouldn't be\n- More changes than expected from your code diff\n\n**CI/CD integration**:\n\n```yaml\n# GitHub Actions example\njobs:\n  preview:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v4\n      - name: Pulumi Preview\n        uses: pulumi/actions@v5\n        with:\n          command: preview\n          stack-name: production\n        env:\n          PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}\n\n  deploy:\n    needs: preview\n    runs-on: ubuntu-latest\n    if: github.ref == 'refs/heads/main'\n    steps:\n      - name: Pulumi Up\n        uses: pulumi/actions@v5\n        with:\n          command: up\n          stack-name: production\n```\n\n**PR workflow**:\n\n- Run preview on every PR\n- Post preview output as PR comment\n- Require preview review before merge\n- Deploy only on merge to main\n\n**References**:\n\n- https://www.pulumi.com/docs/cli/commands/pulumi_preview/\n- https://www.pulumi.com/docs/iac/packages-and-automation/continuous-delivery/github-actions/\n\n---\n\n## Quick Reference\n\n| Practice | Key Signal | Fix |\n|----------|-----------|-----|\n| No resources in apply | `new Resource()` inside `.apply()` | Move resource outside, pass Output directly |\n| Pass outputs directly | Extracted values used as inputs | Use Output objects, `pulumi.interpolate` |\n| Use components | Flat structure, repeated patterns | Create ComponentResource classes |\n| Set parent: this | Component children at root level | Pass `{ parent: this }` to all child resources |\n| Secrets from day one | Plaintext passwords/keys in config | Use `--secret` flag, ESC |\n| Aliases when refactoring | Delete+create in preview | Add alias with old name/parent |\n| Preview before deploy | `pulumi up --yes` | Always run `pulumi preview` first |\n\n## Validation Checklist\n\nWhen reviewing Pulumi code, verify:\n\n- [ ] No resource constructors inside `apply()` callbacks\n- [ ] Outputs passed directly to dependent resources\n- [ ] Related resources grouped in ComponentResource classes\n- [ ] Child resources have `{ parent: this }`\n- [ ] Sensitive values use `config.requireSecret()` or `--secret`\n- [ ] Refactored resources have aliases preserving identity\n- [ ] Deployment process includes preview step\n\n## Related Skills\n\n- **pulumi-overview**: Entry-point skill that orients an agent across the three Pulumi surfaces (`pulumi do` CLI, IaC projects, and Pulumi Cloud) and routes to specialized skills. Load it first when the task begins with general infrastructure phrasing or spans multiple Pulumi surfaces. Use skill `pulumi-overview`.\n- **pulumi-component**: Deep guide to authoring ComponentResource classes, designing args interfaces, multi-language support, testing, and distribution. Use skill `pulumi-component`.\n- **pulumi-automation-api**: Programmatic orchestration of multiple stacks. Use skill `pulumi-automation-api`.\n- **pulumi-esc**: Centralized secrets and configuration management. Use skill `pulumi-esc`.\n","contentSource":"skills.sh/api/download/pulumi/agent-skills/pulumi-best-practices","contentFetchedAt":"2026-07-27T08:59:33.895Z"},{"name":"pulumi-automation-api","url":"https://skills.sh/pulumi/agent-skills/pulumi-automation-api","install":"npx skills add pulumi/agent-skills --skill pulumi-automation-api","sdk":"pulumi","key":"pulumi/pulumi-automation-api","description":"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.","hasContent":true,"content":"---\nname: pulumi-automation-api\nversion: 1.0.0\ndescription: 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.\n---\n\n# Pulumi Automation API\n\n## When to Use This Skill\n\nInvoke this skill when:\n\n- Orchestrating deployments across multiple Pulumi stacks\n- Embedding Pulumi operations in custom applications\n- Building self-service infrastructure platforms\n- Replacing fragile Bash/Makefile orchestration scripts\n- Creating custom CLIs for infrastructure management\n- Building web applications that provision infrastructure\n\n## What is Automation API\n\nAutomation 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.\n\n```typescript\nimport * as automation from \"@pulumi/pulumi/automation\";\n\n// Create or select a stack\nconst stack = await automation.LocalWorkspace.createOrSelectStack({\n    stackName: \"dev\",\n    projectName: \"my-project\",\n    program: async () => {\n        // Your Pulumi program here\n    },\n});\n\n// Run pulumi up programmatically\nconst upResult = await stack.up({ onOutput: console.log });\nconsole.log(`Update summary: ${JSON.stringify(upResult.summary)}`);\n```\n\n## When to Use Automation API\n\n### Good Use Cases\n\n**Multi-stack orchestration:**\n\nWhen you split infrastructure into multiple focused projects, Automation API helps offset the added complexity by orchestrating operations across stacks:\n\n```text\ninfrastructure → platform → application\n     ↓              ↓            ↓\n   (VPC)      (Kubernetes)   (Services)\n```\n\nAutomation API ensures correct sequencing without manual intervention.\n\n**Self-service platforms:**\n\nBuild internal tools where developers request infrastructure without learning Pulumi:\n\n- Web portals for environment provisioning\n- Slack bots that create/destroy resources\n- Custom CLIs tailored to your organization\n\n**Embedded infrastructure:**\n\nApplications that provision their own infrastructure:\n\n- SaaS platforms creating per-tenant resources\n- Testing frameworks spinning up test environments\n- CI/CD systems with dynamic infrastructure needs\n\n**Replacing fragile scripts:**\n\nIf you have Bash scripts or Makefiles stitching together multiple `pulumi` commands, Automation API provides:\n\n- Proper error handling\n- Type safety\n- Programmatic access to outputs\n\n### When NOT to Use\n\n- Single project with standard deployment needs\n- When you don't need programmatic control over operations\n\n## Architecture Choices\n\n### Local Source vs Inline Source\n\n**Local Source** - Pulumi program in separate files:\n\n```typescript\nconst stack = await automation.LocalWorkspace.createOrSelectStack({\n    stackName: \"dev\",\n    workDir: \"./infrastructure\",  // Points to existing Pulumi project\n});\n```\n\n**When to use:**\n\n- Different teams maintain orchestrator vs Pulumi programs\n- Pulumi programs already exist\n- Want independent version control and release cycles\n- Platform team orchestrating application team's infrastructure\n\n**Inline Source** - Pulumi program embedded in orchestrator:\n\n```typescript\nimport * as aws from \"@pulumi/aws\";\n\nconst stack = await automation.LocalWorkspace.createOrSelectStack({\n    stackName: \"dev\",\n    projectName: \"my-project\",\n    program: async () => {\n        const bucket = new aws.s3.Bucket(\"my-bucket\");\n        return { bucketName: bucket.id };\n    },\n});\n```\n\n**When to use:**\n\n- Single team owns everything\n- Tight coupling between orchestration and infrastructure is desired\n- Distributing as compiled binary (no source files needed)\n- Simpler deployment artifact\n\n### Language Independence\n\nThe Automation API program can use a different language than the Pulumi programs it orchestrates:\n\n```text\nOrchestrator (Go) → manages → Pulumi Program (TypeScript)\n```\n\nThis enables platform teams to use their preferred language while application teams use theirs.\n\n## Common Patterns\n\n### Multi-Stack Orchestration\n\nDeploy multiple stacks in dependency order:\n\n```typescript\nimport * as automation from \"@pulumi/pulumi/automation\";\n\nasync function deploy() {\n    const stacks = [\n        { name: \"infrastructure\", dir: \"./infra\" },\n        { name: \"platform\", dir: \"./platform\" },\n        { name: \"application\", dir: \"./app\" },\n    ];\n\n    for (const stackInfo of stacks) {\n        console.log(`Deploying ${stackInfo.name}...`);\n\n        const stack = await automation.LocalWorkspace.createOrSelectStack({\n            stackName: \"prod\",\n            workDir: stackInfo.dir,\n        });\n\n        await stack.up({ onOutput: console.log });\n        console.log(`${stackInfo.name} deployed successfully`);\n    }\n}\n\nasync function destroy() {\n    // Destroy in reverse order\n    const stacks = [\n        { name: \"application\", dir: \"./app\" },\n        { name: \"platform\", dir: \"./platform\" },\n        { name: \"infrastructure\", dir: \"./infra\" },\n    ];\n\n    for (const stackInfo of stacks) {\n        console.log(`Destroying ${stackInfo.name}...`);\n\n        const stack = await automation.LocalWorkspace.selectStack({\n            stackName: \"prod\",\n            workDir: stackInfo.dir,\n        });\n\n        await stack.destroy({ onOutput: console.log });\n    }\n}\n```\n\n### Passing Configuration\n\nSet stack configuration programmatically:\n\n```typescript\nconst stack = await automation.LocalWorkspace.createOrSelectStack({\n    stackName: \"dev\",\n    workDir: \"./infrastructure\",\n});\n\n// Set configuration values\nawait stack.setConfig(\"aws:region\", { value: \"us-west-2\" });\nawait stack.setConfig(\"dbPassword\", { value: \"secret\", secret: true });\n\n// Then deploy\nawait stack.up();\n```\n\n### Reading Outputs\n\nAccess stack outputs after deployment:\n\n```typescript\nconst upResult = await stack.up();\n\n// Get all outputs\nconst outputs = await stack.outputs();\nconsole.log(`VPC ID: ${outputs[\"vpcId\"].value}`);\n\n// Or from the up result\nconsole.log(`Outputs: ${JSON.stringify(upResult.outputs)}`);\n```\n\n### Error Handling\n\nHandle deployment failures gracefully:\n\n```typescript\ntry {\n    const result = await stack.up({ onOutput: console.log });\n\n    if (result.summary.result === \"failed\") {\n        console.error(\"Deployment failed\");\n        process.exit(1);\n    }\n} catch (error) {\n    console.error(`Deployment error: ${error}`);\n    throw error;\n}\n```\n\n### Parallel Stack Operations\n\nWhen stacks are independent, deploy in parallel:\n\n```typescript\nconst independentStacks = [\n    { name: \"service-a\", dir: \"./service-a\" },\n    { name: \"service-b\", dir: \"./service-b\" },\n    { name: \"service-c\", dir: \"./service-c\" },\n];\n\nawait Promise.all(independentStacks.map(async (stackInfo) => {\n    const stack = await automation.LocalWorkspace.createOrSelectStack({\n        stackName: \"prod\",\n        workDir: stackInfo.dir,\n    });\n    return stack.up({ onOutput: (msg) => console.log(`[${stackInfo.name}] ${msg}`) });\n}));\n```\n\n## Best Practices\n\n### Separate Configuration from Code\n\nExternalize configuration into files or environment variables:\n\n```typescript\nimport * as fs from \"fs\";\n\ninterface DeployConfig {\n    stacks: Array<{ name: string; dir: string; }>;\n    environment: string;\n}\n\nconst config: DeployConfig = JSON.parse(\n    fs.readFileSync(\"./deploy-config.json\", \"utf-8\")\n);\n\nfor (const stackInfo of config.stacks) {\n    const stack = await automation.LocalWorkspace.createOrSelectStack({\n        stackName: config.environment,\n        workDir: stackInfo.dir,\n    });\n    await stack.up();\n}\n```\n\nThis enables distributing compiled binaries without exposing source code.\n\n### Stream Output for Long Operations\n\nUse `onOutput` callback for real-time feedback:\n\n```typescript\nawait stack.up({\n    onOutput: (message) => {\n        process.stdout.write(message);\n        // Or send to logging system, websocket, etc.\n    },\n});\n```\n\n## Quick Reference\n\n| Scenario | Approach |\n| --- | --- |\n| Existing Pulumi projects | Local source with workDir |\n| New embedded infrastructure | Inline source with program function |\n| Different teams | Local source for independence |\n| Compiled binary distribution | Inline source or bundled local |\n| Multi-stack dependencies | Sequential deployment in order |\n| Independent stacks | Parallel deployment with Promise.all |\n\n## Related Skills\n\n- **pulumi-best-practices**: Code-level patterns for Pulumi programs\n\n## References\n\n- https://www.pulumi.com/docs/using-pulumi/automation-api/\n- https://www.pulumi.com/docs/using-pulumi/automation-api/concepts-terminology/\n- https://www.pulumi.com/blog/iac-recommended-practices-using-automation-api/\n","contentSource":"skills.sh/api/download/pulumi/agent-skills/pulumi-automation-api","contentFetchedAt":"2026-07-27T08:59:34.437Z"},{"name":"pulumi-overview","url":"https://skills.sh/pulumi/agent-skills/pulumi-overview","install":"npx skills add pulumi/agent-skills --skill pulumi-overview","sdk":"pulumi","key":"pulumi/pulumi-overview","description":"Use this skill for any task that creates, modifies, inspects, or destroys cloud infrastructure or SaaS configuration, from one-off CLI operations to full multi-resource projects, across providers in the Pulumi ecosystem. A typical project spans many providers (AWS or Azure or GCP, Kubernetes, Cloudflare, Auth0, Datadog, Vercel, and others), and Pulumi drives them through one CLI, one state model, and one credential layer. Trigger even when the user does not name Pulumi; phrasings like \"deploy this app,\" \"provision a database,\" \"stand up a VPC,\" \"configure Auth0,\" \"set up Datadog monitoring,\" or \"tear down staging\" qualify. Also trigger for tasks that migrate, port, or convert existing infrastructure code (Terraform, CloudFormation, CDK, Bicep, ARM) to Pulumi. Do not trigger for application runtime code that reads or writes data via cloud SDKs; that is application code, not infrastructure.","hasContent":true,"content":"---\nname: pulumi-overview\ndescription: Use this skill for any task that creates, modifies, inspects, or destroys cloud infrastructure or SaaS configuration, from one-off CLI operations to full multi-resource projects, across providers in the Pulumi ecosystem. A typical project spans many providers (AWS or Azure or GCP, Kubernetes, Cloudflare, Auth0, Datadog, Vercel, and others), and Pulumi drives them through one CLI, one state model, and one credential layer. Trigger even when the user does not name Pulumi; phrasings like \"deploy this app,\" \"provision a database,\" \"stand up a VPC,\" \"configure Auth0,\" \"set up Datadog monitoring,\" or \"tear down staging\" qualify. Also trigger for tasks that migrate, port, or convert existing infrastructure code (Terraform, CloudFormation, CDK, Bicep, ARM) to Pulumi. Do not trigger for application runtime code that reads or writes data via cloud SDKs; that is application code, not infrastructure.\n---\n\n# Pulumi\n\nPulumi is a tool for creating and managing cloud infrastructure: virtual machines, storage, Kubernetes clusters, databases, anything from any provider. You write code or run CLI commands, Pulumi previews what would change, then applies it. This skill walks three levels of working with Pulumi, from a single CLI command up to a project with policies and scheduled drift. Start at the smallest level that fits the task.\n\n## The three levels\n\nLevel 1 is `pulumi do`, a CLI for direct CRUD against any provider, with no project files or programming language. Level 2 is a Pulumi project in Python, TypeScript, Go, C#, or Java, used once the work involves multiple related resources, loops or conditionals, reusable abstractions, or environment-specific variants. Level 3 layers Pulumi Cloud onto a project for ESC credentials and configuration, policy, hosted execution, drift detection, schedules, and audit.\n\n| Level | Surface | When to use |\n|-------|---------|-------------|\n| 1 | `pulumi do` | Single resource or multi-vendor bootstrapping |\n| 2 | Pulumi project (Python, TS, Go, C#, Java) | Multiple resources, abstractions, environments |\n| 3 | ESC, policy, deployments, drift, schedules | Governance, secrets, scheduled and hosted runs |\n\nWhen the directory has no existing Pulumi project, a user asking to create a single bucket is a Level 1 task; do not scaffold a new project for it. A request to provision a VPC with subnets and a Kubernetes cluster is Level 2 from the start. A request for nightly drift detection on an existing stack is Level 3.\n\nConverting existing infrastructure code from another tool (Terraform, CloudFormation, CDK, ARM, or Bicep) is a separate path: route straight to the migration skills listed in the table at the end, independent of the level model.\n\nPicking the right level requires knowing what is already in the directory. If you can inspect the filesystem, do so. If you cannot (restricted agent contexts), ask the user before any Pulumi command runs whether there is an existing Pulumi project in the directory. Don't run a Pulumi command to find out: commands that would otherwise require a login silently provision a new agent account, parallel to one the user may already own.\n\n---\n\n## Level 1: `pulumi do` for direct resource operations\n\nUse `pulumi do` for one-shot resource operations against any provider. Examples: create a Cloudflare DNS record, create an S3 bucket for backups, create a GCP storage bucket for image uploads, stand up an Azure virtual machine, configure a Datadog monitor, register a Vercel deployment's domain in Cloudflare DNS. There is no project file, directory layout, or programming language involved.\n\n`pulumi do` is stateless. Each command runs once and operates directly against the cloud provider: `create` provisions a resource and prints its cloud-side identifier, while `read`, `patch`, and `delete` act on a resource addressed by that identifier. Nothing is written to a Pulumi state file, so there is no resource graph and no `${...}` wiring between commands. To connect two resources, capture an output from one command and pass it as a literal value to the next.\n\nWhen a Pulumi project (`Pulumi.yaml`) already exists in the directory, do not use `pulumi do` to mutate resources the project manages. Changes go through the program instead.\n\n### First invocation and signup\n\nThe canonical invocation is `npx pulumi <command>`. It works on any machine with Node.js installed and requires no prior Pulumi setup. If `pulumi` is on PATH, the `npx` shim defers to it; otherwise the command runs from the npm registry. To confirm the CLI is available before any command that would trigger signup, run `npx pulumi version`; it does not touch Pulumi Cloud. The resource verbs (`create`, `read`, `patch`, `delete`, `list`) require CLI v3.243.0 or newer, where `pulumi do` gained resource support. `npx pulumi` fetches a current release, but a `pulumi` already on PATH may be older, so confirm the version is recent.\n\n`pulumi do` writes no Pulumi state, but it resolves provider packages through the Pulumi registry, which can reach Pulumi Cloud. In an agent context without saved credentials, that means a first `pulumi do` may silently provision an ephemeral agent account and print a claim banner.\n\nThe CLI prints one line to stderr noting the new account and a claim URL. Surface that claim URL to the user immediately and again in the final response, since it is the only way the user takes ownership of the account; a session that ends without it leaves resources stranded in the cloud. The access token expires in 3 days and the claim URL stays valid for 30 days; Pulumi Cloud sets both, so surface whatever validity the banner reports.\n\nIf the account-creation banner appears more than once in the same session, credentials may not have been cached. Agent credentials are written to `/tmp/.pulumi/credentials.json` and the claim metadata to `/tmp/.pulumi/agent-claim.json`, but the claim URL itself is printed in the banner, not stored in those files. Capture it from each banner and surface the most recent one before doing more work.\n\nIf authentication fails, ask the user to run `pulumi login`. Never fall back to `pulumi login --local` or set `PULUMI_CONFIG_PASSPHRASE`; both silently change the user's setup.\n\nProvider credentials are separate from Pulumi Cloud credentials. `pulumi do` reads them from the same environment variables the provider's native CLI uses (`AWS_PROFILE`, `CLOUDFLARE_API_TOKEN`, `GOOGLE_APPLICATION_CREDENTIALS`). If they aren't set, ask the user before invoking commands that call out to the cloud. If a command fails with a provider authorization error, look up that provider's required credentials or configuration and have the user supply them rather than guessing at the cause. ESC (Level 3) is the durable place to keep them once a project exists.\n\n### Command shape\n\nHere are two invocations: create an S3 bucket, then read it back by the cloud id the create printed.\n\n```bash\nnpx pulumi do aws:s3:Bucket create --yes --bucket my-data\nnpx pulumi do aws:s3:Bucket read my-data\n```\n\nThe shape is:\n\n```text\npulumi do <pkg:mod:type> create [flags]\npulumi do <pkg:mod:type> read|patch|delete <id> [flags]\npulumi do <pkg:mod:type> list [flags]\n```\n\n- `<pkg>` is the provider package (`aws`, `azure-native`, `gcp`, `cloudflare`, `kubernetes`, etc.).\n- `<mod>` is the module within the package (`compute`, `storage`, `dns`); optional when the module is `index`. For example, `cloudflare:index/record:Record` invokes as `cloudflare:Record`.\n- `<type>` is the resource type (`VirtualMachine`, `Bucket`, `Record`).\n- `<id>` is the cloud provider's identifier for an existing resource, the value `create` prints as `id`. `create` and `list` take no positional argument; `read`, `patch`, and `delete` each take exactly one `<id>`.\n- `[flags]` set resource properties, or you pass a body file via `--input-file <file>`. See Property input below for how flags and files combine, and which values must come from a file.\n\nThere is no Pulumi logical name to choose. The CLI derives an internal name from the resource type, and you address existing resources by their cloud id.\n\n### Verbs\n\n- `create` provisions the resource and prints its properties, including the cloud `id`, as JSON. Capture that `id` to read, patch, or delete the resource later. Pass `--yes` in non-interactive contexts; `read` and `list` never need it.\n- `read <id>` fetches the resource's current state from the provider and prints it as JSON. It writes nothing.\n- `patch <id>` reads the resource's current inputs, overlays the top-level properties you pass as flags or in `--input-file`, and updates the resource in place. The overlay is shallow: properties you do not mention are left as they are. `patch` only updates; it cannot replace a resource, so a change that would require replacement fails rather than recreating it. The command makes you confirm by typing the resource id; pass `--yes` to skip that prompt in non-interactive contexts.\n- `delete <id>` removes the resource from the cloud. This is irreversible. Get explicit user confirmation for the specific resource before invoking; use `--yes` only after that confirmation, not as a default for non-interactive runs.\n\n`pulumi do` also supports two non-CRUD operations. `pulumi do <pkg:mod:type> list [flags]` enumerates existing instances of a resource type, but only for types that implement listing. Native providers support it broadly. The Terraform-bridged providers (`aws`, `azure`, `gcp`) support it too, but coverage varies by resource type, so a type that lacks it rejects the verb. `pulumi do <pkg:mod:function> [flags]` invokes a stateless function the provider exposes alongside its resources.\n\n### Property input\n\nProperties come from per-property flags, a body file, or both; flags overlay the body. Flags set top-level scalar properties only, so nested or structured values (`tags`, nested blocks) must come from the body file. The body defaults to PCL, written as flat `name = value` attributes; pass `--input yaml` (which needs the YAML converter plugin) to use YAML instead.\n\n```bash\ncat > bucket.pcl <<'EOF'\nbucket = \"my-data\"\ntags = {\n  Environment = \"dev\"\n}\nEOF\nnpx pulumi do aws:s3:Bucket create --yes --input-file bucket.pcl\n```\n\nBefore authoring properties for a resource new to this session, run `npx pulumi package info <pkg> --module <mod> --resource <Type>` to list its inputs and outputs with descriptions, scoped to that one resource. Reach for `npx pulumi package get-schema <pkg>` only when you need the full machine-readable schema with the nested type definitions `info` does not expand; for a large provider it runs to tens of MB, so do not read it whole. Property names are camelCase (flags are the kebab-case form). To discover names, run `npx pulumi package info <pkg>` with no module to list its modules and resources, or browse the catalog at https://www.pulumi.com/registry/.\n\n### Connecting resources\n\n`pulumi do` keeps no state and has no resource graph, so there is no `${...}` reference syntax between commands. To feed one resource's output into another, read a field from the first command's JSON output and pass it as a literal flag to the next.\n\n```bash\n# create prints JSON containing \"id\": \"vpc-0abc123\"\nnpx pulumi do aws:ec2:Vpc create --yes --cidr-block 10.0.0.0/16\n\n# pass that id to the subnet\nnpx pulumi do aws:ec2:Subnet create --yes --vpc-id vpc-0abc123 --cidr-block 10.0.1.0/24\n```\n\nThe same pattern connects resources across providers. Here a value from the `random` provider feeds an AWS resource name, a common way to get globally-unique names.\n\n```bash\n# RandomPet prints JSON containing \"id\": \"artistic-bull\"\nnpx pulumi do random:RandomPet create --yes\n\n# use it in the bucket name\nnpx pulumi do aws:s3:Bucket create --yes --bucket assets-artistic-bull\n```\n\nWhen a command needs a value the chain does not produce, like an existing resource id or an API zone id, get it from a provider function, a `list` where the provider supports it, or the user. Do not invent it.\n\n### Output\n\nBy default, `create`, `read`, and `patch` each write one JSON object to stdout for the affected resource. Check the exit code on every invocation.\n\n```json\n{\n  \"id\":     \"my-data\",\n  \"bucket\": \"my-data\",\n  \"arn\":    \"arn:aws:s3:::my-data\"\n}\n```\n\nThe resource's properties are top-level, alongside an `id` field holding the cloud identifier. There is no nested `outputs` object, no `urn`, and the type token you passed in is not echoed back. `list` instead writes a JSON array of `{id, name}` entries, and a function writes its declared result shape.\n\n### Graduating to Level 2\n\nEject to Level 2 when one-shot commands stop fitting. Because `pulumi do` leaves no Pulumi state behind, the resources it created are ordinary cloud resources, so you adopt them into a project with `pulumi import`. From inside a Pulumi project, run `pulumi import` with each resource's full type token, a logical name, and the cloud `id` that `create` returned. Import records the resource in the stack's state and, by default, generates its program code.\n\n```bash\n# the import type token is the full pkg:mod/type:Type form, not pulumi do's short aws:s3:Bucket\nnpx pulumi import aws:s3/bucket:Bucket assets my-data\n```\n\nMove the generated code into your program, then manage the resource there instead of with `pulumi do`. To adopt several at once, pass them in a bulk `--file`.\n\n---\n\n## Level 2: full infrastructure as code\n\nLevel 2 is a Pulumi project: code in Python, TypeScript, Go, C#, or Java that describes a set of related resources and their dependencies. Start here when the task involves multiple related resources, loops or conditionals, reusable abstractions, or environment-specific variants. It is also the right level when ad-hoc work at Level 1 has grown past what a few CLI invocations should carry. Match the user's existing codebase language when one is present; default to TypeScript otherwise.\n\nBefore writing any non-trivial program, use skill `pulumi-best-practices`, which covers `Output<T>` and `apply()` usage, passing outputs directly as inputs, component structure and parenting, secrets hygiene, and safe refactoring with `aliases`.\n\n### Bootstrapping\n\nThe quickest way to start a project is with a template, though you can scaffold one by hand if you prefer:\n\n```bash\nnpx pulumi new aws-typescript\nnpx pulumi new gcp-go\n```\n\nTemplates set up the working directory, `Pulumi.yaml`, an initial stack, the language's package manifest, and a starter program. Browse the full catalog with `npx pulumi template list`, or filter by name with `npx pulumi template list --name <filter>`.\n\n### Core lifecycle\n\nThe lifecycle commands work the same across languages:\n\n```bash\nnpx pulumi preview      # show what would change\nnpx pulumi up           # apply\nnpx pulumi refresh      # reconcile state with cloud reality\n```\n\nAlways run `preview` before `up`; it shows what will change and costs nothing.\n\n`pulumi destroy` tears down every resource in the stack. The Pulumi docs call it \"generally irreversible\"; never invoke without explicit user confirmation of the stack name.\n\n### Stacks and config\n\nA stack is an isolated instance of a project. A common pattern is one stack per environment, named `dev`, `staging`, and `prod`.\n\n```bash\nnpx pulumi stack init dev\nnpx pulumi stack select prod\n\nnpx pulumi config set aws:region us-west-2\nnpx pulumi config set --secret dbPassword \"...\"\n```\n\nRead configuration values from inside the program with the SDK's `Config` object; the exact operation names vary by language, so refer to the per-language examples at https://www.pulumi.com/docs/iac/concepts/config/#code. Use skill `pulumi-best-practices` for `Output<T>` / `apply()` usage and broader secrets hygiene.\n\nA stack only touches resources tracked in its state, so removing a resource from your program causes `pulumi up` to delete it from the cloud. Set `protect: true` on anything you cannot afford to lose.\n\nFor the full IaC reference, see https://www.pulumi.com/docs/iac/.\n\n---\n\n## Level 3: governance and operations\n\nLevel 3 uses Pulumi Cloud for more than state. ESC holds the credentials for every provider a project touches and brokers them into runs and shells. Policy enforcement, hosted execution, drift detection, scheduled operations, and audit round out the surface.\n\n### ESC: environments, secrets, configuration\n\nAn ESC environment composes secrets and configuration from cloud secret managers, OIDC-vended credentials, and other ESC environments into a single resolved bundle that programs and stacks consume.\n\n```bash\nnpx pulumi env init my_org/aws/prod\nnpx pulumi env set my_org/aws/prod aws.region us-west-2\nnpx pulumi env open my_org/aws/prod\nnpx pulumi env run my_org/aws/prod -- aws s3 ls\n```\n\n**Where the provider supports it, vend cloud credentials through OIDC rather than static keys in environment YAML.** OIDC trust policies, IdP registration, and rotation patterns live in `pulumi-esc`; use skill `pulumi-esc` rather than invent ESC YAML by hand.\n\n`env open` resolves and prints live credentials, so avoid capturing its output into logs or transcripts. Prefer `env run -- <command>`, which injects the credentials into the child process rather than printing them.\n\n### Policy\n\nPulumi Policies runs policy packs against the resource graph at preview and update time. A policy can reject the deployment, require approval, or annotate resources with findings; enforcement happens before any cloud API call.\n\n```bash\nnpx pulumi policy new aws-typescript          # scaffold a pack from a policy template\nnpx pulumi policy publish my_org              # the pack name comes from PulumiPolicy.yaml\nnpx pulumi policy enable my_org/<pack-name> latest --policy-group production\n```\n\nPolicies are written in TypeScript or Python, the same languages you use for programs.\n\n### Deployments\n\nPulumi Deployments runs `pulumi up`, `preview`, and `destroy` in Pulumi-managed infrastructure rather than on the local machine. Use it for CI without maintaining your own runners and for any operation that needs to run server-side.\n\n```bash\nnpx pulumi deployment run update --stack my_org/proj/prod\n```\n\nThe target stack must already exist; a wrong `--stack` value can prompt to create a new stack rather than fail.\n\n### Drift detection and scheduled operations\n\nDrift detection compares stack state against the cloud and reports anything that has diverged. For an ad-hoc local check, run a refresh in preview-only mode. Pulumi Cloud schedules operations on a cron (times are UTC), including a purpose-built drift kind.\n\n```bash\n# Ad-hoc local drift check\nnpx pulumi refresh --preview-only\n\n# Scheduled drift detection (detection only)\nnpx pulumi stack schedule new --kind drift --cron \"0 0 * * *\"\n\n# Scheduled secret rotation for an ESC environment\nnpx pulumi env schedule new my_org/aws/prod --cron \"0 0 1 * *\"\n```\n\nA schedule is standing automation that keeps running after the session ends, so confirm the operation, cadence, and stack with the user before creating one. Two kinds act without a human in the loop: `--kind drift --auto-remediate` runs `pulumi up` on detected drift, and `--kind ttl` destroys the stack at a set time. Default to detection-only unless the user asks for remediation.\n\n### Further reading\n\n- ESC: https://www.pulumi.com/docs/esc/\n- Pulumi Policies: https://www.pulumi.com/docs/insights/policy/\n- Deployments: https://www.pulumi.com/docs/pulumi-cloud/deployments/\n- Drift detection: https://www.pulumi.com/docs/pulumi-cloud/deployments/drift/\n\n---\n\n## Reference\n\nWhen you are uncertain about a CLI flag, command shape, or resource property, look it up rather than guess. `npx pulumi <command> --help` documents every flag and subcommand from the CLI itself. The full reference, provider catalog, and conceptual documentation live at https://www.pulumi.com/docs.\n\n---\n\n## Routing to specialized skills\n\nWhen the work moves into territory another skill covers in depth, hand off to that skill rather than reinvent its content.\n\n| Skill | Load when |\n|---|---|\n| `pulumi-best-practices` | Writing any non-trivial Level 2 program |\n| `pulumi-component` | Packaging or consuming `ComponentResource` abstractions |\n| `pulumi-esc` | Defining ESC environments, OIDC trust policies, or rotation |\n| `pulumi-automation-api` | Embedding Pulumi inside another program (IDP, custom CI) |\n| `provider-upgrade` | Upgrading a provider package version in a stack without unintended changes |\n| `package-usage` | Auditing which stacks across the org use a package and at what versions |\n| `pulumi-terraform-to-pulumi`, `pulumi-cdk-to-pulumi`, `cloudformation-to-pulumi`, `pulumi-arm-to-pulumi` | Migrating from those tools |\n\nAn agent only sees the skills the user installed, so a referenced skill may not be present. `pulumi-best-practices`, `pulumi-component`, `pulumi-esc`, `pulumi-automation-api`, `provider-upgrade`, and `package-usage` ship in the same `pulumi` plugin as this skill, so they are available whenever this one is. The migration skills install separately through the `pulumi-migration` plugin and may be absent. When a referenced skill is available, load it. When it is not, do not stall or treat the gap as an error: continue with the guidance in this skill and the docs at https://www.pulumi.com/docs, and tell the user which skill or plugin covers the work in depth.\n","contentSource":"skills.sh/api/download/pulumi/agent-skills/pulumi-overview","contentFetchedAt":"2026-07-27T08:59:34.732Z"}],"official":true,"generatedAt":"2026-07-27T09:02:29.956Z"}