Running the platform

This page describes how to deploy the Renku platform on minikube. Running GitLab (which is a part of Renku) is quite resource intensive. For this reason we describe a setup which excludes GitLab from the Renku deployment and instead uses as GitLab backend. For the Renku graph features to function properly in this setup, needs to be able to contact the locally running platform through a webhook. This can be achieved through many services like ngrok or the like. We are going to use, a minimalistic method based on ssh tunneling which allows for a somewhat static hostname.

The renku source code is hosted on github:


You will need the following tools installed on your machine:

For OS X users, we also recommend to install the hyperkit vm driver for minikube.

Clone the repo

Get the code by cloning the Renku repository:

$ git clone
$ cd renku/charts

Install python dependencies

We recommend using pipenv for managing your virtual python environment. Install all the necessary python dependencies:

$ pipenv install --dev

Start minikube

Next we start minikube. Don’t forget to specify the version with the –kubernetes-version flag to avoid incompatibilities with the most recent kubernetes versions.

Tip: For OS X users we recommend using the hyperkit vm driver by adding the –vm-driver-hyperkit flag to the command. For Linux users, installing VirtualBox as hypervisor is the simplest option. For other solutions, please refer to the installing minikube docs.

$ minikube start --memory 6144 --kubernetes-version=1.14.8

Once minikube has started, make sure you can access it by running:

$ kubectl get node
minikube   Ready     master    3s        v1.14.0

Notice: If minikube did not start successfully issue minikube delete before next minikube start.

Once minikube has started, issue the following command (this will configure your docker CLI to communicate with the docker daemon running in your minikube virtual machine).

$ eval $(minikube docker-env)

Deploy tiller and the NGINX ingress controller

Helm needs a server-side component which is called tiller and runs inside the the kubernetes cluster. Also, we deploy nginx ingress.

$ helm init
$ helm upgrade --install nginx-ingress --namespace kube-system \
    --set controller.hostNetwork=true \

Notice: after the init command, you may need to wait up to 1 minute before you can successfully run helm upgrade.

Build and pull all necessary charts

$ helm repo add jupyterhub
$ helm repo add renku
$ pipenv run chartpress --tag latest
$ helm dep build renku

Set up

We use a service called to expose the platform by establishing an ssh tunnel.

$ ssh -R 80:$(minikube ip):80

This will start the tunnel and display your hostname of the style http://<some-name> Copy it and export it (without the http(s)://) into RENKU_DOMAIN.

$ export RENKU_DOMAIN=<some-name>

Note: When you stop and restart the tunnel without waiting for too long, you should receive the same subdomain that you have previously had. If this is not the case you will have to reconfigure the client application and recreate your Renku deployment (see next steps).

Set up the gitlab client application

Browse to GitLab, then click on the user icon and select settings > applications. Register a new client application with the following settings:

  1. Name: renku-local
  2. Scopes: all except sudo
  3. Redirect URI (use the value of the previously exported environment variable $RENKU_DOMAIN for <renku-domain>):

Copy the Application Id and the Secret that appear at the end of this procedure.

Configure the values.yaml file

Open the file charts/example-configurations/external-gitlab-values.yaml in your cloned Renku repository. You need to modify the values in the first lines by specifying all the required variables and commenting out global if you are not using a cloud instance of GitLab (like Use the Application Id and the Secret from the GitLab client application created in the previous step.

Deploy Renku to minikube

Start the renku platform using helm:

$ helm upgrade renku --install --namespace renku ./renku \
  -f minikube-values.yaml -f example-configurations/external-gitlab-values.yaml \
  --timeout 3600 \
  --set global.renku.domain=$RENKU_DOMAIN \
  --set$RENKU_DOMAIN/api/auth/jupyterhub/token \
  --set notebooks.jupyterhub.auth.gitlab.callbackUrl=http://$RENKU_DOMAIN/jupyterhub/hub/oauth_callback

Executing this command for the first time can easily take a long time depending on your internet connection speed (even 30+ minutes) as all the necessary docker images need to be pulled. Do not interrupt the upgrade command.

If you want to verify that things are moving on, open a new terminal any type kubectl -n renku get pod. The renku-keycloak-* pod is the slowest. If the Ready column reports 0/1 and Restarts is not higher than 1, all is going as expected. This would be a good moment to grab yourself a coffee…

Once the above command has returned you should be able to access the platform using your browser under http://<some-name>

Manage Keycloak

Keycloak is an identity management solution which is deployed as a part of Renku. You can access the admin interface at http://<some-name> The admin username is “admin” and the admin password can be looked up in the corresponding kubernetes secret:

$ kubectl get secrets -n renku keycloak-password-secret -o json | \
    jq -r '.data["keycloak-password"]' | base64 --decode

Configure as the identity provider (optional)

It is possible to configure or another external GitLab deployment as an identity provider for your local Renku deployment. This has the benefit of having only one source for user information and making the login process for the platform more convenient. While logged into the Keycloak admin interface, go to Identity Providers and choose “GitLab” from the “Add Provider…” drop-down menu. Add the Application Id and Secret from the Renku-local application created earlier. Save the identity provider and logout from the Keycloak admin panel.

Configure GitLab CI

For each created project you will have to modify the .gitlab-ci.yaml in the repository for the image build to work. In the image_build job

  • remove the image-build tag
  • add the following entry:
  - docker:dind