Moodle multi-tenant senza Workplace: guida pratica

Se sei un consulente Moodle, un'azienda di e-learning, o un gruppo che vuole una piattaforma per più unità organizzative, prima o poi ti trovi di fronte a questa domanda: gestisco tutto su un unico Moodle o installo istanze separate?

E subito dopo: "Ho sentito che serve Moodle Workplace — ma quanto costa?"

Questa guida risponde a entrambe.

Perché Workplace non è la "versione gratuita di Moodle"

È il malinteso più comune, e vale la pena chiarirlo subito perché porta a decisioni sbagliate.

Moodle LMS è il prodotto open source, gratuito, mantenuto dalla community. È quello che usi quasi certamente adesso.

Moodle Workplace è un prodotto commerciale separato, sviluppato da Moodle HQ e venduto esclusivamente tramite Moodle Partner certificati. Aggiunge funzionalità native di multi-tenancy (tenant con dati segregati), workflow aziendali, programmi di apprendimento avanzati — ma ha un costo di licenza annuale significativo.

La versione "gratuita" di Moodle che tutti usano è Moodle LMS. Workplace non è una versione aggiornata o premium di LMS — è un prodotto diverso con una base di codice separata che viene mantenuta in sync con LMS.

Per la maggior parte dei casi d'uso di multi-tenancy che vediamo, Workplace non è necessario.

Cohorts + Theme override: la base senza codice

Il punto di partenza per il multi-tenant su Moodle LMS standard sono le Cohorts (gruppi globali) combinate con i Course Categories e il tema Boost (o un tema custom).

Cosa puoi fare nativamente:

• Separazione dei corsi per categoria. Ogni tenant ha la sua categoria di corsi. Gli utenti di un tenant vedono solo i corsi della propria categoria tramite restrizioni di enrolment.
• Cohorts per utenti. Gli utenti sono assegnati alla cohort del loro tenant. Le regole di enrolment automatico possono iscrivere automaticamente tutti i membri di una cohort a un corso.
• Custom menu per tenant. Boost Themes (e la maggior parte dei temi custom) supportano un menu di navigazione per-tenant configurabile via CSS/Sass con selettori basati su un attributo HTML che identifica il tenant.

Limite principale di questo approccio: non c'è isolamento visivo vero. Un utente che conosce l'URL dei corsi di un altro tenant può tentare di accedervi (anche se le enrolment rules lo bloccano a livello di accesso al contenuto). Non è adatto se i tenant hanno requisiti di branding completamente separati o se il cliente vuole che i suoi utenti "non vedano mai" che ci sono altri tenant.

Plugin open source per la multi-tenancy

Esistono plugin Moodle che aggiungono funzionalità native di multi-tenancy. Il più noto è local_multitenancy (disponibile su moodle.org/plugins), che aggiunge:

• Un pannello di amministrazione per-tenant
• Isolamento dei manager per tenant (un admin di tenant non vede gli utenti degli altri tenant)
• Restrizioni sui report per tenant
• Possibilità di branding separato per tenant

Pro: riduce la complessità rispetto a una soluzione completamente custom, è mantenuto dalla community.

Contro: l'isolamento dei dati è a livello logico, non fisico. Il supporto per scenari edge (migrazione tenant, export dati per GDPR per singolo tenant) può richiedere sviluppo custom. La manutenzione dipende da chi mantiene il plugin nel Plugin Directory.

Prima di adottare un plugin open source per multi-tenancy in produzione, verificate sempre: ultima versione rilasciata, compatibilità con la vostra versione Moodle, numero di installazioni attive e reattività del maintainer alle issue.

Soluzione custom: tenant detection via subdomain

Per scenari con più di 10 tenant o con requisiti di branding rigidi, la soluzione che preferiamo è un plugin local con tenant detection via subdomain.

Il principio: ogni cliente accede alla propria istanza tramite un sottodominio dedicato (es. clienteA.tuapiattaforma.it, clienteB.tuapiattaforma.it). Un unico server Moodle gestisce tutte le richieste. Il plugin intercetta la request e applica configurazione, tema e restrizioni di dati specifiche per quel tenant.

// local/tenant_router/lib.php
function local_tenant_router_after_config(): void {
    global $CFG;
 
    $host = $_SERVER['HTTP_HOST'] ?? '';
    // Estrae il subdomain: 'clienteA' da 'clienteA.tuapiattaforma.it'
    $parts = explode('.', $host);
    if (count($parts) < 3) {
        return; // Nessun subdomain — homepage principale
    }
 
    $subdomain = $parts[0];
    $tenant = local_tenant_router_load_tenant($subdomain);
 
    if (!$tenant) {
        // Subdomain non riconosciuto — redirect alla homepage o 404
        redirect(new moodle_url('/'), '', null, \core\output\notification::NOTIFY_ERROR);
    }
 
    // Override configurazione per questo tenant
    $CFG->wwwroot   = "https://{$host}";
    $CFG->theme     = $tenant->theme ?? 'boost';
    $CFG->sitelogo  = $tenant->logo_url ?? '';
 
    // Salva il tenant corrente nel session namespace
    // per usarlo nei capability checks
    $_SESSION['current_tenant_id'] = $tenant->id;
}

Il hook after_config viene chiamato da Moodle ad ogni request, prima che qualsiasi output venga generato — il punto giusto per intercettare e re-direzionare la configurazione.

La funzione local_tenant_router_load_tenant() legge la configurazione del tenant da una tabella custom nel database (nome, logo, colori tema, ID manager, corsi accessibili).

Confronto TCO: Workplace vs Cohorts vs Custom

Per la maggior parte degli scenari under 20 tenant con clienti business standard, la soluzione custom con subdomain ha un break-even rispetto a Workplace di 12-18 mesi.

Quando Workplace vale davvero la pena

Siate onesti con i vostri clienti: ci sono casi in cui Workplace è la scelta giusta.

• Requisiti di isolamento fisico dei dati. Se il vostro cliente è in un settore regolato (healthcare, finance) e deve dimostrare che i dati di ciascun tenant sono in tabelle separate con access control separati a livello DB, Workplace è la risposta — non una soluzione custom su Moodle LMS.
• Workflow aziendali nativi. Workplace include funzionalità di programmi di apprendimento strutturati, approvazioni manager, certificazioni con scadenza gestite nativamente. Queste si possono sviluppare su LMS, ma è lavoro.
• SLA commerciale su tutto lo stack. Se il vostro cliente vuole un unico vendor responsabile del software, dell'hosting e del supporto, Moodle HQ + Partner è la strada.

Se nessuno di questi tre casi vi riguarda, probabilmente non avete bisogno di Workplace.

Per approfondire la logica di scelta tra soluzioni esistenti e sviluppo custom, leggi il nostro articolo su plugin Moodle vs sviluppo custom.

Se state valutando l'hosting per questa architettura, leggi anche il nostro approfondimento su hosting Moodle — le considerazioni di performance per multi-tenant sono diverse da un'istanza singola.

Conclusione: tre punti da portare via

1. Workplace non è obbligatorio per il multi-tenant. Per la maggior parte degli use case business, un plugin open source o una soluzione custom è tecnicamente equivalente e più economica.

2. La complessità cresce con i requisiti di isolamento. Se un cliente dice "i miei utenti non devono sapere che esistono altri clienti sulla piattaforma", serve la soluzione subdomain. Se dice "basta che non vedano i corsi degli altri", bastano le categorie.

3. Il TCO di Workplace include la licenza in perpetuo. Con una soluzione custom, dopo il setup paghi solo la manutenzione. Con Workplace paghi la licenza ogni anno indipendentemente da quanto lo usi.

Stai valutando Workplace ma il preventivo del partner ti sembra alto? Mandaci il numero di tenant e i requisiti: in 24 ore ti diciamo se ha senso una soluzione custom e quanto costerebbe.