English Vocabulary for Pulumi Infrastructure as Code

Pulumi is an Infrastructure as Code (IaC) tool that lets you define cloud resources using general-purpose programming languages like TypeScript, Python, Go, and Java. If you work with Pulumi or are migrating from Terraform, knowing Pulumi’s specific vocabulary is essential for reading its documentation, contributing to team codebases, and participating in infrastructure discussions.

Key Vocabulary

Stack A stack is an isolated, independently deployable instance of a Pulumi program. Stacks typically map to environments (dev, staging, production) or regions. Teams “create,” “update,” “preview,” and “destroy” stacks. Each stack has its own state and configuration. Example: “We have three stacks for the API infrastructure — api-dev, api-staging, and api-prod — each pointing to a different AWS account.”

Project A project is the unit of code organization in Pulumi — a directory containing a Pulumi.yaml file and the program source code. A project can have multiple stacks. Teams “initialize,” “structure,” and “organize” projects. Example: “We split the monolithic project into three separate projects — networking, database, and application — so teams can deploy them independently.”

Program The Pulumi program is the code (TypeScript, Python, etc.) that declares the desired cloud resources. When you run pulumi up, Pulumi executes the program and computes the necessary changes. Developers “write,” “run,” and “execute” Pulumi programs. Example: “The Pulumi program creates the VPC, subnets, and security groups in order — Pulumi resolves the dependency graph automatically.”

Resource A resource represents a cloud infrastructure component — an S3 bucket, an RDS instance, a Lambda function. Resources are declared by instantiating provider classes in the program. Developers “declare,” “provision,” and “manage” resources. Example: “I declared an S3 bucket resource with versioning enabled and encryption at rest configured as properties.”

Output An output is a value computed by a resource after it is created — for example, a bucket’s name, an EC2 instance’s public IP, or a load balancer’s DNS name. Outputs are Promise-like values. Developers “export,” “consume,” and “reference” outputs. Example: “We export the database endpoint output so other stacks can consume it without hardcoding the value.”

Stack Reference A StackReference is a Pulumi resource that lets one stack consume exported outputs from another stack. It is the standard mechanism for cross-stack dependencies. Teams “create,” “use,” and “read from” stack references. Example: “The application stack uses a StackReference to read the VPC ID and subnet IDs exported by the networking stack.”

ComponentResource A ComponentResource is a reusable higher-order resource that groups multiple child resources together into a logical unit. It is how teams build internal modules and abstractions. Developers “write,” “define,” and “implement” ComponentResources. Example: “We built a ManagedDatabase ComponentResource that creates an RDS instance, a security group, and a Secrets Manager secret together as a single unit.”

Automation API The Automation API is a Pulumi SDK that lets you embed Pulumi operations (up, preview, destroy) into your own programs and pipelines, without the CLI. Teams “use,” “integrate,” and “build with” the Automation API. Example: “We built an internal self-service portal that uses the Automation API to provision developer sandboxes on demand without requiring CLI access.”

Common Phrases and Collocations

“export a stack output” The action of making a value available to other stacks or external consumers. Always “export” — not “publish” or “share.” Example: “Export the load balancer’s DNS name as a stack output so the monitoring team can configure their alerts without reading the code.”

“reference another stack” The standard phrasing for using a StackReference. “Reference” is more precise than “import from” or “read from.” Example: “The application stack references the networking stack to get the subnet IDs — this way the networking team controls the values.”

“run the Pulumi program” The standard description of executing pulumi up or pulumi preview. Always “run the Pulumi program” in documentation. Example: “Run the Pulumi program with pulumi preview first to see the planned changes before applying them.”

“the resource is pending replacement” When a change to a resource’s properties requires destroying and recreating it rather than updating it in place. This is a critical warning in pulumi preview output. Example: “The resource is pending replacement because you changed the RDS engine version — this will cause downtime; schedule a maintenance window.”

“configure the provider” Setting up a Pulumi provider (AWS, Azure, GCP, Kubernetes) with credentials, region, and other options. Teams “configure,” “instantiate,” and “initialize” providers. Example: “Configure the AWS provider with the target account’s role ARN so the program deploys into the correct environment.”

Practical Sentences to Practice

1. “The networking stack exports the VPC ID and the application stack references it via a StackReference.”
2. “We created a ComponentResource for our standard microservice deployment that includes the ECS task definition, service, and auto-scaling policy.”
3. “Run pulumi preview and check for any resources that are pending replacement before approving the change.”
4. “The Automation API lets our CI system run pulumi up programmatically without maintaining shell scripts around the CLI.”
5. “Export the database connection string as a stack output so downstream stacks can reference it without duplicating the configuration.”

Common Mistakes to Avoid

Confusing “project” and “stack” A project is the code; a stack is a deployed instance of that code. Saying “we have three projects for dev, staging, and prod” is incorrect if you have one codebase with three stacks. Say “we have one project with three stacks.”

Saying “apply” instead of “up” Terraform uses terraform apply; Pulumi uses pulumi up. In Pulumi discussions, say “run pulumi up” or “execute the update” — not “apply the changes,” which sounds like Terraform vocabulary.

Using “variable” instead of “output” or “config” Pulumi has specific terms: “config” for input configuration values and “output” for resource return values. Calling both of them “variables” is imprecise. Use the correct term for clarity.

Summary

Pulumi’s vocabulary — stacks, projects, programs, outputs, stack references, ComponentResources, and the Automation API — reflects its programming-language-native approach to infrastructure. Using these terms correctly helps you write clear infrastructure documentation, participate in the Pulumi community on Discord and GitHub, and collaborate effectively with DevOps engineers who use Pulumi daily. The Pulumi documentation and the Pulumi Examples repository on GitHub both use these terms consistently and are excellent resources for learning both Pulumi and professional DevOps English simultaneously.

Navigating Nuance: Common Phrasings for Collaboration

For developers learning professional English, particularly in a technical field like infrastructure as code, understanding subtle phrasing is just as important as knowing the definitions of individual words. It’s not enough to simply know what “stack reference” means; you need to understand how and when it’s used within a team workflow. Often, misunderstandings arise from differences in expectations around communication – for instance, the level of detail required in a comment on a code review, or the tone appropriate when requesting changes.

One frequent area of confusion stems from the shift between describing what something does and why it’s done. A simple statement like “This component needs to be updated” might not convey enough information. A more helpful phrasing, particularly in a pull request description, would be “Updating this ComponentResource is necessary to align with the latest security best practices outlined in our team’s standard operating procedures.” This adds context: it’s not just about changing code; it’s about adhering to established guidelines. Similarly, when responding to feedback, avoid simply saying “Okay.” Instead, acknowledge the concern and explain your reasoning: “I appreciate you pointing out the potential performance impact. I’ve added a caching layer to mitigate this, as detailed in the updated documentation.”

Another common pitfall is the use of overly technical language when communicating with non-technical stakeholders. While precision is vital within a DevOps team, explaining complex concepts in jargon can be alienating. Framing your work in terms that are accessible – for example, describing a Pulumi program’s output as “the information needed to deploy and configure our servers” – significantly improves understanding and collaboration. And remember, proactive communication is key; anticipating potential questions and addressing them upfront can prevent misunderstandings before they escalate.

Finally, be mindful of the tone you use when requesting changes or providing feedback. Phrases like “You need to fix this” can come across as demanding. Instead, opt for suggestions like “Could we explore refactoring this section to improve readability?” or “I was wondering if we could consider using a different approach here – perhaps leveraging [specific Pulumi feature]?” These softer approaches foster a more collaborative and productive environment.

Here’s an example of how you might use pulumi type=azure:resource in a CLI context, illustrating the output:

pulumi up --output-url https://example.com/outputs

This command demonstrates the use of the --output-url flag to direct Pulumi’s generated outputs to a specific location. Understanding how such flags are used and their implications (e.g., accessibility, versioning) is crucial for effective collaboration within an infrastructure as code project.