To run Moodle 5.3 in 2026, use a 64-bit server with PHP 8.3 or 8.4, the sodium extension, max_input_vars set to at least 5000, and a supported current database: PostgreSQL 17, MySQL 8.4, MariaDB 11.4.0, Aurora MySQL 8.0, or Microsoft SQL Server 2019. Moodle’s published baseline is only 512 MB of RAM, a 1 GHz processor, 200 MB for the application code and about 5 GB for content; a real production site normally needs more capacity based on enrolment, concurrent activity, file storage, reports and plugins.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
The practical choice is usually a Linux virtual machine or managed Moodle host running Apache or Nginx, with moodledata outside the web root, reliable SSD storage, scheduled cron and tested backups. The exact requirements below are for the Moodle 5.3 release line current in October 2026, not older Moodle guides.
As an Amazon Associate I earn from qualifying purchases.
What Moodle 5.3 requires in 2026
Moodle 5.3 is the current release target for this guide. Its minimums are substantially newer than requirements quoted in many older hosting articles. Treat them as compatibility floors, not a promise that a busy school, university or corporate academy will perform well at those limits.
Required PHP version and build
- PHP 8.3.0 or later is required.
- PHP 8.4 is supported.
- PHP must be a 64-bit build.
- The
sodiumPHP extension must be enabled. max_input_varsmust be at least5000.
Check the command-line PHP and the PHP instance used by your web server separately; a server can have multiple PHP versions installed, and changing the CLI binary does not necessarily change Apache, Nginx or IIS. A quick CLI check is php -v, followed by php -m to look for sodium and php -i | grep max_input_vars to verify the setting. Confirm the same values through your hosting control panel or a temporary, access-controlled PHP information page before installation.
#1 Best Overall
Supported database versions
| Database | Moodle 5.3 minimum | Operational note |
|---|---|---|
| PostgreSQL | 17 | Use a current 64-bit server build and a dedicated Moodle database and user. |
| MySQL | 8.4 | Configure the database and tables for full Unicode support. |
| MariaDB | 11.4.0 | Do not assume an older MariaDB supplied by budget hosting is sufficient. |
| Amazon Aurora MySQL | 8.0 | Confirm the exact Aurora engine and compatibility mode offered in your region. |
| Microsoft SQL Server | 2019 | The detailed Moodle 5.3 release table identifies 2019 as the minimum. |
The Moodle download page has displayed “MSSQL 2030” for this release, but the detailed 5.3 release information lists SQL Server 2019. Until Moodle corrects that label, use SQL Server 2019 as the documented minimum rather than treating “2030” as a real requirement. Oracle is no longer supported from Moodle LMS 5.0 onward.
Upgrade prerequisite
If you are upgrading rather than making a new installation, the source site must be Moodle 4.4 or later before moving to 5.3. Plan the intermediate upgrade, plugin compatibility checks and rollback backup before changing the production code or database.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Hardware: baseline versus a usable production server
Moodle lists 200 MB for the program code, 5 GB as a realistic minimum for content storage, a 1 GHz processor and 512 MB of RAM. Its recommendations are a 2 GHz dual-core processor or better and at least 1 GB of RAM; a large production server is likely to need 8 GB or more. These numbers describe an installation starting point, not a supported user count or performance guarantee.
| Resource | Published starting point | How to interpret it |
|---|---|---|
| Moodle code | 200 MB | Only the application files; plugins, language packs, logs and deployment copies add space. |
| Content storage | 5 GB realistic minimum | Courses, submissions, backups, multimedia and generated files can quickly exceed this. |
| CPU | 1 GHz minimum | A 2 GHz dual-core or better processor is the practical recommendation. |
| RAM | 512 MB minimum | At least 1 GB is recommended; large production installations are likely to need 8 GB or more. |
Concurrent activity matters more than the number of accounts alone. A thousand occasional learners can use fewer resources than a smaller cohort simultaneously taking a quiz, uploading assignments, generating reports and streaming files. Measure CPU saturation, PHP worker queues, database CPU and memory, disk latency, cache hit rates and peak concurrent sessions during a representative pilot. Increase web workers, database capacity or cache resources according to the observed bottleneck instead of multiplying a generic “users per gigabyte” rule.
Rank #2
Storage and I/O
Fast local SSD or equivalent block storage is preferable for Moodle’s database, application files and moodledata. Moodle specifically warns that slow network storage such as NFS can cause serious performance problems for moodledata, which contains uploaded files, caches, sessions and temporary data. Allow headroom for course backups, restore operations, logs, antivirus scans and database growth; a 5 GB allocation can be exhausted by one media-heavy course archive.
Web server, operating system and directory layout
Moodle is commonly deployed on Linux in a LAMP-style stack: Linux, Apache, MySQL or MariaDB and PHP. Nginx, OpenLiteSpeed and Microsoft IIS are also viable when they meet the PHP, database and Moodle release requirements. Linux generally offers the broadest documentation and automation options, while IIS can fit organizations standardized on Windows.
Free tools Windows power users keep installed
One-click scans. No signup required.
Moodle 5.1 and later use a public directory for web-accessible files. Configure the web server’s document root or routing so that only Moodle’s public directory is served. Do not point the virtual host at the project’s parent directory, because configuration files and private application content should not be directly downloadable.
Filesystem rules
- Place
moodledataoutside the web-accessible document root. - Give the web-server process write access to
moodledata. - Keep Moodle program files non-writable by the web-server user in production whenever your deployment process allows it.
- Use a dedicated database and a non-root database account with only the permissions Moodle needs.
- Set the database and connection to an appropriate Unicode collation, such as
utf8mb4_unicode_cifor MySQL-compatible deployments.
Separating private data from the document root is a security boundary, not merely a recommended folder arrangement. Test downloads, course-file access and error handling from an unauthenticated browser after deployment to ensure private files are not exposed.
Rank #3
- Used Book in Good Condition
A practical installation checklist
- Choose the operating environment. Select a Linux VM, dedicated server, cloud instance or managed Moodle service with control over the required PHP and database versions. Confirm whether the host supplies 64-bit PHP 8.3 or 8.4 rather than an older default.
- Provision the database. Create a database using a supported engine and version, create a separate non-root Moodle user, apply the required Unicode settings and restrict network access to the application servers.
- Install and verify PHP. Enable
sodium, setmax_input_vars = 5000or higher, and check upload, memory and execution limits against the size of your courses and administrative forms. Verify the PHP-FPM or Apache module used by the site, not only the shell version. - Configure the web server. Set the virtual host’s document root to Moodle’s
publicdirectory, enable HTTPS, pass requests to the correct PHP handler and configure URL rewriting as required by your chosen web server. - Create protected storage. Make
moodledataoutside the web root, assign write permission to the web-server account and place it on storage with predictable low latency. - Run the installer. Supply the database credentials, site URL, administrator account and paths. Resolve every environment check before proceeding; do not dismiss a PHP extension, version or permission warning that Moodle identifies as required.
- Schedule cron. Moodle’s background jobs handle tasks such as notifications, cleanup, statistics and queued processing. Use the documented command-line cron schedule for your installation and monitor failures instead of relying only on page-triggered tasks.
- Back up and test recovery. Back up the database, Moodle code, configuration and
moodledataaccording to their different change rates. Perform a restoration on a separate system so you know the backups are usable. - Load-test before launch. Reproduce peak logins, quiz attempts, assignment uploads and reporting. Record response time, PHP worker utilization, database waits, disk latency and memory pressure, then resize before learners depend on the service.
Can Moodle run on shared hosting?
It can, but only when the shared host exposes the exact release requirements and gives you enough control. Many shared plans provide an older PHP or MariaDB version, prohibit long-running cron jobs, restrict database settings, limit process memory or place moodledata on slow shared storage. Any one of those constraints can make Moodle 5.3 unsuitable even if a one-click installer is advertised.
Verify these items before buying a shared plan
- PHP 8.3 or 8.4, 64-bit, with
sodiumenabled. max_input_varsconfigurable to at least 5000.- PostgreSQL 17, MySQL 8.4, MariaDB 11.4.0, Aurora MySQL 8.0 or SQL Server 2019, depending on your chosen database.
- A private, writable
moodledatalocation outside the web root. - Reliable command-line cron at the required interval.
- Sufficient database connections, PHP memory, file storage, inode allowance and backup capacity for peak use.
- Permission to configure the Moodle 5.1+
publicdocument root.
Shared hosting is most defensible for a small pilot, a low-traffic internal site or a temporary test installation. For graded assessments, large file uploads, many simultaneous users or strict uptime and data-residency obligations, a VM, dedicated environment or managed Moodle platform gives you a more predictable scaling path.
Self-hosted infrastructure compared with managed Moodle hosting
The right choice depends on whether your team wants to operate the stack. A managed service can remove routine administration, but it does not remove the need to verify Moodle 5.3 compatibility, storage performance, backups and support terms.
| Decision area | Self-hosted VM or dedicated infrastructure | Managed Moodle hosting |
|---|---|---|
| PHP and database patches | Your team schedules, tests and applies them. | The provider may handle them; confirm the exact responsibility and maintenance window. |
| Moodle upgrades and plugins | Maximum control, but your team owns compatibility testing and rollback. | May be assisted or included; verify whether custom plugins and major upgrades are covered. |
| Backups and recovery | You select retention, storage and restoration procedures. | Check frequency, retention, off-site copies, restore testing and any recovery fees. |
| Performance tuning | You can tune Redis or Memcached, PHP workers, database parameters and web caching. | Some controls may be standardized or restricted; ask what can be changed. |
| Scaling | Add CPU, RAM, storage, separate web front ends or a database server as demand grows. | Scaling may be simpler, but depends on the provider’s architecture and contract. |
| Compliance and support | You control region, access and monitoring, while carrying the operational burden. | Review data residency, SLA, support coverage, incident process and certification status. |
| Total cost | Includes infrastructure, administration, monitoring, security and staff time. | Includes the service fee and any limits, migration, storage or support charges. |
When evaluating a Moodle hosting partner or Moodle Certified Service Provider, verify current certification, the service region, PHP and database versions, upgrade ownership, backup policy, plugin support, response targets and the process for exporting your data. “Managed” should describe a written operational responsibility, not just a marketing label.
Rank #4
Scaling beyond a single server
A single VM is often the simplest reliable starting architecture: web server, PHP workers, database and protected moodledata. As usage grows, separate the database from the web tier so each can be tuned independently. Multiple web front ends can then share a suitable storage and session strategy, with a load balancer distributing requests.
At larger scale, plan capacity around peak concurrent sessions and background jobs rather than registered users. Add memory for database caches and PHP workers, fast storage for database and file operations, and a supported shared caching layer such as Redis or Memcached where your design and Moodle configuration benefit from it. Keep cron and scheduled task execution observable; a cluster that serves pages quickly can still fall behind if background jobs queue up.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchCommon failure modes and fixes
“PHP version is too old”
Upgrade the PHP runtime used by the web server to 8.3 or 8.4, then recheck extensions and configuration. On hosting panels, changing the account’s selector may not change a separate PHP-FPM pool, so verify the runtime from the site itself.
Database rejected during installation
Check both engine and exact version. PostgreSQL 16, MySQL 8.0 or MariaDB 10.x may be functional elsewhere but do not meet the Moodle 5.3 minimums listed here. Confirm the database user has the required permissions and Unicode configuration.
Best Value
File uploads or forms fail unexpectedly
Set max_input_vars to at least 5000 and review PHP upload, post-size, memory and execution limits. Large courses can also expose insufficient moodledata capacity or slow storage.
Private files are downloadable
Move moodledata outside the document root, ensure the virtual host serves only public, and test an unauthenticated request to a known private path. Remove web-server aliases that expose the parent Moodle directory.
Pages become slow under simultaneous activity
Measure database waits, PHP worker saturation, CPU, memory and disk latency during the slow period. Increase the constrained resource, tune the relevant service or separate the database and web tiers; adding storage space alone will not fix CPU or database contention.
Choosing a sensible 2026 starting configuration
For a small test or low-traffic site, begin with a supported 64-bit PHP 8.3 or 8.4 environment, a current supported database, at least the recommended 1 GB of RAM, SSD storage and a reliable cron job. Reserve more than the 5 GB content baseline if users will upload media or if you will keep course backups.
For a production site with regular assessments and file submissions, start above the minimum RAM and CPU figures, use fast storage, monitor peak concurrency and keep independent backups. For a large deployment, budget for 8 GB or more of RAM as a likely starting point, then validate with a pilot and scale web, database, cache and storage tiers based on measurements. No universal server size can replace workload testing.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →
