Workspaces & templates

A workspace is a container that runs on the shared GPU workstation as your Linux user. It has its own CPU, memory, GPU, and disk limits. It stays running until you or an admin stops it - LabPod does not auto-stop idle workspaces.

Templates

A template specifies the software environment. When you create a workspace you pick one template; after creation the template is fixed. Templates ship with resource defaults that you can adjust before creating.

LabPod comes with these global templates:

Template	What’s inside	GPU
PyTorch JupyterLab	JupyterLab + PyTorch, CUDA-ready; TensorBoard launcher available after install	optional by default
TensorFlow JupyterLab	JupyterLab + TensorFlow; TensorBoard launcher included	optional by default
Data Science JupyterLab (CPU)	NumPy, SciPy, pandas, scikit-learn, matplotlib	none
Code Server	VS Code in the browser, Open VSX extensions	optional

The built-in JupyterLab templates run on LabPod-built public images on the GitHub Container Registry (ghcr.io/labpod/*). PyTorch JupyterLab uses ghcr.io/labpod/pytorch-jupyter (CUDA tags cu121/cu126/cu129, auto-matched to your host’s NVIDIA driver and GPU at first start; an admin can pin a specific tag); TensorFlow JupyterLab uses ghcr.io/labpod/tensorflow-jupyter:cu125 (it bundles its own CUDA, so it runs on older drivers too); Data Science JupyterLab (CPU) uses ghcr.io/labpod/scipy-jupyter:py312 (CPU-only).

A dozen more templates ship disabled by default - conda and uv Python workspaces, LLM/Hugging Face, ComfyUI, R and RStudio, MATLAB, parallel programming, and a PyTorch demo showcase. Your admin can enable them after building any required images and accepting required EULAs. See Built-in templates for what each one contains.

Your admin may have added more templates; you can also create your own - see below.

Creating a workspace

1. Click Create on the workspaces home page.
2. Pick a template. A template note expands with details when available.
3. Make sure the template image is available before you start. LabPod does not pull or build a missing image when starting a workspace. For a global template, ask your admin to prepare it.
4. Adjust CPU, memory, and GPU in the Advanced section if the defaults don’t fit.
5. Optionally configure folders and environment variables.
6. Click Create.

Can’t create a GPU workspace?

The Create button stays disabled if your GPU quota is exhausted. If you see “No GPUs are currently selectable for this template”, you can still create the workspace - it will start once a GPU is free. Or lower the GPU count to 0 if you don’t need one right now.

Folders

By default your ~/work directory is mapped to /work in every workspace. The Advanced → Folders section lets you also include:

• Shared presets - admin-configured paths (datasets, model weights, etc.) that your admin has made available. All presets are checked by default.
• Your own folders - any directory on the host you have read access to. These are saved per-workspace and re-applied on every Start.

Folder changes in workspace Settings apply on the next Start.

Environment variables

Set NAME=value pairs that are injected into the workspace when it starts. Useful for overriding HF_HOME, setting API keys, or tuning CUDA behavior. Edit them in Settings → Environment and they apply on the next Start.

User-owned templates

You can save a workspace’s configuration as your own template: export it as a bundle file and import it later. User-owned templates appear under My templates in the template list and are private to your account.

Workspace lifecycle

Action	What it does
Create	Registers the workspace
Start	Runs podman run to start the container and applies all settings. It never pulls or builds a missing image
Stop	Sends SIGTERM to the container then tears it down gracefully
Delete	Removes the container and frees the GPU slot; see below

What survives a Stop

Everything that matters persists:

• /work - your work directory - survives because it is a host mount, not inside the container.
• Your workspace home (/home/<you> inside the container) - backed by a per-workspace directory on the host, so conda envs, pip installs, dotfiles, and shell history all survive stop/start.
• Files in any admin-configured shared mounts.

Processes running inside don’t survive - kernels, training jobs, terminal sessions all end.

What happens when you delete

Delete removes the workspace’s configuration and container. Its per-workspace home directory is not deleted - it is archived into a recoverable location under your account, so ask your admin if you need something back from it. Your /work directory is not touched - it is a host directory that outlives any workspace.

The delete dialog requires you to type the workspace name and tick a confirmation checkbox before the button activates. Deleting a workspace is owner-only - admins cannot delete other users’ workspaces. To reclaim resources from another user’s workspace, an admin can force-stop it, but force-stop does not delete it (see Lifecycle).

Workspace settings

While a workspace is stopped, click Settings on the detail page. You can change:

• Resources - CPU, memory, GPU count (GPU mode is fixed at creation).
• Folders - add or remove host-directory mounts.
• Environment - add, remove, or edit environment variables.

All changes apply on the next Start.

Pinning a workspace to sign-in

On the workspace detail page, the Open at sign-in button (the pin icon) makes that workspace load immediately after you log in, skipping the workspace list. One pin per user; clicking again removes it.