Standalone sandbox

As the name suggests, a Standalone Sandbox is a sandbox that is not based on a Template.

A standalone sandbox is also known as Template builder sandbox in some contexts since it's useful for building a new Template. Even though a template is basically a YAML file internally (see Sandbox Definition), we find in practice it's much easier to have a sandbox handy to set it up. The configuration of a standalone sandbox can be updated quickly and the change can be immediately apply to the sandbox for further testing and iteration. Basically, the process is to adjust settings in this sandbox until it matches the expectation, and save the config as a template.

For example, the following figure shows a standalone sandbox created in the Template builder wizard from previous page.

From the sandbox, click the Edit button on the top right corner will get to the template editing view, as shown follows, here we can add a new component or click into any existing component for editing. After editing, you can click Apply to save the configuration to the sandbox.

You can also edit the configuration directly in YAML format by clicking Edit in YAML (see Sandbox Definition). After everything is properly setup, you can save the configuration as a template by clicking Save as Template. We recommend you try the config with a fresh new standalone sandbox before saving to verify the end-to-end process.

Apply changes

When clicking Apply, the changes of the configuration will be applied to the running sandbox instantly. However, due to the nature of individual configurations, some settings won't be applied to existing workloads:

Configurations	Workload Type	Reason/Comment
Checkout	Workspace	Checkouts are identified by the `path` properties. Existing checkouts (same `path`) won't be updated for the risk of loosing data. Newly added checkouts (with new `path` values) will be applied instantly.
Package	Workspace	When updated, packages are mounted to the workspaces instantly. However, some packages require the `PATH` environment to contains its `bin` folder. The environment of all running processes inside the workspace, including VSCode server, will not be changed, so they won't be able to see the updated package `bin` folder in the `PATH`.
Base Snapshot Home Snapshot Dependency Snapshot Container Snapshot	Workspace/Dependency/Container	Snapshots are life-time configurations, once workspace is created, they will never change.
Env	Workspace	All running processes including VSCode server will not be able to pickup environment changes. Only new processes will be affected.
Service Type and Version	Dependency	These are life-time configuration, and won't be changed after the dependency is created.
Properties	Dependency	This is service specific. In most cases, changing of properties of the running dependency won't have effect, unless the service process is restarted.

To make these configurations effective, the corresponding workload must be rebuilt, from the Sandbox details view, use the button on the workload card

Note: rebuilding a workload is equivalent to deleting the current workload and creating a new one. All persisted data will be discarded. And it's irreversible.