2i2c Initiatives Roadmap

As an end user, I have a maximum amount of home directory storage I can use on a hub. However, there is no easy way for me to know how much I have used, so I bump into storage quota limitations as a surprise.

As a JupyterHub admin, I want to leverage all possible kinds cloud resources available to me to serve my users, rather than just commercial cloud providers (like AWS, GCP, etc). I’ve limited budget that goes towards everything I do, and being able to reduce the cloud spend $$$ lets me put that money towards other things that add value. Due to my affiliation, I have access to an allocation of resources on the National Research Platform. I want something a little more customized than NRP’s hosted jupyterhub, and I don’t have the skillset (or time) to deploy my own JupyterHub there. I would like to be able to use NRP’s resources (particularly GPUs) to serve my users.

As an instructor, I want to teach content that requires use of a not very powerful GPU some of the time. It’s integrated into my teaching syllabus, where there is a lot of CPU bound work and some GPU bound work. While I could bounce to a different tool that offers just GPUs (like Google Colab) that has its own set of compliance, pedagogy and UX problems that detract from my teaching and I don’t want my students to go through that.

As a student, I want to do all my course content in one familiar hub where I have access to similar tools and my home directory is the same over time for any particular course, without bouncing between different tools. I also don’t want to have to understand the differences between various GPUs, etc before I do my work, as I’m just doing light GPU work to understand fundamentals.

As a hub admin, I want to support my instructors using GPUs but without blowing through my budget entirely. I also want to give them any GPU access at all, in the face of limited GPU availability on many cloud providers today (in 2026)

As a 2i2c engineer, I want to support the same features across all cloud providers, so my support load is less.

We use helm to deploy the JupyterHub chart z2jh. The helm project released v4 in September of 2025. We need to structurally keep up with these releases in time, so we don’t have to scramble when the older version gets end-of-life. We currently don’t know if zero to jupyterhub works with helm v4, so we can not ‘simply’ upgrade.

As a JupyterHub admin, I want to provide GPU access to my users, but want to know if they are using it efficiently. GPUs are expensive, and we pay for them when we provision them, regardless of how much they are used. So I want to be able to tell if users are heavily underutilizing them, so I can talk to them to provide more educational resources or investigate if their needs are met by CPU-only tooling already. I also want to tell if someone is maxing out their GPU, so I can offer them bigger resources if needed. This reporting also helps me justify my cloud spend budget, as I can point to end users utilizing the resources I provide.

As a user on the hub, I want to have someone else get into the exact same kind of server I am on (environment, resource allocation, content pulled, etc) so we can work together with less accidental complexity caused by underlying server differences. Currently to do so, I have to explicitly give them verbal instructions on what options to choose or type in their ‘Start Server’ page (‘Select the JupyterLab instance, and pick the 14.1 GB resource allocation, then click start’), which is error prone. It is particularly error prone when those instructions use features such as ‘Unlisted choice’ (‘Select Other..., and type in this exact image, and avoid spaces’) or ‘Build your own image’. I want an easier and more succint way to share this that doesn’t involve verbal instructions.

As an instructor in a smaller or under-resourced college or university, I want to use JupyterHub to provide interactive instructional help for my students. However, we have a limited and fixed budget, and I must know beforehand how much it is going to cost each month. I am told that commercial cloud providers with autoscaling will have cloud spend ‘based on usage’, and the estimates I am given are beyond my current reach. My class sizes are reasonably small, and I would love to have a fixed cost pathway towards running a hub. This should also help me prove to my institution that this is a valuable service that we should pay for as an organization.

As a hub admin, I want to provide GPU access for my instructors & students so they can experiment with modern code that requires GPU. However, GPUs in commercial cloud are expensive and I want to balance how much $$$ I spend on the cloud. Due to my institutional affiliation, I have access to credits on Jetstream2, and I would like to run a hub with GPU access there.

As a JupyterHub admin, I want to put users in different kinds of ‘groups’ for different purposes:

1. For access to the hub

2. For cost monitoring and reporting

3. For access to different size of resources (more RAM, GPUs, etc)

4. For admin access (to other users’ servers and home directories and shared directories)

5. For potential collaboration

All these are groups under different ‘axes’, and I don’t know how to structure groups from my authenticator to support these use cases. There are many different ways to do this, and I don’t have any guidance or expertise to figure out what the options are, and how to choose them.

As a researcher, I want to be collaborate with another user (or users) on my hub by temporarily granting them real time access to the notebook I’m working on in a secure way.

As a student, I want to temporarily grant real time access to my notebook to a TA so they can help me with some conceptual or coding problems I am having.

• As a Project Pythia cookbook author, I want to be able to see previews of PRs created on a GitHub Repository. I do not want to register my cookbook with a central provider such as ReadTheDocs.

• As a Project Pythia maintainer, I want to simplify my CD workflows to reduce complexity around PR previews. Presently, this complexity is required by each community that wishes to implement GitHub Pages-based PR preview workflows. I want to keep pull_request_target workflows as trivial as possible, due to the security challenges with this mechanism.

• As a community leader, I want to be able to view confidential reports that detail usage and costing of our hub. I want to be able to share links to these that continue to work for some time. I already have a JupyterHub running 24/7, and I would like to take advantage of this without incurring much additional expense.

• As a researcher, I want to share in-progress research with my community. I am not yet able / permitted to share this more widely, so I want to ensure that only particular users and/or groups can see it.[^scopes]

Given successful deployment of Canvas based authentication to the UToronto staging hubs, we need to roll this feature out to production. In doing so, we must be careful to ensure that existing users enjoy uninterrupted access to their

With the ability to log into the production UToronto hubs using Canvas authentication, we may turn our eye to restricting particular kinds of users to particular kinds of resources (storage and compute). This requires the existence of an authorization library, jupyterhub_oauthenticator_authz_helpers that will be built for this purpose.

Having built jupyterhub_oauthenticator_authz_helpers, we would like to deploy it to the UToronto production hubs. This will involve ensuring that no adverse impact to user experience occurs, and that the functionality matches the SoW.

There is ongoing governance work in the JupyterHub ecosystem that 2i2c folks are involved in towards setting up a jupyterhub-contrib space that serves as a multi-stakeholder home for non-core projects. Given how broadly used Canvas is, and the desire to continue using it without having to be the sole maintainers of it, jupyterhub_oauthenticator_authz_helpers would make a fantastic addition to such a space once it exists.