Sizing a Moodle Server: RAM, CPU and Storage for Online Courses in 2026

Getting Moodle hosting requirements wrong in either direction costs money: undersize the RAM and CPU and quiz week grinds to a crawl, oversize storage and a training provider pays for capacity it never touches. This guide breaks down exactly how much RAM, CPU and storage a self-hosted Moodle instance needs at three real-world scales — a small training provider, a mid-size school, and a 2,000-student institution — and maps each to a specific VPS tier instead of a vague "it depends."

Moodle is a PHP application backed by a relational database, and its resource profile is shaped by three things: how many users are logged in and interacting at the same time (not your total enrolment count), how much of that activity is CPU-heavy (quiz auto-grading, H5P content, report generation, cron-driven backups), and how much course content — video, SCORM packages, PDFs, submitted assignments — sits on disk. A campus with 5,000 enrolled students but only 200 concurrently active during a typical hour behaves, resource-wise, like a 200-user platform. Sizing against concurrent load rather than total headcount is the single biggest lever for right-sizing a Moodle server.

The table below maps Moodle hosting requirements — RAM, CPU and storage — to the VPS tiers available on X-Zone's VPS hosting lineup, which spans 2GB/1vCPU up to 32GB/8vCPU.

Anything beyond the Business tier's ceiling — multi-campus deployments, LMS platforms serving several thousand concurrent users, or Moodle paired with heavy video/streaming content — is a candidate for X-Zone's dedicated server line instead of a VPS, which scales from 128GB DDR4 up to 1TB DDR5 with 24x NVMe for multi-campus or heavy-media deployments.

Moodle's RAM footprint comes from three simultaneous consumers: the PHP-FPM worker pool (each active request holds a worker in memory until it completes), the database engine's buffer cache (MySQL/MariaDB or PostgreSQL, which benefits enormously from being allowed to cache hot tables like course modules and grade items), and any caching layer running in front of Moodle (Redis or Memcached for session and application caching). Underprovisioning RAM shows up as swapping under load, which is the most common cause of a Moodle server feeling fine at 9am and unusable during a scheduled 10am exam window when concurrency spikes. Full root access on every X-Zone VPS tier means an institution can tune PHP-FPM pool sizes, database buffer settings and Redis memory limits directly rather than working around a shared-hosting cap.

Moodle's CPU load is not evenly distributed across the day. It spikes hard during three predictable events: scheduled quizzes and exams (many students submitting and being auto-graded within the same window), the cron job (Moodle's background task runner, which handles notifications, calendar events and completion tracking and can be CPU-intensive on courses with heavy activity completion rules), and course backups (compressing large course files is CPU-bound, not just disk-bound). This is why vCPU count matters as much as clock speed for Moodle specifically: a 4-vCPU Basic instance handles a 150-student cohort submitting a timed quiz far more gracefully than a 2-vCPU instance with the same RAM, because concurrent PHP-FPM requests can actually run in parallel instead of queuing.

Storage on a Moodle server is driven less by student count and more by course content strategy. Text-based courses with quizzes and forums barely touch disk. Courses built around uploaded video lectures, SCORM packages, and student-submitted assignments (especially media files) can consume storage far faster than headcount growth would suggest, and Moodle's own database (grades, logs, forum posts) grows continuously and needs to be included in backup sizing, not just course files. The storage figures in the table above assume a realistic mix of documents, SCORM content and moderate video use; institutions planning primarily video-based delivery should size up a tier for storage headroom even if RAM and CPU needs would otherwise fit a smaller plan.

The alternative to sizing your own server is a hosted Moodle subscription billed by active-user tier, where the recurring fee scales with enrolment regardless of actual concurrent usage. Self-hosting on a VPS decouples cost from headcount: a 2,000-student institution on the Business tier pays a fixed EUR58/mo whether 50 or 500 of those students are active in a given hour, with full root access to configure the stack, no per-seat fee schedule, and no migration lock-in if the institution later needs to move to a larger server or a different provider. For institutions just testing the self-hosting model before committing, the Nano and Micro tiers on X-Zone's VPS hosting line (EUR4-6/mo) are a low-risk way to validate a pilot before stepping up to the Starter or Basic tiers once real usage confirms the fit.

Student records, grades and submitted coursework are personal data under GDPR, and institutions in the EU (or serving EU students) increasingly need to demonstrate where that data physically lives. X-Zone lets customers pick the specific datacenter city for their instance from 12 available locations across Europe and the US, including Frankfurt, Amsterdam and Vienna — so a school can deploy its Moodle VPS in an EU data center and keep student data within the region for the lifetime of the instance. The full list of available cities is on the locations page.

Sizing is only half the job; the server also needs a LAMP or LEMP stack (Linux, Apache or Nginx, MySQL/MariaDB or PostgreSQL, PHP with the extensions Moodle requires), a caching layer, and a TLS certificate before Moodle installs cleanly. Full root access and a choice of Ubuntu, Debian, CentOS, AlmaLinux or Rocky as the base OS covers every common Moodle installation guide without fighting a locked-down shared host. The same root-access, full-stack-control model applies to any self-managed application beyond Moodle, on the same VPS lineup covered above.

Moodle hosting requirements scale with concurrent users, not total enrolment, which is exactly why a one-size-fits-all recommendation doesn't work: a 50-student pilot, a 500-student school, and a 2,000-student institution need genuinely different RAM, CPU and storage, not just a bigger invoice. X-Zone Servers' VPS lineup covers that entire range on one predictable, root-access line, with EU datacenter options for institutions that need student data to stay in-region, and a clear upgrade path to dedicated hardware once an institution outgrows the largest VPS tier.