[Proposal] Multi-instance configuration for the Mobile Apps
Document Metadata
Status: Draft for Community Review
Proposal Date: July 2026
Document Owners / Initial Participants: Edunext, RaccoonGang, Schema Education, ZeitLabs
Target Stakeholders: Open edX Partners Ecosystem & Independent Site Operators
GitHub Tracking Issue:
[Product Proposal] Multi-instance configuration for the Mobile Apps · Issue #516 · openedx/platform-roadmap
1. TL;DR summary
An ecosystem initiative to introduce an optional, multi-instance configuration capability to the Open edX mobile codebase, enabling the existence of trusted, multi-instance mobile clients supported by a site routing registry. This capability lowers the financial and operational barriers to mobile learning for independent Open edX instances at near-zero cost.
Overview
This proposal introduces an optional multi-instance configuration feature for the Open edX mobile applications, operating alongside a site routing registry backend. Once enabled, this capability allows for an initial provider-led testing phase to gather real-world operational stability and security data , paving the way for a future potentially official Axim-sponsored multi-instance mobile client while allowing other specialized initiatives to deploy their own independent multi-instance apps.
Problem
Building, publishing, and maintaining individual, single-client mobile applications in the public marketplaces is financially and operationally prohibitive for many independent site operators and service providers. This friction leaves a significant portion of the Open edX ecosystem without native mobile access, limiting the learner experience and creating a competitive disadvantage for Open edX against proprietary learning management systems.
Use Cases
As an Open edX Learner: I need to download a single, readily available mobile app and connect seamlessly to my specific institution's domain in order to log in securely and consume my course content on the go.
As a Small or Medium-Sized Open edX Operator: I need a way to provide high-quality native mobile access to my learners at no additional cost. By leverage-pointing my LMS site to the official community-hosted instance registry , I want to eliminate the operational and financial burden of managing independent developer marketplace accounts.
As a Large Open edX Operator or Network Provider: I need a pluggable, multi-instance client mobile architecture that allows me to run a unified mobile application wrapper for my own large portfolio of enterprise clients or distinct institutional sites. I want to point this application package to my own independent, self-hosted registry backend.
Proposed solution
We propose a pluggable, feature-gated mobile architecture that introduces an advanced multi-instance routing mode into the core Open edX mobile codebase without disrupting traditional single-instance deployments.
The solution consists of two primary components:
The Pluggable Multi-Instance Layer (Mobile Client): This is an optional, configuration-driven extension built directly on top of the mobile app code.
Default Behavior: When a organization compiles the mobile app normally, this layer remains inactive, and the app functions in its traditional single-instance mode (hardcoded to one specific LMS platform).
Advanced Mode (Pluggable): If this optional module is explicitly enabled via a configuration flag at build time, the application transforms into an instance-agnostic client. It adds a domain selection interface for the user and unlocks the logic required to dynamically fetch authorized LMS endpoints. Developers enabling this mode will simply be required to specify the URL endpoint where their instance registry lives.
Screenshots
|
|
|
|
|
|---|---|---|---|---|
 | |
|
| |
The Instance Registry Backend: A lightweight, look-up directory that handles the routing for the multi-instance client. It securely maps authorized Open edX domains and serves them to the app wrapper upon request, while storing absolute zero student PII, credentials, or course data.
Implementation plan
Technical Implementation and testing: Raccoon Gang has already developed an initial working Proof of Concept (POC) for both components that demonstrates strong operational viability. Currently, a collaborative effort between Raccoon Gang, Edunext, Schema Education, and Zeitlabs is actively driving this initiative to further develop and test the solution all the way until real learners download and use the mobile apps. The collaboration framework remains open to other ecosystem providers to participate, thoroughly test the existing POC, and iteratively improve it into a highly stable, production-ready product.
The detailed execution roadmap can be found in the following link: Collaboration around the multi-instance mobile app POC
Resources: Joint development, release management, and compliance auditing teams provided by Edunext and Raccoon Gang, with product validation from Schema Education and Zeitlabs.
Funding Status: Fully funded through the resource commitments of the initial participating providers.
Experimental Safeguards & Exit Strategy: To guarantee total transparency and safeguard the core platform throughout the initial evaluation process, all feature development will live entirely on an isolated, dedicated branch. Absolutely no code will be merged into the
mainormasterbranches of the official mobile repositories until this product proposal is formally approved by the community. Furthermore, if this product proposal is ultimately rejected or not accepted, the experimental Site Registry backend repository will be permanently removed from the officialopen-edxGitHub organization.
Long-term ownership and maintenance plans
As this proposal introduces an optional, pluggable feature layer directly into the core Open edX mobile codebase, its long-term maintainership will follow the standard Open edX core contributor and maintainer model. The initial contributing providers (Edunext and RaccoonGang) formally commit to co-maintaining this configuration-driven architecture alongside the Mobile Working Group, ensuring that the pluggable module remains fully supported, maintained, and stable across subsequent platform releases.
Future Roadmap: Community-Driven Multi-Instance apps & Registry
While this specific proposal focuses strictly on adding the multi-instance capability to the shared codebase, enabling this feature unlocks a broader operational roadmap for the ecosystem. The participating providers intend to leverage this newly introduced capability to build a trusted, scalable, and community-aligned multi-instance mobile client.
To guide the governance and progression of this secondary operational layer, the following framework is proposed:
Provider-led Steering Committee: The pilot deployment and initial site registry will be overseen by an open, multi-party Joint Steering Committee composed of the initial participating providers. Clear onboarding pathways will be established to grant equal governance representation to any future ecosystem partners who commit resources to the initiative.
Path to Official Axim Sponsorship: The explicit long-term objective of this pilot is to gather rigorous operational data. Once predefined stability, data privacy, governance, and security audit milestones are met , the committee will execute a data-driven pathway to hand over the registry infrastructure, and application marketplace accounts directly to Axim Collaborative. This may result in transitioning the provider-led multi-instance client into an official community asset operating under an
openedx.orgsubdomain.
To guarantee total transparency and safeguard the core platform throughout the initial testing and evaluation process, all multi-instance app development will live entirely on an isolated, dedicated branch. Absolutely no code will be merged or committed into the main or master branches of the official mobile repositories until this product proposal is formally approved by the community. Furthermore, if this initiative is ultimately rejected or not accepted, the experimental Site Registry backend repository will be completely retired and permanently removed from the official open-edx GitHub organization.
Contact person
Submitter / Coordinator: Juan Camilo Montoya (Edunext)
Optional additions: Competitive research
How Canvas and Moodle solve this: Both Moodle (via the core Moodle App) and Canvas (via Canvas Student) rely on this exact "multi-instance App + URL Routing" model as their primary mobile strategy. Instead of forcing thousands of individual schools to manage their own developer accounts, they publish a single marketplace wrapper. Users download the application, type in their specific institutional URL or search a global school directory, and authenticate directly against their isolated site.
Ecosystem Validation: This industry-standard approach proves that a centralized domain router successfully balances multi-tenant scale with strict institutional data isolation, directly validating the architecture proposed for Open edX.
Comments
I don’t have any data on this unfortunately. We tried to back into a number in the past but it felt very very hand-wavey
Following our alignment during today's Product Mobile Working Group meeting, I have updated the naming convention and framing throughout this entire proposal to eliminate ambiguity.
We have shifted the terminology from "Universal Mobile App" to "Multi-instance configuration for the Mobile Apps". This adjustment clarifies that we are introducing an optional, feature-gated platform capability to the core codebase rather than attempting to launch a single, exclusive application wrapper. Framing it this way emphasizes that this feature can support the existence of multiple, independent multi-instance clients across the ecosystem—whether that means a future official Axim-sponsored client or other specialized community initiatives.
The TL;DR, Overview, and Future Roadmap sections have been updated to reflect this corrected taxonomy. We look forward to your continued feedback and discussions in the thread below!
I’m quite supportive of this latest proposal.
I expressed this in the Mobile WG meeting but I’ll restate it here. With any “Universal” app proposal, I see three major challenges:
Refactoring the mobile apps – they will need be able to switch between multiple backend instances. Right now they assume one backend.
Version compatibility. Does the app support only one named release at a time? If so, will all backend instances be ready to upgrade at the same time?
Hosting, brand name, & content moderation. Who hosts the registry? Which instances get listed? Who makes sure there are no instances with abusive content? Will Axim/TOC allow use of the “Open edX App” name (I do not know the answer to this myself)? Or will it be called something else?
With this latest proposal, we are not talking about one “universal” app, but about multi-instance capability in general. This will let the team focus on challenges (1) and (2) and deliver something that providers can try out. I don’t know how or when there will be a universal answer to challenge (3), so I am glad that this proposal can move regardless of that.
@Edward Byun did you by chance have any data into the number of initiatives that deploy the single client mobile app so that we can support the claim that the friction is actually real and limiting many initiatives now?