Skip to main content

Fully Managed
Jupyter Hub
as a Service

Deploy Jupyter Hub as a fully managed service starting at €9/mo. Get automated backups, SSL, updates, support and monitoring included.

JupyterHub is the multi-user server for Jupyter notebooks. It spawns and manages a separate notebook server for every member of your team, class, or lab — combining the convenience of Colab with the security and control of self-hosted infrastructure.

Free 7-day trial  99.9% Uptime SLA  No credit card  Cancel anytime

Free 7-day trial  99.9% Uptime SLA
No credit card  Cancel anytime

Jupyter Hub

Jupyter Hub

STARTING AT

€9/month
Automated Backups
Monitoring
Automated Updates
Auto SSL

USAGE

Unlimited
Human Support
Custom Domains
Terminal Access
File Manager Access
Deploy in your region 21 locations worldwide
GermanyFinlandNetherlandsUKSwedenUnited StatesCanadaSingaporeJapanAustraliaBrazilSouth Africa+9 more →
Jupyter Hub Preview Image

ABOUT THE SOFTWARE

What is Jupyter Hub

JupyterHub is the multi-user server for Jupyter notebooks. It authenticates each person, then spawns and proxies a private notebook server for them, so a whole team or class works from one shared address.

JupyterHub is written in Python and licensed under the 3-Clause BSD license. It is maintained by Project Jupyter, whose funds are now hosted by LF Charities at the Linux Foundation. The repository has more than 8,000 stars and is depended on by over 3,000 other projects.

It runs everywhere serious notebook work happens. UC Berkeley uses it to teach more than 3,000 students. CERN runs it as SWAN for analysis of Large Hadron Collider data. NASA, NERSC, and Argonne run it on national supercomputers, and Netflix built a notebook platform on it that ran more than 150,000 jobs a day against a 100-petabyte warehouse.

FEATURES

What Jupyter Hub does

JupyterHub turns a single shared address into a private notebook server for every user. Its real strength is how much of that behaviour is pluggable: who signs in, where servers run, and how resources are capped are all yours to set.

Multi-user spawning

Each person gets their own notebook server on demand, isolated from the others, started and stopped on sign-in and idle.

Configurable spawners

Run servers as containers, on Kubernetes, or onto an HPC batch scheduler, each with explicit CPU and memory limits per user.

Idle-server culling

A built-in service stops servers that have gone quiet, returning memory to the pool, with thresholds you control.

REST API

Provision users, start servers, and read activity programmatically, so the hub fits into your own automation.

Pluggable authenticators

Sign users in through OAuth (Google, GitHub, GitLab, Azure), LDAP against your directory, an LMS, or native self-signup.

Named servers

One user can keep several servers at once, so exploration and a debug session stay separate without losing either.

Admin console

Administrators see who is running what, start or stop servers, and manage access from a single web view.

Custom kernels and environments

Ship the exact packages and kernels your work needs in the single-user image, identical for everyone on the hub.

WHAT'S ALWAYS INCLUDED

Every app. Fully managed.
Nothing extra to pay for.

Every app you deploy includes the full managed service — security, backups, updates, and support from day one.

Automatic updates and patches

Apps run the latest stable version. Security patches applied silently, with rollback if needed.

Daily off-site backups

Multiple daily backups in redundant off-site locations. One-click restore if anything goes wrong.

24/7 uptime monitoring

Continuous monitoring with instant alerting. We respond before you notice.

SSL, firewall, DDoS protection

Auto-renewing SSL, hardened firewall rules, DDoS mitigation on every deployment.

Performance and scaling

We monitor resource usage continuously. When your app needs more headroom, we flag it and upgrade with your explicit approval.

Dedicated engineering support

Real engineers on chat. DNS, SMTP & migration help. All included in €9.

WHY MANAGED

Why teams pick managed Jupyter Hub

JupyterHub shipped two security fixes in spring 2026, one for an open redirect and one for cross-site request forgery. A self-hosted hub that is not patched within weeks runs a known issue. Outsourcing that patch burden is the common reason teams move to us.

Running JupyterHub is not the same as installing it. The install is an afternoon. Keeping it healthy is the recurring job: patching the hub and the proxy, renewing certificates, watching memory, backing up the database, and migrating that database on every major upgrade. None of that shows up in a demo, and all of it shows up at 2am.

The sharpest example is the idle culler. It decides whether to shut a notebook down by reading a last-activity field that only advances on kernel messages. A silent training loop that prints nothing looks idle, so the default culler stops it and discards the running work. Meanwhile an abandoned browser tab can keep a server alive for days. Few teams discover this until a long job dies overnight.

REVIEWS

Hear from customers ​like you​​​​​​​

Successful businesses and professionals around the world rely on DANIAN every day

USE CASES

Three teams who run Jupyter Hub on DANIAN

These are representative team types we set up most often. Each starts with the same flat €9 plan.

UNIVERISTY DATA-SCIENCE COURSE

Teaching 3,000 students without 3,000 laptops to configure

Students sign in through the campus identity provider and land in an identical environment. nbgrader handles autograding, a shared volume holds the course data, and each student gets a 1 GB memory cap so one runaway notebook cannot stall the class. UC Berkeley runs this pattern across Data 8 and Data 100.

RESEARCH LAB WITH SHARED GPUs

One A100, shared across the group, with limits that hold

Researchers pick a CPU or single-GPU notebook from a menu rather than editing config. A shared dataset is mounted read-only, per-user storage is persistent, and the environment is built from conda-forge to stay clear of the Anaconda terms change. We wire up the GPU device plugin so spawns do not fail on scheduling.

COMPANY ANALYTICS TEAM

Replacing per-seat notebook subscriptions with one shared hub

A 5–25 person team moves off per-seat tools onto a single hub behind corporate SSO. Named servers keep exploration and production-debug work separate, the warehouse driver is baked into the image, and the idle culler reclaims memory overnight. One flat bill replaces a stack of per-editor seats.

COMPARISON

Four ways to run Jupyter Hub

JupyterHub is free; running it for a team is not. Here is the honest tally against a per-seat notebook SaaS, a self-managed VPS, and a home server. DANIAN holds at €9 whether you have one user or ten.

 PATH1 USER5 USERS 10 USERSYOUR OPS TIME
Proprietary SaaS
Google Colab Pro, per seat
$11.99/mo$59.95/mo $119.90/mo
cost scales with every seat
None, but compute units run out
Self-host on a VPS
2 vCPU / 4 GB production-class VPS
~$24/mo VPS + ~$20/mo backups and monitoring; add database tuning past 25 userssamesame5–10h setup, then 1–2h/mo
Home server
HP ProLiant ML30 Gen10 tower
~€800–1,500 once, then €17–32/mo electricity + a static-IP business linesamesame2–4h/mo, plus you are on call
DANIAN Managed Jupyter Hub€9/mo€9/mo€9/mo0 hours

BY INDUSTRY

Jupyter Hub for specific industries

Different sectors put different demands on a shared notebook hub: who may sign in, where data may sit, and what must be logged. These are the five we set up most, each with the configuration choices that the sector's rules call for.

Teaching teams handle student records under FERPA, so access and grading have to be controlled. We sign students in with an LTI13 authenticator straight from Canvas or Moodle, and run nbgrader for autograded assignments.

Each student gets a low memory cap, often 1 GB, so a class of 200 cannot be stalled by one runaway notebook.

The payoff is concrete: UC Berkeley teaches more than 3,000 students per term on JupyterHub, and Vrije Universiteit Amsterdam reported that students finish lab work about three times faster than before they adopted it.
Grants attach data-management-plan mandates, and reproducibility is the working standard. We dispatch notebooks onto an HPC batch scheduler or expose GPU spawn profiles, with shared scratch and reference-data mounts and a conda-forge environment pinned per project.

A researcher requests a single-GPU notebook from a menu, reads a multi-terabyte dataset from the parallel filesystem, and commits the notebook to Git.

CERN runs JupyterHub as SWAN for Large Hadron Collider analysis, and NERSC and SDSC run it as the standard interactive interface to their supercomputers, which is why this pattern is well worn.
Quant teams work under SR 11-7 model-risk governance and MiFID II record-keeping, so identity and reproducibility matter more than convenience.

We sign analysts in through your corporate identity provider and set disable_user_config, so a per-user config file cannot quietly override the hub.

A quant pulls historical tick data from the warehouse over an authenticated driver, prototypes a backtest, and publishes a parameterised run through papermill that anyone can re-execute. JP Morgan and Bloomberg engineers sit on the Jupyter steering committee, so the tool is already familiar inside large financial firms.
Health research follows 21 CFR Part 11 for electronic records and strict rules on protected health information, so data separation is the design constraint.

We give each project a named server with storage scoped to its own data namespace, and keep sensitive workloads on isolated nodes away from general compute. A bioinformatician spawns a notebook from a tagged image, mounts a de-identified cohort read-only, and runs a scanpy or Nextflow pipeline whose outputs land in a separate results volume that an audit log records.

HUNT Cloud and Lawrence Livermore both run JupyterHub for population-health and life-science work.
Government research teams operate under FISMA and NIST 800-53 controls, which favour tight network and identity boundaries.

We run the hub against an internal package mirror so notebooks never reach the public internet, sign users in through your agency directory over LDAP, and place the hub in the region you choose.

Civil servants in a public-health agency run epidemiological notebooks against a secured data lake and share parameterised analyses for inter-agency review. Formal authorisation of your environment stays with your agency; we configure the hub to fit inside it. NASA, NOAA, NCAR, and Argonne all run JupyterHub for this kind of analysis.

FAQ

Frequently asked questions

Everything teams ask before signing up — answered straight, without sales speak.

Three groups: technical setup, migration, and how DANIAN works as a service.

01

Technical and configuration

JupyterHub ships with pluggable authenticators. We sign your team in through OAuth against Google, GitHub, GitLab, or Azure, or against LDAP for an internal directory. For Google we restrict to your hosted domain; for GitHub we restrict to your organisation. Native self-signup is available where open enrolment is what you want.

02

Migration and onboarding

We can activate your app on your own custom domain/subdomain. Examples: mydomain.com, anyword.mydomain.com.
Or, on our randomized free subdomain. Example: 963.apps.danian.cloud
If you wish to use a custom domain/subdomain, select that option when ordering your app (or notify us later). We will send you the required DNS records and if needed, our tech team will modify them for you.
21 datacenter locations across six continents. You choose the region at provisioning. Application data sits in the region you choose; pick whichever is closest to your users or matches your data-residency preference.
Yes. Request a region migration from the dashboard and we run the move in the background. The system emails you when the migration completes; total transfer time depends on data volume but typical instances finish in a few hours. There is no extra charge for a region change.
Yes. Full data export is available at any time, in a portable format you can bring to any infrastructure.
Yes. We point the hub at your identity provider and connect your custom domain with SSL during setup. You give us the OAuth callback details or the directory connection, we configure it, and we test a real login together before your team arrives.

03

Billing, support, and platform

€9 covers everything we do for that app: hardware in the region you choose, daily off-site backups with one-click restore, automatic security patches and version upgrades, 24/7 monitoring, SSL and firewall, and engineering support on Email/LiveChat. There are no setup fees or hidden line items. For more info see our Pricing page.
If you decide to continue, we charge €9/app/month from day 8. If you don't, the trial ends and you can export your data. No card is required for the trial, and we never auto-charge you without explicit consent.
No. The €9/month is flat regardless of how many users log into your app. Add 5 users or 50; the price doesn't change.
24/7 Live chat and email support, both staffed by engineers who run the systems. We handle DNS configuration, SMTP setup, app integrations, performance tuning, troubleshooting, and migration help. Response time is typically under an hour. There is no tier system — every customer gets the same support.
Yes. Cancel from the dashboard. We don't charge a cancellation fee, we don't lock data, and we will export your data to you on request before deletion. data to you on request before deletion.
Every customer instance is backed up daily to a separate region from the primary. We test restores. You can request a restore at any backup point within the retention window — usually 7 days for daily backups.
Your application data sits in the region you choose at provisioning — 21 datacenter locations across six continents. Account-level data (billing, account email, support ticket history) is processed centrally. Application data region is picked by you, per app.
99.9% uptime SLA on every app, every tenant. Service credits are documented at danian.co/service-level-agreement. The status page is located at status.danian.co.
When your tenant approaches the resource ceiling — the base tier holds 1 vCPU/RAM, 30 GB storage — we notify you. Resource upgrades happen with your explicit consent; we will not upgrade your tenant or charge you without it.
We wait. We don't suspend the app or delete your data on the first failed charge. We email you, you fix the card on file, and we continue.
Invoices can be downloaded from the billing dashboard in PDF the day each charge succeeds. EU VAT is added where applicable and the VAT-reverse-charge regime applies for VAT-registered businesses with a valid number.
150+ open-source apps across automation, team chat, file sync, analytics, AI, password management, email marketing, dev tools, project management, smart home, CMS, and federated social. See the full catalog →
Yes. Every instance comes with a web-based terminal and a file manager in your DANIAN management dashboard. Useful for managing your data and customizations.
Resources scale with your usage. If your app needs more vCPU, RAM, or storage, we add it — and we ask first before any change to your plan. €9 is the floor; resource-heavy workloads may price higher, but you'll always know in advance.
Yes. We have both a Partner program and an Affiliate program available. Anybody can sign up.
No contract. No minimum commitment. Cancel anytime from the dashboard with one click. The 7-day free trial requires no credit card. After the trial converts to paid, you can still cancel at any month without notice or penalty.

DEPLOY IN YOUR REGION

21 datacenter locations on six continents

Pick the region closest to your users.

United States, Germany, Finland, Singapore, Australia, Brazil, Canada, Netherlands, UK, Spain, Italy, France, Sweden, Malaysia, India, Japan, Mexico, Poland, South Korea, Chile, South Africa and more coming soon

Global Reach Map

Try managed Jupyter Hub for 7 days

No card. Cancel from the dashboard.