Hrm - if Kolibri is not starting after these settings are applied, my only real guess would be that it’s not finding the redis server at set location, or is trying to connect and is unable to do so.
For the multiple instances, this is probably a result of Kolibri using a file backed session store by default.
You can see this in the default Kolibri settings here: kolibri/kolibri/deployment/default/settings/base.py at develop · learningequality/kolibri · GitHub
We don’t currently have a way in our options.ini to override this, so you would need to create a custom django settings file (which can import from the Kolibri default settings and then override this).
from kolibri.deployment.default.settings.base import *
SESSION_ENGINE = ...
You can find other options for the session engine here: How to use sessions | Django documentation | Django I can’t give a recommendation, as I haven’t tried any of them out - but we use database backed sessions on Kolibri Studio.
The reason this is the case is that with a file backed session in a scaling scenario the instance that processes your login may not be the instance that processes your next request - and if you ever send a request to a different instance it will invalidate your session when it doesn’t find it in its session store on disk - so you end up with the behaviour you are seeing.