Why Moodle hosting gets messy, and what multi-tenancy actually solves
Take a multi-academy trust with twelve schools. The central office has a simple ask, run the same safeguarding refresher every September, everywhere. The course already exists and it’s solid. The snag is distribution. It needs to appear in twelve Moodle sites while keeping the bits that matter separate, each school’s enrolment rules, each school’s reporting, and learner data that stays inside that school’s own tenant.
What you can do today mostly comes with a catch.
One approach is to host all twelve schools in a single Moodle. IOMAD is the obvious example, it’s established, it’s free, and for many organisations it does exactly what it says on the tin. Schools become “companies” inside one install. The problem isn’t that it doesn’t work, it’s the boundary. All the data sits in the same database and is separated with row-level filtering. When someone asks, “So where is our learner data actually stored?”, the truthful answer is, “In the same place as everyone else’s, split apart by a column.” In regulated settings, that explanation can turn into a long meeting.
Another option is the cleanest on paper, twelve separate Moodles. Each school gets its own install, its own database, its own backups, clear tenant separation. Then reality arrives. Central has to ship that safeguarding course twelve times. They can do it by publishing manually, or by pushing backups around and restoring them again and again, or by building a process for rolling out updates when a question changes. Isolation is strong, but the workflow is painful, and it stays painful.
The third option is to pay someone to stitch everything together. There’s an entire market of Moodle operations teams doing exactly this with custom scripts, manual MBZ handling, and the occasional spreadsheet to make sure nothing got missed. It can be made to run. It’s also not what most organisations want to be funding in 2026.
The shape that actually fits
Federation.
Each tenant runs its own Moodle with its own database, so the boundary is real. On top of that, the tenants can communicate through a defined protocol so you can move content around without collapsing everything into one shared install.
In practice it looks like a hub-and-spoke setup. Central office runs a “hub” Moodle. Every school runs a “spoke.” The hub publishes a course, the spokes pull it. Learner data stays local to each school’s database. Schools can keep the pulled course aligned with the hub’s version, modify their local copy, or sit somewhere in between.
That’s the core of what Nucleus is, isolated per-tenant Moodles plus a federation layer that handles publishing, pulling, version tracking, and change notifications when something upstream has moved.
Once you start from that shape, a few things become much easier than they are with “one shared tenant” or “twelve unrelated Moodles.”
Course versioning becomes a normal thing
When the hub publishes v1.1.0 of the safeguarding course, it’s a versioned, signed artefact. Spokes are told it exists. Each school can pull it immediately, schedule it, or stay on v1.0.0 until they’re ready. And when they do pull, they get a new local course, the old one stays put so the learner records tied to v1.0.0 don’t vanish. Also, the hub’s draft edits are separate from what spokes currently see as live.
Identity can be either centralised or left alone
Not every federation wants the same identity model. Some want content sharing only, with each school continuing to own its users, call that Mode A. Others want the central office to own the user record and project identities down to the schools, call that Mode B. Both are supported as first-class approaches, you pick the one that matches how you operate. NHS trusts often lean toward Mode B because of compliance pressures. Training bodies often prefer Mode A.
Operations stay tenant-by-tenant
A school can pause its Moodle, restore from a different backup, or upgrade on its own timeline, within reason. One school running a custom theme doesn’t create problems for everyone else. The federation layer isn’t asking every tenant to run identical Moodle configuration or to move in lockstep.
The trade-off
You do pay in operational complexity.
Provisioning a tenant means spinning up a database, deploying a pod, establishing trust between hub and spoke, capturing tokens, and configuring web services. If someone asks whether federation is overkill, the honest answer is that for many organisations, on many days, yes, it would be.
The reason it becomes workable is automation. I’ve spent the last six months building a control plane that runs the whole process in about 60 seconds end-to-end from customer signup. On the engineering side, that’s a large part of what Nucleus is, making federation feel like a SaaS product instead of a manual integration exercise.
What’s next
There’s more to unpack, course versioning in particular, plus identity federation and why I ended up with these design choices. That’s what this series is for.
Next post: course versioning, what it looks like when the hub publishes v1.1.0 and each spoke has to decide whether to take it now, later, or not yet.