Hub and user environments
Operate JupyterHub, proxy and spawner reproducibly.
WZ-IT designs and operates JupyterHub as a shared notebook platform with authentication, isolated environments, resource controls and reproducible images.
Companies worldwide trust WZ-IT
The following are trademarks of their respective owners: JupyterHub (Project Jupyter). WZ-IT is an independent service provider and has no business, partnership, or contractual relationship with these companies. We offer independent migration, installation, hosting, and operations services.
JupyterHub manages users and starts their notebook servers through a selected spawner. Security and scaling depend heavily on isolation, images, storage and compute.
We assess user groups, libraries, data, CPU or GPU requirements and the target environment and develop a suitable architecture.
Notebook users can execute code. Network access, secrets, resource limits, data areas and administrative permissions must therefore be deliberately constrained.
The calculator covers standard operations. Kubernetes, GPU pools and large user counts are sized individually in the proposal.
Each user can execute code, so images, spawners, storage, resource limits and data access define security and scale.
Operate JupyterHub, proxy and spawner reproducibly.
Define CPU, RAM, GPU, libraries and limits.
Protect home, project and shared data.
Control identity, network, monitoring and backups.
WZ-IT operates the platform and isolation; user code, packages and business results remain customer-owned.
| Area | Responsibility | Scope and boundaries |
|---|---|---|
| JupyterHub platform | WZ-IT | Hub, proxy, spawner, base images, monitoring and updates. |
| Compute and limits | WZ-IT | Technical CPU, RAM, GPU and storage quotas. |
| Images and libraries | Shared | We build reproducibly; teams define required packages. |
| Data access | Shared | We connect storage while the customer approves datasets. |
| Notebook code | Customer | Code, processing and validation remain with user teams. |
| Pipelines and GPU workflows | Optional WZ-IT service | Automation and special images are scoped separately. |
Provide Jupyter notebooks and supported development environments per user.
Provide shared images, projects and data areas with clear access boundaries.
Integrate authentication through suitable authenticators and existing identity providers.
Provide libraries and runtimes through versioned images or defined packages.
Allocate CPU, memory, GPU and storage according to user group and workload.
Technically monitor platform state, utilisation, errors and capacity limits.
Assess existing data and configuration, migrate them in a test run and move to managed operations through a controlled cutover.
Secure SSO, roles, administrative paths and external access for the application and existing infrastructure.
Back up all stateful components consistently and document the recovery path for the agreed scope.
Monitor and update the application and its technical dependencies and operate them under the agreed service level.
A clearly defined operating scope instead of an opaque hosting flat fee.
We set up a test instance for you, usually on the next business day. No payment details required. After seven days it is deleted unless you continue.
We combine the right compute size with ongoing operations, backups, monitoring and a service level appropriate for the criticality of JupyterHub. High availability and recovery targets are designed separately where needed.
We also design custom hosting architectures, integrations and migrations around JupyterHub. Contact us for a technical assessment.
One managed standard JupyterHub application is included in the Starter workload. Business and higher levels add a flexible operations allowance for planned work during regular service hours. Select compute, additional applications, storage and the appropriate service level.
A workload is one compute instance with the applications agreed for it.
One standard app per workload is already included. Additional dedicated servers count as separate workloads.
€79.90 per started TB and month, including daily encrypted offsite backup with 7-day retention.
Enquiry
Briefly describe the current state and objective for JupyterHub. We assess infrastructure, integration, and ongoing operations.
Concurrent servers, libraries, datasets, notebook load and GPUs determine the platform.
| Usage scenario | Technical starting point | Key factors |
|---|---|---|
| Small analysis or teaching team | Spawner and image assessment | Profiles, limits and storage are defined. |
| Many concurrent servers | Cluster architecture | Scheduling, isolation and storage are sized. |
| GPU notebooks | GPU pool assessment | Drivers, images and quotas are planned. |
| Research or production data | Security and recovery design | Access, audit and recovery are agreed. |
User profiles, isolation, images, storage and CPU/GPU demand are reviewed before a proposal.
Compute and storage are placed close to data with suitable isolation.
European CPU or GPU environment after assessment.
Integration with existing Kubernetes and storage.
Local operation near sensitive data or GPUs.
Central identity with separate compute or data.
Identity, spawner, images, compute and data access receive explicit boundaries.
Browser-based notebook environments.
SSO, groups, quotas and restricted administration.
Roles, images, limits and data areas.
Hub, proxy, spawner and user servers.
Containers, VMs or Kubernetes with CPU and GPU.
Homes, projects, datasets and backups.
Python, R, Julia and agreed libraries.
Arbitrary code execution requires stronger isolation than a standard web application.
Answers about users, images, GPUs, data and operations.
Spawner, isolation, profiles, storage and GPUs materially change architecture and price.
It is configurable, but versioned base images improve security and reproducibility.
Yes. Pools, quotas, drivers and images are planned for the workloads.
Yes, especially when data or GPU systems must remain local.
Persistent home and project areas are backed up within the agreed scope.
As an alternative to managed hosting in the data centre, WZ-IT provides the hardware, configures JupyterHub, and handles hardening, monitoring, updates, backup and technical support. Access can be limited to the internal network or enabled through VPN and existing identities.
from EUR 349 excl. VAT / month · plus one-time provisioning and initial setup

01.06.2026
Your own ChatGPT, running entirely in-house: a familiar chat interface, a large language model on your own hardware behind it, without a single prompt going...
24.05.2026
Anyone bringing AI into production business processes quickly faces an uncomfortable question: what is actually happening in there? Which prompt went to which model, why...
These solutions are often used together with JupyterHub
These solutions offer similar functionalities and can be evaluated together
No risk: worst case, you leave with a clearer understanding of your project than before.


“WZ-IT's advice on our Azure migration was technically sound and completely non-binding right from the intro call - we took away a great deal.”
Whether a specific IT challenge or just an idea - we look forward to the exchange. In a brief conversation, we'll evaluate together if and how your project fits with WZ-IT.