/cloudbase-declarative-deploy

name: cloudbase-declarative-deploy
description: CloudBase declarative deployment from a cloudbaserc config (声明式部署, 配置式部署, cloudbaserc 部署) through the deployBuild / deployPlan / deployApply MCP tools. Use when deploying database, functions, app, hosting, or gateway resources described in cloudbaserc.json/yaml as a single desired-state config, when a user wants to build static hosting artifacts locally first (deployBuild), or wants a dry-run plan before applying (deployPlan), or when handling multi-environment deploys via mode / envOverrides. Covers build-plan-apply flow (deployBuild local build → deployPlan dry-run → deployApply confirm=true), hosting build-output neutralization, envId resolution priority, only/skip filtering, concurrency, and continueOnError. Prefer deployBuild (when hosting declares a buildCommand) and deployPlan before deployApply; do not confuse with per-resource tcb CLI deploy or single-function deploy.
version: 2.36.1
license: MIT
alwaysApply: false

CloudBase Declarative Deploy

Deploy a whole CloudBase project from one `cloudbaserc` config as **desired state**, using the `deployBuild` (local hosting build), `deployPlan` (dry-run) and `deployApply` (apply) MCP tools. The orchestrator applies resources in a fixed dependency order:

database → functions → app → hosting → gateway

Sibling skills (local only)

Sibling CloudBase skills ship beside this skill. Use local relative paths such as `../cloudbase-cli/SKILL.md`.

Cloud-hosted MCP mode does not guarantee access to a local workspace filesystem or stable relative paths. If a referenced sibling file is not available in cloud mode, use this skill's embedded guidance as source of truth and ask the user for any missing constraints (or to install the missing skill). Do **not** HTTP-fetch remote skill or protocol markdown into the agent context.

**Cross-cutting protocols** (required before applying any deploy):

• Change Safety Protocol: `../cloudbase-platform/references/protocols/change-safety-protocol.md`
• Deployment Gate: `../cloudbase-platform/references/protocols/deployment-gate.md`

When to use this skill

• The project has a `cloudbaserc.json` / `.yaml` / `.yml` / `.js` describing multiple

resources, and the user wants to deploy them together as one config.

• The user asks for 声明式部署 / 配置式部署 / "deploy from cloudbaserc" / "deploy the whole project".
• The user wants to preview what a deploy will change before applying (dry-run plan).
• The user wants to build the static hosting artifact locally first (declarative

hosting deploys no longer build implicitly — see `deployBuild`).

• Multi-environment deploy: production/staging via `mode` + `envOverrides`.

Do NOT use for

• Deploying a single cloud function or one static site via `tcb` CLI → `../cloudbase-cli/SKILL.md`.
• In-app SDK integration (web/miniprogram/node) → the matching SDK skill.
• Console UI operations.

Cloud mode: deploy through the two-step upload channel

`deployBuild` / `deployPlan` / `deployApply` in this skill are the **local-form declarative executor**. In cloud-hosted MCP mode they are intentionally not registered, because that runtime has no local `cwd` and no filesystem-bound execution path.

This is an **execution-channel switch, not a capability gap**. Everything still deploys, but the artifact is uploaded first and the build runs in the cloud. If those three tools are missing from the tool list, that is expected — pick the channel that matches the resource.

Cloud functions — two-phase zip

1. `queryFunctions(action=getFunctionUploadUrl, functionName?)` returns `uploadUrl`, `uploadHeaders`, `cosBucketName`, `cosBucketRegion`, `cosObjectName`, `expiresInSeconds` 2. `PUT` the function zip to `uploadUrl` with `uploadHeaders` 3. `manageFunctions(action=createFunction|updateFunctionCode, code={cosBucketName, cosObjectName, cosBucketRegion?})` — phase B deploys from the environment's own COS bucket (`deployMode=cos`); pass the triple through unchanged, the schema is strict

`contentPath` (a local directory) is rejected in cloud mode. For layer contents use `base64Content`; for code use the two-phase path above.

CloudApp — two-step upload plus a cloud pipeline

1. `queryApps(action=getUploadUrl, serviceName=...)` returns `uploadUrl`, `uploadHeaders`, `unixTimestamp` 2. Upload the source/build zip to `uploadUrl` with the returned headers (`Content-Type: application/zip`)

• Public dependencies resolvable from a lockfile: `package.json` plus lockfile is enough
• Private or offline dependencies: package `node_modules` explicitly

3. `manageApps(action=deployApp, cosTimestamp=<unixTimestamp>, installCmd?, buildCmd?, deployCmd?)`

• `installCmd` / `buildCmd` / `deployCmd` are pipeline declarations executed in the cloud

container; you pass data and declarations, you do not run local shell commands

Static hosting — route through CloudApp

`manageHosting(action=upload)` is blocked in cloud mode because it needs a local path. Deploy a static site through the CloudApp two-step upload above (upload the prebuilt artifact, exclude `node_modules`). Uploading or downloading an already-hosted file has no remote substitute and needs local mode. The other hosting actions (`delete`, `setWebsiteDocument`, `enableService`, `bindDomain`, `unbindDomain`, `updateDomain`) remain available.

What cloud mode does not give you

• **No dry-run.** There is no `deployPlan` against a local `cloudbaserc`. Do not claim a plan

was generated or reviewed in cloud mode; state what is about to be deployed and what the upload contains. Roadmap: upload `cloudbaserc` as a data artifact, then run server-side plan/apply orchestration.

• **No local project context.** `mode` / `envOverrides` resolution from a project file does

not apply; pass the target environment explicitly.

For parameter details, see `references/plan-and-apply.md` (`Cloud-hosted upload pipeline path`).

Core principles

1. **Plan befor