Skip to content

Why LabPod

LabPod exists to solve one narrow problem: a 5–10 person research group shares one expensive GPU workstation and everyone needs GPU access from a browser, with fair quotas, without fighting over the box.

ToolWhere it’s strongWhy it doesn’t fit the small-lab problem
Google ColabQuick hosted notebooks with no local setupHardware and software can change between sessions, which hurts reproducibility; sessions are time-limited, so long-running deep learning training is fragile
Docker Desktop / PortainerContainer management for individuals or ops teamsNo workspace UX - users see container primitives; no quota or GPU policy
JupyterHubMulti-user notebooksNotebook-only; weak GPU allocation and quota enforcement
Open OnDemandHPC portals, Slurm/PBS integrationDesigned for clusters; brings a large install surface to a single machine
Slurm / KubernetesCluster scheduling at scaleOverkill for one node; requires dedicated infra knowledge to operate
Backend.AIEnterprise multi-node GPU platformFull-featured but sized for a team with an infra department, not a PI with a workstation

LabPod is deliberately narrower than all of these. Its selling point is installation and operational simplicity - one install command, one binary, one SQLite file.

LabPod is single-node and interactive-first. Researchers need to iterate quickly: start a kernel, run a cell, inspect a gradient, iterate. A job scheduler is the wrong abstraction for that workflow.

Coordination in LabPod is:

  • Quotas - each user gets a CPU/memory/GPU budget. New workspaces are rejected if the budget is exhausted.
  • Visibility - the admin dashboard shows who’s using what in real time.
  • Admin force-stop - the admin can reclaim resources from an idle or stuck workspace.

No daemon, no queue, no scheduler. One Go binary plus Podman.

  • Daemonless - no root daemon that all users share. Each workspace runs as its owner’s Linux account.
  • --userns keep-id - files created inside a workspace are owned by the right user on the host. SSH access, scripts, and data pipelines work without ownership confusion.
  • OCI-compatible - any Docker Hub or GHCR image works.
  • CDI - clean, standard interface for GPU device allocation.
  • Rootless by default - no Docker group, no root-equivalent socket exposed to users.

Single GPU workstation. One lab, not a cluster.