Moodle Hosting Requirements in 2026: PHP, Database, Server and Storage

Moodle hosting requirements in 2026 depend on the branch you run. Moodle 5.3 LTS needs 64-bit PHP 8.3 or 8.4 with about 20 standard extensions, max_input_vars of at least 5000, and PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019. The official minimum hardware is modest (512 MB of RAM, 1 GB or more recommended, and at least 5 GB of disk), but any real site needs far more, set by concurrent users, quiz peaks and file storage rather than by total accounts.

This article lists the exact software requirements for each supported branch, then explains how to choose the server layout, storage, caching and PHP settings for a Moodle site, and which signs tell you it is time to move to the next tier. For server sizing tables across learner counts, see our companion article on LMS hosting requirements; this one focuses on what is specific to Moodle.

Requirements were checked against the Moodle 5.3 release notes, the 5.3.0 environment checks and docs.moodle.org in October 2026.

Moodle software requirements by version

All branches require 64-bit PHP. Amazon Aurora MySQL is supported and is configured with standard MySQL version numbers rather than Aurora's internal versions. The database table prefix is limited to 10 characters. If you are choosing a version for a new site in late 2026, choose 5.3: it is the current LTS, with security fixes until 1 October 2029, and our Moodle guide explains the support calendar in full.

PHP extensions and settings Moodle checks

The installer and the environment page check PHP before Moodle will install or upgrade. These are the requirements for 5.3, which are the same extension list as 4.5 to 5.2.

Required extensions

iconv, mbstring, curl, openssl, ctype, zip, zlib, gd, simplexml, spl, pcre, dom, xml, xmlreader, intl, json, hash, fileinfo, sodium and filter, plus the driver for your database (pgsql, mysqli or sqlsrv). tokenizer, soap and exif are recommended. On most Linux distributions the missing ones are usually intl, sodium, zip and gd, each a separate package.

PHP settings

If you run PHP-FPM, remember that its pool configuration and the CLI php.ini are separate from the web server's. A common failure is a site that passes the environment check in the browser while cron, run by the CLI, uses different limits.

Web server and directory layout

Apache, Nginx and OpenLiteSpeed are all documented options. Whichever you use, the layout rules are the same:

• Serve only the public directory on Moodle 5.1 and later. The project root, with config.php, Composer files and the CLI scripts, must not be web accessible. Do not end $CFG->wwwroot in /public; Moodle rejects it.
• Configure the router. Recent versions route some URLs through r.php. Set up the web server rule (for Nginx, falling back to /r.php) and set $CFG->routerconfigured once it works; 5.2 and later check for it.
• Keep moodledata outside the web root, writable by the web server user. Keep the code owned by root and not writable by the web server.
• Run Composer on 5.1 and later. Some dependencies are installed with Composer, so deployment includes composer install --no-dev --classmap-authoritative in the project root.
• Terminate TLS properly. If a load balancer or proxy handles HTTPS, enable sslproxy (and reverseproxy where needed) in config.php so Moodle builds correct URLs.

Database choices for Moodle

PostgreSQL, MySQL and MariaDB are all well supported, and the right choice is usually the one your team already operates well. Our own default for new self-hosted sites is PostgreSQL, because it handles Moodle's heavier reporting queries well, but a well-tuned MariaDB or MySQL server runs large Moodle sites too. SQL Server is supported for organisations standardised on Microsoft.

For the MySQL family, use the utf8mb4_unicode_ci collation, the InnoDB engine with per-table files and large prefixes (all checked by the installer), and a max_allowed_packet large enough for session data if you store sessions in the database. Whatever the engine, give the database dedicated memory and fast disks, and turn on the slow query log; database contention is the most common cause of a Moodle site that slows down under load.

Storage: moodledata, backups and file growth

moodledata holds every uploaded file, SCORM package, backup and cache. It grows with content and with backups, and it is what makes Moodle sites run out of disk unexpectedly. Plan for it explicitly:

• Size for content plus backups. Automated course backups are stored in moodledata unless you point them elsewhere, and they multiply quickly on sites with many large courses.
• Keep caches on fast local storage. On a single server that is simple. On a cluster, the main dataroot and the temp, cache and backup temp directories must be shared by all nodes, while localcachedir stays local to each node.
• Consider object storage at scale. Large sites often move file content to object storage with a third-party plugin, keeping the shared filesystem small. Test restores when you do this.
• Back up all three parts together: code, moodledata and a database dump, taken at the same time so they match.

Choosing a Moodle hosting layout

Most Moodle sites move through three layouts as they grow. Rather than fixed user counts, which vary too much with usage patterns, use the signals in the last column to decide when to move up.

The figure that drives sizing is concurrent active users, especially during quizzes and deadlines, not the number of accounts. A site with 50,000 accounts and steady daily use can need less than a site with 5,000 students who all start an exam at 9:00. Load test with your own course structure before a big launch; our Moodle performance optimisation guide explains how we profile and tune before buying more hardware.

Monitor before you need to

Whatever the layout, collect the same few measurements from day one: CPU and memory on each server, database connections and slow queries, PHP-FPM worker usage, disk space on moodledata, and how long scheduled tasks take to run. Moodle 5.2 and later can also send traces through OpenTelemetry. With a few weeks of history you can see a peak coming and resize ahead of it, instead of discovering limits during an exam.

Cron, caching and sessions

• Cron: run php admin/cli/cron.php every minute from the project root. On clusters, run cron on dedicated nodes rather than every web node, and set the cron keep-alive to 0 if you use dedicated task runners.
• Caching: core cache stores in 5.3 are APCu, File, Redis, Session and Static. Redis is the usual choice once you have more than one web node or slow storage.
• Sessions: database or file sessions work on a single server; use the Redis session handler for clusters, with locking settings appropriate to your traffic.

Managed hosting, MoodleCloud or self-hosting

You can run Moodle on your own servers or cloud VMs, buy managed Moodle hosting from a partner, or use MoodleCloud, Moodle HQ's hosted service. MoodleCloud is simple but does not allow you to install plugins or integrations, so it suits only sites that can live with core features. Self-hosting or managed hosting is the route for anything customised. Whichever you choose, ask the provider which Moodle branches and PHP versions they support, how quickly they apply minor security releases, and how backups are tested.

How we can help

We set up and run Moodle hosting for organisations that need control over their data: server and database sizing, Redis and caching, clustering, backups and monitoring, plus upgrades across major versions. See our Moodle services or contact us with your expected users and peak patterns, and we will recommend a hosting layout.