Workspace Templates

A workspace template is a reusable configuration for creating Remote Workspaces. You define the coding agents, dependencies, network policy, and an optional setup script once, and every workspace provisioned from the template gets the same environment.

Templates help your team standardize workspaces: the same toolchain, the same resource sizing, and the same security posture for everyone, without each person configuring their workspace by hand.

When a new Remote Workspace is created for your organization, the workspace is provisioned from a template — the template decides the resources it gets, the tools installed, and the network policy applied. Templates are managed from the Kimchi console, and every change to them is recorded in the Audit Log.

Open the Workspace Templates page

In the Kimchi console, open the Workspace Templates page. It lives in the Remote group of the sidebar, next to Remote Sessions and Remote Credentials.

The page lists all templates in your organization:

Use the ⋯ menu on a row to Edit or Delete the template. Which actions are available depends on your role — see User Roles.

Create a template

Coding agents

Choose which agent CLIs are preinstalled in every workspace created from the template:

Enable or disable Claude Code and Codex with their switches. Agent CLIs are installed into the workspace alongside Kimchi, so sessions created from the template can use them immediately.

Dependencies

Dependencies are packages installed when a workspace created from the template starts. They are passed to the workspace agent through the WORKSPACE_DEPENDENCIES environment variable.

Add a dependency by selecting a curated package from the catalog or typing a free-form name:

For catalog packages, pick Latest or a curated version from the dropdown. Free-form entries use the devkit grammar [registry:]tool[@version] — for example aws-cli, aws-cli@2, or npm:[email protected]. Scoped packages keep the full @scope/name string.

Use lowercase letters, digits, and -_. in dependency names.

Network policy

The network policy controls which external destinations workspaces created from the template can reach. Choose one of four modes:

For the two list-based modes, add destinations — each rule is a domain or a CIDR block, with optional ports:

The policy applies to outbound traffic from the workspace. When a list is empty, "Allow only listed destinations" blocks everything and "Allow all except listed destinations" allows everything.

Setup script

A workspace template can carry a setup script — an optional bash script that runs when a workspace created from the template is provisioned, after its dependencies are installed.

#!/bin/bash
npm install

The script is stored as written: whitespace and formatting are preserved verbatim. Workspaces created from the template run it at boot, so you can tailor the environment for your team — install a project, pin a directory layout, or configure tools that are not covered by dependencies.

A script can be up to 64 KiB. Scripts that exceed the limit are rejected when the template is saved. A template without a setup script provisions workspaces without running one.

Edit a template

Select Edit from the row's ⋯ menu. Change the description, dependencies, agents, network policy, or setup script, then select Save changes.

The template name is immutable and cannot be edited — it identifies the template everywhere it is referenced.

Delete a template

Select Delete from the row's ⋯ menu and confirm in the dialog. Deleted templates can no longer be used for new workspaces. The deletion is recorded in the Audit Log with the user who performed it.

See also

• Remote Workspaces — Workspaces and sessions, /teleport, and Remote Execution.
• Web IDE — A full browser-based IDE for your Remote Workspace.
• Audit Log — Every change to your workspaces and workspace templates, recorded with who made it and what changed.
• User Roles — Manage who can view and change workspace templates.