The Perfect Moodle Server Architecture: 2026 Planning Guide

The Perfect Moodle Server Architecture: 2026 Planning Guide Your quiz window opens at 9 AM. Three hundred students log in simultaneously. Your single server, which handled last week's light browsing just fine, now crawls to a halt. Database connections pile up. Pages time out. Students panic. Your phone starts ringing.

This is the cost of choosing the wrong server architecture for your Moodle deployment.

The "perfect" architecture isn't a single blueprint -- it's an evolutionary path that matches your current scale while preparing for growth. A deployment serving 100 concurrent users needs fundamentally different infrastructure than one handling 2,000 students taking high-stakes exams. This guide walks you through three proven architectural models, with hardware specifications, current cost breakdowns, and the critical decision points between them.

Software note: Moodle requirements are version-specific. Moodle 4.5 LTS requires PHP 8.1+ and supports PHP 8.3. Moodle 5.0 and 5.1 require PHP 8.2+. Moodle 5.2, the current stable release as of May 2026, requires PHP 8.3 plus MariaDB 10.11, MySQL 8.4, PostgreSQL 16, or MSSQL 2019. If you're still running PHP 7.x or older database engines, plan that upgrade before any infrastructure changes.

Cost assumptions: AWS examples use public on-demand Linux pricing in us-east-1 checked in May 2026, rounded monthly. They exclude taxes, support-plan changes, unusual egress spikes, and reserved/Savings Plan discounts unless stated. Treat them as reproducible planning examples, not quotes.

The Four Building Blocks of Every Moodle Architecture

• Web Server: Your web server (Nginx or Apache with PHP-FPM) processes incoming HTTP requests and executes Moodle's PHP code. Each concurrent user consumes one worker process. When you run out of workers, users see connection timeouts. A server with 8 GB RAM can handle roughly 20-40 PHP-FPM worker processes, depending on your memory_limit settings.
• Database: Your database server (MariaDB, MySQL, or PostgreSQL) is where Moodle stores every course, user, grade, and interaction -- and your most common performance bottleneck. A query that takes 200ms under light load can balloon to 5 seconds when 300 students hammer the same quiz table simultaneously. You need enough RAM to cache your working dataset, typically 50-80% of your total database size.
• File Storage: The moodledata directory holds every uploaded file, assignment submission, and course resource. On a single server this lives on local disk. In a multi-server cluster, all web servers need access to the same files -- via shared storage (NFS, GlusterFS) or object storage (S3, Azure Blob) with the ObjectFS plugin.
• Caching: An in-memory cache (Redis or Memcached) stores frequently accessed data in RAM, bypassing slow database queries. In MooDIY internal quiz-load tests, moving user sessions from the database to Redis has cut session-related database load by up to 5x. In clustered deployments this isn't optional -- it's architectural bedrock.

How you arrange these four determines whether your site handles 100 concurrent users or 5,000.

Model 1: The All-in-One Server (100-500 Concurrent Users)

A single virtual machine running all four service layers is the starting point for most Moodle deployments.

Hardware Specifications

• Small (100-200 concurrent): 4 vCPU, 16 GB RAM, 100 GB SSD, 1 Gbps network
• Medium (200-500 concurrent): 8 vCPU, 32 GB RAM, 250 GB SSD, 1 Gbps network

Cost Breakdown (Cloud, on-demand -- us-east-1, May 2026)

The t3.xlarge (4 vCPU / 16 GB) runs at ~$121/month and the t3.2xlarge (8 vCPU / 32 GB) at ~$243/month on AWS on-demand pricing. Add ~$50-100/month for bandwidth at typical usage. If you're running steady-state production workloads, Reserved Instances or Savings Plans reduce these figures by 37-55%.

Cost tip: AWS Graviton4 (M8g) instances deliver 10-20% lower pricing than comparable x86 instances with equal or better performance, and PHP/MariaDB run natively on ARM64 with no code changes. Worth evaluating if you're provisioning new infrastructure.

Managed hosting for this tier typically runs $150-400/month, depending on provider and included support.

When This Model Fits

Use an all-in-one architecture when peak concurrent users stay consistently below 500, you have no synchronised exam windows, acceptable downtime windows exist for maintenance, and your budget is $150-400/month.

Critical Limitations

• Single point of failure: Any component failure -- hardware, OS, network -- takes your entire site offline until restored from backup. Expect 30 minutes to 4 hours of downtime depending on your recovery setup.
• Resource contention: Database grade calculations compete with web server CPU. Large file uploads spike disk I/O and slow quiz page loads. Everything competes for the same resource pool.
• No horizontal scaling: You can upgrade vertically (bigger server), but you can't add a second web server. This creates a hard ceiling around 500-800 concurrent users regardless of hardware spend.

Model 2: Separated Database Tier (500-2,000 Concurrent Users)

The single most impactful architectural upgrade is moving your database onto a dedicated server. This eliminates resource contention and unlocks independent scaling of your two most critical layers.

Hardware Specifications

• Web server: 8 vCPU, 32 GB RAM (20 GB for PHP-FPM workers, 12 GB for OS/cache), 100 GB SSD
• Database server: 8 vCPU, 64 GB RAM (50 GB for InnoDB buffer pool, 14 GB for OS/connections), 500 GB NVMe SSD -- fast random I/O is critical here.

Cost Breakdown

On AWS, the r5.2xlarge (8 vCPU / 64 GB RAM) runs ~$368/month as an EC2 instance. If you use managed RDS, the db.r5.2xlarge is ~$664/month -- significantly more, but you gain automated failover, backups, and patching. Your typical Model 2 cloud spend runs approximately $610-910/month (t3.2xlarge web + r5.2xlarge or db.r5.2xlarge database), plus bandwidth and storage.

Important: If you're running MySQL 5.7 or PostgreSQL 11 on RDS, AWS doubled Extended Support Year 3 rates on March 1, 2026 to $0.20/vCPU-hour. On a db.r5.2xlarge (8 vCPUs), that's an extra $1,152/month. Upgrade your database engine version before this applies to you.

Managed hosting at this tier typically runs $800-1,200/month.

When to Move to This Model

Make the move when you observe consistent peaks of 500-1,000 concurrent users, database CPU regularly hitting 70%+ utilisation, query response times degrading during peak load, or exam windows with synchronised quiz starts.

Key Advantages

• Independent tuning: Allocate 50 GB to your InnoDB buffer pool without starving the web server. Run database maintenance (OPTIMIZE TABLE, ANALYZE) without impacting frontend performance.
• Isolated failure domains: If your web server crashes, your database keeps running. You can patch and reboot the web server during a maintenance window while the database stays online.
• Clear upgrade path: When you outgrow one web server, you're already positioned to add a second and a load balancer. This is Model 3 with minimal rework.

Critical Configuration: Network Performance and DB security

Both servers must be in the same data centre -- ideally the same availability zone -- with sub-1ms latency between them. Minimum 1 Gbps interconnect, 10 Gbps preferred. Lock down database firewall rules to allow only the web server's IP on port 3306.

Model 3: High-Availability Cluster (2,000+ Concurrent Users)

When you need a materially lower outage risk during exam windows with thousands of simultaneous users, you need a horizontally scalable, highly available cluster backed by tested failover procedures.

Hardware Specifications

• Load balancer (HAProxy or cloud-native): 4 vCPU, 8 GB RAM -- HAProxy handles 40,000+ concurrent connections on this spec. ~$50-120/month, or $30-50/month for a cloud-native load balancer service.
• Web servers (minimum 2, typically 3-4): Each: 8 vCPU, 32 GB RAM, 100 GB SSD. All stateless -- sessions in Redis, files in shared storage. ~$243/month per node (t3.2xlarge) or less with Graviton equivalents.
• Database cluster (MariaDB Galera or PostgreSQL with replicas): Primary + replica, each with 16 vCPU, 128 GB RAM, 1 TB NVMe SSD. InnoDB buffer pool sized to 80 GB. Percona XtraDB Cluster recommended for active-active failover. ~$800-1,200/month per node.
• Redis cluster (sessions + MUC caching): 3 nodes in Sentinel or Cluster mode for HA. Each: 4 vCPU, 16 GB RAM. ~$150-200/month per node.
• Shared file storage: ObjectFS with S3 or Azure Blob -- ~$50-150/month depending on usage. Strongly preferred over GlusterFS/NFS for cost, concurrency, and durability.

Total Cost Breakdown

Component	Cloud (DIY)
Load balancer	~$100/month
Web servers (3 x t3.2xlarge)	~$730/month
Database cluster (2 nodes)	~$2,000/month
Redis cluster (3 nodes)	~$550/month
Object storage	~$100/month
Monitoring, backup, network	~$200/month
Total DIY	~$3,680/month
Fully managed (MooDIY-style)	$2,500-3,500/month

When This Model Is Required

You need an HA cluster when peak concurrent load regularly exceeds 1,500-2,000 users, you conduct high-stakes exams with synchronised start times, downtime during business hours is unacceptable, or your organisation requires a formal disaster recovery plan.

Critical Design Decisions

• Sessions in Redis: Configure Moodle's session_redis cache store and set session_handler_class to \core\session\redis. Without this, users are tied to a single web server -- which defeats load balancing entirely.
• File locking in Redis: With multiple web servers writing to shared storage, Moodle's file locking prevents race conditions during cron and file uploads. Configure Redis-based locking.
• Cron isolation: Only one server should run Moodle's cron jobs. Use a dedicated cron node or designate one web server as cron master to prevent duplicate task execution.
• Connection pooling: Each web server opens 50-100 database connections. With 4 web servers, configure your database for 400-500 max connections and monitor usage closely.

Scaling Beyond 5,000 Concurrent Users

Add web servers horizontally -- you can scale to 10-20 nodes before database becomes the bottleneck again. At that point, introduce database read replicas for reporting queries and a CDN for static assets (CSS, JavaScript) and course files via ObjectFS's CDN integration.

The Hidden Bottleneck: Shared File Storage in Clusters

In a single-server setup, moodledata lives on local SSD with sub-millisecond access. In a cluster, all web servers need the same files -- and this becomes your new performance constraint.

The NFS trap: NFS is the traditional solution, but it serialises heavy file writes. With 2,000 active users, you're writing thousands of small files per minute over the network. NFS queues these writes and creates latency spikes that manifest as slow page loads.

The object storage solution: The ObjectFS plugin moves your moodledata contents to S3, Azure Blob, or Google Cloud Storage. There's no file locking contention (object storage handles concurrency natively), storage costs drop to ~$0.023/GB/month versus ~$0.10/GB/month for SSD, and durability and replication are automatic. Local NVMe caching on each web server handles hot files with sub-10ms reads.

Use Redis for Moodle's MUC application cache and sessions. Reserve object storage for actual files -- course content, submissions, backups. This hybrid approach gives you Redis speed with object storage capacity.

Decision Matrix

Factor	Model 1: All-in-One	Model 2: Separated DB	Model 3: HA Cluster
Concurrent Users	100-500	500-2,000	2,000-10,000+
Typical Hardware	4-8 vCPU, 16-32 GB RAM	16 vCPU, 96 GB RAM	60+ vCPU, 400+ GB RAM
Cloud Cost	~$170-350/month	~$610-910/month	~$3,500-4,000/month
Managed Cost	~$150-400/month	~$800-1,200/month	~$2,500-3,500/month
Uptime	No SLA (single failure)	Improved (isolated layers)	99.9%+ (fully redundant)
Downtime Risk	High	Medium	Low
Scaling Path	Vertical only	Add web servers -> Model 3	Horizontal (add web nodes)
Setup Complexity	Low (1-2 hours)	Medium (4-6 hours)	High (2-3 days)
Best For	Small schools, dev/test	Growing organisations	Large institutions, high-stakes

All cloud prices are rounded AWS on-demand estimates for us-east-1, checked in May 2026. Reserved Instances or Savings Plans can reduce compute costs for steady-state workloads, but prices vary by region, provider, support plan, and traffic pattern.

Conclusion

Your server architecture isn't a decision you make once -- it's a foundation you evolve as your institution grows. The three models in this guide give you a clear progression: start with what fits your current scale, build in the headroom for growth, and make the jump to the next tier before a capacity crisis forces your hand. The single most expensive mistake in Moodle infrastructure isn't choosing the wrong model -- it's staying on the wrong model too long. A site that needed Model 1 two years ago may be quietly accumulating technical debt on the same single server while user counts and assessment complexity have doubled. Watch your metrics, know your thresholds, and move before your students feel it.

Your Architecture, Without the Overhead

Designing and maintaining the infrastructure in this guide requires significant engineering time and ongoing expertise. MooDIY offers a free plan to get started, with paid plans built for organisations that need scalable infrastructure, more users, additional storage, dedicated support, and enterprise-grade architecture without the enterprise-grade complexity.

• Start with a Free Plan
• View All Plans & Pricing

References

• AWS Pricing Calculator -- On-demand instance and RDS pricing used in Scenario
• AWS RDS Extended Support Pricing -- Current pricing including the March 2026 Extended Support Year 3 rate increase for MySQL 5.7 and PostgreSQL 11.
• Moodle Release Schedule -- Major and minor release cadence referenced in upgrade cost calculations.
• Moodle Latest Download Requirements -- Current Moodle 5.2 PHP and database requirements.
• Moodle Security Announcements -- CVE history and patch cadence underlying the security patching cost estimates.
• BLS Occupational Outlook Handbook -- Network and Computer Systems Administrators -- Authoritative US employment and salary data underpinning sysadmin cost figures.