Here's a summary of the themes from the Hacker News discussion about Trigger.dev:
Differentiation and Market Saturation
The discussion opens with a question about how Trigger.dev differentiates itself in a crowded market of AI agent workflow frameworks. Several users acknowledge the sheer volume of similar tools but find Trigger.dev's specific features compelling.
- martinkallstrom states, "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."
- eallam further elaborates on the platform's role: "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."
Robust Technical Features and Architecture
A significant portion of the discussion revolves around Trigger.dev's technical capabilities, with users highlighting features like snapshotting, long-running tasks, system package support, and real-time updates.
- eallam details the snapshotting mechanism: "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." They also mention the move to "whole VM snapshots with our MicroVM release."
- Regarding system packages and long-running tasks, eallam notes, "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)."
- jumski found the CRIU snapshot/restore feature particularly interesting for data-intensive pipelines.
Developer Experience and Ease of Use
Several users praise Trigger.dev for its developer-friendly aspects, including documentation, ease of integration, and local development experience.
- aavci simply states, "This is awesome. I love the documentation."
- paduc highlights the accessibility: "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."
Customer Satisfaction and Support
Positive testimonials from existing customers underscore the platform's reliability and the responsiveness of the team.
- flippyhead, a self-proclaimed "Super happy customer," shares their experience: "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."
Orchestration and Durable Execution
Trigger.dev's core functionality as a durable execution engine is compared to other established players like Temporal and Restate. The discussion clarifies Trigger.dev's approach and its advantages.
- tao_oat directly asks, "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."
- matt-aitken responds by differentiating: "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... Restate is definitely simpler than Temporal, in a good way. You wrap any code that's non-deterministic in their helpers... I don't think you can install system packages that you need, which has been surprisingly important for a lot of our users."
- scottydelta contrasts Trigger.dev with Temporal and 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."
Comparison with Inngest
Inngest is identified as a close competitor, and a comparison is drawn regarding their core features and deployment models.
- babyshake asks, "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."
- matt-aitken elaborates on the distinctions: "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... Trigger.dev... also run compute. This makes some things possible which aren’t when you only control one side: No timeouts, you can run code for as long as you need. You don’t need to divide your work into steps... You can install any system packages you need... Atomic versioning."
- lazharichir offers a different perspective: "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)."
Deployment Models and Cloud vs. Self-Hosting
Trigger.dev offers both cloud and self-hosted options, with discussions around the implications of uploading source code and future plans for deployment flexibility.
- awaseem raises concerns about uploading source code for the cloud offering, questioning how it compares to Temporal's worker-on-your-cloud model.
- eallam clarifies: "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." They confirm plans to offer a model "allowing payloads and outputs to stay on-prem as well."
User Interface and Frontend Integration
The ability to trigger jobs from the frontend and display real-time progress is a point of discussion, with Trigger.dev providing solutions for this.
- rutierut expresses a desire for frontend triggering and mentions needing a proxy.
- matt-aitken clarifies that this is supported with a public access token: "We support this but you do need to pass a public access token to your frontend so it's secure."
Error Handling and Retries
The default behavior of automatic retries on uncaught errors is flagged as a potential pitfall, but the system also provides tools for granular control and safe retrying.
- weego voices concern: "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."
- matt-aitken addresses this: "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."
Specific Use Cases and Pivot from "Zapier for Developers"
The discussion touches on earlier use cases and the platform's evolution, clarifying how it's being applied beyond simple marketing automation.
- doctorpangloss questions the use cases, suggesting they might be for "remarketing slop."
- eallam corrects this: "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."
- alexdanilowicz of Magic Patterns confirms their use: "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."
Technical Challenges and Pitfalls in Workflow Development
The conversation delves into common mistakes developers make when building workflows, which Trigger.dev aims to mitigate.
- paulantwilliams asks for more details on what "most developers struggled to write reliable code with implicit determinism" means.
- eallam lists common issues: "forgetting to put non-determistic code inside of steps... incorrect use of cache keys... a single step would take longer than the serverless function timeout... the amount of data that needed serializing/deserializing became pretty huge... data being serialized/deserialized and changing shape (e.g. you couldn't have a step that just returned a class instance, for example)."