When one Open edX installation can serve several branded sites
A single Open edX installation can serve several branded sites when the sites share one platform, one operating team and one set of release decisions, and when they differ mainly in domain, look and course list. Universities with several faculties, training providers with partner brands and groups with customer-facing academies often fit this pattern. If each site needs its own release cycle, its own data boundary or its own administrators who must never see other sites, separate installations are usually the safer answer. The rest of this section explains what a multi-site setup actually is and how to decide.
In Open edX, a multi-site setup means one running platform answers to several hostnames. Each hostname is mapped to a site configuration that controls the LMS domain, the Studio domain, the visual theme and which courses or organizations appear to learners. The two core services, the LMS for learners and Studio for course authors, both have to understand these mappings. Themes are applied per site, so the branding a learner sees on one domain should not leak onto another. Course listings and organization assignments decide what each site shows. Confirm with your Tutor version and documentation how site configuration and theme selection are set up, because the exact steps differ between releases.
The edx-platform codebase is a modular monolith, with independently deployable applications and React-based micro-frontends around a shared core. That structure matters for multi-site work. A change to the shared LMS code, a platform-wide setting, a database migration or an upgrade affects every site at once, including sites whose owners never asked for the change. Plan for a single change window and a single test cycle across all sites. Ask whether a shared component, such as the authentication setup, email templates or the shared cache, can be scoped per site at all, and record the answer before you commit to one installation.
Teams need a multi-site setup when they want to reuse one operating cost, one upgrade path and one copy of course content across brands. They should choose separate installations when a site must be hosted or governed separately, when different legal or data residency rules apply, when a partner needs its own identity provider or analytics pipeline, or when sites will upgrade on different schedules. A useful check is to write down, for each site, who administers it, which identity provider it uses, where its data may sit and when it must be upgraded. If those answers conflict across sites, the shared installation will cost more to operate than its licence savings suggest.
Shared installation or separate installations per brand
This table compares four ways to host several branded Open edX sites: one shared installation, separate installations per brand, a hybrid that isolates high-need customers, and a shared base with per-brand theme and configuration forks. Read each row against your own brand count, data rules and upgrade appetite, and treat release-specific points as items to confirm for the named release you plan to run.
| Factor | Shared installation | Separate installation per brand | Hybrid (shared base, isolated high-need brands) |
|---|---|---|---|
| Best fit | Brands that share a catalog, learner base and policies, such as faculties or one partner network | Brands with distinct legal entities, data rules or hosting demands that cannot share a user pool | Mostly shared brands with a few customers that require their own database, storage or domain governance |
| Upkeep burden | One platform to patch, back up and monitor, but every site's theme and config must be tested together | Each instance needs its own upgrade, backup, monitoring and on-call coverage, so effort scales with brand count | Two patterns to run: the shared stack plus a standard template for isolated instances |
| Data separation | Users, enrollments and analytics share one database; separation depends on site configuration and access roles | Strong separation by default, since each brand has its own database, media store and admin accounts | Strong separation for isolated brands; shared data rules apply to the rest |
| Upgrade coordination | One upgrade window for all sites, which means every brand must accept the same release and test date | Each brand can schedule its own window, but the work repeats per instance | Shared sites upgrade together; isolated instances need their own window and rollback plan |
| Theme and course isolation | Themes and course lists are managed per site within one codebase; confirm which settings are site-scoped in your release | Full freedom of code and theme per brand, at the cost of drift between copies | Theme changes for shared sites follow the shared release; isolated brands can diverge |
| What changes when a brand leaves | Export that brand's courses, users and records, then remove its site configuration and confirm nothing else depends on it | Decommission the instance, retain or delete data under your retention policy, and remove its DNS and infrastructure | Shared-site brands follow the first option; isolated brands follow the second, which is usually cleaner |
| Release dependency | Multi-site behavior and site-scoped settings can change between named releases; confirm against the release you run | Less dependent on multi-site features, but each instance still follows the named release support window | Depends on both patterns; confirm the shared-site features in your target release before committing |
How to set up multi-site, step by step
This sequence takes one Open edX installation from release choice to a set of branded sites, each with its own domain, theme, identity setup and course list. Each step closes with a check the team can run, so problems surface before any learner signs in.
Confirm the release and deployment method
The platform owner confirms the named Open edX release to build on and whether the installation runs on Tutor with Docker or Tutor with Kubernetes, following the Tutor documentation for the chosen method. Open edX supports only the latest named release, so the team should check the release notes for the version it targets and plan any upgrade before build work starts. This step is done when the release, deployment method and hosting environment are written down and a test environment on that method starts cleanly.
Agree the site list and domain map
The platform owner and each faculty, partner or customer owner agree the list of sites, the audience for each, the domain for each and the named owner who approves its course list. The team also records whether sites share learner accounts or keep them separate, because that decision shapes the identity work in a later step. This step is done when one signed table exists with a single accountable owner per site.
Plan DNS and TLS for each domain
The infrastructure team creates DNS records for every domain, points them at the ingress or load balancer, and issues a certificate for each host name from the certificate authority the organization uses. The team confirms how the platform routes requests by host name and checks that redirects never send a learner from one site to another. The check: from outside the network, request each domain over HTTPS and confirm the expected site loads with a certificate that matches its name.
Configure per-site theme and branding
Front-end and theme developers build or select the assets for each site, covering logos, colors, footer text, legal links and the sender details used in platform email. They confirm in the Open edX and Tutor documentation for the chosen release how each site is assigned its own theme. The check: the login page, footer and a test transactional email on each site show that site's brand and no other site's brand.
Set up catalog and publishing rights
The platform owner defines which courses appear on which site, which organization each site's authors belong to and who may publish to which site. The team writes this access model down before any author is invited, and confirms with the release documentation how Studio permissions are scoped by organization or site. The check: an author with rights on one site attempts to create or publish under another site's organization, and the platform refuses the action.
Configure identity providers for each site
For each site, the team decides whether it uses a shared identity provider or its own, then configures the third-party sign-in providers Open edX supports for that site, such as OAuth2, SAML 2.0, Shibboleth or LTI, following the identity provider documentation for the release. Each provider's registered redirect addresses must match the site's domain exactly. The check: sign in through each provider on each site and confirm the account lands on the correct site and cannot reach another site's enrollments unless that access was intended.
Test isolation before launch
The QA lead runs a written test matrix with dedicated test accounts for each site, covering logins, enrollments, email senders and footers, branding, course visibility across sites and administrator access. Each failed case is fixed and retested, and the owner of each site signs off on its results. The step is done when the test log shows every case passing and no cross-site leak remains open.
Security and data separation across branded sites
One Open edX installation serving several branded sites shares its database, processes and administrative tooling, so a mistake in one site's setup can reach another. The cards below cover the places where separation tends to fail and the checks to run for each site before launch.
Cross-site data visibility
Learners, enrollments, course content and reports sit in one shared database, so separation depends on how each course, organization and site is assigned and filtered. Check that learner records, grades and instructor dashboards for one site cannot be listed or exported from another, and test this with accounts that belong to a single site. Confirm the same rule applies to analytics and any search index that reads from the platform.
Staff roles that span sites
Platform staff and course teams are often given roles at the installation level, which grants access to every branded site at once. Map each administrator, course author and support role to the sites it may touch, and remove global roles that were granted for convenience during setup. Review this list whenever a partner or faculty team joins or leaves, since role changes are where cross-site access tends to persist.
Identity provider configuration per domain
Each site may sign learners in through its own identity provider, such as a university directory or a partner's SSO. Open edX third-party authentication supports OAuth2 providers, SAML 2.0, Shibboleth and LTI, and each site's identity setup must be checked separately, including which provider is offered on which domain, how attributes map to accounts and whether a user from one site can authenticate on another. Document the provider settings for every site as part of its launch record.
Session and cookie scope across domains
Session and authentication cookies set for a parent domain can be sent to every subdomain, and a session created on one branded site may remain valid on another. Confirm the cookie domain, secure and same-site attributes, and session lifetime for each domain, and test sign-out on one site to see whether it ends sessions on the others. Plan how embedded content or single sign-on redirects behave across domains before opening the sites to learners.
Outbound email sender identity
Enrollment confirmations, certificates, notifications and password resets are sent from the platform, and the sender name, reply address and footer can all be set per site. Confirm that each site uses its own sender domain with correctly published mail authentication records, and that a message about one site's course never carries another site's branding or links. Ask the team who controls the mail provider and who receives bounces and complaints for each domain.
Audit logging of administrative actions
Changes to site configuration, role assignments, identity providers and course settings need a record of who made them, when and on which site. Decide where these events are stored, how long they are retained and who can read them, and confirm that logs from a shared platform can be filtered by site. Test that a change made on one site appears in the log with the correct site attribution, because a log that cannot separate sites makes investigation slower.
How release timing affects a multi-site platform
A multi-site Open edX installation runs one platform release, so every site moves when the platform is upgraded. Open edX states that the latest named release is the only supported release and that it cannot support more than one release at a time. Verawood is the current named release, published on 30 July 2026, and Willow and Xylon are listed for December 2026 and June 2027. For a multi-site operator, this means there is no option to keep one faculty or partner on an older release while another site moves ahead on the same codebase. Build the upgrade calendar around the named release cycle, and treat each site's launch dates and enrollment peaks as constraints on that calendar rather than as separate plans.
Plan a single upgrade window for all sites. The window should cover the shared LMS and Studio code, the common theme, the site configuration for each domain, and the course catalog that each site exposes. Name one owner for the window who can approve go or no-go decisions for every site at once. Agree freeze periods with each faculty, partner or customer before the window is set, so that no site is in the middle of a course launch or exam period when it moves. Rehearse the full upgrade on a staging copy that includes every site's domain, theme and settings, and write down the rollback steps for the whole installation, because a rollback will also affect every site.
Confirm each site's theme and plugin compatibility against the target release before the window is scheduled. Check the shared base theme, each site's overrides for templates and SCSS, and any custom XBlocks, pip-installed plugins and LMS applications that run on every site. Verawood, for example, added a new Studio sidebar and new frontend plugin slots, so any site that overrides those areas needs a specific review when it moves to Verawood. Repeat the check for each target release on your calendar, including Willow and Xylon, and record the results per site so that a site-specific blocker is visible before it becomes a schedule problem.
Timing also creates risk when a release cycle falls close to a site's launch. If one site cannot move in the chosen window, the choices are to delay the whole installation, split the installation, or run the site on an unsupported release. Since Open edX does not support more than one release at a time, the third option is the hardest to justify to an auditor or an institutional partner. Ask any implementation partner to state in the written scope how per-site testing, rehearsal and sign-off are covered, and ask how long the platform team needs to prepare each release. Put the decision rule for a late site into the upgrade plan before the window is fixed.
What a shared platform cannot isolate, and what to confirm
One Open edX installation serving several sites shares far more than a domain name and a theme. The cards below cover the parts of the stack that sites tend to share, and the questions a buyer should answer for their own environment before committing to a single installation.
Shared database and cache capacity
All sites in one installation read and write the same MySQL and MongoDB databases and the same shared Django cache backend, such as Redis or Memcached, which multi-node deployments require. A large course import or heavy enrollment on one site draws on the same capacity as every other site. Confirm with your Tutor or service provider how database connections, cache memory and backups are sized for the combined load, and whether any of these can be separated per site.
Shared search and analytics data
Search indexes, learner events and analytics pipelines may hold data from several sites in one store. Whether results, dashboards and exports are filtered by site is a configuration question, not an assumption. Confirm in your own environment, with test accounts on two sites, that a learner or staff member on one site cannot see another site's course content, search hits or event data, including through Aspects dashboards.
Custom code that touches every site
Custom XBlocks, theme overrides, plugins and LMS or Studio patches run for every site in the installation. A change written for one faculty can alter the behavior of all the others. Confirm with the vendor and your own test plan which customizations are site-aware, how each release upgrade will be regression tested across all sites, and who approves changes that affect shared code.
Performance interference between sites
Load from one site, such as a registration campaign or a large exam window, can slow pages for every other site on the same web, worker and database tier. Ask how autoscaling, queue separation and rate limits are configured per site, and test peak scenarios for the largest site with the rest of the installation running. Confirm the expected capacity figures with your provider in writing rather than relying on general statements.
Authorization scoping by site
Whether staff roles, course authoring permissions and instructor access are limited to one site or apply across the installation depends on the feature and the release. Verawood and later releases add authorization work that may change this. Confirm with the vendor, for your release and feature flags, whether role-based access is scoped per site, per organization or per course, and test that an administrator on one site cannot change another site's courses.
Notifications and email per site
Notifications, digests and outbound email are sent from installation-level settings unless the feature supports site-level defaults. Sender identity, templates, opt-out behavior and digest timing can therefore apply to every site at once. Confirm in your environment which of these are configurable per site, which need a separate installation, and how each site's learners see branding in messages they receive.
Shared upgrades and release timing
Every site moves to a new named release at the same time, because the installation runs one release. A site with a fixed academic calendar or a partner contract may not accept that timing. Confirm with the vendor and your provider the release calendar, the testing window for each site, and whether a rollback plan exists for a single site's regression without reverting the others.
What does a multi-site Open edX setup cost and need from our team?
What drives the cost of a multi-site Open edX setup?
The cost follows the written scope, and five factors move it most: the number of sites, how deep the theme goes, how many identity providers each site uses, how much existing content and learner data must move, and how the platform is hosted. Each site adds its own domain, theme, course list, email sender and sign-in configuration, so ten sites are not simply ten times the work of one, because shared components are built once. Testing scope matters too, since every site needs checks for sign-in, enrollment, certificates and branding. Ask the partner to price each factor separately so you can see where a change in scope changes the quote.
Which parts of a multi-site setup are one-time and which recur?
One-time work includes discovery, the shared platform build, theme and frontend design, identity integration for each site, data migration, testing and handover. Recurring costs come from running the platform: hosting capacity, backups, monitoring, security patching, and upgrades to each named Open edX release as it becomes the supported one. Open edX states that only the latest named release is supported, so plan for upgrades as a standing cost rather than a single event. Ask any quote to split one-time fees from recurring support and to state what an upgrade of the full multi-site platform includes.
Can our internal team run a multi-site Open edX setup without a partner?
Yes, if you have people who can operate Open edX in production, and the edx-platform maintainers recommend running it through a service provider or with Tutor, because bare-metal installation is complex and gets limited community support. A capable internal team usually needs Python and Django skills, Docker or Kubernetes operations, database administration, identity integration experience and frontend skills for themes. Check the skills you already have against those areas and the time your staff can commit. A partner is most useful where internal experience is thin or where the schedule cannot absorb a learning curve.
How long does a multi-site setup take?
Duration depends on scope, not on a fixed template, so no timeline is promised here. The main inputs are the number of sites, whether each has a distinct theme or only colors and logos, how many identity providers must be connected, how much content and learner history must be migrated and how thorough testing must be. Phasing helps: launching one pilot site first lets the shared platform be proven before the rest follow. Ask for a schedule that lists milestones and what each one depends on from your side.
What does our team need to provide for the project?
The work needs decisions and access from your organization, not only budget. You will need domain control for every site, including DNS records and certificates. Identity administrators must provide access to your identity providers and agree attribute mapping. Content owners must supply course material, catalog rules and migration sources. Brand and academic leaders must sign off on themes, site names, the course catalog and which content each site shows. Name one owner per site for approvals so that sign-off does not stall the schedule.
How do we ask for a fixed-scope quote for a multi-site setup?
Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. Give the partner a site list with domains, the branding and theme depth you expect for each site, the identity providers per site, the data to migrate with volumes and formats, the hosting model and the testing you require. Ask for deliverables, assumptions, client responsibilities, acceptance criteria and the handling of changes. Request separate line items for one-time work, first-year recurring support and any optional retainer for upgrades and continuous testing.
Which multi-site decisions should we settle before requesting a quote?
Settle the decisions that change the scope most: how many sites will exist at launch, whether they share one course catalog or each keeps its own, which identity providers each site uses, and whether sites share learner accounts. Also decide the hosting model, since your own cloud accounts, data centers or air-gapped networks each carry different operating duties. Clarify who approves branding and who owns the catalog. Decisions made early avoid rework, and a partner can then write a clearer and narrower scope.
How DeployOpen scopes and delivers a multi-site Open edX platform
DeployOpen plans, implements, customizes, integrates, hardens and supports self-hosted open-source platforms inside your own infrastructure, including Open edX. For multi-site and white-label work, we start from a written scope that names each site, its domain, theme and course list, then build on Tutor so your team can run the platform after handover. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- The written scope lists every site, its domain, theme, course catalog and the administrators who manage each one.
- We confirm the target release first, since Open edX supports only its latest named release.
- Fixed-scope terms mean deliverables, timelines and exclusions are agreed in writing before work starts.
How we build
- Tutor supplies the Docker-based distribution and Kubernetes deployment options, with plugins that carry site-specific changes.
- Multi-node deployments need a shared Django cache backend such as Redis or Memcached, which the build plan includes from the start.
- Each site's theme, domain and course list are tested in staging before any learner-facing change goes live.
How we hand over
- Handover includes configuration records, a runbook for adding a site, and the deployment code kept in your repository.
- Your administrators get a tested procedure for creating a new site, changing its theme and retiring it.
- Operational limits of a shared platform, including shared upgrades and shared data, are documented for your decision makers.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Upgrades follow each named Open edX release, with breaking changes and data migrations reviewed before the site is moved.
- Because one installation upgrades all sites together, the support plan sets maintenance windows with every site owner.
