Moodle Hosting: Requirements, Costs, and Pitfalls in 2026
PHP 8.3, minute-by-minute cron, and moodledata outside the public folder: discover what separates a Moodle hosting plan that survives exam week from one that crashes.
by Cleverson Gouvêa

Choosing Moodle hosting is an infrastructure decision, not a matter of plan price. The same server that effortlessly runs an institutional WordPress site can crash an environment with 300 concurrent students during a Thursday exam. This guide compiles the official requirements for 5.x versions, realistic server sizing, the hidden costs often omitted from comparison tables, and migration pitfalls I've seen cost an entire semester for an institution.
TL;DR
- Moodle 5.2, released on 04/20/2026, requires 64-bit PHP 8.3+, the
sodiumextension, andmax_input_varsgreater than or equal to 5000.- Minimum databases for the 5.2/5.3 line: PostgreSQL 16, MySQL 8.4, MariaDB 10.11. Oracle support was dropped in 5.0.
- Moodle 5.3 is due on 10/05/2026 and will be the next LTS. Upgrades are only possible from 4.5 or higher.
- A minute-by-minute cron job and
moodledataoutside the public folder are mandatory — and this is precisely where shared hosting often fails.- MoodleCloud ranges from $170/year (50 users) to $2,150/year (750 users), with no custom plugins or themes.
- Standard shared hosting fails on these two points; managed Moodle hosting or a VPS with a dedicated sysadmin are the viable paths.
Why Moodle Hosting is a Different Problem
An institutional website is, in practice, read-only. An LMS is write-intensive: every student click logs data, every quiz attempt opens a transaction, every assignment submission moves a file. Moodle is a stateful PHP application with a relational database under pressure and an asynchronous task queue that needs to run continuously.
Contracting Moodle hosting based on average access is a classic mistake. Add to this the typical load pattern in education. Demand isn't distributed evenly: it concentrates during exam windows, submission deadlines, and the first days of the semester. An environment serving 2,000 students over a week might receive 400 concurrent sessions in a specific hour — and that hour defines the sizing.
The US context has made this even more critical. While specific US figures vary by state and institution, the trend mirrors what's seen in other markets. For instance, in Brazil, the 2024 Higher Education Census by Inep reported that distance learning (EAD) accounted for 50.7% of undergraduate enrollments nationwide, surpassing in-person learning for the first time, with a 5.6% increase over 2023. In technology courses, 82.6% of enrollments are already distance learning. The VLE is no longer just course support; it is the course. When it goes down, operations cease.
I've worked with Moodle since 2008 and have administered EAD environments in production for over a decade. The calculation almost no one makes when contracting Moodle hosting: how much does an hour of downtime during exam week cost, factoring in rescheduling, support, and institutional reputation damage? Typically, this number is greater than the annual difference between a cheap plan and an adequate one.
Official Moodle 5.x Requirements in 2026
Moodle requirements aren't vendor opinions — they're published in the release notes. And they've increased rapidly in recent cycles. Anyone who contracted hosting in 2023 and hasn't kept up is likely running PHP and a database below the minimum.
| Item | Moodle 4.5 LTS | Moodle 5.1 | Moodle 5.2 / 5.3 LTS |
|---|---|---|---|
| Release | 10/07/2024 | 10/06/2025 | 04/20/2026 · 10/05/2026 |
| Minimum PHP | 8.1 | 8.2 | 8.3 (supports 8.4) |
| PostgreSQL | 13 | 15 | 16 |
| MySQL | 8.0 | 8.4 | 8.4 |
| MariaDB | 10.6.7 | 10.11 | 10.11 |
| SQL Server | 2017 | 2017 | 2019 |
| Oracle | supported | removed | removed |
Any Moodle hosting contracted today should already be at the level of the rightmost column — not the middle one. Source: Moodle release notes. Three details often overlooked:
- Only 64-bit PHP is supported. Legacy 32-bit environments are out.
- The
sodiumextension is mandatory. Its absence is the most common cause of stalled installations on manually configured VPS. max_input_varsmust be ≥ 5000. With the default PHP value (1000), large forms — question banks, batch grades — silently lose data. It doesn't throw an error; it simply saves less than you entered.
The Calendar That Defines Your Upgrade
Moodle releases major versions in April and October, and minor versions every two months (February, April, June, August, October, December). Minor versions carry security fixes.
The dates that matter now: 4.5 LTS receives security fixes until 10/04/2027; 5.0 ends security support on 10/05/2026; 5.1 exits general support on 10/05/2026 and continues with security until 04/19/2027. 5.3 LTS arrives on 10/05/2026 and requires an upgrade from 4.5 or higher — anyone on 4.4 or below faces an intermediate upgrade jump. I've already detailed this version and LTS logic in the case of UFBA's Moodle and the VLE upgrade cycle.
Sizing: How Much RAM, CPU, and Disk Your Environment Needs
The official documentation is honestly conservative: 200 MB for the code, "5 GB is probably a realistic minimum" for disk space, a minimum 1 GHz CPU (2 GHz dual-core recommended), and a minimum 512 MB of RAM, with 1 GB recommended and "8 GB or more on a large production server".
These numbers are for initial installation, not for ongoing operation: a real Moodle hosting setup needs more headroom. What I use as a starting point in production:
- Up to 500 students, light usage: 2 vCPU, 4 GB RAM, 20 GB SSD. Suitable for corporate training and small schools.
- Up to 5,000 students: 4 vCPU, 8–16 GB RAM, 50–100 GB SSD, with Redis in a separate process and the database on the same machine only if there's ample RAM.
- Above that: database on its own server, two or more application nodes behind a load balancer, and
moodledataon shared storage with local caching.
Disk space is the most underestimated item in Moodle hosting. Video lectures, PDF materials, and video assignment submissions grow unchecked, and Moodle's automatic backup duplicates the course volume within moodledata itself if you don't move the files externally. I've seen environments halt due to full backup disks — not from lack of resources, but from lack of a retention policy. The case of content deletion in UFOP's Moodle clearly illustrates the cost of treating backup as a minor detail.
Regarding investment priority, the performance documentation is direct: first RAM, then faster disk, only then the processor. Upgrading the CPU before addressing memory is money spent in the wrong place.
Cron, moodledata, and Cache: Where Cheap Hosting Fails
There are three technical requirements that separate Moodle hosting that works from hosting that merely installs the system.
1. Minute-by-Minute Cron
Moodle's documentation is explicit: the site will not function correctly if the cron script doesn't run regularly. The recommendation is to execute admin/cli/cron.php every minute, and via the command line (php -f), not via HTTP request — calling it via HTTP consumes more memory in large installations and is subject to web server timeouts.
Without a proper cron: forum emails won't send, quiz grades won't finalize, scheduled backups won't run, badges won't be issued, and reports will be outdated. And the worst part — no error appears on screen. The environment just seems to work.
Many shared plans limit cron to every 15 or 30 minutes, or prohibit CLI execution. This alone eliminates the plan from any list of viable Moodle hosting.
2. moodledata Outside the Public Area
The data directory cannot be within the folder served by the web server. If it is, student submissions, backups, and session files become accessible via URL. This is a security and privacy (e.g., CCPA or state privacy laws) failure, with student personal data exposed.
Shared hosting control panels that only provide access to public_html make this impossible to do correctly. The documentation also warns that placing moodledata on NFS can lead to performance issues with the default cache configuration.
3. RAM Cache
Moodle uses MUC (Moodle Universal Cache). By default, it writes to disk. The official recommendation is to move it to memory with Redis or Memcached — the documentation itself notes that installing Redis was "the single biggest improvement" made to a medium-sized Moodle site.
Worthwhile additions: OPcache enabled in PHP (the documentation explicitly asks for this to be checked), memory_limit above the default 128 MB — backup and restore operations will exceed this value — and, in MySQL/MariaDB, the InnoDB buffer pool generously sized, potentially reaching 80% of memory on a dedicated database machine.
MoodleCloud, VPS, or Managed Moodle Hosting: How to Choose
There are four ways to contract Moodle hosting today, and they solve different problems.
| Model | Typical Cost/Year | Plugins & Themes | Who Administers | Best For |
|---|---|---|---|---|
| MoodleCloud | $170 to $2,150 | Not allowed | Moodle HQ | Small classes, testing, no customization |
| Standard Shared Hosting | $40 to $120 | Yes, if compatible | You | Almost nothing in production |
| Self-Managed VPS | $240 to $1,200 | Yes | You | Teams with a sysadmin |
| Managed Hosting | By proposal | Yes | Provider | Institutions without an infrastructure team |
MoodleCloud is the official service from Moodle HQ and works well within its scope: Starter $170/year (50 users, 1 GB), Mini $280 (100 users), Small $500 (200 users, 5 GB), Medium $1,220 (500 users, 20 GB), and Standard $2,150/year (750 users, 50 GB). The limitation is clear: it does not run third-party plugins or custom themes, and billing is in Australian dollars — factor in exchange rates and international transaction fees for your budget.
Traditional shared hosting is the option that appears cheapest but delivers the least. It fails on cron, fails on moodledata, rarely offers Redis, and almost always imposes process limits that crash the environment precisely at peak times.
A bare VPS is excellent — if there's someone on the team to update the kernel, renew certificates, monitor cron queues, tune InnoDB, and keep up with Moodle security alerts. Without that person, a VPS is technical debt with interest.
What It Really Costs (and When Not to Migrate)
The price of a Moodle hosting plan is the smallest part of the bill. What usually comes up afterward:
- Migration: Exporting, importing, revalidating plugins, re-pointing DNS, and reviewing themes. One to five days of work.
- Version Upgrade: With custom plugins, a testing and approval cycle per release. Twice a year if you follow the main line; less if you stick to LTS.
- Certificate, WAF, and Monitoring: Inexpensive individually, forgotten until an incident occurs.
- Offsite Backup Retention: Grows with your content, every semester.
- Support Hours: The real cost is your coordinator's time resolving issues that should have been handled by the provider.
And the flip side — when not to migrate:
- On the eve of an assessment period. Migrations should be done during low-activity windows, with a relaxed semester schedule. Never during exam week.
- Without a plugin inventory. Document what's installed and if each item has a compatible version for the destination. Abandoned plugins are the #1 reason for migrations that revert.
- Without a tested restore. A backup that has never been restored isn't a backup; it's just a file.
- If the problem is configuration, not the server. Slowness due to disabled cache, active debug logging in production, or expensive report queries isn't solved by changing hosts — it's solved by adjusting Moodle. Migrating in this case only moves the problem's address.
A specific pitfall: since Moodle 4.3, the database prefix ($CFG->prefix) has a limit of 10 characters. Older installations with long prefixes will halt during upgrade — and the error appears mid-process, not beforehand. Environments coming from 3.x versions often also have tables in utf8 instead of utf8mb4, which requires conversion. The PVANet UFV upgrade that I analyzed here clearly illustrates the scale of an institutional version jump.
How Agathas Web Solves This
We built our managed Moodle hosting around the requirements above — it's not a generic website plan with Moodle simply installed on top. See what's included.
What runs underneath: PHP 8.3 with OPcache and PHP-FPM, Nginx, MariaDB 10.11+, and Redis for MUC and sessions. In other words, the environment is born meeting Moodle 5.2/5.3 requirements, without needing an emergency upgrade during LTS launch week.
Security and Continuity: Cloudflare WAF, Let's Encrypt SSL, Fail2ban, AES-256 encryption, daily backup with 15-minute binlog, and encrypted offsite copy. moodledata is outside the public web root by default — it's not a configuration option; it's how the environment is delivered.
Operation: Monitoring with Grafana, Prometheus, Sentry, and UptimeRobot. The goal is to detect slowness before a student complains, not after a ticket is opened. The SLA is contractual: 99.9% uptime, critical incident response within 15 minutes, resolution within 2 hours, and LTS update within 90 days of release — for 5.3, this means being updated still within 2026.
Plans: Starter (up to 500 students, 5 GB SSD), Professional (up to 5,000 students, 20 GB SSD, priority WhatsApp support, and 24/7 monitoring), and Enterprise (over 50,000 students, dedicated infrastructure, load balancer, WAF, and real-time backup). Staging and training environments are included starting with the Professional plan.
How to contract: Moodle hosting is contracted by proposal. Through the product page, you can request a quote or ask for assisted migration, which we complete within five days — including plugin inventory, data copy, staging environment validation, restore testing, and only then the DNS cutover. Beyond hosting, we also provide performance consulting for those who wish to keep their existing environment and only resolve bottlenecks.
Conclusion: Decide by Peak, Not Average
LMS hosting should be sized for the worst day of the semester. Before signing any plan, ask the provider five questions: what are the PHP and database versions, how often does cron run and by what method, where is moodledata located, if Redis is available, and what is the written SLA with a version update timeline. If any answer is vague, it will turn into a support ticket during exam week.
With Moodle 5.3 LTS arriving in October 2026 and requiring PHP 8.3, PostgreSQL 16 or MariaDB 10.11, and an origin of 4.5 or higher, the window to get your house in order is now — during the semester break, calmly. If you want us to take on this part, start with Agathas Web's managed Moodle hosting — view the plans and SLA and request a diagnostic of your current environment.
Related posts
Migrate Moodle to a New Server: No Data Loss, No Downtime
A blueprint for LMS operators: the three critical components, the pre-migration rehearsal, and a cutover window measured in minutes.
Slow Moodle: Real Causes and How to Diagnose
Before upgrading your Moodle server, measure. The most common causes of slowness are configuration issues—and cost nothing to fix.
Moodle on AWS vs. Managed Hosting: The True Cost
Your EC2 bill is just the starting point, not the total price. Egress, NAT Gateway, and staff time are the real cost drivers — and often overlooked.