# Use published Docker image for Binder

**URL:** <https://discourse.jupyter.org/t/use-published-docker-image-for-binder/10333>\
**Category:** Binder\
**Tags:** docker\
**Created:** [August 10, 2021, 7:54pm UTC](https://discourse.jupyter.org/t/use-published-docker-image-for-binder/10333 "2021-08-10T19:54:22Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![fortierq](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/fortierq/32/4760_2.png) [@fortierq](https://discourse.jupyter.org/u/fortierq)\
**Post date:** [August 10, 2021, 7:54pm UTC](https://discourse.jupyter.org/t/use-published-docker-image-for-binder/10333/1 "2021-08-10T19:54:22Z")

</div>

So far I use a Dockerfile in my GitHub repo to define my Binder environment. I wonder if it would be better to build & publish (on Dockerhub) the corresponding image, so that Binder can pull it without having to build it?

---

<div class="post-metadata">

**Author:** ![sgibson91](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/sgibson91/32/487_2.png) [@sgibson91](https://discourse.jupyter.org/u/sgibson91)\
**Post date:** [August 10, 2021, 9:07pm UTC](https://discourse.jupyter.org/t/use-published-docker-image-for-binder/10333/2 "2021-08-10T21:07:33Z")

</div>

I would recommend that you use this GitHub Action to achieve this [GitHub - jupyterhub/repo2docker-action: GitHub Action for repo2docker](https://github.com/jupyterhub/repo2docker-action)

---

<div class="post-metadata">

**Author:** ![rabernat](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/rabernat/32/192_2.png) [@rabernat](https://discourse.jupyter.org/u/rabernat)\
**Post date:** [September 7, 2021, 1:21pm UTC](https://discourse.jupyter.org/t/use-published-docker-image-for-binder/10333/3 "2021-09-07T13:21:19Z")

</div>

Noting that this issue was also raised in the binderhub repo:

> <https://github.com/jupyterhub/binderhub/issues/1298>
>
> \### Proposed change
> 
> 
> In Pangeo, we use CI to build complex docker images wit…h our full stack in https://github.com/pangeo-data/pangeo-docker-images. These images are used directly in various Pangeo JupyterHubs.
> 
> We also want to use the same images in binder. We nearly always use use the \[nbgitpuller trick\](https://jupyterhub.github.io/nbgitpuller/link) to use separate repos for the binder env and contents. Currently this requires making a "passthrough" repo with a single-line Dockerfile pointing at the desired image on Dockerhub, e.g.: \<https://github.com/pangeo-gallery/default-binder/blob/master/binder/Dockerfile\>
> 
> Maintaining this "passthrough" repo is an extra step that leads to unnecessary complexity and also wastes binder resources rebuilding docker containers that are unchanged from the dockerhub version.
> 
> \*\*I would love to have an option to launch a binder directly from a dockerhub (or other container registry) image, completely bypassing repo2docker.\*\*
> 
> \### Alternative options
> 
> 
> Just keep doing what we are doing now, which works fine but requires additional complexity.
> 
> \### Who would use this feature?
> 
> 
> \[Pangeo Gallery\](http://gallery.pangeo.io/) and the entire Pangeo project would use this feature heavily. More generally, this feature would help bridge the gap between cloud-based JupyterHubs using pre-built docker images and Binders, improving interoperability between environments. \_It would make it trivial to launch a binder with an identical environment to a cloud-based JupyterHub\_, without requiring users to mess around with Dockerfiles. 
> 
> \### (Optional): Suggest a solution
> 
> 
> I don't know enough about how binderhub works to propose an implementation.

I’m not sure it is fully solved by the repo2docker GitHub action. That solution still requires a “passthrough” one-liner binder Dockerfile (i.e. `FROM myorg/myimage:latest`). What @fortierq is asking for is the same thing I asked for in that issue: **BinderHub directly launching a container from dockerhub, rather than its own private container inventory**.

Also raised here:

> <https://github.com/jupyterhub/mybinder.org-deploy/issues/1474#issuecomment-649769488>
>
> In a recent conversation on gitter @betatim and I brainstormed some ideas about …how we could support "default environments" better. E.g., an environment that users don't have control over, but that they can use in combination with their files. 
> 
> Here are a few steps that we could take - sharing them here in case others have thoughts/comments, and so we don't forget :-)
> 
> 1. ~Create a repository that we think has an environment that covers 90% of "I just want it to work, and fast" use-cases~
> - Decided this probably wasn't a good idea from a maintenance perspective, and we should probably instead use \`docker-stacks\` image, or something another org maintains like the kaggle image.
> 2. Document \`nbgitpuller\` functionality more cleanly, recommending that people use this repository as a default
> 3. Add a form to do this at the \`nbgitpuller\` docs (or the Binder docs?) semi-automatically and advertise it / document it (see https://github.com/jupyterhub/nbgitpuller/issues/125 for reference)
> 4. Wait and see how people use these steps, collect some data about it
> 5. Explore adding a "default environment" to BinderHub (or to mybinder.org), decide if it's a good idea
> 6. Explore adding a short-hand for the \`nbgitpuller\` pattern we documented in 2, decide if it's a good idea

---

<div class="post-metadata">

**Author:** ![cgranade](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/cgranade/32/5154_2.png) [@cgranade](https://discourse.jupyter.org/u/cgranade)\
**Post date:** [September 7, 2021, 8:21pm UTC](https://discourse.jupyter.org/t/use-published-docker-image-for-binder/10333/4 "2021-09-07T20:21:01Z")

</div>

In case it’s helpful, I was able to partially workaround the issue somewhat by using a GitHub Actions workflow to create a new commit on a special branch every time a new cached image is built ([https://github.com/microsoft/Quantum/blob/8118f183e5ae7efed823c4ef20f747f7666ce69f/.github/workflows/prebuild-docker.yml](https://github.com/microsoft/Quantum/blob/8118f183e5ae7efed823c4ef20f747f7666ce69f/.github/workflows/prebuild-docker.yml)). It’s not quite directly launching from a given DockerHub image, but it at least allows for prebuilding from a GitHub Actions workflow.