Skip to content

Console walkthrough: workbenches

Creating a workbench writes a Notebook object and a PersistentVolumeClaim into your project, and starts one pod from an IDE image. See the overview for what that gets you and what it costs while it runs.

Prerequisites

  • Membership of the group that grants dashboard access
  • A project - see Accounts & projects
  • GPU quota, only if you intend to attach a GPU

1. Open the project's workbenches

Projects, then your project, then Workbenches. A project with none offers a single button.

Workbenches are per-project. A workbench you create here is visible to the project, but running it and opening it belong to you.

2. Fill in the form

Create workbench opens one page rather than a wizard, with the sections listed down the left.

Cluster storage is pre-filled with a new volume named after the workbench, mounted at the home directory. It is created with the workbench unless you attach an existing volume instead.

Name becomes the name of the Notebook object.

Image selection chooses the IDE and what is already installed in it. The list covers JupyterLab in several flavours - Minimal, Data Science, PyTorch, TensorFlow, TrustyAI - and code-server for a VS Code interface. Version selection pins which build of that image you get, and the packages it carries are listed under View package information.

A GPU workbench needs its image and its hardware profile to agree

The CPU images do not become GPU images by attaching a GPU, and a CUDA or ROCm image matches only the GPU generation it was built against. This is the same pairing that decides whether a model server starts - see the runtime and profile warning.

Hardware profile sets the CPU, memory and any GPU. This is the whole of how a workbench gets a GPU - there is no separate accelerator setting, and no request to make of anyone. The GPU profiles offered here are the same ones the model-serving form offers, and choosing one attaches its default number of cards to the workbench.

A GPU workbench holds its card the entire time it runs, not only while you use it

The card is attached to the pod, so an open notebook that is doing nothing holds it just as firmly as one that is training, and closing the browser tab does not release it. It also counts against the project's GPU quota, so a forgotten workbench is a model deployment that cannot schedule. Choose a CPU profile unless the notebook needs the card, and Stop the workbench when you are done.

Cluster storage is the home directory. The default volume is ReadWriteOnce, which is what limits a workbench to one pod - it is a personal environment, not a shared one.

Environment variables and Connections inject configuration. A connection's values arrive as environment variables, so anything running in the workbench can read them; that includes any notebook you were sent by someone else.

3. Watch it start

The workbench appears in the list and reports its progress. The first start of a given image pulls it, which is the slow part; later starts of the same image are much faster.

The image column carries the version as well as the flavour, so a list of workbenches shows at a glance which ones are on an older build.

4. Open it

The workbench's name in the list is the link that opens it, at /notebook/<project>/<workbench-name>. It opens the IDE in the same browser session you are already signed in to, so there is no second login and no token to paste.

The link is live only while the workbench is running. A stopped workbench still lists, still holds its home directory, and starts again from the same list.

Stop and start

Stop, on the row, ends the pod and keeps the volume. Use it whenever you are done for the day: a running workbench holds its CPU, memory and GPU whether or not anyone is connected, and closing the browser tab does not stop it. Edit workbench, in the same menu as delete, changes the image, the hardware profile and the variables; each edit restarts the pod.

A workbench that sits idle for four hours is stopped for you, with the same effect as pressing Stop. That is a backstop against forgotten hardware, not a substitute for stopping deliberately - four hours of an idle GPU is still four hours nobody else could use the card.

Starting it again re-attaches the same home directory. Anything installed into the image rather than the home directory is gone, which is the practical reason to install packages from inside the notebook.

Delete

Delete workbench, from the menu at the end of the row, removes the Notebook.

The volume is not removed with it. It carries no owner reference back to the workbench, so nothing garbage-collects it: it stays under Cluster storage, keeping the home directory and continuing to be billed, until it is deleted there.

That separation is usually what you want. It is also the most common way to end up paying for storage nobody is using, so a deleted workbench is worth following with a look at Cluster storage.

Next

Self-hosted models → - when the work in a notebook becomes something other people need to call.