Jupyter Blog

JupyterHub 6.0

2026-09-11T08:54:00+00:00

By Serena Bonaretti and Min Ragan-Kelley

JupyterHub is a collection of tools that provides standardized, user-friendly computing environments for education and research. Today, we’re pleased to announce the release of JupyterHub 6.0. This is a substantial release with several new features. The breaking changes ought to be minimal, and should affect very few deployments. There is a small database schema upgrade, so make sure to backup your database prior to upgrading, as usual.

Some changes to highlight:

Stricter named server rules: Named servers now have stricter rules on their names, and a new less-restricted “display name” field. This might be the most significant change affecting you! See the documentation for more details.
Python 3.10 and database upgrade: JupyterHub 6.0 now requires Python 3.10 and includes a database schema upgrade. Make sure to back up your database before upgrading.
Updates to metrics: The old StatsD metrics have been removed, in favor of the Prometheus metrics that most people are already using. For Spawner (and spawn hook) authors, JupyterHub 6.0 also introduces SpawnException, which provides more granular information for classifying spawn failures in metrics, to help deployments separate errors from rejections.
Internal communication changes: JupyterHub now uses aiohttp for internal HTTP requests, which may require tuning for large deployments since internal HTTP requests. This update has facilitated using unix sockets for internal communication on single-node deployments.
Improved granularity in API access: JupyterHub provides new API endpoints for working with single servers, along with more flexible ways to define permissions, such as start:servers scope and extra_user_scopes.
See the documentation for more information.

Beyond these main changes, there have been lots of other improvements and bugfixes. You can find more details in the upgrading documentation and changelog.

Thank you to our contributors

The following people contributed discussions, new ideas, code and documentation contributions, and review: agoose77, anny0811, ateucher, betatim, bl-aire, clhedrick, consideRatio, dometto, dragz, erawn, ericvd-ucb, jezwilkinson, jnywong, jrdnbradford, kellyrowland, kreuzert, LUC4R4T0R, manics, mayli, milliams, minrk, mynkyu, nsychev, Paul2708, Rameshkumar31595, rgaiacs, shaneknapp, sixonenines, tbizouerne, Tech-Abhang, wilkinvr, willingc, yuvipanda

Mark Your Calendars: Jupyter Day 2026 is Coming to San Jose!

2026-09-04T10:01:00+00:00

Project Jupyter has always grown around its community. From early notebook hacks to large-scale deployments across research labs and universities, what makes this ecosystem work is the people building tools, running infrastructure, and sharing workflows.

That is why we are excited to announce Jupyter Day 2026, happening on Monday, October 19, 2026, at the San Jose Convention Center in California!

This year, we are co-locating with PyTorch Conference North America. If you are already planning to be in town for PyTorch, you can easily add Jupyter Day to your week — or you can simply register to attend Jupyter Day on its own!

What We Are Covering

Jupyter Day is a focused event for developers, maintainers, data scientists, educators, and system admins to talk about real-world setups and future project architecture.

Here are the main tracks and suggested topics for the event:

Data Science: How Jupyter is used by data science practitioners across industry, government, research, and beyond.
Community & Ecosystem: Insights into the Jupyter community, frontends, kernels, custom extensions, and essential ecosystem tools.
Research and Scientific Discovery: Practical applications in specific scientific fields, including medical research, astronomy, physics, climate science, meteorology, social sciences, and the humanities.
Education: Practical methods and strategies for teaching and learning with Jupyter across diverse educational settings.
Jupyter Infrastructure: Deploying Jupyter and JupyterHub at scale across high-performance computing, cloud environments, enterprise, and academia — covering DevOps, scaling, security, and compliance.
AI & Machine Learning: Leveraging AI and machine learning inside Jupyter and using Jupyter environments to drive ML development.

Whether you want to showcase a JupyterLab extension you built, explain a tricky deployment setup, or discuss new open standards, we want to hear from you.

Call for Proposals is Open!

The Call for Proposals (CFP) is live right now. We are looking for technical talks, panel ideas, and poster presentations from every part of the community.

CFP Deadline: Sunday, September 13, 2026 at 11:59 PM PDT
Submit your proposal: Jupyter Day CFP Portal

Put your organization front and center at Jupyter Day 2026! Sponsoring this event connects your brand directly with core developers, researchers, and AI leaders building the future of open-source interactive computing.

View opportunities: Download the Jupyter Day 2026 Sponsorship Prospectus.
Get in touch: Reach out to jupyterevents@linuxfoundation.org to reserve your sponsorship or ask questions.

You can find full event details, hotel info, and registration links directly on the Linux Foundation event page.

We hope to see you in San Jose this October!

A Robotics Workbench for JupyterCAD

2026-09-02T18:22:00+00:00

Robotics education often hits a wall before the fun even begins. Students and engineers must first navigate a labyrinth of installations: ROS, environment configurations, dependency management, and a patchwork of software, just to visualize a simple robot. It doesn’t have to be this way.

Thanks to Jupyter and its extensions, the entire process, from designing a robot to simulating its kinematics, can now happen entirely in the browser, in a single workspace with zero local installation.

The Problem: The Fragmented Robotics Pipeline

Traditionally, creating a robot model involves dealing with three distinct, often incompatible worlds:

Parametric Design: Creating the shapes in dedicated CAD software (FreeCAD, SolidWorks, and the like).
Mesh Generation: Exporting those solid bodies into triangular meshes (STL) while manually managing the coordinates and file paths.
Kinematic Description: Writing URDF (Unified Robot Description Format) XML that ties the meshes together using joints and other parameters.

Getting this pipeline working locally typically requires a complete ROS installation, a source of friction for students and educators.

The Solution: A Unified Browser Workflow

By leveraging the JupyterCAD and JupyterLite, this entire toolchain is delivered as an instant, zero-install workspace in the browser. It is made available on the notebook.link service.

1. JupyterCAD: The Design Hub

JupyterCAD is a JupyterLab extension for collaborative 3D modeling. It also supports FreeCAD files and offers a full set of tools for creating, transforming, and combining 3D shapes.

It can also export to various formats:

STL/BREP: Users can simply right-click any shape and generate meshes directly in their browser.

FreeCAD: Through the JupyterCAD-FreeCAD plugin, designs can move freely between the browser and desktop CAD (FreeCAD) without losing the feature tree, exporting back and forth between the .jcad and .FCStd formats.

2. JupyterCAD-URDF: The URDF Workbench for JupyterCAD

JupyterCAD-URDF is a JupyterCAD plugin for exporting CAD designs to the URDF format.

It generates STL meshes automatically for complex shapes. For simple primitives (boxes, spheres, and cylinders), it emits XML tags instead of producing external mesh files.
It produces a URDF XML document that references those meshes while preserving hierarchies, names, colors and placements.

3. JupyterLab-URDF: Interactive Kinematics

Once the model is exported, the JupyterLab-URDF extension, which can be used in JupyterLab independently of JupyterCAD, allows for inspection of the XML content as well as interactive 3D visualization:

Real-Time Kinematic Articulation: Drag joint sliders to test degrees of freedom, joint limits, and coordinate hierarchies in real time.
3D Scene Controls: The control panel has several settings to customize the scene, such as coordinate frame helpers, lighting controls, mesh visibility, and other options.
Joints Editor: An interface to define kinematic relationships (joints) between parts by selecting them directly in the 3D scene. This allows for creating new joints or editing existing ones.

Walkthrough: Zero-to-Robot Workflow

This new pipeline allows a student to go from a blank page to a moving robot:

Phase 1: CAD Modeling & Export (JupyterCAD + JupyterCAD-URDF)

Design parametric parts in JupyterCAD.
Export to URDF using JupyterCAD-URDF.

Phase 2: Assembly & Simulation (jupyterlab-urdf)

Assemble the generated URDF in jupyterlab-urdf and use the Joints Editor to connect links.
Simulate the robot movement using the joint sliders.

You can try it right now without any local installation thanks to the deployment on notebook.link, by following the link below.

Repos

All tools in this pipeline are free, open source, and available on GitHub, PyPI, npm, and Conda-forge:

Acknowledgements

This work was conducted at QuantStack as part of an effort to make 3D modeling and robotics accessible directly in web-native environments.

Special thanks go to everyone in the open-source community who made this possible, to Isabel Paredes, the creator and maintainer of the jupyterlab-urdf extension, to Le Duc Trung and Martin Renou, the main contributors to JupyterCAD, and to everyone else at QuantStack who helped with this project.

About the Author

Yahia Heni is a software engineer at QuantStack, focusing on the Jupyter Ecosystem, by contributing to Jupyter and several of its extensions, as well as notebook.link and other related open-source projects.

What you told us: results from the 2026 Jupyter User Experience and Product Enhancement Survey

2026-08-25T13:42:00+00:00

From time to time, Jupyter runs user surveys to understand how our communities use Jupyter technology (or alternatives) and how they feel about it. The Jupyter Foundation recently completed a user experience survey for 2026. It was open between 29 May and 29 June 2026, with 542 people providing answers. This post covers what we found, what you can do today about the most common problems, and where we are looking for proposals.

Each of the areas below rose to the top of pain points that users consistently felt. We would love to see applications in the 2026 Call for Proposals that address any of these areas by improving Jupyter technology. In some areas, there are already Jupyter or third-party open-source tools that address some of the issues, and we list them as a guide to readers who want to learn more.

About the responses*: Three of the six questions were free text, and 246 people wrote something in at least one of them, some at considerable length. Writing several paragraphs about environment setup or version control at the end of a survey takes real time, and that detail shaped most of what follows. We want to extend our heartfelt appreciation to everyone who answered this survey, high-quality experience stories like this are crucial at shaping Jupyter’s priorities and technical direction.*

Who answered

Two thirds of respondents (65%) use Jupyter for data science and analysis, and 55% use it in education. Smaller groups deploy Jupyter for others (14%), develop extensions (14%), or contribute to the open-source project (12%). These add to more than 100% because the question accepted multiple answers. See the Appendix below for a deeper dive into the respondents and the tools they reported using. Below we’ll focus on the pain-points and themes that were commonly reported, since those are the most actionable for our community to improve upon and learn from.

Common themes that people raised

We reviewed all 677 free-text responses and coded the recurring themes, cross-checking the coding against the source responses.

Environment and dependency management, and version control and collaboration, are the two largest friction themes, and between them account for 51 of the 246 people who wrote to us, with 7 raising both. Other themes follow closely: interface and editor parity (17 people), handling large data sets and performance (15), documentation and discoverability (14), respondents who use a different tool instead (13), deployment and multi-user operations (12), and security, authentication and compliance (6).

When we asked what is blocking people from using Jupyter more, 130 of 239 answers named something concrete, while 53 said that nothing is blocking them, either in a sentence or as a one-word “no”. Limited time and competing priorities appear throughout those 53 responses.

The Foundation is committed to finding ways to address these pain points across our community, and we’ll be exploring other ways to make progress in these areas in the coming months.

Environment and dependency management

This was the largest friction theme, raised by 32 people across 51 responses.

The responses concentrate in three sub-problems:

Installation and first run, and package and dependency management, account for 17 responses each.
Environment and kernel registration accounts for 13
Reproducing an environment on a second machine for 4.

What connects them is that the failures arrive early and are hard to diagnose from the error message alone. For example: an installation completes but the jupyter command cannot be found; packages install into one environment while the notebook runs a kernel from another; a course needs the same environment on thirty machines that nobody administers centrally. Each of these has a known cause, and in many cases, a known fix, but users struggle to find the right solution to these problems.

We welcome submissions in our Call for Proposals to improve upon these pain points! We’ve also listed a few open-source tools from Project Jupyter and the third-party ecosystem that partially address these challenges.

Open-source tools that partially address this problem:

From Project Jupyter:

JupyterLab Desktop bundles Python and JupyterLab in a single installer and removes most first-run failures. v4.6.2 was released recently.
JupyterLite and Binder avoid per-machine installation entirely, which is often the right answer for teaching.
python -m jupyter lab works when a pip install succeeds but the entry point is not on your PATH. This is a common cause of “command not found” straight after a successful install.
repo2docker fetches a git repository and builds a container image based on the configuration — useful for creating reproducible images for use with Binder or JupyterHub
%pip install and %conda install run inside a notebook and install into the environment the running kernel is actually using, which is usually what goes wrong when installing from a terminal

From third-parties:

better package installation from UI
- gator creates and manages conda environments from the JupyterLab interface
- package-manager browses and installs Python packages without leaving the interface
kernel per environment which encodes “lockfile”
- pyproject-local-kernel provisions kernels per environment for the project the notebook file resides in
- pixi-kernel Per-directory Pixi environments with multi-language Jupyter kernels
notebook itself can include requirements
- juv is CLI tool that encodes dependencies in the notebook using PEP 723 (inline script metadata) and creates ephemeral virtual environments for kernel execution
- juvio also encodes dependencies in the notebook using PEP 723 but also includes bespoke integration with jupyter kernel spec manager and a JupyterLab extension
better integration with other environment management tools
- nb-conda-kernels and nb-nebi-kernels provision kernel specs auto-discovered from all conda and nebi-tracked pixi environments respectively
- jupyterlab-launchpad replaces the launcher with one that has first-class support for kernels discovered from conda and nebi-tracked pixi environments
- jupyterhub-fancy-profiles allows JupyterHub users to select a Binder-like environment and build it at hub launch time

Several respondents asked for closer integration between Jupyter and environment managers, including a graphical option for people who do not work at a command line, which is part of what those extensions provide. A consistent environment and kernel story across package managers and operating systems still requires sustained work across several projects, and we would welcome proposals in this area. Another area where future work is needed is preventing the drift between server and kernel environments (join the discussion).

Version control and collaboration

This theme was raised by 26 people across 33 responses.

Git diffing and merging accounts for 13 responses, real-time collaboration for 9, sharing and publishing for 8, and review and commenting for 3.

The underlying cause is that the notebook format stores code, outputs and execution metadata in a single JSON document. Tools built to compare source line by line report changes that are technically accurate and hard to read: re-executing a cell without editing it can produce a large diff, and merges conflict on execution counts and output data rather than on anything a person wrote (which can be desirable when reproducibility is the primary goal, but less so when prioritizing iterative development). Reviewing a colleague’s notebook therefore costs more than reviewing an equivalent script, which pushes teams either toward exporting notebooks to scripts before review, or toward skipping review.

We welcome submissions in our Call for Proposals to improve upon these pain points! We’ve also sourced a few recommended tools within Jupyter and from third-parties that partially address these challenges, and list them below for readers that want to learn more.

Open-source tools that partially address this problem:

From Project Jupyter:

nbdime provides content-aware diff and merge that understands cells and outputs. Running nbdime config-git --enable --global once makes git diff on a notebook readable.
jupyterlab-git brings Git operations into the JupyterLab interface and uses nbdime for diffs.
jupyter-collaboration brings real time collaboration; it allows several people to edit the same notebook simultaneously and time-travel to older versions.

Third-party:

Jupytext pairs a notebook with a .py or .md file that diffs and merges like an ordinary source, which makes notebook changes reviewable in a normal pull request.
nbstripout tools remove most merge conflicts for teams that do not need outputs in version control. The community has produced at least three variants: nbstripout, the original; nbstripout-fast, a faster alternative; and fastai-nbstripout (no longer maintained). They differ in behaviour and performance, so pin whichever you adopt. We read this fragmentation as a consequence of the gap, and a single well-supported answer would be a reasonable thing to propose.

Most of the tools above ship separately from JupyterLab and have to be installed and configured before they help, which limits how many people find them. We are considering both closer integration of these tools into the default experience and approaches that reduce the underlying problem, and we would welcome proposals for either.

Review and commenting on notebooks remains the clearest gap. Nothing in the current open-source stack provides a way to leave a comment on a cell and resolve it later; that also works for colleagues who do not use GitHub.

The interface, and parity with editors

Seventeen people wrote about the interface, and their requests are concrete rather than architectural: completion as you type, a variable explorer, working drag and drop, faster scrolling in long notebooks, and a more modern appearance.

We welcome submissions in our Call for Proposals to improve upon these pain points! We’ve also sourced a few recommended tools within Jupyter and from third-parties that partially address these challenges (including a few JupyterLab plugins that directly solve the problem), and list them below for readers that want to learn more.

Open-source tools that partially address this problem:

From Project Jupyter:

JupyterLab Desktop. The project went through a period with little activity, which some respondents referred to. It now has active maintainers and regular releases, and v4.6.2 was published after the survey closed.
Jupyter Notebook v7 now includes multiple improvements covering features requested by respondents, inheriting them from JupyterLab; after reviewing the survey answers we improved the documentation to mention the variable explorer available in the debugger (which has basic support, while the plugin below has more in-depth support) and the opt-in as-you-type autocompletion.
jupyterlab-lsp adds better completion, jump-to-definition, signature help and diagnostics.

Third-party: the variable explorer people asked for, plus several conveniences carried over from mainstream editors.

jupyterlab-variableInspector and variable-inspector both provide the variable explorer that came up more than once
jupyterlab-quickopen jumps to a file by name.
jupyterlab-unfold gives a tree-style file browser.
jupyterlab-code-formatter formats code cells.
jupyterlab-favorites pins frequently used directories.
jupyterlab-vim for vim users
jupyterlab-search-replace for search and replace across file

Thirteen respondents told us they use another tool instead: VS Code, Google Colab, Spyder or Positron, marimo, or plain Python scripts. We are glad that support for Jupyter notebooks and kernels has landed in many editors and has inspired other notebook-based applications. Maintaining an open ecosystem where people can move between the tools that suit their workflow matters to us. For reactive execution in particular, ipyflow brings dataflow-aware execution inside the JupyterLab interface.

Artificial Intelligence

Twenty-four of the 246 people who wrote free text mentioned AI. Of those, 14 asked for more AI capability in Jupyter, 1 asked for it with explicit caveats, 3 objected to AI being a priority, and 5 mentioned AI (e.g. as a use case) but did not take a stance.

Three requests recur:

Explanation at the point of failure. Clearer error messages and guidance for people who are learning, including one request for a “fix code” action placed directly below an error.
Working with self-hosted and third-party models. Support for running against “own LLM-servers”, compatibility with proxy layers, and simpler installation of Jupyter AI, which one respondent described as too complicated to set up.
Help with libraries, and checking generated code. Finding relevant packages within a research field, and being able to validate generated code before running it against real data.

The objections are about prioritisation, and specifically that AI work displaces maintenance and work on features aimed at human users.

Over the past twelve months the Foundation has facilitated several rounds of AI workshops and summits, and more are planned. Anyone is welcome regardless of their stance. Working out how the project should respond to increasing AI usage in data analysis and teaching needs both positions in the room. Proposals through the funding process are welcome here too.

Other themes

Here we list a few more themes that showed up in the survey responses along with some open-source tools that can help as of August 2026.

Theme	People	What might help today
Performance with large data	15	Recent versions of JupyterLab/Notebook improve UI performance. Large outputs freezing the browser can be prevented by using visualisation and tabulation libraries that make use of rasterization and canvas renderers (e.g. plotly, ipydatagrid or newcomers like xy). Third-party extensions streamline work with large dataset in dedicated big data formats (e.g. jupyterlab-h5web for HDF5, NeXus, ANNData, etc; Arbalister for Parquet, CSV, Avro, ORC, SQLite, Arrow IPC).
Documentation and discoverability	14	Jupyter documentation and Discourse. We are aware that changelogs and breaking-change notes are missing or inconsistent across subprojects, and this needs addressing.
Deployment and multi-user operations	12	The Littlest JupyterHub for single-server teaching and Zero to JupyterHub on Kubernetes. batchspawner for Slurm and HPC, systemdspawner for resource limits and sandboxing. Third-party: jupyterhub-usage-quotas and jupyterhub-cost-monitoring.
Security, authentication and compliance (including accessibility)	6	JupyterHub authenticators cover most institutional identity providers, and Zero to JupyterHub documents TLS and network configuration. jupyterlab-a11y-checker is a UC Berkeley CDSS extension for assisting authors of extensions. New versions of Jupyter software include notable accessibility improvements: JupyterLab, myst-theme
Teaching and grading	8	nbgrader for assignment distribution and autograding, usually alongside JupyterHub.
Execution model and cell state	8	In IPython `%load_ext autoreload` followed by `%autoreload 2` gives hot reload while developing a package against a live kernel. Third-party ipyflow brings reactive execution to Jupyter interfaces.
Publishing and export	7	`jupyter nbconvert --to webpdf` produces PDFs without a LaTeX installation. Jupyter Book for longer documents and Voilà for dashboards. Third-party: Quarto.
Mobile and tablet access	3	No good answer today. Recent work on lumino is addressing certain limitations.
Non-Python kernels	3	Maturity varies by language. Specific bugs are best filed on the relevant kernel’s issue tracker, where they can be followed up.
Excel and spreadsheet interop	3	JupyterLab opens CSV and TSV files in a data grid without any extension. Third-party: jupyterlab-spreadsheet-editor makes CSV and TSV files editable in place, and jupyterlab-spreadsheet opens Excel workbooks read-only.

Submit a proposal

Most of what people asked for needs sustained work rather than a configuration change. The Jupyter Foundation’s Community Funding Proposals process is open through the 9th of September, 2026. Proposals do not need to come from existing maintainers, and you can propose work without intending to be the person who carries it out.

Larger changes may warrant a new Jupyter Enhancement Proposal, or completing work on an existing one. Both are in scope for community funding, and are expected to involve support and consensus building in the community.

Thank you

Once again, thank you to the 542 people that offered their time and expertise to provide responses to our user survey. For those interested in the 2026 Call for Proposals, we’d love to see submissions that address these pain points. Keep an eye open for future surveys, as they have a big impact on where Jupyter improves its technology moving forward.

Appendix

Here is some more information about the survey respondents and the kinds of tools they used in general. We share it below in case it helps provide context for the analysis above.

The data, and how to read it

An anonymized version of the dataset is available at jupyter.org/surveys (repo here: github.com/jupyter/surveys), together with the analysis notebook that produced every figure in this post, including its caveats and the checks that did not work.

Analysing the questionnaire turned up several problems worth fixing before reusing the questions, and worth taking into account when re-analysing the data: a question that asked for a single primary answer while accepting several, a list that mixed applications with libraries and server components, and a question that asked two things at once.

Around 6% of this dataset shows clear quality problems, rising to roughly 11% under a stricter definition that also counts respondents who selected every available option. We even had two self-identified AI assistants fill in the survey. We re-ran the headline figures with those responses removed and none of the percentages moved by more than a point.

Product-use numbers

We asked participants to note the Jupyter tools that they use, and share the results below. A caveat for this data: we learned that many Jupyter users do not easily distinguish between the many different tools in the “Jupyter Stack”, and respondents often only chose one tool while many were likely in-use (e.g. only choosing “IPython” but not choosing “Jupyter Server”, which is almost always used alongside IPython). We’ll try to improve our methodology to tease this out more effectively in the future, but share the data below for others.

To understand whether the above question was skewed by the effect of mistakenly only responding with one selection, while many selections were more appropriate, we broke down the answers to the above question by whether the respondent also selected at least one other option. Of 542 respondents, 303 ticked exactly one box.

Nearly half of all IPython/ipykernel selections came from people who ticked nothing else, which suggests that some respondents ticked the single item they recognised rather than enumerating everything they use. For example, jupyter-server usage should be equal or greater to that of JupyterLab and Notebook (while alternative servers such as jupyverse exist, adoption of these would not explain the gap). We would treat these percentages as reflecting name recognition at least as much as adoption. Which products are used together holds up better: among the 239 people who ticked more than one, Binder, JupyterHub, Jupyter Server, Jupyter Book and ipywidgets form a clear cluster.

Usage patterns

Just over half (53%) use Jupyter daily for more than thirty minutes, 15% once a day for shorter sessions, 17% weekly, and 16% monthly or less. The sample leans heavily toward regular users. The survey was open for a month, with almost all responses arriving in the final nineteen days.

JupyterGIS 0.16: New visualization capabilities, collaborative Story Maps, and more

2026-08-24T16:09:00+00:00

Read this article in Notebook.link, as a live story-map! https://notebook.link/@martinRenou/jupytergis-announcement

Earlier this year, we introduced STAC browsing and Story Maps in JupyterGIS, making it easier to discover geospatial datasets and communicate results without leaving Jupyter.

JupyterGIS 0.16 continues in the same direction. This release adds support for new geospatial formats, tighter integration with the scientific Python ecosystem, a redesigned Story Map editor, and a more expressive way to style geographic data.

Story Maps are getting a new look!

Story Maps in JupyterGIS let you build a scrollable presentation around your map. A Story Map is made up of a sequence of segments that can combine Markdown content with map views, so you can guide the reader through a geographic story as they scroll.

Each segment can define its own map state, including the current map location, visible layers, and layer styling. This means that the map can change as the reader moves through the story: layers can appear or disappear, the view can move to a new location, and symbology can change to highlight different aspects of the data.

Story Maps have received a significant update in this release.

Read this article in Notebook.link, as a live story-map! https://notebook.link/@martinRenou/jupytergis-announcement

The Story-map associated to this release annoucement. It contains Text, images, and map views with associated layer states.

A better Story Maps editing experience

We’ve also made substantial improvements to the Story Map editing experience.

The editor has been redesigned around Jupyter’s real-time collaboration infrastructure, allowing multiple people to edit the same Story Map simultaneously. Changes appear immediately for everyone, making it much easier to prepare presentations, reports, or educational material as a team.

Collaboratively edit the Story Map markdown.

The editor now gives you a much better sense of what the final story will look like while you are working on it. Markdown sections can be previewed directly in the editor, and a new Story Map preview makes it possible to see the complete presentation without leaving the editing workflow. This makes it easier to write, arrange, and refine a story while keeping an eye on the final result. We’ve also introduced a new layout that is better suited for long-form content. In addition to guided geographic narratives, Story Maps can now be used to create richer articles combining text, maps, images, and other interactive content.

New Story Map editor: Set story segment viewport, preview markdown, set layers properties for the story segment.

OpenEO layers

More and more geospatial workflows rely on remote processing instead of downloading datasets locally. openEO provides a common API to describe these processing pipelines as process graphs that are executed by a backend.

JupyterGIS can now display openEO process graphs directly as map layers. Instead of exporting intermediate results before visualizing them, you can connect an openEO backend and inspect the output of your processing pipeline directly in the map.

The visualization is tile-based and lazy: JupyterGIS only requests the data needed for the current map view and zoom level. This makes it possible to explore large remote sensing workflows interactively, without materializing the full result locally.

JupyterGIS can make use of any openEO server that supports tiling, such as titiler-openeo

import openeo
from jupytergis import GISDocument
from openeo.processes import process

connection = openeo.connect(SERVER_URL)
connection.authenticate_basic(username=BASIC_AUTH, password=BASIC_AUTH)

cube = connection.load_collection(
    "sentinel-2-global-mosaics",
    bands=["B03", "B08"],
    temporal_extent=["2022-04-15", "2022-12-31"],
)

cube = cube.reduce_dimension(
    dimension="t",
    reducer="first",
)

cube = cube / 10000.0

# NDWI = (GREEN - NIR) / (GREEN + NIR)
ndwi = cube.ndvi(nir="0", red="1")

ndwi_vis = (ndwi + 1) / 2

ndwi_png = ndwi_vis.linear_scale_range(
    input_min=0,
    input_max=1,
    output_min=0,
    output_max=255,
)

result = ndwi_png.save_result(format="PNG")

doc = GISDocument(latitude=40.75, longitude=-73.95, zoom=12)
await doc.ready()
doc.add_openeo_tile_layer(result)
doc

Define a process graph to compute a NDWI, using the Python API of OpenEO and JupyterGIS. It is then lazily evaluated on a per-tile basis while the user pans/zooms on the map.

In addition to defining openEO process graphs from the scripting Python API, JupyterGIS provides an advanced openEO process graph editor, allowing you to:

connect to an openEO tile server
define the graph graphically, with boxes and arrows
load data collections and define processes with a drag-and-drop UI
directly edit the JSON content

Editing an openEO process graph from the JupyterGIS front-end

Another interesting aspect of openEO is that process graphs have a well-defined, declarative JSON representation. Because of this structured format, they are a natural target for LLM-assisted workflows. Users can describe the analysis they want in natural language, have an LLM generate or refine the corresponding process graph (e.g. using jupyterlite-ai), and immediately visualize the result in JupyterGIS. Combined with the lazy, tile-based rendering, this makes it possible to quickly iterate on processing pipelines without waiting for complete datasets to be exported or downloaded.

Lazy visualization of Xarray datasets with jupyter-tiler

JupyterGIS now integrates with the new jupyter-tiler package, making it straightforward to visualize Xarray datasets from Python.

Datasets can come from anywhere: they may already exist in your notebook, or they can be loaded on demand from a STAC catalog using stackstac. Once you have an Xarray object, JupyterGIS can display it in the map without requiring an export to another format.

Rendering happens lazily, generating only the tiles needed for the current view. This makes it possible to explore datasets that are much larger than memory while keeping navigation responsive.

The result is a smoother workflow from data loading, to analysis, to visualization, all within the same notebook.

await doc.add_data_array_layer(
    name="NDSI Layer",
    data_array=ndsi,
    colormap_name="viridis",
    colormap_range=(-1, 1),
)

Visualizing an Xarray dataset in JupyterGIS.

This feature requires the optional dependency jupyter-tiler to be installed.

pip install jupyter-tiler

A more expressive symbology model

Styling geographic data often requires combining multiple visual properties to communicate patterns effectively.

JupyterGIS 0.16 introduces a new symbology model inspired by the Grammar of Graphics. Instead of relying on a fixed set of styling options, visual properties such as color, size, and opacity can be defined in a more flexible and composable way.

This makes it easier to build everything from simple thematic maps to more advanced visualizations while keeping styling definitions consistent and reproducible.

A symbology example: apply a Viridis color map to the circle colors, a linear scale to the radius of circles, and a fixed stroke color.

GeoZarr and GeoPackage support

This release also expands the range of formats that JupyterGIS can open directly.

Support for GeoZarr makes it possible to work with cloud-native multidimensional geospatial datasets, while GeoPackage support improves interoperability with existing GIS software and common data exchange workflows.

New Collaborative Editing Capabilities

JupyterGIS 0.16 also brings collaborative editing to vector layers. When working on a shared JupyterGIS document, multiple users can now edit the same vector data at the same time.

Features can be created, moved, and edited collaboratively, with changes synchronized in real time between users. This makes it possible to work together on tasks such as digitizing features, annotating a map, or refining a dataset without having to exchange files or manually merge changes.

Combined with the collaborative Story Map editor, this makes collaboration a more integral part of JupyterGIS: users can work together on the data itself, and then use the same shared document to explore and communicate their results.

A new R API

JupyterGIS 0.16 also introduces an R client, bringing JupyterGIS to R users through the new r-jupytergis package. The R client provides bindings for interacting with JupyterGIS widgets from an R notebook, using the same JavaScript front-end as the Python client.

The main interface is the GISDocument widget, which can be used to create and manipulate JupyterGIS documents directly from R. This makes it possible to build geospatial workflows in R while using the same interactive map interface available to Python users.

The R client also uses the same underlying collaborative infrastructure as the Python client, including the Yrs CRDT library. This means that R users can participate in the same collaborative JupyterGIS workflows rather than working in a separate environment.

doc <- GISDocument$new("france_hiking.jGIS")
layer <- doc$add_raster_layer(
    url = "https://mt1.google.com/vt/lyrs=y&x={x}&y={y}&z={z}",
    name = "Google Satellite",
    attribution = "Google",
    opacity = 0.6
)

Bug fixes and performance improvements

As usual, this release also includes many smaller improvements throughout the project.

We’ve fixed a number of bugs, improved performance in several parts of the application, and continued polishing both the user interface and the Python API.

JupyterGIS continues to evolve as a collaborative GIS environment that fits naturally within the Jupyter ecosystem. Whether your workflow starts from a notebook, a STAC catalog, an openEO backend, or a local dataset, the goal remains the same: make it easier to move between analysis, visualization, and communication without switching tools.

Acknowledgements

This work on JupyterGIS by QuantStack was funded by the European Space Agency (ESA) for the Story-maps development, the R API, openEO layers support and the collaborative labelling. Additionally, QuantStack was funded by the French National Centre for Space Studies (CNES) for the lazy visualization of xarray datasets.

Contributors to this release

By order of number of contributions:

Arjun Verma is a Developer at QuantStack. He worked on the server-side geoprocessing infrastructure and on the openEO editor in the JupyterGIS front-end.

Martin Renou is a Technical Director at QuantStack and a maintainer of JupyterGIS. For this release, Martin coordinated and guided much of the development, and worked on the integration of openEO layers.

Gregory Mooney is a Developer at QuantStack and a long-time contributor to JupyterGIS. He led much of the work on the new Story Map editor and its collaborative editing capabilities.

Matthias Meschede is Chief Operating Officer at QuantStack. He introduced the new Grammar of Graphics-inspired symbology model, bringing a more expressive and composable approach to styling geographic data.

Matt Fisher is the Community Manager of GeoJupyter. He contributed to many of the discussions around the release and helped shape several of the design decisions across the project.

Nakul Verma is an open-source contributor to JupyterGIS. He contributed numerous bug fixes and improvements throughout the release, and introduced support for Vega expressions in the new symbology system.

Antoine Prouvost is a Developer at QuantStack. He led the initial work on the R API for JupyterGIS, building its first skeleton and establishing the foundations for the r-jupytergis package.

Sandrine Pataut is a Developer at QuantStack. She worked on bringing many of JupyterGIS’s features to the R API, helping make the new client more complete and useful for R users.

We are grateful to everyone who contributed code, reviews, ideas, discussions, and feedback to this release. JupyterGIS continues to benefit from an increasingly diverse community of contributors, and we look forward to seeing what comes next!

Positron Server available for academic use via JupyterHub

2026-07-29T18:19:00+00:00

Editor’s note: This is a guest blog post from Posit, a Jupyter Foundation member

Academic institutions can now offer Positron directly within their existing JupyterHub environments, giving students access to a modern, full-featured data science IDE without requiring local installation or additional infrastructure. Licensed under the permissive, source-available Elastic License 2.0, Positron as a desktop app is free for everyone to use, build on, and extend across personal, academic, and commercial projects. Through a free educational license, universities and other academic organizations can additionally make Positron Server available to currently enrolled students for coursework, helping create a consistent learning experience across classrooms, labs, and remote environments.

By integrating Positron into JupyterHub, educators can provide students with a powerful development environment alongside the tools they already use. Students simply launch Positron from the JupyterHub interface, just as they would open JupyterLab or a different environment, and can begin working immediately.

Bringing a Modern Data Science IDE to the Classroom

Positron combines the familiarity of notebook-based workflows with the capabilities of a professional integrated development environment (IDE). Once launched through JupyterHub, students have access to the complete Positron experience, including:

Comprehensive support for both Python and R
Access to the OpenVSX extension marketplace
Built-in data viewer and variables explorer
Integrated help pane, debugging tools, and version control
Advanced development features that help students grow their data science skills over time

This approach allows instructors to standardize course environments while reducing the technical barriers often associated with software installation and configuration.

Designed to Work with Existing JupyterHub Deployments

Positron Server is built to integrate directly into existing JupyterHub environments, making adoption straightforward for administrators already managing Jupyter-based infrastructure.

The solution is compatible with:

JupyterHub deployments running JupyterLab 4
Python 3.9 and later environments

Installation is provided through the jupyter-positron-server Python package, which is built on Jupyter Server Proxy. For administrators who have previously configured services within JupyterHub, the setup process will feel familiar.

Rather than functioning as a standalone desktop application, Positron Server extends existing JupyterHub deployments by making the Positron IDE available as another launch option within the environment.

Free Educational Licensing for Teaching

Academic institutions using Positron for instructional purposes are eligible for a free teaching license. Under this license, access can be provided to:

Currently enrolled students
Course participants
Faculty and staff involved in delivering educational programs

This licensing model enables institutions to incorporate Positron into coursework without additional software costs, helping educators provide professional-grade tools to learners.

Getting Started

Institutions interested in offering Positron through JupyterHub can get started in three simple steps:

Review the eligibility requirements outlined in the Positron Education License Rider.
Contact Posit to request a free teaching license.
Follow the jupyter-positron-server installation and configuration documentation to deploy Positron within your JupyterHub environment.

Supporting the Next Generation of Data Scientists

As data science and computational research continue to grow across disciplines, educational institutions are looking for ways to provide students with professional tools that are easy to access and manage. By bringing Positron directly into JupyterHub, universities can deliver a modern, scalable development environment that supports both teaching and learning while minimizing setup complexity.

Whether students are writing Python code, analyzing data in R, or exploring advanced development workflows, Positron Server helps create a seamless experience from the first day of class through more advanced coursework and research projects.

JupyterLite 0.8 is released! 🎉

2026-07-10T05:01:00+00:00

JupyterLite is a Jupyter distribution that runs entirely in the web browser without any server components. Deployment and hosting are easy as JupyterLite sites are just static websites.

The new 0.8 release includes a number of new features, bug fixes, and enhancements. This release also brings significant improvements to the user experience and new customization options for JupyterLite deployments.

When the REPL toolbar is enabled, it now includes a Copy Shareable Link button. Clicking it captures the current state of the REPL, the prompt content, the selected kernel and theme, and any non-default options, into the page URL, and copies the resulting link to the clipboard. A notification confirms the link was copied, making it easy to share a ready-to-run REPL with others.

Refreshed Loading Screen

The loading indicator shown while JupyterLite starts up has been redesigned to match the JupyterLab splash screen to make the transition from the initial loading screen to the fully loaded application feel more seamless.

The loading indicator remains configurable, and can be enabled or disabled for specific applications. See the loading indicator guide for more details.

File System Reliability Improvements

JupyterLite 0.8 includes many fixes to the in-browser file system used to store your notebooks and files. Creating files and directories is now faster and more reliable, saving a file to a directory that does not exist is now rejected with a clear error rather than failing silently, and files are no longer opened twice on startup when using query parameters. These changes make working with files in JupyterLite smoother and more dependable.

JupyterLab 4.6 and Notebook 7.6

JupyterLite 0.8 is built on top of JupyterLab 4.6 and Notebook 7.6, and brings many of the respective improvements and bug fixes. Check out the announcement post to learn more about these new releases.

This JupyterLite release includes 9 new features and enhancements, 11 bug fixes, and 5 documentation improvements. 13 people contributed to this release. Across 85 maintenance tasks and dependency updates, we kept JupyterLite up to date with the latest JupyterLab and Notebook releases.

A Terminal in the Browser

The JupyterLite Terminal adds a fully in-browser command-line terminal to JupyterLite, powered by the cockle shell. Commands run as WebAssembly directly in the browser, with no server involved. Version 1.5 adds compatibility with JupyterLite 0.8, and recent releases include:

A growing set of familiar command-line tools compiled to WebAssembly, including ls, cat, cp, mv, grep, sed, tree, git, and the vim and nano editors.
Tab completion for commands, arguments, and file names, with a confirmation prompt before listing a very large number of matches.
New JupyterLab commands for running shell commands programmatically and capturing their output, without opening a terminal panel.

Running terminal commands in the browser

More Kernels with jupyterlite-xeus

jupyterlite-xeus builds JupyterLite deployments around Xeus-based kernels and lets you pre-install packages from conda-forge and emscripten-forge straight into the browser environment through an environment.yml file. Its recent releases (the 4.5 series and the new 5.0) are compatible with JupyterLite 0.8 and add a number of improvements:

A growing list of supported kernels, including xeus-python, xeus-r, xeus-cpp, xeus-lua, xeus-nelson, xeus-octave, and xeus-javascript.
Installing packages at runtime now feels more natural: you can run pip installor conda installdirectly in a cell, with the leading % or ! now optional.

To learn more about pre-installing packages, mounting files, and the available kernels, see the jupyterlite-xeus documentation.

Python 3.14 with the Pyodide Kernel

The Pyodide kernel has been updated to version 0.8.0. It bundles the latest Pyodide release, which upgrades the in-browser Python interpreter to Python 3.14. Notebooks and consoles running on the Pyodide kernel now use the newest Python version, including recent standard library additions such as the new compression.zstd module.

For deployments that pre-compute the set of packages to ship offline, the kernel’s lock add-on can now build a customized pyodide-lock.json from your own requirements — including reading dependencies from a requirements.txt file or a pyproject.toml dependency group — giving site authors finer control over which packages are available without a network connection.

See the pyodide-kernel 0.8.0 release notes for the full list of changes.

Pyodide 314 in JupyterLite

JavaScript Kernel Improvements

The in-browser JavaScript kernel has gained several improvements in its 0.4 development line:

A new iframe-based execution mode with better support for libraries that need direct access to the DOM, such as p5.js.
Initial support for Jupyter Widgets, through Comm channels and a set of base widgets.
Clearer error messages and tracebacks, including a fix for errors that previously rendered as blank in Firefox.

Jupyter Widgets and dynamic imports with the JavaScript kernel

Try it in your browser

If you would like to try the new release in your browser, click on the following link:

Acknowledgments

Thanks to Bloomberg for funding the work on JupyterLite at QuantStack, and for their ongoing support for JupyterLite in general.

Many thanks to all the contributors to JupyterLite. The list below is based on GitHub usernames for the 0.8 release across the different projects:

New contributors: @Darshan808, @MMesch, @MUFFANUJ, @wata727
Returning contributors: @DerThorsten, @agriyakhetarpal, @bollwyvl, @ianthomas23, @jasongrout, @jtpio, @martinRenou, @trungleduc

Thank you to the extended group of contributors in Jupyter Frontends and related project in the Jupyter ecosystem 💛

Navigating the Post-Workshop Fog: a Path to Myst

2026-07-09T15:15:00+00:00

by Chiara Marmo and Serena Bonaretti

From June 15th to 17th 2026 a Jupyter Workshop took place at Paris-Saclay University : “Demystifying MyST Markdown in education”. The workshop combined presentations in the mornings with collaborative sprints during the afternoons. It has been funded by the Jupyter Foundation and SaclAI-School.

Milestones

Improving documentation and tools for easier deployment even for non-specialists.

Freek Pols from Delft University and Brigitta Sipočz form CalTech presented some examples and challenges in publishing courses and documentation at large scales. Angus Hollands, MyST maintainer, made an in depth presentation of Myst and JupyterBook2. Guided tutorials introduced participants to complete a Jupyter Book workflow. The participants learned how to create their first Jupyter Book, and how to publish it.

Text notebooks as first citizens.

Marc Wouts and Yahya Heni discussed the path from jupytext to jupyter-plainb to open and execute plain markdown text notebooks directly in Jupyter Lab. Two Jupyter Enhancement Proposals (JEP) has been discussed together with Jupyter Lab and MyST maintainers:

One step at a time

Over 30 issues and pull requests have been opened in the whole Jupyter ecosystem:

documentation items: for example, about text notebooks in jupyterlite or publishing on different hosting solutions;
feature requests: for example, single document feature in JupyterBook2, non-default application to open files in Jupyter Lab;
adopt JupyterBook2 for software documentation: for instance itables and travo.

Sidewalks

The workshop provided the opportunity to continue previous discussions about AI in education: some participants attended the workshop “AI in Jupyter” and were able to pick up the conversation from there.

Relationships between Academia and Open Source Software communities were also topic of conversation: about Open Source Program Offices (OSPOs) and how their action can be connected to education strategies.

Wandering

Collaboration is a matter of trust. That’s why it is still important for people to meet in person and to know each other. It is about exchanging details, like keys to decrypt characters and aspirations. One might discover a shared passion for shoes. Another may finally enjoy long French-style lunch breaks.

When the time comes to resume the path, important steps have already been taken in the right direction.

2026 Jupyter Community Call For Funding Proposals

2026-07-06T19:32:00+00:00

The Jupyter Executive Council and Jupyter Foundation are pleased to announce a new Call for Proposals (CFP) for funding the Jupyter community to improve Jupyter. Visit the Jupyter Foundation Community Proposals webpage to learn more about the process and how to submit proposals. Submit a proposal by Wednesday, September 9, 2026.

The Jupyter Foundation began its operations in early 2025 with a mission to use its resources to support the Jupyter community. As part of this mission, we funded a round of community proposals in 2025. This funded work continues to bring many benefits to the Jupyter ecosystem (see the progress reports here). In this next call for proposals, we are iterating on this success.

Visit the Community Proposals webpage to learn more about past funded proposals and the Jupyter Foundation team compass for more detailed background about this funding call. In this second round, our goal is to continue learning how to best manage a community funding program. Based on feedback, we are updating the proposal process in several ways, including:

A new section of the proposal template has been added for Jupyter council or committee endorsements. We strongly encourage authors to seek and include endorsements from Jupyter councils or committees affected by the proposal. Each endorsement should be a brief paragraph about the impact of the proposed work from the council or committee’s perspective, and express support for the work and a willingness to receive it. We encourage authors to communicate early with relevant Jupyter councils and committees to make this endorsement process easier.
The de-risk section of the proposal is now optional for smaller funding requests.
The CFP is open for several weeks longer than the previous round. We do not anticipate extending the CFP deadline this time.

Submit a proposal by Wednesday, September 9, 2026.

As with the previous round, to help inspire proposals we are particularly excited to fund, we’ve defined funding priorities for the Jupyter Foundation. These are key outcomes that we must improve in order to grow the overall health and impact of the ecosystem. Briefly summarizing, these priorities are:

Grow the contributor capacity of Jupyter. We would like to grow the number of contributors, improve the efficiency of existing contributors, and facilitate learning across Jupyter subprojects. We’d love to see proposals that help us mobilize and support the total pool of energy available to contribute to Jupyter. Examples of recent activities in this area include hiring a community manager and hosting community workshops.
Improve the reliability, security, and consistency of Jupyter’s software and team practices. We believe that our technology will be more impactful and easier to contribute to and deploy if we improve our development infrastructure and team practices in ways that contribute to reliability, security, and consistency. Examples of recent activities in this area include investing in better testing infrastructure and linting rules, refactoring build systems, improving accessibility, funding security issue triage, and hosting a subproject roadmap alignment workshop.

While we’re particularly excited about these two outcomes and aim to focus funding on proposals that clearly feed into one or both of these priorities, we also encourage people to get creative and submit proposals for outcomes that have high impact and strategic value for the Jupyter community. We’re excited to see what others come up with, and are eager to work with you in unlocking critical funding in support of Jupyter’s community.

JupyterLab 4.6 and Notebook 7.6 are out!

2026-07-02T16:13:00+00:00

JupyterLab 4.6 features new interface customization options, improved file browser and debugger, an easy way to jump between recently edited cells, and numerous other notebook experience improvements. Keyboard shortcuts, navigation and accessibility is another focus area in this release. Jupyter Notebook 7.6 has also been released, including the fixes and enhancements of JupyterLab along with a new Scratchpad console and other Notebook-specific improvements. This article highlights notable changes in both applications.

You can try out the changes in your browser: JupyterLab 4.6, Notebook 7.6
At the time of publication, the preview runs on JupyterLite 0.8.

Overview of some user interface enhancements visible in JupyterLab UI

Enhancements shared by JupyterLab and Notebook

Notebook improvements

Two new navigation commands, “Select previous last modified cell” and “Select next last modified cell”, allow jumping back and forward through recently edited cells. The commands are accessible from the Command Palette and as buttons in the Table Of Contents toolbar when a notebook is active.

Clicking the highlighted button will jump to a previously edited cell

Copy, cut, and paste text commands have been added to the notebook context menu. This feature requires permission to access clipboard to work reliably and may not work in Firefox depending on version and additional restrictions.

Copy/Cut/Paste Selected cells expose clipboard actions on cell source

The cell toolbar delete button now shows a confirmation dialog to prevent accidental deletion. The “Do not ask me again” checkbox is available and the preference is persisted in Cell Toolbar settings. The standard keyboard shortcut (D, D) is unaffected.

Dialog shown when deleting a cell from cell tollbar

Pressing Ctrl + B (Cmd + B on macOS) in a markdown cell wraps the selected text in bold formatting.

When exporting a notebook as HTML via File → Save and Export Notebook As → HTML, a dialog now asks whether to sanitize the HTML output before download.

File browser: new column, editable breadcrumbs, open in terminal

A new “Date Created” column has been added to the file browser, showing when files were created. The column can be toggled via Settings → File Browser → “Show date created column” or by right-clicking the column header. The latest jupyter-server (v2.18+) is required for accurate values across operating systems.

New date created column in file browser

The breadcrumb bar now supports direct path editing with tab-completion. Clicking the area behind breadcrumbs (highlighted on hover), or using the Command Palette, opens an editable text field where pressing Tab completes the longest common prefix of matching subdirectories.

Editable breadcrumbs

A new “Open in Terminal” option in the file browser context menu opens a terminal navigated to the selected directory. When multiple directories are selected, one terminal is opened per directory.

Opening terminal for a specific directory is now easier.

Additional file browser improvements include: a configurable file name sort order, persistence of the sort state across sessions, automatic clearing of the file filter when changing directories, and a loading animation during file browser refresh.

Debugger: kernel sources filter, floating overlay

The debugger Sources panel has been moved out of the debugger sidebar; the Sources now open as read-only editors in the main area, keeping the sidebar uncluttered while you explore the code state. The previous behavior can be restored by disabling the “Show Sources in Main Area” setting in the Debugger settings.

An overlay with continue/step in/stop buttons has been added easing the control of the debugger steps:

The Kernel Sources filter bar has been moved to the toolbar and now supports live filtering, making it easier to search through kernel source files while debugging.

The refresh button for sources list was removed — the sources will now update automatically after each code execution.

Keyboard navigation has been improved across several components:

The terminal no longer traps keyboard focus, allowing users to move focus away with the keyboard.
The console and file browser breadcrumbs both received keyboard navigation fixes.
Focus is now correctly restored after closing the command palette, and input elements in dialogs opened from the command palette receive focus immediately.
The find-and-replace button focus in the document search box has been corrected.

Screen reader behavior has been improved in the launcher and notebook. Toolbar buttons now correctly reflect their pressed state via the aria-pressed attribute.

The Keyboard Shortcuts settings panel has been updated to improve accessibility, including better keyboard interaction and screen reader announcements within the shortcuts editor dialog.

Focus indicators have been improved across the interface, including the status bar and other interactive components.

Keyboard shortcuts

Shortcuts can now be added from the UI shortcut editor for any command (previously this required writing JSON in Advanced Settings Editor).

“Find and Replace” has been added to the Edit menu with the keyboard shortcut Ctrl + H (Cmd + H on macOS).

Ctrl + Y has been added as a redo shortcut on Windows and Linux.

Pressing 1, 2, 3, 4, 5 and 6 will no longer convert a focused code or raw cell to Markdown to avoid accidental conversions. These shortcuts continue working on markdown cells, switching the heading level, as they did before.

Internationalization

Language packs can now be installed directly from within JupyterLab by selecting “Install more languages…” at the bottom of the Settings → Language menu. This opens the Extension Manager pre-filled with a search for available language pack extensions.

Terminal enhancements

Pressing Shift+Enter in the terminal now inserts a newline without executing the current line. This matches the behavior expected by certain terminal applications.

Inline completion enhancements

Inline completion suggestions can now be rendered with syntax highlighting that matches the active editor language. This can be enabled in Settings → Inline Completer → “Ghost text syntax highlighting”.

Ghost text is now also shown for all active cursors in a multi-cursor editing session.

JupyterLab-specific enhancements

Layout and interface customization

The activity bar can now be positioned at the top or bottom of the interface, in addition to the default left and right placement. The setting is available under Settings → Interface → Activity Bar Position.

Sections of accordion sidebars can now be moved between panels via a context menu. Right-clicking a section header shows a “Move To” menu. The placement and collapsed state of moved sections are persisted across sessions.

The sidebar panels themselves can be moved between areas. Right-clicking a sidebar shows submenu with options to move it to the main area, a different sidebar, or the down area.

Tabs can now be split in four directions using the “Split Tab” context menu item (or the command palette), which adds split left, right, up, and down options.

Individual panels can be zoomed in or out using Ctrl + mouse wheel (when “Enable Ctrl+ Scroll Zoom” is turned on in Settings → Interface) or via the command palette, without affecting other panels.

Performance

Panel resizing is now more responsive; the width of individual widgets inside resized panels is frozen during the drag. This behaviour can be disabled by toggling “Optimize panel resize” in Settings → Application Shell.

Notebook-specific enhancements

Scratchpad console

A scratchpad console can now be opened next to a notebook, sharing the same kernel. This makes it easy to run quick experiments or inspect variables without modifying the notebook itself.

The scratchpad console can be opened from the File -> New -> Scratchpad console menu, from the command palette, or with the Ctrl + B (or Cmd + B on macOS) keyboard shortcut, which toggles the console panel.

Confirmation dialog when closing and shutting down a notebook

The “Close and Shut Down Notebook” command now asks for confirmation before closing the browser tab and shutting down the kernel. The confirmation prompt can be disabled in the Settings Editor with the “Prompt for confirmation before closing and shutting down” setting.

Miscellaneous

Tab widths in JupyterLab are kept frozen while the mouse pointer hovers over them, making it easier to close multiple tabs with the mouse
Autocompletion heuristics were improved; the autocompletion (which remains opt-in) should no longer trigger in unexpected scenarios
The output scroll overlay collapse icon is now visible regardless of the output size and scroll state
The fonts used across components were standardized and fonts specified by themes or overrides are respected in every component of the application

For extension authors

Building extensions (and JupyterLab/Notebook themselves) is now ~5 times faster thanks to migration from webpack to Rspack. Building extensions no longer requires a full JupyterLab installation as the relevant machinery was extracted to jupyter-builder (see this blog post for more details). This (among others) enables faster build environment setup on CI. Future improvements to the build system can now be released independently of the JupyterLab release cadence.

Please refer to the Extension Migration Guide for more details on API changes and up-to-date advice.

As large as minor releases go

This JupyterLab release includes 68 new features and enhancements, 97 bug fixes, and 38 documentation improvements. 95 people contributed to this release. Across record-breaking 171 maintenance tasks we kept the dependencies up-to-date, improved quality of code and reduced the time to PRs getting merged by improving the CI performance and robustness. These efforts were in part funded by Jupyter Foundation Community Proposals.

While the size of minor releases fluctuated across years, this one is on the higher side, with only v3.1 featuring slightly more merged PRs. The reviewers worked hard to ensure no regressions are introduced, but if any slipped through, please open an issue in respective repository (JupyterLab or Notebook).

Acknowledgements

Thank you to all the new contributors, we hope to see you back!

JupyterLab (39): @aarondr77, @Akshitguptaa, @altis0725, @amanparganiha, @anafontan, @autodots-AHassan, @aviu16, @bittoby, @boskodev790, @chenjiahan, @cursoragent, @dhgoal, @DTiming24, @github29tani, @GlassOfWhiskey, @harshaagrawal20, @hroncok, @jayaprajapatii, @JaYRaNa213, @jianyexi, @ktaletsk, @lin9long, @mfisher87, @MMesch, @moktamd, @nightcityblade, @nthiery, @raffaelemancuso, @RamiNoodle733, @reteps, @rodrigosf672, @Siddhazntx, @statxc, @TheChyeahhh, @tsharma-dev, @tubaman, @u-wlkjyy, @Yahiewi, @ZhYGuoL
Notebook (9): @bodhisilberling, @Darshan808, @goelakash, @joaovml, @KH-Coder865, @Mirochill, @xlumzee, @yangsong97, @Yann-P

And thank you to returning contributors for their continued work!

JupyterLab (56): @aaron-seq, @afshin, @agriyakhetarpal, @AliMahmoudDev, @andrii-i, @apoorvdarshan, @arjxn-py, @arun-357, @bollwyvl, @brichet, @Carreau, @ceasermikes002, @cmarmo, @CrafterKolyan, @Darshan808, @davidbrochart, @DeborahOlaboye, @doshi-kevin, @erkin98, @fcollonval, @filipeoliveira05, @flaviomartins, @fleming79, @FoSuCloud, @frenzymadness, @HaudinFlorence, @i-aki-y, @ianhi, @ianthomas23, @IsabelParedes, @itsmejay80, @itsmevichu, @JamesWrigley, @jasongrout, @JasonWeill, @jimangel, @jtpio, @krassowski, @Krish-876, @linlol, @martinRenou, @Meriem-BenIsmail, @MUFFANUJ, @peytondmurray, @prajyot-porje, @pranshugupta01, @RRosio, @schmidi314, @soniya-malviy, @superlevure, @SylvainCorlay, @tmetzl, @utsav-develops, @xc2, @Yann-P, @Zsailer
Notebook (9): @andrii-i, @brichet, @Carreau, @jtpio, @krassowski, @martinRenou, @minrk, @RamiNoodle733, @takluyver

Thank you to all the people who tested and provided feedback for the pre-releases! Lastly, thank you to the weekly triage group for triaging JupyterLab and Notebook issues: @RRosio, @krassowski, @andrii-i, @rodrigosf672, @ktaletsk among others who attend.

Congratulations, Distinguished Contributors!

2026-06-24T15:08:00+00:00

We are proud to announce the recipients of the Jupyter Distinguished Contributor (JDC) award for the 2025 cohort of contributors.

Project Jupyter Distinguished Contributors are recognized for their substantial contributions to Jupyter itself in both quality and quantity over at least two years. Contributions may include code, code review, infrastructure work, mailing list and chat participation, community help/building, education and outreach, fundraising, branding, marketing, inclusion and diversity, UX design and research, etc.

Please congratulate the winners of the 2025 cohort of Jupyter Distinguished Contributors!

James Colliander

Florence Haudin

Greg Mooney

Kirstie Whitaker

Congratulations, Distinguished Contributors!

2026-06-24T15:08:00+00:00

We are proud to announce the recipients of the Jupyter Distinguished Contributor (JDC) award for the 2025 cohort of contributors.

Please congratulate the winners of the 2025 cohort of Jupyter Distinguished Contributors!

James Colliander

Florence Haudin

Greg Mooney

Kirstie Whitaker

Congratulations, Distinguished Contributors!

2026-06-24T15:08:00+00:00

We are proud to announce the recipients of the Jupyter Distinguished Contributor (JDC) award for the 2025 cohort of contributors.

Please congratulate the winners of the 2025 cohort of Jupyter Distinguished Contributors!

James Colliander

Florence Haudin

Greg Mooney

Kirstie Whitaker

Congratulations, Distinguished Contributors!

2026-06-24T15:08:00+00:00

We are proud to announce the recipients of the Jupyter Distinguished Contributor (JDC) award for the 2025 cohort of contributors.

Please congratulate the winners of the 2025 cohort of Jupyter Distinguished Contributors!

James Colliander

Florence Haudin

Greg Mooney

Kirstie Whitaker

Congratulations, Distinguished Contributors!

2026-06-24T15:08:00+00:00

We are proud to announce the recipients of the Jupyter Distinguished Contributor (JDC) award for the 2025 cohort of contributors.

Please congratulate the winners of the 2025 cohort of Jupyter Distinguished Contributors!

James Colliander

Florence Haudin

Greg Mooney

Kirstie Whitaker

Congratulations, Distinguished Contributors!

2026-06-24T15:08:00+00:00

We are proud to announce the recipients of the Jupyter Distinguished Contributor (JDC) award for the 2025 cohort of contributors.

Please congratulate the winners of the 2025 cohort of Jupyter Distinguished Contributors!

James Colliander

Florence Haudin

Greg Mooney

Kirstie Whitaker

Announcing jupyter-builder: A Standalone Build System for JupyterLab Extensions

2026-06-19T13:11:00+00:00

We’re excited to announce the first stable release of jupyter-builder on PyPI and @jupyter/builder on npm. A standalone, configurable build system for JupyterLab and its extensions.

If you build or maintain a JupyterLab extension, this release is for you.

Motivation

For a long time, building a JupyterLab extension has meant installing all of JupyterLab. Take a look at any extension’s build dependencies and you’ll see jupyterlab listed there, not because the extension needs JupyterLab at runtime to be built, but because the build tooling lives inside the JupyterLab repository. The builder/ folder, the jlpm command, the helper scripts, they’re all coupled to the JupyterLab core.

This setup has caused real friction over the years:

Linux packagers have repeatedly raised concerns about the circular dependency where extensions like jupyterlab_pygments need jupyterlab to build, but jupyterlab ships with those extensions. It’s a chicken-and-egg problem that makes packaging painful.
Extension authors have to update their build system every time they update to a new JupyterLab version, which sometimes introduces breakages that have nothing to do with their extension’s actual code.
Users still occasionally run into installation issues that trace back to the incomplete migration from “source” extensions to prebuilt ones.

The need to separate the build system was identified back in jupyterlab#13456, and initial work began during GSoC 2024. With the support of the Jupyter Foundation’s first community-funded proposal, we’ve now brought that work to a stable release.

What `jupyter-builder` does

jupyter-builder extracts all the Node.js-based build tooling out of JupyterLab into a dedicated package. You install it on its own, and it builds your extension, no full JupyterLab installation required.

It ships in two parts:

jupyter-builder (PyPI) — the Python package that provides the jupyter-builder CLI.
@jupyter/builder (npm) — the underlying JavaScript package containing the build scripts. The Python CLI invokes build-labextension.js from this package, which then runs the rspack compiler with all the configuration needed to produce a JupyterLab extension.

Instead of jupyter labextension build ., you now run:

jupyter-builder build .

Build compatibility without JupyterLab installed

One interesting problem we had to solve: if JupyterLab isn’t installed, how does the builder verify that an extension is compatible with a given JupyterLab version?

The answer is @jupyterlab/core-meta, a small npm package that publishes JupyterLab’s core metadata on its own. @jupyter/builder declares a dependency on a specific @jupyterlab/core-meta version, so by default your extension is checked for compatibility against whatever JupyterLab version that pin corresponds to. In general, the latest @jupyter/builder will track the latest JupyterLab.

If you want to build against a different JupyterLab version, pass --core-version:

jupyter-builder build . --core-version 4.4.x

We’ll download that version’s metadata from @jupyterlab/core-meta on npm and check compatibility against it.

Migrating an existing extension

If you’re starting a new extension with the extension template, you’ll get all of this set up automatically. For existing extensions, there are two changes to make.

1. Update the Python build dependencies

In your pyproject.toml, swap jupyterlab for jupyter-builder:

# Before
requires = ["hatchling>=1.5.0", "jupyterlab>=4.0.0,<5", "hatch-nodejs-version>=0.3.2"]

# After
requires = ["hatchling>=1.5.0", "jupyter-builder>=1.0.0", "hatch-nodejs-version>=0.3.2"]

Then update the scripts section of your package.json to use the new CLI:

"build:labextension": "jupyter-builder build .",
"build:labextension:dev": "jupyter-builder build --development True .",
"watch:labextension": "jupyter-builder watch ."

Your build no longer pulls in all of JupyterLab.

2. Update the npm builder dependency

Replace @jupyterlab/builder with @jupyter/builder in your package.json:

"@jupyter/builder": "^1.0.0"

jupyter-builder is backwards-compatible with @jupyterlab/builder, so things will keep working if you don’t migrate immediately. That said, we strongly recommend switching: @jupyterlab/builder is no longer being actively developed, and all new work is happening in @jupyter/builder.

Note that as part of this transition JupyterLab has also moved from Webpack to Rspack. Most extensions won’t need any changes, but if yours uses a custom webpackConfig see the Rspack migration notes.

What’s next

This release is the first stable foundation. We’re continuing to:

Migrate more packages across the Jupyter organization to use jupyter-builder.
Make the builder more configurable, so it can eventually be used for projects beyond JupyterLab.

If you maintain an extension, please try the migration and let us know how it goes. Feedback from real extensions is the best way to make sure the migration path stays smooth.

Acknowledgements

This work was funded under the first round of Jupyter Community Funded Proposals. We want to thank the Jupyter Foundation and everyone involved in setting up this funding mechanism.

A huge thank you to Nicholas Bollweg for many thoughtful discussions on the design and packaging of jupyter-builder, and to Jeremy Tuloup for helping us resolve issues and for guiding the adoption of jupyter-builder in Jupyter Notebook.

This package was initially created during GSoC 2024 by Ronan Coutinho, mentored by Frédéric Collonval. Their work laid the foundation that made this release possible.

About the developers

Darshan Paudyal is an intern at OpenTeams and a member of the Jupyter Frontend Council. Darshan led the work to bring jupyter-builder to a stable release, completing the separation from JupyterLab core and shepherding the package through to its first published version.

Michał Krassowski is a Senior Software Engineer at OpenTeams. Mike provided guidance and technical direction throughout the development of jupyter-builder, helping shape its architecture and roadmap.

Useful links

📦 PyPI: jupyter-builder
📦 npm: @jupyter/builder
💻 Source: github.com/jupyterlab/jupyter-builder
📖 Migration guide: jupyter-builder migration section
💬 Issues & feedback: GitHub issues

Jupyter User Survey

2026-06-18T15:04:00+00:00

The Jupyter Foundation is excited to gather your feedback on the Jupyter user experience through a brief survey. If you had a magic wand, what would you change or add to Jupyter? Your insights are incredibly important as we continue to invest in making Jupyter better for everyone.

The survey takes only about 3 minutes to complete, and we highly encourage you to participate. The survey will close on Sunday, June 28th.

TAKE THE SURVEY

Thank you for your time, your input, and your continued support of the Jupyter ecosystem!

Becoming the new JupyterHub and Jupyter Book community manager

2026-06-15T07:01:00+00:00

There are moments in life when things, simply, converge. You work and study, study and work, and then, simply, it happens. It starts one day when somebody tells you “there is this new thing called Jupyter Notebook, you should give it a try!”. So you install it, play around with it. It works like a charm. It’s easy, fast, nearly playful. It’s beautiful–and if you grow up in Italy, beauty always matters. Then, you have the urge to tell others about it. You organize a workshop at a conference in musculoskeletal image analysis and introduce marvelous novel tools for computational research: “You know? Nowadays we can do open science easily because somebody has created Jupyter Notebook, Binder, new Python libraries!” And then, together with some friends, you write a proposal for a Jupyter Community Workshop, and–unbelievable!–you get it. Initially, you think you are just organizing a workshop. But somehow, the number of people interested becomes larger and larger, and you find yourself co-founding and coordinating what is now the Open and Reproducible Musculoskeletal Imaging Research (ORMIR) Community. In ORMIR’s Python packages, the examples are in Jupyter Notebook, the documentation is in Jupyter Book. Sooner or later, we will have our JupyterHubs too; it’s just a matter of time. In parallel, life gives you some professional challenges. So you start teaching Python online, one-to-one. You look for material that fits your style, but you cannot find any. So you start teaching it your way, using Jupyter Notebook in JupyterLab and it works. Students find it easy, independent of their background. The teaching material seems to work, so you transcribe it into a book entitled Learn Python with Jupyter, and you make it open. At the same time, you are obsessed with keeping up to date. You go to JupyterCon, meet the people, watch their YouTube videos, participate in online meetings. And then, there is a job posting for a community manager. And you are like: “Nah, they will never hire me”, so you set it aside. But then somebody out of the blue tells you to apply because “100% of lottery winners played!”. So you give it a chance, and here I am: my name is Serena Bonaretti and I am the new JupyterHub and Jupyter Book community manager!

In this new role, I am very much looking forward to working with the JupyterHub and Jupyter Book communities! I will collaborate with maintainers to understand and document projects’ priorities and define the best processes to achieve their vision. I will support contributors in finding their way into the projects and make the real-world impact that they hope to achieve. I will dialogue with users to make sure that the tools we create are useful for their work. And I will share our activities monthly and what we learn with anybody interested, so that we can all benefit from this journey!

And you? How did you start using the tools of the Jupyter ecosystem? Do you work in JupyterHub? Have you ever written a Jupyter Book? Would you like to be a contributor? Are you an enthusiastic user? Write me on Discord (Jupyter Book/MyST) or Zulip (JupyterHub). The JupyterHub and Jupyter Book communities and I are looking forward to getting to know you!

Catching Jupyter-specific bugs before CI does: announcing jupyter eslint plugin

2026-06-11T15:13:00+00:00

We’re excited to announce the release of the first version of the Jupyter ESLint plugin @jupyter/eslint-plugin, now available on npm. It’s a custom ESLint plugin designed specifically for the official Jupyter frontends (JupyterLab, Notebook, JupyterLite) and TypeScript extensions built around them.

Motivation

If you’ve ever written a JupyterLab extension, you’ve probably hit something like this:

You wire up a new plugin, push a PR, walk away to make coffee, and 30 minutes later CI fails on a test you didn’t expect to be related. You scroll through logs, eventually trace it back, and realize the problem was a single misaligned argument in your activate function. TypeScript was happy. The editor showed no red squiggles. Nothing in your local toolchain said a word.

And the slow CI feedback loop is only half the story. Some of these mistakes don’t fail CI at all, a hardcoded English label, an enum in a settings schema, a malformed token id. They pass tests, ship to users, and only surface at runtime. They’re the kind of bugs you hear about from users months later, if at all.

JupyterLab, Jupyter Notebook, and the wider extension ecosystem follow a lot of project-specific patterns around plugins, commands, tokens, settings schemas, translations, and visual tests. These patterns aren’t enforced by TypeScript, because they live one level above the type system. They’re contracts about how the framework expects code to be written, not about whether the code type-checks.

A few examples of what generic linters and TypeScript can’t catch:

A JupyterFrontEndPlugin that requires [TokenA, TokenB] but whose activate function takes those arguments in the wrong order. Both are tokens, both type-check but the plugin fails at activation.
A command added with commands.addCommand(...) whose label is a hardcoded English string. The extension ships, gets translated by the community, and that one button silently stays in English.

These are real, recurring issues. They cost contributor time, they frustrate first-time contributors, and they pile onto reviewer load. They’re exactly the kind of knowledge that lives in the heads of long-time maintainers and exactly the kind of knowledge that a linter is great at encoding. So we built one.

What v1 catches

The plugin currently ships eight rules, grouped by what they protect:

Plugin structure

plugin-activation-args — Keeps activate function arguments aligned with requires and optional tokens.
plugin-description — Requires a non-empty description on every JupyterFrontEndPlugin.
token-format — Enforces the <package>:<TokenSymbol> convention for new Token(...) ids.

Commands and settings

command-described-by — Requires a describedBy schema on commands that accept args.
no-schema-enum — Disallows enum in settings JSON schemas in favor of translatable oneOf with const and title.

Internationalization

no-untranslated-string — Flags hardcoded user-facing strings in command labels, dialogs, accessibility attributes, JSX, and more.
no-translation-concatenation — Forbids dynamic concatenation inside trans.__() calls that translation extractors can’t pick up.

Testing

require-soft-assertions-before-snapshots — Requires expect.soft(...) for all but the last snapshot in a Playwright test, so a single failure doesn’t block the rest from updating.

Each rule has incorrect/correct examples, options, and rationale in the rules reference.

Getting started in 60 seconds

Install the plugin:

npm install --save-dev @jupyter/eslint-plugin

Add it to your ESLint fconfig and turn on the recommended ruleset:

javascript

import jupyterPlugin from '@jupyter/eslint-plugin';

export default [
  {
    plugins: {
      jupyter: jupyterPlugin
    }
  },
  jupyterPlugin.configs.recommended
];

That’s it. Run jlpm eslint and you’ll start seeing Jupyter-specific issues alongside your existing lint output. If you’re still on legacy .eslintrc configs, there’s a recommended-legacy config too. However, we strongly recommend upgrading to ESLint v9 and using the new flat config format.

Full setup details, including type-aware configuration for plugin-activation-args and the JSON parser setup for no-schema-enum, are in the user guide.

If you maintain an extension, the most useful thing you can do today is install it and run it once on your codebase. Even if you don’t adopt it permanently, the first run is often informative most extensions surface a handful of issues they didn’t know they had.

Help us encode more knowledge

Eight rules is a starting point. The plugin is most valuable when it captures the recurring mistakes that maintainers across the ecosystem keep running into and a lot of that knowledge isn’t written down anywhere.

If you’ve ever been bitten by a Jupyter-specific issue that could have been a lint rule, something where you found yourself thinking “I wish my editor had warned me about this” please open an issue on the repository. Even a short description of the bug and a minimal example helps. We’d much rather encode that knowledge into an automated check once than have every new contributor learn it the hard way.

Acknowledgement

This work was funded under the first round of Jupyter Community Funded Proposals. We want to thank the Jupyter Foundation and everyone involved in setting up this funding mechanism.

We’re also grateful to Jeremy Tuloup and Nicolas Brichet for their help in adopting the plugin.

About the developers

Darshan Paudyal is an intern at OpenTeams and a member of the Jupyter Frontend Council. Darshan led the development of v1 of @jupyter/eslint-plugin, designing and implementing the rule set, the documentation, and the release.

Michał Krassowski is a Senior Software Engineer at OpenTeams. Mike provided guidance and direction for the development of the plugin.

Jupyter Blog

JupyterHub 6.0

Thank you to our contributors

Mark Your Calendars: Jupyter Day 2026 is Coming to San Jose!

What We Are Covering

Call for Proposals is Open!

Sponsor Jupyter Day 2026

A Robotics Workbench for JupyterCAD

The Problem: The Fragmented Robotics Pipeline

The Solution: A Unified Browser Workflow

1. JupyterCAD: The Design Hub

2. JupyterCAD-URDF: The URDF Workbench for JupyterCAD

3. JupyterLab-URDF: Interactive Kinematics

Walkthrough: Zero-to-Robot Workflow

Repos

Acknowledgements

About the Author

What you told us: results from the 2026 Jupyter User Experience and Product Enhancement Survey

Who answered

Common themes that people raised

Environment and dependency management

Version control and collaboration

The interface, and parity with editors

Artificial Intelligence

Other themes

Submit a proposal

Thank you

Appendix

The data, and how to read it

Product-use numbers

Usage patterns

JupyterGIS 0.16: New visualization capabilities, collaborative Story Maps, and more

Story Maps are getting a new look!

Story Maps have received a significant update in this release.

A better Story Maps editing experience

OpenEO layers

Lazy visualization of Xarray datasets with jupyter-tiler

A more expressive symbology model

GeoZarr and GeoPackage support

New Collaborative Editing Capabilities

A new R API

Bug fixes and performance improvements

Acknowledgements

Contributors to this release

Positron Server available for academic use via JupyterHub

Bringing a Modern Data Science IDE to the Classroom

Designed to Work with Existing JupyterHub Deployments

Free Educational Licensing for Teaching

Getting Started

Supporting the Next Generation of Data Scientists

JupyterLite 0.8 is released! 🎉

Sharing a REPL

Refreshed Loading Screen

File System Reliability Improvements

JupyterLab 4.6 and Notebook 7.6

A Terminal in the Browser

More Kernels with jupyterlite-xeus

Python 3.14 with the Pyodide Kernel

JavaScript Kernel Improvements

Try it in your browser

Acknowledgments

Navigating the Post-Workshop Fog: a Path to Myst

Milestones

One step at a time

Sidewalks

Wandering

2026 Jupyter Community Call For Funding Proposals

JupyterLab 4.6 and Notebook 7.6 are out!

Enhancements shared by JupyterLab and Notebook

Notebook improvements

File browser: new column, editable breadcrumbs, open in terminal

Debugger: kernel sources filter, floating overlay

Keyboard navigation and accessibility

Keyboard shortcuts

Internationalization

Terminal enhancements

Inline completion enhancements

JupyterLab-specific enhancements

Layout and interface customization

Performance

What `jupyter-builder` does