Jupyter server · Rust · no Python
Ganymede runs your kernels and serves the same API as
jupyter_server, so JupyterLab and VS Code connect to it unchanged. It is
one Rust binary, or a library to embed, and it needs no Python environment to run a
TypeScript notebook, or any other.
For people who want Jupyter where a Python environment is a burden or impossible: TypeScript notebooks on cdp-kernel, CI jobs that run notebooks, and apps that embed a notebook server.
# Linux, macOS: latest release, plus cdp-kernel if Node 24+ is installed
curl -fsSL https://ganymede-server.com/install.sh | sh
ganymede kernelspec list# Rust toolchain
cargo install --git https://github.com/tlockney/ganymede ganymede-cli
ganymede kernelspec listLinux and macOS are tested end to end. Windows binaries are built but not tested. Other ways to install
ganymede lab, running a TypeScript notebook on
cdp-kernel.ganymede serve prints a URL with its token. Paste it into VS Code's
Existing Jupyter Server, or open JupyterLab's own bundle from it, and pick any
kernel you have installed: cdp-node for TypeScript, python3
if ipykernel is there.
No server at all for scripts and CI: ganymede run sends code to a
kernel and prints the output, and ganymede execute writes the same
notebook jupyter execute would.
$ ganymede serve --root-dir ~/notebooks
http://127.0.0.1:8888/?token=4f9c…
$ ganymede run -k cdp-node 'const x = 2; x * 21'
42
$ ganymede execute report.ipynb --inplacejupyter server, jupyter execute,
jupyter kernel, and jupyter kernelspec.The docs are grouped by how much you already know.
Install, find your kernels, run code, execute notebooks, and serve the API.
GuidePoint an existing Jupyter frontend at Ganymede, and what works so far.
AdvancedThe Jupyter stack, where Ganymede sits in it, and how its crates fit together.
The server, kernel host, notebook format, and executor are Rust, with no Python
dependency. Python appears only as a kernel someone installed, as the reference
CI compares against, and as the format the notebook writer matches.
ganymede lab install unpacks JupyterLab's JavaScript from its PyPI
wheel without running Python. Details
Kernels come from the standard kernelspecs in the Jupyter data directories. The host knows no language; the same tests run on cdp-kernel and ipykernel.
The jupyter_server REST and websocket API, both websocket framings,
and JupyterLab's /lab/api/* endpoints.
jupyter executeNotebooks come out as nbclient writes them, and saves are byte-identical to
Python's nbformat, so git sees no churn.
ganymede-engine is a library: start kernels, execute with streaming
output, run notebooks. It builds for iOS, Android, and wasm.
Atomic writes, modification-time conflict checks, and checkpoints outside the notebook folder, so synced folders such as iCloud Drive stay intact.
Ganymede takes jupyter_server's place and keeps both of its
interfaces: the API above it and the kernels below.
| Client | How it connects | Status |
|---|---|---|
| VS Code | The Jupyter extension's Existing Jupyter Server, with the URL and token. | Works |
| @jupyterlab/services | JupyterLab's client library: kernels, sessions, contents, interrupt, restart. | Works |
| JupyterLab | Its static bundle served by Ganymede at /lab, from ganymede lab. | Works |
| Own UI | A Swift shell with a web view on iPadOS and macOS, the core in-process. | Planned |
Nothing in the Jupyter protocols requires Python, but the server does: running a TypeScript notebook means installing a Python environment first. That rules out places Python can't easily go, such as an iPad app. Ganymede keeps the protocols and the ecosystem and drops the dependency.
Early software. An end-to-end suite compares it against jupyter execute
and jupyter server on cdp-kernel and ipykernel, on Linux and macOS.
Windows builds but is not tested end to end. Known gaps