After completing these changes on opening the newly created tenant domain the site was not opening up, throwing a “connection refused” error, soI checked Caddyfile and the new domains were not added to it, so I replaced old domains with new domain blocks in Caddyfile, but even after replacing domains when I open site-a.local.openedx.io, then I am redirected to site-a.local.openedx.io/dashborad and agin redirected to apps.local.openedx.io/learner-dashboard with a blank page.
A similar discussion is ongoing here for multi-tenancy.
Let’s combine both here.
@Andrey, I’ve seen your responses regarding multi-tenancy. It would be great if you could share any documentation or step-by-step guidance for configuring this.
Your configuration looks fine. Indeed, this plugin is not difficult to set up, but there may be a misunderstanding about its scope. Basically, this plugin allows you to edit or insert new settings based on the domain. It does not modify other aspects of the platform, such as the Caddy file.
If you need to change that behavior, you would either need a Tutor plugin or make those changes manually. That said, when working with a standard local Tutor setup, you do not need to modify the Caddy file. You can access any domain prefix as long as you keep the base domain local.openedx.io. I’ve attached a video showing this behavior.
That said, the issue might be related to how you are testing the expected behavior. You are expecting a different result when accessing the dashboard page; however, the LEARNER_HOME_MICROFRONTEND_URL setting has not been modified, so the page will redirect to the base configuration.
lms-1 | 2026-01-14 13:24:59,257 INFO 30 [eox_tenant.signals] [user None] [ip None] signals.py:49 - Site ``local.openedx.io``, does not use eox_tenant signals
Any idea why am I facing this issue after installing eox-tenant?
Sorry, but I cannot help you with that. As I mentioned before, eox-tenant allows you to edit or insert new settings based on the domain at the backend level, and it does not modify other aspects of the platform, such as the MFEs.
The reason behind the result you are seeing is that local MFEs are not designed to work in a multi-tenant platform. There are multiple strategies to address this, but I have never implemented them in a local environment.
If you check the network requests, you will find a call to:
If you inspect the response of the previous request, you will likely find a key called LMS_BASE_URL, which should contain the site-a domain instead of the default one. There are also additional settings that will return an invalid domain for the same reason.
All of this points to a configuration issue. If your goal is only to validate the eox-tenant behavior at the learner-dashboard MFE level, you can make a request to:
