Moodle Server Requirements by Concurrent Users, and What Hosting Costs per Month

Every Moodle sizing conversation starts with the wrong number: the enrolment count. A university with 20,000 enrolled students may have 400 of them in Moodle at 10 a.m. on a Tuesday and 3,000 during an exam, and the server has to be sized for the second figure, not the first. This guide takes Moodle's published requirements, checked on 1 November 2026, and turns them into three configurations on MassiveGRID PaaS, built on Virtuozzo Application Platform (formerly Jelastic), with the monthly cost of each.

What Moodle publishes

Moodle's installation page keeps the hardware section short. Disk: 200 MB for the Moodle code plus as much as you need for content, with 5 GB as a realistic minimum. Memory: 512 MB minimum, 1 GB or more recommended, and the note that a large production server is likely to want 8 GB or more. Processor: 1 GHz minimum, 2 GHz dual core or more recommended. The database can be PostgreSQL, MariaDB, MySQL or MSSQL; the supported PHP and database versions are in each release's notes rather than on the page.

What the page does not give is a users-per-gigabyte rule, and it is right not to, because Moodle's load depends on what the users do. A hundred students reading course pages is light; a hundred students sitting a timed quiz with auto-save every minute, or watching embedded video through the file API, is heavy. The moodledata directory, where uploads and course backups live, is the other variable: it grows with every submitted assignment and is where the disk estimate goes wrong.

Sizing by concurrent users, not enrolments

The useful planning figure is peak concurrent users, which most institutions can read from their current LMS analytics or estimate as 2 to 5% of active enrolments on an ordinary day and 15 to 25% on an exam day. Three bands cover most deployments.

Up to about 50 concurrent users, a school or a department: one PHP node with 1 GiB, a 512 MiB database, and attention to PHP's OPcache. A few hundred concurrent users, a college or a faculty: 2 GiB for PHP, 1 GiB for the database, and Redis for sessions and the application cache, which the Moodle performance recommendations push hard. Thousands at a peak, a university at exam time: several PHP nodes behind a load balancer with shared moodledata and a database on its own node, which the exam-week scaling post builds step by step.

The three configurations on PaaS and their cost

The Moodle package on MassiveGRID PaaS installs a PHP application server, a database node and persistent moodledata storage, with a platform subdomain and certificate. Cloudlets are 128 MiB RAM plus 400 MHz CPU, billed at $0.003372 per cloudlet-hour ($2.46 per cloudlet-month), no licence fee.

Because billing is hourly for the cloudlets actually used, a Moodle on the Production allocation that idles at 1.5 GiB through the summer is billed for 1.5 GiB through the summer; the table is the ceiling. Moodledata disk is billed per gigabyte on top. Price a different topology or an academic-year schedule in the PaaS pricing calculator.

The settings that matter more than the server

Moodle's performance guidance is mostly about configuration, and three settings buy more than the next cloudlet. OPcache on the PHP node, enabled in the package, removes most of PHP's compile cost. Caching stores: point the application and session caches at Redis instead of the file store, which on a multi-node Moodle is not optional, because file-based sessions do not survive a load balancer. Cron must run every minute, from one node only on a cluster, or notifications, grades and backups silently stop.

On the database side, Moodle wants InnoDB with the full UTF-8 character set and a buffer pool that holds the hot tables; the Standard row's 1 GiB covers a college, and the Production row's 2 GiB a university's grade tables. Scheduled course backups write to moodledata and are the usual cause of a full disk, so set the backup retention and watch the per-gigabyte line.

Upgrades, plugins and the clone

Moodle releases twice a year and plugins break on both occasions, which is why institutions fall behind. On the platform, the environment can be cloned in minutes, the clone upgraded and tested with real course data, and production upgraded only once the clone passes; the upgrade post is the runbook. The clone is billed only for the hours it exists, which for a weekday rehearsal is a few dollars.

For an institution comparing this with MoodleCloud, the 8,000-student comparison prices both for a full academic year; the short version is that per-user SaaS pricing and per-cloudlet hosting cross somewhere in the low hundreds of users, and that self-hosting is also where plugins, integrations and data residency stop being someone else's decision.

Frequently Asked Questions

How much RAM does Moodle need?

Moodle's installation page, checked on 1 November 2026, gives 512 MB as the minimum and 1 GB or more as the recommendation, with 8 GB or more likely on a large production server. On MassiveGRID PaaS the Starter configuration allocates 1 GiB to the PHP node, Standard 2 GiB and Production two 3 GiB nodes behind a load balancer.

How many concurrent users can one Moodle server handle?

It depends on the activity more than the server: reading course pages is light, timed quizzes and video are heavy. As a planning band, a 1 GiB PHP node serves tens of concurrent users, a 2 GiB node a few hundred, and exam peaks of thousands need several PHP nodes behind a load balancer with Redis sessions and shared moodledata.

What does Moodle hosting cost per month?

On MassiveGRID PaaS, about $29.52 for the Starter configuration, $59.04 for Standard and $167.28 for the Production layout, at $0.003372 per cloudlet-hour before volume discounts, plus moodledata disk per gigabyte. Moodle itself is open source with no licence fee.