# Manage a Blueprint

Change settings, set resource limits, test upgrades, and publish Blueprints for others.

Canonical: https://docs.deliberate.space/blueprints/lifecycle/

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

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

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

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](/blueprints/authoring/) for the complete contract,
candidate, preview, release, and audience workflow.

## 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

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.

## Next steps

- [Author and release a Blueprint](/blueprints/authoring/)
- [Test an upgrade in a preview Environment](/deploy/environments/)
- [Configure alerts for the deployed instance](/operate/alerts/)