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.

Navigating Nuance: Polishing Your Technical English

Pulumi’s strength isn’t just about declarative infrastructure as code; it’s about communicating that complexity effectively. For developers who are building their professional English skills alongside their technical ones, the subtleties of Pulumi terminology can be particularly challenging. Let’s face it, “state” is a common word, but understanding its precise application within Pulumi’s context – how it relates to drift detection, immutable changes, and the overall management of your cloud environment – demands more than just rote translation. Similarly, describing changes in a Pull Request isn’t simply stating “updated database schema.” It requires careful phrasing that conveys intent, impact, and potential consequences.

Consider this scenario: Alex, a developer new to Pulumi, is reviewing a pull request submitted by Ben. The PR description reads: “Updated the PostgreSQL instance.” Alex, recognizing the need for more detail, might politely comment, “Ben, could you elaborate on the changes you made to the PostgreSQL instance? Specifically, what schema modifications were implemented and how do they align with our existing data migration strategy? It would be beneficial to include a description of any potential impact on downstream applications.” This is a common situation – Ben’s initial description is functional but lacks the precision needed for a robust code review. The key here isn’t that Ben’s phrasing was wrong, it’s that it wasn’t sufficiently detailed for a professional context. Using terms like “schema modifications,” “data migration strategy,” and proactively mentioning “potential impact” demonstrates a deeper understanding of Pulumi’s core concepts and the importance of thorough documentation.

Another example might appear in a Slack channel during troubleshooting. Sarah is struggling to understand an error message related to a Pulumi stack deployment: “State drift detected – resource ‘database-server’ has changed unexpectedly.” Instead of simply saying, “Fix it!”, a more helpful response would be, “Let’s investigate the state drift. Can you describe the changes that triggered this? Did a new provider configuration update the database server definition, or is there an issue with our existing pulumi up command?” This level of detailed questioning demonstrates an ability to diagnose problems by understanding the relationship between Pulumi’s state, the resources it manages, and the potential sources of inconsistency. The goal is always clear communication – ensuring everyone involved understands the situation and can contribute effectively towards a solution.

pulumi_command = "pulumi up --stack my-app --auto-approve"

This simple command illustrates a critical concept: Pulumi’s approach to infrastructure as code emphasizes explicit control over changes, rather than implicit reliance on provider defaults. Understanding that pulumi up isn’t just about “applying” configurations but triggering a process of state validation and potential modification is fundamental to using Pulumi effectively – and communicating those actions clearly within your team.