Planned
Vercel integration
Right now you can have a great experience with Trigger.dev and Vercel by using our Preview branches and our syncVercelEnvVars extension. — An official Vercel integration would do those two things but with less setup: Sync environment variables from Vercel to Trigger.dev. Create preview branches on Trigger.dev.
Linear Over 1 year ago
Planned
Vercel integration
Right now you can have a great experience with Trigger.dev and Vercel by using our Preview branches and our syncVercelEnvVars extension. — An official Vercel integration would do those two things but with less setup: Sync environment variables from Vercel to Trigger.dev. Create preview branches on Trigger.dev.
Linear Over 1 year ago
Planned
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 Over 1 year ago
Planned
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 Over 1 year ago
Self-hosted workers
You can fully self-host Trigger.dev. This is a really good option in lots of situations if you’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 Trigger.dev 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.
mattaitken Over 1 year ago
Self-hosted workers
You can fully self-host Trigger.dev. This is a really good option in lots of situations if you’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 Trigger.dev 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.
mattaitken Over 1 year ago
Planned
Rate Limiting / throttling
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 Over 1 year ago
Planned
Rate Limiting / throttling
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 Over 1 year ago
In Progress
Make cold starts faster
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 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 MicroVMs for the cloud machines. Our target is to get the p95 for starts and resumes to under 500ms.
Linear Over 1 year ago
In Progress
Make cold starts faster
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 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 MicroVMs for the cloud machines. Our target is to get the p95 for starts and resumes to under 500ms.
Linear Over 1 year ago
CPU and Memory graphs on the run page
It’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: const memory = process.memoryUsage(); logger.log(“Memory usage”, memory);
mattaitken About 1 year ago
CPU and Memory graphs on the run page
It’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: const memory = process.memoryUsage(); logger.log(“Memory usage”, memory);
mattaitken About 1 year ago
CPU and memory optimised machines
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?
An Anonymous User Over 1 year ago
CPU and memory optimised machines
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?
An Anonymous User Over 1 year 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 Over 1 year 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 Over 1 year ago
Planned
VPC peering
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 Over 1 year ago
Planned
VPC peering
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 Over 1 year 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 Over 1 year 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 Over 1 year ago
Support log drains
Support for logs to be sent from Trigger.dev to 1+ other destinations. We would probably start with an HTTP POST request with a JSON body, similar to how Supabase do this.
mattaitken Over 1 year ago
Support log drains
Support for logs to be sent from Trigger.dev to 1+ other destinations. We would probably start with an HTTP POST request with a JSON body, similar to how Supabase do this.
mattaitken Over 1 year ago
Planned
Logs view with global search and filtering
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.
mattaitken Over 1 year ago
Planned
Logs view with global search and filtering
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.
mattaitken Over 1 year ago
Specify a smaller concurrencyKey concurrency limit
This would allow for being able to have a concurrency limit on the entire queue, lets say 10, but each concurrency key only gets lets say 1 at a time. So the queue would never been executing more than 10 at once, and each concurrency key would only ever execute 1 in parallel. See this real world use-case: https://x.com/euboid/status/1929470623191101613
Eric Allam 7 months ago
Specify a smaller concurrencyKey concurrency limit
This would allow for being able to have a concurrency limit on the entire queue, lets say 10, but each concurrency key only gets lets say 1 at a time. So the queue would never been executing more than 10 at once, and each concurrency key would only ever execute 1 in parallel. See this real world use-case: https://x.com/euboid/status/1929470623191101613
Eric Allam 7 months ago
Run Trigger.dev in dev mode offline
Trigger.dev currently does not support “offline” dev mode, where you can run tasks without an internet connection. Please let us know if this is a feature you want/need. 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’m at an airport or in a cafe with bad wifi.
Zachary Keener About 1 year ago
Run Trigger.dev in dev mode offline
Trigger.dev currently does not support “offline” dev mode, where you can run tasks without an internet connection. Please let us know if this is a feature you want/need. 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’m at an airport or in a cafe with bad wifi.
Zachary Keener About 1 year ago
Simple support for Observability tools (e.g. Sentry, DataDog, Axiom, etc)
These tools typically require code to be inserted extremely early in the code execution order because they automatically instrument other modules. It might be technically possible to write an ESBuild plugin that works with Trigger.dev (we support those via extensions) but it won’t be trivial. We should add an easy way to use these tools.
mattaitken Over 1 year ago
Simple support for Observability tools (e.g. Sentry, DataDog, Axiom, etc)
These tools typically require code to be inserted extremely early in the code execution order because they automatically instrument other modules. It might be technically possible to write an ESBuild plugin that works with Trigger.dev (we support those via extensions) but it won’t be trivial. We should add an easy way to use these tools.
mattaitken Over 1 year ago
