Open edX sizing: 1,000 or 2,000 concurrent learners without Kubernetes

Short answer (updated October 21, 2026): Cubite's Resilient tier serves up to 2,000 concurrent learners on two application nodes behind a load balancer for $1,850 a month; Kubernetes is only in its Scale tier, from $3,400 a month. Lean was load-tested at 1,000 concurrent users. Cubite prices managed Open edX by capacity tier, not per learner: $1,260 a month covers up to 1,000 concurrent learners.

Cubite runs managed Open edX and publishes this guide. Tutor figures below come from Tutor's own documentation, and every Cubite figure from Cubite's published tiers.

Registered, active and concurrent learners are three different numbers

A registered learner has an account. An active learner used the platform in some period, such as a week. A concurrent learner is signed in and making requests in the same few minutes as everyone else. Servers are sized for the third number at its peak, because that is when pages slow down: an exam window, a cohort start, a live session.

Weekly users say little about that peak. Tutor's scaling guide relays an unattributed report that a large Open edX platform can serve up to 500,000 unique users a week on one virtual server with 8 vCPU and 16 GB of memory. It gives no concurrency figure for that platform; a weekly count that size can fit on one server because the users are spread across the week. There is no fixed ratio between registered and concurrent learners, and Cubite does not publish one because it has not measured one. Measure your own peak instead: count the distinct signed-in users active in your busiest few minutes, from your platform's activity logs or analytics. On Open edX, the LMS tracking log records every user event with a username and a time.

What Tutor asks for, and what it does not promise

Tutor, the official Docker-based Open edX distribution, lists a minimum of 4 GB of RAM, 2 CPUs and 8 GB of disk, and recommends 8 GB of RAM, 4 CPUs and 25 GB of disk. Those are the resources to run the platform, not a capacity rating: Tutor gives no concurrent-learner figure for either machine, and its scaling guide says the number of users a single server can serve at once is limited by that server's capacity.

Cubite's managed Open edX tiers, and the basis for each number

Every tier includes named-release upgrades rehearsed on a UAT environment before production, SSO (SAML or OIDC) implementation, SCORM, xAPI and LTI, branding, learner and course analytics, daily backups and a quarterly restore rehearsal. Lean and Resilient also include the cloud resources when Cubite hosts the platform; Scale bills cloud infrastructure through at cost. See the tiers on managed Open edX.

When you need Kubernetes, and when you do not

Tutor has two production deployment targets: tutor local, Docker Compose on one server, and tutor k8s, a Kubernetes cluster, which its scaling guide calls the recommended way to run Open edX at scale. One server can never be highly available, because it is a single point of failure.

Between those two sits a middle path: move the databases onto a dedicated data node, then run more than one application node behind a load balancer. Tutor documents the first step, offloading MySQL, MongoDB, Redis, object storage and search to dedicated services, but not the second without Kubernetes. On the Open edX forum in 2025, an operator who wanted to run Tutor across several servers without Kubernetes, for 1,500 to 2,000 concurrent users, was told by a community member that this is not officially supported or documented outside Kubernetes and would be a very complex and unsupported configuration to develop and maintain on their own. The reply's practical paths were a much bigger single server or Kubernetes.

That middle path is how Cubite's Resilient tier is built: dedicated application and data nodes, with two application nodes behind a load balancer for application-tier redundancy, up to 2,000 concurrent learners, $1,850 a month, no Kubernetes. Kubernetes earns its extra cost when your own platform standards require it, or when your peak outgrows two application nodes; that is the Scale tier.

How to size your own deployment

1. Find your peak. Count the distinct signed-in users in your busiest few minutes over a normal month and over your heaviest event.
2. Add headroom. Plan for the next peak, not the last one, and for growth before your next upgrade window.
3. Pick the tier that covers the peak. Up to 1,000 concurrent learners: Lean. Up to 2,000, or if one application node going down is not acceptable: Resilient. More, or a Kubernetes requirement: Scale.
4. Load-test before a big launch. Run the test on a UAT copy of production, not on production itself.

For provider prices and the full cost of self-hosting, read the Open edX hosting guide.