Agenti AI con Trigger Dev: task, workflow e costi

Trigger Dev: quali componenti sostituisce?

Trigger.dev riunisce un esecutore di task, code, pianificazione, deployment e una dashboard delle esecuzioni. Si scrive una funzione asincrona, le si invia un payload e si lascia che un worker separato la esegua, mentre l'app restituisce una risposta all'utente. Può sostituire l'infrastruttura che altrimenti andrebbe costruita intorno ai job in background; non sostituisce il database dell'applicazione, le regole di business o il modello che prende le decisioni di un agente AI.

Verifica effettuata su documentazione pubblica, prezzi, changelog e repository GitHub l'11 novembre 2026. Questa valutazione si basa sulla documentazione: non sono stati eseguiti test con accesso a un account né benchmark delle prestazioni. La raccomandazione dipende da chi gestisce il runtime, dai confini del recupero dopo un errore, dalla facilità d'uso per gli operatori e dai limiti in produzione.

Il changelog del lancio di v4, datato 18 agosto 2025, ha introdotto warm start, waitpoint per approvazioni e callback, code con priorità, modifiche alla dashboard e hook del ciclo di vita. L'ultima release elencata al momento della verifica, v4.8.4 del 10 novembre 2026, aggiunge l'identità dei workload e la pubblicazione attendibile dei deployment. Queste funzioni consentono ai servizi e ai sistemi di deployment supportati di autenticarsi con token di identità di breve durata anziché con credenziali permanenti memorizzate.

Per chi fonda un prodotto, il cambiamento concreto è questo: «genera il report dopo il caricamento» può diventare un task in background gestito, anziché un endpoint web tenuto aperto fino al completamento del report. L'app deve comunque registrare a quale cliente appartiene ogni report e stabilire cosa succede se la generazione fallisce.

A chi conviene e chi dovrebbe scegliere altro?

Trigger.dev è adatto a un prodotto gestito da un team tecnico, in cui la logica in background deve vivere accanto al resto del codice TypeScript. Più l'esigenza si avvicina a «esegui questa funzione in modo affidabile, con le sue dipendenze», più la scelta è sensata.

Il confronto seguente mette a fuoco dove si definisce il workflow e di cosa ci si deve occupare direttamente. Sono scelte architetturali, non una classifica del fornitore con più funzionalità.

n8n: quando il workflow è in mano a un operatore

n8n ha più senso per chi si occupa delle operazioni commerciali e collega acquisizione dei contatti, arricchimento dei dati e follow-up. L'approccio visivo permette di esaminare il processo senza trasformare ogni modifica in un intervento sul codice applicativo. Supporta l'AI e l'automazione aziendale: dire «ci serve un agente» non basta quindi a escluderlo.

Il compromesso riguarda chi se ne occupa. Se la parte difficile è una logica applicativa personalizzata, con librerie e dipendenze di deployment, un task TypeScript può essere più semplice da mantenere rispetto a un flusso visivo che continua a crescere. Se invece la difficoltà è permettere a un operatore di modificare i passaggi aziendali, Trigger.dev lo rende dipendente dal team tecnico. Per questa decisione d'acquisto, c'è il più ampio confronto tra le alternative a n8n.

Inngest e Trigger Dev a confronto

Inngest è il confronto più diretto per gli sviluppatori che cercano funzioni durevoli. La documentazione attuale descrive il salvataggio dei risultati dei passaggi e la ripartenza dal passaggio fallito, con SDK TypeScript, Python e Go. Vale quindi la pena valutarlo quando l'applicazione si scompone naturalmente in passaggi con un nome o quando un team Python vuole scrivere i workflow in Python.

L'attrattiva di Trigger.dev sta nell'offrire il runtime dei task e le relative dipendenze insieme all'orchestrazione. Il modello a passaggi espliciti di Inngest rende visibile nel codice il confine entro cui avviene il recupero. Nessuna delle due soluzioni elimina la necessità di rendere sicura la ripetizione di una scrittura su un sistema esterno. La scelta dipende da come si vuole distribuire il workload e ragionare sui guasti, senza presumere che solo una delle due supporti attese o agenti.

Temporal: quando la scelta riguarda la piattaforma

Temporal merita di essere valutato quando un processo aziendale attraversa più servizi e il suo ciclo di vita conta più della rapidità con cui si mette in produzione una funzione in background. La sua documentazione copre SDK per più linguaggi e il deployment dell'applicazione accanto a un servizio Temporal gestito o in self-hosting.

Il costo, qui, è un impegno architetturale: gli sviluppatori si fanno carico dell'applicazione di workflow e della sua progettazione operativa. Per un piccolo prodotto TypeScript che vuole spostare la generazione dei report fuori dal percorso della richiesta, potrebbe essere un sistema più complesso del necessario. Per un team di piattaforma che standardizza processi aziendali di lunga durata, può essere proprio l'obiettivo.

Come scrivere, distribuire e ritentare un task in background

Trigger.dev sposta la parte lenta di una richiesta in un task osservabile separatamente. Prendiamo una funzione di importazione dei documenti: l'app accetta il caricamento, registra un'importazione, avvia l'elaborazione e restituisce il controllo al cliente. Estrazione e classificazione possono proseguire in background.

Quello che segue è l'esempio hello-world della documentazione sui task, senza commenti e con l'aggiunta di un export, per consentire il rilevamento e l'importazione del task:

import { task } from "@trigger.dev/sdk";

export const helloWorld = task({
  id: "hello-world",
  run: async (payload: { message: string }) => {
    console.log(payload.message);
  },
});

Il confine importante è il payload: deve contenere le informazioni necessarie per trovare ed elaborare l'importazione, lasciando la richiesta rivolta al cliente indipendente dal completamento del task.

La documentazione sui tentativi distingue tra la ripetizione di un task e quella di un blocco più piccolo con retry.onThrow o di una richiesta HTTP con retry.fetch. Un nuovo tentativo del task può ripetere l'intero task. Se l'elaborazione dell'importazione riesce ma una notifica successiva genera un errore, rieseguire tutto alla cieca può ripetere scritture già effettuate.

La regola di progettazione: ritentare gli errori transitori vicino all'operazione che fallisce e rendere le scritture idempotenti, cioè fare in modo che ripetere la stessa operazione non produca un altro effetto sul processo aziendale. Una piattaforma di task fornisce i meccanismi di recupero; i vincoli del database e le API esterne scelte determinano se un nuovo tentativo duplica una fattura, un'email o un record.

Trigger Dev e Python

Trigger.dev può eseguire script Python all'interno di task TypeScript tramite la sua estensione di build per Python. È utile quando il prodotto web è in TypeScript ma il parser dei documenti è in Python. È un ponte tra runtime, con un'esperienza di sviluppo diversa da quella di un SDK di workflow nativo Python.

C'è un dettaglio di deployment importante: l'installazione tramite requirementsFile dell'estensione avviene solo in produzione; le dipendenze di sviluppo vanno installate in locale. Un parser che funziona su un portatile non dimostra che le dipendenze nel deployment siano corrette.

Agenti AI: come attendere un'approvazione o una callback

I waitpoint di Trigger.dev permettono a un workflow di fermarsi finché una persona o un servizio esterno non fornisce il risultato mancante. Per un agente che gestisce rimborsi, significa separare «proponi un rimborso» da «emetti il rimborso». Il task può preparare la proposta, attendere l'approvazione e continuare solo dopo averne ricevuto l'esito.

La guida ai waitpoint del produttore usa wait.createToken, wait.forToken e wait.completeToken per questo passaggio di controllo. Mostra anche URL di callback per i servizi esterni. Spetta comunque all'applicazione decidere chi può approvare e cosa autorizza un'approvazione.

Tempo e costi hanno controlli separati. La documentazione attuale sulle attese indica che le attese temporizzate superiori a 5 secondi non vengono conteggiate nell'utilizzo di calcolo. Un'attesa temporizzata, però, libera il proprio slot di concorrenza solo dopo che viene creata un'istantanea della macchina e la macchina viene spenta, a 60 secondi dall'inizio dell'attesa. Un'attesa più breve può quindi non consumare calcolo e continuare comunque a occupare uno slot.

Questa distinzione conta quando molte esecuzioni di agenti si fermano contemporaneamente per brevi periodi. Un task in attesa non libera automaticamente capacità per un altro task. Il dimensionamento della concorrenza deve considerare sia il lavoro in esecuzione sia le attese brevi, non soltanto le operazioni che impegnano molto la CPU.

Per il livello di ragionamento dell'agente, c'è il confronto dedicato ai framework per agenti AI. Il runtime di Trigger.dev può far proseguire il lavoro, ma sono ancora prompt, strumenti e regole di approvazione a determinare cosa fa l'agente.

Pianificare le sincronizzazioni senza dare per scontati gli orari

Trigger.dev supporta le attività ricorrenti tramite schedules.task, con pianificazioni definite nel codice oppure associate tramite dashboard e SDK. La sincronizzazione dei dati dei clienti è un buon esempio: la pianificazione avvia l'elaborazione, il task svolge il lavoro e la cronologia delle esecuzioni mostra se è stato completato.

La documentazione sui task pianificati contiene un limite più importante della parola «cron»: le nuove pianificazioni prevedono per impostazione predefinita una finestra di distribuzione degli avvii di 60 minuti. Un job giornaliero non deve necessariamente partire all'ora nominale esatta del cron. Dove il piano lo consente, window: "0m" disattiva questa distribuzione.

Le nuove pianificazioni create su Free non possono avere una frequenza superiore a quella oraria e devono avere una finestra minima di 60 minuti. Fanno eccezione le pianificazioni esistenti che conservano le condizioni precedenti. Il passaggio a un piano superiore non modifica subito una pianificazione soggetta a questi limiti: bisogna salvarla di nuovo o ridistribuirla mentre è attivo il piano a pagamento.

Per un riepilogo giornaliero, distribuire gli avvii può essere accettabile. Se si promette al cliente un report a un'ora precisa, l'impostazione predefinita è un presupposto sbagliato. Prima di sostituire un cron job esistente, frequenza, fuso orario e ritardo consentito vanno trattati come requisiti distinti.

Mostrare l'avanzamento agli utenti e gli errori agli sviluppatori

Trigger.dev Realtime aiuta a trasformare un job in background da un indicatore di caricamento senza spiegazioni a un workflow visibile. In una schermata di importazione, si possono mostrare stato dell'esecuzione e metadati di avanzamento; per il testo generato, si può trasmettere l'output in streaming mentre il task lavora. Sono percorsi dei dati diversi.

La panoramica di Realtime distingue useRealtimeRun, che segue stato e metadati, da useRealtimeStream, che legge i dati emessi attraverso stream definiti. Tutti gli hook e le funzioni Realtime richiedono autenticazione. Un cliente deve poter vedere l'avanzamento della propria importazione, senza ottenere accesso alle esecuzioni degli altri.

Per gli sviluppatori, dashboard e log dei task rispondono a una domanda diversa: dove si è fermata l'esecuzione? I messaggi di avanzamento rivolti agli utenti devono essere chiari e utili, senza riportare nell'interfaccia del prodotto i dettagli degli errori interni.

Trigger Dev e MCP

Il server MCP di Trigger.dev offre a un assistente di programmazione strumenti per cercare nella documentazione, inizializzare progetti, avviare task, eseguire deployment ed esaminare le esecuzioni. MCP, Model Context Protocol, è l'interfaccia attraverso cui l'assistente richiama questi strumenti.

Serve ad accorciare il ciclo di modifica e debug, senza sostituire la verifica del comportamento del task. Il fatto che un assistente possa distribuire un workflow non dice nulla sulla sicurezza di ripeterne le azioni esterne durante un nuovo tentativo.

Trigger Dev: prezzi e limiti dei piani in produzione

Trigger.dev Hobby è un punto di partenza sensato per una piccola app in produzione il cui carico rientra nei limiti del piano: $10/mese con $10 di crediti di utilizzo inclusi, 50 esecuzioni simultanee e conservazione dei log per 7 giorni. Free costa $0/mese con $5 di crediti, 20 esecuzioni simultanee e log per 1 giorno; una volta esauriti i crediti, occorre passare a un piano superiore per continuare a eseguire i task. Sono i valori della pagina prezzi, verificati l'11 novembre 2026.

Il limite che spinge verso Hobby non è solo il consumo. Le restrizioni di Free sulle pianificazioni possono renderlo inadatto prima che il calcolo diventi costoso. Le connessioni Realtime sono un altro confine: Free include 10 connessioni simultanee, Hobby 150. Pro costa $50/mese con $50 di crediti, include 200 esecuzioni simultanee e log per 30 giorni: diventa rilevante quando la concorrenza o la cronologia necessaria al debug richiedono il passaggio di piano.

Per una stima concreta, ipotizziamo 10,000 job completati con successo al mese, ciascuno in esecuzione per 60 secondi su Small 1x, senza nuovi tentativi. A $0.0000338 al secondo più $0.000025 per invocazione, l'utilizzo è:

10,000 × ((60 × $0.0000338) + $0.000025) = $20.53.

Su Hobby, l'abbonamento da $10 include $10 di questo utilizzo, lasciando $10.53 extra: $20.53 di costo totale della piattaforma, ovvero $0.002053 per job completato con queste ipotesi. È un calcolo ricavato dalle tariffe pubblicate, non un workload misurato. Chiamate alle API dei modelli, archiviazione e altri servizi restano costi separati; i nuovi tentativi aggiungono lavoro da eseguire.

Il piano va scelto per la concorrenza, la pianificazione e la cronologia necessarie. Stima l'utilizzo in base al tempo di esecuzione e aggiungi un margine per errori e nuovi tentativi, senza considerare una stima di sole esecuzioni riuscite come un tetto di spesa.

I limiti che possono cambiare la scelta

Trigger.dev elimina una parte consistente dell'infrastruttura dei worker, ma le responsabilità che restano sono precise e importanti.

Il self-hosting non garantisce le stesse funzioni di Cloud

Il repository di Trigger.dev indica la licenza Apache-2.0 e rimanda alle guide di deployment con Docker Compose e Kubernetes. Il repository GitHub è la fonte da consultare per codice e licenza.

Il confronto sul self-hosting attualmente elenca warm start, autoscaling, checkpoint e assistenza dedicata come funzionalità riservate a Cloud. Con il self-hosting ricadono inoltre su di te la webapp, Redis, Postgres, i supervisori dei worker, gli aggiornamenti e l'affidabilità.

Per i workflow che richiedono molte approvazioni, il comportamento dei checkpoint è un motivo concreto per preferire Cloud. L'ultima release cita anche la pulizia degli snapshot delle microVM in self-hosting: il confronto documentato e i dettagli della release non dimostrano quindi una semplice parità. Verifica il comportamento supportato dalla configurazione che intendi usare e includi nella decisione la gestione dell'infrastruttura.

Nessun timeout di piattaforma non significa nessuna politica di gestione degli errori

Trigger.dev permette alle esecuzioni di proseguire senza un limite fisso di durata imposto dalla piattaforma, ma la configurazione può comunque imporre maxDuration, un limite al tempo di calcolo. La documentazione sulla durata supporta override e timeout.None per l'esecuzione a tempo indefinito.

Indica inoltre che cleanup, onSuccess e onFailure non vengono richiamati quando si supera la durata massima. È un'insidia se l'applicazione si aspetta che un hook di errore liberi una prenotazione o contrassegni un'importazione come fallita. Serve un modo per riconciliare i record applicativi rimasti incompleti, senza affidare l'intero recupero a un solo hook.

Un nuovo tentativo non può decidere se un'azione aziendale è sicura

Trigger.dev non può dedurre se un rimborso, una sequenza di email o un'importazione di dati completati solo in parte debbano essere ripetuti. Anche quando il recupero dell'esecuzione funziona, il risultato aziendale può essere sbagliato se ripetere un'azione esterna produce un ulteriore effetto.

Prima di adottarlo, individua la scrittura che non deve avvenire due volte e il record che ne dimostra l'avvenuta esecuzione. Se il workflow non ha un confine di questo tipo, cambiare piattaforma di task non ne corregge il funzionamento.

Le credenziali su Cloud richiedono una scelta consapevole di fiducia

Trigger.dev ha segnalato un incidente di sicurezza il 1 novembre 2026, relativo ad accessi non autorizzati alle variabili d'ambiente tramite chiavi API root dei clienti compromesse in alcuni ambienti. Il rapporto sull'incidente indica che i clienti coinvolti sono stati avvisati e le chiavi interessate revocate; i deployment in self-hosting non sono stati coinvolti.

Per un nuovo acquirente, questo rende l'ambito delle credenziali e gli interventi correttivi del fornitore parte della valutazione. Non dimostra che tutti i clienti siano stati coinvolti, né che un'installazione in self-hosting sarebbe automaticamente più sicura. Esamina quali credenziali dovrebbe detenere il worker e se le opzioni di identità supportate sono adatte ai tuoi servizi.

Il verdetto: sceglierlo quando si vuole un worker gestito

Tra le opzioni esaminate, Trigger.dev è particolarmente adatto a un team di prodotto TypeScript che vuole ricevere insieme codice in background, infrastruttura di esecuzione e dashboard delle esecuzioni. Parti da un workload problematico, come un'importazione o un generatore di report, e definisci il confine dei nuovi tentativi prima di migrare il resto.

Scegli n8n quando un operatore deve gestire e modificare il flusso di integrazione. Valuta Inngest per il modello a passaggi espliciti o per gli SDK di workflow nativi Python/Go. Scegli Temporal quando un team di piattaforma vuole deliberatamente farsi carico dell'architettura di processi aziendali durevoli tra servizi.

Se l'esigenza consiste soprattutto nello spostare informazioni tra applicazioni aziendali, la guida alle alternative a Zapier è un punto di partenza più adatto rispetto all'adozione di un'infrastruttura per task.

Usa la checklist per l'audit dei workflow aziendali con AI per mappare il workload, il responsabile, il percorso in caso di errore e il passaggio di consegne prima di spostarlo.

Domande frequenti