Agent Sandboxesagentsandboxes.org
Sandbox profile · Open-source project

Jupyter Kernel Gateway

Answer in brief

BSD-licensed headless web server that exposes Jupyter kernels over REST and WebSockets; on its own it runs kernels as local processes, while the sibling Enterprise Gateway launches each kernel in its own Kubernetes pod and namespace. The open-source kernel-as-a-service building block: stateful and flexible, but isolation is only as strong as the Kubernetes pod security you configure around it.

By the Agent Sandboxes editors · Updated

Overview

Jupyter Kernel Gateway is a web server from Project Jupyter that gives applications headless access to Jupyter kernels: start and stop kernels through a REST API compatible with the Notebook server's kernel endpoints, then send code over a WebSocket carrying the Jupyter messaging protocol; a second notebook-http mode turns annotated notebook cells into HTTP endpoints. Configuration covers an auth token, max_kernels, a seed_uri notebook run on every kernel launch and prespawn_count. It performs no sandboxing itself (kernels run in the gateway's process and filesystem space), so the docs point to containerising it with docker-stacks images and scaling with Kubernetes. The latest release is 3.0.1 (12 March 2024).

Jupyter Enterprise Gateway extends the same idea into a multi-tenant "kernel as a service" that launches each kernel on a resource manager: on Kubernetes every kernel becomes its own pod (image chosen per kernelspec or via KERNEL_IMAGE from an allow-list), by default in a freshly created namespace with the baseline Pod Security Standard, non-root UID 1000, CPU/memory/GPU requests and limits from the client, and optional idle culling; YARN, Docker Swarm and IBM Spectrum Conductor are also supported. Version 3.3.0 shipped on 1 June 2026. Both are BSD-3-Clause. This is the open-source substrate behind hosted Jupyter-for-agents products; it gives you stateful kernels but leaves isolation strength to your pod security settings.

Notable

  • Kernel Gateway 3.0.1 released 12 March 2024; Enterprise Gateway 3.3.0 released 1 June 2026
  • Enterprise Gateway creates one Kubernetes pod per kernel in a per-kernel namespace by default, with root prohibited and the baseline Pod Security Standard applied (since 3.4.0 configurable via EG_KERNEL_NAMESPACE_POD_SECURITY)
  • Enterprise Gateway idle culling defaults to off (0 s) in the config docs, 3,600 s in the Helm chart

Jupyter Kernel Gateway specifications

AttributeDetails
IsolationNone by itself: Kernel Gateway launches kernels in its own local process and filesystem space, so you must run it in a container or VM. Enterprise Gateway launches each kernel as a Kubernetes pod (or on YARN, Docker Swarm or IBM Spectrum Conductor), by default in a per-kernel namespace with the baseline Pod Security Standard and root prohibited
DeploymentOpen-source project · Self-hostable
Open sourceYes (BSD-3-Clause)
SDKs and interfacesREST API, Python
Cold start (vendor claim)Enterprise Gateway kernel launch timeout defaults to 60 seconds on Kubernetes
Max session lengthNo limit by default; Enterprise Gateway idle culling is off by default (cull_idle_timeout 0, with 43,200 s recommended) and the Kubernetes Helm chart defaults to 3,600 s
PersistenceStateful kernel: variables and files persist for the life of the kernel; Kernel Gateway can seed every kernel from a notebook (seed_uri) and prespawn kernels; no snapshots
GPUEnterprise Gateway accepts KERNEL_GPUS / KERNEL_GPUS_LIMIT requests on Kubernetes; Kernel Gateway itself has no GPU handling
NetworkingNot restricted by the gateways; whatever the host or pod allows
PricingFree (BSD-3-Clause)
Free tierFree to self-host
ComplianceNot documented
RegionsNot documented

Facts from Jupyter Kernel Gateway’s public documentation, verified November 9, 2026. Performance numbers are vendor claims.

Strengths and trade-offs

Strengths

  • You want stateful Jupyter kernels (Python, R, Scala) under your own control, free of licence cost
  • You run Kubernetes and want one pod per kernel with per-kernel namespaces and resource limits
  • You are building on the standard Jupyter protocol so any kernel language and client works

Trade-offs

  • Kernel Gateway alone provides no isolation; security depends entirely on how you containerise it
  • Enterprise Gateway warns that KERNEL_USERNAME comes from the client, so per-user namespaces are not a full access control
  • No snapshots, pause/resume or per-call time limits; sessions are bounded only by optional culling
  • Kernel Gateway has had no release since March 2024

Good fit for: Teams already on Jupyter and Kubernetes who want to run their own stateful kernels-as-a-service.

How Jupyter Kernel Gateway compares

SandboxIsolationOpen sourceSelf-host / BYOCCold start (vendor)Max sessionSnapshots / pauseGPUSDKs
Jupyter Kernel GatewayProcess (KG) / pod (EG)YesYes / NoNot documentedUnbounded (culling optional)No / NoNot documentedREST API, Python
Datalayer RuntimesNot documentedNoNo / NoNot documentedMinutes (set per runtime)Yes / Not documentedYesPython, JavaScript/TypeScript, CLI, MCP server, REST API
Kubernetes Agent SandboxgVisor or KataYesYes / Yes<1 s (warm pool)Not documentedYes / YesYesKubernetes CRDs, Python, kubectl
MicrosandboxMicroVM (libkrun)YesYes / Yes<100 msNot documentedYes / Not documentedNoTypeScript, Python, Rust, Go, Ruby, CLI, MCP server
OpenHands RuntimeDocker containerYesYes / NoNot documentedNot documentedNot documented / Not documentedNot documentedPython, JavaScript/TypeScript, REST API
Kata ContainersVM per podYesYes / NoNot documentedNot documentedNot documented / Not documentedYesCLI

See all Jupyter Kernel Gateway alternatives →

Frequently asked questions

What is Jupyter Kernel Gateway?
BSD-licensed headless web server that exposes Jupyter kernels over REST and WebSockets; on its own it runs kernels as local processes, while the sibling Enterprise Gateway launches each kernel in its own Kubernetes pod and namespace. The open-source kernel-as-a-service building block: stateful and flexible, but isolation is only as strong as the Kubernetes pod security you configure around it.
How does Jupyter Kernel Gateway isolate code?
Jupyter Kernel Gateway documents its isolation as: None by itself: Kernel Gateway launches kernels in its own local process and filesystem space, so you must run it in a container or VM. Enterprise Gateway launches each kernel as a Kubernetes pod (or on YARN, Docker Swarm or IBM Spectrum Conductor), by default in a per-kernel namespace with the baseline Pod Security Standard and root prohibited.
Is Jupyter Kernel Gateway open source?
Yes (BSD-3-Clause). It can be self-hosted.
How much does Jupyter Kernel Gateway cost?
Free (BSD-3-Clause) Check the official pricing page for current rates.
What are the alternatives to Jupyter Kernel Gateway?

Sources

  1. github.com/jupyter-server/kernel_gateway
  2. jupyter-kernel-gateway.readthedocs.io/en/latest/
  3. jupyter-kernel-gateway.readthedocs.io/en/latest/config-options.html
  4. jupyter-kernel-gateway.readthedocs.io/en/latest/websocket-mode.html
  5. pypi.org/project/jupyter-kernel-gateway/
  6. github.com/jupyter-server/enterprise_gateway
  7. jupyter-enterprise-gateway.readthedocs.io/en/latest/
  8. jupyter-enterprise-gateway.readthedocs.io/en/latest/operators/deploy-kubernetes.html
  9. jupyter-enterprise-gateway.readthedocs.io/en/latest/operators/config-culling.html
  10. pypi.org/pypi/jupyter_enterprise_gateway/json

Cite this page

Agent Sandboxes. (2026). Jupyter Kernel Gateway. agentsandboxes.org. Last reviewed November 9, 2026. https://agentsandboxes.org/sandboxes/jupyter-kernel-gateway/

Found an error or a missing sandbox? Submit a correction — every entry links to the sources it relies on.