Multi-tenant per Agenzie — Architettura SaaS per Gestire più Clienti senza Impazzire

Hai 15 clienti, ognuno con la propria dashboard, i propri dati, le proprie fatture. Se per ogni nuovo cliente duplichi l'installazione, stai costruendo un cimitero di codice e un incubo di manutenzione. Il multi-tenant non è un lusso da architetti software: è la differenza tra un'agenzia che scala e una che affoga nella gestione. Noi, di Meteora Web, lo sappiamo bene: abbiamo costruito una piattaforma proprietaria per gestire la presenza social di più clienti, e senza un'architettura multi-tenant sarebbe stato impossibile tenere il ritmo.

Cos'è il multi-tenant e perché conviene alla tua agenzia?

Il multi-tenant è un'architettura software dove una singola istanza dell'applicazione serve più clienti (tenant), isolando i loro dati. Pensala come un condominio: un solo edificio, tanti appartamenti, ognuno con la sua serratura. L'alternativa è il single-tenant: un edificio separato per ogni famiglia — costoso da mantenere, difficile da coordinare.

Per un'agenzia, il multi-tenant significa: una sola base di codice da aggiornare, un solo server da monitorare, costi infrastrutturali condivisi. Ma il vero vantaggio è operativo: quando rilasci una nuova funzionalità, la rilasci per tutti i clienti in un colpo solo. E quando un cliente chiede una personalizzazione, la isoli senza toccare il resto.

Il rischio? L'isolamento dei dati. Se un tenant può vedere i dati di un altro, hai un problema legale e di fiducia. Per questo l'architettura multi-tenant richiede disciplina: ogni query deve filtrare per tenant, ogni cache deve essere segregata, ogni job asincrono deve conoscere il suo contesto.

Come funziona l'isolamento dei dati nel multi-tenant?

Ci sono tre approcci principali:

• Database separato per tenant: massimo isolamento, ma costoso e difficile da scalare oltre qualche decina di clienti.
• Schema separato per tenant: buon compromesso, ma richiede migrazioni complesse.
• Shared schema con colonna tenant_id: il più comune per SaaS, economico e scalabile, ma richiede rigore assoluto nelle query.

Noi abbiamo scelto la terza via per la nostra piattaforma social: una colonna tenant_id su ogni tabella, e un middleware che inietta automaticamente il filtro. Zero possibilità di dimenticanze.

Come gestire l'onboarding di un nuovo cliente senza attriti?

L'onboarding è il momento in cui il multi-tenant brilla o fallisce. Se devi creare manualmente un database, configurare un dominio, settare le credenziali, stai perdendo tempo prezioso. Con un'architettura multi-tenant ben fatta, l'onboarding è un flusso automatizzato: crei il tenant, assegni un piano, invii l'invito.

Nel nostro caso, quando un cliente si registra, il sistema crea il tenant, genera un sottodominio (es. cliente.tuapiattaforma.com), configura le impostazioni di default e invia una email di benvenuto con le credenziali. Tutto in pochi secondi, senza intervento manuale.

Quali dati isolare per ogni tenant?

Non basta mettere tenant_id ovunque. Devi decidere cosa è condiviso e cosa no. Ecco la nostra checklist:

• Utenti e ruoli: ogni tenant ha i suoi utenti, con permessi specifici.
• Configurazioni: logo, colori, dominio personalizzato — tutto deve essere per-tenant.
• Dati operativi: ordini, clienti, fatture — ovviamente isolati.
• File e media: se usi storage cloud, separa le cartelle per tenant.
• Log e audit trail: ogni azione deve essere tracciata per tenant, per rispondere a eventuali dispute.

Quali sono le sfide di performance nel multi-tenant?

Quando tutti i tenant condividono le stesse tabelle, le query diventano più pesanti. Un indice su tenant_id è obbligatorio, ma non basta. Devi pensare a:

• Cache per tenant: se un tenant ha dati molto diversi, la cache globale può mischiare i risultati. Usa chiavi con prefisso tenant.
• Job asincroni: se un tenant invia 10.000 email, non deve bloccare gli altri. Usa code con priorità per tenant.
• Rate limiting: un tenant che fa abuso di API può rallentare tutti. Imposta limiti per tenant, non globali.

Come implementare il multi-tenant in Laravel?

Laravel è il nostro cavallo di battaglia, e ha un ecosistema maturo per il multi-tenant. Ecco un esempio pratico con il pacchetto stancl/tenancy:

// Configurazione del middleware per identificare il tenant dal dominio
Route::middleware(['tenant'])->group(function () {
    Route::get('/dashboard', [DashboardController::class, 'index']);
    Route::resource('/orders', OrderController::class);
});

// Nel modello base, aggiungi il filtro automatico
class Order extends Model
{
    protected static function booted()
    {
        static::addGlobalScope('tenant', function (Builder $builder) {
            $builder->where('tenant_id', tenant()->id);
        });
    }
}

// Creazione di un nuovo tenant durante l'onboarding
$tenant = Tenant::create([
    'name' => 'Cliente XYZ',
    'domain' => 'xyz.tuapiattaforma.com',
]);
$tenant->domains()->create(['domain' => 'xyz.tuapiattaforma.com']);
$tenant->run(function () {
    // Esegui migrazioni o seed specifici per il tenant
    Artisan::call('db:seed', ['--class' => 'TenantSeeder']);
});

Questo è un esempio semplificato, ma funzionante. Il punto chiave è il global scope: ogni query su Order avrà automaticamente il filtro tenant_id, senza che tu debba ricordarlo in ogni controller. Meno errori, più sicurezza.

Come gestire i costi e la fatturazione per ogni tenant?

Noi veniamo dalla contabilità: bilanci, partita doppia, IVA. Per questo sappiamo che il multi-tenant non è solo tecnica, è anche business. Ogni tenant deve essere associato a un piano, e il sistema deve tracciare l'utilizzo per fatturare correttamente.

Nel nostro SaaS, ogni tenant ha un piano (Base, Pro, Enterprise) con limiti di risorse: numero di utenti, post programmati, spazio di archiviazione. Quando un tenant supera il limite, il sistema lo notifica e propone un upgrade. La fatturazione è integrata: alla fine del mese, generiamo le fatture per tutti i tenant in automatico, con IVA e ritenute gestite dal sistema.

Come implementare la fatturazione multi-tenant?

Se usi Stripe, puoi sfruttare i subscription items per tracciare l'utilizzo per tenant. Ecco uno schema:

// Creazione di una subscription per il tenant
$tenant->newSubscription('main', $plan->stripe_price_id)
    ->create($paymentMethod);

// Tracciamento dell'utilizzo (es. numero di post)
$tenant->usage('posts')->add(1);

// Fatturazione automatica a fine mese
$invoice = $tenant->invoice();

Il vantaggio è che Stripe gestisce i pagamenti ricorrenti, e tu hai un report chiaro di quanto ogni tenant ti rende. Esattamente quello che serve per capire se il tuo SaaS sta generando margini, non solo fatturato.

Quali errori evitare nel multi-tenant?

Abbiamo visto progetti fallire per errori banali. Ecco i tre più comuni:

• Dimenticare il tenant_id nelle query: un errore che può esporre dati sensibili. Usa sempre i global scope, mai query manuali senza filtro.
• Cache condivisa senza prefisso: un tenant vede i dati di un altro. Usa chiavi cache con il tenant_id, sempre.
• Migrazioni non reversibili: quando aggiungi una colonna a una tabella condivisa, assicurati che la migrazione sia testata con dati reali. Un errore qui blocca tutti i tenant.

Cosa fare adesso

Se stai pensando di costruire un SaaS white label per la tua agenzia, il multi-tenant è il cuore. Non puoi rimandare questa decisione. Ecco tre azioni concrete:

1. Valuta il tuo stack: se usi Laravel, esplora stancl/tenancy o tenancy/tenancy. Se usi altri framework, cerca soluzioni analoghe. La cosa importante è che l'isolamento sia automatico, non manuale.
2. Progetta il modello dati: identifica tutte le tabelle che devono avere tenant_id e quelle condivise (es. piani, configurazioni globali). Scrivi una checklist e verificala con il tuo team.
3. Automatizza l'onboarding: crea un flusso che genera tenant, domini e configurazioni in pochi secondi. Se l'onboarding richiede più di 5 minuti, stai perdendo tempo.

Noi, di Meteora Web, abbiamo scelto questa strada per la nostra piattaforma, e i risultati parlano chiaro: gestiamo decine di clienti con un team snello, e ogni nuovo cliente costa quasi zero in termini di setup. Se vuoi approfondire come funziona un SaaS white label end-to-end, dai un'occhiata alla nostra guida pillar sul SaaS white label. E se hai domande specifiche sul tuo progetto, scrivici: ti rispondiamo con i numeri alla mano, non con teoria.