Quickstart

This is for a researcher who just got a LabPod account on a shared GPU workstation. In about five minutes you’ll log in, create a workspace, run something on the GPU, and stop cleanly.

If you don’t have an account yet, ask whoever runs the box - they create accounts and set your password. (Operators: see Users & quotas.)

Log in

Open the URL your admin sent you, for example http://lab-gpu.example.local:24680.

• Username - the same as your Linux account on the workstation.
• Password - your LabPod password, set by the admin. This is separate from your Linux password.

Forgot your password?

Ask the admin to run labpod admin set-password <username> as root, or with sudo on systems that use sudo for administration. It only resets your LabPod password, never your Linux login.

Create a workspace

A workspace is a Podman container that runs on the shared host as your Linux user. It has its own CPU, memory, GPU, and disk limits, taken from your quota.

1. Click Create (top-right of the workspaces page).

2. Pick a template. Enabled by default:

   • PyTorch JupyterLab - the default for most users, GPU-ready.
   • TensorFlow JupyterLab - JupyterLab + TensorFlow, with the TensorBoard launcher.
   • Data Science JupyterLab (CPU) - NumPy, SciPy, pandas, scikit-learn, matplotlib.
   • Code Server - VS Code in the browser, with Open VSX extensions.

   Your admin can also enable additional opt-in templates, including CUDA Composite Workspace (JupyterLab, TensorBoard, code-server, Terminal, and MLflow preinstalled), MS Code Serve-Web (official Microsoft VS Code; requires accepting the EULA), and others - see Workspaces & templates for the full list.

3. Pick a GPU mode:

   • None - CPU only.
   • Whole GPU - exclusive use of one or more whole GPUs (within your quota).
   • Fractional GPU - share a card by VRAM fraction (e.g. 0.25 of a 24 GB card ≈ 6 GB). Only if your admin enabled fractional GPU sharing.
   • MIG - an A100/H100 hardware partition, only if your admin provisioned slices.

4. Click Create.

Prepare the image before starting

Selecting a template does not start a download. If its registry image is missing, the workspace form offers Pull and asks for confirmation. For an administrator-built template, Pull copies the administrator’s prepared image into your own image store; ask the administrator to build it first if it is not available. Dockerfile-backed personal templates use Build from Images.

See Workspaces & templates and Using the GPU for the full picture.

Open the workspace

Click the workspace in your list. The detail page shows:

• Apps - a card for each launcher (JupyterLab, Terminal, TensorBoard, MLflow, …). Click Start on a launcher, then Open to launch it in a new tab.
• Extra apps - declare your own ports for tools you run yourself (Gradio, Streamlit, an extra TensorBoard). See Extra apps & ports.

Workspace URLs are path-based and protected by your LabPod session cookie, for example http://<host>:24681/ws/<id>/jupyter/. LabPod redirects them to the adjacent workspace gateway; start from the platform URL your administrator gave you rather than bookmarking its old /ws/ form.

Run training

Open the LabPod Terminal (or the terminal inside JupyterLab) and work as you normally would:

nvidia-smi                                   # confirm the GPU is visible
python train.py
tensorboard --logdir runs/ --bind_all        # then open the TensorBoard launcher

For long runs, just close the browser tab - the process keeps going inside the container.

Don’t Stop a workspace to “save” it

Stop tears the container down and kills whatever is running in it. To step away, close the tab; the workspace stays up. Only Stop when you actually want to free the GPU.

LabPod sizes the container’s /dev/shm to half your memory limit, so PyTorch DataLoader(num_workers>0) and single-container multi-GPU DDP (NCCL) work out of the box. (If you hit Bus error in a container you started yourself with podman run, add --shm-size there - Podman’s default is only 64 MB.)

Know where your files live

• /work - your ~/work on the host, mounted automatically. Persists across restarts and across workspaces. Put datasets, checkpoints, and code here.
• /home/<you> - a per-workspace home, so conda envs, dotfiles, and shell history survive a stop/start of that workspace.
• Files you create show up as your own Linux user on the host (--userns keep-id) - no chown.

Full details: Files & storage.

Stop when you’re done

• Stop when the experiment is finished and someone else needs the GPU. The stop is graceful (SIGTERM, then teardown).
• Don’t Stop for a coffee break - leaving a container running is cheap.
• Don’t Delete unless you no longer need the workspace configuration and container. Its private home is archived under your account for recovery; /work is preserved either way because it is a host mount.

If a workspace stops on its own

A workspace can stop without you - most often an OOM kill (it exceeded its memory limit) or the host rebooting (workspaces don’t auto-restart; you click Start to bring them back). The card and detail page explain why. See When a workspace stops.

Next steps

• Workspaces & templates - what each template gives you.
• Apps & launchers - Jupyter, code-server, terminal, TensorBoard, MLflow.
• Example notebooks (Cookbook) - ready-to-run environments and notebooks across deep learning, HPC, and more research domains.
• Quotas & usage - your limits and where to read them.
• Desktop app - a native launcher instead of bookmarking URLs.