Trigger.dev (YC W23), we are currently hiring for 3 roles:
- Developer Relations Engineer | Hybrid UK or Europe remote | Full-time
- Support Engineer | Hybrid UK or remote | Full-time
- Senior Backend Engineer | Hybrid UK or Europe remote | Full-time
We are an open source developer platform for building and running managed workflows and AI agents, serving thousands of teams and handling hundreds of millions of executions per month.
We are looking for passionate devs who love solving challenging technical problems and want to directly contribute to a large commercial open source project.
Trigger.dev (YC W23) | Senior Backend Engineer | Hybrid UK or Remote (EET to PST) | Full-time
We are an open source developer platform for building and running managed workflows and AI agents, serving thousands of teams and handling hundreds of millions of executions per month.
The role: Build SDK/platform features, backend systems, optimize database performance, create scalable APIs, implement monitoring solutions, customer support and more.
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.
> 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.
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.
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.
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.
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.
- 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.
Speaking only for us (trigger.dev founder here): In our last X products we've used two different solutions for accomplishing two tasks together: event-driven architecture and integrating 3rd party APIs. We noticed that these two concerns were intertwined, and weren't happy with how the existing solutions only solved for just 1 (leaving us to build the other). We also noticed how well tools like n8n and Zapier solved these problems, but at the UI layer, and we wanted something like those tools but in code. Hence the creation of trigger.dev.
That's a good point regarding the marketing, although we're hoping to save a few poor souls from ever know the painful bits you so eloquently wrote about!
Indeed we've had a few people who've requested this type of thing (they want to make requests authenticated as their customers, not as theirselves). Currently we only support making requests as yourself (e.g. post into your own slack channel), but our architecture will support making requests as your customers, and something we are very interested in doing eventually
We haven't done any ee features yet, which is why we stuck that "if such directories exists" line in there. We're following the playbook from some other OSS companies such as PostHog and Cal.com. Features that will go in ee (off the top of my head) are the teams and billing features of our hosted option.
We'll be working on self-hosting instructions soon as well :)
Yup I've done the AWS Step Functions thing in the past, and it usually was about 90% wrangling with AWS and 10% writing code... we wanted to flip that ratio around (that's the goal at least!)
As for temporal, we are pretty similar to them, although I think we have more of a focus on making it easy to trigger (sorry) the workflows from third party events (webhooks, etc.) and then making reliable requests once you are in a workflow.
Thanks for the feedback though, we'll try and add service comparison docs soon!
- Developer Relations Engineer | Hybrid UK or Europe remote | Full-time
- Support Engineer | Hybrid UK or remote | Full-time
- Senior Backend Engineer | Hybrid UK or Europe remote | Full-time
We are an open source developer platform for building and running managed workflows and AI agents, serving thousands of teams and handling hundreds of millions of executions per month.
We are looking for passionate devs who love solving challenging technical problems and want to directly contribute to a large commercial open source project.
Our stack: Node.js, TypeScript, Postgres, Redis, Remix, AWS
Learn more and apply here: https://jobs.ashbyhq.com/triggerdev