Trigger.dev: фоновые задачи TypeScript, тарифы и ограничения

Что может заменить Trigger.dev?

Trigger.dev объединяет среду выполнения задач, очереди, расписания, развёртывание и панель мониторинга запусков. Вы пишете асинхронную функцию, передаёте ей данные, а отдельный воркер выполняет её, пока приложение уже возвращает ответ пользователю. Сервис может заменить инфраструктуру, которую иначе пришлось бы собирать вокруг фоновых задач. Но он не заменяет базу данных приложения, бизнес-правила или модель, которая принимает решения за ИИ-агента.

Сведения сверены с актуальной документацией, тарифами, журналом изменений и репозиторием GitHub 11 ноября 2026 года. Оценка основана на документации: тестирования с входом в аккаунт и замеров производительности не проводилось. Рекомендация учитывает, кто отвечает за среду выполнения, где проходят границы восстановления, насколько удобно сопровождать процессы и какие ограничения действуют в продакшене.

В анонсе выхода v4 от 18 августа 2025 года появились тёплый запуск, точки ожидания для согласований и обратных вызовов, приоритетные очереди, изменения панели управления и хуки жизненного цикла. Последний релиз, указанный на момент проверки, — v4.8.4 от 10 ноября 2026 года. В нём добавлены идентификация рабочих нагрузок и публикация доверенных развёртываний. Эти возможности позволяют поддерживаемым сервисам и системам развёртывания проходить аутентификацию по короткоживущим токенам идентификации вместо хранимых долгоживущих учётных данных.

Для основателя продукта практическая разница такова: «сформировать отчёт после загрузки файла» становится управляемой фоновой задачей, а не веб-обработчиком, который держит соединение открытым до готовности отчёта. Приложение по-прежнему должно хранить связь отчёта с клиентом и определять, что делать, если генерация завершится ошибкой.

Кому стоит выбрать сервис, а кому — рассмотреть другие варианты?

Trigger.dev подходит продуктам, за которые отвечает команда разработки и в которых фоновая логика должна жить рядом с остальным кодом на TypeScript. Чем ближе требование к формулировке «надёжно выполнить эту функцию со всеми её зависимостями», тем удачнее выбор.

В таблице ниже сравнивается, где описывается процесс и за что приходится отвечать вашей команде. Это выбор архитектуры, а не рейтинг поставщиков по длине списка возможностей.

n8n: когда процессом управляет специалист по операциям

n8n логичнее выбрать для специалиста по операционному сопровождению продаж, который связывает сбор лидов, обогащение данных и последующие контакты. Визуальная модель позволяет видеть устройство процесса и менять его без обязательных правок кода приложения. n8n поддерживает ИИ и автоматизацию бизнеса, поэтому одного аргумента «нам нужен агент» недостаточно, чтобы исключить его из рассмотрения.

Компромисс связан с распределением ответственности. Если основная сложность — собственная логика приложения с библиотеками и зависимостями для развёртывания, задачу на TypeScript может быть проще сопровождать, чем разрастающуюся визуальную схему. Если же важно дать специалисту по операциям возможность менять бизнес-шаги, Trigger.dev сделает его зависимым от разработчиков. Для такого выбора полезно более широкое сравнение альтернатив n8n.

Inngest или Trigger.dev: что выбрать?

Inngest — ближайший вариант для сравнения, если разработчикам нужны функции с восстановлением после сбоев. В актуальной документации описаны сохранение результатов шагов и повторное выполнение с того шага, на котором произошёл сбой, а также SDK для TypeScript, Python и Go. Его стоит рассмотреть, когда приложение естественно разбивается на именованные шаги или команда Python хочет писать процессы на Python.

Привлекательность Trigger.dev в том, что вместе с оркестрацией он предоставляет среду выполнения задач и их зависимости. Явная модель шагов Inngest делает границы восстановления видимыми в коде. Ни один из вариантов не отменяет необходимости безопасно повторять запись во внешнюю систему. Выбирайте по тому, как хотите развёртывать нагрузку и разбирать сбои, а не исходя из предположения, что ожидания или агентов поддерживает только один сервис.

Temporal: когда выбор затрагивает всю платформу

Temporal стоит включить в список, когда бизнес-процесс проходит через несколько сервисов, а его жизненный цикл важнее быстрого развёртывания фоновой функции. В документации описаны SDK для нескольких языков и развёртывание приложения рядом с сервисом Temporal — собственным или управляемым.

Цена такого выбора — архитектурные обязательства: ваши разработчики отвечают за приложение с процессами и за организацию его эксплуатации. Небольшому продукту на TypeScript, которому нужно лишь вынести генерацию отчёта за пределы веб-запроса, такая система может оказаться избыточной. Для платформенной команды, которая стандартизирует долгоживущие бизнес-процессы, именно это и может быть целью.

Как написать, развернуть и повторно запустить фоновую задачу

Trigger.dev переносит медленную часть обработки запроса в задачу, за которой можно наблюдать отдельно. Например, при импорте документов приложение принимает файл, сохраняет запись об импорте, запускает обработку и возвращает управление клиенту. Извлечение данных и классификация продолжаются в фоне.

Ниже — пример hello-world из документации по задачам. Комментарии удалены, а экспорт добавлен, чтобы задачу можно было обнаружить и импортировать:

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

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

Ключевая граница здесь — входные данные задачи: передайте информацию, необходимую для поиска и обработки импорта, а ответ на пользовательский запрос не связывайте с завершением задачи.

Документация по повторным попыткам разделяет повтор всей задачи, повтор небольшого блока через retry.onThrow и повтор HTTP-запроса через retry.fetch. При повторной попытке задача может выполниться целиком. Если импорт успешно обработан, а последующее уведомление завершилось ошибкой, бездумный перезапуск всего кода может повторить уже выполненные записи.

Правило проектирования: временные сбои обрабатывайте повторными попытками как можно ближе к проблемной операции, а записи делайте идемпотентными — повтор той же операции не должен создавать ещё один бизнес-эффект. Платформа задач даёт механизмы восстановления, но именно ограничения базы данных и выбранные внешние API определяют, появятся ли при повторе лишний счёт, письмо или запись.

Trigger.dev и Python

Trigger.dev умеет выполнять скрипты Python внутри задач TypeScript через расширение сборки для Python. Это полезно, если веб-продукт написан на TypeScript, а парсер документов — на Python. Это мост между средами выполнения, а не тот же опыт разработки, что у нативного SDK процессов для Python.

Есть важная деталь развёртывания: установка из requirementsFile в этом расширении выполняется только в продакшене; зависимости для разработки нужно устанавливать локально. Если парсер работает на ноутбуке, это ещё не доказывает, что зависимости в развёрнутой среде настроены правильно.

Как приостановить агента до согласования или обратного вызова

Точки ожидания Trigger.dev позволяют остановить процесс, пока человек или внешний сервис не предоставит недостающий результат. Для агента возвратов это означает разделение действий «рекомендовать возврат» и «выдать возврат». Задача может подготовить рекомендацию, дождаться согласования и продолжить работу только после получения решения.

В руководстве разработчика по точкам ожидания для такой передачи управления используются wait.createToken, wait.forToken и wait.completeToken. Там же показаны URL обратных вызовов для внешних сервисов. Приложение по-прежнему определяет, кто вправе согласовать действие и какие полномочия даёт это согласование.

Время и стоимость регулируются отдельно. Согласно актуальной документации по ожиданиям, ожидания по таймеру дольше 5 секунд не учитываются в вычислительном потреблении. Но такое ожидание освобождает слот параллельного выполнения только после создания снимка машины и её выключения — через 60 секунд после начала ожидания. Поэтому более короткое ожидание может быть бесплатным с точки зрения вычислений, но всё ещё занимать слот.

Разница важна, если множество запусков агентов одновременно ненадолго приостанавливаются. Спящая задача не означает автоматически свободную ёмкость для другой задачи. Планируйте лимит параллельных запусков с учётом выполняющихся задач и коротких ожиданий, а не только операций с высокой нагрузкой на CPU.

Для выбора слоя рассуждений агента есть отдельное сравнение фреймворков ИИ-агентов. Среда выполнения Trigger.dev помогает работе продолжаться, но поведение агента по-прежнему определяется промптами, инструментами и правилами согласования.

Как планировать синхронизации с учётом реального времени запуска

Trigger.dev поддерживает регулярные задачи через schedules.task. Расписания можно задать в коде либо подключить через панель управления и SDK. Хороший пример — синхронизация клиентских данных: расписание запускает обработку, задача выполняет работу, а история запусков показывает, завершилась ли она.

В документации по задачам с расписанием есть ограничение, которое важнее самого слова «cron»: для новых расписаний по умолчанию действует 60-минутное окно распределения запусков. Ежедневная задача не обязана стартовать точно во время, указанное в cron. Если тариф позволяет, window: "0m" отключает такое распределение.

На Free новые расписания могут запускаться не чаще раза в час, а минимальное окно составляет 60 минут. Исключение — существующие расписания, для которых сохранены прежние условия. Переход на платный тариф не меняет ограниченное расписание автоматически: его нужно снова сохранить или повторно развернуть уже на платном тарифе.

Для ежедневной сводки такой разброс может быть допустим. Но если клиенту обещан отчёт к точному времени, полагаться на настройки по умолчанию нельзя. Прежде чем заменять существующее задание cron, отдельно определите периодичность, часовой пояс и допустимую задержку.

Прогресс — пользователям, сведения о сбоях — разработчикам

Trigger.dev Realtime помогает превратить фоновую задачу из непонятного индикатора загрузки в прозрачный процесс. На экране импорта можно показывать состояние запуска и метаданные прогресса, а при генерации текста — передавать результат потоком по мере работы задачи. Это разные каналы данных.

В обзоре Realtime разграничены useRealtimeRun, который отслеживает статус и метаданные, и useRealtimeStream, который получает данные из определённых потоков. Все хуки и функции Realtime требуют аутентификации. Клиент должен видеть прогресс своего импорта, а не получать доступ к запускам остальных пользователей.

Для разработчиков панель управления и логи задач отвечают на другой вопрос: где остановилось выполнение? Сообщения о прогрессе должны помогать пользователю понимать происходящее, но не переносить внутренние подробности ошибок в интерфейс продукта.

Trigger.dev и MCP

MCP-сервер Trigger.dev предоставляет помощнику по программированию инструменты для поиска по документации, инициализации проектов, запуска задач, развёртывания и просмотра запусков. MCP, Model Context Protocol, — интерфейс, через который помощник вызывает эти инструменты.

Используйте его, чтобы сократить цикл правок и отладки, сохраняя проверку поведения задачи. Способность помощника развернуть процесс ничего не говорит о том, безопасно ли повторять его внешние действия при сбое.

Тарифы Trigger.dev: что нужно для продакшена

Trigger.dev Hobby — разумная отправная точка для небольшого приложения в продакшене, если нагрузка укладывается в его ограничения: $10 в месяц с включёнными кредитами на использование на $10, 50 параллельных запусков и хранение логов 7 дней. Free предлагает $0 в месяц с кредитами на $5, 20 параллельных запусков и логи за 1 день. После исчерпания этих кредитов для продолжения работы задач потребуется платный тариф. Это данные с актуальной страницы тарифов, проверенные 11 ноября 2026 года.

Причиной перейти на Hobby может стать не только потребление ресурсов. Ограничения расписаний Free способны исключить этот тариф ещё до того, как вычисления станут дорогими. Другой рубеж — подключения Realtime: Free включает 10 одновременных подключений, Hobby — 150. Pro стоит $50 в месяц с кредитами на $50, включает 200 параллельных запусков и хранение логов 30 дней. Он становится актуален, когда перехода требуют параллельность или нужная глубина истории для отладки.

Для конкретного расчёта возьмём 10,000 успешных задач в месяц, каждая из которых выполняется 60 секунд на Small 1x, без повторных попыток. При ставке $0.0000338 за секунду плюс $0.000025 за вызов потребление составит:

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

На Hobby подписка за $10 покрывает $10 этого потребления, а доплата составит $10.53. Итого: $20.53 за платформу, или $0.002053 за завершённую задачу при указанных допущениях. Это расчёт по опубликованным ставкам, а не результат измерения нагрузки. Вызовы API моделей, хранение данных и другие сервисы оплачиваются отдельно; повторные попытки добавляют работу.

Выбирайте тариф по необходимым лимитам параллельности, расписаниям и глубине истории. Оценивайте потребление по времени выполнения и закладывайте запас на сбои и повторы: расчёт для успешных запусков не задаёт верхнюю границу расходов.

Ограничения, которые могут повлиять на выбор

Trigger.dev снимает значительную часть забот об инфраструктуре воркеров, но оставшиеся обязанности вполне конкретны и серьёзны.

Собственный хостинг не гарантирует возможностей Cloud

В репозитории Trigger.dev указана лицензия Apache-2.0 и даны ссылки на инструкции развёртывания через Docker Compose и Kubernetes. Источник кода и сведений о лицензии — репозиторий GitHub.

В сравнении вариантов размещения тёплый запуск, автомасштабирование, контрольные точки и выделенная поддержка сейчас перечислены как возможности только Cloud. При собственном хостинге веб-приложение, Redis, Postgres, супервизоры воркеров, обновления и надёжность также переходят в вашу зону ответственности.

Для процессов с большим количеством согласований поведение контрольных точек — существенный аргумент в пользу Cloud. В последнем релизе также упоминается очистка снимков microVM при собственном хостинге, поэтому из таблицы сравнения и описания релиза нельзя вывести простое равенство возможностей. Уточните, какое поведение поддерживает нужная вам конфигурация, и учтите эксплуатацию инфраструктуры при выборе.

Отсутствие тайм-аута платформы не отменяет правила обработки сбоев

Trigger.dev позволяет запускам работать без фиксированного ограничения длительности со стороны платформы, но в вашей конфигурации всё равно может быть задан maxDuration — лимит вычислительного времени. Документация по длительности описывает переопределение настроек и timeout.None для выполнения без ограничения времени.

Там же сказано, что при превышении максимальной длительности cleanup, onSuccess и onFailure не вызываются. Это опасная особенность, если приложение рассчитывает, что хук ошибки снимет резервирование или отметит импорт как неудавшийся. Предусмотрите способ сверять и приводить в согласованное состояние незавершённые записи приложения, чтобы единственный хук не оставался единственным механизмом восстановления.

Повторная попытка не определит безопасность бизнес-действия

Trigger.dev не может самостоятельно понять, нужно ли повторять частично выполненный возврат, цепочку писем или импорт данных. Даже исправное восстановление выполнения может дать неверный бизнес-результат, если повторное внешнее действие создаёт дополнительный эффект.

Перед внедрением найдите запись, которую нельзя делать дважды, и данные, подтверждающие, что она уже сделана. Если такой границы в процессе нет, смена платформы задач не сделает его корректным.

Доверие облаку с учётными данными требует осознанного решения

Trigger.dev сообщил об инциденте безопасности 1 ноября 2026 года: в некоторых средах через скомпрометированные корневые API-ключи клиентов был получен несанкционированный доступ к переменным окружения. В отчёте об инциденте сказано, что затронутые клиенты уведомлены, а скомпрометированные ключи отозваны; установки на собственном хостинге не пострадали.

Для нового покупателя это повод включить в оценку права учётных данных и меры, принятые поставщиком. Из инцидента не следует, что пострадали все клиенты или что собственная установка автоматически безопаснее. Изучите, какие учётные данные будут доступны воркеру и подходят ли вашим сервисам поддерживаемые способы идентификации.

Итог: когда стоит передать управление воркерами платформе

В этом сравнении Trigger.dev лучше всего подходит команде продукта на TypeScript, которая хочет получить фоновый код, инфраструктуру выполнения и панель запусков вместе. Начните с одной проблемной нагрузки — например, импорта или генератора отчётов — и определите границы повторного выполнения до переноса остальных задач.

Выбирайте n8n, если специалист по операциям должен самостоятельно вести и редактировать интеграционный процесс. Рассмотрите Inngest ради явной модели шагов или нативных SDK процессов для Python/Go. Temporal подходит, когда платформенная команда осознанно берёт на себя архитектуру надёжных бизнес-процессов между сервисами.

Если ваша основная потребность — перемещать информацию между бизнес-приложениями, лучше начать с обзора альтернатив Zapier, а не с внедрения инфраструктуры задач.

Перед переносом воспользуйтесь чек-листом аудита бизнес-процессов с ИИ, чтобы описать нагрузку, ответственного, обработку сбоев и передачу управления.

Частые вопросы