What is Trigger.dev?

Trigger.dev is a platform and an SDK for building and running workflows in your codebase, triggered by various sources, but without having to worry about managing any complicated orchestration infrastructure.

​

What we take care of for you:

• We provide a an orchestration platform for running workflows in your codebase.
• We provide an SDK for building workflows in your codebase, triggered by various sources such as custom events, scheduled events, and webhooks.
• We provide out-of-the-box integrations with popular services such as Slack, GitHub and more, which vastly simplifies the process interacting with 3rd-party services.
• We provide a nice UI for viewing and debugging your workflows.

​

What you take care of:

• You write your workflows in your codebase.
• You deploy your codebase to a long-running Node.js server.

​

How it works

To get an idea of how Trigger.dev works, let’s take a look at a simple workflow that sends a Slack message when a GitHub issue is labelled as critical:

The code on the left is running in a long-running Node.js server, managed by you. It is listening for the issueEvent GitHub webhook, and when it receives one, we will take care of calling the run function supplied to the Trigger constructor with the webhook payload. This gives you the following advantages over traditional webhooks:

• When working locally, you don’t need to expose your local server to the internet over a tunnel like ngrok.
• We will automatically register the webhook with GitHub for you, and verify the payload signature.
• We provide a nicely typed event payload to your run function, so you don’t have to setup webhook payload types.
• If your server isn’t running, we will wait until it’s back online before attempting to run the workflow.
• It is very easy to test your workflow locally using our Test Run feature.

As you can see the above workflow also makes a call to our Slack postMessage function, which provides the following advantages over using the raw Slack API:

• We automatically handle the OAuth flow for you, so you don’t have to worry about setting up a Slack app and dealing with credentials in your code (see our Authentication guide for more details).
• We let you pass the channelName parameter to the postMessage function, and we will automatically resolve it to the channel ID for you (which is required by the Slack API).
• We will automatically invite the bot to the channel if it isn’t already a member.
• We will automatically retry the request if the Slack API returns a rate limit error.
• We provide a nicely typed response object to your postMessage function, so you don’t have to setup Slack API types.

​

Why use Trigger.dev?

Apart from the reasons mentioned above, there are a few other reasons why you might want to use Trigger.dev:

• You want to access your database or other internal services from your workflows, without having to expose them to the internet.
• You want to colocate your workflows with your code, so you can deploy them together in one atomic unit.
• You want to build event-driven architectures without having to manage any complicated orchestration infrastructure.
• You want to add in delays or retries to your workflows, without having to worry about managing a queue.

​

Limitations

There are a few limitations to be aware of:

• We currently only support deploying to long-running Node.js servers, but we plan on adding support for serverless (e.g. AWS Lambda, Next.js and Vercel) and other languages in the future.
• Our integrations are currently quite limited, but we are trying to add more as fast as we can. If you have any suggestions, please let us know in the Discord!
• We don’t offer any kind of self-hosting option at the moment, but we plan on adding this in the future as well as various hybrid options for deploying to your own cloud.

​

Architecture

Below is a simplified architecture diagram of how Trigger.dev works:

As you can see above, we communicate between your Trigger code and the Trigger.dev platform using a WebSocket connection. This allows us to send events to your code, and receive tasks from your code.

We make use of Apache Pulsar, an open-source distributed message broker, to ensure messages are delivered reliably and in order. And we host our Pulsar Cluster using StreamNative.io.

Our WebSocket servers and the Trigger.dev service are hosted on AWS courtesy of flightcontrol.dev.