Create and Manage Pipelines in the Console

Create a pipeline in the console, configure build and deploy commands, and view deployment records. To deploy locally through the CLI or Cloud API, see CLI and Cloud API Deployment Reference. For a first deployment you want to run end to end, see Tutorial: Deploy the Sample Project.

Prerequisites

The project root contains a cloudbaserc.json that declares the resources to deploy. For field descriptions, see Configuration file.

Create a pipeline

Create a pipeline on the Pipeline page of the console. Configure basic settings, deployment settings, and advanced settings in order.

Basic settings

Item	Description
Pipeline name	Lowercase letters, digits, and hyphens only. Starts with a lowercase letter, no consecutive hyphens, at most 30 characters
Trigger	See Triggers
Git repository	Select the repository type, organization, repository, and branch in order. If authorization is missing or expired, the page prompts you to reauthorize
Auto deploy	When enabled, pushing code to the linked repository triggers a build and deployment
Container specification	CPU and memory of the build container, fixed at a 1:2 ratio

Triggers

Trigger	Description
Git repository	Supports personal and public repositories. Authorize once and reuse globally. Pushing code can update the deployment automatically
Code package	Upload a code package to trigger a deployment

With a Git trigger, the pipeline pulls the latest commit of the selected branch and deploys it. GitHub, Gitee, and CNB are supported.

Build environment

The build environment has Node.js, Python, Go, Docker, and CloudBase CLI preinstalled. The CLI is already logged in, so you do not need to configure keys.

Deployment settings: command mode

The command mode decides which commands the pipeline runs in the build environment. There are two modes: simple commands and custom steps.

Mode	When to use
Simple commands	The project follows three steps: install dependencies → build → deploy, and the default flow is enough
Custom steps	You need extra steps beyond the three, such as preprocessing, image builds, or notifications

Simple commands

Item	Description
Target directory	Directory of the project code. Defaults to the root ./. For a project in a subdirectory, enter a relative path such as ./frontend
Install command	Installs project dependencies, such as npm install. Leave empty if no installation is needed
Build command	Compiles and packages the project, such as npm run build. Leave empty if no build is needed
Deploy command	Required. Defaults to tcb deploy --yes

The deploy command defaults to tcb deploy, which deploys Cloud Functions, cloud apps, Static Hosting, and gateway resources in one pass, according to cloudbaserc.json. For deployment rules, see Declarative deployment (tcb deploy). For the configuration file, see Configuration file.

⚠️ tcb deploy does not run the local build for Static Hosting. When hosting in cloudbaserc.json has a buildCommand, set the build command to tcb app build, or generate the outputDir directory in your own build command. If outputDir already exists, tcb deploy uploads its contents as they are and does not warn that the artifacts are outdated. See tcb app build.

⚠️ tcb app build does not install dependencies. Dependencies must be installed in the hosting[].root directory. When the frontend project is in a subdirectory, point the install command to that directory, for example npm install --prefix web. Running npm install in the repository root makes tcb app build fail with "node_modules not detected".

Example: the frontend project is in web/, and hosting[].root in cloudbaserc.json is ./web.

Item	Value
Install command	npm install --prefix web
Build command	tcb app build
Deploy command	tcb deploy --yes

If the project is in the repository root, set the install command to npm install.

When hosting[].deployPath is a subpath such as /pipeline-demo, the asset paths of the frontend build must match it. For a Vite project, set base: './' in vite.config.js. Otherwise, requests for /assets/* return 404. tcb validate warns about this.

Custom steps

Custom steps split the deployment into multiple steps that run in order. Each step has a name and a command.

Use custom steps to:

• Generate configuration files or environment variables before deployment
• Build and push Docker images (when a command contains docker build or docker push, the build environment provides a Docker service)
• Call a webhook for notification after deployment

Custom steps can still deploy resources with CLI commands such as tcb deploy, tcb app deploy, and tcb cloudrun deploy.

tcb deploy does not deploy CloudBase Run. When one pipeline run must deploy Cloud Functions, Static Hosting, gateway, and CloudBase Run together, split it into multiple steps:

Step name	Command
install-web	npm install --prefix web
build-web	tcb app build
deploy-declarative	tcb deploy --yes
deploy-cloudrun	tcb cloudrun deploy -s demo-run --source ./cloudrun/demo-run --port 3000 --force --yes --wait

For the CloudBase Run command parameters, see Deploy CloudBase Run.

Advanced settings: environment variables

Environment variables are injected at build time. Three input methods are supported:

Input method	Description
Visual input	Enter keys and values one by one
JSON input	Enter multiple variables as a JSON object
Configuration file input	Enter multiple variables from a configuration file

Build and deploy commands can read these environment variables directly.

Pre-deploy confirmation

After you click Deploy, the page shows the target type and resource list of this deployment. After you confirm, existing resources are overwritten and new resources are created.

After confirmation, the page jumps to the build log of that version.

View deployments

Pipeline information

After deployment, the pipeline information page shows the result of each resource, such as the Static Hosting access URL, Cloud Functions, and HTTP gateway.

A static site deployed through hosting in cloudbaserc.json is under the deployPath directory in Console: Static Hosting → File Management. It does not appear in the Apps list. Only sites deployed through app are apps. See Two deployment forms of Static Hosting.

Deployment variables and the auto deploy switch are also set here.

Deployment versions

The version list shows the version, time, status, and target of each deployment. Click a version to view:

• Version details: trigger, operator, Git commit, and build log
• Deployed resources: all resources of this deployment, down to the instance name

If new commits are pushed to the same branch during a build, only the latest commit is deployed after the current build finishes, and queued builds are canceled.

Manage pipelines

Update a pipeline

Use this to switch the production branch or change build commands.

After you save the changes, they take effect at the next trigger. A deployment is not triggered automatically.

Redeploy

Use this to retry failed builds or dependency pull errors.

Redeploying rebuilds with the original code of that deployment (the commit SHA for Git, or the originally uploaded file for a code package).

Auto deploy

The auto deploy switch takes effect immediately without a rebuild.

FAQ

How does the pipeline handle a change of the production Git branch?

Change the Git branch in the pipeline settings. It takes effect after saving. The next push to the new branch triggers a production deployment. To apply it immediately, trigger a deployment manually.

Deploy only some resources of a project

Change the deploy command in the pipeline settings to specify the deploy directory, save, and trigger the deployment again.

Does the pipeline keep build artifacts?

No. Each resource manages its own artifacts (code packages, images, static files). Static Hosting has no versions, and every deployment overwrites the previous one.

Are private repositories on an enterprise intranet supported?

Not supported.