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

Show HN: We built a developer-first open-source Zapier alternative

trigger.dev

Post reply on HN
Print view View original

1–10 of 196 posts

Show HN: We built a developer-first open-source Zapier alternative

#1

Post by eallam »

For the past few months we’ve been building Trigger.dev and can now share our beta with you: https://github.com/triggerdotdev/trigger.dev. Trigger.dev is an open source platform that makes it easy for developers to create event-driven background tasks directly in their code. You write workflows using our SDK, and can view all the runs in our web app.

Why we built this:

- We found current workflow / automation tools like Zapier and n8n are good for simple tasks, but not for more advanced use cases.

- Dropping down into code in these tools is just not a great experience. We prefer using our own IDEs, version control, and having access to GitHub Copilot etc.

- Sometimes, a workflow requires us to query a database or handle some sensitive information. It would be great if this data wasn’t sent to a third party.

Our beta version lets you:

- Trigger workflows from webhooks, custom events or schedules (CRON)

- Use API integrations with Slack, GitHub, Shopify and Resend. We’re adding more of these each week.

- Add delays of up to 1 year. Workflows will resume where they left off, even if your server has gone down.

- Support for Fetch and subscribing to generic webhooks.

- Observe every workflow run in the app (great for debugging).

- Open source MIT license so anyone can self-host the platform.

We’re still early so would love your feedback and opinions. Feel free to try us out for free – and if you want a specific API integrated, just let us know.

Main website: https://trigger.dev Github: https://github.com/triggerdotdev/trigger.dev

Show HN: We built a developer-first open-source Zapier alternative
trigger.dev

Re: Show HN: We built a developer-first open-source Zapier alternative

#2

Post by robbiemitchell »

Speaking as a tech-forward "business user" who uses Zapier _a lot_: a key benefit of Zapier is that it enables business users to work independently. Moving triggers and actions behind "developer-friendly" (i.e., developer-required) tooling caps how fast an organization can move on anything outside the critical path for product and strategy.

- Core transactional email flow? Great.

- Alerting Slack for non-critical activities elsewhere? Ehh...

Re: Show HN: We built a developer-first open-source Zapier alternative

#5

Post by sigstoat »

i think an open source zapier alternative would be a desktop app that had a nice UI, and synthesized terraform/FaaS code/API gateway-equivalent stuff behind the scenes and then ran it against my preferred cloud provider account.

not this, as convenient for some as it may be.

Re: Show HN: We built a developer-first open-source Zapier alternative

#6

Post by aliqot »

robbiemitchell wrote: post #2

Speaking as a tech-forward "business user" who uses Zapier _a lot_: a key benefit of Zapier is that it enables business users to work independently. Moving triggers and actions behind "developer-friendly" (i.e., developer-required) tooling caps how fast an organization can move on anything outside the critical path for product and strategy. - Core transactional email flow? Great. - Alerting Slack for non-critical act…

and suddenly at least one of us realizes why zapier costs money. the cycle continues.

Re: Show HN: We built a developer-first open-source Zapier alternative

#7

Post by lolinder »

robbiemitchell wrote: post #2

Speaking as a tech-forward "business user" who uses Zapier _a lot_: a key benefit of Zapier is that it enables business users to work independently. Moving triggers and actions behind "developer-friendly" (i.e., developer-required) tooling caps how fast an organization can move on anything outside the critical path for product and strategy. - Core transactional email flow? Great. - Alerting Slack for non-critical act…

They already address that specifically:

> We found current workflow / automation tools like Zapier and n8n are good for simple tasks, but not for more advanced use cases.

This isn't intended to replace Zapier for your use case.

Speaking as a developer who's been asked to set up integrations before, I'm glad to see more competition in this space with a developer focus!

Re: Show HN: We built a developer-first open-source Zapier alternative

#8

Post by eallam »

robbiemitchell wrote: post #2

Speaking as a tech-forward "business user" who uses Zapier _a lot_: a key benefit of Zapier is that it enables business users to work independently. Moving triggers and actions behind "developer-friendly" (i.e., developer-required) tooling caps how fast an organization can move on anything outside the critical path for product and strategy. - Core transactional email flow? Great. - Alerting Slack for non-critical act…

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.

Re: Show HN: We built a developer-first open-source Zapier alternative

#9

Post by cube2222 »

Looking at the long delays, do I understand correctly that this is something similar to Temporal[0] or AWS Step Functions?

My first sentiment was "when I'm already writing code, why not just use Lambda", but it looks like these delays are kind of the selling feature, and it looks like the UX is better than step functions.

I'd be curious about your selling points over Temporal, as I can't seem to find any comparison.

Good luck!

[0]: https://temporal.io

Post reply on HN