Managed Moodle Hosting: Your Options, the Real Maintenance, and What It Costs
Self-host, MoodleCloud, or a managed host? Here's the honest comparison — what “managed” should really include, the true maintenance burden, real 2026 costs, and when you don't need to hire anyone.
The short version
Key takeaways
- ✓ "Managed" is only worth the name if it includes same-cadence security patching, backups you have actually restored, PHP/DB tuning, monitoring, plugin vetting, and a staging site — ask providers to confirm each in writing.
- ✓ Moodle ships a major release every 6 months (April & October) and a point release with bug + security fixes every 2 months (Feb/Apr/Jun/Aug/Oct/Dec), plus occasional out-of-band critical patches — that cadence is the real self-hosting burden.
- ✓ Each standard version gets ~12 months of general (bug-fix) support, then security-only fixes to ~18 months total from release; LTS runs far longer (Moodle 4.5 LTS is patched until October 2027). Running past security end-of-life is the biggest avoidable risk.
- ✓ MoodleCloud (official) is cheapest for zero-ops small sites — fixed annual tiers, billed yearly — but blocks custom plugins, custom themes, and advanced integrations/API, so it's a dead end if you need real customization.
- ✓ A small self-hosted server is cheap (Hetzner, DigitalOcean, and AWS Lightsail all offer inexpensive small tiers), but total cost of ownership including staff time is far higher — the real cost is your team's ongoing hours, not the server bill.
- ✓ You may not need to hire anyone: MoodleCloud, or a comfortable admin on a modest, inexpensive box with a real patch/backup routine, honestly covers many small sites.
At a glance
Self-host vs MoodleCloud vs specialist managed
| Option | Cost & effort | Who does ops | Custom plugins/themes | Best for |
|---|---|---|---|---|
| Self-host (IaaS/on-prem) | Low server cost + your ongoing time | You | Yes (full control) | Skilled admins, small/non-critical sites, tight budgets |
| MoodleCloud (official) | Fixed annual tiers, billed yearly | Moodle | No | Small sites wanting zero ops, no customization |
| Specialist managed host | Monthly subscription, entry to enterprise scale | Provider | Yes | Business-critical sites needing plugins, SLA, and scale |
Your three real options
There are only three, and the honest trade-off is control vs. how much ops work lands on you.
- Self-host on cloud IaaS or on-prem (Hetzner, DigitalOcean, AWS, Google Cloud, or your own server): maximum control and the lowest server bill, but you own every patch, backup, upgrade, and outage.
- MoodleCloud (moodle.com's official SaaS): zero server ops, automatic updates, the premium mobile app, and built-in BigBlueButton web conferencing (with participant limits) — but no custom plugins, no custom themes, no advanced integrations/API, and fixed user/storage tiers.
- Specialist managed Moodle host: they run the stack and let you keep custom plugins, themes, and integrations — the middle path most business-critical sites land on.
- Rule of thumb: pick MoodleCloud if you'll never customize; self-host if you have real in-house Linux/PHP skill and time; pick managed hosting the moment Moodle becomes business-critical or you need plugins MoodleCloud forbids.
What "managed" should actually include
Many hosts say "managed" and mean "we installed it once." Hold them to this checklist.
- Security patching on Moodle's cadence — ideally same-day for critical CVEs, not "quarterly."
- Backups that are tested and restorable — ask when they last did a full rehearsed restore, not just "we take daily backups."
- PHP and database tuning: OPcache, a real cache store (Redis/Memcached), and sane MariaDB/PostgreSQL settings — not stock defaults.
- Uptime monitoring with an actual SLA and alerting, plus cron running every minute as the web-server user (Moodle breaks quietly without it).
- A staging/clone environment so upgrades and plugin changes are tested before they hit learners.
- Plugin vetting and version compatibility — someone checking that add-ons match your Moodle and PHP version before install.
- Scaling headroom for concurrent (not just registered) users — the number online at once during an exam or launch is what actually sizes the server.
The real maintenance burden if you self-host
This is the part people underestimate. It's not the install — it's the discipline every month after.
- Track and apply point releases every ~2 months (bugs + security), plus rare emergency out-of-band patches — with a maintenance window and a rollback plan.
- Plan a major upgrade every 6-18 months before your version hits security end-of-life; note the LTS-to-LTS path; the current release is Moodle 5.2 (April 2026), with 5.3 LTS due October 2026, and Moodle 5.1+ introduces a new public/ directory your web server serves as document root (plugins may need moving on upgrade).
- Keep PHP current: Moodle 4.5 needs PHP 8.1+ (up to 8.3); Moodle 5.x needs PHP 8.2+ (support 8.2-8.4). OS and PHP end-of-life will force your hand.
- Keep the database supported and tuned — minimums rise each release (Moodle 5.1 needs MySQL 8.4, MariaDB 10.11, or PostgreSQL 15); check the exact minimum for your version.
- Run and monitor cron every minute, renew SSL, watch disk (backups and logs silently fill it), and test restores — a backup you've never restored is a guess.
- Budget the hours honestly: a few hours most months, plus a hard day or two per major upgrade, indefinitely.
How to choose based on your situation
- Small site, no customization, want zero ops: MoodleCloud.
- Small-to-mid site, you have a capable admin and time: self-host on Hetzner/DigitalOcean/Lightsail and run the routine yourself.
- Business-critical, need plugins/themes/integrations, or must meet compliance/SLA: specialist managed host.
- Compliance-heavy (data residency, audit logs, SSO): confirm region, backup encryption, and access controls in writing — this rules out some cheap tiers.
- Large or spiky concurrency (launches, exams): prioritize a host that sizes on concurrent users and offers caching + scaling, not the cheapest per-month price.
The honest numbers
What it costs
| Item | Effort & scale | What drives it |
|---|---|---|
| MoodleCloud (official SaaS) | Fixed annual tiers, billed yearly (small monthly equivalent) | User count and storage tier (Starter 50 users/1GB up to Standard 750 users/50GB). No custom plugins, custom themes, or advanced integrations/API at any tier; prices are set in AUD and shown in local currency. |
| Self-host: cloud server only | Inexpensive small server; more for mid-size | vCPU/RAM, concurrent users, storage and backup space, bandwidth. Hetzner (CAX11 ARM), DigitalOcean (1 vCPU/1 GB), and AWS Lightsail all offer inexpensive small tiers that scale up as you add vCPU/RAM. |
| Self-host: true total cost of ownership | Substantial — mostly staff time (estimate) | Staff time for patching, backups, monitoring, upgrades, and incident response — the hidden labor cost that dwarfs the server bill. Varies widely with in-house rates and how critical the site is. |
| Specialist managed Moodle host | Monthly subscription; entry to enterprise-scale SLAs | SLA/uptime, patch cadence, plugin and theme support, staging, and user scale. Entry tiers are affordable monthly plans; enterprise SLAs and heavy customization drive the top end. |
| Moodle Workplace / enterprise (Certified Partner) | Quote-based; enterprise-scale annual commitment | Enterprise features (multi-tenancy, org structures), seat counts, and full certified-partner support and customization. Pricing is opaque and quoted per deal; smaller Workplace sites can cost well under the enterprise floor. |
Ranges reflect 2025–2026 pricing and vary with scope; treat them as planning figures, not quotes.
You may not need to hire anyone. Two honest DIY paths cover a lot of small sites. First, MoodleCloud: if you'll never need custom plugins, custom themes, or integrations/API, buy an official plan and you're done — updates, backups, and the mobile app are handled on fixed annual tiers, billed yearly, no server skills required. Second, self-manage a small server: if you (or a colleague) are comfortable on Linux and PHP, an inexpensive small Hetzner, DigitalOcean, or AWS Lightsail box will happily run a small Moodle. The catch is the routine, not the install — you must apply the ~bi-monthly point releases in a maintenance window, keep PHP current (8.1+ for 4.5, 8.2+ for 5.x), run cron every minute, watch disk, and actually restore a backup at least once to prove it works. If you'll do that discipline month after month, self-hosting is a legitimate, cheap, fully honest choice. You only need a managed host when the site becomes business-critical, you can't guarantee that monthly discipline, or you need customization and scale beyond what you want to babysit.
Where to start
- Count your concurrent users (peak online at once), not just registered accounts — that number sizes everything.
- Decide the customization question first: if you need custom plugins, custom themes, or API/integrations, MoodleCloud is out — go self-host or managed.
- If self-hosting, spin up a small Hetzner/DigitalOcean/Lightsail box, install the current release, and set a recurring calendar reminder for the bi-monthly patch window.
- Write your backup-and-restore routine before launch, then actually restore a backup once to prove it works.
- If buying managed, send the "what managed should include" checklist above and make each item a written yes/no before you sign.
- Check your Moodle version's support dates and plan the upgrade before security support ends.
If you'd rather hand it off
None of this requires us. But if you'd rather hand off the patch windows, tested backups, and tuning than babysit them, that is exactly what our managed Moodle hosting does — a straightforward monthly subscription, senior US engineers, no contract. The “what managed should include” checklist above is the one we hold ourselves to.
References & further reading
- Moodle releases, cadence & support dates (official)
- Moodle 5.1 release notes — PHP & database requirements (official)
- Installing Moodle — system requirements (MoodleDocs)
- MoodleCloud Standard Plans (official pricing)
- DigitalOcean Droplet pricing
- Hetzner Cloud pricing
- AWS Lightsail pricing
On Sternfast
Questions people ask
Is managed Moodle hosting worth it, or should I self-host?
If Moodle is business-critical, or you don't have someone who'll reliably patch, back up, and upgrade it every month, managed pays for itself. If you have a capable admin, a small non-critical site, and the discipline for a monthly patch window, self-hosting is genuinely fine and much cheaper on the server bill.
How often does Moodle need updating?
A point release with bug and security fixes lands every ~2 months, a major release every 6 months (April and October), and occasional emergency patches in between. You also need a bigger upgrade before your version's security support ends (~18 months for standard releases, longer for LTS — Moodle 4.5 LTS is covered until October 2027).
Can I just use MoodleCloud and skip all of this?
Yes, if you'll never need custom plugins, custom themes, or integrations/API — MoodleCloud handles updates, backups, and the mobile app on fixed annual tiers, billed yearly. The moment you need real customization or integrations, you've outgrown it and need self-hosting or a managed host.
How much server do I need for X users?
Size on concurrent (simultaneously online) users, not registered accounts. A small site with ~50 concurrent users runs comfortably on a 2 vCPU / 4 GB box (an inexpensive small cloud server on DigitalOcean, Lightsail, or Hetzner). Exams and launches spike concurrency, so plan for that peak, not your total headcount.
What's the cheapest legitimate way to host Moodle?
For a small no-customization site, MoodleCloud Starter — its smallest fixed annual tier. For a customizable site, an inexpensive small Hetzner or DigitalOcean box — but only if you'll actually do the patching and backups yourself; otherwise the "cheap" option costs you a breach or a lost site.