Marie has the notebook that "works on her machine". Thomas opens it: kernel crash — insufficient RAM, different pandas version, hardcoded /Users/marie/... path. The CTO finds a client export in a public Git repo. Team Jupyter is not sending .ipynb files on Slack: it is a platform with identity, resources, and governance.
A local notebook on 32 GB RAM is not team infrastructure. Once three people share data, GPUs, or regulated environments, you need centralised auth, resource isolation, and access logging. Deployed badly, JupyterHub is a VPS where everyone has the same rights. Deployed well, it bridges exploration and production pipelines.
Minimum viable architecture
A team setup rests on a few non-negotiable components:
| Component | Role |
|---|---|
| JupyterHub | SSO/LDAP login, per-user notebook spawn |
| Spawner | Docker or Kubernetes — reproducible image |
| Persistent storage | Per-user or per-project space, not ephemeral disk alone |
| Secrets | Vault or injected env vars — never API keys in notebooks |
| Resource quota | CPU, RAM, GPU max per user or group |
Hosting depends on load: capable VPS for CPU exploration, GPU machine for training (see GPU rental), or Kubernetes if the team already runs orchestration. Compare offers with GPU access and EU regions via the directory and compare tool.
Share without data leaks
Version notebooks in Git, but strip outputs before every commit (nbstripout or pre-commit hook). A notebook exported with plain client data in a cell is a GDPR leak waiting to happen.
Limit data access: read-only roles on production databases, anonymised views, no full dump "for testing." Disable bulk download if data is sensitive; log exports with timestamp and user identity.
Cull idle kernels to free GPU and RAM — a notebook left open since Friday must not block the team queue.
For internal LLMs, do not mix confidential prompts and shared notebooks — see hosting an LLM.
Common mistakes that accelerate shadow IT
Four patterns show up in almost every post-mortem:
- Single shared SSH account — same problem as team SFTP access: nobody is accountable, everyone is root.
- Notebook = production — a cron running an untested
.ipynbat night replaces a pipeline with no observability. - GPU on 24/7 for pandas EDA that only uses CPU.
- No backup of user home on a single local disk.
Each fixes without banning Jupyter — by applying the same requirements as an API: identity, logs, limits.
GPU, quotas, and controlled cost
You rarely need one GPU per data scientist. JupyterHub schedules jobs, applies per-group quotas, and releases resources after idle timeout. Reserve expensive GPU instances for heavy training; data exploration (EDA) often runs fine on CPU.
For intensive training, spot or on-demand instances complement the Hub without tying up hardware 24/7. Document who can launch a GPU job, maximum duration, and how to alert when the queue exceeds a threshold.
The peak: shared Jupyter without governance = accelerated shadow IT
Here is what notebook enthusiasm forgets to formalise.
Compare hosts with GPU access and EU hosting via the directory before buying hardware "for Jupyter."
Decide and move forward without blind spots
Before buying a GPU or deploying a Hub:
- Count how many notebooks must run at once, on which data, with what audit trail.
- Choose JupyterHub + Docker once three regular data users share resources or regulated data.
- Fix a pinned base image and Git policy (outputs stripped before commit).
- Configure CPU/RAM/GPU quotas and automatic idle kernel shutdown.
- Audit data access like any sensitive system — logs, roles, EU region.
- Test user persistent storage restore before trusting critical datasets.
Without a clear answer to the first question, you fund chaos — not science.
Frequently asked questions
Local JupyterLab or hosted JupyterHub?
Local for solo exploration. Hosted Hub once several people share GPU, regulated data, or need traceability — otherwise everyone emails CSV copies and versions diverge within a week.
How to stop a notebook hitting prod?
Separate environments (staging data), read-only database access by default, secrets outside notebook (vault, env vars), mandatory review before any scheduled cron job.
One GPU per data scientist?
Rarely. Hub scheduling, GPU quotas, spot instances for heavy training — CPU suffices for most EDA. See our GPU rental guide.
Notebooks and GDPR — what precautions?
No plain personal data in exported cells, access logs, EU hosting region, purge outputs accidentally committed to Git. Treat a notebook as a sensitive document, not a disposable draft.
Before buying a GPU "for Jupyter", ask: how many notebooks must run at once, on which data, with what audit trail? Without an answer, you fund chaos — not science.