Built-in workspace templates

LabPod ships a catalog of global workspace templates. Most are enabled out of the box, because LabPod pulls a tested published image for them - no image build required. A few ship disabled: two need a vendor licence acknowledgement before anyone can use them, and two more (MATLAB and MS Code Serve-Web) can’t be redistributed as a ready image at all, so each researcher builds them in their own account after the admin enables the recipe.

If you only want to know which ones you can pick right now, look at your workspace creation page - it lists exactly the workspace templates your admin has enabled. This page explains what each one is for.

Fresh install vs. upgraded server

On a brand-new LabPod install, every workspace template in Enabled by default below arrives ready to use. On a server that was upgraded from an older LabPod, your admin’s previous enable/disable choices are preserved - if one of these workspace templates was left disabled before the upgrade, it stays disabled until an admin turns it on in Workspace templates, but turning it on no longer requires building anything first.

Browsing and cloning

Open Workspace templates from the top bar, then the Workspace templates tab (or press Set up workspace from the gallery header, which reaches the same create form as the dashboard), to browse every workspace template shipped with LabPod, including ones your administrator has not enabled. The status on each card explains what can happen next:

• Ready to launch: create a workspace immediately, or clone the workspace template to customize it.
• Not enabled here: the administrator has not enabled the global workspace template. You can still clone it when its source is available.
• Preparation after Create: the administrator enabled the workspace template, but its image is not yet in your account. Create the workspace, then choose Download image or Build image on its own page - this is also how MATLAB and MS Code Serve-Web get built, since neither ships as a ready image.

Clone & customize creates a private entry under My workspace templates. A Dockerfile-backed workspace template copies its editable build context into your work directory; edit it, choose Build, then enable launching by saving the workspace template. A registry-image workspace template keeps the existing image reference and has no Dockerfile to edit, though you can still change its workspace-template settings.

A folded Adding Python packages? You don’t need your own image. note above the gallery covers the common case: for project-level Python packages, cloning and rebuilding an image is usually unnecessary. Create a virtual environment under your persistent workspace home instead:

python3 -m venv ~/.venvs/myproj
source ~/.venvs/myproj/bin/activate
pip install ...

Getting more from the Cookbook

Below the built-in list, Get Cookbook workspace templates fetches searchable, ready-to-import workspace templates from the public LabPod Cookbook. LabPod contacts the Cookbook only after you press this - the built-in gallery itself stays fast and works offline, and an air-gapped or disconnected host can retry in place or fall back to a manual bundle import.

Each loaded entry shows Prebuilt image or Build required, plus GPU and Terms required badges where they apply. Import checks the published bundle’s digest when your browser supports it, blocks a known mismatch, and previews the bundle before opening the new private workspace template for review. From there:

• A registry-image import is ready once you accept any required terms.
• A Dockerfile import tells you whether to wait for its build or start the build yourself before enabling it.

Browse Cookbook source links to the repository directly if you’d rather read a bundle’s README first. Owners can accept required terms while a private workspace template stays disabled, build it, then save to enable it - after saving, Set up workspace continues straight into workspace creation.

Published images vs. locally built

Wherever you’re choosing or reviewing a workspace template - the workspace create form’s Customize section, the Advanced tools → Workspace templates → My workspace templates tab, and image history - LabPod labels its Artifact source:

• Published image: a tested image LabPod built and pinned to an exact version when it shipped this workspace template definition. Preparing the workspace just downloads that already-verified image.
• Locally built: built from the current Dockerfile on this host. A local build resolves whatever package versions are current today, which is not necessarily what was tested.

Every published workspace template on this page still ships its Dockerfile, so you (or an admin) can always inspect it, clone it, or export it - the normal path just downloads the pinned image instead of rebuilding it. If that download fails, the workspace create page offers Build locally instead: it builds the same, unchanged Dockerfile as an explicit fallback, under the same image reference. This is also the supported path on an air-gapped host with no registry access.

Cloning or importing a published workspace template and then editing its Dockerfile switches that copy to a local build from then on; leave the Dockerfile unchanged and it keeps pulling the pinned published image.

Enabled by default

Workspace template	What’s inside	Apps	GPU
PyTorch JupyterLab	PyTorch on a tested CUDA image; the CUDA build is matched to your host’s driver and GPU at first start*	JupyterLab, TensorBoard, Code	on by default
TensorFlow JupyterLab	TensorFlow, bundling its own CUDA so it runs on older drivers too	JupyterLab, TensorBoard, Code	on by default
Data Science JupyterLab (CPU)	NumPy, SciPy, pandas, scikit-learn, matplotlib, seaborn, bokeh	JupyterLab	none
Code Server	VS Code in the browser with Open VSX extensions	Code	optional
CUDA Composite Workspace	A general CUDA workspace with the full app set*	JupyterLab, TensorBoard, Code, Terminal, MLflow, Aim	on by default
LLM / Hugging Face Workspace	transformers, datasets, accelerate, peft, trl, bitsandbytes for fine-tuning and inference*	JupyterLab, TensorBoard, Code, Terminal	on by default
ComfyUI / Stable Diffusion	Node-based image generation; models, inputs, outputs and custom nodes live under /work/comfyui*	ComfyUI	required
R ML JupyterLab	R with tidyverse, tidymodels, caret, xgboost, randomForest, glmnet, and data.table; JupyterLab, its Python kernel, and reticulate share one interpreter	JupyterLab (R and Python kernels), TensorBoard	none by default; R torch/keras are not included
RStudio Server	RStudio with R, tidyverse, data.table, and reticulate on the rocker/ml base	RStudio	optional
Parallel Programming (CUDA/MPI/OpenMP)	GCC/gfortran/clang, OpenMP, OpenMPI, the CUDA toolkit (nvcc, cuda-gdb), Nsight profilers, served through OSS code-server*	Code	on by default
Miniforge JupyterLab	A conda base with no commercial licensing attached (conda-forge)	JupyterLab	none
Python (uv) JupyterLab	Plain PyPI Python with uv, no conda	JupyterLab	none

* CUDA build auto-selected for your host - see below.

These pull tested ghcr.io/labpod/* images at an immutable version (v2-...), so nothing needs to be built. Parallel Programming moved to OSS code-server specifically so it no longer needs Microsoft’s editor terms.

CUDA build auto-selection

For PyTorch JupyterLab, LLM / Hugging Face, ComfyUI, CUDA Composite Workspace, and Parallel Programming, LabPod reads the host’s NVIDIA driver and GPU generation and picks the highest CUDA build both support - for example, driver 525 selects the v2-cu121 build. This runs once when the server first seeds these workspace templates, and again on later image preparation as long as an admin hasn’t manually pinned that workspace template’s image reference. TensorFlow JupyterLab bundles its own CUDA in a single tag, and the CPU-only workspace templates don’t need a CUDA build at all, so auto-selection doesn’t apply to them.

Opt-in, nothing to build

Your admin enables these; no image build is needed, though one requires accepting a vendor’s terms first.

Workspace template	What’s inside	Apps	Notes
PyTorch Demo Workspace	A guided showcase of everything at once; demo notebooks are seeded into /work on first start	JupyterLab, TensorBoard, Code, Terminal, MLflow, Aim	CPU-only
Anaconda JupyterLab	Anaconda Distribution: conda plus the curated data-science stack	JupyterLab	licence acknowledgement required (Anaconda’s commercial terms)

Opt-in, image built in your account

Only two workspace templates can’t ship as a ready-to-pull image, because LabPod isn’t allowed to redistribute either one: MATLAB needs your own organisation’s licence, and Microsoft’s VS Code for the Web needs Microsoft’s own Marketplace terms. Both ship a Dockerfile instead. Your admin accepts the terms and enables the workspace template; you create the workspace, then build it in your own account by choosing Build image on the workspace’s own page.

Workspace template	What’s inside	Apps	Notes
MS Code Serve-Web	Microsoft’s VS Code for the Web, with the official Marketplace and Pylance rather than Open VSX	Code	per-user build and licence acknowledgement required
MATLAB (matlab-proxy)	MATLAB in the browser	MATLAB	bring your own MATLAB licence; acknowledgement required

MATLAB keeps matlab-proxy’s own vendor token authentication turned on, in addition to your LabPod session. LabPod injects that token into the request only after checking you own the workspace, so another Linux user on the shared host can’t reach MATLAB by opening its loopback port directly.

Asking for one

If a workspace template you want is disabled, ask your admin to enable it. What that involves depends on the workspace template:

1. Pull-first workspace templates - everything in the two tables above except MATLAB and MS Code Serve-Web. Your admin just enables it; no image build is required, and once it’s visible on your workspace create page you can prepare its image yourself. Anaconda additionally needs your admin to accept its vendor terms first.
2. Local-build workspace templates (MATLAB, MS Code Serve-Web) - your admin accepts any required terms and enables the recipe. You create the workspace, then build the image in your own account by choosing Build image on its own page. MATLAB additionally needs your organisation’s own MATLAB licence.

Customising a built-in workspace template

Admins can edit any built-in workspace template - change the image, adjust defaults, add or remove apps. Simply enabling or disabling one preserves that choice while its shipped definition continues to receive release updates. Editing or deleting a built-in workspace template marks it as locally managed, so LabPod no longer overwrites it. Reset to shipped defaults restores the current definition without changing its enabled state or terms acknowledgement.

Editing a workspace template’s Dockerfile (rather than just its image reference or resource defaults) also switches that copy from the published pull to a local build - see Published images vs. locally built above. Build it before re-enabling.

Not what you need?

• Your admin can create additional global workspace templates for the whole lab.
• You can create your own private workspace template - see Workspaces & workspace templates.
• For ready-made environments across research domains (statistics, chemistry, bioinformatics, seismology, CFD and more), see Example notebooks (Cookbook).