Differences from Cloud Native Build

About 509 wordsAbout 2 min

Essential Relationship

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

Both share the same underlying execution mechanism — both are defined via .cnb.yml configuration files, scheduled by the Cloud Native Build engine, and both support 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.

Workspace Button

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 opens 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: After a development environment is created, if no one enters the VSCode page within 10 minutes, or if there is no activity within 10 minutes after the page is closed, the environment is automatically recycled.
No overnight policy: If the environment has been in use for more than 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, so you don't need to reconfigure them.

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.