# Using xeus-cling kernel in jupyterhub running on kubernetes

**URL:** <https://discourse.jupyter.org/t/using-xeus-cling-kernel-in-jupyterhub-running-on-kubernetes/10852>\
**Category:** Kernels\
**Created:** [September 18, 2021, 12:18am UTC](https://discourse.jupyter.org/t/using-xeus-cling-kernel-in-jupyterhub-running-on-kubernetes/10852 "2021-09-18T00:18:06Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![jokuNimi](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/jokunimi/32/5268_2.png) [@jokuNimi](https://discourse.jupyter.org/u/jokuNimi)\
**Post date:** [September 18, 2021, 12:18am UTC](https://discourse.jupyter.org/t/using-xeus-cling-kernel-in-jupyterhub-running-on-kubernetes/10852/1 "2021-09-18T00:18:06Z")

</div>

I’m trying to set up a webpage that runs interactive C++ code. I have access to a kubernetes cluster with binderhub installed through helm. I would like xeus-cling to be enabled by default for all notebooks requested from the binderhub server. Is there a reasonable way of doing this?

I’ve been looking at the helm configuration of jupyterhub but don’t see anything suitable. It seems to be possible to install xeus-cling for a user by launching binderhub at the repostiory [https://github.com/jupyter-xeus/xeus-cling](https://github.com/jupyter-xeus/xeus-cling). This seems like an inefficient solution to me, since the installation will be included in every user’s notebook, and will need to be reinstalled if there is a change to the repository.

---

<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:** [September 18, 2021, 7:29pm UTC](https://discourse.jupyter.org/t/using-xeus-cling-kernel-in-jupyterhub-running-on-kubernetes/10852/2 "2021-09-18T19:29:35Z")

</div>

BinderHub uses [`repo2docker`](https://repo2docker.readthedocs.io/en/latest/) to build container images that are then run by JupyterHub.

You can configure repo2docker to run a set of commands after every build:

- [Using repo2docker — repo2docker 2023.06.0+43.gc6f97e5 documentation](https://repo2docker.readthedocs.io/en/latest/usage.html?highlight=appendix#cmdoption-jupyter-repo2docker-appendix)
- [app — BinderHub documentation](https://binderhub.readthedocs.io/en/latest/reference/app.html?highlight=appendix#binderhub.app.BinderHub.appendix)

However if your repositories rely on something in your appendix they won’t be compatible with any other BinderHub, so it would be better if you explicitly included xeus-cling in the dependencies for any repository that requires it.

Alternatively if your dependencies are fixed for all notebook repositories you can use [nbgitpuller](https://jupyterhub.github.io/nbgitpuller/) to decouple your dependencies from your notebook repositories, see

> [@Tip: speed up Binder launches by pulling github content in a Binder link with nbgitpuller](https://discourse.jupyter.org/t/tip-speed-up-binder-launches-by-pulling-github-content-in-a-binder-link-with-nbgitpuller/922):
>
> Something people often want is to de-couple the content of a repository from the environment that is needed to run it. This would allow you to update the content of a repo without needing to re-build the Binder needed for it. One option is to use a tool called [nbgitpuller](https://github.com/jupyterhub/nbgitpuller). This a tool for quickly pulling in GitHub content into a JupyterHub. You can create links that, when clicked, will automatically pull in content into a user’s workspace. nbgitpuller lets you share a link with this structure: …