Planned
Vercel integration
This could do two things: Sync environment variables from Vercel to Trigger.dev. Create preview deployment on Trigger.dev for each preview deployment on Vercel. We need to figure out the details of how preview deployments would work with API keys, environment variables and filtering.
Linear 4 months ago
Planned
Vercel integration
This could do two things: Sync environment variables from Vercel to Trigger.dev. Create preview deployment on Trigger.dev for each preview deployment on Vercel. We need to figure out the details of how preview deployments would work with API keys, environment variables and filtering.
Linear 4 months ago
Delete a v3 project
At the moment you can't delete a v3 project. You can rename them from "Project settings", but they can't be deleted.
Linear 6 months ago
Delete a v3 project
At the moment you can't delete a v3 project. You can rename them from "Project settings", but they can't be deleted.
Linear 6 months ago
Python support
We’ve had a few requests for Python support in our Github issues and wanted to add it here as well: https://github.com/triggerdotdev/trigger.dev/issues/862
maverickdotdev About 1 month ago
Python support
We’ve had a few requests for Python support in our Github issues and wanted to add it here as well: https://github.com/triggerdotdev/trigger.dev/issues/862
maverickdotdev About 1 month ago
In Progress
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 6 months ago
In Progress
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 6 months ago
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 4 months ago
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 4 months ago
Incoming webhook trigger
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.
mattaitken 2 months ago
Incoming webhook trigger
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.
mattaitken 2 months ago
Rate Limiting on V3
We currently support setting a concurrencyLimit on a task, or on a queue that you create. This can also be used with a concurrencyKey to have per-user queues: https://trigger.dev/docs/queue-concurrency 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.
An Anonymous User 4 months ago
Rate Limiting on V3
We currently support setting a concurrencyLimit on a task, or on a queue that you create. This can also be used with a concurrencyKey to have per-user queues: https://trigger.dev/docs/queue-concurrency 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.
An Anonymous User 4 months ago
Self-hosted workers
You can fully self-host Trigger.dev. 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 Trigger.dev cloud.
mattaitken 2 months ago
Self-hosted workers
You can fully self-host Trigger.dev. 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 Trigger.dev cloud.
mattaitken 2 months ago
Static IP addresses
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.
Linear 6 months ago
Static IP addresses
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.
Linear 6 months ago
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 5 months ago
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 5 months ago
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 5 months ago
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 5 months ago
Event triggers
Please reintroduce the events feature in V3, similar to what was available in V2. Trigger with an event name and payload A task can subscribe to a named event with a filter (it will only create a run if the filter matches) A single event can trigger many tasks if it matches many
An Anonymous User 3 months ago
Event triggers
Please reintroduce the events feature in V3, similar to what was available in V2. Trigger with an event name and payload A task can subscribe to a named event with a filter (it will only create a run if the filter matches) A single event can trigger many tasks if it matches many
An Anonymous User 3 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 3 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 3 months ago
Planned
More environments
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.
mattaitken 4 months ago
Planned
More environments
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.
mattaitken 4 months ago
E2E and unit testing utilities
Would be cool to unit test: have a way to unit test specific tasks and mock other other tasks (that are used within the tested task) 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
An Anonymous User 4 months ago
E2E and unit testing utilities
Would be cool to unit test: have a way to unit test specific tasks and mock other other tasks (that are used within the tested task) 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
An Anonymous User 4 months ago
Filter by run type (schedule/task) or hide schedule runs
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.
Luca D'Alessandro 4 months ago
Filter by run type (schedule/task) or hide schedule runs
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.
Luca D'Alessandro 4 months ago
Ability to "pause" a task from the dashboard
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.
Linear 6 months ago
Ability to "pause" a task from the dashboard
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.
Linear 6 months ago