Differences from Cloud Native Build

About 527 wordsAbout 2 min

Essential Relationship

Workspace is essentially a Cloud Native Build pipeline with service.vscode declared.

Both share the same underlying execution mechanism — defined via .cnb.yml, scheduled by the Cloud Native Build engine, and supporting stages, docker, imports, and other configuration options.

Core Differences

Item	Cloud Native Build	Workspace
Purpose	Automated build, test, and deploy	Remote development and code writing
Declaration	Define any trigger event in `.cnb.yml`	Declare `service.vscode` in the pipeline
Default Image	`cnbcool/default-build-env`	`cnbcool/default-dev-env`
Node Assignment	Build nodes	Dev nodes
Billing	Cloud Native Build usage	Workspace usage

For detailed environment information, see Build Environment. For node details, see Build Nodes. For billing, see Pricing.

For easier access, the repository branch page provides a 「Workspace」button. Clicking it triggers a Workspace event (vscode), and the system automatically creates a pipeline with service.vscode and starts the development environment.

Starting a Dev Environment in Non-vscode Events

Not only vscode events can create development environments — declaring service.vscode in any pipeline also starts a Workspace environment.

For example, automatically creating a development environment and sending a notification when a branch is created:

.cnb.yml
feature/**:
  # Branch creation
  branch.create:
    - services:
        # Declare the vscode service to create a Workspace environment
        - vscode
        # Import environment variables from a secret repo file (e.g. WeCom robot address)
      imports: https://cnb.cool/<your-repo-slug>/-/blob/main/xxx/envs.yml
      stages:
        - name: notify
          image: tencentcom/wecom-message
          settings:
            robot: $ROBOT
            content: |
              Your environment is ready～

              [$CNB_BRANCH]($CNB_VSCODE_WEB_URL)

For more trigger options, see Customizing the Dev Environment Creation Process.

Auto-Recycling and Timeout

Cloud Native Build pipelines have a maximum execution time of 20h, after which they are automatically destroyed. Workspace environments have a maximum retention time of 18h, plus the following recycling mechanisms:

Heartbeat detection: If no one enters the VSCode page within 10 minutes after creation, or if there is no activity within 10 minutes after closing the page, the environment is automatically recycled.
No overnight policy: If in use for over 8 hours and the time falls between 4-6 AM, the environment is forcibly recycled.

For details, see Workspace Recycling.

Code Backup and File Roaming

Workspace environments are designed for on-demand usage with automatic cleanup when idle. To prevent code loss, the following mechanisms are provided:

Code backup: When an environment is destroyed, uncommitted code (including stash, unpushed commits, and workspace changes) is automatically backed up and restored when the environment is rebuilt.
File roaming: Non-workspace config files such as IDE settings and .gitconfig roam across environments, no reconfiguration needed.

For details, see Code Backup and File Roaming.

Business Port Preview

Workspace environments support previewing running business services by accessing their ports. You can use the WebIDE's PORTS panel or VSCode/Cursor client's port forwarding feature.

For details, see Business Port Preview.