In Review

Planned

In Progress

Completed

Main Roadmap

You can <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://trigger.dev/docs/open-source-self-hosting">fully self-host Trigger.dev</a>.This is a really good option in lots of situations if you&rsquo;re experienced with setting up and managing infrastructure.Another option would be if we offered self-hosted workers. You would host them inside your own cloud account (or on-prem) and they would connect to the <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="http://Trigger.dev">Trigger.dev</a> cloud.The pricing model for this is TBD, but it would probably be a combination of a cost per connected worker server and an invocation cost that is higher than the managed worker one.

Self-hosted workers

mattaitken

It&rsquo;s currently difficult to diagnose performance issues. It would be useful to have graphs on the run page. This would also make it possible to find memory leaks.Currently you have to use Node functions to log out the memory:<pre><code>const memory = process.memoryUsage();
logger.log(&ldquo;Memory usage&rdquo;, memory);</code></pre>

CPU and Memory graphs on the run page

Please reintroduce the events feature in V3, similar to what was available in V2. <ul><li>Trigger with an event name and payload</li><li>A task can subscribe to a named event with a filter (it will only create a run if the filter matches)</li><li>A single event can trigger many tasks if it matches many</li></ul>

Event triggers

An Anonymous User

Currently all our machines are evenly balanced between CPU or RAM (or some of them have double the RAM than vCPU).We could add a set of CPU-optimized machines (e.g. 1vCPU + 0.25GB RAM) and memory optimized machines (e.g. 0.25vCPU + 1GB RAM). What do people think? What combos would be useful?

CPU and memory optimised machines

This feature will follow on from our <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://trigger.dev/changelog/python-extension">Python extension</a> to allow full Python support in Trigger.dev.

Full Python support

James

Would be cool to <ul><li>unit test: have a way to unit test specific tasks and mock other other tasks (that are used within the tested task)</li><li>e2e test: have a way to spin up a instance for e2e tests locally (programmatically for jest/bun testing) and tear it down after tests ran</li></ul>

E2E and unit testing utilities

Workers in Asia will reduce the latency when accessing your regional resources from your tasks.

&#12450;&#12472;&#12450;&#12398;&#12527;&#12540;&#12459;&#12540;&#12399;&#12289;&#12479;&#12473;&#12463;&#12363;&#12425;&#22320;&#22495;&#12398;&#12522;&#12477;&#12540;&#12473;&#12395;&#12450;&#12463;&#12475;&#12473;&#12377;&#12427;&#38555;&#12398;&#12524;&#12452;&#12486;&#12531;&#12471;&#12540;&#12434;&#28187;&#12425;&#12377;&#12371;&#12392;&#12364;&#12391;&#12365;&#12414;&#12377;&#12290;

&#12450;&#12472;&#12450;&#21172;&#20685;&#32773;&#22320;&#22495;

Asia worker region

Support for logs to be sent from <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="http://Trigger.dev">Trigger.dev</a> to 1+ other destinations. We would probably start with an HTTP POST request with a JSON body, similar to <a target="" rel="noopener noreferrer nofollow" class="link" href="https://supabase.com/docs/guides/platform/log-drains">how Supabase do this</a>.

Support log drains

<blockquote><a target="_blank" rel="noopener noreferrer nofollow" class="link" href="http://Trigger.dev">Trigger.dev</a> currently does not support &ldquo;offline&rdquo; dev mode, where you can run tasks without an internet connection. <a target="_blank" rel="noreferrer" class="link" href="https://feedback.trigger.dev/">Please let us know</a> if this is a feature you want/need.</blockquote>This would be great to have, and would compliment a Supabase/Next.js stack nicely. I am online 99% of the time but it would be great to develop fully locally in that last 1% where I&rsquo;m at an airport or in a cafe with bad wifi.

Run Trigger.dev in dev mode offline

Zachary Keener

I recently tried to find a run by filtering on a value of the payload but I couldn&rsquo;t figure out how. It would be great to be able to do something like &ldquo;get be runs where task = X and payload.customerId = Y&rdquo;

Filter runs by payload value

Rich Turnbull

In the dashboard you each task would have a URL for each of your environments.Then you can use this URL in 3rd party products. Any data in the body of the request to that URL would come through to the task as the payload.

Incoming webhook trigger

We currently support setting a <code>concurrencyLimit</code> on a task, or on a queue that you create. This can also be used with a <code>concurrencyKey</code> to have per-user queues: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://trigger.dev/docs/queue-concurrency">https://trigger.dev/docs/queue-concurrency</a>Sometimes instead of concurrency you want to limit using a rate. For example, 10/minute, 1/second.This is especially useful when using APIs that have rate limits.We should support this with a per-tenant key like we do for concurrency.

Rate Limiting / throttling

Simulate CPU and Memory Limits on Dev Environments

Conner Aldrich

When you trigger a prod or staging run in the Trigger.dev cloud it takes 3 seconds on average for the machine to start up and your code to start executing. This same slowness happens when a run resumes, like after using <code>wait.for</code> if the delay is above a threshold when we shut the machine down.They take this long because we're using Kubernetes for our cluster and a new pod takes a while to come up.We're switching to using MicroVMs for the cloud machines. Our target is to get the p95 for starts and resumes to under 500ms.

Make cold starts faster

Linear

I would like to be able to create multiple API keys and configure access permissions on a per-endpoint or per-task basis.Currently, there is only one API key per project, but from a security perspective, it would be much better to be able to create and distribute API keys with permissions limited to specific tasks only when integrating with external systems via API.This feature would allow us to follow the principle of least privilege by granting minimal necessary access rights to each external integration, thereby improving overall security posture.

Multiple API Keys with Granular Access Control for Endpoints and Tasks

Wakamatsu Kouta

When you call the SDK functions, there&rsquo;s an extra param which allows you to pass request options. We should add the ability to pass an access token and branch here.

Add ability to specify access token and preview branch in trigger options

Eric Allam

Allow organizations to configure SSO settings at the org level, including selecting a single SSO provider, restricting access to specific email domains. This gives organizations more control over authentication methods and access policies.

Organization-level SSO configuration with domain restrictions

Iss Haddad

The <code>syncEnvVars</code> build extension only syncs plain environment variables, so sensitive values (e.g. database URLs) show up revealable in the dashboard. Add per-variable secret support (e.g. <code>{ name, value, secret: true }</code>) so auto-synced vars can be stored as secrets like manually created ones.

Support marking variables as secrets via syncEnvVars

Right now you can have a great experience with <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="http://Trigger.dev">Trigger.dev</a> and Vercel by using our <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://trigger.dev/changelog/preview-branches">Preview branches</a> and our <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://trigger.dev/docs/config/extensions/syncEnvVars#syncvercelenvvars">syncVercelEnvVars extension</a>.&mdash;An official Vercel integration would do those two things but with less setup:<ol><li>Sync environment variables from Vercel to Trigger.dev.</li><li>Create preview branches on Trigger.dev.</li></ol>

Vercel integration

Easily get realtime data from your task runs to your frontend (or backend).This would include basic stuff:<ol><li>Run status</li><li>Run payload</li><li>Run output</li></ol>But also more advanced use cases:<ol><li>Being able to send structured (and typed) data from inside your run functions to your frontend.</li><li>Being able to stream data from inside your run function to your frontend.</li><li>Being able to send React Server Components from your run function to you frontend. Maybe. We're trying to figure out if this is possible.</li></ol>

Realtime notifications

To access some databases, and other services, you need to provide them with an IP whitelist. 
For this to work well we need to have static IPs, potentially a per customer IP address.

&#1063;&#1090;&#1086;&#1073;&#1099; &#1087;&#1086;&#1083;&#1091;&#1095;&#1080;&#1090;&#1100; &#1076;&#1086;&#1089;&#1090;&#1091;&#1087; &#1082; &#1085;&#1077;&#1082;&#1086;&#1090;&#1086;&#1088;&#1099;&#1084; &#1073;&#1072;&#1079;&#1072;&#1084; &#1076;&#1072;&#1085;&#1085;&#1099;&#1093; &#1080; &#1076;&#1088;&#1091;&#1075;&#1080;&#1084; &#1089;&#1083;&#1091;&#1078;&#1073;&#1072;&#1084;, &#1085;&#1077;&#1086;&#1073;&#1093;&#1086;&#1076;&#1080;&#1084;&#1086; &#1087;&#1088;&#1077;&#1076;&#1086;&#1089;&#1090;&#1072;&#1074;&#1080;&#1090;&#1100; &#1080;&#1084; &#1073;&#1077;&#1083;&#1099;&#1081; &#1089;&#1087;&#1080;&#1089;&#1086;&#1082; IP-&#1072;&#1076;&#1088;&#1077;&#1089;&#1086;&#1074;. 
&#1063;&#1090;&#1086;&#1073;&#1099; &#1101;&#1090;&#1086; &#1093;&#1086;&#1088;&#1086;&#1096;&#1086; &#1088;&#1072;&#1073;&#1086;&#1090;&#1072;&#1083;&#1086;, &#1085;&#1072;&#1084; &#1085;&#1091;&#1078;&#1085;&#1099; &#1089;&#1090;&#1072;&#1090;&#1080;&#1095;&#1077;&#1089;&#1082;&#1080;&#1077; IP-&#1072;&#1076;&#1088;&#1077;&#1089;&#1072;, &#1074;&#1086;&#1079;&#1084;&#1086;&#1078;&#1085;&#1086;, IP-&#1072;&#1076;&#1088;&#1077;&#1089; &#1082;&#1072;&#1078;&#1076;&#1086;&#1075;&#1086; &#1082;&#1083;&#1080;&#1077;&#1085;&#1090;&#1072;.

&#1057;&#1090;&#1072;&#1090;&#1080;&#1095;&#1077;&#1089;&#1082;&#1080;&#1077; IP-&#1072;&#1076;&#1088;&#1077;&#1089;&#1072;

&#272;&#7875; truy c&#7853;p m&#7897;t s&#7889; c&#417; s&#7903; d&#7919; li&#7879;u v&agrave; c&aacute;c d&#7883;ch v&#7909; kh&aacute;c, b&#7841;n c&#7847;n cung c&#7845;p cho h&#7885; danh s&aacute;ch tr&#7855;ng IP. 
&#272;&#7875; &#273;&#7843;m b&#7843;o ho&#7841;t &#273;&#7897;ng hi&#7879;u qu&#7843;, ch&uacute;ng ta c&#7847;n s&#7917; d&#7909;ng &#273;&#7883;a ch&#7881; IP t&#297;nh, c&oacute; th&#7875; l&agrave; m&#7897;t &#273;&#7883;a ch&#7881; IP ri&ecirc;ng cho t&#7915;ng kh&aacute;ch h&agrave;ng.

&#272;&#7883;a ch&#7881; IP t&#297;nh

Static IP addresses

Inside your run function it would be useful to be able to pause execution until something external has happened.
We had a feature called "wait for event" in v2 that allowed you to do this. You could then send an event from your own code and the run would continue where it left off.
An example might be for an application process where the application needs to go through an approval step e.g. an AML check.
There would be a timeout of how long it would wait, with a default.

Wait for token

At the moment you can't delete a v3 project. You can rename them from "Project settings", but they can't be deleted.

Delete a v3 project

Currently, if your database of some of your services are not accessible to the public internet you can&rsquo;t access them inside your <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="http://Trigger.dev">Trigger.dev</a> tasks (unless you self-host the entire platform). There are many ways we could solve this. One obvious solution is for us to provide a Bridge Connector that you can run inside your cluster and it would only allow access from your <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="http://Trigger.dev">Trigger.dev</a> tasks. We use a tool like this to access our restricted database outside of AWS. It would be very useful if you can share the kind of private resources you need to use in <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="http://Trigger.dev">Trigger.dev</a> and what solutions you would be happy with!

VPC peering

HIPAA compliance

You can only provide 100 items in <code>batchTrigger</code> and <code>batchTriggerAndWait</code> at the moment. if you want to batch more items than this you need to call it multiple times, creating more than one batch.
We should add a way to create larger batches. It would involve multiple API calls and we'd probably want to make that explicit. For example, you would create a batch, add items to it and then finalize it.

Support more than 100 items in `batchTrigger` at once

Right now, multiple trigger dev instances for the same project share one queue, so any instance can run any task and they end up &ldquo;stealing&rdquo; each other&rsquo;s work. The ask is to support something like preview branches, but for the dev environment: separate dev sessions (e.g. a session id or &ldquo;dev branch&rdquo;) so each local instance only runs tasks triggered from that same session. That would let you run several work trees or app copies in parallel (e.g. with Codex/Claude) without tasks from one ending up running in another.

I &oslash;jeblikket deler flere trigger-udviklingsinstanser for det samme projekt &eacute;n k&oslash;, s&aring; enhver instans kan k&oslash;re enhver opgave, hvilket betyder, at de ender med at &raquo;stj&aelig;le&laquo; hinandens arbejde. &Oslash;nsket er at underst&oslash;tte noget i stil med preview-grene, men for udviklingsmilj&oslash;et: separate udviklingssessioner (f.eks. et sessions-id eller en "udviklingsgren"), s&aring; hver lokal instans kun k&oslash;rer opgaver, der udl&oslash;ses fra den samme session. Det ville give mulighed for at k&oslash;re flere arbejdstr&aelig;er eller app-kopier parallelt (f.eks. med Codex/Claude) uden at opgaver fra den ene ender med at k&oslash;re i den anden.

Isolerede udviklingssessioner til flere lokale trigger-udviklingsinstanser

Isolated dev sessions for multiple local trigger dev instances

You can view logs per-run at the moment, but not across all runs. It would be very useful to have search and filtering across all logs with full text search.This will require us to change where we store logs to Clickhouse (probably) so we can do fast filtering/search.