Jupyter Server: the backend that Notebook, Lab and Voilà all share

One backend, three front ends, and that is the division of labour

The Jupyter Server provides the backend, meaning the core services, APIs and REST endpoints, for Jupyter web applications like Jupyter notebook, JupyterLab and Voilà. That single sentence is the architecture. The user interface is a separate project in each case, and the server underneath is the same, which is why a Notebook install and a Lab install end up speaking the same REST dialect to their kernels. The homepage is jupyter-server.readthedocs.io and the primary language is Python. The package is published as jupyter_server and it is BSD-3-Clause licensed, which for a server component that other people's applications depend on is a sensible choice. The design has a practical consequence for anyone building on it: if you want a Jupyter application that is not Notebook or Lab, you are not writing a server, you are writing a front end and adopting this one, so the REST endpoints become your public contract and the version you pin becomes your API version.

The dependency list is the clearest statement of what a Jupyter app needs

The pyproject.toml names the runtime dependencies, and reading them tells you what the server actually does. Tornado at 6.2.0 or newer is the async web framework underneath, and traitlets at 5.6.0 or newer is the configuration system that makes the server declaratively configurable. AnyIO provides the async compatibility layer, and jinja2 is the template engine. On the notebook side there is nbformat, nbconvert and jupyter_client, with jupyter_core and jupyter_server_terminals for the surrounding machinery, and terminado and pyzmq for the terminal and ZeroMQ sides of talking to a kernel. The security and auth side shows up as argon2-cffi for password hashing and websocket-client for the websocket traffic, and jupyter_events is there for the event system, with overrides pinned for Python below 3.12. The Windows specific entry is worth a closer look, because pywinpty is pinned with an exclusion: the version 3.0.4 ships broken Windows wheels with winpty.dll and the native binaries for arm64 no longer bundled, so the pyd fails to load, the import raises an ImportError, terminado falls back to object, and the resulting object.spawn AttributeError breaks the terminal. The project therefore pins pywinpty at 2.0.1 or newer while excluding 3.0.4 on Windows.

Installing and starting it takes two commands

To install the latest release locally you need pip installed, and then the install itself is one line.

pip install jupyter_server

Jupyter Server currently supports Python 3.10 or newer on Linux, OSX and Windows, and the pyproject classifiers agree, listing Python 3 only and the framework as Jupyter with a production and stable development status. Launching a local instance is the second command.

jupyter server

That is the whole quick path, and it is deliberately short, because the point of the project is to be the piece you do not think about. The documentation lives at jupyter-server.readthedocs.io, the contributing guide is CONTRIBUTING.rst with a section on running tests, and the tree at the top level shows the shape of a modern Python project with a pyproject.toml, a tests directory, an examples directory, a docs directory, a CHANGELOG.md and a RELEASE.md, alongside a jupyter_server package directory and a package.json that exists for the front end assets.

Why the package.json exists at all, and what Bootstrap is doing there

The presence of a package.json in a Python project is worth explaining rather than skipping. The manifest is marked private, and its only build script copies the minified Bootstrap CSS from node_modules into the static style directory of the package. Bootstrap is pinned at the 3.4 series, and copyfiles does the copy. The eslint configuration ignores minified files, anything with components in the name, node_modules and build directories, and the babel preset is es2015. So the JavaScript toolchain here is not a build pipeline for the server, it is a way of vendoring a stylesheet that the server's HTML pages use, and the pre-commit and prettier configuration at the top of the tree points to a project that does run JavaScript formatting over what little JavaScript exists. It is a small example of the wider pattern in Jupyter, where a Python package still has to ship some static assets and therefore has to keep a Node toolchain in the loop.

Semantic versioning, with a warning that matters if you depend on it

The versioning section is the part of the readme most relevant to an engineer deciding whether to depend on this. If Jupyter Server is a dependency of your project or application, it is important that you pin it to a version that works for your application. Jupyter Server follows semantic versioning, where major versions may include breaking API changes, minor versions add functionality in a backwards compatible way, and patch versions contain backwards compatible bug fixes. Given that the project is the REST and services layer for other people's front ends, that breaking-change surface is large, which is why the pinning advice is stated as an instruction rather than a suggestion. Maintenance branches are kept for prior major release lines, with 1.x given as the example, and the main branch always reflects the latest unreleased version, so a checkout of main is explicitly not something to pin against. To see what changed between releases, the readme points at the CHANGELOG.

The examples directory shows the three configurations people actually need

The tree has an examples directory with three named subdirectories, and they line up with the three things a server deployment has to decide. There is an authorization example, which is the identity and permission layer, an identity example, which covers who the user is, and a simple example, which is the baseline server. That is a useful shape for a project whose hardest configuration problem is not the server but the access model around it, since a Jupyter Server that anyone on the network can open is a serious problem in most deployments. The documentation badge points at the readthedocs project and the build badge at a GitHub Actions workflow that runs the Python tests against the main branch. The recent releases are v2.21.1 from 2026-09-15, v2.21.0 from 2026-08-27 and v2.20.0 from 2026-06-17, and the last push to the repository was on 2026-10-05, so the 2.x line is the current one.

A shared copyright model, and where the maintainers meet

The copyright policy section is unusual enough to be worth reading, because it says something about the project rather than the code. Jupyter uses a shared copyright model, where each contributor maintains copyright over their contributions, but the important part is the caveat: those contributions are typically only changes to the repositories, so the Jupyter source code in its entirety is not the copyright of any single person or institution. Instead it is the collective copyright of the entire Jupyter Development Team, and a contributor who wants a record of their specific copyright should indicate it in the commit message of the change. The readme gives the banner to use in any source file.

# Copyright (c) Jupyter Development Team.
# Distributed under the terms of the Modified BSD License.

The Jupyter Development Team is described as the set of all contributors to the Jupyter project, including all of the Jupyter subprojects, with the core team that coordinates development on GitHub at the jupyter organisation. The team meetings are on Thursdays at 8:00am Pacific time on a Jovyan Zoom, with the meeting notes and agenda kept in separate issue trackers, and the tentative roadmap lives in an issue on the repository.

Editorial conclusion

Jupyter Server fits a team that ships a custom front end on top of the Jupyter stack, whether that is a bespoke notebook application or an embedding of JupyterLab, because the whole point of the project is to keep the backend, the REST surface and the kernel plumbing in one place instead of in each front end. It does not fit a user who just wants to run notebooks, because they should install Notebook or Lab directly and will get a compatible server automatically, and it does not fit a deployment that ignores the pinning advice, since major versions can carry breaking API changes. Before you depend on it, pin the version your front end works with, read the CHANGELOG between releases, and check the pywinpty constraint on Windows, where the project pins away from 3.0.4 because the shipped wheels fail to import.

Frequently asked questions

Official sources

1. jupyter-server/jupyter_server on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases