JupyterHub on GPU Clusters for Research Teams: Quotas and Storage

Running JupyterHub on a shared GPU cluster gives researchers self-service access to accelerators without handing out cluster credentials or provisioning individual machines. JupyterHub is a multi-user server that authenticates users and launches an isolated notebook environment for each one, which on a GPU cluster means scheduling a container with a defined accelerator allocation, image, and storage mount.

Two design decisions determine whether the deployment succeeds: how GPU allocation is offered and reclaimed, and how storage is laid out across home directories, shared datasets, and scratch. Get these wrong and the cluster fills with idle notebooks holding accelerators while researchers wait in a queue.

This covers the deployment architecture, profile and quota design, storage tiering, and the governance controls that keep research data inside the boundary it belongs in.

Deployment Architecture on a GPU Cluster

The standard pattern places JupyterHub on Kubernetes with a spawner that creates one pod per user session. Four components carry the design.

The hub handles authentication, session state, and spawn requests. It should be backed by persistent state so a hub restart does not orphan running sessions, and it should be sized as a small always-on service rather than an accelerated workload.

The spawner translates a user's profile selection into a pod specification, including GPU resource requests, node selectors or tolerations that route work to accelerated nodes, image reference, and volume mounts. This is where most cluster-specific configuration lives.

The authenticator connects to institutional identity, typically through OIDC or SAML. Group membership from the identity provider should drive which profiles a user can see, so entitlement is managed in one place rather than in Hub configuration.

The proxy routes browser traffic to the correct session. It needs to tolerate hub restarts and handle long-lived websocket connections, which are how notebook interfaces stay responsive.

Placing notebook pods on the same cluster as training jobs raises a scheduling question that has to be answered deliberately. Interactive sessions are latency-sensitive at spawn time and idle most of their lifetime; training jobs are the opposite. Most teams designate a node pool for interactive work rather than allowing notebooks to preempt or be preempted by batch jobs.

Profile Design and GPU Quotas

Profiles are the main control surface. Instead of asking researchers to specify resources, present a short list of named options that map to allocations the cluster can actually satisfy.

Three rules make profiles work in practice.

Default to CPU. A large share of notebook time is spent reading data, editing code, and inspecting results, none of which needs an accelerator. Making CPU the default and requiring an explicit choice for GPU recovers more capacity than any other single change.

Reclaim idle GPU sessions aggressively. Configure culling on notebook inactivity, and treat a GPU-attached session differently from a CPU one: a notebook holding an accelerator with no kernel activity for an hour should be stopped. Warn users in the interface so the behavior is predictable rather than surprising.

Enforce quotas per group, not per user. Research groups plan in aggregate, so allocate at the group level and let members distribute within it. This aligns the technical control with how principal investigators actually manage their teams and removes per-user negotiation from the platform team's workload.

Cluster-wide, these policies need enforcement above the Hub, because notebooks are only one consumer competing with training and inference. The OnePlus Platform, OneSource Cloud's AI orchestration platform, provides the quota and scheduling layer that keeps interactive access from crowding out production workloads.

Storage Layout for Notebook Workloads

Storage design causes more support tickets than GPU allocation. Notebooks touch three distinct kinds of data, and mounting them the same way creates both performance and governance problems.

• Home directories hold code, small artifacts, and environment customization. They need to be persistent, backed up, per-user, and quota-limited. Without a quota, a single user unpacking a dataset into their home directory can exhaust shared capacity.
• Shared datasets should be mounted read-only from a common location. This prevents duplicate copies, keeps a single governed source of truth, and makes access auditable at the mount level rather than per file copy.
• Scratch space handles intermediate outputs and cached data. It should be fast, explicitly temporary, and cleaned on a schedule that users know about.

Two failure modes recur. The first is researchers copying shared datasets into home directories to avoid read-only restrictions, which multiplies storage consumption and destroys the governance model. Prevent it with home directory quotas small enough that copying a dataset is impractical, plus a documented path for requesting write access to a working area.

The second is treating notebook storage as low-performance because notebooks feel interactive. A researcher iterating on a data loader against slow storage will conclude the GPU is slow. Interactive work benefits from the same low-latency data path as training, which is why AI storage architecture should cover the notebook tier rather than only the training tier.

Environment and Image Management

Notebook environments drift. A researcher installs a package with pip, the session restarts, the package is gone, and the notebook no longer runs. Or worse, it persists in a home directory and silently shadows a different version for someone else.

The workable pattern offers a small set of maintained images — a base image with common frameworks, plus one or two domain images — and gives users a documented way to request additions. Pin framework and driver-compatible library versions in the image rather than letting each user resolve them, since GPU library mismatches produce failures that are difficult for non-specialists to diagnose.

Allow per-user environments through a supported mechanism such as a conda environment or virtual environment on persistent storage, and make clear that anything installed outside that path will not survive. This gives researchers flexibility without turning every session into an unreproducible snowflake.

Governance Controls for Research Data

Interactive access widens the data egress surface, because a notebook can read a governed dataset and write the results anywhere the session can reach. For teams handling restricted data, four controls are usually the minimum.

1. Network egress policy on notebook pods: Restrict outbound connectivity so a session cannot push data to an arbitrary external endpoint. Allow-list package registries and internal services explicitly.
2. Read-only mounts for governed datasets: Combined with access logging at the storage layer, this produces a record of which datasets a session could reach.
3. Identity-linked sessions: Every session should map to an authenticated institutional identity, with session start, profile, and duration logged for review.
4. No shared credentials inside images: Credentials belong in per-session secrets scoped to the user's entitlements, not baked into a common image where every user inherits them.

These controls matter most in multi-department environments where one platform serves groups with different data agreements. Academic and research computing deployments typically face exactly this pattern: a single GPU cluster shared across labs whose data use terms are not identical.

FAQ

Is JupyterHub better than giving researchers individual GPU VMs?

For shared capacity it usually is, because pooled GPUs can be reclaimed when idle while dedicated VMs cannot. Individual VMs make sense when a researcher needs root access, custom kernels, or long-running processes that do not fit a notebook session model.

How do we stop notebooks from holding GPUs when nobody is using them?

Configure idle culling with a shorter timeout for GPU-attached sessions than for CPU sessions, set a maximum session lifetime for large allocations, and default new sessions to CPU. Communicate the policy in the spawn interface so reclamation is expected rather than disruptive.

How much storage should each user get?

Size home directories for code and small artifacts rather than datasets, so that copying a dataset there is impossible. Provide separate shared read-only dataset mounts and a scratch area with a documented cleanup schedule. The exact quota depends on your corpus, but the principle is that home directories should never be the place datasets live.

Can JupyterHub sessions run on the same nodes as training jobs?

Technically yes, but interactive and batch workloads have opposing scheduling needs. Most teams separate them into different node pools so that a large training job does not delay notebook spawns and an idle notebook does not occupy capacity a queued job needs.

What GPU allocation should a notebook profile request?

Match it to the work: prototyping and teaching are well served by a GPU partition or shared slice, while fine-tuning needs a full accelerator. Offering a shared-GPU profile alongside a full-GPU profile lets most users take the smaller allocation, which raises the number of concurrent researchers the cluster can support.

Summary

A JupyterHub deployment on GPU infrastructure succeeds or fails on allocation and storage policy. Default sessions to CPU, offer a small set of profiles that map to real cluster capacity, reclaim idle GPU sessions on a short timer, and assign quotas per research group. Separate home directories, read-only shared datasets, and scratch, with home quotas small enough to make dataset copying impractical. Maintain a short list of pinned images, and apply egress and identity controls so interactive access does not become an ungoverned data path.

Interactive access is only as good as the capacity behind it. OneSource Cloud provides dedicated GPU environments with managed AI infrastructure operations and multi-team orchestration, so research groups get self-service access without competing with production workloads. Request an architecture review to size interactive capacity for your teams.