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?
Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps
11–20 of 70 posts
Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps
#12How 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.
Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps
#13Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps
#14I 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.
Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps
#15Congrats on the launch! Would love to do a collab for theunwindai.com.
Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps
#16Congrats 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?
Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps
#17I 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 e…
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.
Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps
#18[deleted]
Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps
#19Congrats 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.
Re: Launch HN: Trigger.dev (YC W23) – Open-source platform to build reliable AI apps
#20This 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.