# BinderHub for HPC

**URL:** <https://discourse.jupyter.org/t/binderhub-for-hpc/143>\
**Category:** BinderHub\
**Created:** [November 8, 2018, 11:24pm UTC](https://discourse.jupyter.org/t/binderhub-for-hpc/143 "2018-11-08T23:24:51Z")\
**Posts on this page:** 1\
**Showing post:** 19

<div class="post-metadata">

**Author:** ![manics](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/manics/32/85_2.png) [@manics](https://discourse.jupyter.org/u/manics)\
**Post date:** [August 17, 2020, 5:00pm UTC](https://discourse.jupyter.org/t/binderhub-for-hpc/143/19 "2020-08-17T17:00:28Z")

</div>

In addition to what @betatim said you might find this forum thread interesting:

> [@Brainstorming: Repo2Docker Action-\> VM on GCP, AWS, Azure?](https://discourse.jupyter.org/t/brainstorming-repo2docker-action-vm-on-gcp-aws-azure/5345):
>
> Today we launched an official [repo2docker GitHub Action](https://github.com/jupyterhub/repo2docker-action) that makes it even easier for people to leverage the power of [repo2docker](https://github.com/jupyter/repo2docker) in their workflows. One problem I have been thinking about solving is the desire for folks to quickly launch a ready-to-go Jupyter Server with dependencies loaded (via repo2docker) on the compute and cloud of their choice, which is very useful if you want specialized compute like GPU, or a high memory/CPU instance and for whatever reason [mybinder.org](http://mybinder.org) doesn’t suit you…

I think it’s also worth stepping back and asking “What is your ultimate goal?”, as this may affect whether modifying BinderHub is the right choice, or whether we’re looking for a new application inspired by BinderHub but with much bigger aims.

Do you want a way to dynamically spin up and destroy environments with automatic installation of dependencies? Are these environments conda environments, containers, VMs, or something else? Does it have to be fully automated, or is it ok to give the user a blank environment and tell them to run `repo2something` to install some dependencies?

Two of the big advantages of binderhub are it requires very little knowledge on the part of the user to obtain an environment where they can run stuff, and its reproduciblity. Is this what HPC users want, or are the limitations of a fixed disposable environment likely to be frustrating given they probably have above average coding skills?

Edit: Another interesting thread:

> [@Better security isolation mechanisms for untrusted users](https://discourse.jupyter.org/t/better-security-isolation-mechanisms-for-untrusted-users/4245/):
>
> Hello! To follow up with this issue: [https://github.com/jupyterhub/zero-to-jupyterhub-k8s/issues/1615](https://github.com/jupyterhub/zero-to-jupyterhub-k8s/issues/1615) I’m opening this thread to centralize information about how JupyterHub on k8s could be made more secure in scenarios where users are considered fully untrusted in the threat model. Currently we have multiple potential solutions that yet have to mature: [Kata Containers (used in production, but still maturing)](https://katacontainers.io/)[gVisor (experimental)](https://gvisor.dev/) unprivileged kubernetes: [usernetes](https://github.com/rootless-containers/usernetes) and [conference talk video](https://archive.fosdem.org/2019/schedule/event/containers_k8s_rootless/) …

---

_[View the full topic](https://discourse.jupyter.org/t/binderhub-for-hpc/143)._