Pulumi Kubernetes: A Guide to Infrastructure as Code

Your team already has deep expertise in languages like Python, TypeScript, and Go. Instead of forcing them to learn a domain-specific language or wrestle with complex YAML templating, you can empower them to manage infrastructure with the tools they use every day. This is the core value of Pulumi Kubernetes: it allows you to define, deploy, and manage your clusters and workloads using general-purpose programming languages. This approach treats your infrastructure with the same rigor as your application code, enabling you to apply standard practices like version control, automated testing, and code reuse, ultimately breaking down the silos between development and operations.

Key takeaways:

• Use familiar languages to build reliable infrastructure: Pulumi lets you define Kubernetes resources with languages like Python or TypeScript, allowing you to apply standard software practices like testing and version control to prevent configuration errors.
• Standardize deployments with reusable code: Move beyond repetitive YAML by creating functions and classes that encapsulate common infrastructure patterns. This reduces boilerplate, enforces consistency, and makes your configurations easier to manage.
• Orchestrate Pulumi runs at scale with a platform: For managing multiple clusters, use a platform like Plural to automate Pulumi deployments through a GitOps workflow. Plural Stacks provide a centralized, API-driven way to manage runs, enforce policies, and maintain control over your entire fleet.

What Is Pulumi for Kubernetes?

Pulumi is an Infrastructure as Code (IaC) platform that lets you define and manage Kubernetes infrastructure using general-purpose programming languages instead of static YAML or proprietary DSLs. With the Pulumi Kubernetes provider, you can model everything from individual Pods to entire clusters in TypeScript, Python, Go, C#, or Java.

The core shift is architectural: infrastructure becomes a first-class software artifact. Kubernetes objects are defined as code, versioned in Git, tested, reviewed, and promoted through CI/CD pipelines the same way application services are.

Pulumi also supports provisioning underlying cloud infrastructure and Kubernetes workloads in a single program. For example, you can create a VPC, provision a managed Kubernetes cluster such as Google Kubernetes Engine, configure node pools, and deploy application workloads—without switching tools or state backends. This unifies cloud and cluster lifecycle management and reduces cross-tool drift.

What Is IaC?

IaC is the practice of declaring desired infrastructure state in source code and reconciling actual state against it using an automation engine. Instead of manually configuring environments through a cloud console or imperative scripts, you define resources declaratively.

Key properties of IaC:

• Deterministic, repeatable environments
• Version-controlled infrastructure definitions
• Peer-reviewed changes via pull requests
• Automated provisioning and updates
• Reduced configuration drift and human error

Pulumi evaluates your program, builds a resource graph, computes a diff against current state, and applies the minimal set of changes required to converge to the desired configuration.

How Pulumi Uses Programming Languages

Pulumi’s distinguishing characteristic is that infrastructure is defined in real programming languages rather than a custom DSL. You can use:

• TypeScript
• Python
• Go
• C#
• Java

Because these are full languages, you can use:

• Loops and conditionals to generate resources dynamically
• Functions and classes to encapsulate patterns
• Modules and packages for reuse
• Native testing frameworks for validation
• Standard IDE tooling and debuggers

For example, you can implement a reusable function that provisions a Deployment, Service, and Ingress for a microservice, parameterized by image, replicas, and environment variables. That abstraction can then be reused across services without duplicating YAML.

This enables higher-level constructs that are difficult to express cleanly in templating systems.

Defining Kubernetes Resources with Pulumi

The Pulumi Kubernetes provider maps Kubernetes API objects to strongly typed classes in your chosen language. Each resource—Deployment, Service, ConfigMap, CustomResourceDefinition, or any CRD-backed object—is instantiated directly in code.

Under the hood:

1. Your program defines the desired resource graph.
2. Pulumi communicates with the Kubernetes API server.
3. It computes a diff between declared and actual cluster state.
4. It applies changes to converge state safely.

This model moves you beyond static manifests. You can express dependencies explicitly, compose higher-level abstractions, and generate dynamic configurations programmatically—while still targeting the native Kubernetes API.

The result is Kubernetes management that behaves like software engineering rather than configuration management.

How Pulumi Simplifies Kubernetes Management

Kubernetes management at scale often degrades into YAML sprawl: duplicated manifests, environment overlays, and fragile templating. As workloads grow, maintaining consistency across environments and preventing configuration drift becomes operationally expensive.

Pulumi replaces static manifest management with programmable infrastructure. Kubernetes resources are defined in TypeScript, Python, Go, C#, or Java, turning cluster configuration into a maintainable software project. You can build abstractions, enforce conventions, and compose reusable components instead of copying YAML blocks across repositories.

This shifts Kubernetes management from file templating to structured, testable code.

Tame Configuration Complexity and Drift

YAML duplication is a structural problem. For example, every microservice typically requires a Deployment, Service, and optionally an Ingress, along with labels, resource limits, and environment configuration. In Pulumi, you encapsulate that pattern in a reusable function or class and instantiate it per service.

This yields:

• Elimination of boilerplate duplication
• Centralized control of platform standards
• Explicit dependency modeling
• Strongly typed resource definitions

Pulumi maintains state and computes diffs against live cluster state before applying changes. Drift becomes detectable and correctable through controlled updates rather than manual reconciliation.

When integrated with Plural, Pulumi executions can be orchestrated through API-driven workflows. Plural enforces standardized rollouts and ensures drift-free configurations are applied consistently across clusters, reducing environment skew across fleets.

Use Standard Coding Practices and Testing

Because infrastructure is defined in a real programming language, you inherit the full language ecosystem:

• IDE support with type checking and autocompletion
• Linting and static analysis
• Unit tests for infrastructure logic
• Integration tests against ephemeral environments

You can validate that abstractions generate expected Kubernetes resources before anything reaches production. Infrastructure changes move through CI pipelines like application code, increasing confidence and reducing regression risk.

This aligns directly with Plural’s PR automation model. Infrastructure updates are validated through CI, reviewed via pull requests, and promoted using controlled workflows. Testing and policy enforcement happen before cluster mutation.

Improve Collaboration with Version Control

Infrastructure defined in code lives in Git, becoming the authoritative source of truth. Every change is traceable, reviewable, and auditable.

Instead of modifying live clusters imperatively:

1. A change is proposed via pull request.
2. CI validates the update.
3. Reviewers approve the change.
4. Automation applies it deterministically.

This workflow reduces operational silos and enforces governance without slowing delivery.

Plural builds on GitOps principles to coordinate these workflows across environments and clusters. By combining Pulumi’s programmable infrastructure model with Plural’s fleet-level orchestration, teams get a scalable, transparent, and policy-driven Kubernetes management system.

What Languages Can You Use with Pulumi?

Pulumi differentiates itself by using general-purpose programming languages instead of a DSL such as HCL. Infrastructure is authored in the same languages used to build production services, enabling type safety, modular design, automated testing, and full IDE support.

This reduces cognitive overhead and eliminates the need for a separate IaC-specific toolchain. Engineers can apply established software engineering practices—linting, dependency management, abstraction, CI validation—to Kubernetes infrastructure.

Pulumi’s primary supported languages include:

• Python
• TypeScript / JavaScript
• Go
• C#
• Java

When combined with Plural’s GitOps-driven orchestration, this language-native model allows infrastructure workflows to integrate directly into standard development pipelines. Engineers remain in their preferred ecosystem while Plural coordinates deployments across clusters and environments.

Manage Kubernetes with Python

Python is widely used across backend services, automation, and data systems. Pulumi’s Python SDK allows teams to define Kubernetes resources using familiar syntax and tooling.

Benefits include:

• Clear, expressive resource definitions
• Access to Python packaging and virtual environments
• Native unit testing with pytest or unittest
• Dynamic infrastructure generation using functions and classes

For Python-centric teams, infrastructure code becomes a natural extension of the application codebase rather than a separate configuration domain.

Use TypeScript and JavaScript

Pulumi provides first-class support for both TypeScript and JavaScript. TypeScript, in particular, offers strong compile-time guarantees that help surface configuration errors before deployment.

Advantages include:

• Static typing for Kubernetes resource definitions
• npm/yarn ecosystem integration
• Modular architecture using classes and interfaces
• Familiar Node.js-based workflows

This lowers the barrier for frontend and full-stack teams to participate in infrastructure management without switching languages.

Leverage Go and C#

Go and C# provide strongly typed, compiled environments suited for large-scale systems.

Go offers:

• Static typing and explicit struct definitions
• Strong concurrency primitives
• Alignment with the Kubernetes ecosystem

C# enables:

• Deep integration with the .NET ecosystem
• Visual Studio tooling
• Unified solutions containing both app and infrastructure code

For organizations standardized on Go or .NET, Pulumi enables Kubernetes infrastructure to be authored within the same language boundaries as core services.

Across all supported languages, the outcome is consistent: infrastructure becomes structured, testable, and composable software. When orchestrated through Plural, these language-defined stacks can be promoted, validated, and enforced across fleets using standardized PR-driven workflows.

Get Started with Pulumi and Kubernetes

Getting started with Pulumi for Kubernetes involves three core steps: install the CLI, initialize a project, and deploy a resource. The workflow replaces ad hoc kubectl apply operations with a repeatable, code-driven deployment model.

Pulumi executes infrastructure programs locally (or in CI), computes a resource graph, previews changes, and reconciles desired state against the target cluster.

Install the Pulumi CLI

Install the Pulumi CLI for your operating system. Then ensure a supported runtime is available:

• Node.js (for TypeScript/JavaScript)
• Python
• Go
• .NET (for C#)
• Java

Pulumi uses your existing Kubernetes context. If kubectl is configured and points to a cluster via your kubeconfig file, Pulumi will use that same context by default. No separate credential layer is required unless explicitly configured.

Typical setup flow:

1. Install Pulumi CLI.
2. Install language runtime and package manager.
3. Authenticate to a Pulumi backend (Pulumi Cloud or self-managed state).
4. Verify cluster access with kubectl config current-context.

At this point, your local environment is ready to manage Kubernetes resources programmatically.

Set Up Your First Kubernetes Project

A Pulumi project is a directory containing:

• A Pulumi.yaml project definition
• A program entry point (e.g., index.ts, __main__.py, main.go)
• Dependency configuration (package.json, requirements.txt, go.mod, etc.)

Initialize a project:

pulumi new kubernetes-typescript

or

pulumi new kubernetes-python

The template scaffolds a minimal project with the Kubernetes SDK dependency preconfigured. From here, infrastructure and application-level cloud resources can coexist in the same codebase—VPCs, managed clusters, and Kubernetes workloads can all be defined in one program.

This unified model reduces cross-tool fragmentation between cloud provisioning and in-cluster deployment.

Create and Deploy Your First Resource

Define Kubernetes resources using the Pulumi Kubernetes SDK. For example, you can declare:

• Deployments
• Services
• ConfigMaps
• Ingress resources
• Helm charts
• Custom resources

Your program expresses the desired state. When you run:

pulumi up

Pulumi performs:

1. A preview (diff against current state)
2. Dependency graph evaluation
3. Targeted updates to converge state

The preview step is critical—it provides deterministic visibility into changes before mutation.

In production environments, this workflow is typically automated. Plural Stacks can orchestrate Pulumi executions based on Git events, embedding infrastructure updates into a GitOps pipeline. Pulumi handles resource graph computation and state reconciliation; Plural coordinates promotion, policy enforcement, and multi-cluster rollout.

The result is a controlled, auditable, and repeatable Kubernetes delivery workflow.

How Pulumi Manages Kubernetes State

State management is fundamental to any Infrastructure as Code system. Without an authoritative record of provisioned resources and their configuration, safe updates, deletions, and dependency-aware changes are impossible.

Pulumi manages Kubernetes state through:

• Persistent state files and backends
• Automatic dependency graph construction
• Deterministic diffing and drift reconciliation

Together, these mechanisms ensure the live cluster converges toward the declared state in code.

State Files and Backends

Pulumi records managed resources in a state file (JSON). This file maps logical resources in your program to their corresponding physical resources in the cluster or cloud provider. It also stores metadata required for diffs, updates, and deletions.

State can be stored:

• Locally (file-based backend)
• In object storage (e.g., S3-compatible backends)
• In the managed Pulumi Cloud backend

For teams, a remote backend is required. It provides:

• Centralized state visibility
• Concurrency control via state locking
• Audit history of updates

Without locking, concurrent pulumi up operations could corrupt state or cause conflicting updates. The backend enforces serialized mutations to maintain consistency.

Resource Dependencies and Execution Order

Pulumi builds a resource dependency graph at runtime. Dependencies are inferred from:

• Explicit references between resources
• Input/output property relationships
• Declared dependsOn constraints

For example, if a Deployment references a ConfigMap output, Pulumi establishes an edge in the graph. During updates, it performs a topological sort to determine execution order.

This guarantees:

• Prerequisites are created before dependents
• Updates propagate safely
• Deletions occur in reverse dependency order

The engine computes minimal diffs and applies changes incrementally, reducing blast radius and preventing race conditions common in manual or script-driven deployments.

Drift Detection and Reconciliation

Drift occurs when cluster state diverges from declared state—often due to manual kubectl changes or external controllers modifying resources.

During pulumi up, Pulumi:

1. Reads current state from the backend.
2. Queries live resource state from the Kubernetes API.
3. Computes a diff against the desired configuration.
4. Produces a preview of corrective actions.

If discrepancies are found, Pulumi proposes updates to reconcile the environment back to the declared state.

This preserves code as the authoritative source of truth.

At fleet scale, Plural extends this model by orchestrating Pulumi executions within a GitOps framework. Drift detection becomes continuous, and reconciliation is automated across clusters through API-driven workflows. Pulumi ensures deterministic state convergence; Plural ensures consistent enforcement across environments.

Key Pulumi Features for Kubernetes Automation

Pulumi extends Infrastructure as Code beyond static configuration by leveraging general-purpose programming languages. For platform teams managing Kubernetes fleets, this enables enforceable standards, composable abstractions, and scalable automation.

The following capabilities are particularly relevant for Kubernetes-heavy environments.

Policy as Code

Pulumi supports Policy as Code through programmable policy packs. Policies are authored in TypeScript or Python and evaluated during previews and updates, allowing violations to be caught before resources are created or modified.

Typical enforcement patterns include:

• Restricting container images to approved registries
• Requiring CPU and memory limits
• Blocking privileged containers
• Enforcing labeling and tagging standards

Policies execute at deployment time, preventing non-compliant infrastructure from being applied.

In a broader governance model, this complements runtime enforcement mechanisms such as OPA Gatekeeper. Within a Plural-managed fleet, Pulumi policies can prevent invalid infrastructure from being merged, while cluster-level admission controls enforce compliance continuously. This creates layered policy enforcement across both CI and runtime.

Multi-Cluster and Multi-Cloud Management

Pulumi can provision and manage Kubernetes clusters and workloads across major cloud providers, including:

• Amazon EKS
• Azure AKS
• Google GKE

Clusters across providers can be defined in a single codebase, with environment-specific parameters injected via configuration. This supports hybrid and multi-cloud strategies without fragmenting tooling.

Because Pulumi models infrastructure as code rather than provider-specific templates, abstractions can span clouds while still allowing provider-native configuration when required.

When combined with Plural’s agent-based deployment architecture, this enables centralized orchestration of distributed clusters. Pulumi defines infrastructure consistently; Plural coordinates GitOps-driven rollouts and lifecycle management across the fleet.

Reusable Infrastructure Components

Pulumi enables higher-level abstractions through functions, classes, and packages. Instead of duplicating Kubernetes manifests, teams can encapsulate patterns into reusable components.

For example, a platform team can define a standardized service component that provisions:

• A Deployment with enforced resource limits
• A Service with consistent labeling
• An Ingress with predefined security annotations

This component can then be parameterized and reused across services.

Benefits include:

• Elimination of YAML duplication
• Centralized enforcement of platform conventions
• Reduced configuration drift
• Faster onboarding for application teams

Integrated with Plural’s self-service workflows, these components can be exposed through PR-driven automation. Developers request infrastructure via code changes; Pulumi enforces structure and dependencies; Plural manages rollout and promotion across clusters.

The result is a programmable, policy-aware Kubernetes automation system that scales with organizational complexity.

Best Practices for Using Pulumi with Kubernetes

Adopting Pulumi for Kubernetes management is a solid first step. To harness its power for scalable and secure infrastructure, you need to follow established best practices. These guidelines help prevent common pitfalls, improve team collaboration, and ensure your deployments are consistent and reliable. By structuring your projects logically, handling secrets securely, and automating your deployment pipeline, you can build a robust foundation for managing your Kubernetes resources with code.

Organize Projects and Configure Stacks

A well-organized Pulumi project is the foundation for maintainable infrastructure code. Structure your code into projects and stacks. A project should contain a related set of resources, like a single application. Within that project, stacks represent isolated instances of your infrastructure, corresponding to environments like development, staging, and production. This separation prevents changes in one environment from affecting another and simplifies configuration management. A logical structure makes it easier for your team to understand, review, and contribute to the codebase as your infrastructure grows.

Manage Secrets and Security

Handling sensitive data like API keys and database credentials requires careful attention. Never commit secrets in plaintext to version control or expose them as environment variables, where they can be leaked in logs. Instead, use a dedicated secrets management solution. Pulumi provides built-in encryption for secrets, which encrypts sensitive values in your state file. For more robust security, integrate with external secret stores like HashiCorp Vault or AWS Secrets Manager. This approach centralizes secret management and ensures your Pulumi code only references secrets, rather than storing them directly.

Integrate with Your CI/CD Pipeline

To achieve consistent and repeatable deployments, integrate Pulumi into your CI/CD pipeline. This automation reduces human error and enforces a standard deployment process. A typical CI/CD setup runs pulumi preview on every pull request to show proposed changes for review. Once merged, the pipeline automatically runs pulumi up to apply them. This GitOps-style workflow creates a clear audit trail and ensures your infrastructure state always matches your codebase.

Plural's API-driven Stacks provide a scalable framework for this. By defining a stack declaratively, you can automate Pulumi runs on each commit, creating a seamless, self-service workflow for your entire team.

How Does Pulumi Compare to Other Kubernetes Tools?

Pulumi offers a distinct approach to Kubernetes management by using general-purpose programming languages to define and deploy infrastructure. While it shares the goal of simplifying configuration with tools like Helm and Kustomize, its scope and methodology are fundamentally different. Understanding these differences helps clarify where Pulumi fits into a modern cloud-native toolchain. It’s not always about replacing existing tools but rather leveraging the right tool for the job, and in many cases, using them together.

Pulumi vs. Helm and Kustomize

Helm and Kustomize are designed to solve the problem of managing Kubernetes YAML files. Helm acts as a package manager, bundling YAML manifests into reusable "charts" that can be configured with a values.yaml file. Kustomize, on the other hand, provides a template-free way to customize raw YAML for different environments. Both are excellent for packaging and distributing applications on Kubernetes.

Pulumi operates at a different level of abstraction. Instead of templating YAML, it allows you to define your entire cloud infrastructure—including Kubernetes clusters, networking, and databases—using languages like Python or Go. This means you can manage not just the application configuration but the underlying resources as well, all within a single, unified codebase. Pulumi can also work alongside existing tools; for instance, you can use it to deploy Helm charts, combining the power of programmatic infrastructure with the convenience of pre-packaged applications.

When to Choose Pulumi Over YAML

YAML is the native language of the Kubernetes API, and for simple applications, it works well. However, as your infrastructure grows, managing hundreds or thousands of lines of YAML becomes difficult. You end up with repetition, a lack of abstraction, and no easy way to implement logic. This is where Pulumi provides a clear advantage.

By using a real programming language, you can apply standard software engineering practices to your infrastructure. You can create reusable functions and classes to build modular components, use loops to generate multiple resources, and apply conditional logic to tailor deployments for different environments. This approach reduces boilerplate code, minimizes errors, and makes your infrastructure definitions more maintainable and easier to test.

Integrate Pulumi into Existing Workflows

Adopting a new tool often raises concerns about migrating existing infrastructure. Pulumi is designed for incremental adoption, allowing you to integrate it into your current workflow without a complete overhaul. You don't need to rewrite everything from scratch. Instead, you can start by managing a single new component or application with Pulumi while leaving your existing resources untouched.

Pulumi can also import existing infrastructure that was created manually or with other tools. This feature lets you bring your current Kubernetes resources under Pulumi's management, allowing you to manage their lifecycle programmatically from that point forward. Because Pulumi works with the Kubernetes API, it integrates smoothly with tools like kubectl and fits naturally into CI/CD pipelines like GitHub Actions or GitLab. This flexibility makes it possible to introduce Pulumi's benefits to your team gradually, without disrupting established processes.

Scale Kubernetes Management with an Enterprise Platform

While Pulumi provides a powerful framework for defining Kubernetes resources with code, managing those resources across a large fleet of clusters introduces a new set of challenges. As an organization scales, the complexity shifts from defining individual resources to orchestrating deployments, enforcing standards, and maintaining security and compliance across dozens or hundreds of environments. Simply running pulumi up from a developer’s laptop is no longer a viable or secure option.

At scale, teams face significant operational hurdles. Managing separate state files and backends for each environment becomes cumbersome and error-prone. Distributing secrets and configuration values securely across a fleet requires a robust management system to prevent leaks or misconfigurations. Furthermore, ensuring that every cluster adheres to organizational security policies, RBAC rules, and compliance standards is nearly impossible without a centralized control plane. Without one, configuration drift is inevitable, creating security vulnerabilities and operational instability. An enterprise platform provides the necessary layer of governance and automation to manage this complexity, allowing teams to move from managing individual clusters to strategically operating an entire fleet.

Integrate with GitOps for Fleet Management

Integrating Pulumi with a GitOps workflow is a standard practice for achieving consistent and automated deployments. In this model, a Git repository serves as the single source of truth for your desired infrastructure state, which is defined using Pulumi code. When changes are merged into the main branch, an automated process triggers a Pulumi run to reconcile the live environment with the state defined in Git. This creates a transparent and auditable trail for every infrastructure change.

For fleet management, this pattern requires a robust orchestration engine. A platform like Plural provides a GitOps-based continuous deployment system that automates this entire process at scale. It connects your Git repositories to your target clusters, ensuring that every change to your Pulumi code is automatically applied across the designated environments. This removes manual steps and enforces consistency, helping you manage multiple clusters as a single, cohesive unit.

How Plural Simplifies Pulumi at Scale

Plural is designed to operationalize Infrastructure as Code tools like Pulumi across an entire Kubernetes fleet. It achieves this through Plural Stacks, an API-driven framework for managing IaC runs in a Kubernetes-native way. Instead of building custom CI/CD pipelines to execute Pulumi, you can declaratively define a Stack that points to your Pulumi code in a Git repository and targets a specific cluster for execution.

On every commit, Plural automatically creates and executes a run, capturing outputs and state within its unified UI. For pull requests, it executes a "plan" and posts the results directly to the PR for review. This workflow gives you fine-grained control over permissions and network location for each run, ensuring that sensitive operations are executed securely. By providing a standardized, API-driven mechanism for Pulumi, Plural simplifies orchestration and allows you to manage infrastructure changes with the same rigor and automation as your application code.

Related Articles

• Terraform vs Pulumi for Kubernetes: How to Choose
• Kubernetes Native Terraform Automation: A Guide
• Managing Kubernetes Infrastructure: 2024 Innovations
• Cloud Native DevOps with Kubernetes: A 2024 Guide

Frequently Asked Questions

If my team already knows YAML, why should we switch to a full programming language for Kubernetes? While YAML is the native format for Kubernetes, it can become difficult to manage as your applications grow. Using a language like Python or TypeScript allows you to apply standard software engineering practices to your infrastructure. You can create reusable functions to eliminate repetitive code, write automated tests to catch errors before deployment, and use loops and logic to build dynamic configurations. This approach makes your infrastructure more reliable and easier to maintain over time.

Can I use Pulumi without throwing away all my existing Helm charts? Absolutely. Pulumi is designed to integrate with your existing tools, not force a complete rewrite. You can deploy Helm charts directly from your Pulumi code, allowing you to manage their release lifecycle programmatically. This gives you the power of a real programming language for orchestration while still leveraging the convenience of pre-packaged applications from the Helm ecosystem. You can adopt Pulumi incrementally, starting with one new service or component.

How does Pulumi prevent different team members from overwriting each other's infrastructure changes? Pulumi manages this through its state management system. For team collaboration, you use a remote backend, like an S3 bucket or the Pulumi Service, to store the infrastructure's state file. This backend acts as a single source of truth and supports state locking. When one team member runs an update, the state is locked, preventing others from making conflicting changes simultaneously and ensuring your deployments are safe and predictable.

What's the best way to manage different environments like dev, staging, and production with Pulumi? Pulumi uses a concept called "stacks" to manage separate environments. A stack is an isolated instance of your infrastructure. You can have a dev stack, a staging stack, and a prod stack, all created from the same codebase but with different configurations. This allows you to test changes in a development environment before promoting the exact same code to production, ensuring consistency across your entire release pipeline.

How does running pulumi up on my laptop scale to managing a whole fleet of clusters? It doesn't, and that's where an orchestration platform becomes essential. Running commands locally works for small projects, but it isn't a secure or scalable solution for managing production infrastructure across many clusters. A platform like Plural operationalizes Pulumi through an API-driven framework called Plural Stacks. This automates Pulumi runs based on Git commits, manages state and secrets securely, and provides a centralized control plane to ensure every change is applied consistently and safely across your entire fleet.