Moodle VPS or Managed Hosting: The True Cost for UK Organisations

Contracting a Moodle VPS might seem like an obvious solution for those tired of shared hosting, often costing less than £30 a month. However, the monthly fee is only a small part of the total expense. This comparison reveals what a VPS truly delivers and what responsibilities remain with you, the actual annual cost of updates, backups, and security, and when each option makes sense for an online learning institution.

TL;DR

• A Moodle VPS delivers hardware, network, and root access. The operating system, PHP, database, cron, Moodle backup, updates, and incident response remain with your team.
• Moodle releases a major version every 6 months and a minor version every 2 months. That’s at least 8 update windows per year, all the responsibility of whoever administers the server.
• The weekly backup included in a VPS plan is not a Moodle backup. You need consistent database and moodledata backups, stored off-server, with restoration tested.
• On a VPS, the monthly fee rarely exceeds 20% of the annual cost. The rest comprises technical hours and the risk of your VLE going down during exam week.
• A VPS makes sense when you have an in-house sysadmin with available time and on-call duty. Without that, managed Moodle hosting works out cheaper annually.

What you buy when you contract a Moodle VPS

A VPS (Virtual Private Server) is a slice of a physical server with dedicated CPU, memory, and disk. The provider ensures the machine is powered on, has network connectivity, and is operational. Beyond that, everything is your responsibility.

Hostinger's pricing page, consulted on 18/10/2026, states this explicitly: the client receives root access and is "responsible for their virtual private server." This isn't a flaw of Hostinger; it's the model. It applies to Hetzner, Contabo, DigitalOcean, Locaweb, or any other provider.

A Moodle VPS only becomes a VLE after someone installs and maintains, at a minimum:

• Operating system updated, with firewall and hardened SSH access.
• Web server (Nginx or Apache) pointing to the correct folder. Since Moodle 5.1, this folder has changed, as you'll see below.
• PHP-FPM in the version required by the Moodle release, with OPcache and mandatory extensions.
• Database (MariaDB, MySQL, or PostgreSQL) at the minimum supported version.
• Redis for sessions and cache, because disk-based sessions are the first bottleneck on exam day.
• Cron running every minute. The official documentation is clear: without cron, "your site will not function correctly."
• moodledata outside the public folder, with correct permissions.
• SSL, automatic certificate renewal, and transactional email that avoids spam folders.
• Backup, monitoring, and alerts.

None of this is difficult for someone who does it every day. The problem is that almost no online learning institution has someone doing this every day.

Who manages what: Moodle VPS vs. managed hosting

The most honest way to compare the two models is to ask who is responsible for each layer when something goes wrong. We've already published the generic matrix for managed hosting vs. VPS. Here's the Moodle-specific version:

Layer	Unmanaged VPS	Managed Moodle Hosting
Hardware, network, power	Provider	Provider
OS, patches, firewall	Your team	Provider
PHP, database, Redis, Nginx	Your team	Provider
Cron and scheduled tasks	Your team	Provider
Minor Moodle updates (every 2 months)	Your team	Provider
Major updates and plugins (every 6 months)	Your team	Provider, with your approval
Database and moodledata backup	Your team	Provider
Restoration testing	Your team (rarely happens)	Provider, with contractual periodicity
Monitoring and alerts	Your team	Provider
Out-of-hours incident	Whoever answers the phone	Contractual SLA
Content, courses, enrolments	Your team	Your team

Note the last line. Managed hosting doesn't remove the academic work from the institution: coordination, tutoring, and administration remain with you. It removes the infrastructure work, which is precisely not the institution's core business.

The VPS SLA doesn't protect your VLE

VPS providers advertise 99.9% or 99.99% availability. This figure measures whether the virtual machine is powered on. If PHP-FPM exhausts processes when a questionnaire opens, the VPS is "online," and the student sees a 502 error. For the provider, no incident occurred.

The Moodle calendar that creates work for your VPS

This is the point that most affects those who migrate to a Moodle VPS thinking "it's just a matter of installing it." Moodle has a fixed calendar, published on the official releases page:

• Major versions every 6 months, in April and October.
• Minor versions every 2 months, in February, April, June, August, October, and December. These bring security fixes.
• Out-of-calendar releases when emergency fixes are needed.

Status of each version on 18/10/2026, according to the same page:

Version	Release	End of general support	End of security support
4.5 LTS	07/10/2024	06/10/2025	04/10/2027
5.0	14/04/2025	20/04/2026	05/10/2026 (ended)
5.1	06/10/2025	05/10/2026	19/04/2027
5.2	20/04/2026	19/04/2027	04/10/2027
5.3 LTS	05/10/2026	04/10/2027	01/10/2029

Anyone still running 5.0 is, today, without any security patches. We detail the exit routes in the post about the end of Moodle 5.1 support.

Minor updates: routine, but not automatic

On a Moodle VPS, each minor version means: downloading the code, maintaining config.php and plugins, putting the site into maintenance mode, running the upgrade from the command line, clearing caches, and checking that nothing broke. In my experience, this takes one to two hours per environment when all goes well. That's at least six times a year.

Major updates: where the VPS bills you

A major version is a different story. Here are three real-world examples from 2025-2026 that come as a surprise to those who administer their own VPS:

1. The public folder changed in Moodle 5.1. According to the upgrade documentation, from 5.1 onwards, only the /public folder should be web-accessible, and the server's document root needs to point to it. Without this adjustment in Nginx or Apache, the upgrade won't proceed. Plugins installed via Git also need to be relocated.
2. PHP minimum version increases. Moodle 5.2 began requiring PHP 8.3. Those who set up their VPS on Ubuntu 22.04 have PHP 8.1 in the standard repositories and will need an external repository or a full operating system upgrade. Ubuntu 24.04 already includes 8.3.
3. PHP itself reaches end-of-life. According to the official PHP table, PHP 8.2 loses security support on 31/12/2026. A VPS stuck on 8.2 will enter 2027 with an unpatched interpreter.

Each major upgrade requires a staging environment, testing of third-party plugins, and a maintenance window outside of teaching hours. For a VLE with a custom theme and half a dozen plugins, I estimate 8 to 16 hours of technical work per major version.

True backup on a Moodle VPS

Most VPS plans include some form of backup. Hostinger's, for example, is weekly. This seems sufficient until the first difficult question: if the server becomes corrupted on a Friday, is the institution willing to lose six days of submissions, grades, and forum messages?

The Moodle backup documentation lists three things to protect: the database, the moodledata folder, and the code (with plugins and customisations). The database and moodledata change constantly and require frequent copies. The database dump should be consistent, using an option like --single-transaction, to avoid capturing "half-baked" data.

What a Moodle VPS backup needs to include

• Database and moodledata from the same moment. Restoring a Tuesday database with Sunday files results in tasks pointing to non-existent files.
• Copy outside the VPS. A snapshot with the same provider doesn't protect against account suspension, billing errors, or data centre incidents.
• Retention policy. Accidental course deletion is often discovered days later. A single copy, overwritten every night, won't solve this.
• Tested restoration. A backup that has never been restored is merely a hypothesis. It's also the item that is usually first to disappear from the routine of someone administering a VPS alone.

When the provider's backup is sufficient

For test environments, pilot courses with few students, or a VLE that can revert a week without significant detriment, the provider's snapshot may suffice. For an institution with graded assessments and certificates, it's not enough.

Security: what lands in the inbox of a Moodle VPS owner

Moodle is mature software with an active security team. This also means that vulnerabilities are found, published, and patched throughout the year. For example: on 29/04/2026, CERT-FR, the French government's incident response centre, published alert CERTFR-2026-AVI-0508, detailing seven Moodle vulnerabilities, including remote code execution and SQL injection. The fixes were released in versions 4.5.11, 5.0.7, and 5.1.4.

For those with managed hosting, this alert is a task for the provider. For those with a Moodle VPS, it poses a question: who in the institution read this alert, and how many days did it take to apply the fix?

The minimum security a VPS requires

• Subscribe to Moodle's security announcements and apply minor versions without delay.
• Update OS, PHP, and database with the same discipline.
• Block SSH login by password, use key-based authentication, and limit attempts (fail2ban or equivalent).
• Place a WAF in front of the VLE and limit requests on login routes.
• Review unmaintained third-party plugins: these are the most common entry point I find in inherited environments.
• Remember UK GDPR and the Data Protection Act 2018: the VLE often stores personal data, grades, and data of minors. A breach due to an outdated server is a security incident with a duty to communicate. We cover this topic in our post on UK GDPR in Moodle.

Real cost of a Moodle VPS over 12 months

Let's look at the numbers. First, the monthly fee. Hostinger prices on 18/10/2026, excluding card processing fees and for a long-term contract:

Plan	vCPU / RAM / NVMe	Promotional Price	Renewal Price
KVM 1	1 / 4 GB / 50 GB	£9.99/month	£19.99/month
KVM 2	2 / 8 GB / 100 GB	£14.99/month	£25.99/month
KVM 4	4 / 16 GB / 200 GB	£19.99/month	£49.99/month
KVM 8	8 / 32 GB / 400 GB	£39.99/month	£84.99/month

Two observations. The renewal of KVM 4 costs 2.5 times the introductory price; calculate with the renewal value, not the promotional one. And VPS prices are not stable: the German provider Hetzner adjusted its portfolio in April 2026 and again in June, with some lines more than doubling.

For a VLE with a few hundred peak concurrent users, a reasonable Moodle VPS starts in the range of 4 vCPU and 16 GB. This amounts to something between £240 and £600 per year just for the hardware. How to size for your actual peak is covered in our guide to concurrent users in Moodle.

The part that doesn't appear on the invoice

Now, the hours. The estimate below is from my operations, not a market average. Adjust for your reality:

Task	Frequency	Hours/year (estimate)
Minor Moodle versions	6 per year	6 to 12
Major version, with staging approval	1 to 2 per year	8 to 32
OS, PHP, and database patches	monthly	12
Backup restoration testing	quarterly	8
Monitoring, alerts, and minor incidents	continuous	24 to 36
Total		58 to 100 hours

Hypothetical example: if the technical hour you pay costs £50, that's between £2,900 and £5,000 per year. Even in the optimistic scenario, the hardware is less than 20% of the cost. And this calculation doesn't even include the most expensive part: the VLE being down on the eve of an exam, with the coordination team responding to student messages one by one.

When each option makes sense for your institution

Neither model is right for everyone. The criterion I use with clients is simple: who will wake up at 3 AM when the VLE goes down?

A Moodle VPS makes sense when:

• The institution has an in-house Linux sysadmin, with time reserved for the VLE and holiday cover.
• There is genuine on-call duty during critical periods: admissions, exam week, start of term.
• The VLE is internal or low-criticality: optional corporate training, test environment, pilot.
• IT policy requires full server control, for example, for integrations with internal systems that only run on the institution's network.

A Moodle VPS does not make sense when:

• IT is a single person who also manages networking, printers, and email.
• Moodle generates revenue: paid courses, postgraduate distance learning, time-sensitive certifications.
• No one can say when the last restoration test was performed.
• The VPS was set up by a freelancer who is no longer available, and no one is sure of the root password.

Signs it's time to move away from your VPS

Your VLE is two or more minor versions behind. PHP is nearing end-of-life. The disk filled up without warning. The coordination team discovers the site is down via student WhatsApp messages. If two of these appear together, the decision has already been made by the facts.

Pitfalls we see in inherited Moodle VPS environments

Most of the environments we take over come from a VPS that worked well in the first year. The recurring problems are:

1. Cron running every 15 minutes (or not at all). Notifications are delayed, course completion isn't calculated, and emails are sent in batches.
2. moodledata inside the public folder. Student files accessible via direct URL.
3. Backup that only copies the database. Upon restoration, courses appear without any files.
4. Disk-based sessions. During peak times, the VLE logs out students mid-quiz.
5. Disk full due to logs and trash. Moodle stops writing, and no one receives an alert.
6. Abandoned plugins blocking upgrades. The institution gets stuck on an unsupported version because a plugin lacks a compatible version.

If your institution has already decided to move, the technical guide is in how to migrate Moodle from one server without losing data.

How Agathas Web solves this

Agathas Web's managed Moodle hosting exists to take the infrastructure burden off the institution without removing its control over the VLE. In practice, what's included:

• Moodle-optimised stack: PHP 8.3 with OPcache, PHP-FPM with a dedicated pool, Nginx, MariaDB 10.11+, Redis for sessions and cache, and isolated cron on its own worker. No cPanel and no sharing CPU with WordPress sites.
• Daily backup with binlog every 15 minutes, encrypted offsite copy, and restoration tested monthly.
• Moodle updates within 90 days of release, always passing through staging environment approval, with a window agreed upon with the coordination team.
• Security: Cloudflare WAF, fail2ban, request limits on critical routes, and operating system hardening.
• Monitoring with Grafana, Prometheus, Sentry, and external UptimeRobot, with alerts to the technical team's WhatsApp.
• Contractual SLA: 99.9% availability and response within 15 minutes for critical incidents.

How the contracting process works

1. Diagnosis: We assess your Moodle version, plugins, moodledata size, and peak concurrent users.
2. Proposal: The plan is sized for your actual peak usage, not the average.
3. Assisted migration: Within 5 business days, with staging environment approval and written sign-off before go-live.
4. Go-live outside of teaching hours, with the old environment preserved for 30 days for rollback.

Should the institution ever wish to leave, we provide a complete backup. I am certified by the Moodle Academy and have administered Moodle since 2008, but Agathas is independent: we are not a Moodle Partner, and our commitment is in the contract, not a badge. To request a diagnosis, speak with our team via the Moodle hosting page.

Conclusion: a Moodle VPS is cheap; administering it is not

The choice between a Moodle VPS and managed hosting is not about the price of the hardware. It's about who takes on 8 update windows per year, the backup that needs to be restored within hours, and the security alert that arrives on a Friday night.

If your institution has an in-house sysadmin and on-call duty, a VPS delivers control and genuine savings. If not, the low monthly fee hides an annual cost several times higher and a risk that falls on the coordination team during the worst week of the semester.

The next practical step: list who, today, performs each line of the responsibility matrix in this post. If several remain blank, it's worth exploring Agathas Web's managed Moodle hosting and requesting a diagnosis of your environment.