Core 02 · CI/CD & Environments

Turn any running workload into a reusable blueprint.

Capture a workload that already runs — spec, config, dependencies — as a versioned, parametrized blueprint. Then let any team self-serve it to any cluster from a golden-path catalog. No rewrite, no copy-pasted YAML.

Capture a blueprint → See how it works

✓ From a live workload
✓ Versioned & parametrized
✓ Self-serve catalog

Inspect

Read a running workload's spec, config & dependencies.

Capture

Snapshot it into a versioned blueprint — no hand-written YAML.

Parametrize

Expose env, replicas & resources as safe inputs.

Reuse

Publish to a catalog — any team, any cluster, self-serve.

How a blueprint is made

From a running service to a self-serve template

Inspect

Start from what already runs

Point Atmosly at a live workload. It reads the deployment, services, config, and dependencies as they actually exist — no greenfield manifest required.

Reads real specs, not idealized templates
Captures config maps, secrets refs & dependencies

deploy/checkout-apiread

+ svc, configmap, hpa✓

dependencies · 3resolved

Capture & version

Snapshot into a versioned blueprint

Atmosly captures the workload as a blueprint with a version. Update the source and cut a new version — every deploy traces back to a known, reviewable definition.

Versioned — no snowflake one-off manifests
Diffable history between blueprint versions

blueprint · checkout-apiv3

changed · replicas, limitsvs v2

published✓

Parametrize

Expose the knobs that matter — and only those

Decide what's configurable: environment, replicas, resources, image tag. Everything else stays locked to the golden path, so self-serve never means free-for-all.

Typed inputs with sane defaults & bounds
Everything else stays on the golden path

input · environmentenum

input · replicas (1–6)default 2

locked · security ctx✓

Publish

Drop it in the catalog for self-serve

Publish the blueprint and any team can deploy it to any cluster — through the same guardrails and audit trail as everything else. No ticket, no platform-team bottleneck.

Self-serve from a catalog — no ticket queue
Deploys run through guardrails + audit trail

catalog · checkout-api v3live

deployed by · 4 teams✓

targets · 6 clusters✓

What a blueprint gives you

Golden paths, not copy-pasted YAML

The reusable, governed building block that turns one good setup into the standard everyone ships.

Versioned & diffable

Every blueprint carries a version with a readable history. Promote v3, compare it to v2, roll back if you need to — the same discipline as code, for deploys.

checkout-api · v3current

diff vs v2 · replicas, limits2 changes

Parametrized, within bounds

Expose exactly the inputs a team should touch — environment, replicas, resources — with types, defaults, and bounds. Everything else stays locked to the golden path.

replicas (1–6)default 2

security contextlocked

Self-serve catalog

Any team deploys from the catalog without filing a ticket or waiting on the platform team.

Any cluster, any cloud

One blueprint targets EKS, GKE, AKS or on-prem — no per-environment fork.

Guardrails built in

Every self-serve deploy runs through the same policy checks and audit trail as the rest of the platform.

Pairs with the Pipeline Builder

A blueprint is the deployable unit your pipelines promote and your preview environments clone — capture it once, and the rest of the CI/CD core reuses it everywhere.

The payoff

What changes when deploys are blueprints

Any service

becomes deployable CD — no rewrite

Self-serve

teams ship without a platform-team ticket

Versioned

every deploy traces to a reviewable definition

copy-pasted snowflake manifests

Same control plane

Workload Blueprints is one of three cores

Capture, ship, and run share one UI, one audit trail, and one permissions model.

Questions

What teams ask about blueprints

How is a blueprint different from a Helm chart?

A blueprint is captured from a workload that already runs, not authored from scratch — so it reflects reality on day one. It carries golden-path defaults, typed inputs with bounds, and the platform's guardrails, and it can wrap Helm charts where you already use them.

Does capturing a blueprint change my running workload?

No. Capture is a read of the live spec — it produces a reusable definition without touching what's running. Changes only happen when someone deploys the blueprint, through the usual guardrails.

Is self-serve safe for non-platform teams?

Yes — that's the point of parametrizing. Teams only touch the inputs you expose, with types and bounds you set; everything else stays locked to the golden path. Every deploy still runs through guardrails and lands in the audit trail.

Can I version and roll back blueprints?

Yes. Blueprints are versioned with a diffable history. Promote a new version, compare it to the last, and roll back if needed — every deploy traces to a specific, reviewable version.

From the blog