Skip to content
podmaker docs

The plan lifecycle

A plan is a YAML description of a topology. The lifecycle takes it from an interview answer to reconciled infrastructure, with verifiable hand-offs in between.

1. Generate

Terminal window
pdctl plan generate

A short interview produces a plan in three cost archetypes:

  • ECONOMY — smallest viable footprint.
  • BALANCED — sensible production defaults.
  • PERFORMANCE — headroom and redundancy.

2. Inspect before you spend

Terminal window
pdctl plan estimate plan.yaml     # monthly cost
pdctl plan inspect  plan.yaml     # node-by-node analysis
pdctl plan validate plan.yaml     # schema check

Compare alternatives, or diff two plan files or two Git refs:

Terminal window
pdctl plan compare a.yaml b.yaml
pdctl plan diff a.yaml b.yaml                       # two files
pdctl plan diff --git-a main --git-b feature/bigger-db \
                --path plan.yaml                    # two Git refs

Once a topology is live, project its cost against a budget:

Terminal window
pdctl plan budget <topology-id>

3. Customise

Terminal window
pdctl plan customise plan.yaml        # interactive editor
pdctl plan inspect plan.yaml --ai    # AI-explained breakdown

4. Apply and watch

Terminal window
pdctl plan apply plan.yaml
pdctl plan watch <topology-id>            # live SSE rollout
pdctl plan dashboard <topology-id> \
            --tail-logs --ai              # live TUI + AI summary
pdctl plan show <topology-id>

If something looks wrong:

Terminal window
pdctl plan rollback <topology-id>

5. Publish, sign, verify, replay

For repeatable deploys across clusters, bundle the plan. plan publish writes manifest.sha256 plus provenance.json and, when cosign is on PATH, signs the manifest:

Terminal window
pdctl plan publish plan.yaml              # bundle + manifest + provenance + cosign
pdctl plan publish plan.yaml --keyless    # Sigstore keyless (Fulcio + Rekor)

In CI the --keyless flow auto-detects the GitHub Actions OIDC token, so bundles are signed without managing keys. The bundle is content-addressed; anyone with it can verify and re-apply without trusting the channel it arrived on:

Terminal window
pdctl plan verify ./bundle                # check files against manifest.sha256
pdctl plan replay ./bundle                # re-apply on another cluster

This is how the same topology reaches many clusters without drift: publish once, verify everywhere, replay deterministically. For multi-cluster plans, the publish step can also emit per-cluster slices for a GitOps controller (ArgoCD / Flux) and render cross-cluster federation — see Kubernetes & Mesh.