Development Workspaces¶

The Development sidebar entry provides each user with a private, browser-based development workspace for Triton model repositories. The workspace UI is powered by code-server and is embedded directly in Triton Control.

Prerequisites¶

Development workspaces are available only when Kubernetes support is enabled. The sidebar entry is disabled when Triton Control cannot perform Kubernetes actions.

Each authenticated user can own one workspace. Workspaces are isolated by ownership: the backend permits users to list, open, proxy, refresh, and delete only their own workspace.

The Kubernetes cluster must provide:

a default or otherwise matching StorageClass for the workspace PVC
permission for Triton Control to create StatefulSets, Services, ConfigMaps, Secrets, PVCs, and optional image pull Secrets
internet access from the workspace pod when code-server or marketplace extensions must be downloaded
NVIDIA GPU scheduling support when a GPU count is requested

Create a Workspace¶

Open Development in the sidebar and configure the workspace:

Field	Required	Default	Purpose
Workspace name	Yes	`workspace`	Name used to derive the user's Kubernetes resource names.
Triton development image	Yes	`nvcr.io/nvidia/tritonserver:26.06-py3`	Container image used for the workspace pod.
Image already has Development installed	No	disabled	Uses the `code-server` binary from the image instead of installing a standalone runtime during startup. Triton Control starts it on `0.0.0.0:8080`.
Workspace storage	Yes	`20Gi`	Persistent volume claim size mounted at `/workspace`.
VS Code theme	Yes	`Default Dark+`	Initial code-server color theme.
CPU request	No	unset	CPU request and limit for the workspace container.
Memory request	No	unset	Memory request and limit for the workspace container.
GPU count	No	unset	Adds an `nvidia.com/gpu` resource limit when greater than zero.
Registry credentials	No	unset	Docker `.dockerconfigjson` used to pull a private workspace image.

In this field, Development refers to the code-server runtime. Enable Image already has Development installed only if code-server is available on the image's PATH. Triton Control overrides the image startup command and starts that binary with --bind-addr 0.0.0.0:8080; the image does not need to start code-server itself. The resulting workspace must listen on container port 8080, which is also used by the Kubernetes Service and health probes. Otherwise workspace startup fails. When the option is disabled, the pod installs a standalone code-server runtime under /tmp/triton-control-code-server and starts it on the same port.

Creating a workspace provisions:

one StatefulSet with a single workspace pod
one internal Service on port 8080
one persistent volume claim mounted at /workspace
Secrets for workspace authentication mode and optional registry credentials
a ConfigMap containing the bundled Triton Control Deploy extension

The workspace is created in the Triton Control namespace when the backend runs inside Kubernetes. For an external backend, the namespace is selected from TRITON_CONTROL_NAMESPACE, KUBERNETES_NAMESPACE, or POD_NAMESPACE, with triton-control as the fallback.

Workspace Lifecycle¶

After creation, Triton Control polls the StatefulSet and pod until the workspace status becomes ready. The page then embeds code-server through the authenticated backend proxy:

/api/development/<workspace-id>/proxy/?folder=/workspace

Both HTTP and WebSocket traffic pass through this proxy. The code-server Service is therefore not exposed directly to the browser.

code-server webviews, including the bundled Triton Control Deploy extension, require a browser secure context. Use trusted HTTPS for non-localhost hosts. Plain http://triton-control.test can load the workspace, but plugin webviews may fail because browser crypto APIs are unavailable. HTTPS with an untrusted certificate can still fail when code-server registers its webview service worker. For local testing, http://localhost:<port> via kubectl port-forward also works.

Use Refresh to read the latest pod status. Use Delete to remove the managed StatefulSet, Service, Secrets, ConfigMap, and any legacy ingress.

Persistent volume retention

Deleting a Development workspace does not delete its Kubernetes PVC. Remove retained workspace claims separately when their data is no longer needed.

Persistent Files and Extensions¶

The /workspace directory is persistent. Triton Control also keeps code-server settings and user-installed extensions on that volume:

/workspace/.triton-control/code-server-settings.json
/workspace/.triton-control/code-server-extensions/

These files survive pod restarts while the PVC remains available. New workspaces receive the Python extension when its marketplace installation succeeds and the bundled Triton Control Deploy extension.

Triton Control starts code-server with Workspace Trust disabled. The managed /workspace folder is treated as the user's development area, so code-server does not prompt users to mark the folder as trusted on each new workspace.

S3 Profiles and Optional S3/R2 Explorer¶

The Triton Control Deploy extension works best with an S3 profile. Members and admins can create profiles from the Triton Control account menu under S3 Profiles. The extension loads those profiles and shows them in an S3 profile dropdown.

Use profiles for shared or repeated deployment settings. Each profile stores the endpoint, bucket, optional prefix, region, access key, encrypted secret key, path-style mode, and optional CA certificate.

Manual S3 settings are still available inside the extension in a collapsed section. Use them for one-off deployments or to save a new profile from inside code-server.

Optional: Install S3/R2 Explorer¶

S3/R2 Explorer is optional and is not installed automatically when a Development workspace is created. The Triton Control Deploy extension works without it because S3 profiles and manual settings are handled by Triton Control.

To add S3/R2 Explorer:

Open the Extensions view in the Development workspace.
Search the code-server extension marketplace for S3/R2 Explorer.
Select Install.
Open the extension settings and configure the S3-compatible endpoint, region, access key, secret key, and path-style behavior.

The installed extension is stored under /workspace/.triton-control/code-server-extensions and therefore survives workspace pod restarts while the PVC is retained.

When S3/R2 Explorer is installed and configured, its settings can still be used as defaults for manual extension fields:

Setting	Used for
`s3x.endpointUrl`	S3-compatible endpoint
`s3x.region`	S3 region
`s3x.accessKeyId`	Access key
`s3x.secretAccessKey`	Secret key
`s3x.forcePathStyle`	Path-style request mode

Use path-style access for compatible object stores that address objects as https://s3.example.com/bucket/key. Disable it only when the object store uses virtual-host addressing such as https://bucket.s3.example.com/key.

For a private or self-signed HTTPS object-store certificate, provide the PEM CA certificate requested by the extension. This certificate is passed to the Triton deployment so its model repository client can trust the endpoint.

Create a Model Repository¶

The bundled Triton Control Deploy extension can create starter Triton model repository structures in /workspace.

Open the Triton Control icon in the code-server Activity Bar and select New Model Repository. The same command is also available from the command palette and from the Explorer folder context menu.

The command asks for:

repository type: Single model or Ensemble pipeline
repository target folder name
model name for a single model, or ensemble name plus step names for an ensemble
template/backend selection

The target folder becomes the Triton repository root. Model, ensemble, and step names become folders inside that repository.

Single-model templates:

Python backend
ONNX Runtime
TensorRT plan
TensorRT-LLM
vLLM
PyTorch / LibTorch

Example single-model output:

/workspace/my-repository/
  preprocess/
    config.pbtxt
    1/
      model.py

Artifact-based templates create the model folder, config.pbtxt, a version folder, and editable README guidance explaining which model artifact must be provided before deployment.

Generated config.pbtxt files are templates. Review and update the real model name, backend/platform, input tensor names, output tensor names, shapes, and data types before deploying. The scaffold defaults are intentionally generic.

Ensemble scaffolding creates child model folders plus a separate ensemble model folder with platform: "ensemble" and editable ensemble_scheduling maps.

Example ensemble output:

/workspace/fraud-pipeline/
  preprocess/
    config.pbtxt
    1/
      model.py
  score/
    config.pbtxt
    1/
      README.md
  postprocess/
    config.pbtxt
    1/
      model.py
  fraud_detector/
    config.pbtxt

After creation, the repository appears both in Explorer and in the Triton Control Activity Bar view. The Triton Control view marks repositories as:

review model setup when placeholder artifact guidance or generated config.pbtxt template values are still present
ready to deploy when the scaffold placeholders are no longer detected

Select a repository row to switch to Explorer and reveal the real folder in the workspace filesystem. Use the repository context menu to open the setup README or config.pbtxt template. Review the model files and config before using the deploy action. Repositories marked ready to deploy expose deploy actions in the Triton Control view and context menu.

Repository discovery follows the filesystem. If a repository folder is deleted from Explorer or the terminal, it is removed from the Triton Control view after the filesystem watcher or the view refresh action runs.

Deploy a Model Repository¶

The Triton Control Deploy extension has two modes:

Triton Control: Deploy Model Repository opens the full webview form, uploads the repository to S3-compatible storage, and creates a self-deployed Triton instance.
Triton Control: Upload Model Repository (Simple Wizard) uses native code-server prompts instead of a webview. Use it when Triton Control is opened through plain HTTP or an untrusted local certificate. It uploads the repository and prints the Add Deployment values in the output panel; finish the deployment from Triton Control's Add Deployment page.

The full webview mode requires trusted HTTPS or localhost because code-server webviews use browser APIs and service workers that do not work on insecure origins.

Create or edit a Triton model repository under /workspace.
Confirm required model artifacts are present and config.pbtxt matches the real model inputs and outputs.
Use a ready to deploy repository from the Triton Control Activity Bar view, or right-click the repository root or a single model folder in Explorer and run Triton Control: Deploy Model Repository.
Select an S3 profile, or expand manual S3 settings for a one-off deploy.
Confirm the Triton image, detected backend summary, S3 upload target, model control mode, and optional resources.
After full webview deployment, Triton Control opens the new instance and its deployment logs.

A repository should follow Triton's model layout:

repository-root/
  model-name/
    config.pbtxt
    1/
      model.py

The extension reads the model name and backend from config.pbtxt. If no model name is present, it prompts for one. If no backend is declared, the detected backend summary shows No backend in config.pbtxt; otherwise it shows the configured backend, for example vLLM model backend.

Selecting a single model folder uploads it below the chosen repository prefix while keeping the deployment's s3_url at the parent repository prefix. The form shows an S3 upload target preview before deploy. Manual S3 deployments show the same final path as Target path at the end of the manual S3 section.

Model control is displayed as a summary and configured in the collapsed Model control section. Polling mode shows the poll interval field; Explicit mode hides it and uses the startup model behavior.

The resulting deployment behaves like one created through Add Deployment. Its in-pod S3 repository connection is fixed at deployment time. Changing that connection requires deleting and recreating the deployment.