MoodleCloud vs self-hosted Moodle

Moodle's core code is GPL-3.0 licensed, so there is no license fee for the LMS itself. The recurring cost is the infrastructure and the people who run it: servers or cloud accounts, PHP and database hosting, backups, monitoring, storage that grows with course media, and staff time for patching and upgrades. Costs rise with concurrent users, video and file volume, the number of plugins you maintain, and how many environments (test, staging, production) you keep. Ask any provider for a quote that separates one-time setup, recurring hosting, and recurring support, and that names which party handles Moodle upgrades, plugin compatibility checks and restores. DeployOpen does not publish a price list; a quote follows from a written scope.

MoodleCloud annual plans are billed in Australian dollars. The Starter plan is 230 AUD per year for 50 users and 1 GB of storage, Mini is 380 AUD for 100 users and 2.5 GB, Small is 700 AUD for 200 users and 5 GB, Medium is 1,700 AUD for 500 users and 20 GB, and Standard is 3,000 AUD for 750 users and 50 GB. The caps that usually bite first are user count and storage, since video-heavy courses fill 1 to 5 GB quickly. Plans cannot install plugins or integrations, custom domains are a 160 AUD per year add-on on Medium and included on Standard, and Stripe course sales start at the Small plan. Moodle's team hosts and updates the site, and a 28-day free trial is offered. Confirm current prices with Moodle before budgeting, since the published figures are the only ones this page can cite.

Yes, if your team has Linux server administration, PHP and database skills, and the time to patch on Moodle's release cadence. Moodle ships major releases in April and October and minor point releases every two months, so someone must own that calendar. Upgrades carry real requirements: Moodle 5.1 requires 64-bit PHP 8.2 or later and sites must be on Moodle 4.2.3 or later, while Moodle 5.3 requires PHP 8.3 or later and sites must run Moodle 4.4 or later. From Moodle 5.1 the web server document root must point to the /public directory. Teams without this depth often bring in a partner for setup, hardening and upgrades. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in the client's own infrastructure, under fixed-scope agreements or retainers.

The timeline depends on scope, not on a single default. The main variables are the hosting target (cloud account, data center or air-gapped network), the database choice, identity integration such as LDAP, SAML or OAuth 2, the number of plugins, content migration volume, and the approval process for production access. Your team must supply infrastructure access, a named owner for decisions, identity provider details, a backup and retention policy, and test users for acceptance. Agree the timeline and deliverables in writing before work starts; any duration quoted without a written scope should be questioned. Ask any provider to list the environments, the migration steps and the acceptance tests they will deliver.

MoodleCloud sites cannot install any plugins or integrations. A self-hosted Moodle can install plugins from the Moodle plugin ecosystem, subject to compatibility with your Moodle version. Core already includes authentication plugins for manual accounts, email self-registration, external database, LDAP, LTI, OAuth 2, Shibboleth and web services. Single sign-on through SAML 2 is available as a plugin, and custom integrations are possible in a self-hosted install. Before you commit, list the integrations you need (SSO, HR feeds, payment gateways, reporting, AI providers), then check each one against the plugin's support status for your target Moodle release. Confirm any integration you depend on with the plugin maintainer or your provider, since compatibility varies by version.

Moving between MoodleCloud and a self-hosted site is a migration project, so plan it as one. Confirm what export and import paths Moodle provides for courses, users, grades, files and enrollments, and test them on a copy of your data before cutover. Check that custom domain, Stripe payment and course sales settings are rebuilt on the new host, that user passwords and authentication methods carry over, and that learners receive new login details if needed. Storage and course media often take the longest to move. Ask for a migration plan with a named rollback point, acceptance tests and a cutover window. Moving in the other direction, from self-hosted to a hosted plan, is constrained by the plan caps and the no-plugin rule, so check those before you leave the self-hosted environment.

Start by writing down the growth you expect over the next few years: users, storage, integrations and whether you will sell courses. MoodleCloud suits individuals selling courses and small organisations with straightforward needs, and it offers integrated video conferencing for up to 100 users. Once you need more plugins, custom authentication, larger storage or tighter control over hosting and data location, self-hosting becomes the better fit, and it carries the upgrade and security workload that comes with it. Moodle's own page points larger or more complex requirements to its Solutions team. Ask both paths for a quote tied to the same three-year user and storage forecast so the comparison is fair.