Skip to navigation

Workspaces

View as Markdown

Workspaces are the fundamental organizational and authorization boundary in NeMo Helix. All platform resources—models, datasets, customization jobs, evaluation results, and more—must belong to a workspace.

When authentication is enabled, users are granted roles (Viewer, Editor, or Admin) within specific workspaces, and all resources within a workspace inherit its access controls.

Create separate workspaces when you need true isolation—for example, to separate teams (team-ml-research, team-nlp), individual users (user-jsmith), environments (dev, staging, production), or clients (client-acme). For lighter-weight organization within a workspace that does not require access separation, use projects.

Built-in Workspaces

The platform automatically creates two built-in workspaces during initialization:

  • default — General-purpose workspace for experimentation, editable by all authenticated users.
  • system — Reserved for platform-provided resources (for example, evaluation targets, customization templates). Read-only for regular users; only platform administrators can modify.

Create a Workspace

To create a workspace, provide a name and optionally a description. The name must be unique within your deployment.

Resource names must follow these rules:

  • Must start with a lowercase letter (a-z)
  • 2-63 characters long
  • Allowed characters: lowercase letters, digits, hyphens, and temporarily @, ., +, _
  • No consecutive hyphens (--)
  • Cannot end with a hyphen

Example valid names: my-model, llama-3.2-3b, test-config-v1

Once created, a workspace cannot be renamed—choose the name carefully. The description is a free-form text field to help identify the workspace’s purpose.

The system also generates a unique id (UUID) for internal use, but the name is the primary identifier used in API paths and SDK calls.

By default, any authenticated user can create a workspace because NeMo seeds a wildcard WorkspaceCreator role binding in the system workspace. The creator still automatically becomes Admin of the new workspace.

To restrict workspace creation, remove that wildcard WorkspaceCreator binding and grant the role only to the users or groups that should retain create access. This changes creation policy without changing the API surface.

from nemo_helix_plugin.client.client import NemoClient
from nemo_helix_plugin.workspaces.types import CreateWorkspaceRequest
client = NemoClient.from_config()
workspace = client.workspaces.create_workspace(
body=CreateWorkspaceRequest(
name="ml-team", description="Machine Learning Team workspace"
),
).data()

Restrict Workspace Creation

Workspace creation is now governed by RBAC instead of a hardcoded policy exception. The default seed creates this binding:

principal: *
workspace: system
role: WorkspaceCreator

To restrict workspace creation:

  1. Remove the wildcard WorkspaceCreator binding from system.
  2. Grant WorkspaceCreator only to the users or groups that should create workspaces.

Example:

nemo workspaces members update "*" \
--workspace system \
--roles Viewer
nemo workspaces members create \
--workspace system \
--principal ml-leads@bigcorp.com \
--roles WorkspaceCreator

Updating the wildcard member to Viewer preserves the seeded read-only access on system while revoking WorkspaceCreator.

List Workspaces

To list workspaces, call the list endpoint. When authentication is enabled, only workspaces the user has access to are returned. The response includes pagination metadata.

from nemo_helix_plugin.client.client import NemoClient
client = NemoClient.from_config()
for workspace in client.workspaces.list_workspaces().items():
print(f"{workspace.name}: {workspace.description}")

Get a Workspace

To retrieve a specific workspace by its name:

from nemo_helix_plugin.client.client import NemoClient
client = NemoClient.from_config()
workspace = client.workspaces.get_workspace(name="ml-team").data()

Update a Workspace

To update a workspace, only the description field can be modified. The name cannot be changed after creation.

from nemo_helix_plugin.client.client import NemoClient
from nemo_helix_plugin.workspaces.types import UpdateWorkspaceRequest
client = NemoClient.from_config()
workspace = client.workspaces.update_workspace(
name="ml-team",
body=UpdateWorkspaceRequest(
description="Updated: ML Team workspace for model development"
),
).data()

Delete a Workspace

Deleting a workspace revokes access immediately and asks an asynchronous cleanup controller to delete the remaining resources (jobs, deployments, filesets, and other entities). Role bindings are removed as part of that first step. The API returns Workspace marked for deletion, and the workspace disappears from get and list responses. Its name stays reserved until cleanup finishes.

If cleanup cannot delete a resource, the attempt is recorded and retried about every 60 seconds. A fileset that another workspace’s model or adapter still references is the common case: the files service returns 409, and the workspace stays in the failed stage with that error. Creating the same name then returns 409 saying the workspace is still being deleted, including the stored reason, instead of already exists.

The original creator, a platform admin, or a service principal can read that status:

nemo workspaces deletion-status team-a

To free the name, relink or delete the referencing model or adapter, then wait for the next cleanup retry.

from nemo_helix_plugin.client.client import NemoClient
client = NemoClient.from_config()
client.workspaces.delete_workspace(name="ml-team").data()