Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps

news.ycombinator.com

Post reply on HN
Print view View original

1–10 of 70 posts

Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps

#1

Post by eallam »

Hi HN, I’m Eric, CTO at Trigger.dev (https://trigger.dev). We’re a developer platform for building and running AI agents and workflows, open-source under the Apache 2.0 license (https://github.com/triggerdotdev/trigger.dev).

We provide everything needed to create production-grade agents in your codebase and deploy, run, monitor, and debug them. You can use just our primitives or combine with tools like Mastra, LangChain and Vercel AI SDK. You can self-host or use our cloud, where we take care of scaling for you. Here’s a quick demo: (https://youtu.be/kFCzKE89LD8).

We started in 2023 as a way to reliably run async background jobs/workflows in TypeScript (https://news.ycombinator.com/item?id=34610686). Initially we didn’t deploy your code, we just orchestrated it. But we found that most developers struggled to write reliable code with implicit determinism, found breaking their work into small “steps” tricky, and they wanted to install any system packages they needed. Serverless timeouts made this even more painful.

We also wanted to allow you to wait for things to happen: on external events, other tasks finishing, or just time passing. Those waits can take minutes, hours, or forever in the case of events, so you can’t just keep a server running.

The solution was to build and operate our own serverless cloud infrastructure. The key breakthrough that enabled this was realizing we could snapshot the CPU and memory state. This allowed us to pause running code, store the snapshot, then restore it later on a different physical server. We currently use Checkpoint Restore In Userspace (CRIU) which Google has been using at scale inside Borg since 2018.

Since then, our adoption has really taken off especially because of AI agents/workflows. This has opened up a ton of new 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).

You can get started with Trigger.dev cloud (https://cloud.trigger.dev), self-hosting (https://trigger.dev/docs/self-hosting/overview), or read the docs (https://trigger.dev/docs).

Here’s a sneak peek at some upcoming changes: 1) warm starts for self-hosting 2) switching to MicroVMs for execution – this will be open source, self-hostable, and will include checkpoint/restoring.

We’re excited to be sharing this with HN and are open to all feedback!

Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps

#3

Post by flippyhead »

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 ;)

Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps

#6

Post by martinkallstrom »

asdev wrote: post #2

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?

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.

Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps

#8

Post by jumski »

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).

Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps

#10

Post by eallam »

asdev wrote: post #2

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.

Post reply on HN