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.

Planned

Vercel integration

Linear

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

In Progress

Wait For Request

Michał Kowalkowski

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.

Europe workers

mattaitken

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.

In Review

Self-hosted workers

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

An Anonymous User

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

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.

Чтобы получить доступ к некоторым базам данных и другим службам, необходимо предоставить им белый список IP-адресов. 
Чтобы это хорошо работало, нам нужны статические IP-адреса, возможно, IP-адрес каждого клиента.

Статические IP-адреса

Static IP addresses

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

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:<pre><code>const memory = process.memoryUsage();
logger.log(“Memory usage”, 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

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

SOC2 compliance

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

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

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

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

HIPAA compliance

Support for being able to write your tasks in Golang

Go support

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.

Run on complete/failed webhook

Rostislav Dascal

At the moment all users in your team are admins, which means they can all view the API keys, deploy, add/remove team members, and create/edit/view/delete environment variables.We need to add a permissions system so this can be configured by admins.

Trigger.dev

Have something to say?