Jupyter Blog - Chris Holdgraf

How we combine multiple repositories into one website at jupyterbook.org

2026-04-22T13:01:00+00:00

The Jupyter Book project has content in a bunch of different repositories — user docs, a blog, a team compass, and project & community pages. We recently finished an initiative to serve each set of content at jupyterbook.org, while keeping the source files separated in their repositories.

Jupyter Book builds tools and standards for communicating and publishing computational narratives.

Getting there required a combination of Netlify configuration and several improvements to MyST and the MyST theme along the way. This post walks through the pieces and how they fit together, so you can do something similar with a multi-repo project.

Cross-posted with this Jupyter Book blog post where you can see the MyST engine in action.

Why is this useful?

Two things bugged us about the old setup:

We had multiple types of content embedded in one repository. In particular we had versioned user documentation alongside evergreen community documentation (e.g., the roadmaps page). This meant we had duplicated content for some user documentation, and a slow lag time before it’d make it’s way into /stable.
Search engines treat subdomains as separate websites, so blog.jupyterbook.org wasn’t helping jupyterbook.org in search rankings.

We wanted jupyterbook.org, jupyterbook.org/blog, jupyterbook.org/stable, jupyterbook.org/compass all under one roof, with each repo still deploying on its own via static websites.

We accomplished this with Netlify proxy rules and shared MyST configuration!

Proxying sub-sites with Netlify rewrites

We discovered that Netlify reverse proxy rules are a great way to accomplish this. These essentially intercept queries to a URL path (eg. /blog/**) and serve content at that path from elsewhere (e.g., blog.jupyterbook.org). The browser sees jupyterbook.org/blog, but Netlify fetches the content from a totally different site behind the scenes.

We set up a “jupyterbook.org” repo that serves the landing page and our evergreen community documentation, and proxies everything else:

/ - served directly from the jupyterbook.org repo (served on Netlify)
/blog - proxied from the blog repo (served on Netlify)
/compass - proxied from the team-compass repo (Served on Netlify)
/stable - proxied from the jupyter-book repo (served on ReadTheDocs)

Here’s what the netlify.toml looks like (simplified):

# Blog: proxied from another Netlify site
[[redirects]]
  from = "/blog/*"
  to = "https://jupyter-book-blog.netlify.app/blog/:splat"
  status = 200
  force = true

# User docs: proxied from ReadTheDocs
[[redirects]]
  from = "/stable/*"
  to = "https://jupyter-book.readthedocs.io/stable/:splat"
  status = 200
  force = true

Each repo deploys independently, meaning we can update the content at whatever cadence is best for that repository. The jupyterbook.org repo only needs updating when the nav structure changes. But making it all feel like one site took some work on the MyST side.

Shared configuration with `extends`

MyST’s extends: configuration lets one project inherit configuration from another. We use this to share navbar, logo, and favicon config across all sub-sites from a single site.yml in the core repo:

# In the blog's myst.yml
extends:
  - https://github.com/jupyter-book/jupyterbook.org/raw/refs/heads/main/docs/_site/site.yml

If we change the configuration at that file, it’ll automatically be inherited in every other repository when we re-build it (usually done on each commit, or on a daily CRON job with GitHub Actions).

Here are a few useful things that we’ve shared across sites via the pattern above:

Navigation bar URLs
Site footer configuration
Site branding (logo, titles, etc)
Announcement bars (when we need a temporary announcement to show up everywhere)
Internal domain configuration (see above)

Along the way we added parts: support to the extends: key to get this working.

One gotcha: `BASE_URL` for asset paths

MyST bakes BASE_URL into CSS, JS, and image paths at build time. If you build with BASE_URL=/ but serve at /blog, none of those load properly.

To fix this, each sub-site builds with BASE_URL set to its final path on jupyterbook.org. For example, here’s some Netlify config from the blog that does this:

[build]
  publish = "publish"
  # This ensures that `/blog` is appended to asset paths
  environment = { BASE_URL = "/blog" }
  command = """
    cd docs && myst build --html && \
    mkdir -p ../publish/blog && \
    # Here we move the HTML assets to the blog
    mv _build/html/* ../publish/blog/
  """

`internal_domains` for cross-site navigation

BASE_URL fixes asset loading, but it doesn’t fix navigation. Jupyter Book used to treat full URLs as “external” links, adding an extra icon and opening a new tab when clicked. This led to a bunch of tabs any time you navigated around jupyterbook.org, and was also reported by the Project Pythia team.

We added an internal_domains option to fix this:

site:
  options:
    internal_domains: jupyterbook.org

Now the theme treats any link to jupyterbook.org as internal. It provides same-tab navigation and no external link icon, even though the link is technically a full URL.

Want to do this too?

Hopefully this is a useful workflow for communities that have multiple repositories of content.

All of the config is in jupyter-book/jupyterbook.org, and the tracking issue with the full story is jupyter-book/jupyter-book#2528.

If you’ve got questions about this work, come chat with us at discord.mystmd.org.

Acknowledgements

Thanks to Project Pythia for providing additional guidance, collaboration, and support for this work.
Thanks to EarthScope for giving user feedback about the usefulness of this as they explore converting their docs to the new MyST engine.

Announcing our first Jupyter Community Funded Proposals

2025-11-04T19:19:00+00:00

We are thrilled to announce the results of our first round of Jupyter Community Funding proposals. This is the first funding call from the Jupyter Foundation to directly solicit proposals from the Jupyter community.

We received many outstanding ideas from community members. We are so grateful for the time and effort everyone put into their submissions. This is a new process for us, and we’ve already learned a lot. We’re excited to take this first step in directly supporting community-driven work.

After a careful review, we are happy to fund the following proposals:

More reliable visual testing for Jupyter frontends: This project will improve visual regression and integration testing across Jupyter frontends. We hope this will lower maintenance costs and reduce maintainer burnout by making testing more reliable.
Separating JupyterLab’s build system for easier maintenance: This work will finish separating JupyterLab’s build system into a standalone tool. This will make maintenance easier for both core developers and extension authors.
Improving keyboard accessibility in JupyterLab: This proposal will focus on making JupyterLab fully navigable via keyboard and testing with disabled users. The goal is to find and fix key accessibility blockers, making the tools more usable for everyone.
Growing the contributor community for JupyterHub and JupyterBook: This project will tackle efforts like team coordination and mentorship pipelines with clear entry points for contributions. We hope this will grow our contributor base by making it easier to attract, retain, and leverage community contributions.
Improving code quality with custom linting rules: This proposal will develop custom linting rules to enforce project-specific standards in the JupyterLab and Notebook codebases. This will help catch common issues early and improve the long-term health of the code.
Reviving the extension playground for easier prototyping: This project will revive and improve the extension playground, a tool for prototyping new extensions. We’re excited for this to lower the entry barrier for extension development and help the ecosystem grow.

A huge thank you to everyone who submitted a proposal and participated in the review. We also want to thank the authors of proposals that were not funded in this round. We particularly appreciate their effort and hope they will continue to engage with this process.

We’re excited to see these projects develop and support the dedicated people behind them. This is just the beginning, and we look forward to more community funding opportunities in the future.

We want to send a special thank-you to Savannah Ostrowski, former Jupyter Foundation board treasurer, for her work in setting up this initial round of funding.

Your Ideas, Our Support: Jupyter Community Call For Funding Proposals

2025-08-28T15:18:00+00:00

The Jupyter Executive Council and Jupyter Foundation are pleased to announce a call for proposals for the Jupyter community. Visit the Jupyter Foundation Community Proposals webpage to learn more about the process and how to submit proposals. The call for proposals is open through Sunday, October 5th, 2025.

edit: We’ve decided to extend this by one week to give a few in-progress proposals time to write and submit! The new deadline is October 5th.

The Jupyter Foundation began its operations in early 2025 with a mission to use its resources to support the Jupyter community. We’ve set up the operations, structure, goals, and strategy of the Jupyter Foundation and published them on the Foundation team compass. We’ve had several rounds of feedback from the Jupyter community and defined the Foundation’s overall goals for its first year of operation.

Our first funding allocation supported events that grow the connections within the Jupyter community via the community workshops series as well as our connection with the broader data science community via JupyterCon 2025.

For the next wave of funding for the community, we’re running an experiment to directly solicit funding proposals from the Jupyter community. We think this will result in a strong clear connection between the Foundation’s funds and the needs of Jupyter’s maintainers, contributors, power users, and advocates.

The call for proposals is open through Sunday, October 5th, 2025.

Visit the Community Proposals webpage to learn how to submit a proposal and the Jupyter Foundation team compass for more detailed background about this funding call.

In this first round, one of our goals is to learn. We’d like to learn how to administer a community call like this as well as what kind of value it delivers to the Jupyter community. We’ve set minimum targets for funding disbursement and hope to grow our funding allotment as we iterate from here.

To help inspire proposals we are particularly excited to fund, we’ve defined funding priorities for the Jupyter Foundation. These are key outcomes that we must improve in order to grow the overall health and impact of the ecosystem. Briefly summarizing, these priorities are:

Grow the contributor capacity of Jupyter. We would like to grow the number of contributors, improve the efficiency of existing contributors, and facilitate learning across Jupyter subprojects. We’d love to see proposals that help us mobilize and support the total pool of energy available to contribute to Jupyter.
Improve the reliability, security, and consistency of Jupyter’s software and team practices. We believe that our technology will be more impactful and easier to contribute to and deploy if we improve our development infrastructure and team practices in ways that contribute to reliability, security, and consistency.

While we’re particularly excited about these outcomes and aim to focus funding on proposals that clearly feed into one or both of these priorities, we also encourage people to get creative and submit proposals for outcomes that have high impact and strategic value for the Jupyter community. We’re excited to see what others come up with, and are eager to work with you in unlocking critical funding in support of Jupyter’s community.

Acknowledgements

We are grateful for the support of the Jupyter Foundation and its members that makes this opportunity possible. If your organization would like to support this program, please contact the Jupyter Foundation.

Simplifying and speeding up Binder builds with BuildKit

2025-03-03T14:05:00+00:00

The Binder Project allows users to build reproducible, sharable environments for interactive computing. To accomplish this, Binder uses a tool called repo2docker to generate an executable Docker image using the Reproducible Execution Environment Specification.

The first time a repository is launched on Binder, repo2docker must build the reproducible environment for it. This process can take a long time because of all the dependencies that need to be installed and turned into the image. As a result, Binder launches can feel slow and clunky, which is a poor UX for workflows that are designed around quick interactive sessions.

repo2docker was built several years ago, and followed patterns that were commonplace at the time. However, in the past few years the Docker community has made significant advances in optimizing the image building process. One-such improvement is the creation of BuildKit, a replacement for Docker’s historical build system that is much more sophisticated. However, repo2docker hasn’t leveraged these improvements because it was still using the original Docker Build system.

So, we’ve decided to spend a few cycles modernizing repo2docker’s image building logic by using the more modern BuildKit API (via ‘docker buildx build’). This allows for optimizations like build parallelization, better build caching, and supporting some Dockerfile features that Binder didn’t support earlier (particularly, COPY --chown). It also lays a foundation for significantly simplifying the repo2docker build infrastructure and leveraging more of BuildKit’s parallelization functionality. For example, we’d like to leverage BuildKit’s Kubernetes driver which distributes builds much more efficiently and in parallel.

Authors of Binder repositories won’t need to take any action¹, and they’ll simply notice that mybinder.org (and any other community-run BinderHub instance) will be a bit snappier at building images.

If you’d like to learn more about the changes that enabled this, check out this mybinder.org pull request which has links to the repo2docker pull requests that added this functionality. We’re excited keep improving Binder, and are hopeful that this makes the experience of using mybinder.org and community Binders a little bit better.

Authors and acknowledgements

Yuvi Panda is a co-founder and the Technical Lead at 2i2c. He is passionate about building participatory open infrastructure for scientific & educational use cases. He is a Project Jupyter team member primarily focused on infrastructure related projects (JupyterHub, Binder, etc). He also wrote most of the code for this docker buildx transition, and shepherded it through to deployment on mybinder.org as well. He is ex-Wikimedia and ex-GNOME. Let’s eliminate accidental complexities wherever we find them.

Chris Holdgraf is a co-founder and the Executive Director of 2i2c. He is on the Executive Council of Project Jupyter, and co-leads the JupyterHub and Binder team as well as the Jupyter Book team). He was previously a post-doctoral researcher in the Department of Statistics at UC Berkeley, and a Community Architect with the Division of Data Science at Berkeley. He’s interested in using open infrastructure to support interactive computing workflows in research and education.

Many thanks to @minrk, @manics, and @consideRatio for their help reviewing and shaping this work.

Footnotes

¹ Unless they were relying on undocumented implementation details of the old builder — in particular, the presence of a /.dockerenv file to detect if you are running in repo2docker scikit-learn/scikit-learn#30835 has an example.

CZI awards three EOSS grants to Jupyter community members

2021-10-14T20:30:00+00:00

The Jupyter community is pleased to announce that members of its community have received three awards from the CZI Essential Open Source Software grant series. This grant series has previously funded work in the Jupyter ecosystem such as real-time collaboration in JupyterLab and JupyterHub’s Contributor in Residence pilot. Read below for a brief overview of the recently-funded proposals!

CZI’s Essential Open Source Software for Science program supports software maintenance, growth, development, and community engagement for critical open source tools.

Accessibility in Jupyter

One of the biggest challenges in building complex web-based applications is ensuring that they are accessible to a broad and diverse audience of users. Improving accessibility requires dedicated time and significant expertise in understanding the major challenges to overcome. Tania (@trallard), Isabela (@isabela-pf), and Tony (@tonyfast) were recently awarded an EOSS award to dedicate time and development towards making Jupyter tools more accessible. You can follow some of their work in the Accessibility repository and see the original text of this proposal here. This grant will be led by Tania, Isabela, and Tony (each at QuanSight Labs), and administered by the team at QuanSight Labs.

Interactive documentation

Because Jupyter is a dynamic and web-based interface, you can do a lot more with interactive documentation than is possible on traditional static websites. @carreau was awarded an EOSS grant to improve the state of interactive documentation within Jupyter. You can check out some of his early ideas in this blog post. This grant will be led by Matthias Bussonnier at QuanSight Labs, and administered by the team at QuanSight Labs.

Community strategic support for JupyterHub

The JupyterHub community built off of its Contributor in Residence pilot to propose a dedicated role for designing and developing community strategy for the JupyterHub sub-project. This role will spearhead efforts to ensure that there are inclusive and effective pathways into and throughout the JupyterHub community, with the goal of sharing best-practices with others in Jupyter and PyData ecosystems. You can follow along with this work in the JupyterHub Team Compass and find the original text of this proposal here. This effort will be led by Sarah Gibson(@sgibson91) and Chris Holdgraf (@choldgraf) (both at 2i2c), and Sarah will serve as our first community strategic lead. The grant will be administered by the team at NumFocus.

Congrats to the recipients of these awards, we’re excited to see what comes out of this work! And many thanks to all of the community members that helped write and refine these proposals.

Announcing the new Jupyter Book

2020-08-12T19:55:00+00:00

Note: this announcement is cross-posted between the Jupyter Blog and the Executable Book Project updates blog

Jupyter Book is an open source project for building beautiful, publication-quality books, websites, and documents from source material that contains computational content. With this post, we’re happy to announce that Jupyter Book has been re-written from the ground up, making it easier to install, faster to use, and able to create more complex publishing content in your books. It is now supported by the Executable Book Project, an open community that builds open source tools for interactive and executable documents in the Jupyter ecosystem and beyond.

The new Jupyter Book interface, highlighting how you can insert code outputs into your content

This post is a short overview of the new features in Jupyter Book, and gives some background on the future of the project.

You can also browse the new Jupyter Book documentation, or check out the Jupyter Book GitHub repository.

❗❗ Jupyter Book is still in beta, so things are always changing. We’d love your feedback, ideas, and PRs for how to make the project better!❗❗

What does the new Jupyter Book do?

The new version of Jupyter Book will feel very similar. However, it has a lot of new features due to the new Jupyter Book stack underneath (more on that later).

The new Jupyter Book has the following main features (with links to the relevant documentation for each):

✅ Write publication-quality content in markdown
You can write in either Jupyter markdown, or an extended flavor of markdown with publishing features. This includes support for rich syntax such as citations and cross-references, math and equations, and figures.

✅ Write content in Jupyter Notebooks
This allows you to include your code and outputs in your book. You can also write notebooks entirely in markdown to execute when you build your book.

✅ Execute and cache your book’s content
For .ipynb and markdown notebooks, execute code and insert the latest outputs into your book. In addition, cache and re-use outputs to be used later.

✅ Insert notebook outputs into your content
Generate outputs as you build your documentation, and insert them in-line with your content across pages.

✅ Add interactivity to your book
You can toggle cell visibility, include interactive outputs from Jupyter, and connect with online services like Binder.

✅ Generate a variety of outputs
This includes single- and multi-page websites, as well as PDF outputs.

✅ Build books with a simple command-line interface
You can quickly generate your books with one command, like so: jupyter-book build mybook/

These are just a few of the major changes that we’ve made. For a more complete idea of what you can do, check out the Jupyter Book documentation

Major changes

In the next few sections we’ll talk about some major changes that you may notice in Jupyter Book.

An enhanced flavor of markdown

The biggest enhancement to Jupyter Book is support for the MyST Markdown language. MyST stands for “Markedly Structured Text”, and is a flavor of markdown that implements all of the features of the Sphinx documentation engine, allowing you to write scientific publications in markdown. It draws inspiration from RMarkdown and the reStructuredText ecosystem of tools. Anything you can do in Sphinx, you can do with MyST as well.

MyST Markdown is a superset of Jupyter Markdown (AKA, CommonMark), meaning that any default markdown in a Jupyter Notebook is valid in Jupyter Book. If you’d like extra features in markdown such as citations, figures, references, etc, then you may include extra MyST Markdown syntax in your content.

For example, here’s how you can include a citation in the new Jupyter Book:

A sample citation. Here we see how you can include citation syntax in-line with your markdown, and then insert a bibliography later on in your page.

And here’s how you can include a figure:

A sample figure. Here we see how you can insert a figure with a caption into your book, and control some aspects of how the figure is displayed with options.

A smarter build system

While the old version of Jupyter Book used a combination of Python and Jekyll to build your book’s HTML, the new Jupyter Book uses Python all the way through. This means that building the HTML for your book is as simple as:

jupyter-book build mybookname/

In addition, the new build system leverages Jupyter Cache to execute notebook content only if the code is updated, and to insert the outputs from the cache at build time. This saves you time by avoiding the need to re-execute code that hasn’t been changed.

An example build process. Here the jupyter-book command-line interface is used to convert a collection of content into an HTML book.

More book output types

By leveraging Sphinx, Jupyter Book will be able to support more complex outputs than just an HTML website. For example, we are currently prototyping PDF Outputs, both via HTML as well as via LaTeX. This gives Jupyter Book more flexibility to generate the right book for your use case.

You can also run Jupyter Book on individual pages. This means that you can write single-page content (like a scientific article) entirely in Markdown.

A new stack

The biggest change under-the-hood is that Jupyter Book now uses the Sphinx documentation engine instead of Jekyll for building books. By leveraging the Sphinx ecosystem, Jupyter Book can more effectively build on top of community tools, and can contribute components back to the broader community.

Instead of being a single repository, the old Jupyter Book repository has now been separated into several modular tools. Each of these tools can be used on their own in your Sphinx documentation, and they can be coordinated together via Jupyter Book:

The MyST markdown parser for Sphinx allows you to write fully-featured Sphinx documentation in Markdown.
MyST-NB is an .ipynb parser for Sphinx that allows you to use MyST Markdown in your notebooks. It also provides tools for execution, cacheing, and variable insertion of Jupyter Notebooks in Sphinx.
The Sphinx Book Theme is a beautiful book-like theme for Sphinx, build on top of the PyData Sphinx Theme.
Jupyter Cache allows you to execute a collection of notebooks and store their outputs in a hashed database. This lets you cache your notebook’s output without including it in the .ipynb file itself.
Sphinx-Thebe converts your “static” HTML page into an interactive page with code cells that are run remotely by a Binder kernel.
Finally, Jupyter Book also supports a growing collection of Sphinx extensions, such as sphinx-copybutton, sphinx-togglebutton, sphinx-comments, and sphinx-panels.

We’ll write a more developer-focused post in the future to describe each of these components in more detail.

What next?

Jupyter Book and its related projects will continue to be developed as a part of the Executable Book Project, a community that builds open source tools for high-quality scientific publications from computational content in the Jupyter ecosystem and beyond.

If you’d like to learn more about Jupyter Book or get started building your own books, then check out the new Jupyter Book documentation. Jupyter Book is still in beta and is constantly being improved, so your feedback and contributions are always welcome.

If there are particular features you’d like to see, open an issue or give a 👍 to a pre-existing issue, and it will be bumped up on the feature request leaderboard.

Get involved

If you’d like to contribute to any of the projects listed in this post, you are highly encouraged to do so! The Executable Book Project (and thus Jupyter Book) is run as an open project that welcomes contributions from others.

We are excited about all the new features and improvements in the new Jupyter Book, and look forward to seeing the new books that the community creates with this stack!

A 2019 retrospective from the Binder Project

2020-01-15T17:48:00+00:00

2019 was a busy year for the Binder and JupyterHub projects — each saw growth in both their community and technology. Now that the year has wrapped up, it is a good time to reflect on some of the highlights from the year.

Overall, 2019 was about improving the robustness, stability, and team dynamics around the JupyterHub and Binder projects, as well as connecting these projects with other tools and services in the open source community. Here are a few things that we are most-excited about.

More people are using mybinder.org

The Binder Federation is a collection of BinderHubs accessible from mybinder.org. This deployment is run as a public service and a demonstration of BinderHub, the underlying technology of the Binder project. This deployment is run on a volunteer basis by Binder community members, and is supported through grants and donations in infrastructure from project stakeholders. In 2019, the user base of mybinder.org grew from around 70,000 users per week to around 100,000 users (a growth of nearly 40%). mybinder.org is being used for teaching classes, sharing reproducible analyses, creating interactive documentation and narratives, and much more. We’re astonished at the rapid growth of Binder-ready repositories, and we’re excited to see what the community creates next.

Weekly user sessions at mybinder.org. Here you can see a typical pattern of activity over the course of a year. There are dips in activity over the summer and winter months, reflecting reduced activity from academic institutions.

JupyterHub reaches 1.0

JupyterHub, the underlying technology that provides interactive computing sessions to multiple users, is now at 1.0 status. The JupyterHub Python application was written several years ago, and reaching 1.0 reflects the work of dozens of open source contributors over time. JupyterHub is now a robust and stable application, having been used at smaller scales (think 5–10 people running on a single VM) as well as much larger scales (think 5,000 students running Jupyter sessions for a class).

The JupyterHub logo

BinderHub is out of beta

BinderHub, the kubernetes-based technology that powers mybinder.org, also came out of Beta this year. This reflects the fact that BinderHub is a battle-hardened application that can provide a stable service over time. mybinder.org runs nearly 100,000 sessions a week, and requires minimal maintenance time from the Binder’s projects team of volunteer operators.

The BinderHub federation is launched

The Binder Project envisions a world in which technology can be used in vendor-agnostic and decentralized ways. BinderHub runs on Kubernetes, which can be deployed on a variety of cloud and local infrastructure. While the Binder team runs one BinderHub deployment at mybinder.org, our goal has always been to see other organizations running their own BinderHubs. This year, we went one step beyond this by launching the BinderHub Federation. This is a collection of research and technology organizations that combine their expertise and computational resources to power mybinder.org. When users visit mybinder.org, they are now directed to one of several BinderHub instances. This makes mybinder.org more robust, and grows the number of organizations that utilize the project’s technology for their communities. A BIG THANKS goes out to Google, OVH, GESIS, and the Turing Institute for supporting the Binder Federation.

The (rough) location of each BinderHub deployment in the mybinder.org federation

Binder connects with open science services

Another goal of Binder is to be a part of the solution to more transparent, sharable, reproducible computational work. This means plugging in to other ecosystems and projects in order to leverage the broader open science community. This year we saw a number of new connections with other services. BinderHub now supports links that point directly to Zenodo and Dataverse repositores, and we are working on a few other integrations in the coming months. This means that projects utilizing these resources will be able to share reproducible and interactive links to their work out-of-the-box.

Binder now works with Zenodo repositories!

The Binder community grows

The Binder project’s most important asset is its people — this is a collection of volunteers spread across the world and from a variety of organizations. Binder community members do a variety of things — from working on technology, to teaching others how to make their work more reproducible, to participating in community discussions, to maintaining and debugging Binder tech. There is also a “core team” of Binder members that dedicates a significant part of their time to supporting the project. In 2019, we saw several new members join the core team, as well as a general growth in the Binder community. Welcome to all of our new team members! You can find a list of our current team members here.

We welcome our first Contributor in Residence

One challenge with running large, open projects is that resources tend to be scarce. The Binder Project has no formal project funding, and must find ways to both grow its technology as well as run mybinder.org on resources that are donated from its community. One thing that often suffers as a result is the maintenance and general improvement of our open source technology. This work is often under-appreciated, difficult, and unlikely to happen with purely volunteer labor.

For this reason, the Binder project decided to apply for the CZI Essential Open Source grant series. We proposed the creation of the “Binder Contributor in Residence” position — an annual contractor position that pays a member of the Binder community to do many of the daily things that are crucial for the project’s growth. We are excited to have Georgiana Dolocan as our first contributor in residence, and look forward to where this project will go in 2020.

Many thanks to CZI for their support of the Binder and JupyterHub projects in 2020!

There are more BinderHub deployments

The Binder Project aims to create technology that is deployable anywhere so that other organizations can support their communities with Binder infrastructure. In 2019 we ran a number of training sessions for how other groups can run their own BinderHub. In particular, the Turing Institute ran several workshops that had attendees up-and-running with their own functioning BinderHubs.

Thanks to our community

As you can see, 2019 was a busy and exciting year for the Binder community. As a final note, we want to say thanks to all of you who have supported Binder in one form or another over the years. Binder is a project run by the community, for the community. It wouldn’t be possible without all of your hard work and friendly faces, thanks! We look forward to what’s coming next in 2020!

The International Binder Federation

2019-07-01T09:11:00+00:00

About two years ago, the Binder project evolved into the community led project that it is today. The deployment at mybinder.org was upgraded to use
BinderHub, a scalable open-source web application that runs on Kubernetes and provides free, sharable, interactive computing environments to people
all around the world.

In the ensuing years, the Binder community has grown considerably.
Now people use the public deployment at mybinder.org around 100,000 times each week, and there are around 8,000 unique repositories compatible with Binder. Binder links now work with multiple repository providers, such as GitHub, GitLab, BitBucket, and even Zenodo! This means that providing enough compute power for everyone is a challenge.

This is why today we are happy to announce that mybinder.org is now backed by two clusters hosted by two different cloud providers: Google Cloud and OVH. This is the beginning of the International Binder Federation.

How did we get here? Alongside mybinder.org’s growth we’ve seen growth in another part of the Binder ecosystem: people deploying a BinderHub for their own groups. In the last year, we have seen BinderHubs deployed for large-scale earth analytics with the Pangeo project, for communities of best-practices in open science with The Turing Way, and for specific domains such as the social sciences like GESIS.

As more BinderHubs are deployed, we realized that there was an opportunity to leverage the strengths and resources of the community to improve the large, public BinderHub deployment at mybinder.org. Instead of a single BinderHub run by the Binder team, we could build a network of BinderHubs that shares the load and keeps mybinder.org stable and quick.

OVH Joins the mybinder.org Federation

Today, we are thrilled to announce that the Binder Project now has a world-wide federation of BinderHubs powering mybinder.org. We’ve partnered with OVH, a cloud hosting company based in Europe that is supportive of open projects such as Jupyter and Binder.

Through the partnership with OVH, all traffic to mybinder.org will now be split between two BinderHubs - one run by the Binder team, and another run by a team of open-source advocates at OVH. They have generously offered their resources and computing time to allow Binder to serve the scientific and educational communities.

The mybinder.org federation currently has two BinderHubs, but this network can (and will!) grow as more groups offer to connect their own BinderHubs to the network.

What does this mean?

So what has changed for you, the user? Probably not much. The
biggest difference you’ll notice is that landing at mybinder.org
will now redirect you to one of two places:

gke.mybinder.org is the BinderHub hosted on the Google Cloud Platform
ovh.mybinder.org is the BinderHub hosted on the OVH platform in France.

Other than this, your experience should be the same. You might even notice an improvement in speed and load times because the BinderHub you’re using has a little bit less traffic on it 😀.

As always, we are pushing this out as soon as we think it is useful. You can help us to scale this model and make it rock solid by reporting weird things you notice. Expect tweaks over the next few weeks based on feedback from users. Let us know about the things you like, dislike or have questions about at https://discourse.jupyter.org/t/the-binder-federation/1286.

Why is this a big deal?

We think that having a federation of BinderHubs behind mybinder.org is pretty cool, for a few different reasons. First, it demonstrates the dedication that the Binder community has towards building tools that anybody can deploy — we certainly don’t want to be the only ones running a BinderHub, and having other BinderHubs behind mybinder.org is a great example of this. Second, a network of BinderHubs for mybinder.org means that we can eventually do some clever things like use geolocation to distribute users, which should improve the performance that you all experience. Third, having fewer users per BinderHub means that we can optimize the resources available to each hub — resulting in improvements in speed and stability. Finally, having a federation of BinderHubs makes the mybinder.org service significantly more robust, and less-dependent on a single team, deployment, platform, and funding source. We are now more confident than ever that mybinder.org will continue to be available as a stable, free, public service that keeps growing.

What’s next?

Now that we’ve reached N=2 BinderHubs powering mybinder.org,
it is straightforward for us to grow this network to N=3 and beyond. Over the summer we will continue our work on approaching universities, research councils, and cloud hosting companies.

If you are interested in helping out: we’d love to see other community members come forward to offer their time or resources to provide more nodes in the international BinderHub federation. If you’re interested in doing so, please open an issue in the JupyterHub team compass repository
to discuss the possibilities of working together!

We’re excited about the ability for the Binder community continuing
to grow, and to build more tools for distributed, community-run
infrastructure for open science and education. This is all possible
because of the hard work of many people in the community, so a big
thank you to those who spend their time working on open tools in
the Jupyter and Binder ecosystems. We’re excited to see what comes
next!

Binder + Zenodo: A how-to guide

2019-06-21T13:46:00+00:00

Interactive and reproducible repositories powered by Zenodo and Binder.

When the Binder project was first launched, we imagined a world in which scientific scholarship and reproducibility could be carried out by the community using a fully-open stack of technology. We’re happy to say that this is now possible!

Zenodo DOIs now work with BinderHub

The BinderHub team recently added in support for building Binder links that point to Zenodo repositories. Zenodo is a general purpose open-access repository hosted by CERN that allows researchers to archive and apply a DOI to information that they put up on the web.

Zenodo has the ability to archive GitHub repositories, which means that you can archive the code, data, or reports that underly a scientific analysis and assign it a unique, citeable identifier. Now that BinderHub knows how to resolve a Zenodo identifier, you’ll be able to share Binder links that point to Zenodo and provide interactive access to your repository, letting readers reproduce results and interact with your analyses!

Here’s a quick primer for how to do this:

Step 1: Create a Zenodo account

First off you’ll need to create an account on Zenodo. You can
do so using a number of different log-in options.

Step 2: Create your Binder-ready repository on GitHub

Next, you should create your Binder-ready repository on GitHub. Binder uses pre-existing best practices in data science in order to infer and build the environment needed for your repository.

To make a repository Binder-ready, follow the instructions in the Binder docs.
Briefly, what you need to do is add the configuration files that define the environment needed to run your code. Once those files are in place, and you’ve added an analysis script (a Jupyter or R Notebook) that actually runs your code and displays the results, your repository is ready to build with Binder.

Step 3: Make sure your repository is ready to be published!

Once you create a DOI for your repository, it will be frozen in time — you won’t be able to easily update it. So double check that the repository builds properly with Binder and runs the way that you’d expect it to.

Make sure to launch a Binder from your repository and run the analyses you’d like others to run. If they produce the expected result from within a Binder session, then they’ll continue to do so for others (assuming you have pinned your versions and followed other best practices in reproducibility).

Step 4: Create a Zenodo DOI for your repository

Now that your repository is ready, you’ll connect Zenodo with GitHub to create a DOI for your repository. Remember that this will be unique to the current state of the repo — future changes to this repository won’t be reflected in the DOI.

We recommend following the GitHub Citable Code Guide which provides some best-practices for creating your Zenodo DOI for a GitHub repository. Click the image below to be taken to this (excellent) guide.

The GitHub Citable Code guide.

Once you’re done, you should have a Zenodo DOI badge
like the one below:

A Zenodo DOI badge

Step 5: Create a Binder link for your Zenodo DOI

Finally, use your Zenodo DOI to create a Binder link that allows others to interact with and replicate your results. You can create a Binder link for your Zenodo record by heading to https://mybinder.org and filling in the form:

Building a Binder link for your Zenodo archive with the Binder UI.

This will give you a link you can share with others as well as the Markdown and reStructured text snippets for creating a badge.

The link’s structure should look like this:

https://mybinder.org/v2/zenodo/<zenodo-DOI>

For example, if your Zenodo DOI is 10.5281/zenodo.3242074 (corresponding to this zenodo repository), the Binder link for it would be:

https://mybinder.org/v2/zenodo/10.5281/zenodo.3242074/

You can even pair this Binder link with your Zenodo DOI badge that
we showed above!

The “launch binder” button contains a Binder link for your Zenodo archive. Clicking will launch a Binder session.

And that’s it! You now have an archived version of your analysis with a unique identifier. This identifier can be used in conjunction with BinderHub to allow readers to interact with your code and results!

Last minute update 🎉

A few hours before publishing this post we merged a contribution from Tom Morrell who works at CalTech’s library that allows you to launch records from CalTech’s Data Repository as well! For example a notebook to analyze traffic to the archive itself: https://mybinder.org/v2/zenodo/10.22002/d1.1250. You should also check out a quick response to this post from Lorena Barba, who describes her group’s approach to creating reproducible, citable bundles for figures in papers, and how Binder+Zenodo DOIs might fit into that workflow!

What’s next?

We are close to closing the loop of fully reproducible computational environments for scientific publication. We’re excited to see journals begin to integrate these workflows with their own publishing pipelines. For example, the Neurolibre project is deploying their own BinderHub and using it alongside their reviewing and archiving process in order to provide more rich
interaction with submitted material.

Each type of repository needs a small amount of custom work to be integrated with Binder. We started with Zenodo because it is well known,
general purpose and integrated with GitHub already. If there is an archive you’d like to see integrated please do stop by this repository and open a new issue or contribute the code to do so directly.

If you’re working with a publisher and are interested in this
please reach out! The Binder community would love to work with you in deploying these open tools to make your published work more open and accessible. Whether it is big or small, we hope that these workflows can make an impact across the publishing landscape, and we’re looking forward to seeing what people do next!

Introducing repo2docker

2018-12-14T18:24:00+00:00

The Binder Project’s repo2docker tool gives data scientists the benefits of containerization technology without needing to learn Docker itself. To make your repository compatible with repo2docker, you only need to add text files that are already present in many repositories. This means that you get the benefits of containerization, a powerful and complex ecosystem, without having to change your workflow.

repo2docker is a lightweight command-line tool written in Python that takes a path or URL to a git repository and creates a suitable docker image for it. To achieve this it follows the steps that a human would take to do so. The steps are:

Inspect the repository for common “configuration” files (like requirements.txt),
From these well-known files infer the Docker commands to run; and
Build a Docker image.

It has a few more tricks up its sleeve, such as automatically installing RStudio for you when it detects that you are using R. Once the image has been built, a Docker container is created and executed, giving you access to the environment in which the repository author wanted the code to be executed. To achieve this, one needs access to two things: repo2docker and a docker daemon (they do not necessarily have to have docker installed on their local computer).

The JupyterHub team just released v0.7 of repo2docker, so we decided to spend a bit of time explaining what it’s all about.

An example repo2docker workflow. In this case, repo2docker is invoked locally. repo2docker is passed a URL to a git repository (https://github.com/norvig/pytudes). It then clones the repository, discovers configuration files in the repo (in this case, requirements.txt), builds a Docker image with this environment installed, and opens a local Jupyter server to explore and run the contents of the repo.

The guiding principles behind repo2docker

repo2docker is meant to be as lightweight and common-sense as possible. The driving principles behind repo2docker are as follows:

Leverage pre-existing workflows in data science as much as possible. This means using standard configuration files (like requirements.txt) instead of requiring people to learn new configuration patterns.
The shareable unit is a repository or directory containing human-readable files. Not a single file (like a notebook) nor a binary blob (like a built docker image). This means that humans can inspect and extend other repositories meant for repo2docker, and that they can manually do what repo2docker does automatically. No black box.
Be workflow agnostic. repo2docker supports many languages and user interfaces, it can run arbitrary shell scripts that are baked into the image, or it can trigger a script to be run each time a person runs the Docker image.
Be extensible and composable. repo2docker should allow for multiple languages, tools, or workflows to be defined in a single GitHub repository. It should also be relatively easy to extend to support new use-cases.
Enable deterministic outputs. We want repo2docker to make it possible for authors to generate the exact same environment from their repository every time, provided that they follow best-practices in computational methods (like providing specific version numbers for packages). repo2docker can build a specific commit, tag, or branch of a repository, which allows for an image to be deterministically built.

How can repo2docker be used?

Over the last 18 months, we have been using repo2docker in production to automatically generate images that run repositories for mybinder.org.
It is used to build around 1000 unique repositories every week. The core functionality has proven itself and is considered production ready.

Over the last year, we’ve seen a few major use-cases come out of repo2docker:

First, it can be used as a part of production systems like BinderHub. BinderHub automatically uses repo2docker to build images that run a user’s environment, and lets them share links that let others interact with the image.

Second, repo2docker can be used to build an image for use with a JupyterHub. For example, teachers have used repo2docker to convert their GitHub repository with course materials into a runnable Docker image that students access via a shared jupyterhub in the cloud.

Finally, repo2docker has been used by individuals who wish to build reproducible images from their local work. repo2docker can optionally run a Jupyter server from within the built image, which makes it possible to verify the results of analyses in an environment that was built solely from the configuration files present in the repository.

What next?

We think that repo2docker serves as a useful tool for the community and that it is an important part of the large reproducible scientific software stack. It gives data scientists the benefits of containerization technology without needing to learn a new tool like Docker. It achieves this by being a lightweight command-line tool written in Python that automates the creation of the environment in which the authors of a piece of software wanted it to be executed.

We’d love to see the repo2docker community grow, and for more
languages, interfaces, use-cases, and workflows to be supported
with repo2docker’s build pack system. Let us know what you think!

repo2docker is primarily maintained by the JupyterHub and Binder teams. If you’d like to get involved with the community or want to learn
more about the tool, reach out! Check out these links for more information:

Note*: some folks might be wondering why we developed repo2docker instead of contributing to a pre-existing containerization tool such as the excellent* source2image project. We take the decision to create new open-source tech very seriously, and wrote a blog post about our decision to do-so in this case: http://words.yuvi.in/post/why-not-s2i/

Announcing the JupyterHub Helm Chart v0.5

2017-12-20T16:24:00+00:00

JupyterHub makes it possible to serve Jupyter instances to multiple users. The JupyterHub Helm Chart makes it possible to run this setup on kubernetes, making JupyterHub more scalable, stable, and flexible.

We, the JupyterHub team, are proud to announce the next version of the JupyterHub Helm Chart: version 0.5. This post describes a bit of what’s new in this release. We’ve nicknamed the releases of the JupyterHub Helm Chart after famous cricketers, in this case world-class bowler Hamid Hassan*.

tl;dr: The release bumps JupyterHub to 0.8, adds better HTTPS support, and improves scalability to ~4,000 simultaneous users. See the Helm Chart Changelog for more information.

New Features

The following major features have been added to v0.5:

JupyterHub 0.8

Version 0.8 of JupyterHub was released earlier this year. It is full of new features, many of which directly benefit the Kubernetes deployment of JupyterHub. Below is a list of relevant points along with the relevant sections of the Helm Chart configuration:

Lots of performance improvements. We now know we can handle up to 4k active users.
Limit the number of users who can try to launch the hub at once. This can be tuned to avoid crashes when hundreds of users try to launch at the same time. It gives them a friendly error message and asks them to try later. See hub.concurrentSpawnLimit.
Limit the number of simultaneous active users . The Active Server limit can be used to limit the total number of active users that can use the hub at any given time. This allows admins to control the size of their clusters more effectively. See hub.activeServerLimit.
Memory limits & guarantees can now contain fractional units. So you can say 0.5G instead of having to use 512M.
No more ‘too many redirects’ errors at scale. This fixes an annoying race condition causing users to get stuck in a redirect loop when starting their servers.

Easier HTTPS

Version 0.5 of the helm chart makes it easier for admins to set up HTTPS for their users with Let’s Encrypt. Users often access a JupyterHub instance from a public URL. To avoid nefarious behavior and increase security, using HTTPS is important. You can now choose to use Let’s Encrypt or a valid HTTPS certificate and key. You can also use your own HTTPS certificates & keys rather than using Let’s Encrypt. You can find the new instructions here.

More authenticators

Authenticators allow you to control who has access to your JupyterHub. The following new authentication providers have been added in 0.5:

You can now also set up a whitelist of usernames that have access to the hub (in addition to other authenticators in use). Do so by adding to the list in auth.whitelist.users.

Hub Services support

Services let you connect your JupyerHub to other web services (for example, in mybinder.org). You can now add external JupyterHub Services by adding them to hub.services. Note that you are still responsible for actually running the service somewhere (perhaps as a deployment object in Kubernetes).

More customization with `jupyterhub_config.py`

Sometimes it is useful to be able to run arbitrary extra code when setting up your deployment. You can put extra snippets of jupyterhub_config.py configuration in hub.extraConfig. Now you can also add extra environment variables to the hub in hub.extraEnv and extra configmap items via hub.extraConfigMap. This makes it cleaner to customize the hub’s configuration in ways that are not yet possible with config.yaml. You can find more information in the documentation.

More customization options for user server environments

More options have been added under singleuser to help you customize the environment that the user session is spawned in. You can…

Change the uid / gid of the user with singleuser.uid and singleuser.fsGid
Mount extra volumes with singleuser.storage.extraVolumes & singleuser.storage.extraVolumeMounts
Provide extra environment variables with singleuser.extraEnv.

More information

For more information about the JupyterHub Helm Chart, and the JupyterHub ecosystem more broadly, see the following links:

The JupyterHub documentation
The JupyterHub development repository
The JupyterHub Helm Chart development repository
The Zero to JupyterHub guide to deploying JupyterHub on Kubernetes

*Hamid Hassan is a fast bowler who currently plays for the Afghanistan National Cricket Team. With nicknames ranging from “Afghanistan’s David Beckham” to “Rambo”, he is considered by many to be Afghanistan’s first Cricket Superhero. Currently known for fast (145km/h+) deliveries, cartwheeling celebrations, war painted face and having had to flee Afghanistan as a child to escape from war. He says he plays because “We are ambassadors for our country and we want to show the world that Afghanistan is not like people recognize it by terrorists and these things. We want them to know that we have a lot of talent as well.”

Binder 2.0, a Tech Guide

2017-11-30T16:01:00+00:00

Authors: The Binder project is comprised of many individuals within and outside of the core Jupyter team. A list of members that contributed to this post is at the end of this article.

Note: this post focuses more on technical changes in the Binder 2.0 reboot. For a post about user-facing features and future plans, see this eLife blog post.

We are undergoing a dramatic increase in the complexity of techniques for analyzing data, doing scientific research, and sharing our work with others. In early 2016, the Binder project was announced, attempting to connect these three components. A blogpost in eLife described a vision where scientists could specify dependencies along with a collection of Jupyter notebooks. Binder builds a Docker image from these dependencies, and provides a URL where any user in the world can instantly recreate this environment.

Want to see it in action? Click the button below.

With this post we are proud to announce the next version of Binder. It aims to be more modular, more flexible, more stable, faster, and more extensible than its predecessor. Powering this version of Binder is a collection of tools in the Jupyter ecosystem. Since being released, the Binder project has learned many things about implementing fast, flexible online deployments. In addition, its vision has expanded to include not only Jupyter notebooks, but many other computational workflows. You can access an open beta version of this deployment here:

mybinder.org

You can find a list of sample repositories to learn how to create “Binder”-ready repositories here:

github.com/binder-examples

You can also see what the Binder community has been up to in creating their own repositories by checking the GitHub Binder topic:

https://github.com/topics/binder

Give it a shot, build some repositories, and importantly, tell us what could be improved on our GitHub repo. Below we’ll describe a bit about what’s new.

The new Binder UI. Users input a URL to a git repository (or specify a specific branch/tag/commit). Upon clicking “launch”, you will be directed to a live environment where you can interact with the code.

What’s new?

First off we’ll describe how the experience will change for users. The short answer is: not much. The goal of Binder is still enabling you to intantly create interactive and shareable repositories. We’ve completely rebuilt the backend of Binder, but we’ve made minimal changes to the front-end user experience.

The biggest difference you should notice is that Binder is both faster and more stable. You’ll still be able to generate Binder links from a git URL from a single web-page. However, there are a few key differences:

New Default Environment

Old versions of Binder were based off of a Docker image that contained a fairly heavy computational environment. The new Binder deployment makes minimal assumptions about what environment you want installed, by default the only thing that will be installed is the Jupyter Notebook and Python 3. This means you’ll need to be more expressive in the dependencies you include in your dependency files. For example, if you want numpy or matplotlib, you should specify them in a requirements.txt or environment.yml file. Since you’re explicitly listing your requirements it makes reproducing your work more reliable, and allows the Binder infrastructure to change more freely without breaking your repository code.

New URL structure

The new URL structure for Binder follows the following convention:

https://mybinder.org/v2/gh/<org-name>/<repo-name>/<branch|tag|hash-name>?filepath=<path-to-file>

For example, below is the URL for a basic Binder-ready Python 3 repository, it includes basic information about the repository:

https://mybinder.org/v2/gh/binder-examples/requirements/master

You can also specify parameters that do things like point users to a particular file or initialize a user-interface. For example, the following URL starts JupyterLab once users click the link:

https://mybinder.org/v2/gh/binder-examples/jupyterlab/master?urlpath=lab

In each case, note the gh at the very beginning — this specifies that the git URL exists on github.com. It is possible to build new URL parsers for other online repositories such as BitBucket, osf.io, or any other provider. We are currently focusing on Git and GitHub, but nothing prevents Binder from being compatible with other kinds of content providers. Shortly before this blog post we added support for arbitrary git URLs to binderhub, so watch this space.

Specify a specific branch / tag / commit

Also notice that in the URL above you can specify a branch, tag, or commit hash for the Binder image. This allows you to ensure that a Binder image will always remain the same (if you specify package versions properly). This is a crucial step for reproducibility and maintaining consistency in how users experience the files in your repository.

Notice that in the URL above you can specify a commit hash or git tag for the Binder image. This hash is unique to the state of the code at the moment that the commit was made, ensuring that Binder can rebuild the exact same environment any time. Note that if authors don’t want to guarantee the same reproducible environment, they can specify a branch and BinderHub will resolve it to the latest commit hash before building the environment.

Binder auto-building

When a git repository is launched, Binder will now check whether an image has already been built for that repository at the same commit hash. If it has, then Binder will skip the building process and take you straight to a JupyterHub instance that serves this image.

If the image hasn’t been built, then it will automatically be generated before sending the user to JupyterHub. The only difference will be the amount of time it takes before entering the JupyterHub environment. This means that authors no longer need to explicitly build their Binder images when they update a branch. The next time someone clicks a Binder link, it will happen automatically. If you don’t want this behavior, be sure to point Binder to a specific tag or commit hash, rather than a branch name or tag. For example, here’s a Binder URL that will always point to the same commit hash:

https://mybinder.org/v2/gh/wildtreetech/explore-open-data/binder20-elife

While this URL points to a branch, and will thus be re-built each time a new commit is made to that branch:

https://mybinder.org/v2/gh/wildtreetech/explore-open-data/master

More options for dependency files

Users often want to specify a computational environment that is more complex than a simple list of Python requirements. While this is possible by specifying a Dockerfile, it’s often an overly-complicated solution to this problem. Binder now uses repo2docker to build a Docker image from your repository. This makes it possible to specify a more complex environment with text files. For example, you can use an apt.txt file to install packages with apt-get, or use a file called postBuild to define shell commands that are run before generating the Docker image (e.g. for downloading some data or running scripts). See the repo2docker documentation for a list of files that are supported with Binder.

For a selection of examples that show off how to specify dependencies take a look at the example gallery: https://github.com/binder-examples

More user interfaces

The JupyterLab interface running on Binder. You can access the JupyterLab demo repository at ``mybinder.org/v2/gh/binder-examples/jupyterlab/master?urlpath=lab

The previous iteration of Binder only supported the classic Jupyter Notebook user interface, while the new deployment will additionally support RStudio and JupyterLab. Because of the extra build configuration files specified above, you can also utilize more tools in the Jupyter widgets ecosystem, such as the RISE plugin for interactive presentations or the appmode plugin to generate interactive apps from your repository. We also welcome contributions to add support for other user interfaces.

More online repository providers

While GitHub is a fantastic repository of open-source code, it’s not the only repository. The new Binder deployment makes it straightforward to adding support for new sources of code (for example, GitLab, the OSF, or even non-git codebases). Currently GitHub is the only supported source for code, but we welcome contributions enabling support for new sources.

We’re excited about this next step in Binder’s development, and hopeful that we can build a community around this powerful set of tools. Don’t hesitate to open an issue or pull request on our GitHub repository, or to reach out via our Gitter channel. We look forward to seeing what comes next, and to continue enabling reproducible and open workflows in data science and research.

For developers

The next few sections are meant for developers interested in deploying their own Binder, or for those interested in the technical details behind the new deployment.

Tech components

The three main technical components behind the new Binder backend are:

BinderHub, currently on display at mybinder.org and contained in the binderhub repository.
repo2docker, a tool that converts a code repository into a Docker image with an environment specified via dependency files (e.g., requirements.txt).
JupyterHub, which hosts user instances with a server in the cloud. We use a distribution of JupyterHub that runs on top of Kubernetes.

For more information on the infrastructure behind Binder, see the documentation.

A prototype of RStudio running in a Binder. This is currently support with a Dockerfile, and we are working on supporting R build files natively. You can access this repository at: <https://mybinder.org/v2/gh/binder-examples/dockerfile-rstudio/master>

Kubernetes

Binder now also heavily relies on Kubernetes for scaling our image building service and the JupyterHub. Kubernetes is massively scalable and has a strong community of developers behind it. Moreover, Kubernetes is cloud-agnostic. It can be run on Google Cloud, Microsoft Azure, and AWS among others, as well as on your own bare metal hardware if needed. Because BinderHub is built to run on top of Kubernetes, you can deploy Binder off of any of these resources as well (see below).

Deploying your own Binder server

While mybinder.org will continue to exist as a public service, we hope to see new Binder deployments for many different use cases in the wild. One of our primary goals is to make it easier for users to deploy their own Binder servers. This is relatively straightforward by following the instructions on the BinderHub documentation, which are currently under active development to make ongoing improvements as the Kubernetes technology evolves. We’re continuously updating these steps to make them as clear as possible, so please don’t hesitate to open an issue or a pull request on our github repository and make suggestions.

We would love to see others deploy their own BinderHub servers, either for their own communities, or as part of a federated public service of BinderHubs.

Future development

This is the just the beginning of new features and improvements to Binder. We’re working hard to grow an open-source community around these tools, and we encourage issues, comments, and PRs on the BinderHub, repo2docker, and JupyterHub repositories. We look forward to growing the Binder ecosystem, and we’re excited to see all of the Binders that people design.

Acknowledgements (alphabetical order)

C. Titus Brown (UC Davis), Matthias Bussonnier (UC Berkeley), Jessica Forde (UC Berkeley), Brian Granger (Cal Poly), Tim Head (Wild Tree Tech), Chris Holdgraf (UC Berkeley), Andrew Osheroff (Google), Naomi Penfold (eLife Sciences), M Pacer (UC Berkeley), Yuvi Panda (UC Berkeley), Fernando Perez (UC Berkeley), Min Ragan-Kelley (Simula Research Laboratory), and Carol Willing (Cal Poly). The Binder project is currently being funded from a grant from the Moore Foundation.

Jupyter Blog - Chris Holdgraf

How we combine multiple repositories into one website at jupyterbook.org

Why is this useful?

Proxying sub-sites with Netlify rewrites

Shared configuration with extends

One gotcha: BASE_URL for asset paths

internal_domains for cross-site navigation

Want to do this too?

Acknowledgements

Announcing our first Jupyter Community Funded Proposals

Your Ideas, Our Support: Jupyter Community Call For Funding Proposals

The call for proposals is open through Sunday, October 5th, 2025.

Acknowledgements

Simplifying and speeding up Binder builds with BuildKit

Authors and acknowledgements

Footnotes

CZI awards three EOSS grants to Jupyter community members

Accessibility in Jupyter

Interactive documentation

Community strategic support for JupyterHub

Announcing the new Jupyter Book

What does the new Jupyter Book do?

Major changes

An enhanced flavor of markdown

A smarter build system

More book output types

A new stack

What next?

Get involved

A 2019 retrospective from the Binder Project

More people are using mybinder.org

JupyterHub reaches 1.0

BinderHub is out of beta

The BinderHub federation is launched

Binder connects with open science services

The Binder community grows

We welcome our first Contributor in Residence

There are more BinderHub deployments

Thanks to our community

The International Binder Federation

OVH Joins the mybinder.org Federation

What does this mean?

Why is this a big deal?

What’s next?

Binder + Zenodo: A how-to guide

Step 1: Create a Zenodo account

Step 2: Create your Binder-ready repository on GitHub

Step 3: Make sure your repository is ready to be published!

Step 4: Create a Zenodo DOI for your repository

Step 5: Create a Binder link for your Zenodo DOI

Last minute update 🎉

What’s next?

Introducing repo2docker

The guiding principles behind repo2docker

How can repo2docker be used?

What next?

Announcing the JupyterHub Helm Chart v0.5

New Features

JupyterHub 0.8

Easier HTTPS

More authenticators

Hub Services support

More customization with jupyterhub_config.py

More customization options for user server environments

More information

Binder 2.0, a Tech Guide

What’s new?

New Default Environment

New URL structure

Specify a specific branch / tag / commit

Binder auto-building

More options for dependency files

More user interfaces

More online repository providers

For developers

Tech components

Kubernetes

Deploying your own Binder server

Future development

Acknowledgements (alphabetical order)

Shared configuration with `extends`

One gotcha: `BASE_URL` for asset paths

`internal_domains` for cross-site navigation

More customization with `jupyterhub_config.py`