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

https://cubite.io/blogs/open-edx-sizing-concurrent-learners

**By:** Amir Tadrisi
**Updated:** 2026-10-21

Concurrent learners, not registered accounts, decide how big an Open edX deployment must be. How to size one, and where Kubernetes actually comes in.

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](https://cubite.io/services/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](https://docs.tutor.edly.io/sysadmin/scale.html) 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](https://docs.tutor.edly.io/gettingstarted/requirements.html). 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

| Tier | Price | Concurrent learners | Basis for the number | Architecture |
| --- | --- | --- | --- | --- |
| Lean | $1,260 a month | Up to 1,000 | Load test: proven at 1,000 concurrent users | Dedicated application and data nodes; UAT and production kept at parity |
| Resilient | $1,850 a month | Up to 2,000 | Cubite's estimate for the tier; not load-tested | Two application nodes behind a load balancer; patch or rebuild one node while the other serves; zero-downtime deploys |
| Scale | from $3,400 a month | Elastic, scales on demand | No fixed number: capacity is added on demand on Kubernetes | Pod-level self-healing and horizontal scaling; cloud infrastructure billed through at cost |

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](https://cubite.io/services/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](https://docs.tutor.edly.io/sysadmin/scale.html) 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](https://discuss.openedx.org/t/deploying-sumac-with-tutor-on-multiple-servers-without-kubernetes/16367) 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.

## Open edX sizing questions

### How many learners can one Open edX server handle?

It depends on the server and on your peak concurrency, not on the number of registered accounts. Tutor recommends 8 GB of RAM and 4 CPUs for one server but gives no concurrent-learner figure for it, and its scaling guide says a single server's capacity is the limit. Cubite's Lean tier puts the application and the data on separate dedicated nodes rather than one server; it was load-tested at 1,000 concurrent users and costs $1,260 a month.

### Do I need Kubernetes for 2,000 concurrent learners?

Not necessarily. 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. If you self-host, Tutor documents more than one application node only on Kubernetes.

### What is the difference between registered and concurrent learners?

Registered learners have accounts; concurrent learners are signed in and making requests in the same few minutes. Servers are sized for the peak of concurrent learners, and Cubite publishes no ratio between the two because it has not measured one.

### Does Cubite charge per learner for managed Open edX?

Cubite prices managed Open edX by capacity tier, not per learner: $1,260 a month covers up to 1,000 concurrent learners.

### What hardware does Tutor require?

Tutor's documentation 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.

For provider prices and the full cost of self-hosting, read the [Open edX hosting guide](https://cubite.io/blogs/open-edx-hosting).

## Sizing an Open edX deployment?

Book a 30-minute call with your peak numbers, and we will tell you which tier covers them.

[Book a sizing call](https://cubite.io/go/book?src=open-edx-sizing)