Moodle hosting and updates: choosing a version and planning for performance

LTS or the latest release?

Moodle publishes major releases on a regular cycle, sets an end of general support (bug fixes) and an end of security support for each, and marks some as LTS (long-term support). The releases below follow the official release schedule at the time of writing (November 2026). The schedule changes over time, so check the official releases page (https://moodledev.io/general/releases) before any decision.

• 4.5

  Release date: October 7, 2024 — End of bug fixes: October 6, 2025 — End of security support: October 4, 2027 — LTS: Yes

• 5.1

  Release date: October 6, 2025 — End of bug fixes: October 5, 2026 — End of security support: April 19, 2027 — LTS: No

• 5.2

  Release date: April 20, 2026 — End of bug fixes: April 19, 2027 — End of security support: October 4, 2027 — LTS: No

• 5.3

  Release date: October 5, 2026 — End of bug fixes: October 4, 2027 — End of security support: October 1, 2029 — LTS: Yes

How to read the release schedule

If you are building a new platform and want longer stability, the latest LTS release (currently 5.3) gives you the longest security support. Anyone currently on 4.5 has security support until October 2027, but should plan the move well before then. Non-LTS releases suit teams that update continuously and can upgrade every few months. The rule: never keep a live platform on a release whose security support has ended.

Plugins constrain upgrades

Every plugin you install (theme, payment gateway, or virtual classroom component) must support the version you are moving to. Before upgrading, check: does each plugin have a compatible version? And who maintains it? Many plugins and customizations make upgrades slower and more expensive, so install only what you need.

Server requirements

Each release has minimum versions of PHP, the database, and their extensions, listed in the official installation documentation for your release. Ask your hosting provider to state the versions they run, make sure they are supported, and confirm they can upgrade PHP when needed.

Performance: plan for peaks, not averages

Moodle's documentation explains that performance depends on many factors, including the server, database, caching, and PHP settings. What matters in practice:

• Separate roles when needed

  Put the web server and database on adequate resources, and separate them further as the load grows.

• Enable caching

  Moodle supports caching (MUC) with systems such as Redis or Memcached, and PHP opcache should be tuned to speed up execution.

• Large files

  Where possible, serve heavy video from a streaming service or CDN, not from the server itself.

• Scheduled tasks (cron)

  Make sure they run regularly; if they stop, notifications, completion, and backups break.

• Load test

  The documentation recommends tools like JMeter to simulate users. Test real peak scenarios: mass login and the start of an exam.

Backup and restore

A backup you have never restored can't be relied on. Run a full restore on a test environment at least once a year, store backups off the server itself, and decide how much data you can afford to lose (an hour? a day?), then set the backup frequency accordingly.

A safe update plan

• Copy the whole platform to a staging environment

• Update staging, and test login, courses, quizzes, payments, and plugins

• Set a maintenance window away from exams and the start of the semester, and announce it

• Take a fresh backup before starting, then run the update

• Check scheduled tasks and logs after the update

• Prepare a clear rollback plan in case something breaks

Shared hosting, a dedicated server, or cloud?

• Shared hosting

  Suits: trials and very small numbers — Watch for: shared resources and limited control

• Virtual private server (VPS)

  Suits: small and medium institutions — Watch for: responsibility for administration and updates

• Scalable cloud

  Suits: clear peaks and growth — Watch for: cost control and administration expertise

• Managed hosting

  Suits: those who don't want to manage a server — Watch for: the contract, support level, and data ownership

Frequently asked questions

• Should I upgrade as soon as a new release comes out?

  Not necessarily. Wait until your plugins are confirmed compatible, and plan the move before security support ends.

• How many resources do I need?

  There is no number that fits everyone. It depends on concurrent users and the type of activities, so load test instead of guessing.

• Can I move from one host to another?

  Yes. It requires migrating the database, files, and settings, with testing before switching the domain.

Sources

• Moodle Developer Resources

  Release schedule (moodledev.io/general/releases).

• Moodle documentation

  Performance recommendations and Installing Moodle.