Pulumi Setup — Infrastructure as Code in the Language You Already Know

Terraform's HCL is a domain-specific language that gets the job done but fights you on anything beyond basic conditionals and loops. Need to generate a dynamic number of resources based on a JSON config file? In HCL, you are wrestling with for_each, dynamic blocks, and string interpolation. In Pulumi with TypeScript, it is a for loop.

The real advantage is type safety. Pulumi's TypeScript SDK gives you full IntelliSense for every cloud resource. Misspell an instance type? The compiler catches it. Pass a string where a number is expected? Red squiggly line before you even run a command. This eliminates an entire class of runtime errors that Terraform only catches during plan or apply.

Testing is where Pulumi truly shines. You can write unit tests using Jest or pytest that validate your infrastructure logic without deploying anything. Mock the cloud provider, assert that your security group does not allow 0.0.0.0/0 ingress on port 22, and run it in CI on every commit. Try doing that with HCL.

Pulumi also supports Terraform providers natively via the Pulumi-Terraform bridge, so you are not giving up ecosystem breadth. If a Terraform provider exists for a service, Pulumi can use it.

We scaffold a Pulumi project in your preferred language (TypeScript is most popular) with a stack-per-environment architecture. Each stack (dev, staging, production) shares the same program but uses different configuration values stored in Pulumi.{stack}.yaml files. Secrets are encrypted using Pulumi's built-in secrets manager or your KMS key.

The project structure follows a component-resource pattern. We create custom component classes — VpcComponent, DatabaseComponent, EcsServiceComponent — that encapsulate related resources with sensible defaults and typed interfaces. Your main program composes these components, making the infrastructure readable even for developers who have never touched IaC before.

State management uses Pulumi Cloud (free tier for small teams) or a self-managed S3 backend. We configure RBAC so developers can run pulumi preview but only CI can run pulumi up in production. State is encrypted at rest and access-controlled via your identity provider.

CI/CD integration posts preview diffs on pull requests and applies changes on merge. We use the official Pulumi GitHub Action or a custom pipeline step that runs pulumi preview --diff and captures the output. Policy as code via Pulumi CrossGuard enforces organizational rules — no public S3 buckets, no unencrypted EBS volumes, mandatory tags on all resources.

A production-ready Pulumi codebase with everything your team needs:

• Component architecture — reusable, typed infrastructure components with documentation
• Multi-stack setup — dev, staging, production stacks with environment-specific configuration
• Secret management — encrypted secrets per stack using Pulumi secrets or AWS KMS
• Unit tests — infrastructure tests in Jest/pytest that run in CI on every commit
• Policy as code — CrossGuard policies enforcing security and compliance rules
• CI/CD pipeline — preview on PR, apply on merge, with approval gates for production
• Import existing resources — your current infrastructure imported into Pulumi state
• Runbook — operational documentation for common tasks and troubleshooting

Always use ComponentResource as your base class for grouping resources. This gives you logical grouping in the Pulumi console and makes pulumi destroy work correctly on component boundaries. Raw resources scattered across your program become unmanageable past 50 resources.

Use pulumi config set --secret for anything sensitive. Pulumi encrypts these values in the stack file so they can be committed to git safely. Never use plain config for database passwords, API keys, or tokens — even for development stacks.

Set protect: true on databases and stateful resources. This prevents accidental deletion during refactoring. You can always remove the protection explicitly when you genuinely want to destroy the resource, but the default should be safety.

If you are migrating from Terraform, use pulumi import to bring existing resources under Pulumi management without recreating them. We handle this migration as part of our migration service.