Show HN: We built a developer-first open-source Zapier alternative (trigger.dev)
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
195 comments
[ 2.7 ms ] story [ 249 ms ] thread- Core transactional email flow? Great.
- Alerting Slack for non-critical activities elsewhere? Ehh...
I think what often gets missed and what gives zapier great power is the developer platform that can let devs build anything! I have a lot of custom integrations with apps that support use cases that afaik only I have. It is incredible effective.
> 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!
This is not an advanced use case to be developed in house and owned by developers. This is bread and butter marketing or product engagement email flows using anything from Mailchimp to customer.io to HubSpot.
The developer side would involve capturing the identities and events from your system and sending them (typically via something like Segment) to the downstream tools, where business users will manage those campaigns: flows, templates, content, integration with other flows, and reporting.
The next example is "Sync GitHub issues to Linear". Again, this is a fairly simple Zapier use case, probably using built-in integrations, or falling back to Python if needed. Zapier would store the credentials to both security and use a trigger/action flow.
I can see trigger.dev being more useful for things like:
- Schedule-based tasks, or super high-volume tasks. (These are expensive on platforms)
- That are driven primarily by code, not pre-built integrations
- Using private data (such as authorization tokens) you don't want to expose in plain text
Given there is undoubtedly a market of developers who want to bring things back into their standard codebase and code release practices, I suggest targeting the examples to situations to those more typically owned by developers.
The three categories of problems you identified that are best solved with a code tool are what we're seeing with our early customers. Plus a lot of notification use cases like when developers want to be notified in Slack when something important/bad happens.
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.
Based on the example shown, it looks like Trigger.dev handles all this while allowing you to write code pretty close to what I would call "in the normal way." I haven't tried it myself, but if the examples work as advertised, it looks pretty attractive to me.
If done well, that would be an advantage over Zapier since a non-technical user can start something basic, then have a dev look at it if they need to get more sophisticated.
This is what has made Excel and Access so successful—a biz person can get it started and have something tangible to hand off to a dev.
not this, as convenient for some as it may be.
Disclaimer: I'm a co-founder of Automatisch
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
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!
That was the final straw what led a friend and me to try to do what you’ve done.
We had started off using Zapier, and it’s horrendous objects & arrays handling, then moved on to Step Functions, then gave up on what we were initially doing to try and build a workable alternative.
With a cumulated grand total of 6 months of experience, we had no idea what we were getting into.
Anyway, the point is: thanks for making this.
Considering how much progress has been made since, and even though I haven’t gotten around to try App Composer for myself yet, I would tend to agree on both, with two caveats.
First, after Amplify, I am wary of any and all AWS "It just works™" claims.
It seems they have a hard time figuring out what "easy", "simple" and "straightforward" mean. And I say that as someone who very much appreciates Lambda, DynamoDB, EventBridge & co, and really wanted to like using Amplify.
Second, considering how expensive those can be to run, I would think twice before using them in a "high"-throughput and low margins scenario, and definitely appreciate there being alternatives.
Regarding Workato… I’d never heard of it. But the description they picked for Google and their landing page makes it clear who they’re appealing to and on what grounds. Sorry you have to deal with that.
But something
- offering a clear visualisation
- and allowing to simply integrate with third-party APIs
- without having to deal with some’s quite obscure documentation
while at the same time
- easy to monitor & debug
- offering versioning
- allowing to just write a few lines instead of going through pointy-clicky drag-and-droppy mess
Yes, that was lacking. Reminds me of Zenaton (https://zenaton.com/). I can only wish you to be more successful than they were.
I've just been waiting for someone to launch BestCloud as a competitor.
The license says "All content that resides under any "ee/" directory of this repository, if such directories exists, are licensed under the license defined in "ee/LICENSE".", but there's no folder named ee? What is this referring to?
We'll be working on self-hosting instructions soon as well :)
I haven't had a chance to go through your site yet, but that would be a killer feature to have.
I think trigger.dev nails it. This is exactly what I needed.
Was a dealbreaker for me.
It's still a mess to manage arrays and arguments auto-split by commas
1. I want a proper IDE
2. Proper typing so the feedback cycle is faster.
3. Being able to use external packages
4. Being able to quickly test my custom node across old runs.
Their JavaScript nodes take me an absurd amount of time to get right. And I've needed to use them far more often than I would like.
Despite them being GUI based, you can do everything that temporal enable, approval steps/suspending workflows until being reactivated by a webhook, branching, etc, etc... It's 100% open-source and self-hostable.
https://news.ycombinator.com/item?id=31272793 (9 months ago)
A contributors guide? Documentation? A PUBLIC ROADMAP!
THIS is an example of open source done well.
The example repo eallam shared has more though, we will be moving all of them to the docs soon!
The workflow code is in your codebase and runs on your servers, we don't host that.
We host the service that triggers your code (using events like scheduled, webhooks, customEvents) and that you can call using our SDK to do requests, logging and delays inside the workflow (e.g. using our Slack integration or using our fetch that auto-retries with exponential back-off). We also host the web app that you use to authenticate with APIs, show all of your runs with associated data and any errors.
Soon we will add a self-hosted guide so that you can also choose to host the Trigger.dev service yourself too. It's a bit hard to explain, hopefully this clears things up!
My thoughts -
1. I don't see proper secret storage being handled. You typically don't want your API keys in your code. What would you recommend instead?
2. "OAuth" based secrets. Many integrations require giving access to an App via OAuth, which involves a flow. I think that's being handled internally from the video [1] and from this project [2], but it's not clear. How is that handled?
A common use case I'd automated once is that when a GitHub project gets starred, the developers public information is scrapped and they are then followed on Twitter, if their twitter handle is found. With Trigger.dev, the twitter part isn't clear.
3. Error Handling - What about when some job fails to run? I understand there is a delay mechanism. But what about injecting custom error handling? Sending a message on slack, for example.
4. Dashboards - They look awesome. And I get the impression that each "action" in the code is mapped to individual blocks in the dashboard. I'd love to be able to see a proper graph of the flow.
I love that I can see the json request / response for each. It'll make debugging easier when some API changes or fails.
5. No Code solutions - In the long run, I can easily picture writing the integration I want in plain text, and having Github CoPilot or ChatGPT generate the code for me, and then I can quickly modify it.
6. Incentive for integrations - As with most automation tools, entering the market is challenging as you're lacking integrations. The awesome thing about ActionsFlow [0] was that it was re-using an existing community of GitHub Actions, and therefore you don't start from scratch. Have you thought about reusing workflows from n8n or other projects?
7. Integrating with existing Automations - I think a bit more focus should be made on integrating with IFTTT / Zapier / n8n. I see you provide webhooks, but I think some easy wrappers + documentation would be better. This way, I can try out newer workflows in Trigger, and easily just extend my existing system. And then if Trigger.dev works for me, I can think about migrating away from my existing automation solution.
8. Open Source Longevity - Trigger.dev is MIT licensed. Could you please explain the rationale? How do you plan to combat someone launching a competitor using your code? N8n is deliberately "Soure Code Available" and not "Open source", which I thought was a decent compromise. Will you be following a more Open Core model similar to GitLab (which is also MIT licensed)?
9. De-coupling runners and the dashboard - I'd love to not have the pain of maintaining the dashboard / event listeners, but being able to control the running of the jobs. Similar to a CI or Airflow.
10. Support for other languages - This is something that Dagger CI [3] now allows. Letting you use whatever programming language. With Github Actions, I can just package it as a container. Do you plan to support anything else?
After moving from using HCL to Typescript for my Terraform code, the advantage is so great, that I can't seem myself going back to using a custom language such as Dagger's CUE [4]. Trigger.dev targeting Typescript is already a big win. However, I do have a number of automations in Python.
Overall, I'm super optimistic. Congratulations on the launch.
[0] - https://actionsflow.github.io/
[1] - https://www.youtube.com/watch?v=aFlwD0frvnQ
[2] - https://github.com/triggerdotdev/Pizzly
[3] - https://dagger.io/
[4] - mattaitken ↗ Thanks for such an amazing reply, I'll do my best to answer everything. I am also on the Trigger.dev team btw. johtso ↗ "4. Exactly right, each "step" is a block in the UI with clear inputs and outputs. We would really like to have a graph view. That'll be especially useful when you put loops in the code, and of course branching." rubenfiszel ↗ We support both typescript and python at windmill [1]. But our model is doing low-code for the workflows, and actual scripts/code for the steps themselves so it's quite different than trigger.dev. We handle OAuth, refresh tokens and secrets being managed by the platform. It's quite different from trigger.dev considering they are doing workflows entirely in code which has some pro and cons.
1. Your API key with us can either be passed into the Trigger constructor or you can use our TRIGGER_API_KEY environment variable. For the API integrations we provide, we handle API keys for you and they're added inside the dashboard UI. For everything else: as the workflows and files are just code on your server you can use environment variables (or your preferred alternative) to inject secure values.
2. When a workflow step that requires OAuth is hit, the workflow pauses and prompts you to sign in. After you've signed in the workflow continues where it left off. You only need to connect each service once per organization. You can sign optionally in multiple times to the same service and switch connections where needed, e.g. multiple separate Slack workspaces.
GitHub star to Twitter follow is a great idea. You could achieve that right now by using our GitHub integration and our fetch call (which auto-retries with exponential back off and logging in the dashboard). We'll add a Twitter integration soon so this is really easy and publish it as an example :)
3. We have detailed error messages attached to the step that failed but don't currently have a way to hook into this like you describe. This is a great idea, I've added it to our task list.
4. Exactly right, each "step" is a block in the UI with clear inputs and outputs. We would really like to have a graph view. That'll be especially useful when you put loops in the code, and of course branching.
5. 100%, making this work well with AI code generation would be great.
6. This is a great idea, we'll investigate. Rather than just mapping 1:1 with an SDK we're trying to make the experience better. For example, with the normal Slack API you can't post to a channel name, you have to use an id. We make it so you can use the name and we deal with the hassle for you.
7. We'll look into this too. Integrations for interoperability could make this easier.
8. We're going to follow the GitLab/PostHog model. Like GitLab, the repository as a whole is MIT licensed but we can add some /ee folders in the future with enterprise features. We feel it gives us the right balance of being open source and gives us some protection from a competitor hijacking the project.
9. We will separate out the dashboard from the runners – this was a compromise so we could ship the first version faster.
10. We can relatively easily ship other languages SDKs and Python is probably where we'd start. Our core backend code will most likely remain in TypeScript.
Thanks again for so much feedback!
I can't help but think that you want a state machine here, rather than imperative code that's being analysed to try and get some kind of a graph out of it..
I'm personally looking forward to a cloud, state machine based service that offers the whole long running workflow thing. The closest I've seen so far was people using xstate within temporal.io workflows.. but would be amazing to have really nice observability out of the box, with all the clarity that state machines bring.
[1]: https://github.com/windmill-labs/windmill
That would improve discoverability as well !
Especially since a project going from one to three, and in the rare case four or five, folks is pretty common, but hitting 10 team members is a serious project milestone. At 10, you're probably also starting to look at funding. These plans are missing a tier =S
(people seem to be falling over themselves trying to read this as someone who works for a company that can afford this service complaining there should be a plan that lets them pay less for it. Instead, take a moment and remember there's an entire unpaid open source ecosystem out there, with devs who can't afford Zapier, don't have 50/mo to spend on automation for a project that gets used, sometimes by billion dollar copmanies, but no one is paying them for, and who might still want to pay for a service like this at a tier above "free". Does that mean "trigger.dev must add a tier"? no of course not, but it would be great to understand why there's nothing between free and business plan pricing)
If you use and benefit from a product that saves time for 3 (usually the most highest paid) employees in the business (developers), you either need re-evaluate how much value this product provides or re-evaluate your business plan.
I'd implore the OP not to get distracted by this sort of feedback: any serious business user will be more than happy to spend $50/month on a service like this. Trying to cater to people who are this price sensitive is a recipe for an unprofitable nightmare.
And of course, "it's open source, just install it on your own host" is a perfectly valid response, but "you have money, what are you complaining about" is maybe a little ridiculous given that people can voice concerns for an entire class of folks, not just themselves. $50 is a lot of money for a lot of folks in open source.
Asking a company to sell their services to everyone at a huge loss because a minority of open-source projects can’t afford their service is more ridiculous.
I have no beef with your point about open-source developers having very limited budgets, but it’s very important to contextual your feedback. You specifically talked about teams of multiple people, it was unclear you intended to describe a very niche situation.
You have to sell SO many of those plans for them to become worthwhile.
It's a lot easier to sell 100 $50 accounts than it is to sell 500 $10 accounts, and you end up with customers that are more likely to increase to even higher tiers in the future.
[1] https://trigger.dev/pricing
[1] https://temporal.io/
i.e. pay for what resources you use instead of how many users you have. This is how we pay for AWS/GCP/Azure. I think a lot of dev SaaS could / should go this way.
They have a full in-browser editor that handles many-to-many API integrations with autocomplete and helpers. They also have a CLI that lets you work with your favorite editors.
https://www.val.town/ernest.newCitationNotification
I'm the founder of val.town, so email me if you'd like help setting this up. I'd be more than happy to pair program with you on it. My email is steve @ val.town
With SDK examples you have to set up a code project, install the SDK, add some boilerplate code, make the API call, and figure out out to display/use the output. Ugh.
With curl examples you can run the example with no set up, just a little customization. You just run a single command. Easy-peasy.
That's like, exactly what we are, take a look at this screenshot for instance: https://github.com/windmill-labs/windmill/blob/main/imgs/win...
As for syncing code to git, we do it as well through our CLI and Github Actions: https://github.com/windmill-labs/windmill-sync-example
Can I ask, what were the benefits of writing a new workflow engine instead of building around Temporal?
1 - https://github.com/huginn/huginn
Overall it would have been possible to build this on top of Temporal but the biggest benefit of Temporal, which is idempotency/checkpointing is not something we could have offered at the level of abstraction that we operate, running arbitrary single scripts piped together using a result graph and a shared mounted folder. So why bother?
[1] https://docs.windmill.dev/docs/intro/
What else makes this Trigger.dev stand out compared to Temporal? Temporal already has self hosting option, multiple language support and a battle proven history. Even if trigger looks good on paper, it would need some other really convincing reason for me to consider a completely fresh tool over something more proven, that appears to fill the same space.
Good to see some competition in this space though. Workflows are too important to be relegated to flaky scripts, diy workflow engines or worst of all: yaml-as-code.
Scaling takes a lot of expertise, and I'd say almost everyone saves time & money and gains in reliability by using Temporal Cloud over self-hosting.
But most important, no one knows how to say "Zapier". Is it ZAHpier or ZAYpier?
All the points you mention, can be fixed by zapier. Then the alternatives do have a moat.
What people are missing is the fact that executing a GTM the way zapier did is more that just building the product and is actually very hard.
Zapier seems to be the best way to get stuff done quickly and cheaply but not the best for long term high volume use as an integration platform. At my old job we migrated a from Zapier to Integrator.io, which fixed the reliability issues but broke the low barrier to entry.
How does this compare to something like Prefect?
If there are any other tools folks would suggest to achieve what I'm looking for, I'd love to hear about them!
Additionally, this seems to rely on you inputting your credentials. How would that work for a usecase where my customers are the ones who provide the credentials?
On the UI, you can customize the credentials with a connection variable which is what enables in-app product integrations. We have users who are doing this. Shoot me an email if you'd like to explore our approach: ash@activepieces.com
If I'm reading correctly, to build features on top of Windmill requires the commercial license even if self-hosting which comes with a price of $.002/ computation where a computation is 1 second of processing on 1 CPU with 2GB ram.
One of my main usecases would be to create flows to pull data from various sources. The speed of such processes often depends on the 3rd party APIs - so it wouldn't be unheard of for a process to take 30+ min to pull a bunch of data where much of the time is spent on data transfer or waiting for the service. Does that mean it would cost me .002 * 60 * 30 = $3.60 for one 30 min data sync? That's not including any downstream etl I might do that would potentially multiply the cost. Curious if that's accurate or if I'm misinterpreting something.
Your calculation is correct and I agree it is a bit of a steep pricing. Most companies have small scripts to run and we wanted to bill according to the value they were extracting of the product and do transparent enterprise pricing instead of the usual "contact us". Unfortunately, it is not a one-size-fits-all situation. For data heavy/IO bound workflows, we should bill per number of GB transferred rather than per computation. In any case, we are very open to do price capped contracts depending on your use case: ruben@windmill.dev
I'm doing some more research but will keep ya'll in mind and reach out if I have more questions!
[0] https://airbyte.com/pricing
This is an itch I'm waiting for someone to scratch
We are focused on CRMs / Marketing tools for the next couple of months though.
https://www.nango.dev/ for reference.
[Edit: Added link to Nango website]