icp-cli 1.2.0 Turns Deployment Intent Into an Explicit Safety Boundary

DFINITY released icp-cli 1.2.0 on July 23, introducing a set of changes that make deployment intent more explicit. The update is less about a new project template and more about reducing ambiguity at the point where local configuration becomes a live canister deployment.

The most important addition is icp canister link. It assigns an existing canister principal to a project canister, giving teams a direct way to connect a checked-out project to an already deployed resource. That is useful for recovery workflows, environment handoffs, and projects whose canister identities must remain stable across machines.

The release also adds icp canister create --with-icp. This route uses the Cycles Minting Canister to create canisters and is intended for restricted system subnets. It is not supported as part of icp deploy, which preserves a meaningful distinction between explicitly creating a canister through the command line and deploying an application through the normal project workflow.

A second safety-oriented change is icp deploy --no-create. With this flag, deployment fails if a declared canister does not already exist instead of silently creating it. In production pipelines, that turns an implicit resource-creation side effect into a checked precondition. Teams can therefore separate provisioning from code deployment and make an accidental new canister easier to detect.

The release also addresses a practical observability problem. icp deploy now prints a frontend URL for any canister exposing an http_request endpoint, including certified-asset canisters whose interface does not match the previously hard-coded signature. Frontend and Candid UI URLs are grouped separately, making deployment output easier to read and less likely to send a developer to the wrong endpoint.

For asset-heavy builds, plugin synchronization now exposes ICP_CLI_PLUGIN_COMPUTE_LIMIT_SECS, with a default of 60 seconds. A team can raise the limit for legitimate workloads such as Brotli compression on a large asset bundle. Invalid values are rejected, and timeout errors report both the variable and the active limit. That behavior is preferable to silently ignoring a malformed CI setting.

The practical lesson is to treat 1.2.0 as a deployment-policy release. Existing projects can use icp canister link when identity continuity matters, --no-create when provisioning must be controlled separately, and the plugin limit when build work is predictably expensive. Before standardizing the upgrade, teams should also note the evidence boundary: the release notes do not provide a compatibility matrix for existing project configurations, so teams should test icp-cli 1.2.0 in CI before making it the default deployment toolchain.

The current ICP quickstart documents @icp-sdk/icp-cli as the primary command-line tool for creating projects, starting local networks, deploying canisters, and calling Candid methods. That makes the new release relevant beyond a single command: it changes how developers can express ownership, provisioning, and deployment assumptions inside the same workflow.