Deploying a free, multi-user, browser-only IDE in just a few minutes

The indispensable stock IDE picture (photo by Clément H from unsplash.com)

Public and private clouds give developers the opportunity to run and deploy their software artifacts very quickly and scale computations — for example, Machine Learning training — to more-or-less indefinite power. How to bridge the gap between local development on the computer of the developers and the cluster is however a crucial open question.

This is a problem, that online, browser-only IDEs are trying to solve. Running the IDE directly on the cluster (no matter if public cloud or private company datacenter) has a large number of benefits

• use the power of the cluster directly in your IDE, e.g. for compilation or quick tests
• work entirely remote on any device without the need to set up anything on your local machine — all you need is a web browser
• share the setup and the data across users in the same project reducing the risk for “it works on my machine” problems

There exist already a few products in this space, but not all of them can be deployed to your local private infrastructure or tailored to your own needs.

Therefore, we will create a quick-to-deploy, multi-user, browser-only IDE setup in this post using only the free open-source tools JupyterHub and code-server, which you can easily customize to your own needs and deploy to your own infrastructure, as long as you have a Kubernetes cluster.

The post is structured in three parts:
First, we will bring up the needed infrastructure on a public cloud provider (GCP in this case). If you have already a Kubernetes cluster (e.g. in your company), a persistent storage provider, and helm, you can skip this step.
Then, we will install a vanilla online-IDE setup built on top of Visual Studio Code.
In the end, the post will showcase how you can customize things like authentication, environments, or resource usage.

Bringing up the infrastructure: a Kubernetes cluster

Kubernetes (or k8s for short) is a way to run, schedule, and orchestrate large fleets of containers and is the de facto standard to run distributed applications today. Chances are high, you are already using k8s in your company. If not, or if you want to give the online IDE a quick test, you can follow one of the great guides from the “Zero to JupyterHub” project to spin up a k8s cluster on one of the public cloud providers.

For example, to start a small k8s cluster on GCP, enable the “Kubernetes Engine API” in the Google cloud console and run

gcloud container clusters create \
  --machine-type n1-standard-2 \
  --num-nodes 2 \
  --zone <compute zone> \
  --cluster-version latest \
  <cluster name>

either in the cloud shell or on your local computer (if you have installed and configures the gcloud utility and kubectl). Make sure to choose a compute zone near you and a cluster name. After the deployment, you should be able to see two running nodes in your cluster with

kubectl get node

Last but not least, make sure to have helm installed by following the instructions on the project page (it is already installed in the Google cloud shell). Helm is a utility for installing and managing k8s deployments.

That’s already it! We are ready to start deploying!

Deploy an online multi-user IDE

The basis for our deployment will be JupyterHub, a highly configurable platform to deploy multi-user Jupyter Notebook setups. Using JupyterHub allows us to reuse its great ecosystem of predefined authenticators, settings, etc. However, we will replace the Jupyter Notebook part with a Visual Studio Code installation using the code-server project, which has ported VS Code to run in a browser. With this, every authenticated user gets its own VS Code instance and a home folder.

Simplified overview of the setup we are going to deploy.

We will follow the official documentation on how to deploy JupyterHub to k8s, except for some settings custom to the IDE setup. These settings are specified in a yaml file, that you can download from this github repository (to the cloud shell or your local computer):

wget https://raw.githubusercontent.com/nils-braun/codehub/main/values.yaml

Open the file with a text editor and replace theproxy.securityToken (indicated with a TODO) with the result of calling

openssl rand -hex 32

Now add the JupyterHub helm chart from the official repository

helm repo add jupyterhub https://jupyterhub.github.io/helm-chart/
helm repo update

and you are ready for deployment:

helm upgrade --cleanup-on-fail --install codehub jupyterhub/jupyterhub --values values.yaml

That’s it, you have successfully deployed a browser-only multi-user IDE!

You can either visit it with its public IP (if you are using a deployment on a public cloud provider)

kubectl get services proxy-public --output jsonpath='{.status.loadBalancer.ingress[0].ip}'

or by creating a port-forwarding to your local computer,

kubectl port-forward svc/proxy-public 8000:80

and visiting http://localhost:8000. By default, any user and password combination will be valid. The result will look something like this:

The online IDE is up and running!

The deployment does not just look like VS Code, it is nearly a full-blown VS Code. The great group of the code-server project use the open-source part of VS Code, make it accessible for a web browser and package it into a docker image, which we are using here. They name the few remaining differences in their FAQ. You can even run web services for deployment and access them via your browser.

Configure the setup

So what’s next? Now you can start customizing the installation to your own needs and environment.

• First, you should use a different authenticator, e.g. OAuth2 (and GitHub integration), LDAP, Active Directory, etc. instead of the default, dummy one. See here for more information.
• Next, make sure to use HTTPS for encrypting the communication with the hub, if you are running in public. See here for more information.
• You can also customize the resources for each user and the persistent storage (where the home folder and files are stored).
• How about letting the users choose between different “profiles” (e.g. resources, predefined images, and settings)? See here.
• And to not put too much strain on your luster, automatically remove idle servers, see here.
• Learn how to monitor the status of your deployment.

The list can go on for a while, as the ecosystem of JupyterHub extensions is huge. You can even change the looks and run “normal” Jupyter notebooks alongside the IDE servers. In most cases, the only thing you need to do is to add some lines into the values.yaml file and re-deploy with

helm upgrade --cleanup-on-fail --install codehub jupyterhub/jupyterhub --values values.yaml

Happy Coding!

That’s it. You can now run an easily-managed browser-only IDE setup for your team or company and customize it to your needs. Once you are done, you should uninstall the deployment with

helm uninstall codehub

and undeploy the k8s server

gcloud container clusters  delete <cluster name> --zone <zone>

If you like this setup, make sure to visit the pages of the two projects JupyterHub and code-server, and praise them for their great work!
You can also have a look into the repository of this deployment to read more information.