Trigger.dev v4.7.0 moves concurrency limits from queues to tasks

Trigger.dev, the background-job platform for developers, has shipped v4.7.0 with a reworked way to limit how many task runs execute at once. According to the company's changelog, dated October 1, 2026, concurrency used to be a property of the queue and is now its own option on the task. The older queue-level concurrencyLimit setting keeps working but is deprecated, the company says.

The main change is for multi-tenant apps. Trigger.dev says that when runs were triggered with a concurrencyKey, the single limit became a per-key cap, with no way to also cap the task as a whole, so ten active tenants under a limit of one could run ten jobs at once. A task can now set perKey and total together: for example one run per tenant and at most ten across all tenants. The company says total covers every run of the task, with or without a key.

Limits can also be shared. Per the changelog, a named limit declared with concurrencyLimit() can be given to several tasks, each of which keeps its own queue and ordering, rather than being merged onto one queue. A task can hold up to two named limits plus one inline limit, and a run starts only when every limit it holds has capacity.

A new concurrencyLimits namespace lets developers list and retrieve limits with live running and queued counts, override or reset bounds, and pause or resume a limit, the changelog says.

What is confirmed and what is not: everything above comes from Trigger.dev's own release notes. The company says its Cloud service enforces the new limits today, while self-hosted installations need the v4.7.0 image, and older servers accept the option without enforcing it. That last point matters for self-hosters, because a limit that is silently ignored could allow more concurrency than intended. We have not tested the behavior, and we did not find an independent report on the release.

Why it matters: teams that rate-limit calls to a shared API, or want to stop one tenant from crowding out others, previously had to combine queues to get a shared limit. The new model separates the two ideas, if it works as described.

This is a single-source item based on the vendor's changelog.

Revised 16 October 2026: Guth re-read the original sources and rewrote this article. The earlier version remains available as revision 1.