Get in touch

TL;DR — Nexia Academy is our white-label learning platform — multi-tenant, brand-isolated, SCORM/xAPI/cmi5 ready. Building it taught us most of what we know about tenancy, content packaging and LMS interoperability. Here is the architecture, the trade-offs and the parts we would redesign if we started over.

Nexia Academy — white-label multi-tenant LMS architecture Tenants share the platform but live in isolated schemas with their own brand, domain and content. — /Nexia Academy stack acme.lms tenant A · brand A contoso.lms tenant B · brand B delta.lms tenant C · brand C Nexia core edge tenant resolver SCORM · xAPI · cmi5 SSO · reporting Postgres schema acme schema contoso schema delta
Tenants share the platform but live in isolated schemas with their own brand, domain and content.

The product, in one paragraph

Each tenant runs on their own domain (or subdomain), with their own logo, theme colors, email templates and course catalog. Learners only see the tenant’s brand. The platform handles user provisioning (manual, CSV import, SSO via SAML or OIDC), content ingestion (SCORM 1.2 / 2004, xAPI, cmi5), course assignment, progress tracking, reporting and certificate issuance.

Architecture

  • Backend — Node.js (TypeScript) services + Postgres with schema-per-tenant isolation
  • Content storage — S3-compatible object storage with per-tenant bucket prefixes
  • Frontend — Next.js with tenant resolution at the edge, theme loaded from tenant config
  • LMS runtime — custom SCORM 2004 and xAPI player; cmi5 launcher; LRS-compatible statement store
  • Operations — single application deployment serving all tenants, scoped per tenant ID at the request level

The tenancy choice

We started on a shared database with tenant ID columns. That carried the first three tenants comfortably. The move to schema-per-tenant happened when one tenant requested per-tenant content versioning that did not interleave with others, and another wanted independent backup snapshots. Both became routine in Pattern 2; in Pattern 1 they would have been bespoke work per tenant.

White-label without code branches

The temptation in early white-label work is to fork the code per tenant. We resisted from day one. White-label is a configuration layer: tenant config holds the logo URL, color tokens, font choices, email templates and certificate templates. No tenant has bespoke code paths. Custom requests become product features available to all tenants — or they do not happen.

SCORM/xAPI/cmi5 at the ingestion layer

  • Validate the package on upload (manifest schema, asset paths, max size)
  • Strip and rewrite asset URLs to point at the tenant’s CDN path
  • Sandbox the content runtime — no cross-tenant cookies, no cross-tenant requests
  • Capture SCORM API calls and translate to internal progress events
  • Capture xAPI statements directly to the LRS-backed statement store with tenant scoping
  • For cmi5: implement the launch contract correctly so AUs initialize against the right endpoint and auth token

What we would redesign

  • Earlier OpenTelemetry coverage. Some early debugging cost more than it should have because we did not have distributed traces.
  • Webhooks as a first-class feature. Tenants want completion events delivered to their HRIS / CRM. We added it later; first-class would have been cleaner.
  • A formal evaluation set for the SCORM runtime. Edge cases in real-world content packages would have been caught faster with a regression library of representative packages.

What aged well

  • Schema-per-tenant — operations are clean and per-tenant requests are easy to honor
  • Configuration-as-tenant-product — zero per-tenant code branches
  • Strict TypeScript across the codebase — refactors stayed safe across 2 years
  • Postgres-first — search, JSONB for flexible metadata, LRS-style statement store all live in the same database for most tenants

If you are planning a white-label learning product, the highest-leverage decisions are tenancy model, configuration architecture and content runtime — in that order. The rest is software engineering.

Frequently asked questions

What makes Nexia Academy white-label?

Each tenant runs on their own domain with their own branding, their own user database and their own course catalog. There is no Nexia Academy branding in the learner experience. From the learner side, the tenant is the brand.

What kinds of clients use it?

Corporate L&D teams, professional associations and certification bodies, and education companies that want their own LMS without building one. The common thread is brand-owned learning at scale without infrastructure overhead.

Working on something similar?

T-Square is an independent software engineering studio. We architect, build and operate production-grade systems for learning, AI and custom software products. Talk to a senior engineer if you’d like a second opinion on your architecture or roadmap.