2i2c

A new Linux kernel zero-day called CopyFail lets code break out of containers onto the host. We took a close look at our community hubs, confirmed they're likely safe, and added another layer of protection just in case. Here's a post about what we learned 👉 2i2c.org/blog/copyfai...

We took a few extra measures on our hubs, like deploying copyfail-ebpf-k8s (thanks iwanhae!) across our hubs. It blocks the specific kernel feature CopyFail depends on.

A new Linux kernel zero-day called CopyFail lets code break out of containers onto the host. We took a close look at our community hubs, confirmed they're likely safe, and added another layer of protection just in case. Here's a post about what we learned 👉 2i2c.org/blog/copyfai...

We tested the public Kubernetes proof-of-concept on a staging hub running on AWS / EKS. The exploit was unable to break out of our container. This was a good indicator, and we spent a bit of time investigating why.

We just contributed a JupyterHub feature that lets hub admins keep their admin powers while still using a shared password for participants (often used in workshops). 👉 2i2c.org/blog/shared-...

Hub admins can now set two passwords instead of one: a participant password and an admin password. Attendees still get a simple shared login, while organizers regain group management, the admin dashboard, and shared directory access.

Why does 2i2c upgrade core infrastructure quickly when new versions come out? Our collaborators at NASA VEDA recently asked us this exact question. Here's how Yuvi explained it. 👉 2i2c.org/blog/why-upg...

Of course, upgrading can break things. We've had communities hit issues in the past, and it's important to move carefully. But staying current means when security fixes drop, rollout is fast because the hard work is already done.

Why does 2i2c upgrade core infrastructure quickly when new versions come out? Our collaborators at NASA VEDA recently asked us this exact question. Here's how Yuvi explained it. 👉 2i2c.org/blog/why-upg...

Staying up-to-date keeps the whole ecosystem moving forward. Upgrades aren't just maintenance - they're how we drive improvements upstream in JupyterHub, Helm, and the wider open source tools we depend on.

We spent a bit of time updating Jupyter Book's landing page documentation, and making it more useful for communities with multiple content repositories under one domain. Here's a little post about it: 2i2c.org/blog/jupyter...

We’re proud to share a public roadmap for 2i2c's team - it's a step toward more participatory, transparent open development with our member and upstream communities. 👉 2i2c.org/blog/public-...

We also want to use this to experiment with fractional co-funding, so multiple member communities can share the cost of impactful work. You can learn more about how our membership model works here: 2i2c.org/membership

We’re proud to share a public roadmap for 2i2c's team - it's a step toward more participatory, transparent open development with our member and upstream communities. 👉 2i2c.org/blog/public-...

We’re incredibly proud to announce that Jenny Wong was invited to join the JupyterHub team as a contributor and maintainer! 2i2c.org/blog/jenny-j...

We’ve enjoyed seeing Jenny bring care, follow-through, and a collaborative mindset to her upstream work. That’s what makes someone a great maintainer <3.

We’re incredibly proud to announce that Jenny Wong was invited to join the JupyterHub team as a contributor and maintainer! 2i2c.org/blog/jenny-j...

Angus just gave a FOSDEM 2026 talk on Introducing Jupyter Book 2 and why this stack matters for reusable, reproducible computational publishing. 2i2c.org/blog/fosdem-...

In short: Jupyter Book 2 (now built on the MyST Document Engine) gives communities a better path to publish and maintain computational narratives without locking content into one format or workflow.

UC Berkeley's DataHub team shared error log data that helped us redesign error handling in nbgitpuller - a tool used across education and research to distribute Jupyter content via a single link. 2i2c.org/blog/nbgitpu...

Instead of showing every user the same raw git output, nbgitpuller now detects the error type and displays a targeted, human-readable message with specific steps to resolve it. The terminal log is still available - just tucked behind a toggle.

UC Berkeley's DataHub team shared error log data that helped us redesign error handling in nbgitpuller - a tool used across education and research to distribute Jupyter content via a single link. 2i2c.org/blog/nbgitpu...

We helped STRUDEL run a workshop where 30+ researchers prototyped building scientific web applications in a single day. Everyone left with a working prototype, even folks who'd never built a web app before! 2i2c.org/blog/strudel...

If you're thinking about running workshops that need pre-configured environments, this setup might be useful. Tips on using STRUDEL with AI assistants here: github.com/strudel-scie...

We helped STRUDEL run a workshop where 30+ researchers prototyped building scientific web applications in a single day. Everyone left with a working prototype, even folks who'd never built a web app before! 2i2c.org/blog/strudel...

People built prototypes for real work in astrophysics, genomics, energy, water quality, and light sources. The hub gave them space to experiment without worrying about infrastructure. strudel.science/engage/news/...

We helped STRUDEL run a workshop where 30+ researchers prototyped building scientific web applications in a single day. Everyone left with a working prototype, even folks who'd never built a web app before! 2i2c.org/blog/strudel...

Our goal was to provide an AI-assistant environment with zero friction. We configured a JupyterHub with VS Code for the Web and Cline (an AI coding assistant) so participants could start building with AI help immediately instead of spending hours on environment setup.

Community work is infrastructure work. It’s how open source projects stay healthy, resilient, and welcoming over the long term. We're proud to share that our April (our People Lead) has joined the Jupyter Community Building Working Group! 2i2c.org/blog/april-j...

This kind of thing is a key part of the foundational impact 2i2c wants to have for open source communities: not just technical and infrastructure work, but also bringing expertise and support in community and governance. We're proud April was willing to step into this role!

We helped empower CloudBank to provision and manage their own infrastructure on our shared platform. Instead of waiting on 2i2c engineers, they can now handle these changes themselves. 2i2c.org/blog/cloudba...

This is part of how we think about agency vs safety on a shared open platform, give partners control in a way that's safe for other member organizations. As a result, CloudBank can run routine Terraform changes, and they validated it by deploying a hub without 2i2c in the loop.

We helped empower CloudBank to provision and manage their own infrastructure on our shared platform. Instead of waiting on 2i2c engineers, they can now handle these changes themselves. 2i2c.org/blog/cloudba...