Infra Stacks
An Infra Chart defines what you can deploy — a reusable template with parameterized placeholders. But a template alone does not answer the questions that matter for a specific deployment: which region, which domain name, how many availability zones, which environment. An Infra Stack captures those answers. It is a configured instance of a template with your specific parameter values filled in, ready to deploy as real infrastructure.
The relationship mirrors how Helm works: an Infra Chart is to an Infra Stack as a Helm chart is to a Helm release. The chart is reusable; the stack is the deployed instance with specific values. This separation enables teams to capture infrastructure patterns once and instantiate them many times — across different environments, regions, or customers — each instance tracked as a distinct, versioned Infra Stack.
Why Infra Stacks Exist
Before Infra Stacks, the platform had Infra Charts for reusability but no persistent record of each deployment instance. Consider an organization that deploys five ECS environments from the same chart — development, staging, production-us, production-eu, and production-asia. Each uses different parameter values. Without a stack record, fundamental questions have no answers:
- Which parameters deployed production-us last month?
- Did staging update to the latest chart version?
- Who changed the load balancer domain in production-eu?
- Can we redeploy production-asia with last week's configuration?
Infra Stacks solve this by introducing a persistent, versioned record of every template instantiation. Each stack captures the chart's templates, the exact parameter values used, the environment, the rendered catalog object manifests, the dependency graph, and a link to every pipeline that deployed it. Pipelines are transient — they run and complete. Infra Stacks persist as the source of truth for what was configured and when.
One Chart, One Environment
You select an Infra Chart from the catalog, pick the environment it deploys into, provide parameter values, and the stack renders the chart's templates into concrete catalog object manifests.
When the stack is created, the complete template is copied from the chart into the stack. This ensures that chart updates do not break or silently change existing stacks — each stack is a self-contained snapshot of the template it was created from, and it can be checked out to disk and edited with no chart in reach.
The web console provides a creation wizard: browse the chart catalog, pick the environment, fill in the parameter form (auto-generated from the chart's parameter definitions), preview the rendered output, and deploy.
Automatic Pipeline Triggering
Creating or updating an Infra Stack starts an Infra Pipeline. The pipeline takes the stack's Infra Component dependency graph and executes deployments in the correct order. There is no separate "apply" step — an Infra Stack is the declaration of an environment's infrastructure, and the platform acts on it.
Deploying again without changing anything, and tearing the environment down, are explicit operations on the stack: deploy and undeploy are a pair, and both hand back the stack with the new run's id.
Dependency Graph Visualization
Each Infra Stack maintains a dependency graph that visualizes the relationships between its Infra Components. The web console displays this as an interactive DAG where you can see:
- Resource nodes with their current deployment status (queued, running, succeeded, failed)
- Dependency edges showing which resources must be deployed before others
- Real-time updates as a pipeline progresses through the graph
This visualization makes it easy to understand the deployment topology and diagnose failures — if a resource fails, you can immediately see which downstream resources are blocked.
Infra Stack Lifecycle
Create
Create an Infra Stack from a chart with the CLI:
planton chart install my-stack ./my-chart -f values.yaml --org <org> --env <env> -m "why"
A values file lists only the parameters it changes; every other parameter keeps the chart's value (see how parameter values resolve). Add --dry-run to see every parameter and the rendered documents first, without creating anything.
Or from the web console's chart catalog by selecting a chart, picking the environment, filling in parameters, and deploying. The message becomes the run's own name, so a person reading the run later knows why it happened.
Redeploy
Trigger a new pipeline without changing the stack's configuration. Useful for drift correction (re-applying desired state after manual cloud console changes), retrying after a failed deployment, or re-running after fixing external issues like quota limits or permissions:
planton infra stack deploy <stack-name-or-id>
Undeploy
Destroy all Infra Components owned by the stack without deleting the stack record. The stack configuration is preserved and can be redeployed later — useful for temporarily tearing down infrastructure to save costs:
planton infra stack undeploy <stack-name-or-id>
Purge
Destroy all Infra Components and delete the stack record permanently:
planton infra stack purge <stack-name-or-id>
Deleting an Infra Stack does not automatically destroy its infrastructure. You must explicitly undeploy first if the infrastructure should be removed. This is a deliberate safety measure — deleting a configuration record should never accidentally destroy production resources.
Using the CLI
# Create an Infra Stack from a chart (triggers deployment automatically)
planton chart install my-stack ./chart-dir -f values.yaml
# Deploy an existing stack (starts a deploy run and follows it)
planton infra stack deploy <stack-name-or-id>
# List pipelines for a stack
planton infra stack infra-pipelines <stack-name-or-id>
# Get the last pipeline for a stack
planton infra stack last-pipeline <stack-name-or-id>
# Undeploy (destroy resources, keep stack)
planton infra stack undeploy <stack-name-or-id>
# Purge (destroy resources and delete stack)
planton infra stack purge <stack-name-or-id>
# Get stack details
planton infra stack get <stack-name-or-id>
# Check a stack out as a chart-shaped folder you can edit and install again
planton infra stack checkout <stack-name-or-id>
When to Use Infra Stacks vs. Direct Infra Components
| Scenario | Recommended Approach |
|---|---|
| Complete environment (dev, staging, production) | Infra Stack — coordinated deployment, dependency handling, versioned configuration |
| Single resource needed quickly | Direct Infra Component — no orchestration overhead |
| Reproducible deployments | Infra Stack — configuration captured as a versioned artifact |
| Quick experiments | Direct Infra Component — fast iteration, easy to delete |
| Production infrastructure | Infra Stack — audit trails, parameter history, rollback capability |
| Adding to existing infrastructure | Direct Infra Component — targeted change without touching other resources |
Related Documentation
- Infra Charts — The templates that Infra Stacks instantiate
- Infra Pipelines — How Infra Stack deployments are orchestrated
- Infra Components — The deployed instances that Infra Stacks own and manage
- Infra Jobs — The atomic execution units within pipelines
- Flow Control — Governance policies that affect pipeline execution
Next article