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 starts ahead and stays ahead, and the distance grows with concurrency rather than shrinking. Past 64 kernels the comparison stops being about cost: 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, which is what “up to 40×” reports. At light load the difference is closer to 3–4× on both — the advantage is a function of concurrency, not a constant. The crosses are measured the same way as the lines: replies received against requests sent, which is flat at five replies per request until a server stops answering — so 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 speaks Jupyter's wire protocol and 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 articleThe numbers above are only half the question. Every screen below is a running session, not a mock-up.
Conda, uv, venv and every Jupyter kernel you have installed — detected on open and one click from a blank notebook or a shell. Nothing to register by hand.
Not an emulation. A full terminal that restores its session on reopen, in a tab beside the notebook it belongs to.
Branch, stage, commit and read a side-by-side diff in the window you are already working in. JupyterLab ships no source control at all; git there is a third-party extension you install and maintain yourself.
Underneath all three: Zasper speaks Jupyter's wire protocol, reads and writes .ipynb at
its own nbformat version, and runs the kernels you already have — so the notebooks in the
screenshots above are the notebooks you have now.
The things you stop noticing until they are missing.
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.
Fifty cells at once, including the ones that are not open, and the read-only ones.
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 both implementations: ipykernel and Xeus (xeus-python).
Conda, uv and venv environments are detected on open — the launcher above is showing nine of
them, two of which are 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.
An image to 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 four, including the two ways to sign in.
Ten minutes from nothing to a notebook you have run, saved and put under version control.
Homebrew, snap, conda, or the binary for your platform. No runtime to install first, nothing to configure after.
InstallationMake 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 notebookPoint Zasper at the conda or uv environment you already work in, 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.
They are found the way Jupyter finds them, through kernelspecs, and appear in the launcher without being registered again. An environment that runs a notebook today runs it here.
No. Zasper runs a server on your own machine and your files stay on it. The only
thing sent anywhere is anonymous usage data — no file names, no paths, no contents,
no IP address —
PRIVACY.md is
the complete list, and ZASPER_TELEMETRY=0 switches it off.
Zasper is developed in the open, by people who use it. The parts of that worth knowing before you depend on it:
Issues kept labelled for people arriving, 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 DiscussionsThe project's own workspace, for the conversations that are quicker as a conversation.
Join the Slack
Nothing to sign up for, nothing to upload, nothing to uninstall first.
A high performance IDE for Jupyter notebooks. Any Jupyter kernel, one static binary, and a fraction of JupyterLab's resource use.