Email:info@softosmith.com
Working Hours:Mon - Fri: 9 AM - 5 PM (PKT)
Reselling an LMS under your own brand — to your own clients — is a genuinely different architecture problem than building one for your own learners. Here's how multi-tenancy, per-tenant branding, and billing separation actually get designed.
A standard custom LMS is built for one organization's own learners. A white-label LMS is built to be resold — a training company, an agency, or a SaaS business puts the platform in front of their own clients under their own brand, with each of those clients expecting to see only their own data, their own look, and their own bill.
Organizations that deliver training or course content to multiple client companies and want each client to experience it as "their own" branded portal.
Products that need to offer training or certification as a feature to their own customer base, without building an LMS as a one-off for each customer.
Businesses whose actual product is the LMS itself — sold to many organizations at once — where every architectural shortcut around tenancy compounds with every new tenant onboarded.
This is the single most consequential decision in a white-label LMS, and it's genuinely a trade-off between isolation and operational cost/complexity — there's no option that wins on both axes.
One database, one schema, with every table carrying a tenant_id column and every query scoped by it. The cheapest to run and simplest to operate at small-to-medium scale — one set of migrations, one set of backups. The trade-off is isolation: a bug in a query's tenant filter can leak data across tenants, so row-level security or a strict ORM-level scoping layer is non-negotiable, not optional.
One database instance, but each tenant gets its own schema/namespace. This gives real isolation at the query level — a missing WHERE clause can't leak into another tenant's schema — while still sharing infrastructure and connection pools. The cost is operational: migrations now have to run against every tenant schema, and a database with thousands of schemas can hit real performance and tooling limits.
Each tenant gets a fully separate database, sometimes on separate infrastructure entirely. This is the strongest isolation model — the natural fit for enterprise clients with compliance or data-residency requirements — but it's also the most expensive to operate: every schema migration, every backup, and every scaling decision now multiplies by tenant count.
The whole point of white-labeling is that a tenant's learners never see your platform's brand — they see the reseller's. That means branding can't be a design-time decision baked into the build; it has to be data, resolved and applied at request time for every tenant.
Each tenant needs to appear at their own domain (training.theirbrand.com) or a fully custom domain, resolved at the routing layer to the correct tenant before any application logic runs.
Colors, logos, and fonts loaded per-tenant at runtime from a theme configuration record, not hard-coded or rebuilt per client — a new tenant's branding should be a data entry, not a deploy.
Enrollment confirmations, deadline reminders, and certificates sent under the tenant's own brand and sending domain, not a generic "noreply@yourplatform.com" that breaks the white-label illusion.
Two distinct privilege layers need to exist side by side: the tenant's own administrators managing their own courses and learners, and your platform-level controls for provisioning, suspending, and billing tenants — with billing tracked and enforced independently per tenant.
A tenant's own administrators need full control over their courses, learners, and branding — without ever seeing another tenant's data, and without needing the platform owner in the loop for routine changes.
A separate, higher-privilege role for you (the platform owner) that can provision new tenants, suspend one for non-payment, and see cross-tenant operational metrics without being a member of any tenant.
Each tenant's subscription, usage, and invoicing tracked independently — usually against a metered dimension like active learners or courses — so pricing tiers and payment failures are handled per tenant, not platform-wide.
A white-label LMS doesn't scale the same way a single-tenant application does — growth means more tenants, not just more users of one tenant, and that shifts what actually needs engineering attention as the platform grows.
We've built and reasoned through shared-database, schema-per-tenant, and database-per-tenant models — and can tell you honestly which one fits your tenant count and isolation needs.
Tenant theming built as configuration, not per-client code branches — so onboarding a new tenant doesn't require a developer and a deploy.
Per-tenant billing and usage metering architected alongside the data model, not retrofitted after the first reseller asks for it.
We'll tell you plainly when shared-database scoping is genuinely fine for your tenant count, instead of over-selling database-per-tenant complexity you don't need yet.
Straight answers to what clients usually ask before scoping a multi-tenant build.
A white-label LMS is a platform that a training company, agency, or SaaS business resells or sub-licenses under their own brand to their own clients — as opposed to a single-tenant custom LMS built for one organization's own learners. It's a genuinely distinct, higher-value architecture problem: the platform now needs to support many independent "customers of your customer," each with their own branding, admins, and billing.
For most platforms starting out, shared database with strict tenant_id scoping is the right starting point — it's the cheapest to build and operate, and is safe as long as scoping is enforced consistently (ideally via row-level security, not just application code). Database-per-tenant is worth the added operational cost once you have enterprise tenants requiring hard data isolation or specific compliance and data-residency guarantees.
Yes, and it's a common growth path — start shared, and migrate specific high-value tenants to their own schema or database as they need stronger isolation, without re-architecting the whole platform. This is much easier if tenant_id scoping was applied consistently from the start.
A theme configuration record per tenant — logo URL, color tokens, font choices, and email sender identity — loaded at request time based on the resolved domain or subdomain, then injected into the frontend (CSS custom properties are a common mechanism) and into transactional email templates. None of it should require a separate code branch or deploy per tenant.
Per-tenant rate limiting and resource quotas at the API layer, database connection pooling that can't be monopolized by one tenant's queries, and background job queues that process fairly across tenants rather than first-in-first-out globally. At larger scale, isolating especially heavy tenants onto dedicated infrastructure is also a valid option.
Each tenant is modeled as its own billing entity — its own subscription, usage metering (typically active learners, courses, or storage), and payment method — tracked independently, usually through a payment provider's subscriptions API, so a payment failure or plan change for one tenant has zero effect on any other tenant.
Both. Some clients need the full platform built from scratch; others already have a single-tenant LMS and need it re-architected for multi-tenancy so it can be resold. We scope either as its own engagement.
The top-level overview of our Moodle and custom eLearning development services.
Monolith vs. API-first design, backend framework trade-offs, and core domain modules for a single-tenant custom LMS.
If Moodle is actually the right fit for your use case, see our full Moodle development service instead.
Tell us about your tenant count and use case and we'll walk you through the right multi-tenancy architecture for it.
Talk Through Your Architecture
