V10.0.0: Juniper is here!

Juniper, the 10th release of Open edX, is out! See the announcement here: https://discuss.openedx.org/t/juniper-is-here/

We’ve been hard at work upgrading Tutor to make sure that you can smoothly upgrade your Open edX platforms from Ironwood to Juniper. Today, I’m pleased to announce that we’ve managed to streamline the upgrade process to the point that it should be transparent for most users.

Upgrading Tutor

  1. Download the latest (v10.0.0) release of Tutor: https://docs.tutor.overhang.io/install.html
  2. If you are running Tutor from source (with git clone or pip install), you should remember to upgrade the plugins you enabled with pip install --upgrade tutor-myplugin. Note that the figures plugin has not been upgraded yet, as the maintainer of the underlying application has not yet upgraded the code to Python 3.5.
  3. If you are running the Indigo theme, remember to upgrade it: https://github.com/overhangio/indigo#upgrade

Locally-running platforms

Making a backup

It is strongly recommended to make a backup prior to upgrading your local Open edX platform:

tutor local stop
sudo rsync -avr "$(tutor config printroot)"/ /tmp/tutor-backup/

Automatic upgrade

For locally-running platforms, the upgrade process will be automatically performed by running:

tutor local quickstart

Manual upgrade

Alternatively, you can run the upgrade command by running:

tutor local upgrade --from=ironwood

This command should only be run once. If you try to run it a second time, it will fail.

The tricky part when upgrading Open edX from Ironwood to Juniper is that Mongodb needs to be upgraded from v3.2 to v3.6. If you are relying on a 3rd-party hosted Mongodb database (ACTIVATE_MONGODB = false) then you need to perform the database upgrade yourself. Instructions vary from one provider to the next.

Upgrading platforms running on Kubernetes

Users who maintain platforms running on Kubernetes are responsible for making backups. The manual upgrade instructions are printed by running:

tutor k8s upgrade --from=ironwood

What does it mean for Tutor users?

From the perspective of a platform maintainer and developer, the biggest change concerns the way to access local non-production Open edX platforms. Prior to v10.0.0, it was possible to access a locally-running platform from http://localhost and http://studio.localhost. This is no longer possible in v10.0.0. Instead, when running tutor local quickstart, users are asked whether they want to run a platform for testing purposes:

Are you configuring a production platform? Type 'n' if you are just testing Tutor on your local computer [Y/n]

If users answer “n”, the LMS_HOST and CMS_HOST configuration variables will automatically be set to local.overhang.io and studio.overhang.io. These domain names all point to Also, SSL/TLS will be automatically disabled. Thus, the platform will be accessible at:

And in development:

This change was made to simplify internal addressing and communication between Docker containers.


If you encounter an issue during your upgrade, please create a new topic in these forums. Do not open a Github issue right away!

Please note that releases prior to v10.0.0 will not be officially supported on these forums! If you need support for past Open edX releases, you should subscribe to a Long Term Support (LTS) license.


Note that the French provider Free blocks domain name resolution for and maybe as well but I did not verify that. If someone runs tutor on a machine with a resolver provided by a Freebox and foo.bar resolves to, it will reply that it does not exist. It’s worth checking if that’s also the case with My 2cts.

What are the GDPR/privacy implications of routing localhost through the domain name?

Thanks for your comment @antoine. I don’t have a Free subscription to verify this. Let’s see if that problem emerges at some point. It’s good to be aware of this, I’ll keep that in mind.

Good question @ak00001! I thought about this, and as far as I know there are none. That’s because I have no way to log DNS queries to local.overhang.io. Also, DNS is outside of the scope of GDPR. Finally, note that this question arises only when developing locally. Production users make requests to the domain name pointed by LMS_HOST, as usual.