Moodle high availability guide

Moodle high availability: when one web node is no longer enough

Adding a second or third Moodle web node removes a single point of failure only if every piece of state that a request depends on is available to all nodes. If one node holds a session, a cache entry, an uploaded file or a cron lock that the others cannot see, the load balancer will send a student to a server that cannot answer correctly, and the site will look intermittently broken rather than cleanly down. That is why a slow or failing Moodle site during enrolment, assessment or exam windows is rarely fixed by simply adding servers. The first question is which state is still local, and the answer is often more than the team expects. Four kinds of state need deliberate design. Moodle stores uploaded and generated files in the moodledata directory, which must be on storage that every web node and every cron runner mounts with the same view. Course content, grades, users and most configuration live in the database, so the database layer needs its own availability design, such as replication with a defined failover method. Caches and sessions are the quieter problem: by default they may sit on the local file system, and a session written on one node must be readable on another. Each of these is a separate decision with its own failure modes, and none is solved by the web tier alone. Cron is the part most often overlooked. Moodle runs scheduled and ad hoc tasks through cron, and those tasks can touch files, send mail, process gradebook updates and generate reports. Running cron on every web node without coordination can duplicate work or create contention during peak loads. Decide early whether cron runs on a dedicated node or worker, how long-running ad hoc tasks are handled, and how a failed runner is detected. Confirm the exact cron and task-runner recommendations in the Moodle documentation for the release you run, because these details change between versions. Confirm before you commit to a design. The settings, cache stores, session handlers, storage requirements and supported load balancer arrangements depend on the Moodle release, PHP version and database engine in use. The release notes for the version you plan to run, and the administration documentation for caching and cron, are the sources to check. This page covers self-hosted sites in infrastructure you control, so each shared component should be placed in your own cloud account, data center or private network, with the owner, backup and recovery path named for each one.

Placeholder.

Which Moodle components must be shared across nodes

A Moodle cluster works only when every web node sees the same code, files, data, sessions and scheduled work. Each component below holds state that a single node cannot keep privately without causing lost sessions, missing uploads or duplicated tasks.

Web nodes running PHP

Each web node runs the same Moodle code and PHP version, so code must be deployed identically to every node at the same time. Confirm the PHP and database versions required by your target release, since Moodle 5.1 requires 64-bit PHP 8.2 or later. A node on a different code revision can fail in ways that appear only for some users. Check that every node points its web server document root at the same release's public directory.

Load balancer and session affinity

The load balancer decides which node serves each request, and its affinity settings determine whether a user keeps returning to the same node. Affinity can mask problems with local state, but it does not replace shared session storage and it complicates node drain during maintenance. Test with affinity off to confirm the cluster behaves correctly without it. Confirm health check paths against the Moodle documentation for your release.

Shared moodledata directory

The moodledata directory holds uploaded files, course backups, temporary files and other data that Moodle writes during normal use. If one node keeps its own copy, a file uploaded through one node will be missing when another node serves the request. Use a shared file system that every node mounts with the same permissions, and confirm locking and performance behavior with your storage vendor. Test restores against this directory, not only the database.

Database with replication or failover

The database holds courses, users, grades, enrolments and configuration, so it is the single source of truth for the whole cluster. Every node must connect to the same primary through a write endpoint, with replicas or failover designed for your database engine. Confirm supported engines and versions for your release, for example PostgreSQL 15 or MySQL 8.4 for Moodle 5.1. Test failover with a real Moodle session in progress to observe how the application reconnects.

Shared cache stores and session handler

Moodle caches configuration and course data and can store user sessions outside the web server. If a node keeps its own cache, administrators will see stale settings and users may see inconsistent pages after a change. If sessions stay local, a user switched to another node is logged out or loses form data. Confirm which cache store and session handler options are supported for your target release in the Moodle documentation before choosing a design.

Cron and scheduled task runner

Moodle scheduled tasks and ad hoc tasks, such as sending messages, processing imports and generating reports, must run on a defined schedule. If every node runs cron, tasks can execute several times and cause duplicate emails, grades or enrolments. Designate a single controlled runner or a documented task worker model, and confirm the approach in the Moodle documentation for your release. Check task queues and run times during exam load tests.

Decisions that set the shape of a Moodle cluster

This table compares the main architecture choices for a multi-node Moodle deployment: database topology, moodledata storage, cache and session stores, load balancer session handling, and where cron runs. Read each row for when the option fits, what it adds to daily operations, and the failure it leaves uncovered. Confirm storage locking and latency behavior with your storage vendor and your own load tests before committing to a design.

Decision	Option and when it fits	Operational cost it adds	Failure it does not cover
Database topology	Active-passive replication fits most sites with one writable primary and a standby for failover. Active-active suits sites that need read scaling and can handle write conflicts, which Moodle's application layer does not manage for you.	Active-passive needs regular failover drills and a tested promotion runbook. Active-active needs staff who understand replication lag, and a plan for Moodle reading stale data after writes.	Active-passive does not protect against logical corruption or a bad upgrade, which replicate to the standby. Neither option replaces point-in-time backups.
moodledata storage: network file system	A shared network file system is a common fit when all web nodes need the same file tree and the platform supports it. Confirm locking behavior and whether the file system is supported for moodledata in your Moodle version.	Storage latency affects page loads and file uploads. Someone must own mount options, permissions, and capacity growth for course files.	A shared file system does not protect against deletion of course content or accidental overwrites. Snapshots and separate backups still apply.
moodledata storage: block or object options	Block storage attached to one node fits only single-node layouts. Object storage may suit file archives, but confirm with Moodle documentation whether your configuration supports it for moodledata as the active store.	Object storage adds integration work and may change backup and restore steps. Block storage on one node reintroduces a single point of failure.	Block storage on one node does not survive that node's loss. Object storage latency and API limits can slow file-heavy courses.
Cache and session stores	A shared cache store such as Redis or Memcached fits sites where all web nodes must see the same cache and sessions. Confirm supported store types for your Moodle version before choosing.	Someone must patch, monitor, and size the cache service. Cache failover behavior and eviction settings need testing under exam load.	A shared cache does not replace database backups. Losing the cache node can drop sessions and force reloads, and it does not protect course data.
Load balancer session affinity versus shared sessions	Session affinity (sticky sessions) fits small clusters with simple balancers and no shared session store. Shared sessions fit clusters that need to drop any node without logging users out.	Affinity leaves users stranded on a failed node until their session is rebuilt. Shared sessions add a dependency on the session store and its availability.	Affinity does not protect sessions when a node fails. Shared sessions do not protect against a session store outage unless that store is itself highly available.
Cron and ad hoc tasks	Running cron on one designated node fits most sites and keeps scheduled jobs from duplicating. Dedicated task workers fit sites with large exam loads or heavy report and backup jobs.	A designated node is one more thing to monitor and move during maintenance. Dedicated workers need their own sizing, patching, and queue monitoring.	A single cron node does not survive its own failure unless you define a standby and a failover step. Overlapping jobs can still occur if the schedule is misconfigured.

How to build a Moodle cluster in the right order

This sequence takes a single Moodle site to a load-balanced cluster in which every web node serves identical code, shares one data store and sessions, and survives the loss of a node without dropping users. Each step ends with a check so the next layer is built on verified ground.

Confirm the target release and its runtime requirements
Choose the Moodle release first, then pin the PHP, database and web server versions it requires, using the release notes for that version. Moodle 5.1 requires 64-bit PHP 8.2 or later, and PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later. Moodle 5.3 raises those minimums, including PHP 8.3 and PostgreSQL 17, so confirm the exact list for your chosen release. From Moodle 5.1, the web server document root must point to the /public directory on every node, not the main Moodle folder, or users may see directory listings or errors. Record the versions in a build sheet that all nodes will be built from. Done when each target platform has been checked against the release notes and the document root configuration is written into the build standard.
Build the database layer with replication
Stand up the database as its own tier before any web node exists, so that Moodle connects to a single writable endpoint from the start. Choose a replicated topology your team can operate, confirm that the engine and version match the release requirements, and set the connection, character set and timeout settings that Moodle expects. Confirm failover behavior with your database team: how a promoted replica is found, and how long Moodle sessions can tolerate a switch. Run the Moodle installer against the primary once and verify that schema creation completes without warnings. Done when a fresh install completes against the primary endpoint and a controlled failover test returns the site to a working state.
Provision shared moodledata storage
The moodledata directory holds uploaded files, course backups, temporary data and caches that every web node must read and write. Place it on shared storage that all nodes mount at the same path, using a network file system or object-backed gateway that your platform team supports. Set ownership and permissions so the PHP process user on each node can write, and keep the directory outside the web root. Test the mount under realistic conditions, including what happens during a storage node restart, because a stale mount will surface as upload and cache errors. Done when a file written from node A is readable and writable from node B and node C, and the mount recovers cleanly after a reboot of one node.
Configure shared cache and session stores
Moodle caches and user sessions must live outside any single web node, or a user switching nodes will lose state and sessions will break under load. Deploy a shared cache store that Moodle supports, such as Redis or Memcached, and confirm the exact store and version your release supports. Point Moodle's session handling at the shared store, and configure the cache stores in the administration pages so every node uses the same definitions. Check the Moodle documentation for your release on how sessions and locks are handled before choosing settings. Done when a logged-in user keeps their session after requests are sent to different nodes, and cache purges made on one node take effect on the others.
Build identical web nodes from one image
Create each web node from the same base image or configuration code so that PHP version, extensions, php.ini settings, web server configuration and the Moodle code tree are identical. Deploy the Moodle code from one versioned artifact, point each document root to /public for release 5.1 and later, and point every node at the same database endpoint, moodledata mount and shared cache. Keep configuration in one file under version control, not edited by hand on each node. Done when every node reports the same Moodle version and the same plugin versions in the administration pages, and a page load from each node returns the same site configuration.
Set load balancer health checks and session affinity
Place the web nodes behind a load balancer and define a health check that tests real Moodle behavior, not only that a port is open. A check on a lightweight page that depends on PHP and the database is a common starting point, and you should confirm with your load balancer's documentation how it treats failed responses. Decide whether the shared session store makes affinity unnecessary, and test both settings if you are unsure. Verify that the balancer removes a node that is stopped or returns errors, and that users already logged in continue without re-authenticating. Done when a node taken out of service leaves the rotation within the configured check interval and active sessions survive the removal.
Schedule cron on one designated node
Moodle cron runs scheduled tasks, and running it on every web node at once causes duplicate work and locking problems. Designate one node, or a separate task runner, to run the cron job on a fixed schedule, and disable cron on the others. Review the scheduled task list to confirm that tasks are not set to run on multiple nodes, and plan for the designated runner to be replaced if it fails. Large exam loads may need dedicated ad hoc task workers, which you should size from load testing rather than estimates. Done when the scheduled task log shows one source of execution, a forced failure of the cron node is detected and recovered from your runbook, and tasks resume on the replacement.
Test failure modes before go-live
Run a structured failover test that covers each layer built so far: stop one web node under load, fail over the database, restart the storage mount, and restart the cache service, recording what users see in each case. Confirm with your team which errors are acceptable during failover and which require a rollback. Keep the results with the build record so the next release upgrade can be tested against the same scenarios. Done when every failure scenario has a documented outcome, sessions survive the single-node failure, and the runbook names an owner for each recovery step.

How the cluster design changes by deployment model

A single web and application node with a separate database server is the simplest starting point for Moodle. Most shared state stays on one host, so few decisions cross machines. This model does not remove the web node as a single point of failure, so it suits sites that accept a planned outage window for recovery and that have a tested backup and restore for both the database and moodledata.

moodledata: stored on the local disk of the web node. Back it up on the same schedule as the database, because the two must match to restore a consistent site.
Sessions and caches: the local file system or database stores keep setup light, but they limit what you can add later without redesigning the stack.
Cron: runs on the one node, so there is no duplicate execution to prevent.
Recovery: rebuilding a failed web node means restoring the host, the code and moodledata from backup. The time this takes sets the recovery expectation you can offer users.

The operations team owns web tier patching, PHP and database client updates, and disk space monitoring for moodledata. Confirm with your platform team whether the database host has its own replication or failover, and time a full restore on a copy of your data before go-live.

How to test that a Moodle cluster fails over safely

A failover test is only useful if it is run against a written plan with known expected results. Before any node is removed, confirm that the cluster behaves correctly under normal load: pages load through the load balancer, logins succeed, course content opens, quizzes save attempts, and file uploads complete. Record response behavior at this baseline so that every later step can be compared against it. Agree in advance who watches which signals, where users will see errors, and who has authority to stop the test. Then run the faults one at a time and record what users see at each step. Remove one web node from the pool and confirm that the load balancer stops sending it traffic and that active users are either carried over or asked to sign in again. Restart a database replica, then trigger a database failover if your design includes one, and watch for connection errors, read-after-write delays and stale course pages. Interrupt the path to the shared moodledata storage for a short, defined period, and stop one cache or session node. For each fault, note the user-visible symptom, the duration, and whether the service recovered without manual intervention. Several checks matter more than uptime alone. Confirm whether sessions survive a web node loss, which depends on where session data is stored and whether all nodes read it from the same place. Check scheduled tasks for duplicates or gaps: cron and ad hoc task runners on several nodes must not run the same job twice, and no task should silently stop. Upload a set of files before and during the faults, then download and checksum them afterward to confirm consistency in moodledata. Finally, bring the failed node back and verify that it rejoins the pool, reads the correct configuration, and serves the same content as its peers without a manual rebuild. Exam-period load testing deserves its own run. Use a staging copy that matches production in PHP and database versions, web node count, cache configuration and storage layout, and load it with representative data volumes, course sizes and concurrent quiz attempts. Results depend heavily on your own hardware, network, database settings and plugins, so treat any published figure as a starting point rather than a benchmark for your site. Ask your implementation partner to state the test assumptions, the pass criteria and the data used, and to deliver the raw results with the test record.

What drives the effort and cost of a Moodle cluster

This table lists the factors that most change the scope of a multi-node Moodle build and the ongoing run cost, along with how to reduce each one. Read each row as a question to answer in your own environment before asking for a quote. The main takeaway is that concurrency, shared storage, environment count and recovery commitments usually matter more than the node count itself.

Driver	Why it changes effort or cost	How to keep it down
User counts and peak concurrency	Peak logins and quiz or exam sessions set the web node count, cache capacity and database connections. Concurrency at peak matters more than total enrolled users.	Ask for peak concurrent users per exam window, not annual totals. Plan load tests against that figure before fixing node sizes.
Data volume in moodledata and the database	Large course files and backups sit on shared storage that every web node reads. Database growth affects replication lag, restore time and backup windows.	Set file upload limits and retention rules for old course content. Confirm storage growth per term with your team before choosing storage tiers.
Environments to build and keep matched	Each extra environment (test, staging, DR) needs the same PHP, plugin and configuration state. Drift between them is a common cause of failed upgrades and exam-day surprises.	Standardize node images and configuration as code. Limit the number of environments to those you can keep identical.
Integrations that write to the database or call web services during peaks	SSO, HR sync, grade passback and LTI tools can add write load and remote call latency exactly when the site is busiest.	Schedule bulk syncs outside exam windows. Confirm which integrations write to the database and whether they can be rate limited or queued.
Custom plugins that hold local state	Plugins that write cache files, generated documents or temporary data to local disk break the assumption that any web node can serve any request.	Limit plugins that write to local disk, or move their state to shared storage or the database. Review each custom plugin for node-local writes before build.
Compliance requirements for backups and recovery testing	Retention periods, encryption, restore evidence and recovery time and point targets determine how much backup tooling and test effort is required.	Agree recovery time and recovery point targets in writing before build. Schedule restore tests and keep the results as evidence for your assessor.
Skills available in your team	Teams without Linux, PHP, database replication or cache administration experience need more vendor support during build and more training before handover.	Inventory current skills for each role before scoping. Ask the implementation partner to document runbooks and deliver training for gaps.

Securing shared state in a multi-node Moodle site

A Moodle high availability design spreads one application across several web nodes, which means the shared data, database, caches and configuration all become attack surface at the same time. The cards below cover the parts that most often drift between nodes or stay open wider than they need to be. Each one names a control to design and a check to run before go-live.

Moodledata access and mount permissions

The moodledata directory holds uploaded files, backups and caches for every course, so it is the most sensitive shared store in the design. Mount it only on the web nodes and cron hosts that need it, with the same owner and group on each node so PHP can read and write without widening permissions. Check that the directory is not reachable through the web server and that its mount options match on every host.

Network isolation between web nodes

Web nodes should accept traffic only from the load balancer and the monitoring hosts that need it, and should reach the database, cache and file store over restricted private paths. Keep administrative access on a separate management network or bastion rather than on the public interface. Test the rules from a node that should be blocked, not only from one that should work.

Database replication traffic and credentials

Replication between the primary and its replicas carries full copies of user records, grades and course content, so the replication channel needs encryption in transit and its own account with the narrowest rights the database engine allows. Moodle nodes should connect through an application account that cannot change replication settings. Confirm which replication features your chosen engine and version support, since this depends on the database you run.

Cache and session store authentication

Shared Redis, Memcached or database session stores hold session identifiers that can impersonate logged-in users, so an unauthenticated cache endpoint is a direct path to account takeover. Require authentication on every shared cache, bind it to the private network, and enable encryption in transit where the product supports it. Ask your cache vendor and your Moodle cache configuration guide which options apply to the version you deploy.

Secrets distribution to identical nodes

Each node needs the same config.php database password, cache credentials, mail credentials and encryption salt, but copying them by hand creates drift and leaves copies on laptops. Distribute secrets from a managed vault or an orchestration tool, rotate them through one procedure, and remove any secret that was ever committed to version control. Record which secrets exist, who can read them, and when each was last rotated.

Document root and PHP settings parity

Every web node must serve the same Moodle code from the same document root and run the same PHP version and extensions, or a request can behave differently depending on which node receives it. From Moodle 5.1 the web server document root must point to the /public directory, and a node left on the old path can show directory listings or errors. Compare the PHP configuration, OPcache settings and document root across all nodes after each change.

Operating, backing up and upgrading a Moodle cluster

A high availability Moodle cluster stays available only if someone watches the parts that fail quietly. Node health checks on each web node are the starting point, but the signals that matter most sit in the shared layers: replication lag between the primary database and its replicas, latency on the shared moodledata storage, and the availability of the cache and session store that every node depends on. A session store that drops out will log users out across all nodes at once, so it should have its own alert, not just a shared dashboard. Ask your platform team which metrics they already collect for the database, storage and cache tiers, and which alert thresholds they have agreed with the Moodle administrators.

Cron deserves its own monitoring because it is easy to run on one node and forget. Confirm that the scheduled Moodle cron runs from exactly one place, and track the ad hoc task queue as a backlog figure. A growing backlog during an exam window usually means the task workers cannot keep up with the load, which affects emails, quiz processing, and grade and course-related jobs. Record the normal backlog size during a quiet week so that a spike during an exam period is recognizable. Where cron design is part of the scope, the operations runbook should state which node runs it, what happens if that node fails, and who is paged.

Backups for this topology must cover the database and moodledata together, taken at the same point in time or with a documented way to reconcile them. A database snapshot without the matching files leaves course content and uploads pointing at data that does not exist, and the reverse is equally broken. Restore is the part teams skip. Run a full restore into an isolated test environment on a regular schedule, start Moodle there, and check a sample of courses, user logins, file downloads and a recent quiz attempt. Record how long the restore took, because that figure is the most honest input to your recovery planning. Confirm with your backup vendor or internal tooling how consistent snapshots are taken across the database and shared storage.

Upgrades in a cluster should keep every node on the same Moodle release at all times. Moodle ships major releases in April and October and point releases every two months, so plan a rhythm rather than reacting to each announcement. Choose between a rolling approach, where you drain one node, upgrade it and return it, and a maintenance window, where all web nodes are taken down together. A rolling approach suits sites that cannot stop, but only if the code and the database schema changes are compatible across the period when old and new code run side by side. Moodle 4.5 is a long-term support release with security support until 4 October 2027, which gives regulated sites a stable base if they do not want to move every six months. Before any upgrade, confirm the target release's requirements for 64-bit PHP and the database engine, including minimum versions, because a passing test on the old stack does not prove the new one works.

Hand over documentation that lets a different engineer run the cluster during an incident. The core set is a topology diagram showing load balancer, web nodes, database primary and replicas, shared moodledata storage, cache and session stores, and the cron location. Add runbooks for failover of the database, failover or removal of a web node, and restore from backup, each with the exact steps and the people to call. Finally, provide the test record: dates of restore tests, what was checked, the measured results, and any gaps found and closed. Auditors and internal reviewers will ask for this record first, and it is only useful if it is kept current after each upgrade.

Questions buyers ask before building Moodle high availability

How much does a highly available Moodle cluster cost to run?

The cost is driven by the components you need and who pays for each one, so there is no single number to plan around. Moodle itself is free under GPL-3.0, so the spend falls on infrastructure (web nodes, a load balancer, a replicated database, shared file storage, and cache or session services), on the people who design, build and test the cluster, and on ongoing administration. Infrastructure is usually paid to your cloud provider or data center team and recurs every month. Build work is a one-time cost paid to your internal team or a partner under a written scope. Ask any quote to separate hardware and hosting, one-time build, testing, documentation, and recurring support or upgrades. Your sizing (concurrent users, exam peaks and data volume) determines most of the infrastructure line, so settle those inputs before comparing offers.

How long does it take to build Moodle high availability?

The timeline depends on the scope, your environment and how ready your team is to make decisions and provide access. A cluster on existing cloud accounts with a clear database and storage design takes a different path than one that needs new network paths, identity integration or a data center build. Delays usually come from waiting for access, unresolved storage or backup decisions, and load testing that has to fit around exam calendars. A fixed-scope quote states the timeline, the deliverables and the dependencies on your side in writing before work starts. If you are comparing offers, check that each one lists the environment assumptions behind its schedule and what happens if those assumptions change.

What does our team need to provide before a Moodle cluster build starts?

Your team needs to provide working access, the technical details of your environment, and named decisions owners. Specifically:

Access: accounts or roles in your cloud or data center, plus DNS, certificate and firewall change paths.
Storage and network details: the shared file system or object option you use, IP ranges, latency between zones, and any restrictions on what can be shared between nodes.
Database ownership: who operates the replicated database, its backup schedule, retention and restore tests.
Backup ownership: who owns the copy of moodledata and the recovery targets you have agreed to.
A named owner: one person who can approve scope changes, resolve conflicts between teams and sign off the test results.

Agree these before the build plan is fixed, because missing ownership is one of the most common causes of delay.

Can our internal team build a Moodle high availability cluster themselves?

Yes, a capable internal team can build it if it has solid skills in Linux administration, PHP and its extensions, a supported database engine, and shared storage. Moodle 5.1 requires 64-bit PHP 8.2 or later, and Moodle 5.3 requires 64-bit PHP 8.3 or later, so your team must track those version floors as part of the build. The harder parts are not the installation. They are session and cache design across nodes, cron that does not run twice, moodledata consistency, failover testing under realistic load, and documentation that someone else can operate at 2 a.m. Be honest about whether those skills and the testing time exist before committing. Many teams split the work, keeping ownership internally while buying a review or load test.

Is a single Moodle server with good backups enough for our needs?

It depends on how much downtime your learners and assessments can tolerate and how long a restore takes in your environment. Good backups protect your data, but they do not keep the site running while you restore, rebuild a server or wait for a database to come back. If a single node failing during a course start, an assessment window or a live session would cause real harm to your programme, high availability is worth evaluating. If outages can be scheduled and recovery can be done within a tolerance you have written down, a single well-backed-up server may be the simpler choice. Test your restore process on a copy of the site before deciding, and record the recovery time you actually measured.

What breaks most often in a load-balanced Moodle deployment?

The most common failures come from state that is not shared correctly between nodes. Typical issues include:

Sessions and caches stored locally on one node, which log users out or show stale content.
moodledata on storage that is not consistent across nodes, causing missing uploads or file locks.
Cron running on every node, which duplicates scheduled tasks and email.
Document root misconfiguration, which from Moodle 5.1 must point to the /public directory, otherwise the site may show directory listings or errors.
Database failover that Moodle was not tested against, leaving connections pointing at a former primary.

Check each of these in a staging copy under load, and confirm them again after every upgrade.

What should we verify before accepting a Moodle high availability build?

Verify behavior, not just that the servers are running. Ask for evidence that a single web node can be removed from the load balancer during a session without users losing work. Confirm that scheduled tasks run once, that uploads appear on every node, and that a database failover completes and Moodle reconnects. Load test the cluster at a concurrency level based on your own peak figures, and record the results. Confirm that backup and restore have been tested end to end, and that runbooks name the owner for each step. Finally, check that the upgrade path for your target Moodle version is documented, including PHP and database version floors, so the cluster does not block future security releases.

How DeployOpen scopes, builds and hands over Moodle high availability

DeployOpen plans, builds, tests, documents and supports self-hosted Moodle high availability inside your own cloud accounts, data centers or air-gapped networks. Each engagement starts from a written, fixed scope that names the web nodes, shared storage, database, caches, sessions and cron design before any work begins.

How we scope

Confirm the Moodle release line and PHP and database versions the cluster must run, checked against Moodle's published requirements for that release
Map concurrent user and exam peaks, file storage growth and cron job volume to the node count and worker design in the scope
Record which shared components are in scope: moodledata storage, replicated database, shared cache stores and session handling
Agree in writing what is excluded, such as third-party plugin fixes, content migration or ongoing monitoring, so the quote matches the work

How we build

Stand up the web nodes behind your load balancer with the document root set correctly for the Moodle release in use
Configure shared moodledata storage and session and cache backends so every node reads and writes the same state
Set up database replication and test failover on a non-production copy before any production cutover
Design cron and ad hoc task execution so scheduled jobs run once across the cluster and scale with exam loads

How we hand over

Run load and failover tests against the agreed scope and record results alongside the configuration used to produce them
Deliver runbooks covering node replacement, database failover, storage recovery, cache flushes and cron troubleshooting
Document the architecture, access model, backup and restore procedure and the upgrade path for future Moodle releases
Walk your platform and administration teams through operations and confirm ownership of each component after handover

How we support

Offer ongoing support, upgrades and continuous testing as a retainer that follows the written scope
Plan clustered upgrades through staged test environments, so each Moodle release is validated on the same topology before production
Review plugin compatibility and cache or session settings whenever the cluster configuration or Moodle version changes
Confirm response expectations, service levels and retainer terms in the written agreement rather than assuming them

Moodle high availability