Trigger.dev Release Notes
177 release notes curated from 56 sources by the Releasebot Team. Last updated: Aug 13, 2026
- Aug 13, 2026
- Date parsed from source:Aug 13, 2026
- First seen by Releasebot:Aug 13, 2026
Trigger.dev v4.5.11
Trigger.dev adds environment API key support for `trigger deploy` and improves onboarding, deployment speed, task visibility, and watch-mode reliability. It also ships several server-side performance and UX fixes for faster, smoother project and environment management.
1 new feature, 4 improvements, and 11 server changes
Highlights
Authenticate trigger deploy with an environment API key
Authenticate
trigger deploywith an environment API keytrigger deploynow accepts an environment API key viaTRIGGER_ACCESS_TOKEN, alongside existing personal access token support. Useful in CI pipelines where you want credentials scoped to a specific environment rather than a user account. (#4561)Improvements
- Dev environment onboarding now tracks real progress. The setup checklist marks your project as initialized after
initruns, then updates live as your dev server connects and tasks register. The blank state adds a "Copy AI agent prompt" button with a project-prefilled setup prompt for Claude Code, Cursor, or any coding agent. Theinitscaffold now imports from@trigger.dev/sdkinstead of the deprecated@trigger.dev/sdk/v3subpath. (#4563) - Deployed images now ship dependencies and bundled task code as separate layers. Repeated deploys with unchanged dependencies push and pull far less data, making deployments and worker image pulls faster. (#4551)
- The current-worker API now reports each task's queue, so you can see which tasks write to a given queue. (#4525)
- Watch-mode chat streams now survive quiet windows and page reloads. A reply cut off by a lost connection shows an error instead of appearing finished. Aborting a resumed subscription only closes your local stream: call
stopGeneration(chatId)or passstopOnAbort: trueto stop the run itself. (#4516)
Server changes
These changes are included in the
v4.5.11Docker image and are already live on Trigger.dev Cloud:- Deployment-related API endpoints now draw from their own rate limit budget, configurable via
DEPLOYMENT_RATE_LIMIT_*environment variables, so runtime API traffic no longer competes with deploys for the same per-environment budget. (#4565) - Schedule validation during deploy and update is faster for projects with many preview branches. Project pages also load faster on these projects by skipping archived branch environments not shown in the UI. (#4598, #4595)
- Database queries that filter on a list of values now reuse cached query plans more consistently, reducing re-planning overhead when the list length changes. (#4480)
- Deleting or editing a secret environment variable, setting and importing environment variables, and loading the environment variables page (which now paginates and searches across all pages) are all faster on projects with many variables. (#4555, #4579, #4597)
- Deleting an alert channel and loading the deployments list are faster on projects with accumulated history. (#4554, #4591)
- Switching project or organization in the sidebar now keeps you on the same page instead of sending you back to Tasks. Pages for a specific run, deploy, or other single item open the matching list instead. (#4585)
- Fixed a timeout on the billing limits page for organizations with many preview branches. (#4594)
- Fixed the Concurrency page showing the wrong limit for the dev environment. (#4596)
- Creating an organization or project now completes reliably instead of sometimes returning to the creation form and making a duplicate. Renaming a project keeps you on the settings page with confirmation, instead of silently redirecting or clearing the form. (#4530, #4584, #4601)
- The health report now shows "unknown" for start latency when no data is available, instead of a misleading 0ms. (#4544)
- In the light theme, the Format, Clear, and Copy buttons on the query editor no longer blend into the query text behind them. (#4592)
How to upgrade
Update the
trigger.dev/*packages tov4.5.11using your package manager:npx trigger.dev@latest update # npm pnpm dlx trigger.dev@latest update # pnpm yarn dlx trigger.dev@latest update # yarn bunx trigger.dev@latest update # bunSelf-hosted users: update your Docker image to ghcr.io/triggerdotdev/trigger.dev:v4.5.11.
Original source - Aug 13, 2026
- Date parsed from source:Aug 13, 2026
- First seen by Releasebot:Aug 13, 2026
trigger.dev v4.5.11
Trigger.dev ships v4.5.11 with faster deploys, better dashboard performance, and a smarter dashboard agent. It also improves chat reliability, environment onboarding, scheduling, and API visibility while tightening fixes across self-hosted and cloud workflows.
trigger.dev v4.5.11
Upgrade
npx trigger.dev@latest update # npm pnpm dlx trigger.dev@latest update # pnpm yarn dlx trigger.dev@latest update # yarn bunx trigger.dev@latest update # bun Self-hosted Docker image: ghcr.io/triggerdotdev/trigger.dev:v4.5.11Release notes
Read the full release notes: https://trigger.dev/changelog/v4-5-11
What's changed
Highlights
Allow trigger deploy to authenticate with an environment API key from TRIGGER_ACCESS_TOKEN. (#4561)
Improvements
Chat in the browser now reconnects when the connection drops mid-turn, instead of leaving the reply stuck as if it were still generating. Reports can be fetched as structured data with the json format, and the shortest report period is now one minute (1m, 30m, 1h, 7d). The mint-token command's help is clearer too: a token minted without --cap is read-only, and --ttl shows the correct maximum lifetime of 7 days. (#4418)
The dev environment onboarding now tracks real progress. After you run init, the setup checklist marks your project as initialized, and it updates live as your dev server connects and your tasks register. The blank state also adds a "Copy AI agent prompt" button that copies a ready-to-paste setup prompt (pre-filled with your project reference) for Claude Code, Cursor, or any coding agent. (#4563)
The init scaffold now imports from @trigger.dev/sdk instead of the deprecated @trigger.dev/sdk/v3 subpath.
Deployed images now ship dependencies and bundled task code as separate layers. Repeat deploys with unchanged dependencies typically push and pull far less data, making deploys and worker image pulls faster. (#4551)
The current-worker API now reports each task's queue, so you can see which tasks write to a given queue. (#4525)
Watch-mode chat streams now survive quiet windows and page reloads, and a reply cut off by a lost connection shows an error instead of appearing finished. Aborting a resumed subscription only closes your local stream — call stopGeneration(chatId) or pass stopOnAbort: true to stop the run. Also fixed a race where quickly restarting a stream could break stop and reconnect, and stopping a chat now hands it back to your other tabs instead of leaving them read-only. (#4516)
Server changes
These changes affect the self-hosted Docker image and Trigger.dev Cloud:
The dashboard agent now has a monthly message allowance and plan-based limits on watches. Queries stay read-only with clearer errors when busy, and messages with unusual characters no longer fail to send. (#4516)
Meet the dashboard agent: a chat in every environment that answers questions about your runs, queues, errors and health with real data and links, replacing Ask AI everywhere it used to appear. Investigate a failed run, an error, a backed-up queue or a run that hasn't started to get a worked-through answer — what happened, why, and how to fix it, with every claim linked to the runs, errors and deploys behind it. It reads your data read-only, works on preview and dev branches with that branch's own data, and reads the same everywhere — dashboard, terminal, editor. A very long chat keeps working: the agent summarises the earlier part and carries on.
Watch… on a run, queue, error or the health report tells you when things change: a run finishes, a queue clears or grows past a number you pick, an error comes back, an environment recovers. The answer arrives in the chat and, if you want, by email, Slack or webhook — and the agent can look into bad news on its own. A watch reaches you on any browser you sign in from, without opening the chat first.
A sample of conversations is scored automatically so the agent keeps getting better; only the score and a one-line summary are kept, never your messages, data or code, and we can switch it off for your organization on request. Ask the agent instead of the Docs buttons in page headers — they stay there when the agent isn't available to you. Separately, a queue's wait times, peak depth, throughput and throttling can now be read from the API. (#4418)
Add backend support for delaying cron schedules within a specified window with a minimum of 60 seconds. (#4566)
Reduced recurring background database load from the billing-limit recovery check, so paused environments are reconciled with less overhead. (#4590)
Validating a schedule when deploying or updating a schedule now does less work on projects with many preview branches, so those operations stay fast as branches accumulate. (#4598)
Project pages now load faster for projects with a large number of preview branches, by no longer loading archived branch environments that aren't shown. (#4595)
Database queries that filter on a list of values now reuse cached query plans more consistently, instead of forcing the database to re-plan whenever the list length changes. (#4480)
Routine cleanup of old dashboard agent data now runs on its own schedule. (#4599)
Database connection metrics are now reported for every configured database connection instead of only the primary one, and stay accurate regardless of connection type. (#4541)
Deployment-related API endpoints now draw from their own generous rate limit budget, configurable via the DEPLOYMENT_RATE_LIMIT_* environment variables, so runtime API traffic no longer competes with deployments for the same per-environment budget. (#4565)
Deleting or editing a secret environment variable is now fast and no longer slows down as a project accumulates variables. (#4555)
Speed up personal access token lookups by indexing them on their owner (#4588)
Switching project or organization in the sidebar now keeps you on the same page instead of sending you back to Tasks. Pages for a specific run, deploy or other single item open the matching list instead. (#4585)
Reduced database load when loading the dashboard by removing an unused organization member count that was being calculated on every page navigation. (#4587)
The environment variables page now loads a page at a time, keeping it fast for projects with a large number of variables. Search matches variable names across every page. (#4597)
Groundwork for an alternative database connection driver, gated behind configuration and disabled by default, so there is no change to default behavior. (#4539)
Deleting an alert channel is now fast and no longer slows down as a project builds up alert history. (#4554)
Reduced internal overhead on the API under high load. (#4532)
Out-of-date upgrade prompts no longer appear in the dashboard: the "V4" badges and the notices saying preview branches and the queues table need V4 have been removed. The side menu still warns you when a project is on v3, with updated wording and a link to the v4 upgrade guide. (#4589)
Make background worker registration cheaper for projects with many scheduled tasks by scoping declarative schedule reconciliation to the current environment and dropping redundant schedule lookups. (#4577)
Speed up setting and importing environment variables for projects with many variables. (#4579)
Loading the deployments list is now faster, especially when filtering by deployment status on projects with many deployments. (#4591)
Fixed the billing limits page timing out for organizations with many preview branches, especially while a spend limit was being enforced. The page now loads quickly, so you can raise or resolve your limit without delay. (#4594)
Fix the Concurrency page showing the plan's default concurrency for the dev environment instead of the environment's actual limit. (#4596)
Creating an organization sometimes left you back on the creation form even though the organization had already been created, so clicking Create again made a duplicate. Creating an organization now completes and takes you to your new organization. (#4530)
Ensure creating a project completes instead of returning to its creation form after a navigation error. (#4584)
Renaming a project now keeps you on the project settings page and tells you what happened, instead of silently moving you to the tasks page or clearing the form with no explanation. (#4601)
Fixed support threads showing no account details for some customers, so the team can see your plan, organizations and projects when you get in touch. (#4575)
In the light theme, the Format, Clear and Copy buttons on the query editor no longer blend into the query text behind them. (#4592)
The health report now says start latency is "unknown" when there is no data for it, instead of showing a healthy-looking 0ms (#4544)
Realtime streams written inside a chat session run now use the same backend as the session itself, and runs are no longer created against a backend that cannot serve them. (#4564)
The grouped "watch updates" notification now shows the total number of results waiting, instead of only the most recent batch's count. (#4525)
All packages: v4.5.11
@trigger.dev/build, @trigger.dev/core, @trigger.dev/python, @trigger.dev/react-hooks, @trigger.dev/redis-worker, @trigger.dev/rsc, @trigger.dev/schema-to-json, @trigger.dev/sdk, trigger.dev
Contributors
Eric Allam, Katia Bulatova, Chris Arderne, claude[bot], Matt Aitken, Saadi Myftija, @isshaddad, @D-K-P, github-actions[bot], James Ritchie, @nicktrn
Full changelog: v4.5.10...v4.5.11
Original source All of your release notes in one feed
Join Releasebot and get updates from Trigger.dev and hundreds of other software products.
- Aug 13, 2026
- Date parsed from source:Aug 13, 2026
- First seen by Releasebot:Aug 13, 2026
v.docker.4.5.11: chore: release v4.5.11 (#4557)
Trigger.dev adds dashboard agent chat, faster deploys and onboarding, plus improved browser chat reliability and richer reports. It also brings performance upgrades across environments, variables, queues and billing pages, with multiple bug fixes and API enhancements.
Summary
4 new features, 24 improvements, 10 bug fixes.
Highlights
Allow trigger deploy to authenticate with an environment API key from TRIGGER_ACCESS_TOKEN.
(#4561)
Improvements
Chat in the browser now reconnects when the connection drops mid-turn, instead of leaving the reply stuck as if it were still generating.
Reports can be fetched as structured data with the json format, and the shortest report period is now one minute (1m, 30m, 1h, 7d).
The mint-token command's help is clearer too: a token minted without --cap is read-only, and --ttl shows the correct maximum lifetime of 7 days.
(#4418)
The dev environment onboarding now tracks real progress. After you run init, the setup checklist marks your project as initialized, and it updates live as your dev server connects and your tasks register. The blank state also adds a "Copy AI agent prompt" button that copies a ready-to-paste setup prompt (pre-filled with your project reference) for Claude Code, Cursor, or any coding agent.
(#4563)
The init scaffold now imports from @trigger.dev/sdk instead of the deprecated @trigger.dev/sdk/v3 subpath.
Deployed images now ship dependencies and bundled task code as separate layers. Repeat deploys with unchanged dependencies typically push and pull far less data, making deploys and worker image pulls faster.
(#4551)
The current-worker API now reports each task's queue, so you can see which tasks write to a given queue.
(#4525)
Watch-mode chat streams now survive quiet windows and page reloads, and a reply cut off by a lost connection shows an error instead of appearing finished. Aborting a resumed subscription only closes your local stream — call stopGeneration(chatId) or pass stopOnAbort: true to stop the run. Also fixed a race where quickly restarting a stream could break stop and reconnect, and stopping a chat now hands it back to your other tabs instead of leaving them read-only.
(#4516)
Server changes
These changes affect the self-hosted Docker image and Trigger.dev Cloud:
The dashboard agent now has a monthly message allowance and plan-based limits on watches. Queries stay read-only with clearer errors when busy, and messages with unusual characters no longer fail to send.
(#4516)
Meet the dashboard agent: a chat in every environment that answers questions about your runs, queues, errors and health with real data and links, replacing Ask AI everywhere it used to appear. Investigate a failed run, an error, a backed-up queue or a run that hasn't started to get a worked-through answer — what happened, why, and how to fix it, with every claim linked to the runs, errors and deploys behind it. It reads your data read-only, works on preview and dev branches with that branch's own data, and reads the same everywhere — dashboard, terminal, editor. A very long chat keeps working: the agent summarises the earlier part and carries on.
Watch… on a run, queue, error or the health report tells you when things change: a run finishes, a queue clears or grows past a number you pick, an error comes back, an environment recovers. The answer arrives in the chat and, if you want, by email, Slack or webhook — and the agent can look into bad news on its own. A watch reaches you on any browser you sign in from, without opening the chat first.
A sample of conversations is scored automatically so the agent keeps getting better; only the score and a one-line summary are kept, never your messages, data or code, and we can switch it off for your organization on request. Ask the agent instead of the Docs buttons in page headers — they stay there when the agent isn't available to you.
Separately, a queue's wait times, peak depth, throughput and throttling can now be read from the API.
(#4418)
Add backend support for delaying cron schedules within a specified window with a minimum of 60 seconds.
(#4566)
Reduced recurring background database load from the billing-limit recovery check, so paused environments are reconciled with less overhead.
(#4590)
Validating a schedule when deploying or updating a schedule now does less work on projects with many preview branches, so those operations stay fast as branches accumulate.
(#4598)
Project pages now load faster for projects with a large number of preview branches, by no longer loading archived branch environments that aren't shown.
(#4595)
Database queries that filter on a list of values now reuse cached query plans more consistently, instead of forcing the database to re-plan whenever the list length changes.
(#4480)
Routine cleanup of old dashboard agent data now runs on its own schedule.
(#4599)
Database connection metrics are now reported for every configured database connection instead of only the primary one, and stay accurate regardless of connection type.
(#4541)
Deployment-related API endpoints now draw from their own generous rate limit budget, configurable via the DEPLOYMENT_RATE_LIMIT_* environment variables, so runtime API traffic no longer competes with deployments for the same per-environment budget.
(#4565)
Deleting or editing a secret environment variable is now fast and no longer slows down as a project accumulates variables.
(#4555)
Speed up personal access token lookups by indexing them on their owner
(#4588)
Switching project or organization in the sidebar now keeps you on the same page instead of sending you back to Tasks. Pages for a specific run, deploy or other single item open the matching list instead.
(#4585)
Reduced database load when loading the dashboard by removing an unused organization member count that was being calculated on every page navigation.
(#4587)
The environment variables page now loads a page at a time, keeping it fast for projects with a large number of variables. Search matches variable names across every page.
(#4597)
Groundwork for an alternative database connection driver, gated behind configuration and disabled by default, so there is no change to default behavior.
(#4539)
Deleting an alert channel is now fast and no longer slows down as a project builds up alert history.
(#4554)
Reduced internal overhead on the API under high load.
(#4532)
Out-of-date upgrade prompts no longer appear in the dashboard: the "V4" badges and the notices saying preview branches and the queues table need V4 have been removed. The side menu still warns you when a project is on v3, with updated wording and a link to the v4 upgrade guide.
(#4589)
Make background worker registration cheaper for projects with many scheduled tasks by scoping declarative schedule reconciliation to the current environment and dropping redundant schedule lookups.
(#4577)
Speed up setting and importing environment variables for projects with many variables.
(#4579)
Loading the deployments list is now faster, especially when filtering by deployment status on projects with many deployments.
(#4591)
Fixed the billing limits page timing out for organizations with many preview branches, especially while a spend limit was being enforced. The page now loads quickly, so you can raise or resolve your limit without delay.
(#4594)
Fix the Concurrency page showing the plan's default concurrency for the dev environment instead of the environment's actual limit.
(#4596)
Creating an organization sometimes left you back on the creation form even though the organization had already been created, so clicking Create again made a duplicate. Creating an organization now completes and takes you to your new organization.
(#4530)
Ensure creating a project completes instead of returning to its creation form after a navigation error.
(#4584)
Renaming a project now keeps you on the project settings page and tells you what happened, instead of silently moving you to the tasks page or clearing the form with no explanation.
(#4601)
Fixed support threads showing no account details for some customers, so the team can see your plan, organizations and projects when you get in touch.
(#4575)
In the light theme, the Format, Clear and Copy buttons on the query editor no longer blend into the query text behind them.
(#4592)
The health report now says start latency is "unknown" when there is no data for it, instead of showing a healthy-looking 0ms
(#4544)
Realtime streams written inside a chat session run now use the same backend as the session itself, and runs are no longer created against a backend that cannot serve them.
(#4564)
The grouped "watch updates" notification now shows the total number of results waiting, instead of only the most recent batch's count.
(#4525)
Raw changeset output
Releases
@trigger.dev/[email protected]
Patch Changes
Updated dependencies:
@trigger.dev/[email protected]
[email protected]Patch Changes
Chat in the browser now reconnects when the connection drops mid-turn, instead of leaving the reply stuck as if it were still generating.
Reports can be fetched as structured data with the json format, and the shortest report period is now one minute (1m, 30m, 1h, 7d).
The mint-token command's help is clearer too: a token minted without --cap is read-only, and --ttl shows the correct maximum lifetime of 7 days.
(#4418)
Allow trigger deploy to authenticate with an environment API key from TRIGGER_ACCESS_TOKEN.
(#4561)
The dev environment onboarding now tracks real progress. After you run init, the setup checklist marks your project as initialized, and it updates live as your dev server connects and your tasks register. The blank state also adds a "Copy AI agent prompt" button that copies a ready-to-paste setup prompt (pre-filled with your project reference) for Claude Code, Cursor, or any coding agent.
(#4563)
The init scaffold now imports from @trigger.dev/sdk instead of the deprecated @trigger.dev/sdk/v3 subpath.
Deployed images now ship dependencies and bundled task code as separate layers. Repeat deploys with unchanged dependencies typically push and pull far less data, making deploys and worker image pulls faster.
(#4551)
Updated dependencies:
@trigger.dev/[email protected]
@trigger.dev/[email protected]
@trigger.dev/[email protected]@trigger.dev/[email protected]
Patch Changes
Chat in the browser now reconnects when the connection drops mid-turn, instead of leaving the reply stuck as if it were still generating.
Reports can be fetched as structured data with the json format, and the shortest report period is now one minute (1m, 30m, 1h, 7d).
The mint-token command's help is clearer too: a token minted without --cap is read-only, and --ttl shows the correct maximum lifetime of 7 days.
(#4418)
The current-worker API now reports each task's queue, so you can see which tasks write to a given queue.
(#4525)
@trigger.dev/[email protected]
Patch Changes
Updated dependencies:
@trigger.dev/[email protected]
@trigger.dev/[email protected]
@trigger.dev/[email protected]
@trigger.dev/[email protected]Patch Changes
Updated dependencies:
@trigger.dev/[email protected]
@trigger.dev/[email protected]Patch Changes
Updated dependencies:
@trigger.dev/[email protected]
@trigger.dev/[email protected]Patch Changes
Updated dependencies:
@trigger.dev/[email protected]
@trigger.dev/[email protected]Patch Changes
Updated dependencies:
@trigger.dev/[email protected]
@trigger.dev/[email protected]Patch Changes
Chat in the browser now reconnects when the connection drops mid-turn, instead of leaving the reply stuck as if it were still generating.
Reports can be fetched as structured data with the json format, and the shortest report period is now one minute (1m, 30m, 1h, 7d).
The mint-token command's help is clearer too: a token minted without --cap is read-only, and --ttl shows the correct maximum lifetime of 7 days.
(#4418)
Watch-mode chat streams now survive quiet windows and page reloads, and a reply cut off by a lost connection shows an error instead of appearing finished. Aborting a resumed subscription only closes your local stream — call stopGeneration(chatId) or pass stopOnAbort: true to stop the run. Also fixed a race where quickly restarting a stream could break stop and reconnect, and stopping a chat now hands it back to your other tabs instead of leaving them read-only.
(#4516)
Updated dependencies:
@trigger.dev/[email protected]Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Original source - Aug 13, 2026
- Date parsed from source:Aug 13, 2026
- First seen by Releasebot:Aug 13, 2026
helm-v4.5.11: chore: release v4.5.11 (#4557)
Trigger.dev ships a broad platform update with faster deploys, richer browser chat reliability, new dashboard agent insights and watches, improved reports and token help, plus performance gains across environments, variables, queues and the dashboard.
Summary
4 new features, 24 improvements, 10 bug fixes.
Highlights
Allow trigger deploy to authenticate with an environment API key
from TRIGGER_ACCESS_TOKEN.
(#4561)Improvements
Chat in the browser now reconnects when the connection drops mid-turn,
instead of leaving the reply stuck as if it were still generating.Reports can be fetched as structured data with the json format, and
the shortest report period is now one minute (1m, 30m, 1h, 7d).The mint-token command's help is clearer too: a token minted without
--cap is read-only, and --ttl shows the correct maximum lifetime of
7 days.
(#4418)The dev environment onboarding now tracks real progress. After you run
init, the setup checklist marks your project as initialized, and it
updates live as your dev server connects and your tasks register. The
blank state also adds a "Copy AI agent prompt" button that copies a
ready-to-paste setup prompt (pre-filled with your project reference) for
Claude Code, Cursor, or any coding agent.
(#4563)The init scaffold now imports from @trigger.dev/sdk instead of the
deprecated @trigger.dev/sdk/v3 subpath.Deployed images now ship dependencies and bundled task code as
separate layers. Repeat deploys with unchanged dependencies typically
push and pull far less data, making deploys and worker image pulls
faster.
(#4551)The current-worker API now reports each task's queue, so you can see
which tasks write to a given queue.
(#4525)Watch-mode chat streams now survive quiet windows and page reloads,
and a reply cut off by a lost connection shows an error instead of
appearing finished. Aborting a resumed subscription only closes your
local stream — call stopGeneration(chatId) or pass stopOnAbort: true
to stop the run. Also fixed a race where quickly restarting a stream
could break stop and reconnect, and stopping a chat now hands it back to
your other tabs instead of leaving them read-only.
(#4516)Server changes
These changes affect the self-hosted Docker image and Trigger.dev Cloud:
The dashboard agent now has a monthly message allowance and plan-based
limits on watches. Queries stay read-only with clearer errors when busy,
and messages with unusual characters no longer fail to send.
(#4516)Meet the dashboard agent: a chat in every environment that answers
questions about your runs, queues, errors and health with real data and
links, replacing Ask AI everywhere it used to appear. Investigate a
failed run, an error, a backed-up queue or a run that hasn't started to
get a worked-through answer — what happened, why, and how to fix it,
with every claim linked to the runs, errors and deploys behind it. It
reads your data read-only, works on preview and dev branches with that
branch's own data, and reads the same everywhere — dashboard, terminal,
editor. A very long chat keeps working: the agent summarises the earlier
part and carries on.Watch… on a run, queue, error or the health report tells you when
things change: a run finishes, a queue clears or grows past a number you
pick, an error comes back, an environment recovers. The answer arrives
in the chat and, if you want, by email, Slack or webhook — and the agent
can look into bad news on its own. A watch reaches you on any browser
you sign in from, without opening the chat first.A sample of conversations is scored automatically so the agent keeps
getting better; only the score and a one-line summary are kept, never
your messages, data or code, and we can switch it off for your
organization on request. Ask the agent instead of the Docs buttons in
page headers — they stay there when the agent isn't available to you.Separately, a queue's wait times, peak depth, throughput and throttling
can now be read from the API.
(#4418)Add backend support for delaying cron schedules within a specified
window with a minimum of 60 seconds.
(#4566)Reduced recurring background database load from the billing-limit
recovery check, so paused environments are reconciled with less
overhead.
(#4590)Validating a schedule when deploying or updating a schedule now does
less work on projects with many preview branches, so those operations
stay fast as branches accumulate.
(#4598)Project pages now load faster for projects with a large number of
preview branches, by no longer loading archived branch environments that
aren't shown.
(#4595)Database queries that filter on a list of values now reuse cached
query plans more consistently, instead of forcing the database to
re-plan whenever the list length changes.
(#4480)Routine cleanup of old dashboard agent data now runs on its own
schedule.
(#4599)Database connection metrics are now reported for every configured
database connection instead of only the primary one, and stay accurate
regardless of connection type.
(#4541)Deployment-related API endpoints now draw from their own generous rate
limit budget, configurable via the DEPLOYMENT_RATE_LIMIT_* environment
variables, so runtime API traffic no longer competes with deployments
for the same per-environment budget.
(#4565)Deleting or editing a secret environment variable is now fast and no
longer slows down as a project accumulates variables.
(#4555)Speed up personal access token lookups by indexing them on their owner
(#4588)Switching project or organization in the sidebar now keeps you on the
same page instead of sending you back to Tasks. Pages for a specific
run, deploy or other single item open the matching list instead.
(#4585)Reduced database load when loading the dashboard by removing an unused
organization member count that was being calculated on every page
navigation.
(#4587)The environment variables page now loads a page at a time, keeping it
fast for projects with a large number of variables. Search matches
variable names across every page.
(#4597)Groundwork for an alternative database connection driver, gated behind
configuration and disabled by default, so there is no change to default
behavior.
(#4539)Deleting an alert channel is now fast and no longer slows down as a
project builds up alert history.
(#4554)Reduced internal overhead on the API under high load.
(#4532)Out-of-date upgrade prompts no longer appear in the dashboard: the
"V4" badges and the notices saying preview branches and the queues table
need V4 have been removed. The side menu still warns you when a project
is on v3, with updated wording and a link to the v4 upgrade guide.
(#4589)Make background worker registration cheaper for projects with many
scheduled tasks by scoping declarative schedule reconciliation to the
current environment and dropping redundant schedule lookups.
(#4577)Speed up setting and importing environment variables for projects with
many variables.
(#4579)Loading the deployments list is now faster, especially when filtering
by deployment status on projects with many deployments.
(#4591)Fixed the billing limits page timing out for organizations with many
preview branches, especially while a spend limit was being enforced. The
page now loads quickly, so you can raise or resolve your limit without
delay. (#4594)Fix the Concurrency page showing the plan's default concurrency for
the dev environment instead of the environment's actual limit.
(#4596)Creating an organization sometimes left you back on the creation form
even though the organization had already been created, so clicking
Create again made a duplicate. Creating an organization now completes
and takes you to your new organization.
(#4530)Ensure creating a project completes instead of returning to its
creation form after a navigation error.
(#4584)Renaming a project now keeps you on the project settings page and
tells you what happened, instead of silently moving you to the tasks
page or clearing the form with no explanation.
(#4601)Fixed support threads showing no account details for some customers,
so the team can see your plan, organizations and projects when you get
in touch.
(#4575)In the light theme, the Format, Clear and Copy buttons on the query
editor no longer blend into the query text behind them.
(#4592)The health report now says start latency is "unknown" when there is no
data for it, instead of showing a healthy-looking 0ms
(#4544)Realtime streams written inside a chat session run now use the same
backend as the session itself, and runs are no longer created against a
backend that cannot serve them.
(#4564)The grouped "watch updates" notification now shows the total number of
results waiting, instead of only the most recent batch's count.
(#4525)Raw changeset output
Releases
@trigger.dev/[email protected]
Patch Changes
Updated dependencies:
@trigger.dev/[email protected]
[email protected]Patch Changes
Chat in the browser now reconnects when the connection drops mid-turn,
instead of leaving the reply stuck as if it were still generating.Reports can be fetched as structured data with the json format, and
the shortest report period is now one minute (1m, 30m, 1h, 7d).The mint-token command's help is clearer too: a token minted without
--cap is read-only, and --ttl shows the correct maximum lifetime of
7 days.
(#4418)Allow trigger deploy to authenticate with an environment API key
from TRIGGER_ACCESS_TOKEN.
(#4561)The dev environment onboarding now tracks real progress. After you run
init, the setup checklist marks your project as initialized, and it
updates live as your dev server connects and your tasks register. The
blank state also adds a "Copy AI agent prompt" button that copies a
ready-to-paste setup prompt (pre-filled with your project reference) for
Claude Code, Cursor, or any coding agent.
(#4563)The init scaffold now imports from @trigger.dev/sdk instead of the
deprecated @trigger.dev/sdk/v3 subpath.Deployed images now ship dependencies and bundled task code as
separate layers. Repeat deploys with unchanged dependencies typically
push and pull far less data, making deploys and worker image pulls
faster.
(#4551)Updated dependencies:
@trigger.dev/[email protected]
@trigger.dev/[email protected]
@trigger.dev/[email protected]@trigger.dev/[email protected]
Patch Changes
Chat in the browser now reconnects when the connection drops mid-turn,
instead of leaving the reply stuck as if it were still generating.Reports can be fetched as structured data with the json format, and
the shortest report period is now one minute (1m, 30m, 1h, 7d).The mint-token command's help is clearer too: a token minted without
--cap is read-only, and --ttl shows the correct maximum lifetime of
7 days.
(#4418)The current-worker API now reports each task's queue, so you can see
which tasks write to a given queue.
(#4525)@trigger.dev/[email protected]
Patch Changes
Updated dependencies:
@trigger.dev/[email protected]
@trigger.dev/[email protected]
@trigger.dev/[email protected]
@trigger.dev/[email protected]Patch Changes
Updated dependencies:
@trigger.dev/[email protected]
@trigger.dev/[email protected]Patch Changes
Updated dependencies:
@trigger.dev/[email protected]
@trigger.dev/[email protected]Patch Changes
Updated dependencies:
@trigger.dev/[email protected]
@trigger.dev/[email protected]Patch Changes
Updated dependencies:
@trigger.dev/[email protected]
@trigger.dev/[email protected]Patch Changes
Chat in the browser now reconnects when the connection drops mid-turn,
instead of leaving the reply stuck as if it were still generating.Reports can be fetched as structured data with the json format, and
the shortest report period is now one minute (1m, 30m, 1h, 7d).The mint-token command's help is clearer too: a token minted without
--cap is read-only, and --ttl shows the correct maximum lifetime of
7 days.
(#4418)Watch-mode chat streams now survive quiet windows and page reloads,
and a reply cut off by a lost connection shows an error instead of
appearing finished. Aborting a resumed subscription only closes your
local stream — call stopGeneration(chatId) or pass stopOnAbort: true
to stop the run. Also fixed a race where quickly restarting a stream
could break stop and reconnect, and stopping a chat now hands it back to
your other tabs instead of leaving them read-only.
(#4516)Updated dependencies:
@trigger.dev/[email protected]Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Original source - Aug 11, 2026
- Date parsed from source:Aug 11, 2026
- First seen by Releasebot:Aug 13, 2026
MCP server gets agent chat, prompt management, and reports
Trigger.dev expands its official MCP server with stateful agent chats, end-to-end prompt version management, server-rendered health reports, TRQL data queries, dev server control, deeper span inspection, profile switching, and safety flags. All tools are available at @latest.
When we shipped the official MCP server at Launch Week 2, it could set up a project, trigger tasks, deploy, and read runs. It does a lot more now. The server always runs at @latest, so every tool below is already available to you. Nothing to upgrade.
Talk to your deployed agents
If you've built a chat.agent(), your coding assistant can hold a real conversation with it.
list_agentsshows what's registered in the current worker, andstart_agent_chat,send_agent_message, andclose_agent_chatdrive a stateful session. Test an agent from Claude Code or Cursor without wiring up a UI first.You: Start a chat with the support agent, ask it to look up order #4821
AI: I found order #4821. Placed March 15, shipped via FedEx (tracking 7891234). Current status: In Transit, estimated delivery March 19.
Tools used: lookupOrder, getShippingStatusManage prompt versions
AI Prompts are versioned, overridable config. The MCP server now manages them end to end. Use
list_promptsandget_prompt_versionsto see what's deployed,promote_prompt_versionto ship a version, andcreate_prompt_override,update_prompt_override,remove_prompt_override, andreactivate_prompt_overrideto point an environment at a specific version without a redeploy. Iterate on a system prompt and roll it out from the same place you write the code.Pull a health report with /report
get_reportreturns a server-rendered health report for an environment: a headline verdict plus text sparklines for whether work is flowing, whether the runs that start are healthy, and whether your telemetry is fresh. The verdict is computed server-side, so you get the same answer in chat, on the CLI, or over the API. In hosts that support MCP prompts, run /report health and it renders inline.Also new since launch
- Query your data with TRQL.
queryandget_query_schemarun SQL-style queries over your runs, metrics, and llm_metrics tables.list_dashboardsandrun_dashboard_querypull the built-in dashboards. - Drive the dev server.
start_dev_server,stop_dev_server, anddev_server_statusrun trigger dev in the background and stream its logs back. - Inspect deeper.
get_span_detailsopens any span in a run trace, including the model, tokens, and cost on AI spans. - Switch profiles.
whoami,list_profiles, andswitch_profilemove between accounts mid-session. - Safety flags.
--readonlyhides every write tool so the assistant can't change anything, and--dev-onlyscopes the server to your dev environment.
Get started
The MCP server always runs at @latest, so all of this is ready now:
npx trigger.dev@latest mcp --installRead the MCP tools reference for the full list.
Original source Similar to Trigger.dev with recent updates:
- Smokeball release notes138 release notes · Latest Aug 12, 2026
- Cosmolex release notes20 release notes · Latest Jul 30, 2025
- PracticePanther release notes36 release notes · Latest Aug 11, 2026
- Salesforce release notes58 release notes · Latest Jul 1, 2026
- Microsoft release notes782 release notes · Latest Aug 13, 2026
- Zoom release notes205 release notes · Latest Jul 27, 2026
- Aug 10, 2026
- Date parsed from source:Aug 10, 2026
- First seen by Releasebot:Aug 11, 2026
Introducing chat agent
Trigger.dev introduces chat.agent, a durable AI chat transport with no timeouts, streamed conversations that survive refreshes and crashes, built-in state, tracing, metrics, and easy useChat integration.
Chat agent is a way to build durable AI chat experiences that run on a machine with no timeouts and keep streaming through refreshes and crashes. The machine sleeps when nobody's typing and wakes where it left off, without you managing any state.
That machine starts when the first message arrives, runs for as long as the work takes, and holds everything in memory between turns: your variables, your caches, the sub-agent you spawned four questions ago.
You write the turn as a Trigger.dev task that takes messages and returns a stream, then point the AI SDK's useChat straight at it. There's no API route in between, and the whole backend is this:
trigger/chat.ts import { chat } from "@trigger.dev/sdk/ai"; import { streamText, stepCountIs } from "ai"; import { anthropic } from "@ai-sdk/anthropic"; export const myChat = chat.agent({ id: "my-chat", run: async ({ messages, signal }) => { return streamText({ model: anthropic("claude-sonnet-4-5"), messages, abortSignal: signal, stopWhen: stepCountIs(15), }); }, });Arena built Agent Mode on chat.agent and runs it in production at scale.
“Every conversation gets a real machine, which made our durable agents much more straightforward to build.
The default tracing and observability make viewing and debugging agentic sessions incredibly easy.”They're not the only ones. chat.agent has been generally available since July 2 and running in production since June, so it arrives here having already served millions of sessions and more than 84 years of compute.
Why chat.agent is better
Most chat backends tie the work to the request, and a normal API endpoint is a poor fit for a chat agent (or any agent, but that's another story).
Request/response cycles normally have timeouts and are stateless. You have to fight this by writing everything to a database, using Redis for durable streams, and queueing slow work to a background worker you then have to coordinate.
Good luck if your model takes longer to answer than your function is allowed to run. Or if something fails and you want to retry it. Or if you want to spawn a sub-agent that does its own thinking. Or if you want to close the browser and come back days later.
A stateful machine is a much better fit:
A real Linux machine. Install what you want, run any CLI, pick the CPU and RAM.
Durable compute, durable streams. No timeout on a turn. A conversation you can close and come back to days later.
Fast first turns. The first LLM call runs in your own warm server while the agent boots alongside it, so durable doesn't mean slow.
Waiting costs nothing. An agent can stop, ask a person to approve something, and sit there for days without running up a bill.
Tracing and metrics built in. Every turn is a span, and there’s an AI metrics dashboard for cost, tokens and latency.And it uses the AI SDK you probably already use.
A real Linux machine
The computer behind a conversation is an ordinary Linux machine, not a restricted runtime. Install what you need. Shell out to ffmpeg, drive a headless browser, run a CLI that expects a real filesystem and a real process tree.
You pick how big it is. Machine presets run from micro at 0.25 vCPU upwards, each with dedicated CPU, memory and disk. Set per agent, overridable per conversation.
Durable compute, durable streams
A turn has no timeout. It runs as long as the work takes, so a slow tool, a long chain of them, or a sub-agent doing its own thinking is just work. You don't have to chop anything into chunks that fit a limit, and you don't need a queue for the slow parts. In production one agent run in twenty lasts longer than 36 minutes, well past where a request would have been cut off.
Memory carries across a sleep. Whatever you kept in a variable on turn three is still sitting there on turn twenty tomorrow, so an expensive lookup you already did stays done.
If the machine crashes you get a new one, and the conversation comes back with it because that part is written down. The heap doesn't: your Map starts empty again. That's the same rule as any long-running server you've operated, so put anything you can't afford to lose in a database and keep memory for speed. What's different here is that memory now lasts the whole conversation instead of a single request.
The stream is durable too. A conversation is a session, and the session outlives the process serving it: runs are the compute, the session is the identity. Refresh mid-response and the stream replays from where your browser stopped reading, without re-running the model. Close the browser and come back days later and the conversation is still there.
That makes the failure cases boring. If a run is killed or runs out of memory, the next message boots a new one with the conversation restored. Deploys don't interrupt anything: a run stays on the version it started on, and moving a conversation onto new code is a call you make yourself with chat.requestUpgrade().
Fast first turns
Durable doesn't have to mean slow. Head Start is optional, and it's there for when you want the first token as fast as a plain endpoint would give it to you. It runs the first LLM call inside your own warm server while the agent boots in parallel, then hands the conversation over mid-turn for the tool calls and everything after. The user sees one continuous response and never notices the seam.
In our tests it roughly halved both time to first token and the length of the whole turn.
It returns a plain Web Fetch handler, so it mounts in Next.js, Hono, SvelteKit, Remix, TanStack Start and the rest with no adapter. And when a first turn is pure text with no tool calls, the agent boots and exits without ever calling a model, so you only pay for what the conversation actually needed.
Because memory is snapshotted rather than replayed, none of this puts determinism constraints on your code. There's no event history to replay, so Date.now(), Math.random(), and a fetch in the middle of your loop are all just code. Nothing to make deterministic, no replay log to version.
Waiting costs nothing
A tool with no execute function ends the turn with the call still open.
The agent suspends, the person takes as long as they take, and their answer resumes the run. Because it's suspended, you're not charged for the wait, so an approval can sit overnight or over a weekend.
The usual chat controls are here too. Stop a generation mid-stream, steer it between tool calls, or edit, branch and regenerate your way back through an earlier message.
Tracing and metrics built in
Every turn is a span in the dashboard, so you can open a conversation and see the prompts, the responses, the tool calls and how long each one took.
An AI metrics dashboard ships with every project. Total spend, total calls, average time to first chunk and average tokens per second, then cost over time and by model, tokens over time, latency percentiles by model, finish reasons, your most expensive runs, and cost broken down by task and by provider.
Every model gets its own row too, so you can see what each one actually costs you and what prompt caching is saving.
The data behind those charts is available to TRQL, so you can ask your own questions and build your own dashboards. sessions.list gives you every conversation, enough to build an inbox.
Keep using the AI SDK
streamText on the server, useChat on the client. chat.agent slots in underneath as a transport, and the API route between them goes away.
Only the new message goes over the wire. History accumulates on the server, so you're not re-uploading the conversation on every turn.
If you already have a chat app, the migration guide has a prompt you can hand to your coding agent.
There's more
You don't have to stay at the top level. chat.agent() manages the turn loop for you, custom agents hand it back so you can write the loop yourself, and underneath that the raw session primitives let you read and write the conversation's streams directly. Start simple, drop down when you need to.
Long conversations stay affordable: compaction summarizes history when it gets close to the context limit, and prompt caching keeps the stable prefix of every request cheap. You decide when it kicks in and what the summary looks like.
Your prompts can live in the codebase too. They're versioned on every deploy, you can override the text or the model from the dashboard without redeploying, and every generation is tracked back to the version that produced it.
Browsers aren't the only client. AgentChat drives a conversation from a task, a script, or another agent, and the MCP server lets you talk to your own agents from Claude Code or Cursor without writing anything at all.
For the frontend there's also actions, for commands that change state without spending a turn.
When things go wrong, a turn killed by an out-of-memory error retries on a bigger machine without losing the message that caused it, recovery boot restores full context after a crash or a cancel, and version upgrades move a suspended conversation onto new code when you decide it's time. You can also give an agent skills, folders of instructions and scripts it discovers and uses on demand.
Testing, and the rest of Trigger.dev
You can test an agent by driving it through real turns in a unit test. No network, no task runtime, and nothing of ours mocked out from under you.
Because an agent is a Trigger.dev task, all of the existing features work too. Trigger other tasks from a tool call and wait for them, put a chat behind a queue with its own concurrency, batch work, schedule it, or build your own evals as tasks that run agents against a fixture set on every deploy. None of that is a separate product you have to adopt.
Open source, and what it costs
Trigger.dev is Apache 2.0 and chat.agent is part of it. Read the code of how this all works and run the whole thing yourself if you'd like.
A chat agent is billed as compute time when it's actually running. A suspended conversation isn't running, which is why waiting is free.
Try it today
Read the chat.agent docs to get an agent running in three steps, or if you already have a chat app, the migration guide has a prompt you can hand to your coding agent.
Original source - Aug 7, 2026
- Date parsed from source:Aug 7, 2026
- First seen by Releasebot:Aug 13, 2026
Trigger.dev v4.5.10
Trigger.dev adds task-scoped API keys that can run batch operations, plus faster, more reliable batching, debounce, chat, and dashboard behavior. The release also brings TypeScript 7 compatibility, region selection for MCP runs, and a refreshed dark theme default.
Highlights
Task-scoped API keys can now run batch operations
Environment API keys scoped to specific tasks can now trigger batch operations for their permitted tasks. The SDK declares the batch's task set before creation, and @trigger.dev/core/v3/apiKeys exports a helper for constructing the additional-key format. (#4389)
Improvements
- Refreshed package builds for TypeScript 7 compatibility, preserving existing runtime entry points. Projects using emitDecoratorMetadata() with TypeScript 7 can install the @typescript/typescript6 compatibility package alongside it; it's optional and not pulled in by installing the Trigger.dev CLI. (#4318)
- AgentChat.reconnect() now settles promptly when reconnecting to an idle chat instead of holding the connection open for the full long-poll window. Also upgrades the S2 streamstore client to 0.25 and moves realtime streams to S2's current hosts. (#4349)
- You can now pick the region a run executes in when triggering a task through the MCP server. (#4439)
- Transient connection errors at run start are now retried for longer, so a brief connectivity blip no longer sends the run back through the queue and delays its first attempt. (#4441)
- debounce now works correctly when passing an array of items to batchTrigger or batchTriggerAndWait, and when triggering from useTaskTrigger. Previously the option was accepted by the types but dropped before the request was sent, creating a separate run for every trigger instead of collapsing onto the debounce key. (#4520)
Bug fixes
- Fix a chunk occasionally dropped when a chat.agent run takes over from the warm first turn. The realtime stream writer now reports the inclusive last-written position as the resume cursor, so the agent's first record after the handover is no longer skipped. (#4349)
- Fix a preloaded chat.agent run dropping an in-flight message when it retries after an out-of-memory error. The message being processed when the run hit OOM is now recovered and re-run on retry instead of being skipped. (#4349)
Server changes
These changes are included in the v4.5.10 Docker image and are already live on Trigger.dev Cloud:
- Self-hosted deployments can now create multiple full-access API keys per environment. (#4390)
- Short links like /_/apikeys now navigate directly to that page in your current project and environment, without needing the full URL. (#4523)
- The dashboard's refreshed dark theme is now the default. You can switch to Light, System, or the original Classic look on the account page, with a contrast slider for the new themes. (#4206)
- Self-hosted Kubernetes deployments can now add tolerations to run pods, allowing runs on tainted nodes. An invalid toleration now stops the supervisor at startup instead of failing every run pod. (#4491)
- Batch triggers no longer fail to start their runs under heavy API load. If a batch still can't be created, batchTriggerAndWait fails with an error instead of leaving the parent run waiting forever. (#4397)
- Fixed debounce doing nothing when the delay exceeded an hour. Debounced runs now keep being pushed back as long as triggers keep arriving; use maxDelay to set a ceiling. Debounce settings that could never fire are now rejected rather than silently ignored. (#4521)
- Fixed a rare case where a single run or span with unprocessable data would cause other runs and trace events in the same batch to disappear from the runs list, traces, and logs. The rest of the batch is now always preserved. (#4358)
- Team members who join an organization through SSO or directory sync now automatically get a development environment for every project. Existing members missing one are repaired on their next membership sync from the identity provider. (#4426)
- Browser tabs now show the name of the current page, and the run, task, or queue when viewing one, instead of always reading "Trigger.dev". (#4517)
- Triggering a task now does one fewer database write, so runs reach the queue slightly faster. (#4419)
- Creating or updating a schedule, and deploying projects with declarative schedules, is faster in long-lived projects that have accumulated many deploys. (#4518)
- Lower background database load during deployments and dev sessions for projects using declarative schedules. (#4522)
- API rate limits now apply per environment. (#4508)
- Triggering a run with a very large priority value no longer fails. The value is now capped to the highest supported limit instead of returning an error. (#4512)
- Fixed a rare error where an idempotency key or debounce key containing a null character would fail to create the run. The null character is now removed automatically. (#4527)
- Speed up resolving the latest worker version and deployment for an environment, removing an occasional stall when triggering runs in projects with many deployed versions. (#4452)
- Fixed the "Contact us" form in the sidebar sometimes failing to send. (#4445)
- The Queues pages now open on the last hour by default and remember the time period you picked when navigating between queues or reloading. (#4438)
- Fixed the health report endpoint returning an internal error when called through the API. (#4488)
- Triggering a task no longer intermittently fails when a database write briefly stalls. (#4514)
- The four charts at the top of the Queues page now always reflect the whole environment, regardless of which queues are visible or how they're sorted. The scheduling delay chart also leaves a gap where no runs started, instead of dropping to zero. (#4486)
- Honor the configured database connection timeout, reducing spurious connection errors during brief connection spikes. (#4513)
- Reject alert webhook destinations in reserved benchmarking IP ranges. (#4528)
How to upgrade
Update the trigger.dev/* packages to v4.5.10 using your package manager:
npx trigger.dev@latest update # npm pnpm dlx trigger.dev@latest update # pnpm yarn dlx trigger.dev@latest update # yarn bunx trigger.dev@latest update # bunSelf-hosted users: update your Docker image to ghcr.io/triggerdotdev/trigger.dev:v4.5.10.
Original source - Aug 7, 2026
- Date parsed from source:Aug 7, 2026
- First seen by Releasebot:Aug 8, 2026
trigger.dev v4.5.10
Trigger.dev releases v4.5.10 with stronger task batching, debounce and API key permissions, plus faster and more reliable run handling. It also adds MCP region selection, refreshed dark theme defaults, and a broad set of self-hosted, dashboard, and stability improvements.
trigger.dev v4.5.10
Upgrade
npx trigger.dev@latest update # npm pnpm dlx trigger.dev@latest update # pnpm yarn dlx trigger.dev@latest update # yarn bunx trigger.dev@latest update # bunSelf-hosted Docker image: ghcr.io/triggerdotdev/trigger.dev:v4.5.10
Release notes
Read the full release notes: https://trigger.dev/changelog/v4-5-10
What's changed
Highlights
Allow task-scoped environment API keys to run batch operations for their permitted tasks. The SDK declares the batch's task set before creation, and @trigger.dev/core/v3/apiKeys now exports the additional-key format helper. (#4389)
Improvements
Refresh package builds for TypeScript 7 compatibility while preserving existing runtime entry points. Projects using emitDecoratorMetadata() with TypeScript 7 can install the @typescript/typescript6 compatibility package alongside it; the package remains optional, so installing the Trigger.dev CLI does not install an additional compiler. (#4318)
AgentChat.reconnect() now settles promptly when reconnecting to an idle chat instead of holding the connection open for the full long-poll window. Also upgrades the S2 streamstore client to 0.25 and moves realtime streams to S2's current hosts. (#4349)
You can now choose the region a run executes in when triggering a task through the MCP server. (#4439)
Transient connection errors when a run starts are now retried for longer, so a brief connectivity blip no longer sends the run back through the queue and delays its first attempt. (#4441)
debounce now works when you pass an array of items to batchTrigger or batchTriggerAndWait, and when you trigger from useTaskTrigger. Previously the option was accepted by the types and dropped before the request was sent, so every trigger created its own run instead of collapsing onto the debounce key. (#4520)
await myTask.batchTrigger([ { payload: { id: "a" }, options: { debounce: { key: "same-key", delay: "30s" } }, }, { payload: { id: "b" }, options: { debounce: { key: "same-key", delay: "30s" } }, }, ]);The streaming (async iterable) forms of the batch calls were already forwarding debounce correctly.
Bug fixes
Fix a chunk occasionally dropped when a chat.agent run takes over from the warm first turn. The realtime stream writer now reports the inclusive last-written position as the resume cursor, so the agent's first record after the handover is no longer skipped. (#4349)
Fix a preloaded chat.agent run dropping an in-flight message when it retries after an out-of-memory error. The message being processed when the run hit the OOM is now recovered and re-run on the retry, instead of being skipped while the run waited for a new message. (#4349)
Server changes
These changes affect the self-hosted Docker image and Trigger.dev Cloud:
Self-hosted deployments can now create multiple full-access API keys for each environment. (#4390)
Short links like /_/apikeys now take you straight to that page in your current project and environment, so you no longer need the full URL with your org, project and environment in it. (#4523)
The dashboard gets a refreshed Dark theme as its new default look. On the account page you can switch to Light, System preference (follows your OS), or the original Classic look, and fine-tune the new themes with a contrast slider. (#4206)
Additional environment API keys can now create scoped public access tokens. (#4390)
Additional environment API keys can authenticate API requests using their configured permissions, with revoked and expired keys rejected. Batch responses use server-issued public access tokens so additional keys never need the environment signing secret. (#4389)
Self-hosted Kubernetes deployments can now add tolerations to run pods, so runs are allowed onto tainted nodes. An invalid toleration now stops the supervisor at startup instead of failing every run pod, so check existing values before upgrading. (#4491)
Lower background database load during deployments and dev sessions for projects that use declarative schedules. (#4522)
Triggering a task now does one fewer database write, so runs reach the queue slightly faster. (#4419)
Creating or updating a schedule, and deploying a project with declarative schedules, is faster in long-lived projects with many deploys. (#4518)
Admins opening an impersonation link from outside the dashboard now get a confirmation page naming the organization and destination instead of being bounced back, and while impersonating they can switch to "View as user" to see the dashboard exactly as that user sees it, with the admin-only UI and the impersonation highlight both hidden. Stopping impersonation is still one click away in the account menu. (#4421)
Browser tabs now name the page you're on, and the run, task or queue when you're looking at one, instead of all reading "Trigger.dev". (#4517)
Allow the database connection pool and connect timeouts to be tuned separately for each database's writer and read replica, falling back to the shared defaults when unset. (#4515)
In-app feedback and add-on/quota requests are now recorded with more account context for the support team. (#4368)
Self-hosted Kubernetes deployments now measure running-task count more accurately when deciding whether to pause pulling new work, so the safeguard engages closer to its configured thresholds. (#4442)
The Queues pages now open on the last hour instead of the last day, and remember the time period you picked when you navigate between queues or reload the page. (#4438)
Speeds up resolving the latest worker version and deployment for an environment, removing an occasional stall when triggering runs in projects that have accumulated many deployed versions. (#4452)
API rate limits now apply per environment, so creating extra API keys no longer increases how many requests an environment can make. (#4508)
When the capacity signal drops out, the last decision is held for a grace period rather than released. (#4444)
Batch triggers no longer fail to start their runs when an environment is under heavy API load. If a batch still can't finish being created, batchTriggerAndWait now fails with an error instead of leaving the parent run waiting forever, and the batches page says so rather than reporting that it resumed. (#4397)
Triggering a run with a very large priority no longer fails. The priority is now capped to the highest supported value instead of erroring out. (#4512)
Fix debounce doing nothing when the delay was longer than an hour, which made every trigger create its own run instead of collapsing onto the debounce key. Debounced runs now keep being pushed back for as long as triggers keep arriving, so set maxDelay when the work has to happen eventually, and settings that could never debounce are rejected rather than silently ignored. (#4521)
Honor the configured database connection timeout so brief connection spikes no longer surface as spurious "can't reach database server" errors. (#4513)
Fixed a rare case where a single run or span carrying data that could not be ingested would make other runs or trace events in the same batch go missing from the runs list, traces, and logs. Now the rest of the batch is always kept: an affected run still appears with its status (only its un-ingestable output is dropped), and an affected trace event or payload is skipped instead of taking down everything around it. (#4358)
Fix the sidebar "Help & Feedback → Contact us" form sometimes not sending your message. It now sends reliably every time. (#4445)
Requests spanning multiple tasks now require permission for every requested task instead of accepting permission for only one task. (#4389)
The four charts at the top of the Queues page now always cover the whole environment, so paging through or re-sorting your queues no longer changes them. The scheduling delay chart also leaves a gap where no runs started, instead of dropping to zero. (#4486)
Reject alert webhook destinations in reserved benchmarking IP ranges. (#4528)
Fix the health report failing with an internal error when requested through the API. (#4488)
Triggering a task no longer intermittently fails to create the run when a database write briefly stalls. (#4514)
Team members who join an organization through single sign-on or directory sync now get their own development environment for every project, so the dashboard's dev view and trigger dev become available to them without an admin having to set anything up. Members who were already missing one are repaired the next time their membership is synced from your identity provider. (#4426)
Fixed a rare error where triggering a task could fail if the idempotency key or debounce key contained an invalid null character. The character is now removed automatically and the run is created as normal. (#4527)
All packages: v4.5.10
@trigger.dev/build, @trigger.dev/core, @trigger.dev/python, @trigger.dev/react-hooks, @trigger.dev/redis-worker, @trigger.dev/rsc, @trigger.dev/schema-to-json, @trigger.dev/sdk, trigger.dev
Contributors
Eric Allam, Chris Arderne, @nicktrn, Matt Aitken, claude[bot], Katia Bulatova, Wes Mason, James Ritchie, @isshaddad, github-actions[bot], Oskar Otwinowski
Full changelog: v4.5.9...v4.5.10
Original source - Aug 7, 2026
- Date parsed from source:Aug 7, 2026
- First seen by Releasebot:Aug 8, 2026
v.docker.4.5.10
Trigger.dev releases v4.5.10 with a routine update.
chore: release v4.5.10 (#4440)
Original source - Aug 7, 2026
- Date parsed from source:Aug 7, 2026
- First seen by Releasebot:Aug 8, 2026
re2-test-supervisor-main-c526528: feat(webapp,database): bound Prisma list filter arity (#4480)
Trigger.dev improves Prisma list filters by introducing boundedIn() padding, cutting prepared statement churn for in and notIn queries and avoiding bind-parameter limits. New oxlint rules enforce the helper across existing call sites, with end-to-end verification showing no regressions.
Summary
Prisma expands in / notIn into one bind parameter per element, so every distinct list length is a separate prepared statement. Where the length tracks data volume (a batch size, a run-graph fan-out, a prior query's id set) one call site can mint hundreds of them. Each is used about once, but inserting it evicts an entry that was being reused, so the cost lands on unrelated queries sharing the pooler's statement cache. An unbounded list also risks the 65535 bind-parameter ceiling.
boundedIn() pads a filter list to the next power of two by repeating its last element. IN and NOT IN ignore duplicates, so results are unchanged, and a call site drops from one statement per length to at most log2(cap). Applied to all existing sites.
Enforcement
Two oxlint rules require the helper: a list filter must be an inline array literal or a boundedIn() call.
The first covers filters reached through where / having / cursor, and deliberately never descends into data, create, update, set or equals. A key named in in those positions is user data, not a predicate, and rewriting it would corrupt what gets stored or compared.
The second covers bare filter objects passed to where-building helpers, which the first cannot see. It found five sites in the run-graph batch loaders that were otherwise invisible.
Both rules follow filters through the shapes they are actually written in: conditional expressions, logical-and objects, spread-conditional properties, computed keys, and call arguments. An array literal only counts as fixed-arity when nothing spreads into it, since [...new Set(ids)] has a runtime length. Twelve sites were hidden behind those shapes until the rules handled them.
Scoped to in and notIn. The scalar-list filters hasSome and hasEvery compile to && $1 and @> $1, passing the whole array as a single bind parameter, so their arity never reaches the statement text and there is nothing to bound.
Both rules are error, so new call sites fail CI. That ratchet has already caught four sites added by other PRs while this one was in review.
Notes
boundedIn pads by repeating rather than with null: x NOT IN (a, b, NULL) is never true, so null-padding a notIn filter would silently return no rows. Lists above 32768 are returned unchanged so padding can never push a query past the parameter limit.
Route modules reach the helper through ~/db.server rather than importing the database barrel directly, since a value import of that barrel into a module that also exports a React component is only safe while dead-code elimination prunes it.
Measured on a local rig: 300 distinct list lengths produce 300 prepared statements unpadded, 10 padded. Verified end-to-end against a local stack with the full task-suite sweep, which surfaced no regressions.
Original source - Aug 7, 2026
- Date parsed from source:Aug 7, 2026
- First seen by Releasebot:Aug 8, 2026
re2-prod-supervisor-heatwave-dualwrite: feat(webapp,database): bound Prisma list filter arity (#4480)
Trigger.dev adds boundedIn and new oxlint rules to pad in/notIn filters, cut prepared statement churn, and avoid bind-parameter limits across existing call sites.
Summary
Prisma expands in / notIn into one bind parameter per element, so every distinct list length is a separate prepared statement. Where the length tracks data volume (a batch size, a run-graph fan-out, a prior query's id set) one call site can mint hundreds of them. Each is used about once, but inserting it evicts an entry that was being reused, so the cost lands on unrelated queries sharing the pooler's statement cache. An unbounded list also risks the 65535 bind-parameter ceiling.
boundedIn() pads a filter list to the next power of two by repeating its last element.
IN and NOT IN ignore duplicates, so results are unchanged, and a call site drops from one statement per length to at most log2(cap). Applied to all existing sites.
Enforcement
Two oxlint rules require the helper: a list filter must be an inline array literal or a boundedIn() call.
The first covers filters reached through where / having / cursor, and deliberately never descends into data, create, update, set or equals. A key named in in those positions is user data, not a predicate, and rewriting it would corrupt what gets stored or compared.
The second covers bare filter objects passed to where-building helpers, which the first cannot see. It found five sites in the run-graph batch loaders that were otherwise invisible.
Both rules follow filters through the shapes they are actually written in: conditional expressions, logical-and objects, spread-conditional properties, computed keys, and call arguments. An array literal only counts as fixed-arity when nothing spreads into it, since [...new Set(ids)] has a runtime length. Twelve sites were hidden behind those shapes until the rules handled them.
Scoped to in and notIn. The scalar-list filters hasSome and hasEvery compile to && $1 and @> $1, passing the whole array as a single bind parameter, so their arity never reaches the statement text and there is nothing to bound.
Both rules are error, so new call sites fail CI. That ratchet has already caught four sites added by other PRs while this one was in review.
Notes
boundedIn pads by repeating rather than with null: x NOT IN (a, b, NULL) is never true, so null-padding a notIn filter would silently return no rows. Lists above 32768 are returned unchanged so padding can never push a query past the parameter limit.
Route modules reach the helper through ~/db.server rather than importing the database barrel directly, since a value import of that barrel into a module that also exports a React component is only safe while dead-code elimination prunes it.
Measured on a local rig: 300 distinct list lengths produce 300 prepared statements unpadded, 10 padded. Verified end-to-end against a local stack with the full task-suite sweep, which surfaced no regressions.
Original source - Aug 7, 2026
- Date parsed from source:Aug 7, 2026
- First seen by Releasebot:Aug 8, 2026
- Aug 4, 2026
- Date parsed from source:Aug 4, 2026
- First seen by Releasebot:Aug 6, 2026
re2-test-supervisor-cancel-on-continue
Trigger.dev fixes core cancel requests by adding a timeout safeguard.
fix(core): bound the new cancel request with a timeout
Original source - Jul 31, 2026
- Date parsed from source:Jul 31, 2026
- First seen by Releasebot:Aug 13, 2026
LLM observability, built in
Trigger.dev adds AI observability for Vercel AI SDK calls, with every LLM request recorded for model, cost, tokens, latency, and trace details. Teams can inspect spans, query spend across workloads, and link prompts for deeper debugging and billing insight.
Every LLM call your tasks make is recorded with its model, cost, tokens, and latency. See the whole workload on a dashboard, open any single call in the run trace, and query all of it yourself.
You could always see what a task did. Now you can see what it spent. One flag, nothing to install, and every LLM call shows up timed and priced, from a single span up to your whole AI bill.
Turn it on
Set
experimental_telemetryon any Vercel AI SDK call. Nothing to install.import { task } from "@trigger.dev/sdk"; import { generateText } from "ai"; import { anthropic } from "@ai-sdk/anthropic"; export const summarize = task({ id: "summarize", run: async (payload: { text: string }) => { const { text } = await generateText({ model: anthropic("claude-sonnet-4-5"), prompt: payload.text, experimental_telemetry: { isEnabled: true }, }); return text; }, });It works the same on
generateText,streamText, andgenerateObject. Every call becomes its own span.The AI SDK is just one way to emit those spans. They follow the OpenTelemetry GenAI semantic conventions, and that's the whole contract: any span with the standard
gen_aiattributes gets cost data attached and the same trace and dashboard observability, whatever produced it.See the whole workload
The dashboard at the top rolls up every recorded call across your project: cost over time, cost by model, total tokens, latency. The shape of your AI spend, without instrumenting anything.
It runs on TRQL, our SQL-style query language for your Trigger.dev data. It reads LLM usage alongside your runs and metrics tables, so cost per task, tokens by model, and latency trends are one query. Or ask in plain English on the Query page and it writes the query for you:
Show me the 10 most expensive tasks over the last 7 daysOpen any single call
The dashboard tells you what you spent. The trace tells you why. Open a model span and the AI inspector breaks the call down:
- Overview: model, provider, prompt/completion/total token counts, cost, and an input/output preview
- Messages: the full thread sent to the model, system prompt and tool results included
- Tools: the tool definitions you passed and every tool call the model made, with arguments
One AI generation span, every tab: the model, tokens and cost; the full message thread; the tools you passed; and the linked prompt version.
So when a call runs slow or a bill jumps, you open the span and see which model ran, what went in, and what came back. No guessing which of five
generateTextcalls in a task was the expensive one.Link a call to its prompt
If you manage prompts with Prompts, resolve one and spread
toAISDKTelemetry()into the call. The span then carries the prompt too, and you can tag it with your own attributes:const resolved = await summarizePrompt.resolve({ tone: "brief" }); const result = await generateText({ model: anthropic("claude-sonnet-4-5"), prompt: resolved.text, ...resolved.toAISDKTelemetry({ "task.type": "summarization", "customer.tier": "enterprise", }), });A fourth Prompt tab appears on the span with the linked template, its version, and the input variables, so a bad output traces straight back to the prompt that caused it.
Chat agents get it too
chat.agentreports its model calls through the same telemetry.chat.toStreamTextOptions()folds it in with the stored prompt, model, and config, so once you set a system prompt withchat.prompt.set(), every turn shows up in the trace with no extra wiring.Get started
Add
Original sourceexperimental_telemetry: { isEnabled: true }to a task, trigger a run, and the whole workload starts filling in. Custom metadata and prompt linking are in the AI observability docs. - Jul 31, 2026
- Date parsed from source:Jul 31, 2026
- First seen by Releasebot:Aug 8, 2026
re2-test-supervisor-podcount-list
Trigger.dev updates Supervisor docs to describe pod count as an estimate instead of an exact number.
docs(supervisor): describe the pod count as an estimate, not exact
Original source
Curated by the Releasebot team
Releasebot is an aggregator of official release notes from hundreds of software vendors and thousands of sources.
Our editorial process involves the manual review and audit of release notes procured with the help of automated systems.