Blueprint lifecycle
Discover and deploy
Section titled “Discover and deploy”The console catalogue contains public Blueprints and Blueprints maintained for your Team. A Blueprint preview shows its topology, inputs, and runtime commitments before it changes an Environment.
Configure and operate
Section titled “Configure and operate”The author owns application architecture: images, internal wiring, and pinned dependencies. The deploying Team supplies declared arguments and owns permitted operational controls. Select the Blueprint node on the Environment canvas to:
- change ordinary arguments;
- rotate secret arguments;
- set maximum CPU, memory, and replicas for managed Components;
- configure alert policy; and
- inspect health and available upgrades.
Upgrade
Section titled “Upgrade”Blueprint versions are pinned. An upgrade is never silently substituted. Review the available version and resulting Environment diff before applying it.
For a production deployment, fork a disposable preview-* Environment first,
apply the upgrade to its Blueprint node, and exercise the resulting application
and data together. Apply that same pinned version to production only after it
has passed your checks, then delete the preview. This tests the Blueprint’s
complete topology rather than only its primary container.
A maintainer may upgrade nested dependencies in their Blueprint release without requiring deployers to wire those dependencies individually.
Author and publish
Section titled “Author and publish”Author Blueprints under Blueprints → Manage. Validate and preview a version before release, then choose its audience:
- Private: visible only while maintaining it;
- Team: discoverable by members of the publishing Team; or
- Public: discoverable by every Team.
Team Blueprints follow the same validation, preview, deploy, and upgrade path as public Blueprints.
Compose
Section titled “Compose”A higher-level Blueprint can pin another Blueprint as a dependency. The parent author maps its own contract to the child and exposes only the inputs and outputs deployers need. Nesting does not ask the customer to deploy or wire each child.
Detach into a private copy
Section titled “Detach into a private copy”Creating a private copy is a power-user escape hatch for deep modification. The copy becomes independently maintained, does not receive upstream upgrades, and does not masquerade as the original author’s release.