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 ;)
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!
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.
That's great to hear, and thanks for the kind words.
Sorry you had some issues migrating. You're right, it was our biggest docs update so far, and unfortunately a few things did get missed which we have (hopefully) since rectified. Please do let us know if there's anything else we missed and we'll get it sorted.
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).
The reliability piece is interesting - we've seen AI apps fail in ways that are hard to predict or reproduce. Traditional monitoring doesn't really work when your 'bugs' are stochastic.
How are you handling failure modes that only show up statistically? Like when a model starts giving subtly wrong answers 2% of the time after a deployment.
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!
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.
We’ve been using it for a while and I’m a super happy customer. The scheduled task feature has been a lifesaver—super simple and just works exactly as expected. Also want to call out the Dev mode: it’s an absolute gem, makes testing and iterating so much smoother than anything else I’ve tried.
Really appreciate the thoughtfulness that’s gone into the product—excited to see the upcoming MicroVM + checkpointing work land!
This is really cool — the snapshotting approach with CRIU feels like the missing piece that serverless was never able to solve cleanly. Being able to “pause” work across long waits without hacks is huge. Curious how you see this stacking up against Temporal or LangGraph — feels like you’re aiming at the same pain points but from a more infra-first angle.
I'm very interested in trying this out for my side project. I'm using Vercel's AI SDK to generate content and images to create PDFs but getting it to output both images and text in the same generateObject call feels almost impossible.
For sure, you can handle generating both images and text in the same workflow running multiple AI SDK operations in parallel or sequence, and then combine the outputs however you need for your PDFs.
I'd recommend browsing our examples docs (https://trigger.dev/docs/guides/introduction) if you want to see different ways of using the AI SDK and converting / generating PDFs (React to PDF / Libreoffice, etc).
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.
You keep saying deterministic… What are you actually trying to say?
Based on your docs: I mean googling “deterministic temporal.dev” brings up nothing. I found other libraries and I get it. I assume you mean, “replayable by our engine,” but that would give away: replayability of most code in all the languages you support is hopelessly out of scope. “Pure” isn’t even a useful constraint - lots of code looks pure, but basically none of Python is, because you will alloc by so much as sneezing and hence you can OOM. Why promise the world?
Determinism means that the control logic should lead to the same set of behaviours every time with the same set of inputs under otherwise normal runtime conditions.
And if you're gonna come back with "but that's not real determinism!" then I would remind you that actually no code is deterministic because of quantum uncertainty, and that quantum uncertainty isn't necessarily real because of solipsism, and that there's more to life than rhetorical definition interrogations.
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).
That's fair, we understand there can be trade-offs when picking a workflow tool. Was there anything else we were missing or was it purely the hosting model which made the difference?
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.
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?
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.
Another happy customer here. Since day one Trigger.dev is powering our AI Automation platform (https://turbotable.ai). It helped us to scale effortlessly and stay on TypeScript stack, easily integrates with tools we use. And the pricing is even cheaper than self-hosting on VPS. Thanks guys!
Mastra and Trigger.dev solve different but complementary problems. Mastra is great for building AI agents, with abstractions for reasoning, memory, tools and observability. Trigger.dev is an agent-agnostic cloud runtime: capable of running long-running compute defined TypeScript with retries, queues, waitpoints, and observability.
We do plan on adding our own AI primitives in the future, but we will also always aim to be framework agnostic. Frameworks like Mastra, Vercel’s AI SDK, etc, pair really well with us; you get agent features on top of our execution layer that’s reliable at scale. We think the best solution for developers gives them optionality to use the tools they’re already familiar with.
> 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.
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.
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.
Can you expand a bit on this use case? Why would Puppeteer constantly crash on your own high end machine, but not on Trigger's infra? Puppeteer doesn't care where it runs, so it would be nice to understand how Trigger's infra works around this problem.
> 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).
I'm curious what product you ship for workflows? I'm looking at pushing out a workflow engine in the near future and it is interesting to me to see what other people are doing.
Out of respect for my competitor's Launch HN, I don't want to say here, but if you look at my profile or google my username it won't be hard to find. :)
> FWIW, more than 1/2 of our customers are AI agents, so it does make sense.
We’ve seen the same thing, more even. Our positioning wasn’t even lead by our investors; we figured if the main thing our customers were doing on the platform was building complex/long-running AI agents (and ‘agentic’ workflows), it made sense to lean into it. Fortunately (or unfortunately) for us, it does actually fit what we do pretty well, even if you can also do a lot of other great stuff with the platform which isn’t covered under that umbrella. It’s a tricky thing to get right.
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.
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 ;)
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!
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.
That's great to hear, and thanks for the kind words.
Sorry you had some issues migrating. You're right, it was our biggest docs update so far, and unfortunately a few things did get missed which we have (hopefully) since rectified. Please do let us know if there's anything else we missed and we'll get it sorted.
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).
The reliability piece is interesting - we've seen AI apps fail in ways that are hard to predict or reproduce. Traditional monitoring doesn't really work when your 'bugs' are stochastic. How are you handling failure modes that only show up statistically? Like when a model starts giving subtly wrong answers 2% of the time after a deployment.
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!
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.
Big fan of Trigger.dev here
We’ve been using it for a while and I’m a super happy customer. The scheduled task feature has been a lifesaver—super simple and just works exactly as expected. Also want to call out the Dev mode: it’s an absolute gem, makes testing and iterating so much smoother than anything else I’ve tried.
Really appreciate the thoughtfulness that’s gone into the product—excited to see the upcoming MicroVM + checkpointing work land!
This seems like a blatant AI comment
This is really cool — the snapshotting approach with CRIU feels like the missing piece that serverless was never able to solve cleanly. Being able to “pause” work across long waits without hacks is huge. Curious how you see this stacking up against Temporal or LangGraph — feels like you’re aiming at the same pain points but from a more infra-first angle.
Can I use this from my .NET app? Or is it JS only?
I'm very interested in trying this out for my side project. I'm using Vercel's AI SDK to generate content and images to create PDFs but getting it to output both images and text in the same generateObject call feels almost impossible.
Is it something that Trigger can do?
For sure, you can handle generating both images and text in the same workflow running multiple AI SDK operations in parallel or sequence, and then combine the outputs however you need for your PDFs.
I'd recommend browsing our examples docs (https://trigger.dev/docs/guides/introduction) if you want to see different ways of using the AI SDK and converting / generating PDFs (React to PDF / Libreoffice, etc).
Perfect! That's exactly what I'm looking for. I'll give it a try and report back :)
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.
You keep saying deterministic… What are you actually trying to say?
Based on your docs: I mean googling “deterministic temporal.dev” brings up nothing. I found other libraries and I get it. I assume you mean, “replayable by our engine,” but that would give away: replayability of most code in all the languages you support is hopelessly out of scope. “Pure” isn’t even a useful constraint - lots of code looks pure, but basically none of Python is, because you will alloc by so much as sneezing and hence you can OOM. Why promise the world?
Determinism means that the control logic should lead to the same set of behaviours every time with the same set of inputs under otherwise normal runtime conditions.
And if you're gonna come back with "but that's not real determinism!" then I would remind you that actually no code is deterministic because of quantum uncertainty, and that quantum uncertainty isn't necessarily real because of solipsism, and that there's more to life than rhetorical definition interrogations.
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!
That's fair, we understand there can be trade-offs when picking a workflow tool. Was there anything else we were missing or was it purely the hosting model which made the difference?
We appreciate the support either way!
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.
[flagged]
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?
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.
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!
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).
I used for a side project really liked. Dev UX was great when compared to UX of SQS. UI is very nice.
Congrats on the launch! Would love to do a collab for theunwindai.com.
Awesome product! Although Trigger.dev is fully capable, if you want to skip installing the browser infra and offload it to a remote session, I wrote a tutorial recently on how to use Anchor Browser with Trigger.dev to achieve this: - https://trigger.dev/docs/guides/example-projects/anchor-brow... - https://anchorbrowser.io/blog/integrate-trigger-dev-and-anch...
Looking forward to tracking Trigger.dev's success in the future.
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
This is awesome. I love the documentation.
Docs created by Mintlify https://www.mintlify.com/
Yep, thanks Mintlify!
Another happy customer here. Since day one Trigger.dev is powering our AI Automation platform (https://turbotable.ai). It helped us to scale effortlessly and stay on TypeScript stack, easily integrates with tools we use. And the pricing is even cheaper than self-hosting on VPS. Thanks guys!
How does this differ to Mastra?
Mastra and Trigger.dev solve different but complementary problems. Mastra is great for building AI agents, with abstractions for reasoning, memory, tools and observability. Trigger.dev is an agent-agnostic cloud runtime: capable of running long-running compute defined TypeScript with retries, queues, waitpoints, and observability.
We do plan on adding our own AI primitives in the future, but we will also always aim to be framework agnostic. Frameworks like Mastra, Vercel’s AI SDK, etc, pair really well with us; you get agent features on top of our execution layer that’s reliable at scale. We think the best solution for developers gives them optionality to use the tools they’re already familiar with.
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.
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.
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.
Can you expand a bit on this use case? Why would Puppeteer constantly crash on your own high end machine, but not on Trigger's infra? Puppeteer doesn't care where it runs, so it would be nice to understand how Trigger's infra works around this problem.
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).
I'm curious what product you ship for workflows? I'm looking at pushing out a workflow engine in the near future and it is interesting to me to see what other people are doing.
Out of respect for my competitor's Launch HN, I don't want to say here, but if you look at my profile or google my username it won't be hard to find. :)
Class act. Appreciated.
> FWIW, more than 1/2 of our customers are AI agents, so it does make sense.
We’ve seen the same thing, more even. Our positioning wasn’t even lead by our investors; we figured if the main thing our customers were doing on the platform was building complex/long-running AI agents (and ‘agentic’ workflows), it made sense to lean into it. Fortunately (or unfortunately) for us, it does actually fit what we do pretty well, even if you can also do a lot of other great stuff with the platform which isn’t covered under that umbrella. It’s a tricky thing to get right.
What a breath of fresh air! Love this comment!
"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.
[dead]
[dead]