// the find
jupyter-server/enterprise_gateway
A lightweight, multi-tenant, scalable and secure gateway that enables Jupyter Notebooks to share resources across distributed clusters such as Apache Spark, Kubernetes and others.
Jupyter Enterprise Gateway is a server that lets multiple users share a pool of Jupyter kernels running on remote infrastructure — YARN, Kubernetes, Docker Swarm, IBM Conductor — instead of each user spinning up local kernel processes. It sits between notebook clients and the cluster, handling kernel lifecycle, user isolation, and resource allocation. The target is data engineering teams running shared Spark clusters who want notebook access without giving everyone SSH or cluster credentials.
The process proxy architecture is genuinely well-designed: each backend (YARN, k8s, Docker, distributed SSH) is a separate class with a clean interface, so adding a new scheduler doesn't require touching core kernel management code. Kubernetes support includes a Helm chart with RBAC, a kernel image puller daemonset, and Jinja2 pod templates that operators can customize — this is more production-ready than most academic Jupyter tooling. Persistent kernel sessions survive client disconnects, which matters when you're running a 30-minute Spark job. The kernelspec-per-backend approach means users pick their execution environment from the notebook kernel selector, no custom UI needed.
666 stars after what appears to be several years of development signals that adoption has stayed narrow; this is a hard operational dependency to take on for a project with limited community momentum behind it. The 'multi-tenant' claim is weak in practice — tenant isolation is based on Linux user accounts and kernel-level process separation, not namespace or network-level boundaries, so a compromised kernel can potentially observe traffic from neighboring kernels on the same node. Docker Swarm support is included but Swarm itself is effectively dead infrastructure; anyone reading this in 2026 should treat that backend as unmaintained. The local dev story is genuinely painful: getting a working test environment requires either a real YARN/k8s cluster or building multi-container Docker setups from scratch, which the integration tests confirm — there's no lightweight mock backend for development.