Zasper is built from the ground up for massive concurrency: a minimal memory footprint, exceptional speed, and thousands of connections at once.
It speaks Jupyter's wire protocol, so it runs the notebooks you already have.
Both servers were run against the same workload, 10 requests per second per kernel on an Apple M4, from 2 concurrent kernels up to 100. Zasper uses less of both at every load, and the RAM gap grows with concurrency, from about 4× at 2 kernels to 38× at 100. At 64 kernels Jupyter Server begins losing kernel connections, and by 100 it has lost all of them, while Zasper answers every request at both loads.
CPU is averaged across each run; RAM is the highest figure observed. The figures above round the widest gaps: 4.5× less CPU at 4 kernels and 38× less RAM at 100. At 2 kernels the difference is about 3× for CPU and 4× for RAM. The CPU gap does not grow with load, while the RAM gap does. The crosses are measured the same way as the lines, as replies received against requests sent, which is flat at five replies per request until a server stops answering. Jupyter's 14% CPU at 100 kernels is 14% while returning nothing. Every point is recomputed from the raw runs in zasper-benchmark, where the harness and the methodology are public.
Zasper reads and writes .ipynb directly,
so a notebook moves between Zasper and JupyterLab without being converted. Your files
stay where they are (no import step, no workspace to create), and the same kernels run
them, registered once.
The whole of it, including what each output type needs, is on Notebook Support.
Zasper reached the front page of Hacker News the week it was released, and has been written up and presented since.
“Zasper: A Modern and Efficient Alternative to JupyterLab, Built in Go”, and a hundred comments arguing about notebooks, which is how you know people read it.
Read the thread“Zasper started out as a front-end interface to JupyterLab like many others, but ended up as a ground up implementation of the Jupyter project.”
Read the articleAn early write-up of the first release on Techzine's DevOps desk: what a Go implementation of the wire protocol is, and why its footprint is smaller.
Read the articleEvery screen below is from a running session.
Claude Code, Gemini CLI, Codex or any agent that speaks ACP, in a panel next to the notebook it is working on. It reads, edits and runs your cells through Zasper's own tools, and every file a turn changed is listed under it, to review in a diff and undo a block, a cell or the whole turn. It runs on your own subscription; Zasper holds no key.
A SQL cell queries your database, or the DataFrames the kernel already holds, and leaves the answer as a DataFrame for the cells after it. PostgreSQL, MySQL, SQLite, DuckDB, Snowflake, BigQuery and more, browsed table by table in the Data panel, with each password kept in your system keychain.
Every Jupyter kernel you have registered, and any Python with ipykernel on
your PATH, in your active conda or virtual environment, or in the project's
.venv, one click from a blank notebook.
Your own shell in a panel below the notebook it belongs to, beside the problems, references and variables of the file you are in.
Branch, stage, commit and read a side-by-side diff in the window you are already working in. JupyterLab ships no source control; git there is a separate extension you install and keep up to date yourself.
Zasper reads and writes .ipynb at each file's own nbformat version and runs the
kernels you already have, so the notebooks in the screenshots above are ordinary Jupyter
notebooks.
Smaller features, in the same download.
Page, sort, filter and chart a frame in its cell, and turn the chart into code.
Close the tab or lose the connection mid-run; every line the cell printed is there when you come back.
What changed, cell by cell, with execution counts left out of it.
Completions, go to definition, find references, rename, and quick fixes, in notebook cells as well as in files.
A word in any file, notebooks read as cells rather than as JSON, and a replace you see before it happens.
Every cell and what it printed. Matches in outputs are shown but not replaced.
Rendered in a tab, side by side with their source where that helps.
A notebook as an HTML page, as Markdown, or as a plain script in the kernel's language.
Your headings, in a column beside the cells, for the notebook that got long.
Per project, across a restart, reading each file only when you first switch to it.
Every command with its key binding beside it, and files in the same box.
Four hues, light and dark, and the editor's syntax colours follow.
Zasper launches kernels through Jupyter's own kernelspec mechanism, so a kernel that runs under Jupyter runs here without being registered again.
Python covers two implementations, ipykernel and Xeus (xeus-python).
Every registered kernel is listed, and so is any Python environment Zasper finds with
ipykernel in it. The launcher above shows ten, two of them Xeus kernels.
Installing kernels walks through adding your own.
The same binary either way. Run it on the machine in front of you, or put it on a box and open it from anywhere. A footprint this small is what makes a shared server cheap.
Every server starts with an access token. Sign in with the link it prints, or paste the token; set it yourself to keep it across restarts.
A reverse proxy in front, WebSockets passed through, and the certificate you already have.
A Dockerfile and a Compose file to build and run it in a container, and a systemd unit for when it should come back up with the machine.
Deploying on Cloud walks through all three, and both ways to sign in.
Ten minutes from nothing to a notebook you have run and saved.
Homebrew, snap, conda, or the binary for your platform. No runtime for Zasper
itself; notebooks need a Jupyter kernel, and pip install ipykernel is
enough to start.
Make one, put it on a kernel, run a cell, write down what it was for, and save it, step by step, with a picture of each.
Your first notebookRegister the conda or uv environment you already work in as a Jupyter kernel, and it appears in the kernel list.
Working with CondaZasper is dual-licensed. Use it under the GNU Affero General Public License, or under a commercial license when the AGPL's terms do not fit what you are building.
Running Zasper, on your own machine or on a server, needs nothing more. If you distribute Zasper, or let people use a modified version over a network, the AGPL requires you to make the corresponding source, including your changes, available under the same license.
Read the licenseFor organizations that want to build Zasper into a proprietary product, keep their modifications private, or need terms the AGPL does not offer.
prasun@zasper.ioContributions are accepted under the Contributor License Agreement, which is what lets Zasper be offered under both licenses.
For your notebooks and your kernels, yes: the same files, the same kernelspecs, the same wire protocol. For JupyterLab itself, no. This is a separate implementation with its own interface, not a re-creation of Lab's UI or its extension API.
No. Zasper has its own extension model rather than Lab's, so a lab extension will not load. If an extension is the reason you are staying, that is a fair reason to stay.
Yes, and there is a Windows build. The one part that needs WSL is the built-in terminal, which is built on a Unix pseudo-terminal; running the server under WSL gives you that too and is the setup we recommend.
Yes, under the AGPL-3.0: install it, run it, put it on your own server, change it. The commercial license is for building Zasper into a proprietary product, which the AGPL does not allow.
One registered as a Jupyter kernel appears in the launcher as it does in Jupyter,
without being registered again. Without a kernelspec, Zasper still lists one with
ipykernel in it if it is active when Zasper starts, is your base conda
install, or is the project's .venv in a trusted folder.
No. Zasper runs a server on your own machine and your files stay on it. It sends
anonymous usage data, with no file names, paths, contents or IP address, and
ZASPER_TELEMETRY=0 switches it off;
PRIVACY.md is
the complete list. It also asks zasper.io once a day whether there is a newer
version, and loads widget libraries it does not bundle from jsDelivr unless
Load widget libraries from the internet is off in Settings.
Zasper is developed in the open, by people who use it. What to know before you depend on it.
The open issues on GitHub, and a developer guide that gets you building from source in two commands.
Open issuesQuestions, ideas and "is this supposed to happen", in the open, where the answer is findable afterwards.
GitHub Discussions
No account to make, and your files stay on your machine.
A high performance IDE for Jupyter notebooks. Any Jupyter kernel, one static binary, and a fraction of JupyterLab's resource use.