Super happy customer here. We've been using trigger.dev on various projects for over a year now. It's been a great experience and awesome to see them grow. I don't know how long it will last, but I regularly get answers to questions from the founders on Discord, often within hours. I am sure there are a bunch of competitors, but we've never really felt the need to even research them as trigger has consistently met our needs (again, across a range of projects) and seems to be anticipating the features we'll need as we AI more and more of our projects. We're cheering for you Trigger team ;)
> However I do personally really dislike that everyone is either marketing themselves or has truly pivoted to AI agents…
I'm the CEO of a direct competitor to trigger, and we're in the same boat. What we make is great for any type of workflow, but our investors are pushing us hard to frame it as AI agents.
FWIW, more than 1/2 of our customers are AI agents, so it does make sense. But you're right, it's great for all sorts of use cases (trigger and us).
In their defense, they are trying to help us grow and get follow on investment. I'm apprecative of my investor's input. They aren't forcing me to do anything, just highly encouraging.
All of the un-budgeted money right now is for AI related workloads, so if you want enterprise money you have to pitch your product as AI.
And if you want investor money right now, you better have an AI product.
I do some AI agent work; I suspect it's because there's a lot of people with infrastructure and programming skills that are new to building "agents". It's easy to think this requires monolithic architecture when a distributed DAG is often optimal. A lot of frameworks and SDKs for "agents" also inadvertently encourage monolithic design.
Long way of saying it's the marketing machine doing its thing. This looks like Cloud or run it yourself DAG software with some bells and whistles.
yeah this really confused me... at first I was like... oh boy yet another "agentic ai saas" but then looking closer I realized this is like hosted temporal alternative which made me a lot more curious.
We're very satisfied customers since January of this year.
We use it as an extension of our node app, for all things asynchronous (long or short). The fact that it's the same codebase on our server and trigger cloud is a huge plus.
For me, it's the most accessible incarnation of serverless. You can add it to your stack for one task and gradually use it for more and more tasks (long or short). Testing and local development is easy as can be. The tooling is just right. No complex configurations. You can incrementally use the queuing, wait points, batch triggers for more power.
We've had some issues with migrating from v3 to v4. The transition felt rushed (some of the docs / examples are still showing v3 code, that is deprecated in v4). I understand that it might take some time to update the docs and examples, because there is a lot of content.
How does Trigger compare to tools like Temporal or Restate? If we put aside the AI use case, it seems like the fundamental feature is durable execution, where there are a few other options in the space.
The core is a durable execution engine, but there's a lot more needed to build good applications. Like being able to get realtime progress to users, or being able to use system packages you need to actually do the work (like ffmpeg, browsers etc).
Both of them are focused more on being workflow engines.
Temporal is a workflow engine – if you use their cloud product you still have to manage, scale, and deploy the compute.
With Temporal you need to write your code in a very specific way for it work, including working with the current time, randomness, process.env, setTimeout… This means you have to be careful using popular packages because they often using these common functions internally. Or you need to wrap all of these calls in side effects or activities.
Restate is definitely simpler than Temporal, in a good way. You wrap any code that's non-deterministic in their helpers so it won't get executed twice. I don't think you can install system packages that you need, which has been surprisingly important for a lot of our users.
I have used Temporal in the past in my previous job and currently using Prefect. All are similar in terms of durable and traced executions but this one seems to be tailored towards AI use cases where as others are more general.
I haven't tried Trigger, planning to give it a spin this weekend!
Congrats on the launch - CRIU snapshot/restore is very cool, especially for data-heavy pipelines like video processing.
Question: is a first-class Supabase/Postgres integration on the roadmap so we can (a) start Trigger jobs from SQL functions and (b) read job status via a foreign data wrapper? That "SQL-native job control (invoke from SQL, query from SQL)" path would make Trigger.dev feel native in Supabase apps.
Disclosure: I'm building pgflow, a Postgres-first workflow/background jobs layer for Supabase (https://pgflow.dev).
This looks great, I wish I had discovered it 4 months ago. I had to build entire coordination of Prefect with Django app in https://listingheroai.com
Listing hero allows ecom brands to generate consistent templated infographics so I reinvented all these things via data share between Django, Celery processes, Prefect, and webhooks. Users can start multiple generations at the same time and all run in parallel in Prefect and realtime progress visible in frontend via webhooks.
I will try playing with Trigger next weekend and probably integrate with a static stack like cloudflare worker. Excited to try it out!
Quite happy when I got to play with it – but I do prefer Inngest as the code is hosted where our actual app is hosted; not on their server. So it's just easier (but it's a tradeoff).
One thing I did notice though from looking through the examples is this:
Uncaught errors automatically cause retries of tasks using your settings. Plus there are helpers for granular retrying inside your tasks.
This feels like one of those gotchas that is absolutely prone to benign refactoring causing huge screwups, or at least someone will find they pinged a pay for service 50x by accident without realising.
ergonomics like your helper of await retry.onThrow feel like a developer friendly default "safe" approach rather than just an optional helper, though granted it's not as magic feeling when you're trying convert eyeballs into users.
Yep you do need to be careful with uncaught errors.
When you setup your project you choose the default number of retries and back-off settings. Generally people don't go as high as 50 and setup alerts when runs fail. Then you can use the bulk replaying feature when things do wrong, or if services you rely on have long outages.
How are you folks handling the "uploading your source" to trigger for the workflows to work on your cloud offering? One thing that I find Temporal always wins over is that the workers live on your cloud/server so you aren't required to upload anything to them. Any plans to tackle this in the future?
Currently we have two deployment models: self-host the entire platform or use our cloud offering, where we host the platform and your workloads. We've had a lot of feedback from users and potential users that they'd like to be able to run workloads themself and have us host the platform side. We definitely plan on offering this deployment model (and allowing payloads and outputs to stay on-prem as well) eventually, but we're waiting until we can do it properly and that will support all the features of the cloud (snapshot/restore, warm starts, atomic versioning). We're planning on offering this alongside the release of our MicroVM runtime later this year/early next year.
Congrats on the launch guys. It's been inspiring to see you iterate on the original idea and get more capable in each version.
Can you say more about "we found that most developers struggled to write reliable code with implicit determinism". What were some of the common mistakes you were seeing?
Very common issues were: forgetting to put non-determistic code inside of steps (deterministic code can be put outside of steps, but non-deterministic = boom), incorrect use of cache keys (people would put dynamic data inside the cache key). Another issue we hit pretty frequently that a single step would take longer than the serverless function timeout it was running on (this was before we ran our own compute platform). Another issue was speed, especially with more complicated tasks with hundreds of steps: the amount of data that needed serializing/deserializing became pretty huge. Oh yea, that was another thing (it's coming back to me now), there were lots of fun surprises about data being serialized/deserialized and changing shape (e.g. you couldn't have a step that just returned a class instance, for example) which caused tons of bugs.
Inngest is very similar to Trigger.dev version 2: it’s an API for queuing and orchestrating workflows. You need to divide your work into steps, where each step needs to have serializable inputs and outputs, and takes less than the timeout of your serverless function (if you're hosted on serverless).
Trigger.dev is a queue and workflow engine but we also run compute. This makes some things possible which aren’t when you only control one side:
1. No timeouts, you can run code for as long as you need.
2. You don’t need to divide your work into steps. If you want you can use multiple tasks.
3. You can install any system packages you need, like ffmpeg, Puppeteer etc. Depending on where you’re deploying this can be a problem with other tools. There are maximum bundle sizes on a lot of platforms which are surprisingly easy to hit.
4. Atomic versioning. Each deploy of your tasks is separate and any runs that have started will continue until finished, locked to that version of the code. This means you don’t need to think about versioning inside your code which can becomes messy and error prone.
I really like Trigger but I would have loved some way to trigger it from the FE, it was a small part of our use case but it sucked having to implement a proxy for it.
If it were possible, how would you have prevented your Trigger account from being abused once a bad actor got its connection details by inspecting your FE app with DevTools?
What's your differentiation? I see a new AI agent workflow framework/platform/library every week, there's gotta be thousands by this point. Why do you feel you can win the market?
- We're not really an agent framework, but more like a agent runtime that is agnostic to what framework you choose to run on our infra. We have lots of people running langchain, mastra, AI SDK, hand-rolled, etc on top of us, since we are just a compute platform. We have the building blocks needed for running any kind of agent or AI workflow: ability to run system packages (anything from chrome to ffmpeg), long-running (e.g. no timeouts), realtime updates to your frontend (including streaming tokens). We also provide queues and concurrency limits for doing stuff like multitenant concurrency, observability built on OpenTelemetry, schedules for doing ETL/ELT data stuff (including multitenant schedules).
- We are TS first and believe the future of agents and AI Applications will be won by TS devs.
- We have a deep integration with snapshotting so code can be written in a natural way but still exhibit continuation style behavior. For example, you can trigger another agent or task or tool to run (lets say an agent that specializes in browser use) and wait for the result as a tool call result. Instead of having to introduce a serialization boundary so you can stop compute while waiting and then rhydrate and resume through skipped "steps" or activities we instead will snapshot the process, kill it, and resume it later, continuing from the exact same process state as before. This is all handled under the hood and managed by us. We're currently using CRIU for this but will be moving to whole VM snapshots with our MicroVM release.
I also see a new AI agent workflow framework/platform/library every week and to me the differentiation of this project is clear in the logging, orchestration and auto-scaling. Of course, I don't need trigger.dev to win the market, I was just looking for exactly this for my own project and haven't found anything else like it.
> use cases like compute-heavy tasks such as generating videos using AI (Icon.com), real-time computer use (Scrapybara), AI enrichment pipelines (Pallet, Centralize), and vibe coding tools (Hero UI, Magic Patterns, Capy.ai)
Okay, but aren't these websites using Trigger to schedule remarketing slop? Like adding you to Slack, sending you an email on day 1, sending you an email on day 7, etc... How exactly is it being used to power applications? You know what the difference is.
co-founder of Magic Patterns here, saw were were mentioned, figured I'd chime in:
We don't use Trigger for marketing at all and I actually never thought of it for that use case.
We're an AI design tool - prompt to create an interactive mockup - and we use Trigger to take screenshots of designs to provide a preview image. Taking a screenshot sounds easy, but it's not because Puppeteer constantly hits OOM errors. So you need a high-end machine, and so it can get expensive. We originally were using a homegrown solution, a microservice, but it would constantly crash (even though were paying $$$$$ for it).
Trigger spinning up jobs was perfect and we migrated in a day and now I never think about it.
That's actually how we started back during YC W23 as a "Zapier for developers" but we pivoted to "async workflows" later in 2023 and have since been used less like Zapier and more like the core part of an apps infra/backend, which has taken off with AI applications building AI workflows and agents, including those examples you quoted there.
Super happy customer here. We've been using trigger.dev on various projects for over a year now. It's been a great experience and awesome to see them grow. I don't know how long it will last, but I regularly get answers to questions from the founders on Discord, often within hours. I am sure there are a bunch of competitors, but we've never really felt the need to even research them as trigger has consistently met our needs (again, across a range of projects) and seems to be anticipating the features we'll need as we AI more and more of our projects. We're cheering for you Trigger team ;)
The platform looks great!
However I do personally really dislike that everyone is either marketing themselves or has truly pivoted to AI agents…
This seems like a great platform to run any type of tasks.
> However I do personally really dislike that everyone is either marketing themselves or has truly pivoted to AI agents…
I'm the CEO of a direct competitor to trigger, and we're in the same boat. What we make is great for any type of workflow, but our investors are pushing us hard to frame it as AI agents.
FWIW, more than 1/2 of our customers are AI agents, so it does make sense. But you're right, it's great for all sorts of use cases (trigger and us).
"our investors are pushing us hard to frame it as AI agents"
One of the biggest downsides of raising money. The moment you have investors, they own a lot of what you do even though they shouldn't in theory.
In their defense, they are trying to help us grow and get follow on investment. I'm apprecative of my investor's input. They aren't forcing me to do anything, just highly encouraging.
All of the un-budgeted money right now is for AI related workloads, so if you want enterprise money you have to pitch your product as AI.
And if you want investor money right now, you better have an AI product.
I do some AI agent work; I suspect it's because there's a lot of people with infrastructure and programming skills that are new to building "agents". It's easy to think this requires monolithic architecture when a distributed DAG is often optimal. A lot of frameworks and SDKs for "agents" also inadvertently encourage monolithic design.
Long way of saying it's the marketing machine doing its thing. This looks like Cloud or run it yourself DAG software with some bells and whistles.
yeah this really confused me... at first I was like... oh boy yet another "agentic ai saas" but then looking closer I realized this is like hosted temporal alternative which made me a lot more curious.
Previously discussed:
https://news.ycombinator.com/item?id=37750763
We're very satisfied customers since January of this year.
We use it as an extension of our node app, for all things asynchronous (long or short). The fact that it's the same codebase on our server and trigger cloud is a huge plus.
For me, it's the most accessible incarnation of serverless. You can add it to your stack for one task and gradually use it for more and more tasks (long or short). Testing and local development is easy as can be. The tooling is just right. No complex configurations. You can incrementally use the queuing, wait points, batch triggers for more power.
We've had some issues with migrating from v3 to v4. The transition felt rushed (some of the docs / examples are still showing v3 code, that is deprecated in v4). I understand that it might take some time to update the docs and examples, because there is a lot of content.
How does Trigger compare to tools like Temporal or Restate? If we put aside the AI use case, it seems like the fundamental feature is durable execution, where there are a few other options in the space.
The core is a durable execution engine, but there's a lot more needed to build good applications. Like being able to get realtime progress to users, or being able to use system packages you need to actually do the work (like ffmpeg, browsers etc).
Both of them are focused more on being workflow engines.
Temporal is a workflow engine – if you use their cloud product you still have to manage, scale, and deploy the compute.
With Temporal you need to write your code in a very specific way for it work, including working with the current time, randomness, process.env, setTimeout… This means you have to be careful using popular packages because they often using these common functions internally. Or you need to wrap all of these calls in side effects or activities.
Restate is definitely simpler than Temporal, in a good way. You wrap any code that's non-deterministic in their helpers so it won't get executed twice. I don't think you can install system packages that you need, which has been surprisingly important for a lot of our users.
I have used Temporal in the past in my previous job and currently using Prefect. All are similar in terms of durable and traced executions but this one seems to be tailored towards AI use cases where as others are more general.
I haven't tried Trigger, planning to give it a spin this weekend!
Congrats on the launch - CRIU snapshot/restore is very cool, especially for data-heavy pipelines like video processing.
Question: is a first-class Supabase/Postgres integration on the roadmap so we can (a) start Trigger jobs from SQL functions and (b) read job status via a foreign data wrapper? That "SQL-native job control (invoke from SQL, query from SQL)" path would make Trigger.dev feel native in Supabase apps.
Disclosure: I'm building pgflow, a Postgres-first workflow/background jobs layer for Supabase (https://pgflow.dev).
We've been using the platform for running our agents. We use the vercel ai sdk and electric sql. Been very happy with everything.
Dallin's building https://www.buster.so (agents for data analytics).
This looks great, I wish I had discovered it 4 months ago. I had to build entire coordination of Prefect with Django app in https://listingheroai.com
Listing hero allows ecom brands to generate consistent templated infographics so I reinvented all these things via data share between Django, Celery processes, Prefect, and webhooks. Users can start multiple generations at the same time and all run in parallel in Prefect and realtime progress visible in frontend via webhooks.
I will try playing with Trigger next weekend and probably integrate with a static stack like cloudflare worker. Excited to try it out!
Quite happy when I got to play with it – but I do prefer Inngest as the code is hosted where our actual app is hosted; not on their server. So it's just easier (but it's a tradeoff).
Good tool, good tooling, congrats to the team!
This looks really interesting, congrats!
One thing I did notice though from looking through the examples is this:
Uncaught errors automatically cause retries of tasks using your settings. Plus there are helpers for granular retrying inside your tasks.
This feels like one of those gotchas that is absolutely prone to benign refactoring causing huge screwups, or at least someone will find they pinged a pay for service 50x by accident without realising.
ergonomics like your helper of await retry.onThrow feel like a developer friendly default "safe" approach rather than just an optional helper, though granted it's not as magic feeling when you're trying convert eyeballs into users.
Yep you do need to be careful with uncaught errors.
When you setup your project you choose the default number of retries and back-off settings. Generally people don't go as high as 50 and setup alerts when runs fail. Then you can use the bulk replaying feature when things do wrong, or if services you rely on have long outages.
I think on balance it is the correct behaviour.
How are you folks handling the "uploading your source" to trigger for the workflows to work on your cloud offering? One thing that I find Temporal always wins over is that the workers live on your cloud/server so you aren't required to upload anything to them. Any plans to tackle this in the future?
Currently we have two deployment models: self-host the entire platform or use our cloud offering, where we host the platform and your workloads. We've had a lot of feedback from users and potential users that they'd like to be able to run workloads themself and have us host the platform side. We definitely plan on offering this deployment model (and allowing payloads and outputs to stay on-prem as well) eventually, but we're waiting until we can do it properly and that will support all the features of the cloud (snapshot/restore, warm starts, atomic versioning). We're planning on offering this alongside the release of our MicroVM runtime later this year/early next year.
Nice glad to hear it!
Congrats on the launch guys. It's been inspiring to see you iterate on the original idea and get more capable in each version.
Can you say more about "we found that most developers struggled to write reliable code with implicit determinism". What were some of the common mistakes you were seeing?
Very common issues were: forgetting to put non-determistic code inside of steps (deterministic code can be put outside of steps, but non-deterministic = boom), incorrect use of cache keys (people would put dynamic data inside the cache key). Another issue we hit pretty frequently that a single step would take longer than the serverless function timeout it was running on (this was before we ran our own compute platform). Another issue was speed, especially with more complicated tasks with hundreds of steps: the amount of data that needed serializing/deserializing became pretty huge. Oh yea, that was another thing (it's coming back to me now), there were lots of fun surprises about data being serialized/deserialized and changing shape (e.g. you couldn't have a step that just returned a class instance, for example) which caused tons of bugs.
I've been using this for a few years. It's great.
(other Trigger.dev co-founder here) That's awesome.
Let us know if there's anything we can do to make the product better for you
How does this compare to Inngest? That seems to be the closest comparison AFAIK so I'd be curious to what extent Trigger might be better than Inngest.
Inngest is very similar to Trigger.dev version 2: it’s an API for queuing and orchestrating workflows. You need to divide your work into steps, where each step needs to have serializable inputs and outputs, and takes less than the timeout of your serverless function (if you're hosted on serverless).
Trigger.dev is a queue and workflow engine but we also run compute. This makes some things possible which aren’t when you only control one side:
1. No timeouts, you can run code for as long as you need. 2. You don’t need to divide your work into steps. If you want you can use multiple tasks. 3. You can install any system packages you need, like ffmpeg, Puppeteer etc. Depending on where you’re deploying this can be a problem with other tools. There are maximum bundle sizes on a lot of platforms which are surprisingly easy to hit. 4. Atomic versioning. Each deploy of your tasks is separate and any runs that have started will continue until finished, locked to that version of the code. This means you don’t need to think about versioning inside your code which can becomes messy and error prone.
One other note is that we’re Apache 2.0.
I really like Trigger but I would have loved some way to trigger it from the FE, it was a small part of our use case but it sucked having to implement a proxy for it.
We support this but you do need to pass a public access token to your frontend so it's secure: https://trigger.dev/docs/realtime/react-hooks/triggering
If it were possible, how would you have prevented your Trigger account from being abused once a bad actor got its connection details by inspecting your FE app with DevTools?
What's your differentiation? I see a new AI agent workflow framework/platform/library every week, there's gotta be thousands by this point. Why do you feel you can win the market?
A couple things purely from the tech angle:
- We're not really an agent framework, but more like a agent runtime that is agnostic to what framework you choose to run on our infra. We have lots of people running langchain, mastra, AI SDK, hand-rolled, etc on top of us, since we are just a compute platform. We have the building blocks needed for running any kind of agent or AI workflow: ability to run system packages (anything from chrome to ffmpeg), long-running (e.g. no timeouts), realtime updates to your frontend (including streaming tokens). We also provide queues and concurrency limits for doing stuff like multitenant concurrency, observability built on OpenTelemetry, schedules for doing ETL/ELT data stuff (including multitenant schedules). - We are TS first and believe the future of agents and AI Applications will be won by TS devs. - We have a deep integration with snapshotting so code can be written in a natural way but still exhibit continuation style behavior. For example, you can trigger another agent or task or tool to run (lets say an agent that specializes in browser use) and wait for the result as a tool call result. Instead of having to introduce a serialization boundary so you can stop compute while waiting and then rhydrate and resume through skipped "steps" or activities we instead will snapshot the process, kill it, and resume it later, continuing from the exact same process state as before. This is all handled under the hood and managed by us. We're currently using CRIU for this but will be moving to whole VM snapshots with our MicroVM release.
I also see a new AI agent workflow framework/platform/library every week and to me the differentiation of this project is clear in the logging, orchestration and auto-scaling. Of course, I don't need trigger.dev to win the market, I was just looking for exactly this for my own project and haven't found anything else like it.
Hey Eric, I've been using trigger since April of this year!
It's a core tenant of my business and a handful of side projects. Wish you and your team the best!
Congrats on the launch! Would love to do a collab for theunwindai.com.
This is awesome. I love the documentation.
Docs created by Mintlify https://www.mintlify.com/
Yep, thanks Mintlify!
I like Trigger but it's a lot of complexity...
> use cases like compute-heavy tasks such as generating videos using AI (Icon.com), real-time computer use (Scrapybara), AI enrichment pipelines (Pallet, Centralize), and vibe coding tools (Hero UI, Magic Patterns, Capy.ai)
Okay, but aren't these websites using Trigger to schedule remarketing slop? Like adding you to Slack, sending you an email on day 1, sending you an email on day 7, etc... How exactly is it being used to power applications? You know what the difference is.
co-founder of Magic Patterns here, saw were were mentioned, figured I'd chime in:
We don't use Trigger for marketing at all and I actually never thought of it for that use case.
We're an AI design tool - prompt to create an interactive mockup - and we use Trigger to take screenshots of designs to provide a preview image. Taking a screenshot sounds easy, but it's not because Puppeteer constantly hits OOM errors. So you need a high-end machine, and so it can get expensive. We originally were using a homegrown solution, a microservice, but it would constantly crash (even though were paying $$$$$ for it).
Trigger spinning up jobs was perfect and we migrated in a day and now I never think about it.
That's actually how we started back during YC W23 as a "Zapier for developers" but we pivoted to "async workflows" later in 2023 and have since been used less like Zapier and more like the core part of an apps infra/backend, which has taken off with AI applications building AI workflows and agents, including those examples you quoted there.