JupyterHub hosting

Notebook servers for a whole team or classroom.

ML platformBSD-3-Clausefrom $18.99/mo

In short

JupyterHub hosting at AIHostBox means a dedicated, single-tenant JupyterHub instance on our infrastructure: we install it, pin it to a reviewed release, put it behind TLS on your domain, back it up nightly and keep it patched. Plans start at $18.99 per month and the admin account, the data and any API keys are yours.

Per-user serversShared environmentAuthenticationResource limits

JupyterHub is the multi-user server from Project Jupyter, released under the BSD-3-Clause licence. Where plain JupyterLab gives one person a notebook server, the Hub authenticates users and starts a separate server for each of them, routing everyone through a configurable HTTP proxy on a single address. An administrator can see who is running what, stop servers and add users from an admin panel or the REST API. What each user gets is decided by a spawner, so the same Hub can start plain processes, Docker containers or Kubernetes pods.

It is built for a server by definition: the whole point is that twenty students or a research group reach the same environment from their own browsers. Running it centrally means one place to install packages, one copy of shared datasets, and no afternoon lost to fixing someone’s laptop Python. The project’s Littlest JupyterHub distribution targets exactly this kind of single-machine deployment, for groups of up to about a hundred users.

JupyterHub hosting plans

ProRecommended minimum

8 GB RAM · 4 vCPU · NVMe

$18.99/mo

Order

MaxLarge document sets

12 GB RAM · 6 vCPU · NVMe

$27.99/mo

Order

Every plan is a dedicated single-tenant instance with NVMe storage, nightly off-box backups, TLS and managed patching. Quarterly, semi-annual and annual terms are discounted at checkout. Model tokens are not included — you bring your own key.

How we run JupyterHub

The JupyterHub process with configurable-http-proxy on port 8000, DockerSpawner starting one JupyterLab container per user with a persistent home volume, SQLite for Hub state, and the jupyterhub-idle-culler service.

What we configure for you

Authenticator of your choice: OAuthenticator (GitHub, Google, generic OIDC), NativeAuthenticator or a shared workshop password
admin_users and allowed users set in jupyterhub_config.py
c.Spawner.mem_limit and cpu_limit so one heavy notebook cannot starve the rest
A single user image with your course or team packages preinstalled
jupyterhub-idle-culler with a timeout that suits your sessions
Shared read-only data directory mounted into every user server

Which plan fits

Pro (8 GB, 4 vCPU) suits a small class or research group, around six simultaneously active users at 1 GB each doing pandas-scale work. Max (12 GB, 6 vCPU) takes about ten active users or fewer people with heavier data; a larger group needs its sessions staggered.

The honest limits

Everything runs on CPU, so deep-learning training in notebooks is slow and GPU kernels are not available. Concurrent memory, not the number of accounts, is what caps a class.

What people run JupyterHub for

Teaching

Every student gets the same working environment.

Research team

Shared data, separate workspaces.

Workshops and bootcamps

Hand out logins for a day, then cull the servers when it is over.

Analyst sandbox

Give analysts Python and SQL access to shared data without local installs.

Licence and version policy

Item	Position
Upstream licence	BSD-3-Clause
Sold as managed hosting	Yes
Tenancy	Single tenant — one customer per instance
Patching	Critical advisories within 24 hours, high severity within 72

Our full position on licences, including the applications we decline to sell, is on the licensing page.

Works well with JupyterHub

More ML platform we host

Questions

JupyterHub hosting: your questions

How do users log in?

JupyterHub uses pluggable authenticators. We can set up OAuthenticator for GitHub, GitLab, Google or a generic OAuth/OIDC provider, NativeAuthenticator for self-registration with admin approval, or a shared password for short workshops. Admin users are named in the configuration.

How many users can one instance serve?

Memory is the ceiling, since each active user runs their own server. With a 1 GB limit per user, Pro holds roughly six people working at the same time after the Hub itself; Max roughly ten. Registered users who are not active cost nothing once the idle culler stops their server.

Can I control which packages everyone gets?

Yes. All user servers start from one image, so we install the Python or R packages your course or team needs once, and every user sees the same versions. Users can still pip install extras into their own home directory for their personal experiments.

What is backed up?

Each user’s home directory with their notebooks and files, the Hub’s SQLite database of users and state, and the configuration file. Running kernels and in-memory variables are not saved, so users should keep work in notebooks rather than in long-lived sessions.

Does it support GPUs or Kubernetes?

Not on these plans. They are single CPU machines, which suits teaching and light analysis. Large deployments with autoscaling or GPU notebooks belong on Zero to JupyterHub with Kubernetes, which is a different kind of infrastructure.

Run JupyterHub without running a server

A dedicated JupyterHub instance, deployed and maintained by us. Month to month, cancel whenever.

Browse the catalogue Talk to a human