Pulumi
Overview
Pulumi enables defining and managing cloud infrastructure using real programming languages (TypeScript, Python, Go, C#) instead of domain-specific languages. It supports 150+ cloud providers and allows using loops, conditionals, classes, and packages to build reusable, testable infrastructure components.
Instructions
- When creating resources, declare them as objects (e.g.,
new aws.s3.Bucket("my-bucket", {...})) and use pulumi.Output<T> with .apply() for computed values from cloud API responses.
- When managing environments, use stacks (
pulumi stack init dev/staging/prod) with stack-specific config for instance sizes, replica counts, and feature flags.
- When handling secrets, always use
pulumi config set --secret for credentials and never hardcode secrets in code.
- When building reusable patterns, create Component Resources by extending
pulumi.ComponentResource to encapsulate common infrastructure patterns (VPC module, ECS service, etc.).
- When referencing across projects, use Stack References to read outputs from other stacks for cross-project dependencies.
- When enforcing compliance, use CrossGuard policies to prevent non-compliant resources (e.g., no public S3 buckets, require encryption) in CI.
- When testing, write unit tests for Component Resources using standard test frameworks (Vitest, pytest, go test) by mocking the cloud provider and asserting resource properties.
Examples
Example 1: Deploy a serverless API on AWS
User request: "Set up an AWS Lambda API with DynamoDB using Pulumi and TypeScript"
Actions:
- Scaffold project with
pulumi new aws-typescript
- Define DynamoDB table and Lambda function resources
- Create API Gateway routes linked to Lambda handlers
- Export endpoint URL as a stack output for consumption
Output: A serverless API with infrastructure defined and deployed via pulumi up.
Example 2: Create a reusable VPC component
User request: "Build a reusable VPC module with Pulumi that teams can share"
Actions:
- Create a Component Resource class extending
pulumi.ComponentResource
- Define VPC, subnets, route tables, and NAT gateway as child resources
- Expose outputs for subnet IDs and security group references
- Write unit tests mocking AWS provider to validate configuration
Output: A reusable infrastructure component that teams import as a package.
Guidelines
- Use Component Resources for reusable patterns; do not repeat VPC/ECS/RDS configs across stacks.
- Always use
pulumi config set --secret for credentials; never hardcode secrets in code.
- Name resources with the project and stack for unique identification across environments.
- Export important outputs (URLs, endpoints, ARNs) for cross-stack consumption.
- Write unit tests for Component Resources by mocking the cloud provider and asserting resource properties.
- Use stack-specific config for environment differences: instance sizes, replica counts, feature flags.
- Enable CrossGuard policies in CI to prevent non-compliant resources from being deployed.
1---2name: pulumi3description: Assists with defining and managing cloud infrastructure using Pulumi with TypeScript, Python, Go, or C#. Use when provisioning AWS, GCP, Azure, or Kubernetes resources with real programming languages instead of HCL. Trigger words: pulumi, infrastructure as code, iac, pulumi up, pulumi stack, cloud infrastructure, component resource.4license: Apache-2.05---67# Pulumi89## Overview1011Pulumi enables defining and managing cloud infrastructure using real programming languages (TypeScript, Python, Go, C#) instead of domain-specific languages. It supports 150+ cloud providers and allows using loops, conditionals, classes, and packages to build reusable, testable infrastructure components.1213## Instructions1415- When creating resources, declare them as objects (e.g., `new aws.s3.Bucket("my-bucket", {...})`) and use `pulumi.Output<T>` with `.apply()` for computed values from cloud API responses.16- When managing environments, use stacks (`pulumi stack init dev/staging/prod`) with stack-specific config for instance sizes, replica counts, and feature flags.17- When handling secrets, always use `pulumi config set --secret` for credentials and never hardcode secrets in code.18- When building reusable patterns, create Component Resources by extending `pulumi.ComponentResource` to encapsulate common infrastructure patterns (VPC module, ECS service, etc.).19- When referencing across projects, use Stack References to read outputs from other stacks for cross-project dependencies.20- When enforcing compliance, use CrossGuard policies to prevent non-compliant resources (e.g., no public S3 buckets, require encryption) in CI.21- When testing, write unit tests for Component Resources using standard test frameworks (Vitest, pytest, go test) by mocking the cloud provider and asserting resource properties.2223## Examples2425### Example 1: Deploy a serverless API on AWS2627**User request:** "Set up an AWS Lambda API with DynamoDB using Pulumi and TypeScript"2829**Actions:**301. Scaffold project with `pulumi new aws-typescript`312. Define DynamoDB table and Lambda function resources323. Create API Gateway routes linked to Lambda handlers334. Export endpoint URL as a stack output for consumption3435**Output:** A serverless API with infrastructure defined and deployed via `pulumi up`.3637### Example 2: Create a reusable VPC component3839**User request:** "Build a reusable VPC module with Pulumi that teams can share"4041**Actions:**421. Create a Component Resource class extending `pulumi.ComponentResource`432. Define VPC, subnets, route tables, and NAT gateway as child resources443. Expose outputs for subnet IDs and security group references454. Write unit tests mocking AWS provider to validate configuration4647**Output:** A reusable infrastructure component that teams import as a package.4849## Guidelines5051- Use Component Resources for reusable patterns; do not repeat VPC/ECS/RDS configs across stacks.52- Always use `pulumi config set --secret` for credentials; never hardcode secrets in code.53- Name resources with the project and stack for unique identification across environments.54- Export important outputs (URLs, endpoints, ARNs) for cross-stack consumption.55- Write unit tests for Component Resources by mocking the cloud provider and asserting resource properties.56- Use stack-specific config for environment differences: instance sizes, replica counts, feature flags.57- Enable CrossGuard policies in CI to prevent non-compliant resources from being deployed.