skills/deploy-to-cloud-engine/SKILL.md
Deploys an already-built Internet Computer project to a user's own cloud engine (an OpenCloud / control-panel engine, administered from a web console). Covers verifying the icp CLI, linking the user's console identity to the CLI with `icp identity link web`, defaulting the console origin to https://opencloud.org (overridable when the user signs in to a different console), obtaining the engine's subnet id (asking the user when it is unknown), running `icp deploy` against that subnet, and tagging the canisters with `__META_*` environment variables so the engine console shows a named app with labelled backend/frontend canisters. Use when a developer wants to ship an app to their cloud engine, mentions a cloud engine, OpenCloud, an engine subnet id, linking the icp CLI to an engine console, or giving a deployed app a name in the console. Do NOT use for a general mainnet deploy with no specific engine or subnet (use the icp-cli skill) or for writing canister code.
npx skillsauth add dfinity/icskills deploy-to-cloud-engineInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
A cloud engine is a user-owned slice of Internet Computer capacity, administered from a web console (by default https://opencloud.org). Each engine runs on a single subnet. This skill takes a project that already builds and gets it deployed onto that engine, from a coding agent.
This skill only covers the cloud-engine-specific steps: linking the CLI to the engine's console identity, and a subnet-targeted deploy. For everything else about the CLI (icp.yaml, recipes, environments, bindings, identities), load the icp-cli skill.
Before running any icp command you are unsure of, run icp <subcommand> --help (e.g. icp identity link --help, icp deploy --help) to confirm the command and flags exist. Do not infer flags. Authoritative reference: https://cli.internetcomputer.org/llms.txt
Two values. Look for them first in icp.yaml or earlier in the conversation. One has a default; the other you must ask for:
https://opencloud.org (the main OpenCloud console). It is used as the --auth origin in Step 1 so the linked CLI identity derives the same principal that administers the engine. Use the default, but say so and give the user a chance to override before linking:
https://opencloud.org, the default console. If you sign in to your engine console at a different URL, tell me now."--auth origin determines the derived principal (see Pitfall 2).icp deploy --subnet. There is no default; never guess it. The user finds it on the engine's App Center / Applications page in the console. If absent, ask and do not proceed without it:
Record both so you do not re-ask within the session.
icp on $PATH — see the icp-cli skill to install. Verify with icp --version (this skill's commands are verified against 0.3.0).icp-cli skill), then return here.The CLI must sign as the same identity that administers the engine — that is the principal you log in to the console with.
First check what already exists:
icp identity list # names + principals; * marks the active identity
The list does not show which console (if any) an identity was linked against — that cannot be determined from the CLI. Decide like this:
anonymous (or plain local identities) listed — no web-linked identity exists; run the link command below.To link, run this, substituting a name the user picks — <your-identity-name> is any local label, not a fixed value (do not hardcode something like my-engine-admin); reuse the same name in every command below:
icp identity link web <your-identity-name> --auth <console-origin>
Use https://opencloud.org as <console-origin> unless the user named a different console. Never omit --auth: the flag has a built-in default (https://id.ai) that is not your console and silently derives the wrong principal.
The command first waits at a "Press Enter to log in" prompt before anything happens. Run it interactively when you can; in a non-interactive shell (e.g. a background process) pipe a real newline:
printf '\n' | icp identity link web <your-identity-name> --auth <console-origin>
Do not redirect stdin from /dev/null — the bare EOF does not satisfy the prompt, and the command sits on "Press Enter to log in" indefinitely with no browser ever opening.
After Enter it opens a browser tab. The user completes the Internet Identity sign-in there. Wait for them to confirm before continuing — you cannot complete the sign-in for them.
--auth must be the exact console origin (scheme + host), e.g. https://opencloud.org. A mismatched origin derives a different principal, and the engine will reject the deploy as unauthorized.
This is a one-time, per-machine step.
Then make it the active identity and verify:
icp identity default <your-identity-name>
icp identity default # prints the active identity name
icp identity principal # prints the principal the deploy will sign as
By default, CLI-deployed canisters appear on the engine console's Applications page as bare rows labelled only by their principal id. Three canister environment variables make the console group them into a single named application with readable per-canister labels and an "Open" button. Set them once in your project config:
__META_PROJECT — the application name. Canisters that share the same value are grouped into one named app, so set an identical value on every canister of the app.__META_NAME — the per-canister display label (e.g. Backend, Frontend).__META_MAIN_CANISTER — the literal string "true" on the single entry-point canister (usually the frontend/asset canister). That canister gets the "Open" button and the app's public URL.Set them under each canister's settings.environment_variables — this is valid alongside a recipe. With per-canister canister.yaml files:
# frontend/canister.yaml
name: frontend
recipe:
type: "@dfinity/[email protected]"
configuration:
build:
- npm install
- npm run build
dir: dist
settings:
environment_variables:
__META_PROJECT: "My App"
__META_NAME: "Frontend"
__META_MAIN_CANISTER: "true"
# backend/canister.yaml
name: backend
recipe:
type: "@dfinity/[email protected]"
configuration:
main: src/main.mo
settings:
environment_variables:
__META_PROJECT: "My App"
__META_NAME: "Backend"
For a single inline icp.yaml (canisters defined there directly), put the same settings.environment_variables block under each canister entry. Note the inline form: canisters is an array of {name, recipe, settings} items, not a map keyed by canister name:
# icp.yaml — canisters defined inline
canisters:
- name: frontend
recipe: # … as in the canister.yaml example above
settings:
environment_variables:
__META_PROJECT: "My App"
__META_NAME: "Frontend"
__META_MAIN_CANISTER: "true"
- name: backend
recipe: # … as in the canister.yaml example above
settings:
environment_variables:
__META_PROJECT: "My App"
__META_NAME: "Backend"
Notes:
PUBLIC_CANISTER_ID:<name> variables it injects automatically at deploy time — the asset canister keeps serving and the app keeps working. (Verified against icp-cli 0.3.0.)__META_MAIN_CANISTER must be the exact string "true".icp deploy (the "Setting environment variables" step). After deploy, confirm with icp canister settings show <name> -e ic.From the project root:
icp deploy -e ic --subnet <subnet-id>
-e ic targets mainnet (the engine runs on an IC subnet); --subnet <subnet-id> pins the deploy to your engine's subnet. Confirm the exact flags with icp deploy --help before running if unsure.Alternative — packaged upload. If the project is distributed as a built .icp package and a direct icp deploy is not available, upload the bundle on the console's App Center via "Upload a custom app" instead.
icp deploy output reports the deployed canister ids.__META_PROJECT name with their __META_NAME labels, and the main canister shows an "Open" button — instead of bare principal rows.https://<frontend-canister-id>.icp0.io.Report the deployed canister ids (and the frontend URL, if any) back to the user.
icp identity link web … but not finishing the Internet Identity sign-in in the browser leaves the CLI unlinked; later commands fail with authorization errors. Re-run and wait for the user to confirm the browser flow finished. If no browser ever opened, the command is stalled at the "Press Enter to log in" prompt — relaunch with a piped newline, printf '\n' | icp identity link web …, never < /dev/null (see Step 1).--auth origin. Using any URL other than the console origin the user signs in with derives a different principal, and the engine rejects the deploy as not authorized. Relink with the exact console URL. If the deploy is rejected as unauthorized after linking against the default https://opencloud.org, ask the user for the exact URL they sign in with and relink.icp identity default <your-identity-name> first.dfx. This ecosystem uses icp, never dfx. The correct sequence is icp identity link web <name> --auth <console-origin> (Step 1), then icp deploy -e ic --subnet <subnet-id> (Step 3). See the icp-cli skill.__META_PROJECT (Step 2), the canisters still deploy and work but render as bare, unnamed principal rows in the console. Setting __META_* is what produces a named app with labelled canisters and an "Open" button.__META_MAIN_CANISTER value. It is matched as the exact string "true". A boolean, "True", or marking more than one canister means no (or the wrong) "Open" button. Mark exactly one entry-point canister.icp.yaml, recipes, environments, bindings, identities). Load it for anything beyond this cloud-engine deploy flow.tools
Guides use of the icp command-line tool for building and deploying Internet Computer applications. Covers project configuration (icp.yaml), recipes, environments, canister lifecycle, and identity management. Use when building, deploying, or managing any IC project. Use when the user mentions icp, dfx, canister deployment, local network, or project setup. Do NOT use for canister-level programming patterns like access control, inter-canister calls, or stable memory — use domain-specific skills instead.
development
Deploy frontend assets to the IC. Covers certified assets, SPA routing with .ic-assets.json5, content encoding, and programmatic uploads. Use when hosting a frontend, deploying static files, or setting up SPA routing on IC. Do NOT use for canister-level code patterns or custom domain setup — use custom-domains instead.
development
One-time installer that makes a Claude Code project keep its Internet Computer skills up to date automatically. Sets up a SessionStart hook plus a sync script so .claude/skills/ always mirrors the latest skills published at skills.internetcomputer.org. Use when a user wants to install, bootstrap, or enable "always-latest" Internet Computer / IC / ICP / Motoko skills in a project, or pastes the link to this skill. This is a one-time setup action, not ongoing IC knowledge — after it runs, the installed hook keeps skills current on every session. Do NOT use for IC coding questions themselves — this only configures auto-updating skills.
development
Integrate Internet Identity authentication. Covers passkey and OpenID sign-in flows, delegation handling, and principal-per-app isolation. Use when adding sign-in, login, auth, passkeys, or Internet Identity to a frontend or canister. Do NOT use for wallet integration or ICRC signer flows — use wallet-integration instead.