Manage a Blueprint
Once a Blueprint is deployed, manage it from its node on the Environment canvas. The instance remains pinned to the version you chose until you approve an upgrade.
Change settings and limits
Section titled “Change settings and limits”Select the Blueprint node to:
- change ordinary arguments;
- rotate secret arguments;
- set maximum CPU, memory, and replicas for Blueprint Components;
- configure alert policy; and
- inspect health and available upgrades.
The maintainer controls the application architecture, images, internal wiring, and pinned dependencies. Your Team controls the exposed settings and the operational limits applied to its instance.
Upgrade safely
Section titled “Upgrade safely”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.
Share a Blueprint with others
Section titled “Share a Blueprint with others”Create Blueprints under Blueprints → Manage. Validate and preview a version before releasing it, then choose who can discover it:
- 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.
Follow Author a Blueprint for the complete contract, candidate, preview, release, and audience workflow.
Reuse another Blueprint
Section titled “Reuse another Blueprint”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.
Take full ownership of a copy
Section titled “Take full ownership of a 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.