Pulumi English: Infrastructure as Code in Any Language

Introduction

Pulumi is an Infrastructure as Code (IaC) platform that lets you define cloud infrastructure using general-purpose programming languages like TypeScript, Python, Go, and C#. If your team uses Pulumi or is evaluating it against Terraform, you will encounter a specific vocabulary in architecture discussions, pull request reviews, and documentation. Understanding these terms precisely will help you communicate clearly about infrastructure changes and participate in design decisions.

Stacks and Projects

In Pulumi, a project is the collection of code that defines your infrastructure, analogous to a repository or package. A stack is a deployment instance of that project — typically representing an environment like dev, staging, or production. Engineers use these terms very specifically:

• “Each environment is a separate stack” — dev, staging, and production are three stacks of the same project
• “We deploy the stack” — run pulumi up to apply infrastructure changes
• “The stack references an output from another stack” — cross-stack references for sharing values like VPC IDs
• “We destroy the stack” — pulumi destroy removes all resources in the stack
• “Stack configuration” — environment-specific settings managed with pulumi config set

The phrase “stack output” is important. Engineers say “we export the load balancer URL as a stack output so other stacks can consume it.” Exporting values from one stack and reading them in another is a common architectural pattern in multi-stack Pulumi setups.

Resources, Providers, and the State

Resources are the fundamental building blocks — a Pulumi S3 bucket, an EC2 instance, or a Kubernetes deployment. Each resource corresponds to a real cloud object. The vocabulary:

• “We declare a resource” — write code that defines a cloud resource
• “The resource is provisioned” — Pulumi has created or updated the actual cloud object
• “Resource inputs” — the configuration you pass to a resource constructor
• “Resource outputs” — the values that become known only after the resource is created, like an IP address or ARN

A provider is the plugin that knows how to interact with a cloud platform. “We use the AWS provider” means Pulumi uses the AWS SDK under the hood. Engineers say “configure the provider with the target region” when setting where resources should be deployed.

State is how Pulumi tracks what it has deployed. By default, state is stored in Pulumi Cloud, but teams can also use “self-managed state” stored in an S3 bucket or Azure Blob Storage. Engineers say: “We keep state in Pulumi Cloud for the managed locking” — referring to the concurrency control that prevents two engineers from running pulumi up simultaneously and corrupting state.

Pulumi Up, Preview, and Refresh

Three commands define the Pulumi workflow:

• pulumi preview — shows what changes would be made without applying them; “we always preview before applying in production”
• pulumi up — applies the changes; “we run pulumi up to deploy the new database”
• pulumi refresh — updates Pulumi’s state to match the actual cloud state; “we refresh after a manual change was made in the console”

Engineers describe the diff that pulumi preview shows as the plan: “The plan shows three resources being updated and one being replaced.” The word replaced is important — it means the resource will be destroyed and recreated, which often causes downtime and requires explicit review.

Pulumi vs Terraform Comparisons

Teams frequently compare Pulumi and Terraform. Key phrases in these discussions:

• “Real loops and conditionals” — Pulumi uses native language constructs; “we use a TypeScript for loop to create 10 S3 buckets, which would require count or for_each in Terraform”
• “Type safety” — Pulumi provides compile-time checking of resource configurations
• “HCL vs general-purpose language” — the central comparison; HCL is Terraform’s domain-specific language
• “Pulumi uses the same provider ecosystem as Terraform” — through the Terraform provider bridge

Key Vocabulary

Term	Definition
project	The Pulumi codebase that defines a set of infrastructure resources
stack	A deployment instance of a project, representing one environment
resource	A cloud object managed by Pulumi, such as a VM or database
provider	The plugin that interfaces with a specific cloud platform
state	Pulumi’s record of what resources have been deployed
stack output	An exported value from a stack that other stacks can consume
pulumi preview	Shows planned changes without applying them
pulumi up	Applies the infrastructure changes
replace	Destroy and recreate a resource, typically due to an immutable property change
self-managed state	Storing Pulumi state in your own cloud storage rather than Pulumi Cloud

Practice Tips

1. Explain the stack model to a colleague in English. Practise: “In Pulumi, a project is the code, and a stack is an instance of that code deployed to a specific environment. We have one project and three stacks: dev, staging, and production.”

2. Use “preview before apply” as a workflow principle. Always say “let me preview this first” before running pulumi up. This phrase signals good practice and is universally understood in IaC communities.

3. Understand the word “replace” in previews. When pulumi preview shows a resource being “replaced,” know how to explain why: “This resource will be replaced because we changed an immutable property — the database engine version — which requires destroying and recreating the instance.”

4. Read Pulumi’s migration guide from Terraform. This document is written in clear English and explicitly compares concepts side by side. It is excellent reading practice and teaches you the vocabulary of both tools simultaneously.

Conclusion

Pulumi’s vocabulary — stacks, resources, providers, state, preview, replace — is precise and important to understand for infrastructure discussions. The tool’s biggest differentiator is using real programming languages, so the vocabulary around loops, conditionals, and type safety is central to discussions. As IaC becomes more programming-language-native, the ability to discuss these concepts in English will be increasingly valuable for infrastructure engineers.