Skip to main content

The Platform Stacks Repository

The platform-stacks repository is the catalog content layer — it is where stack definitions live before they are registered into the Control Plane.

What It Is​

This repository contains bundle.yaml files: declarative specs that describe how to deploy a piece of infrastructure or an application. Each bundle is the source of truth for a catalog entry — the spec that gets registered into the Control Plane, versioned, and eventually deployed into tenant workspaces.

The repository is not a running service. It is a git repo that platform engineers work in to author, review, and version stack definitions. Once a spec is ready, it is registered into the Control Plane's catalog — either manually through the UI or via an automated git sync flow.

Repository Structure​

platform-stacks/
├── stacks/
│   └── <provider>/<stack-name>/
│       ├── bundle.yaml          ← stack spec
│       └── components/          ← supporting files (Helm values, manifests)
└── composite-stacks/
    └── <name>/
        └── bundle.yaml          ← composite spec (references atomic stacks by slug)

How Expressions Work​

Stack specs use ${{ }} expressions that the Control Plane evaluates at deploy time — filling in user-supplied inputs, defaults, and outputs from upstream resources. For example, a Helm chart that needs a database connection string can reference ${{ deps.database.outputs.connection_url }} and the platform will resolve it once the database resource is active.

Secrets use a different syntax ({{ secret('key') }}) that is resolved by the Cluster Agent at execution time, directly from Kubernetes secrets in the cluster. Sensitive values never pass through the Control Plane.

Go Deeper​