Cos'è Trigger.dev
Trigger.dev è una piattaforma open-source per la gestione di background jobs e workflow in applicazioni TypeScript. Nata con l'obiettivo di semplificare l'esecuzione di task asincroni complessi, la versione 3 rappresenta un riprogettazione significativa rispetto alle release precedenti. Il progetto è rilasciato sotto licenza Apache 2.0 e il codice sorgente è disponibile su GitHub all'indirizzo github.com/triggerdotdev/trigger.dev.
La caratteristica distintiva di Trigger.dev v3 è la sua natura code-first: i job non vengono definiti tramite interfaccia grafica o configurazioni esterne, ma direttamente nel codice TypeScript dell'applicazione. Questo approccio consente di versionare i workflow con Git, di sfruttare l'autocompletamento dell'editor e di mantenere la logica di business in un unico posto. La piattaforma supporta nativamente framework come Next.js, Remix, Astro e applicazioni Node.js generiche.
A cosa serve
Trigger.dev v3 serve a chi ha bisogno di eseguire operazioni in background senza bloccare il flusso principale dell'applicazione. Casi d'uso tipici includono l'invio di email transazionali o newsletter in sequenza, l'elaborazione di file, la generazione di report, la sincronizzazione con API esterne, l'ingestione di dati in batch e l'esecuzione di workflow multi-step che possono durare minuti o ore.
Per founder, PMI e agenzie che sviluppano SaaS in TypeScript, la piattaforma risolve un problema ricorrente: la mancanza di una coda di lavoro robusta e gestibile senza dover introdurre componenti infrastrutturali aggiuntivi come Redis, RabbitMQ o servizi cloud dedicati. Con Trigger.dev v3 è possibile eseguire task in container isolati, con retry automatici, rate limiting, scheduling e una dashboard di monitoraggio, utilizzando solo PostgreSQL come datastore.
Come funziona
L'architettura di Trigger.dev v3 si compone di tre elementi principali: l'SDK che si integra nel codice dell'applicazione, il server Trigger.dev che gestisce la coda e l'esecuzione, e il database PostgreSQL che conserva lo stato dei job.
Lo sviluppatore definisce i task come funzioni TypeScript annotate con l'SDK. Ogni task può specificare opzioni come il numero di tentativi in caso di errore, i limiti di concorrenza, i timeout e le dipendenze da altri task. Una volta definito, il task viene deployato insieme al resto dell'applicazione. Quando l'applicazione invoca un task, il server Trigger.dev lo accoda e lo esegue in un container isolato, garantendo che un job lungo o fallito non influenzi gli altri.
Il modello di esecuzione supporta task single-step e multi-step. I task multi-step possono essere sospesi e ripresi, il che li rende adatti a workflow che prevedono attese esterne, come la risposta di un'API di terze parti o l'approvazione manuale. La persistenza dello stato avviene su PostgreSQL, eliminando la necessità di mantenere uno stato in memoria o di gestire manualmente il checkpointing.
La dashboard web permette di monitorare l'esecuzione dei job in tempo reale, ispezionare i log, rilanciare task falliti e analizzare le metriche di utilizzo. Per chi preferisce mantenere il controllo completo, Trigger.dev v3 può essere self-hostato tramite Docker Compose o Kubernetes, oppure utilizzato in versione cloud gestita.
Perché conta
Nel panorama dello sviluppo SaaS, la gestione dei background jobs è spesso un punto di fragilità. Molte applicazioni iniziano con semplici chiamate asincrone o setTimeout, ma questi approcci non reggono a errori, riavvii del server o carichi crescenti. L'adozione di un job queue professionale richiede tradizionalmente l'integrazione di più componenti: un broker di messaggi, un worker separato, un sistema di retry, un registry di task e strumenti di osservabilità.
Trigger.dev v3 riduce questa complessità portando tutto in un'unica piattaforma coerente con lo stack TypeScript. Per le realtà italiane che lavorano con Next.js, Drizzle o Prisma, PostgreSQL e TypeScript, questo significa poter aggiungere capacità di background processing senza cambiare linguaggio, senza aggiungere servizi esterni e senza frammentare il codice.
Un altro aspetto rilevante è il costo operativo. La possibilità di self-hostare su propri server o VPS consente di controllare le spesse, un fattore importante per startup e agenzie che devono ottimizzare il budget. Al contempo, il modello di esecuzione in container isolati offre scalabilità orizzontale: è possibile aumentare le risorse dedicate ai worker in base al carico.
Infine, Trigger.dev v3 si colloca in un mercato in crescita di piattaforme per workflow e agenti AI. La sua capacità di gestire task lunghi e duraturi lo rende adatto anche a pipeline di intelligenza artificiale, come l'ingestione di documenti, la generazione batch di contenuti o l'esecuzione di catene di chiamate a modelli LLM.
Installazione e utilizzo
L'installazione di Trigger.dev v3 in un progetto Next.js avviene tramite CLI. Dopo aver inizializzato il framework, lo sviluppatore crea un file di definizione dei task. Ecco un esempio concettale:
import { task } from '@trigger.dev/sdk/v3';
export const sendWelcomeEmail = task({
id: 'send-welcome-email',
retry: { maxAttempts: 3 },
run: async (payload: { email: string; name: string }) => {
// logica di invio email
console.log(`Inviata email a ${payload.email}`);
},
});
Per invocare il task dall'applicazione:
import { sendWelcomeEmail } from './trigger/send-welcome-email';
await sendWelcomeEmail.trigger({ email: 'mario@esempio.it', name: 'Mario' });
Il codice del task risiede nello stesso repository, ma viene eseguito in background dal server Trigger.dev. Questa separazione permette all'applicazione principale di rispondere immediatamente all'utente, mentre il task viene processato in modo affidabile.
Confronto e adozione
Rispetto a soluzioni come BullMQ, Inngest o AWS Step Functions, Trigger.dev v3 si distingue per l'integrazione nativa con TypeScript e per il fatto di non richiedere Redis. BullMQ è potente e completamente self-hosted, ma richiede Redis e una configurazione separata dei worker. Inngest offre un'esperienza simile con workflow duraturi, ma introduce un servizio esterno e un proprio modello di deployment. AWS Step Functions è scalabile, ma vincolato all'ecosistema Amazon e più orientato a architetture enterprise complesse.
Trigger.dev v3 rappresenta una via di mezzo efficace: abbastanza semplice da essere adottata da un singolo sviluppatore o da una piccola squadra, ma sufficientemente robusta per applicazioni in produzione. La licenza Apache 2.0 garantisce libertà di uso, modifica e distribuzione, anche in contesti commerciali.
Dove trovarlo
Trigger.dev v3 è disponibile su GitHub all'indirizzo https://github.com/triggerdotdev/trigger.dev. La documentazione ufficiale è consultabile su https://trigger.dev/docs, dove si trovano guide per l'installazione, la configurazione, il self-hosting e l'integrazione con i principali framework TypeScript. La community è attiva su GitHub Discussions e Discord, e il progetto riceve aggiornamenti regolari che ne estendono le capacità di workflow duraturi e integrazione con agenti AI.