A partial glossary of terms used in this guide. For more complete descriptions of the components in JupyterHub, see Utilized Tools. Here we try to keep the definition as succinct and relevant as possible, and provide links to learn more details.

admin user#

A user who can access the JupyterHub admin panel. They can start/stop user pods, and potentially access their notebooks.


The way in which users are authenticated to log into JupyterHub. There are many authenticators available, like GitHub, Google, MediaWiki, Dummy (anyone can log in), etc.


The Helm charts templates are rendered with these Helm values as input. The file is written in the YAML format. The YAML format is essential to grasp if working with Kubernetes and Helm.


A container is a isolated working space which for us gives users the tools, libraries, and capabilities to be productive.


A separate process in the JupyterHub that stops the user pods of users who have not been active in a configured interval.


A Dockerfile declares how to build a Docker image.

Docker image#

A Docker image, built from a Dockerfile, allows tools like docker to create any number of containers.

image registry#

A service for storing Docker images so that they can be stored and used later. The default public registry is at, but you can also run your own private image registry. Many cloud providers offer private image registry services.

environment variables#

A set of named values that can affect the way running processes will behave on a computer. Some common examples are PATH, HOME, and EDITOR.

Helm chart#

A Helm chart is a group of Helm templates that can, given its default values and overrides in provided yaml files, render to a set of Kubernetes resources that can be easily installed to your Kubernetes cluster. In other words a Helm chart is like a configurable installation of software and infrastructure to exist on a cloud.

Helm template#

A Helm template (.yaml files), can given values, render to a Kubernetes resource.

Helm values#

Helm charts has a set of predefined values (values.yaml) typically overridden by other values in config.yaml. The final values are used to generate Kubernetes resources from Helm templates within a Helm chart.


For our purposes, you can think of Kubernetes as a way to speak to a cloud and describe what you would like it to do, in a manner that isn’t specific for that cloud.

Kubernetes API server#

The Kubernetes API server, also referred to as the master, will answer questions and update the desired state of the cluster for you. When you use kubectl you communicate with the API server.

Kubernetes Pod#

Pods are the smallest deployable units of computing that can be created and managed in Kubernetes. A pod will use a Docker image to create a container, and most often a controller such as a Deployment will ensure there is always X running pods of a kind.

See the Kubernetes documentation for more information.

Kubernetes resource#

A Kubernetes resource can for example be a Deployment, Service or a Secret. It is something you can request by the Kubernetes API server to be present in the cluster.

persistent storage#

A filesystem attached to a user pod that allows the user to store notebooks and files that persist across multiple logins.

Node Pool#

A node pool or node group represents a set of nodes of the same kind. With cluster autoscaling, a node pool can grow and shrink based on demand allowing you to save computational resources.


A tool which lets you quickly convert a Git repository into a Docker image.


A spawner is a separate process created for each active user by JupyterHub. They are each responsible for one user. This Helm chart relies on KubeSpawner.