Hubs & spokes

Nucleus organises Moodle into a federation: one hub, many spokes.

The hub

The hub is the authoritative Moodle. It holds:

• The canonical course catalogue — courses authored once, distributed to spokes.
• (Optionally) the canonical user identity — see Federation.

Every customer has exactly one hub. It's the centre of gravity.

Spokes

Spokes are the downstream Moodles. Each spoke is its own tenant:

• Its own database
• Its own Kubernetes namespace
• Its own moodledata PVC
• Its own users, grades, certificates

Spokes consume from the hub but are otherwise independent — a problem on one spoke doesn't reach the others. They have their own subdomain, their own admin, their own theme.

Why this shape and not multi-site Moodle

Moodle's built-in multi-site model (multi-tenancy via mnet, or shared codebase with per-customer config) keeps everything in one database. Convenient until it isn't: noisy neighbours, hard upgrades, hard backups, hard to delete one customer cleanly.

Federation trades the cost of running N pods for genuine isolation. A spoke can be backed up, restored, suspended, deleted, or migrated without touching the others. It costs more compute; it pays back the first time a customer asks to leave with their data.

The lifecycle

A spoke goes through six states from request to delete — see Tenant lifecycle.

How automation talks to a federation

Most API calls are scoped: GET /federations/:id/spokes, POST /federations/:id/spokes, etc. Hub admins are restricted to their own federations; operators see everything. See Federations and Spokes for the concrete surface.