eallam

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.

Our stack: Node.js, TypeScript, Postgres, Redis, Remix, AWS

Learn more and apply here: https://jobs.ashbyhq.com/triggerdev

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.

Our stack: Node.js, TypeScript, Postgres, Redis, Remix, AWS

Learn more and apply here: https://trigger.dev/careers/senior-backend-engineer

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.

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.

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.

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.

Eric from Trigger.dev here. We moved the docs from a dedicated repo into our monorepo so that probably accounts for the above issue

No problem, it definitely deserves front-page status, thanks for writing it :)

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!

Contributions welcome! Hop in our Discord and we can chat: https://discord.gg/nkqV9xBYWy

Currently we are hosting, but we are going to be documenting how to self host in the near future so you can host it yourself.

I forgot to mention in the original post we've built a bunch of example workflows here: https://github.com/triggerdotdev/trigger.dev-examples

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!

Where were you 2 months ago!

Zapier is great for non-developers, and as developers we've even used Zapier in the past because in some simple cases it's actually easier and more reliable than writing the code yourself! It's not easy to write code that connects even just a few services together, and handles transient errors and server interruptions, usually it takes some kind of infrastructure and maintenance, and can no longer be written in the normal way (and good luck with delays!).

We wanted to bring the convenience of Zapier (you describe the request you want to do, they figure out how to do it!) back into our codebases, without having to manage a bunch of infrastructure (that's where trigger.dev comes in).

While we were at it we built this as a general purpose event-driven system, complete with AWS Event Bridge like event pattern filtering, and also added the ability to listen for webhooks reliably without having to use a tunnel to your local machine when testing locally.

We definitely need to get better with our error messages! Thanks for the report, we'll look into it! What phone OS are you on?

We do have a VS Code extension: https://marketplace.visualstudio.com/items?itemName=JSONHero...

Yea I really wanted to write "JSON is worse is better" because JSON is great and simple. We really just mean "reading complicated JSON files sucks"

Eric here (one of the creators of JSON Hero) and this is a really good point. We built JSON Hero earlier this year and partly wanted to use it to try out Cloudflare Workers and Remix, hence the decision to store in KV and use that kind of architecture. We're keen to update JSON Hero with better local-only support for this reason, and to make it easier to self-host or run locally.

Hi there, good question! We're planning on using Cloudflare Workers for the API Gateway (great edge performance, simple programming & deployment model). we also have plans to allow customers to run their own code to modify requests and responses in the "gateway" by using Cloudflare Workers for Platforms.