Self-hosted LMS hosting requirements: server sizing from 1,000 to 50,000 learners

A self-hosted LMS for 1,000 learners usually runs well on one server with 4 vCPUs, 8 to 16 GB of RAM and fast SSD storage. At 50,000 learners you need several web servers behind a load balancer, a separate database server with a read replica, a dedicated Redis cache and shared file storage. The number that drives the size is not registered learners but how many people are active at the same time, especially during exams.

The software floor has also moved. Moodle 5.3, released on 5 October 2026, needs PHP 8.3 or later and PostgreSQL 17, MySQL 8.4 or MariaDB 11.4. Teams still on MySQL 8.0 or PHP 8.2 are running versions that are out of support or close to it.

This guide is for IT teams planning to host an LMS on their own servers or cloud account. It covers the current software requirements of the main open-source platforms, sizing starting points for 1,000, 5,000, 20,000 and 50,000 learners, and how to prove the numbers with a load test before go-live. Versions and requirements were checked on each project's official documentation in October 2026.

What actually drives LMS server sizing

Vendors and open-source projects rarely publish a "servers per learner" figure, and for good reason. Moodle's own installation guide says that a forum post asking what hardware is needed for 50,000 users is unlikely to get a useful answer. Two sites with the same headcount can need very different hardware. These are the variables that matter:

• Peak concurrent users. A compliance course that staff finish over a quarter creates a light, even load. A timed exam that 2,000 candidates start at 10:00 creates a spike that decides your server size on its own.
• What learners do. Quiz attempts, SCORM tracking and forum posts write to the database on almost every click. Reading a page or watching an externally hosted video costs far less.
• Video and files. Serving video from the LMS server eats bandwidth and disk. A video platform or CDN removes most of that load.
• Plugins and integrations. Reporting plugins, HR sync jobs and badly written add-ons are a common cause of slow sites. A common failure we see is one custom report that scans a large log table during peak hours.
• Background tasks. Enrolment syncs, notifications, backups and certificate generation run in cron. On a busy site they compete with learners for the same database.

So start from a concurrency estimate. Take your expected active learners, decide what share might be online in the busiest 15 minutes of the year, and size for that peak rather than the average. If you already run an LMS, your web server logs and LMS reports give you real numbers to replace the guess.

Software requirements by platform in 2026

Hardware is only half the requirement. Each platform pins minimum versions of PHP, the database and other services, and those minimums rise with new releases. The table below lists what the official documentation states as of October 2026.

Two points stand out. First, Moodle 5.1 moved the web-facing files into a /public directory, so the web server's document root must point there; upgrades from 4.x need that change in the virtual host. Second, Moodle 5.3 raised its minimums to PostgreSQL 17 and MariaDB 11.4, so check your database version before you plan an upgrade.

If you want a commercial product rather than an open-source project, a few vendors still offer a self-hosted licence. Disclosure: LMS Advisor is built by the All-in-One LMS team. LMS Advisor, our self-hosted LMS, runs on a VPS or capable shared hosting with PHP 8.1 or later and MySQL, or in the vendor's cloud, and updates are applied with in-app tools. You can see how LMS Advisor handles this on its product page. For a wider comparison, see our guide to self-hosted LMS options.

Server sizing from 1,000 to 50,000 learners

The table gives the starting points we use when scoping a self-hosted PHP LMS such as Moodle or Totara. They are planning assumptions, not benchmarks. Treat them as a first draft for your load test, and expect to adjust them for heavy exam use, video hosted on the server or a large plugin set.

The jump between tiers is less about raw CPU and more about removing single points of contention. At around 5,000 active learners the database should move to its own server. Somewhere between 10,000 and 20,000 the web tier needs a second node, which forces shared file storage and a shared session store. At 50,000, read replicas help: Moodle's performance documentation says that up to 80 to 90 percent of database load can be moved away from the primary when read replicas are enabled.

Database, cache and file storage choices

The database is where most large LMS sites hit their limit, so choose versions with a long support runway.

• MySQL 8.0 reached end of life in April 2026 with release 8.0.46. Oracle points users to MySQL 8.4 LTS, which is also Moodle 5.3's minimum.
• PostgreSQL supports each major version for five years. PostgreSQL 14 support ends on 12 November 2026, and PostgreSQL 17, Moodle 5.3's minimum, is supported until November 2029.
• PHP 8.2 receives security fixes only until 31 December 2026. PHP 8.3 is in security-only support until the end of 2027 and PHP 8.4 until the end of 2028.

For caching, Moodle's documentation describes Redis as one of the best options for the application and session caches, and recommends an effective cache such as Redis for load-balanced sites. It is not fully compatible with the request cache, so leave that on the default. Turn on PHP OPcache on every web node.

On a dedicated MySQL or MariaDB server, the InnoDB buffer pool can take up to about 80 percent of RAM according to Moodle's performance guide. Size the database server so the active part of your data fits in memory; a database that keeps reading from disk is the most common cause of slow quiz pages.

File storage grows faster than teams expect. Course backups, SCORM packages, assignment uploads and video all land in the data directory. Budget for growth, keep backups off the server, and move video to a dedicated platform early.

Cron, background tasks and exam-day peaks

Moodle expects its cron to run every minute from the command line, not over HTTP. By default only three scheduled tasks and three ad hoc tasks run at the same time; the limits can be raised in the configuration. On a large site, run cron on its own node and add a long-running ad hoc task worker, so that certificate generation, notifications and course restores do not slow down learner traffic.

Exam days need their own plan:

1. Schedule heavy jobs such as backups, report generation and HR syncs away from exam windows.
2. Scale the web tier up before the exam, not when the alerts start.
3. Stagger start times when you can. Starting 3,000 candidates in one minute is much harder than starting them over 15 minutes.
4. Watch database connections and slow-query logs during the first live exam, then adjust.

Our post on Moodle performance optimization goes deeper into tuning PHP, the database and caches.

How to load test before go-live

A load test turns the sizing table into numbers you can defend. Moodle ships a JMeter test plan generator under Site administration, Development, Make JMeter test plan, with a command-line version in the tool_generator plugin. It creates test courses and a plan in sizes from XS to XXL. The documentation is clear that it is a developer tool: it only works with debugging set to developer level, and the older Moodle developer docs warn that these tools load the server to its limit and beyond. Never run it against production.

A practical approach:

1. Build a staging environment that matches production in versions and configuration, with a copy of real courses if your data policy allows it.
2. Script the journeys that matter most: login, opening a course, a quiz attempt, a SCORM launch and a forum post.
3. Ramp up to your planning peak, then to 1.5 times that peak, and record response times and errors.
4. Find the first resource to saturate, whether CPU on the web nodes, database connections, disk I/O or Redis memory, fix it, and repeat.

Keep the results. They are the evidence your security and procurement teams will ask for, and they give you a baseline for the next upgrade.

On-premise, cloud VM or managed hosting

Self-hosting means you own every layer below the LMS. Before you commit, check that someone owns each item on this list.

A cloud VM gives you elastic capacity for exam peaks and managed databases that handle backups and replicas. On-premise hosting suits organisations with strict data-residency rules or existing data centre teams. Managed hosting from a platform partner shifts patching and monitoring to someone else while keeping the open-source licence. When you compare the options, use our LMS features checklist so the hosting decision does not quietly remove a feature you need.

How we can help

We size, build and tune self-hosted LMS environments, from a single Moodle server to load-balanced clusters with read replicas, and we run the load tests that prove them. If you need changes to the platform itself, our LMS customization team can quote for that too. Tell us your learner numbers and peak events, and we will suggest an architecture and an estimate.