In Review

Planned

In Progress

Completed

Main Roadmap

We’ve had a few requests for Python support in our Github issues and wanted to add it here as well: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://github.com/triggerdotdev/trigger.dev/issues/862">https://github.com/triggerdotdev/trigger.dev/issues/862</a>

Python support

maverickdotdev

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

Linear

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.

Static IP addresses

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

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

It would be awesome so that we could also be able of updating the payload when rescheduling a run (runs with “DELAYED” status). Doing something like:<pre><code>const handle = await runs.reschedule("run_1234", { delay: new Date("2024-06-29T20:45:56.340Z"), payload: { foo: "bar" } });</code></pre>API endpoint: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://trigger.dev/docs/management/runs/reschedule">https://trigger.dev/docs/management/runs/reschedule</a>

Allow Reschedule Run to update payload

JA Castro

HIPAA compliance

Defer.run had a button to pause executions for a task.

Runs would get added to the queue but not processed (or assigned to a version) for that task, until it's unpaused.

Ability to "pause" a queue from the dashboard

Currently it is already possible to setup a Webhook in the runner itself, however that leaves room for error at implementation level.As part of this feature request, I am looking for Webhook manager, where a URL is dispatched whenever a task is completed/failed in a similar way of how stripe works or clerk work (attached screenshot).<img src="https://fb-usercontent.fra1.cdn.digitaloceanspaces.com/019460d0-9767-7a1c-b5be-7ec9451df1ce.png" data-width="100%" data-align="left"> In case of error, it is easily trackable in dashboard.

Webhook support

Rostislav Dascal

If one has many CRON schedules that run every X minutes, they will have their Runs section cluttered with a lot of those schedule originated runs. It would be beneficial to either have a toggle to hide those type of tasks or add an additional filter.

Filter by run type (schedule/task) or hide schedule runs

Luca D'Alessandro

This could do two things:
<ol>
<li>Sync environment variables from Vercel to Trigger.dev.</li>
<li>Create preview deployment on Trigger.dev for each preview deployment on Vercel.</li>
</ol>
We need to figure out the details of how preview deployments would work with API keys, environment variables and filtering.

Vercel integration

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

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

mattaitken

The ability to create additional environments that you name, e.g. “Sandbox”.They’d get assigned API keys, you could filter by them, etc.You could clone them from another environment, and delete them.

More environments

Currently, if your database of some of your services are not accessible to the public internet you can’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!

Support access to internal services and databases

It would be useful to be able to specify a priority for a run in a queue.We have a queue that processes data through a machine learning model. It takes about 150s for the model to do its stuff. Occasionally we run this on large amounts old data, but the usual use case is that fresh data uploaded by users and processed ASAP.If we have many tasks in the queue relating to old data, this currently prevents the new data from being processed in a timely manner. It would be great to be able to specify that new data is processed first.Another approach could be to specify that a queue is processed either FIFO or FILO. FILO would solve our use case, though it is less flexible than a priority system.

Run priority

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.

Logs view with global search and filtering

For the cloud product, we should add user-configurable alerts when you cross usage spend thresholds. E.g. when you exceed $10 get an email. You should be able to add multiple thresholds.

Spend alerts

<a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://trigger.dev/docs/v3/wait-for-request">https://trigger.dev/docs/v3/wait-for-request</a>

Wait For Request

Michał Kowalkowski

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.

Continue after event ("wait for event")

I want to be clear what this feature is and isn’t.It would mean having worker machines in a datacenter in the EU. This would allow you to access APIs that are geo-IP restricted. It means the compute would happen in the EU.It does NOT mean that the data for those runs would reside in the EU. The operational and log data for all of <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="http://Trigger.dev">Trigger.dev</a> cloud is located in US-EAST-1. To have European data we would need to have multiple databases and log stores. This isn’t trivial – most companies that do this get you to select when you create your account between EU and US. If you do want this please create a separate feature request.

EU located workers

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 your 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.

Self-hosted workers

When you trigger a prod or staging run in the Trigger.dev cloud it takes 4 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 Firecracker for the cloud machines. Our target is to get the p95 for starts and resumes to under 500ms. The other benefit of Firecracker is that the built-in security model is much better.

Make runs start/resume faster (using Firecracker)

SOC2 compliance

Cancelling in bulk instead 1 by 1 would be really nice

Cancel runs in bulk

Simulate CPU and Memory Limits on Dev Environments

Conner Aldrich

For example i want to stop further execution of a process and i had a tag on it. An Api endpoint to do that would be nice. e.g. Cancel all runs, with status executing or queued with tag process_10

Cancel runs by type and status

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

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

There are two things that aren't great about deploying at the moment:<ol><li>You can end up having to add a lot packages to <code>dependencesToBundle</code>.</li><li>You need to match the versions between the SDK and the CLI.</li></ol>We are changing the way we bundle your code so it works without intervention in more situations. Mainly this means changing to use ESM – we are currently using CJS because of one of our dependencies.We are also going to change to a single package for the CLI and SDK. This means it will be impossible to have version mismatches between them.

Make deploying (bundling) much easier

Some libraries require binaries that are usually installed inside a Docker image. These are particularly useful in background jobs because you want to do things like audio/video processing or browser automation.
Note: 
<ul>
<li>You can use ffmpeg currently using the <code>ffmpeg-installer</code> package.</li>
<li>You can use Puppeteer by using puppeteer.connect with browserWSEndpoint. We recommend using it with BrightData.</li>
</ul>

Support for binaries

Currently you need to have a <code>tsconfig</code> file for our CLI to work and we run a typecheck before running your code.
Should we add support for vanilla JS?

JavaScript support

An optional property on a task (or passed in when triggering) that would fail the task if it exceeds that amount of duration. Should it be clock time from when it starts executing? Or compute time? (e.g. ignore waits)

Support a maximum duration of a run

You can add tags to a run when you <code>trigger()</code> them and/or inside the run function.This allows you to do advanced filtering in the dashboard and with the SDK.Full details here: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://trigger.dev/changelog/run-tags">https://trigger.dev/changelog/run-tags</a>

Ability to add `tags` to a run

Ability to trigger tasks from frontend

In the dashboard you should be able to edit the payload when you use the "Replay" button.
In the modal that pops up to confirm the replay we should show the payload. You could edit it if you wanted to before hitting "Replay".

Replay a run but be able to edit the payload (dashboard)

You can now attach schedules directly to your scheduled tasks. They sync when you run the dev or deploy commands.More info here: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://trigger.dev/changelog/declarative-cron">https://trigger.dev/changelog/declarative-cron</a>And in the docs: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://trigger.dev/docs/v3/tasks-scheduled">https://trigger.dev/docs/v3/tasks-scheduled</a><pre><code>import { logger, schedules } from "@trigger.dev/sdk/v3";

export const checkMetrics = schedules.task({
 id: "check-metrics",
 //6am every day
 cron: "0 6 * * *",
 run: async (payload) =&gt; {
 const formattedTime = payload.timestamp.toLocaleString("en-US");
 logger.log(formattedTime);
 },
});</code></pre>