Sharing of spawned notebook server

We are developing a research platform based on jupyterhub / kubespawner and are trying to implement a way to either

  • change ownership of a spawned notebook container or
  • make the container available to multiple users

Our current idea is to modify the home template, inject a list of all users via c.JupyterHub.template_vars and adding dropdowns to select a different user to hand over a specific container.


  • c.JupyterHub.template_vars is a static dict and would not reflect newly added users (maybe change Dict -> Dict factory (callable))
  • Get a list of all users: Is direct access of the server state from possible? If not we would have to access the REST API (/hub/api/users) but this specific endpoint needs admin privileges
  • Change ownership of a container: I think there is currently no API endpoint for this task. Is there another solution?

What do you think? Is there a better / different approach?

Access to a spawned notebook is protected by a secret token. This means you could share access to the notebook server by sharing a URL that includes that token. For example by having a “share this session” button in the UI.

The notebook would continue to run under the user that originally started it though.

An alternative approach is to start the notebook as a JupyterHub service and give multiple users access to that service. This is the model nbgrader uses. You’d have to look at their code/docs a bit to see how they do it and if it fits your use case.

Could you explain a bit what the use-case/motivation for wanting to share the session are?

1 Like

Hey Tim
Thanks a lot for your answer!
Our jupyterhub is used in a research environment. So each spawned container will belong to a research project. The container should be be accessible by one person at a time only but it should be possible to pass around the container within a research group after logging out of the container.
We already have a primitiv “locking” mechanism. But now we are thinking about how to implement the container sharing feature. Both approaches you mentioned above sound promising!

Maybe even one step back helps a discussion a bit. These are essentially our use case specs:

  • hand overs / edit token: hand over a single notebook “edit token” between users (think: usual student-supervisor or multiple-authors workflow for paper/notebook editing)
  • instant: do hand-overs instantaneously (excludes rebuilding/respawning; think: multiple hand-overs during meeting)
  • read list all: each user sees all projects (*) and who has the edit token

(*) I guess for this use case we can think of projects as pods/containers w/ Jupyter servers, but in general they are supposed to be a bit more, more specifically, folders out of which users can start new servers, if one was not running or running and stopped already.