| Status | Title | Description | Issue | Funding Status |
|---|
| 🚀 In Flight | Provide group based cost rollups for hubs on AWS | Aggregate per-user cloud costs by JupyterHub group so that hub administrators can transparently see cost attribution by organizational team/department/etc. This builds on per-user cost reporting (#6315) and provides cost rollups where users in multiple groups may be double-counted. | #6321 | |
| 🚀 In Flight | Rollout storage quotas to all AWS and GCP clusters | Deploy storage quota functionality uniformly across all AWS and GCP clusters/hubs so that hub administrators have consistent resource management capabilities to prevent users from consuming excessive storage. | #5477 | |
| 📋 Upcoming | Improve nbgitpuller error handling | Replace technical error messages with human-readable feedback and provide an “escape hatch” link to the Jupyter environment so that non-technical users like students aren’t stranded when nbgitpuller links fail. See the Statement of Work for details. | #6442 | Co-funded |
| 📋 Upcoming | Integrate JupyterBook2/MyST sites for BIDS Hubs | Deploy and operate JupyterBook 2 / MyST site infrastructure integrated with BIDS hubs so that BIDS/Berkeley teams can showcase interactive stories in a content gallery. See the BIDS Statement of Work for details. | #7095 | |
| 📋 Upcoming | Provide per-component and total cloud cost reporting on GCP | Outcome here is that users on GCP will also get total and per-component (compute, disk, object storage, network, base) costs they can explore via Grafana. This would bring feature parity with what exists on AWS as of July 3, 2025. | #6320 | Negotiating funding |
| 📋 Upcoming | Provide per-user and per-group cost reporting for hubs on GCP | Extend per-user and per-group cost monitoring to GCP hubs so that administrators have cloud-agnostic cost transparency. This builds on #6315, #6321, and #6320. | #6322 | |
| 📋 Upcoming | Explore NRP deployment | Validate 2i2c infrastructure on the National Research Platform, document feasibility findings, and publish a blog post on the experiment so that we understand deployment viability and can report results to BIDS. See the BIDS Statement of Work for context. | #7094 | |
| 📋 Upcoming | Compute usage quotas | Develop a quota system for compute resources so that hub administrators can allocate and limit CPU usage for individual users and groups, preventing cost overruns. See Productboard insights for community needs. | #5382 | |
| 📋 Upcoming | Real-time collaboration | Real-time collaboration is a commonly requested feature from our communities. We want to assess what solutions are out there in the ecosystem, and choose one to become the default for our hubs. | #2413 | |
| 📋 Upcoming | Wrap up and roll out dynamic environment building and sharing | As hubs get a wider user base, different users need different environments to do their work. The same user may need multiple environments at different times too. Long term, we can not rely on admins to continuously update the small set of images available, and for users to have to keep up with modifying their code to work with newer packages. We need a way for users to be able to specify environments (without having to really understand Docker), with a view to later being able to share them with others in a standardized way. This should be done in a way that’s compatible with community standards as well, rather than re-inventing something new. As part of the previous PI, we have deployed jupyterhub-fancy-profiles to VEDA for an improved logged-in environment choosing experience. This builds on top of that, with the goal of making it easier for users to easily... | #5064 | |
| 📋 Upcoming | Canvas authentication | Large educational institutions like UToronto, the kinds of institutions likely to be in our Premier tier, use Canvas to manage their users. They are unlikely to ever want to switch to managing their users and groups in something like JupyterHub, but we still want to enable them to everage their user databases for the purposes of usage and costs monitoring. | #6171 | |
| 📋 Upcoming | Dask quotas | EarthScope has highlighted the issue of users being able to spin up an infinite number of Dask nodes, potentially skyrocketing their costs. This issue is also relevant for the P&S MVP 2.0, as Premier customers will want control against Dask cost overruns. | #5381 | |
| 📋 Upcoming | Shared folders with access control | Currently, we have a simplistic shared folder that admins of a JupyterHub can write to, and everyone else can only read from. This works for some subset of use cases, but not all. It would be very useful to have a way for users to create ad hoc shared folders that they can share with specific other users, based on either JupyterHub group memebership or just by username. This would allow students to collaborate together, as well as allow for designated ‘collection zones’ set up by admins for students to submit work. | #5380 | |
| 📋 Upcoming | Create “Allow List” system for public Binderhub service | In the Product and Services MVP 2.0, we explored the concept of a 2i2c-run public binderhub service in the vein of mybinder.org which would allow interactive content shared by 2i2c member organizations to be launched on a small to medium binder. | #1755 | |
| 📋 Upcoming | Allow admins to define the list of images their users can select | We want to provide admins with an interface that will allow them to curate and define a list of images to make available to their hub users. | #5383 | |
| 📋 Upcoming | Provide an interface to assign quotas to users and groups | We want to provide hub administrators a way to self-manage resource quotas, within the limits set by 2i2c. To that end, we want to develop an extensible Web UI application that will allow admins to assign resource quotas to both individual users and groups of users, independent of where those groups and users are managed (e.g. Canvas, GitHub etc.) | #5615 | |
| 📋 Upcoming | Use conda-lock files for 2i2c maintained images | (Needs refinement) | #6904 | |