Differences from Cloud Native Build

About 504 wordsAbout 2 min

Differences from Cloud Native Build explains how Workspaces relates to Cloud Native Build and where they differ.

When to use: when you need to decide between a workspace and a build, or wonder why the two are billed separately.

Essential Relationship

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

Both share the same underlying execution mechanism: configured through .cnb.yml, scheduled by the Cloud Native Build engine, and supporting stages, docker, imports, and other 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 environments see Build Environment, for nodes see Build Nodes, and for billing see Pricing.

The repository branch page provides a 「Workspace」button. Clicking it triggers a Workspace event (vscode), and the system 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
(**):
  branch.create:
    - services:
        - vscode
      stages:
        - name: Environment Ready
          script: echo "$CNB_BRANCH dev environment is ready"

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

Auto-Recycling and Timeout

Cloud Native Build pipelines run for up to 20h and are then destroyed automatically; Workspace environments are kept for up to 18h. Workspaces additionally have these recycling rules:

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

Workspaces are used on demand and cleaned up automatically when idle. To prevent code loss:

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

For details, see Code Backup and File Roaming.

Business Port Preview

Workspaces support previewing business ports, through the WebIDE PORTS panel or the VSCode/Cursor client's port forwarding feature.

For details, see Business Port Preview.