Templates

Templates are curated workspaces your enterprise publishes as starting points for new projects. When someone creates a new workspace from a template, the new workspace opens with the template's files, structure, rulesets, MCP servers, and file tags already in place. Anyone creating a new workspace from a template can focus on the changes specific to their project instead of setting up the same scaffolding every time.

Any workspace can become a template. A workspace built around a Lambda + S3 reference pattern, a landing-zone baseline, or a vendor-specific integration are all good candidates.

Marking a workspace as a template

There are two ways to promote a workspace to a template.

From the workspace card. On any workspace card or list row, open the three-dot menu and choose Convert to → Template. The workspace's kind switches to Template immediately.

From workspace settings. Open the workspace, go to Settings, and choose Template in the kind picker.

You can convert in either direction. A template can be converted back to a regular workspace at any time. A template can also be converted directly to a module if you have both permissions.

Visibility

Templates show up in two places.

The Templates tab in your enterprise. Anyone with view permission for templates sees the full list and can open any template to inspect its files.
The From template chip in the workspace create flow. The picker is a live search over every template the creator can see.

Visibility follows the same model as regular workspaces, with one addition. A user can see a template if any of the following are true.

They are a member of the template workspace
They have the Templates: view permission on the enterprise

This means an enterprise administrator can publish a template once, grant the view permission to a role, and every member of that role can use the template without being added to each one individually.

What gets inherited

When someone creates a new workspace from a template, the new workspace starts with the template's working tree already in place. Every file is there from the moment it opens. The new workspace also inherits the template's rulesets, MCP servers, and file tags.

The new workspace does NOT inherit the template's commit history, compliance evaluation history, or members. Each clone starts fresh in those areas.

If the template was connected to a GitHub repository, the new workspace does not automatically inherit that connection. The new workspace starts local-only, and the creator can connect it to a new repository later if they want to.

Permissions

Two permissions control what someone can do with templates.

Templates: view lets the user see templates they are not a member of, browse the Templates tab, and pick from the full inventory in the create-from-template chip.
Templates: manage lets the user mark a workspace as a template or remove its template status. Combined with the Modules: manage permission, the same user can also convert directly between template and module kinds.

Default role assignments grant view to all enterprise members so the create-from-template chip is useful from day one. Manage is more restrictive and is typically granted to maintainers, owners, and administrators.

Direct conversion between template and module

If you have both Templates: manage and Modules: manage, the Convert to menu lets you switch a workspace directly between Template and Module without going through the regular workspace state in between. The audit log captures this as a single intentional transition.

If you only have one of the two permissions, you can promote to your side and demote back to a regular workspace, but you cannot cross over.

Best practices

Make templates self-contained. A template should open and run without the consumer hunting down hidden context. If a template uses enterprise modules, the template's own files should already reference them so the new workspace works as soon as it opens.
Use descriptive names and descriptions. Both show up in the From template picker; the description is what helps someone choose between similar starting points.
Keep templates current. Templates do not auto-update workspaces that were already created from them. When you change a template, only future clones see the change.
Match templates to scope. A template for an application's full Lambda + S3 pipeline is different from a single reusable Lambda module. Reusable building blocks belong in Modules.