What Is Jupyter Server and How Does It Relate to Jupyter Notebook and JupyterLab?

Jupyter Server is the backend that provides the core services, APIs, and REST endpoints for Jupyter web applications. It is a replacement for the Tornado Web Server that was previously embedded in Jupyter Notebook, and JupyterLab runs on top of it. If you are trying to understand the Jupyter stack — or you are migrating from the classic Notebook server — the key idea is that Jupyter Server is the shared foundation, while Notebook and JupyterLab are frontends or applications built on that foundation.

The three layers, separated

The Jupyter documentation describes Jupyter Server as "a highly technical piece of the Jupyter Stack," which is why its docs are split by persona (Users, Operators, Developers, Contributors). The relationship between the projects is easiest to see as a stack:

So JupyterLab is not a competitor to Jupyter Server — it is an application that runs on it. The documentation lists JupyterLab first among examples of Jupyter Server extensions, alongside Jupyter Resource Usage, Jupyter Scheduler, jupyter-collaboration, NbClassic, and Cylc UI Server.

What "replacement for Tornado Web Server" actually means

In the classic Jupyter Notebook, the web server logic and the notebook application were bundled together. Jupyter Server extracts that server layer into a standalone project. The documentation states plainly that Jupyter Server is a replacement for the Tornado Web Server in Jupyter Notebook, and that Jupyter web applications should move to using Jupyter Server.

The practical consequence: a single Jupyter Server can host multiple extensions and applications, rather than each application carrying its own server implementation. That is why the docs frame extensions as the primary way to build on Jupyter Server — they "use the framework and services provided by Jupyter Server to create applications and services."

How this affects you

The answer depends on which role you are in, since the documentation separates guidance by persona:

• Users — people using Jupyter web applications. Relevant docs cover installation, configuring a Jupyter Server, and launching a bare Jupyter Server.
• Operators — people deploying or serving Jupyter web applications to others. Relevant docs cover managing multiple extensions, configuring extensions, running a public Jupyter Server, security, and logging.
• Developers — people writing Jupyter Server extensions and web applications. Relevant docs cover architecture diagrams, depending on Jupyter Server, the REST API, server extensions, file save hooks, the Contents API, and WebSocket kernel wire protocols.
• Contributors — people contributing directly to the Jupyter Server library.

If you are migrating from the classic Notebook

The documentation provides a dedicated "Migrating from Notebook Server" page, and also covers "Running Jupyter Notebook on Jupyter Server." If your setup currently depends on the Notebook's built-in Tornado server, those two pages are the starting point rather than the general introduction.

Where to go next

The documentation's table of contents is organized so you can jump straight to your role rather than reading linearly. If you only need one thing from this page: Jupyter Server is the backend layer, JupyterLab and Notebook are applications on top of it, and the migration path from the old Notebook server is documented explicitly. If you find gaps in the docs, the project asks you to open an issue or a pull request on the Jupyter Server GitHub repo.