1~
2Wiekszosc aplikacji produkcyjnych potrzebuje pracy, ktora nie pasuje do cyklu zadanie/odpowiedz: wysylanie e-maili, przetwarzanie uploadow, uruchamianie pipeline'ow AI, synchronizacja danych zewnetrznych, generowanie raportow. Tradycyjna odpowiedz to kolejka (Redis, SQS, RabbitMQ), flota workerow, harmonogram i kruchy stos kodu spawajacego, ktory rozpada sie przy kazdym deployu.
3~
4[Trigger.dev](https://trigger.dev) skraca ten stack do jednego SDK TypeScript. Piszesz funkcje, wywolujesz je z dowolnego miejsca i platforma zajmuje sie kolejkowaniem, ponowieniami, obserwowalnoscia, harmonogramowaniem i trwalym wykonywaniem. Tasks dzialaja tak dlugo, jak potrzeba - zaden 10-sekundowy timeout serverless, zaden zgubiony przy redeployu.
5~
6## Dlaczego Trigger.dev
7~
8Zmiana w 2026 to trwale wykonywanie. Przeplywy musza przetrwac restarty, awarie, deploye i rate limity. Musza tez transmitowac postep do UI w czasie rzeczywistym i zatrzymywac sie na input czlowieka. Trigger.dev zostal przebudowany wokol tych wymagan w wersji 3 i nadal rozszerza swoja powierzchnie infrastruktury AI.
9~
10```mermaid
11graph LR
12    App[Twoja App] -->|trigger| API[API Trigger.dev]
13    API --> Queue[Trwala Queue]
14    Queue --> Worker[Container Worker]
15    Worker -->|run task| Task[Twoj kod Task]
16    Task -->|metadata| Realtime[Stream Realtime]
17    Realtime --> UI[React UI]
18    Worker --> Storage[Store stanu Run]
19```
20~
21Model jest prosty: definiujesz tasks jako exports, SDK je odbiera, platforma planuje i uruchamia je w izolowanych kontenerach, a stan run jest przechowywany, abys mogl wznawiac, ponawiac i obserwowac.
22~
23## Pierwsze kroki
24~
25### Inicjalizuj projekt
26~
27```bash
28npx trigger.dev@latest login
29npx trigger.dev@latest init
30```
31~
32To tworzy plik `trigger.config.ts` i katalog `trigger/` z przykladowymi tasks. Plik konfiguracyjny jest zrodlem prawdy dla twojego projektu: ktore katalogi zawieraja tasks, ustawienia builda, lifecycle hooks i opcje runtime.
33~
34```typescript
35// trigger.config.ts
36import { defineConfig } from "@trigger.dev/sdk";
37~
38export default defineConfig({
39  project: "proj_abc123",
40  runtime: "node",
41  logLevel: "log",
42  maxDuration: 3600,
43  retries: {
44    enabledInDev: true,
45    default: {
46      maxAttempts: 3,
47      factor: 2,
48      minTimeoutInMs: 1000,
49      maxTimeoutInMs: 30_000,
50    },
51  },
52  dirs: ["./trigger"],
53});
54```
55~
56### Uruchamiaj tasks lokalnie
57~
58```bash
59npx trigger.dev@latest dev
60```
61~
62Server dev laczy sie z chmura, rejestruje twoje tasks i transmituje runs przez twoj lokalny kod. Ustawiasz breakpointy w edytorze i trafiasz w nie na prawdziwych triggerach - ta sama petla, ktorej uzywalbys w jakimkolwiek normalnym projekcie Node.js.
63~
64## Definiowanie Task
65~
66Task to obiekt eksportowany z unikatowym `id` i funkcja `run`. SDK inspekcjonuje exporty w `dirs` i automatycznie je rejestruje.
67~
68```typescript
69// trigger/send-welcome-email.ts
70import { task } from "@trigger.dev/sdk";
71import { Resend } from "resend";
72~
73const resend = new Resend(process.env.RESEND_API_KEY);
74~
75export const sendWelcomeEmail = task({
76  id: "send-welcome-email",
77  retry: {
78    maxAttempts: 5,
79    factor: 1.8,
80    minTimeoutInMs: 500,
81    maxTimeoutInMs: 30_000,
82  },
83  run: async (payload: { email: string; name: string }) => {
84    const { data, error } = await resend.emails.send({
85      from: "hello@spinny.dev",
86      to: payload.email,
87      subject: `Welcome, ${payload.name}`,
88      html: `<p>Glad you are here, ${payload.name}.</p>`,
89    });
90~
91    if (error) throw error;
92    return { messageId: data?.id };
93  },
94});
95```
96~
97Trzy rzeczy do zauwazenia:
98~
991. **Brak timeoutu w ciele run.** Platforma zarzadza czasem wykonania przez `maxDuration` w configu, nie w runtime.
1002. **Throws to retries.** SDK lapie wyjatki i ponawia z exponential backoff zgodnie z polityka `retry`.
1013. **Wartosc zwracana jest przechowywana.** Inne tasks i twoj frontend moga czytac `run.output` skadkolwiek.
102~
103## Triggerowanie Tasks
104~
105Wywolujesz task z backendu, route'ow API lub innego task'a.
106~
107```typescript
108import { sendWelcomeEmail } from "@/trigger/send-welcome-email";
109~
110const handle = await sendWelcomeEmail.trigger(
111  { email: "user@example.com", name: "Alex" },
112  {
113    idempotencyKey: `welcome-${userId}`,
114    concurrencyKey: `tenant-${tenantId}`,
115    queue: { name: "emails", concurrencyLimit: 50 },
116    delay: "30s",
117    ttl: "10m",
118  }
119);
120~
121console.log(handle.id); // run_xyz - uzyj do sledzenia lub wyswietlania postepu
122```
123~
124Opcje odblokowuja wiele zachowania w jednym wywolaniu:
125~
126- **`idempotencyKey`** - jesli run z ta sama kluczem juz istnieje, SDK zwraca istniejacy uchwyt zamiast duplikowac prace.
127- **`concurrencyKey`** - serializuje runs udostepniajace klucz, abys nie przekroczyl rate limitu na tenanta.
128- **`queue.concurrencyLimit`** - globalna granica dla kolejki we wszystkich kluczach.
129- **`delay`** - planuje run na przyszly czas.
130- **`ttl`** - jesli run nie rozpoczal sie do tego czasu, automatycznie wygasa.
131~
132### Batch trigger
133~
134Dla obciazen fan-out, `batchTrigger` przyjmuje do 500 elementow na wywolanie i tworzy jeden run na element.
135~
136```typescript
137await sendWelcomeEmail.batchTrigger(
138  newUsers.map((u) => ({
139    payload: { email: u.email, name: u.name },
140    options: { idempotencyKey: `welcome-${u.id}` },
141  }))
142);
143```
144~
145## Tasks zaplanowane
146~
147Cron joby staja sie deklaracjami pierwszej klasy. Sam harmonogram to oddzielny obiekt, ktory mozesz przylaczyc do task'a wiele razy.
148~
149```typescript
150// trigger/daily-digest.ts
151import { schedules } from "@trigger.dev/sdk";
152~
153export const dailyDigest = schedules.task({
154  id: "daily-digest",
155  cron: "0 9 * * *",
156  run: async (payload) => {
157    console.log("Scheduled at:", payload.timestamp);
158    console.log("Last run:", payload.lastTimestamp);
159    console.log("Timezone:", payload.timezone);
160    console.log("Next 5 runs:", payload.upcoming);
161~
162    await sendDigestForDate(payload.timestamp);
163  },
164});
165```
166~
167Dla harmonogramow na tenanta - powiedzmy, jeden cron na klienta - tworzysz je dynamicznie przez management API.
168~
169```typescript
170import { schedules } from "@trigger.dev/sdk";
171~
172await schedules.create({
173  task: "daily-digest",
174  cron: "0 9 * * *",
175  timezone: "America/New_York",
176  externalId: `customer_${customerId}`,
177  deduplicationKey: `digest-${customerId}`,
178});
179```
180~
181`deduplicationKey` czyni wywolanie idempotentnym: ponowne uruchomienie tego samego kodu w czasie deployu nie nawarstwia zduplikowanych harmonogramow.
182~
183## Kolejki, Wspolbieznosc i Idempotentnosc
184~
185Trzy primitywy pokrywaja wiekszosc potrzeb rate-limitingu i porzadkowania.
186~
187```mermaid
188graph TB
189    Trigger[trigger payload] --> IK{idempotencyKey<br/>widziany?}
190    IK -->|tak| Reuse[Zwroc istniejacy run]
191    IK -->|nie| CK[bucket concurrencyKey]
192    CK --> Q[Kolejka z<br/>concurrencyLimit]
193    Q -->|slot dostepny| Run[Uruchom task]
194    Q -->|sloty pelne| Wait[Czekaj w kolejce]
195```
196~
197Powszechny wzorzec: jedna kolejka na tenanta z mala wspolbieznoscia na klucz, aby uszanowac rate limit dostawcy, plus klucz idempotentnosci, aby retries byly bezpieczne.
198~
199```typescript
200await syncShopifyOrders.trigger(
201  { shopId },
202  {
203    queue: { name: `shopify-${shopId}`, concurrencyLimit: 2 },
204    concurrencyKey: shopId,
205    idempotencyKey: `sync-${shopId}-${Date.now() / 60_000 | 0}`,
206  }
207);
208```
209~
210## Oczekiwania i praca dlugoterminowa
211~
212Tasks moga sie zatrzymac bez utrzymywania polaczenia czy spalania compute. Platforma utrzymuje stan i wznawia funkcje, gdy oczekiwanie sie konczy.
213~
214```typescript
215import { wait } from "@trigger.dev/sdk";
216~
217export const onboarding = task({
218  id: "onboarding",
219  run: async (payload: { userId: string }) => {
220    await sendWelcomeEmail.triggerAndWait({ userId: payload.userId });
221    await wait.for({ days: 1 });
222    await sendTipsEmail.trigger({ userId: payload.userId });
223    await wait.until({ date: oneWeekFromSignup(payload.userId) });
224    await sendUpgradeOffer.trigger({ userId: payload.userId });
225  },
226});
227```
228~
229`triggerAndWait` to zabojcza funkcja: triggeruje task dziecka i zawiesza rodzica az dziecko sie zakonczy. Komponujesz tasks jak funkcje async, ale orkiestracja dziala trwale przez dni lub tygodnie.
230~
231### Human-in-the-loop z `wait.forToken`
232~
233Dla przeplywow zatwierdzania i bramek AI, `wait.forToken` zatrzymuje sie az twoja aplikacja oddzwoni z wynikiem.
234~
235```typescript
236import { task, wait } from "@trigger.dev/sdk";
237~
238export const publishPost = task({
239  id: "publish-post",
240  run: async (payload: { draftId: string }) => {
241    const draft = await generateAIContent(payload.draftId);
242~
243    const token = await wait.createToken({ timeout: "7d" });
244    await notifyEditor({ draftId: draft.id, token: token.id });
245~
246    const decision = await wait.forToken<{ approved: boolean; notes?: string }>(
247      token.id
248    );
249~
250    if (decision.approved) {
251      return await publish(draft);
252    }
253    return await applyFeedback(draft, decision.notes);
254  },
255});
256```
257~
258Edytor otwiera UI, przeglada draft, klika Zatwierdz i twoj backend kompletuje token. Task wznawia od miejsca, w ktorym sie zatrzymal - nawet jesli minely godziny lub dni.
259~
260## Lifecycle Hooks
261~
262Mozesz przylaczyc `init`, `onStart`, `onSuccess` i `onFailure` do task'a lub globalnie w `trigger.config.ts`. Uzywaj ich do tracingu, error reportingu i wspolnego setupu.
263~
264```typescript
265// trigger.config.ts
266export default defineConfig({
267  // ...
268  init: async () => {
269    Sentry.init({ dsn: process.env.SENTRY_DSN });
270  },
271  onFailure: async ({ error, ctx }) => {
272    Sentry.captureException(error, {
273      tags: { taskId: ctx.task.id, runId: ctx.run.id },
274    });
275  },
276});
277```
278~
279`init` dziala raz na worker container przy bootcie, nie na run, wiec jest to dobre miejsce do skonfigurowania klientow i pul.
280~
281## Realtime w Frontendzie
282~
283Trigger.dev publikuje zmiany stanu run - status, metadata, output - przez streaming API. Hooki React subskrybuja ten strumien i automatycznie re-renderuja.
284~
285```typescript
286// trigger/process-video.ts
287import { task, metadata } from "@trigger.dev/sdk";
288~
289export const processVideo = task({
290  id: "process-video",
291  run: async (payload: { videoId: string }) => {
292    metadata.set("stage", "transcoding");
293    await transcode(payload.videoId);
294~
295    metadata.set("stage", "thumbnails");
296    await generateThumbnails(payload.videoId);
297~
298    metadata.set("stage", "uploading");
299    const url = await uploadToCDN(payload.videoId);
300~
301    return { url };
302  },
303});
304```
305~
306```tsx
307// components/VideoStatus.tsx
308"use client";
309import { useRealtimeRun } from "@trigger.dev/react-hooks";
310import type { processVideo } from "@/trigger/process-video";
311~
312export function VideoStatus({
313  runId,
314  publicAccessToken,
315}: {
316  runId: string;
317  publicAccessToken: string;
318}) {
319  const { run, error } = useRealtimeRun<typeof processVideo>(runId, {
320    accessToken: publicAccessToken,
321  });
322~
323  if (error) return <p>Error: {error.message}</p>;
324  if (!run) return <p>Loading...</p>;
325~
326  return (
327    <div>
328      <p>Status: {run.status}</p>
329      <p>Stage: {String(run.metadata?.stage ?? "queued")}</p>
330      {run.output?.url && <video src={run.output.url} controls />}
331    </div>
332  );
333}
334```
335~
336Generujesz publiczny access token po stronie serwera, scoped do konkretnego run, i wysylasz do klienta. Hook obsluguje auth, ponowne polaczenie i przyrostowe aktualizacje.
337~
338Dla trigger-and-subscribe w jednym kroku:
339~
340```tsx
341import { useRealtimeTaskTrigger } from "@trigger.dev/react-hooks";
342~
343const { submit, run, isLoading } = useRealtimeTaskTrigger<typeof processVideo>(
344  "process-video",
345  { accessToken: publicAccessToken }
346);
347~
348<button onClick={() => submit({ videoId })} disabled={isLoading}>
349  Process video
350</button>;
351```
352~
353## Agenci AI i Streaming
354~
355Trigger.dev stal sie popularnym runtime dla agentow AI poniewaz te same primitywy - trwale wykonywanie, retries, oczekiwania, real-time metadata, human-in-the-loop - to dokladnie to, czego potrzebuja agenci. Strumieniujesz tokeny od dostawcy modelu do `metadata` podczas gdy run sie dzieje, frontend renderuje je na zywo, a run przezywa dlugotrwale tool calls bez spalania serverless timeoutu.
356~
357```typescript
358import { task, metadata } from "@trigger.dev/sdk";
359import { streamText } from "ai";
360import { anthropic } from "@ai-sdk/anthropic";
361~
362export const researchAgent = task({
363  id: "research-agent",
364  maxDuration: 1800,
365  run: async (payload: { question: string }) => {
366    const result = streamText({
367      model: anthropic("claude-opus-4-7"),
368      system: "You are a research assistant. Use the web.",
369      prompt: payload.question,
370      tools: { webSearch },
371    });
372~
373    let fullText = "";
374    for await (const chunk of result.textStream) {
375      fullText += chunk;
376      metadata.set("partial", fullText);
377    }
378~
379    return { answer: fullText, usage: await result.usage };
380  },
381});
382```
383~
384Frontend uzywa `useRealtimeRun` i czyta `run.metadata.partial`, aby renderowac odpowiedz strumieniowa, w ten sam sposob, w jaki renderowalbys chat completion - z wyjatkiem tego, ze ta przezywa pelny reload strony.
385~
386## Deploying
387~
388Deploye kompiluja twoje tasks do bundla z wersja, buduja kontener i atomowo zamieniaja ruch. Stare runs w locie nadal uzywaja poprzedniej wersji.
389~
390```bash
391npx trigger.dev@latest deploy --env prod
392```
393~
394W CI zwykle podlaczasz to do tego samego workflow, ktory wysyla twoja aplikacje:
395~
396```yaml
397# .github/workflows/deploy.yml
398- name: Deploy Trigger.dev
399  env:
400    TRIGGER_ACCESS_TOKEN: ${{ secrets.TRIGGER_ACCESS_TOKEN }}
401  run: npx trigger.dev@latest deploy --env prod
402```
403~
404Dla srodowisk preview, przekaz `--env preview --branch ${{ github.head_ref }}` i Trigger.dev tworzy izolowane srodowisko na branch, odzwierciedlajac sposob, w jaki Vercel obsluguje preview deploymenty.
405~
406## Self-Hosting vs Cloud
407~
408Trigger.dev jest open source na licencji Apache 2.0. Mozesz self-hostowac na dowolnej platformie kontenerowej (Docker Compose, Kubernetes, Fly.io) lub uzywac zarzadzanej chmury w trigger.dev.
409~
410| Aspekt | Cloud | Self-hosted |
411|--------|-------|-------------|
412| **Setup** | Rejestracja, uruchom `init` | Uruchom docker-compose lub Helm chart |
413| **Skalowanie** | Automatyczne | Twoja odpowiedzialnosc |
414| **Pricing** | Za run + za compute | Tylko koszt infrastruktury |
415| **Compliance** | SOC 2 | Co dostarcza twoje srodowisko |
416| **Najlepsze dla** | Wiekszosc zespolow | Surowa rezydencja danych, infra niestandardowa |
417~
418SDK i CLI sa identyczne miedzy trybami - zmieniasz flage profilu i wskazujesz na wlasna instancje.
419~
420## Best Practices
421~
422### 1. Trzymaj payloady male i serializowalne
423~
424Przekazuj IDki i referencje, nie pelne obiekty. Pobieraj dane wewnatrz task'a. Utrzymuje to kolejke mala, payloady tanio loggable i pozwala zmieniac zrodlo danych bez ponownego triggerowania.
425~
426### 2. Klucze idempotentnosci na kazdym wywolaniu zewnetrznym
427~
428Polacz `idempotencyKey` na triggerze task'a z kluczami idempotentnosci na API dostawcow (Stripe, OpenAI, itp.). Retries beda bezpieczne end-to-end.
429~
430### 3. Uzywaj `triggerAndWait` do orkiestracji, a nie `Promise.all` triggerow
431~
432Rodzic, ktory wywoluje `triggerAndWait`, trwale komponuje task dzieci. Rodzic, ktory triggeruje i resolvuje natychmiast, traci obserwowalnosc lancucha.
433~
434### 4. Taguj runs
435~
436Dodaj `tags` do triggerow (`tags: ["user:123", "feature:onboarding"]`), abys mogl filtrowac dashboard i management API wedlug wymiarow biznesowych.
437~
438### 5. Trzymaj `init` idempotentnym
439~
440Dziala przy kazdym cold starcie. Unikaj migracji lub jednorazowych skutkow ubocznych tam.
441~
442## Wniosek
443~
444Trigger.dev usuwa kategorie pracy, ktore wczesniej wymagaly zbudowania systemu jobow od zera. Piszesz async TypeScript, wywolujesz go skadkolwiek i platforma daje ci trwale wykonywanie, harmonogramowanie, kolejki, retries, aktualizacje real-time i wzorce human-in-the-loop out of the box.
445~
446Ta sama powierzchnia, ktora napedza nocnego crona, jest powierzchnia, ktora napedza wieloetapowego agenta AI, ktory strumieniuje do frontendu i zatrzymuje sie na review. Ta konwergencja jest tym, co czyni framework wartym powaznego spojrzenia w 2026, niezaleznie od tego, czy zarzadzasz SaaS, ktory potrzebuje niezawodnej pracy w tle, czy wysylasz funkcje AI, ktore przezywaja serverless timeout.
447~
448> **Checklist Pierwszych Krokow:**
449>
450> - [x] Zarejestruj sie na trigger.dev lub uruchom self-hosted Docker stack
451> - [x] `npx trigger.dev@latest init` w twoim projekcie
452> - [x] Zdefiniuj swoj pierwszy task z `task({ id, run })`
453> - [x] Triggeruj go z twojego API i ogladaj run w dashboardzie
454> - [x] Dodaj `idempotencyKey` i `concurrencyKey` dla bezpieczenstwa produkcyjnego
455> - [x] Polacz `useRealtimeRun` z komponentem statusu
456> - [x] Deployuj z `trigger.dev deploy --env prod` z CI
457~