Roadmap

Have something to say?

Tell Trigger.dev how they could make the product more useful to you.

Planned

Realtime notifications

Easily get realtime data from your task runs to your frontend (or backend). This would include basic stuff: Run status Run payload Run output But also more advanced use cases: Being able to send structured (and typed) data from inside your run functions to your frontend. Being able to stream data from inside your run function to your frontend. 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.

Linear About 2 months ago

Continue after event ("wait for event")

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.

Linear 4 months ago

1

EU located workers

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 Trigger.dev 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.

mattaitken About 2 months ago

2

In Progress

Make deploying (bundling) much easier

There are two things that aren't great about deploying at the moment: You can end up having to add a lot packages to dependencesToBundle. You need to match the versions between the SDK and the CLI. 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.

Linear About 2 months ago

3

Support more than 100 items in `batchTrigger` at once

You can only provide 100 items in batchTrigger and batchTriggerAndWait 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.

Linear 3 months ago

Planned

Support for binaries

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: You can use ffmpeg currently using the ffmpeg-installer package. You can use Puppeteer by using puppeteer.connect with browserWSEndpoint. We recommend using it with BrightData.

Linear 2 months ago

Support access to internal services and databases

Currently, if your database of some of your services are not accessible to the public internet you can’t access them inside your Trigger.dev 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 Trigger.dev 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 Trigger.dev and what solutions you would be happy with!

mattaitken About 1 month ago

1

In Progress

Make runs start/resume faster (using Firecracker)

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 wait.for 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.

Linear 3 months ago

4