Use JupyterHub when…
- The primary workload is hosted notebooks for many users.
- You want Hub’s spawners, auth integrations, and notebook-centric admin model.
- Batch Jobs, desktop sessions, and Kueue-governed campaigns are out of scope—or handled elsewhere.
Fighting JupyterHub to become a general job control plane is usually worse than running Hub for notebooks and something else for the rest. Hub is allowed to be specialized.
The gap Hammrly targets
Platforms often need one tenant-facing control plane for more than notebooks: interactive Jupyter and remote desktops, plus headless campaigns, all as Kubernetes Jobs subject to the same authentication, governance, and fair-sharing story.
That is a different product shape: submit and observe Jobs through gateway/query APIs, open sessions when they become ready, and lean on Kueue for admission instead of inventing a second queueing universe beside Hub.
They are not mutually exclusive
Some organizations will keep JupyterHub for classroom-style notebook hosting and use Hammrly for governed cluster Jobs. Others will standardize on Hammrly sessions and skip Hub. The mistake is pretending one UI checkbox replaces the other’s domain.
If your world is “many users, mostly notebooks,” start with JupyterHub. If your world is “many tenants, Jobs and sessions on shared GPUs,” evaluate Hammrly.