At first I thought that a code alternative for a no-code solution like zapier was counterintuitive. But as an engineer using Zapier (for the first time) these past few months I got so frustrated by the lack of an option to just write some "if" or just 2 lines of code to make things work the way I want them.

I think trigger.dev nails it. This is exactly what I needed.

Trigger.dev looks like it would be amazing if you want a simplified temporal that is still 100% code based and exclusively in Typescript. If you are looking for a Zapier-for-developer experience, we took an alternative route at Windmill of allowing Python/Javascript/Go/Bash as steps but the workflows are still GUI based: https://github.com/windmill-labs/windmill/blob/main/imgs/win...

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.

Interesting. Here's a previous discussion about Windmill:

https://news.ycombinator.com/item?id=31272793 (9 months ago)

Be still me heart!

A contributors guide? Documentation? A PUBLIC ROADMAP!

THIS is an example of open source done well.

n8n is also great about this. It retains the visual “easy mode” environment but lets you drop in a JavaScript node whenever you need to do something more complex

I found the JavaScript nodes to be quite annoying. Specifically -

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.

Wow, I’m never gonna try to build a tool for developers

All of the list and they also want to pay you $0. $20 sounds like a robbery. Meanwhile it costs 20 minutes of a freelance time.. for the whole product.

Zapier has a python / JS code step (basically a AWS lambda) you can use to do something like this. Downside is that it has a timeout of 10s

Huh cool thanks I didn’t know that! I guess it’s just another action and not something “native” to Zapier (so if you want to later connect it to some off-the-shelf action you can’t).

You can connect code steps to other actions. For example, every Python code step has a reserved `output` variable which allows you to pass a list out to the next steps. It gets passed as stringified JSON: if it contains dicts, those values are made available automatically as inputs to other steps. You can also pass more complex, nested JSON and just json.loads it later.

And the second downside is that you don't necessarily get the same data as the normal no-code steps...

It's still a mess to manage arrays and arguments auto-split by commas

I have the same thoughts. I tried node-red and I got frustrated having to do all this drag and drop stuff for something I could code easily.

Also look at https://pipedream.com/

Think that's why they also have built Pipedream.com (not affiliated)

You should try make.com. It is great!

Last time I tried make.com, they couldn’t run scenarios in parallel: every subsequent run had to wait for the prior one to finish.

Was a dealbreaker for me.

This looks great, congrats on the launch! I am interested in a platform that bundles many pre-built integrations to various services that I could wire up through code and execute on my customers' behalf. Essentially, a way for me to present my customers with a plethora of integrations out of the box without having to build them all myself. This seems like it's moving in that direction and I saw another comment where you mentioned workflow execution on customers' behalf in the future which is great!

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!

We also do this at windmill: https://github.com/windmill-labs/windmill

This is interesting, thanks for sharing! It took me a little bit to process all the content but I think I get it :)

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.

You do not need the enterprise license to run this self-hosted, only if you want the commercial license version of AGPLv3 + support/SLA and some high scale plugins like our dependency cache syncing.

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

Makes sense, thanks for the reply! Pricing may be steep compared to diy but as a comparison, Airbyte Cloud seems to charge $10/GB or $15/1M rows transferred[0] which seems like it would be even more expensive.

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

> Essentially, a way for me to present my customers with a plethora of integrations out of the box without having to build them all myself.

This is an itch I'm waiting for someone to scratch

We do exactly this at https://integration.app, including ability to manage flows via API.

We are focused on CRMs / Marketing tools for the next couple of months though.

We do this at Activepieces (activepieces.com).

Is there an API or SDK for creating/managing flows? I want the flexibility to programmatically wire these integrations together rather than a nocode UI

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?

Not yet, we're probably on the way there as we're exposing all our pieces (connectors) as typesafe npm packages. But for now, flows are built with the no-code UI. The workaround is to write all your code in one main Code step in any flow. Our web IDE is VS Code so it's not too much different, and we can be self-hosted.

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

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

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!

The first example on the homepage is "Create an email drip feed campaign in under 2 minutes"

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.

Thanks, this is great feedback. You're right that these examples don't highlight the real advantage of our platform vs no-code tools. We're going to add some new examples to our site based on what our customers are building.

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.

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.

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

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.

It’s not hard to imagine a template library or code generator that sits on top of this code layer that’s more approachable to non-technical users.

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.

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

Comes up all the time. There was another tool like this (huggin?).

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.

I had a lot of bots in Huginn, but the amount of tending that the garden required versus and the developer experience were never good enough that I kept them going. I found myself doing all the JS editing I needed in VSCode and coping it back and forth, which is a bad experience. It definitely saved my butt a few times over the last few years, but I am anxious and excited to swap it out for this.

Did you mean Huginn? (https://github.com/huginn/huginn)

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

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!

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

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.

Now that AWS App Composer is a thing is this still an issue though? I felt that pain in the beginning, but once you get the hang of Step Functions it doesn't seem so bad. I never found a good alternative. My company is using Workato and it's a nightmare.

I should have mentioned this was more than 4 years ago. I remember having to use a Choice State to hack together my own looping mechanism.

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.

Thanks! That's been our experience exactly and is the reason we're building it. The experience of AWS step functions on one extreme and Zapier on the other.

Oh, no. The other extreme wasn’t Step Functions. It was AWS Lambdas stringed together through DynamoDB Streams, SQS, SNS and S3 triggers, all obscurely tied together in a murky single-file yaml template deployed by JAWS (now the serverless framework, which has definitely made some much-appreciated improvements).

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.

Just reiterating what a lot of other folks have said in this thread already, but this scratches a pretty real itch for some stuff we (and our customers) have been thinking about at Mux. Zapier (and similar) is just a little too high level for a lot of our needs, but Temporal feels like overkill. Extremely excited to play around, congrats on the launch!

Thank you, really appreciate that comment. That's the bracket we see ourselves in, and for the same reasons (as product builders).

I was recently looking for a simpler alternative to Temporal (https://temporal.io/) so this could be ideal. If you could add instructions for self-hosting it (_sounds_ like you just need an Express server, but I would guess some backend persistent store/database/queue too) that would be great. The Webhook catalog only lists Github: I think integrating with Stripe would be neat. Like, when someone pays an invoice, Stripe calls a webhook. That could trigger an action.

"A simpler alternative to Temporal" is a good description for us. We'll get a self-hosting guide up soon for you. We're adding integrations that people ask for as fast as we can build them and Stripe is high on that list :)

As someone curious to try out Temporal. What makes you think it is not simple, is it tricky enough that one should avoid it?

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.

I share that curiosity! Temporal looks great and is proven. Running it looks simple enough. I mean getting their self-hosted version deployed (to production). I was reading through their docs and that does _not_ look simple (to me). Plus the guide is open about being a work in progress (https://docs.temporal.io/cluster-deployment-guide#elasticsea...). I am going to try it at some point though.

The simplest way to self-host is with Render: https://render.com/docs/deploy-temporal

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.

We do this at windmill https://github.com/windmill-labs/windmill, including self-hosting instructions and pre-made integrations with stripe

Does windmill have any way of going into code, without it basically becoming "code in a input box". The developer first solution trigger.dev have here is really scratching a real problem. But as they say they are not for the easiest workflows. I'm really looking for something that is gui first but as a drop down to code when you want. But inline code editor, let me save it to a git repo or similar. And don't have globals aka zapiers inputData and output.

> I'm really looking for something that is gui first but as a drop down to code when you want. But inline code editor, let me save it to a git repo or similar.

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

WOW. I have been looking into this at work today, and windmill is def. what I was looking for, a low-code solution that do not hate code (as text). Thank you so much for creating this. The value prop. that you have in the intro[1] is perfect. The first paragraph on github is maybe correct. But I'm still not sold on what it actually does. Marketing is hard. Hope you will succeeded, the product looks great!

[1] https://docs.windmill.dev/docs/intro/

Windmill looks cool! I've always wanted to write something like Huginn [1] available as a single binary.

Can I ask, what were the benefits of writing a new workflow engine instead of building around Temporal?

1 - https://github.com/huginn/huginn

The biggest reason is to be able to deploy, as you mentioned, windmill as a single binary that you can then easily scale horizontally. The second one is deeply rooted to how it works, it is running fork of those scripts calling the interpreter of those respective languages. It has pros and cons but you can do interesting things like having workflows in different languages, first step in python, second step in go.

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?

Ah, ok. Thanks. I'll take a look at that too.

Would love this self-hosted.

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

A little while back, I was working with a startup that built an AI note taking app. They offered several integrations for their customers, and at the time I wished that there was a Zapier alternative that allowed for a multi-tenant approach (i.e. build a pipeline that each customer could independently hook into with their own external accounts).

I haven't had a chance to go through your site yet, but that would be a killer feature to have.

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

When you look at self-hosting instructions then it would be great if it would be one that does not require Docker in your stack. Installation shell script would be even better.

This looks interesting.

Recently I needed some really infrequently executed background workers. Basically just generate a CSV from our DB, email it somewhere. Historically I'd setup a Redis backed worker queue for background jobs. However, right now the aforementioned job is my only background processing requirement and it's massively overkill since serverless is supposed to take care of the infra headache for me. What I found was a surprising amount of BS to get serverless runners doing what you want - there's execution limits, trigger limits, terrible developer experiences (depending on the platform) etc. If you're already invested in a serverless ecosystem, this isn't a huge deal, but for the odd one-off task, the current options are kind of terrible. Supabase edge workers for example are way too limited for this use case. Cloudflare Workers (with the queuing stuff in beta) are probably the best option. But your batteries included approach seems super appealing for this kind of stuff. That said, I think you're in for a hard time marketing this. It requires devs to have "learnt the hard way" before they understand your value proposition.

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!

Missed an opportunity to call it Zapiest

Where were you 2 months ago!

Keeping their Zapier wit to themself.

LOL Good one indeed!

That would probably get them in trademark troubles.

NotIfThisThenThatButUs

TryThisCatchThat

I've spoken to many IT professionals over the years that have been frustrated with BetterCloud.

I've just been waiting for someone to launch BestCloud as a competitor.

Maybe BestCloud was the OG, usurped by BetterCloud.

I used to joke someone should make a better exchange mail client called ‘Lookout’.

Either "trigger" is a blacklisted word or your domain is on a list somewhere, because my company has this url blocked under the "weapons" category. That's unfortunate.

Would be willing to bet your connection has an over aggressive blocking system going on

I'm not see the site blacklisted, I'm outside of usa btw, but inability asume is probably internal policy

Ugh that sucks, sorry. We love the name but the only thing holding us back was the association with guns.

Hey just giving you guys feedback. The emojis are a bit of an issue. NocoDB has this issue as well. If I want to use this at work it's a lot harder sell because of the emojis and statements like "it's blazing fast!!"

For some businesses, it has to look super straight and serious, and give the impression that it's secure (which doesn't necessarily mean writing "we're secure!") Like copying the style of Microsoft Office would be the best. Google Docs or Zoho would be ok too. Of course it's great that you got through YCombinator and pitched, etc. But giving the impression of "Woo! We're a startup!" makes it seem like the company may be gone soon. It could be an issue because the company may not want to change their workflow if it won't stay stable for at least 5 years.

To sell to a more generic established business, it might be better to look like a company that has been around and isn't going anywhere. Like for Microsoft Office, the assumption is that it's secure and your data never leaves your PC.

If I could easily port my business’s Zapier integration [0] to this (or any other Zapier competitor), I absolutely would. But after writing and maintaining the Zapier integration, it’d be too much effort unless the ROI was really high.

[0]: https://github.com/keygen-sh/keygen-zapier

Hey there! I really like your service. What's your tech stack?

Mainly Rails. Some Go.

Cool. What did you use Go for that rails couldn't do (or do well/scale), if you mind me asking?

First version of the distribution API was a Go microservice. But that microservice is now deprecated and its replacement was rolled into the main Rails app. That microservice streamed large files (so I went with Go), but I nixed the streaming and Go was no longer needed.

The CLI is also written in Go.

Thanks!

Have you contemplated making the backend open source or at least source-available ("Look but don't touch", you may only use the hosted service, etc)? Would love to take a look at the implementation

*looks around*

I haven’t announced it yet -- but yes. Working towards open sourcing everything. :)

Oh wow!! That's actually amazing! Thank you so much.

I promise I'll keep the secret till then :)

Oh god thank you for your work.

Jumping from free to $50/mo feels like there's a 4.99/9.99 plan missing somewhere. Just because you have 3 people on your team doesn't mean you can casually spare $50 a month, that's a lot of money to the vast majority =(

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)

^ this here is the reason why I never want to build SaaS products for developers.

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.

You have to account that not everyone is working in the US. For someone earning 15k$ per year, 600$ is not little money.

Please tell me where I can hire developers for $15k per year.

Good/Fast/Cheap. You only get one.

Professionals drawing a paycheque, or folks working on a product? Sure. Open Source that no one pays for even if the users inclulde multimillion dollar companies because "it's open source, why should we pay anything"? No.

The problem with $10/month plans is that replying to a single support email relating to them can swallow your margin for the month and result in a net loss on that customer.

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.

While true, the free tier already comes with email support [1] so I'm not sure a $10/mo tier would have any impact in that respect?

[1] https://trigger.dev/pricing

You work for a billion dollar company, are you speaking from your perspective as a software engineer or... something else? Price sensitivity as an individual is understandable but when you're talking about a team I struggle to understand why there's a meaningful difference between $5 and $50. For a business, if software is valuable enough to use, it's valuable enough to spend $50 on. Plus, $50 is below the threshold most businesses have for discretionary purchases.

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.

Maybe, and this might be confusing, folks didn't always work where they do today, and have experiences based on "I don't have money but I work on a project with 5 others that the world seems to use a ton, but no one's paying for". "A team" and "a business" are not the same. Running a business? Pay for team tier. Open source project that just has more than 2 people organized in a team? I'll let you think of that one.

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.

The situation you’re describing is exceptionally niche and one in which you can simply reach out to the company and ask for accommodation: there’s thousands of open-source projects sponsored by for-profit companies by granting access to paid services for free (your employer is one of them, Fastly sponsor a bunch of projects by giving free CDN).

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.

It's literally the situation I was in before so: why are you trying so hard to gaslight what is a perfectly valid question? They probably have a good reasons for there not to be a middle tier: if so, cool, but it feels missing so hopefully they read HN comments and can explain why the first paid plan jumps straight to $50.

A challenge many startups face is undervaluing their service. You started out by saying that their service was too expensive — “that's a lot of money to the vast majority =(” — which is the sort of complaint that induces founders to think they need to lower their prices. They don’t. Most startups should be charging more. $50 is nothing to the customers that Trigger want to attract in order to succeed.

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.

Thanks for the clarification. I took your comment as a personal assault from the phrasing, accusing me of being a hypocrite because I happen to draw a paycheque these days. Thank you for explaining that wasn't the intention.

Honestly it just sounds like you don’t need it that bad

What a weird reaction to someone voicing the question that open source devs will have, for a project that literally says it's dev-first.

Not really - three teammates and the issue is paying $50 a month?

As someone who got burned by past "Open Source" projects, yours raises all redflags:

- Advertised as "Open Source", yet this is actually a paid product with a pricing page.

- You don't even have a guide on how to install this thing... euh, I mean what's the point of this if I can't use it?

- You have a complicated license: https://github.com/triggerdotdev/trigger.dev/blob/main/LICEN.... You might have an "open" source as anyone can see the source but it's not as open as say an MIT license for the whole project.

- Your pricing conflicts with your open source users. You need them to build and improve the product but you also want them to have a worse experience otherwise your cloud-hosted solution will not prevail.

First off, thanks for this feedback – it makes it clear that we need to do a better job.

We're following the GitLab open core model. Our licensing is the same as their's (and many other open core companies).

This means that all existing code and the vast majority of future code will be under the MIT license. At some point, we will add some enterprise features that are in /ee folders and they will be licensed differently. This is to protect us against a competitor taking the code and launching an alternative hosted service without any effort on their part. We felt that this was a friendlier option than going with something like AGPL.

Sorry that our self-hosting guide isn't available yet, we will get it up really soon. We want people to use Trigger.dev and that includes self-hosting.

There are lots of open core companies that have a cloud version and the ability to self-host. I don't think that our business model conflicts with being open source – anyone contributing will make the experience better for everyone (cloud or self-hosted).

Hopefully this answers your questions and helps to alleviate your worries about the project. We are big believers in open source and have thought hard about how we can create something valuable for everyone.

I’m having trouble seeing the issue here. It’s not uncommon for open source projects to offer hosted services for a price. Seems like a reasonable way to generate revenue to me.

I’ve dabbled in self hosting, and I enjoy it, but sometimes it’s not worth my time and energy. If there is a product I really like and gives me value, I think having the option to pay them to host is a win/ win. I’d rather have that option then not.

As far as the missing self hosting guide, there is a section for it at the bottom of the README that says “Coming soon”. They stated they have only been working on this for a matter of months, and this is an early beta version. I’d imagine the team has been fervidly working on the core product & features, therefore finishing this part of the documentation keeps getting punted down the line.

It’s clearly going to be an option, so I feel like your judgment is a little harsh. I’m willing to be patient, and test drive the product on the free tier in the mean time :)

I always check the license first and this is not too nice. These mixed licenses are a real nightmare for companies and their lawyers. Keep it clean & simple or there won't be a lot of adoption really.

We're using the open core model that Gitlab use. It's popular because it mean 95% of the code is MIT (good for everyone) and a small number of enterprise features are under a different license. This puts off bad actors from building a commercial competitor with zero effort. The alternative we considered was AGPL but that felt worse for our open source users.

I don’t see an ee folder or ee/LICENSE so according to their license, everything in their repo seems open source although annoying they did this instead of just a real OSI recognized license.

Not having install docs isn’t the end of the world if I can figure it out and contribute back. But I don’t want to waste my time if it’s not actually open source and my work will be commercialized by a single org.

I don’t mind contributing for everyone to do whatever (including commercialization) but am not into doing free labor for a profit enterprise.

All the code that has been pushed so far is under MIT and we currently have no enterprise features (/ee folders). The majority of future code will fall into this same bracket.

Some features that are for "enterprise" will be put in /ee folders – ideally we will put all of that in a single /ee folder in the root but we wanted to cover the case where that's non-trivial to implement.

This open core model (that Gitlab use) is popular because it strikes a nice balance between having an open source project (good for everyone) and it puts off bad actors from building a commercial competitor with zero effort.

The wording suggests to me that there can be ee/ subdirectories scattered all through the directory tree, and within those the different licenses apply.

self hosting feels like an afterthought. That's a red flag, it means they actually don't have any open source users or ecosystem.

Right? They advertise as an "Open-Source", MIT and self-host. But then they make it difficult (you need to figure out how to install this thing, lol). That would be understandable if this was done pro-bono (the paid service didn't exist). But they have a team and a paid service behind me.

It's not the model that bothers me (if you want to mix OS with SaaS/Paid, then it's all good) but the false and dark-pattern advertising.

Really sorry about this – we are working on a guide and it will be released soon.

If you're looking for competitors in your space, it's worth checking out Autocode too: https://autocode.com

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.

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

Is there a brief description of what each example is? After following that link, I was just looking for one or two sentences, without having to look through each script.

We have a few examples with descriptions in the docs here: https://docs.trigger.dev/examples/examples

The example repo eallam shared has more though, we will be moving all of them to the docs soon!

Please make curl example on how to send custom event , instead of using nodejs sdk ?

Yes, the best API documentation includes curl examples regardless of any other examples.

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.

Is this any way related to the Nango & Pizzly projects? I see they're mentioned in the docker-compose file.

https://www.nango.dev/ for reference.

[Edit: Added link to Nango website]

We are using Nango (formerly called Pizzly) for our OAuth integrations. It's a fantastic way of making it easier to do OAuth!

This looks great. I'll have to play around with it.

Related, we built a developer oriented Zapier clone for event scale automations awhile back for our internal product. We've since pivoted and have been debating on potentially open sourcing the engine as well.

We built ours using Rust with a DSL for all the triggers, actions, and action inputs/outputs. The actions themselves are defined as APIs, which makes it easy to add functionality in any language. Most of our actions have been built in Typescript.

Is there interest from anyone in potentially using it?

Yes, definitely. Put it on github, create a discord and see if a community forms around it.

I'm always interested in seeing alternative solutions to this problem.

For once, I'd love to have a nice UI around this so I don't need to search docs and write code for simple stuff like "await ctx.waitFor({ hours: 3 });".

That would improve discoverability as well !

All the example use cases seem to be for non business critical stuff.

Is this being sold as a tool that I could use for.. say.. persistent workflows for customer payments? Say I needed to take payment, and make sure that a ticket is reserved using a 3rd party api once the payment is successfully processed, refund the payment if there's some kind of problem, and then I need to send a confirmation email.

Can I store and query state on the workflow? In my code can I `await` the completion of a workflow and get a result?

Zapier is very easy to use - everything you want to do/learn is in the no-code interface page, no need for reading documentation. This (as a developer myself) seems very complex to use. I have to read each integration's library, and also use Typescript (why not JS or something more popular?), at which point, I may aswell just write code and use an API.

We think Zapier is a fantastic product and we've used it ourselves many times. But it's more focused on simpler use cases and we found ourselves hitting the wall and then being frustrated that there wasn't a good alternative that could live in our code.

You can use JavaScript and will have a great experience – all of our code is in TypeScript which means you get a really nice experience as either a JS or TS developer.

+1 to this problem space. Resonate a lot with the gaps with Zapier, particularly around the need for escape hatches/conditional logic when needed––one of the reasons we built Retool Workflows! https://retool.com/products/workflows/

Are you hosting or am I? The marketing implies that I’m hosting but your FAQ, at the bottom, says you are. Can you please clear up?

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.

In the meantime, maybe remove "Your workflows run on your servers, not ours. We only receive the data you choose to send to us." from your front page marketing?

The website is correct, it's just a bit confusing so I'll explain more here:

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!

lol, I need a diagram.

‘Developer-first Zapier alternative’ is an odd positioning, I think the point of Zapier is that it’s for non-developers mainly. Looking at the comments, though, it seems like there’s a need for something like this. Keen to see how you iterate and improve your positioning. Good luck!

My experience with Zapier is that you quickly hit a point where you’re building an ultra complex expression or manipulating json in a less than ideal editor. Also your zap is basically the ast of the code you would have written and grows quickly. Code is far more terse.

That said, long running durable workflow tools that are targeted at devs all have challenges. There’s room for a Goldilocks solution. I’d imagine temporal will win though.

I'm very unfamiliar with this family of tools, but if anyone knows a tool like this that can monitor arxiv or Google scholar for new papers matching a particular query, I'm very interested. I checked Zapier recently but I didn't see these among the support apps.

This is definitely something you could build in https://val.town. Someone made a little daily query that checks for new citations on a particular paper:

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

In Google Scholar, after your search there will be a button at the end of the page (on mobile, maybe somewhere else on desktop). The button is "Create alert" with an email icon by it. Select this and there will be a form for where to send the alert and the query. Click "Create alert" to get automatically notified of new results.

Neat! This seems like it work be great paired with a low/no-code backend like Hasura or Supabase.

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.

There is an open source Zapier alternative (https://automatisch.io) even though it's not a desktop app.

Disclaimer: I'm a co-founder of Automatisch

We do not provide a desktop app, but we provide the FaaS and instructions to self-host wherever: https://github.com/windmill-labs/windmill

How does this compare to Pipedream and Windmill, both of which are also open-source?

Founder of Windmill here, and d-k-p answer is spot-on. If you want to manage your entire workflows as a typescript code, then trigger.dev would be preferable. Windmill supports typescript, python, go and bash, and handle all the advanced features such as retries, approval steps, pre-made integrations to hundreds of API at the workflow level in a UI-based editor. Then for the steps, themselves. you would use either your IDE and sync to Windmill, or use our web IDE.

In Trigger.dev workflows are created completely in your code rather than in a node-based UI (which to be fair does allow you to write code sometimes). We found developers could actually put together workflows faster if the whole thing was code rather than a hybrid of UI / code (because you get to use your own IDE + Copilot).

Would love it if there was an email list I can subscribe to so I can keep up to date with development. I don't have a use for Trigger right now, but it seems like a cool tool that I want to keep up with.

We don’t have a newsletter at the moment so the best way to stay up to date is via Discord where we’ll be posting all our updates: https://discord.gg/hYmCPJRDcb

I can't accept the invite. Has it expired?

Automation in Javascript isn't what I'd call developer friendly. I'm constantly perplexed by javascript presence outside of web environment.

This being open source changes my entire perception of it. Appreciate all the work you've put in and how you are willing to share with the world!

Why are there so many "Zapier alternatives"?

Zapier's UI is a hot mess. If you breathe on a zap it turns off. Default names for zaps are "Untitled Zap". Pricing is very high for any sort of serious traffic. The webapp runs very slow.

But most important, no one knows how to say "Zapier". Is it ZAHpier or ZAYpier?

Zapier's UI might be a hot mess but their revenues indicate that the people are will to go with it and use it as is.

All the points you mention, can be fixed by zapier. Then the alternatives do have a moat.

Rhymes with happier.

In my mind it will always rhyme with tapir..

Then it should have been spelled Zappier.

Because Zapier is an established business and showcases that there is market for automation tools. It is a safe bet to make by creating an alternative.

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.

My experience is that for some types of integrations you see about a 70% success rate. Eventually you need something that is more reliable. Maybe you need an all in one solution that has some ETL capabilities. Maybe it’s a cost thing.

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.

So am I allowed to clone and self-host this free of charge? Or does it somehow phone home and tie me into an account / pricing plan.

This sounds great and very much needed! If you need a contributor, I’m interested (currently looking for a good project to get into).

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

How does this compare to n8n.io? Seems like you need to be a bit more knowledgeable to use this than a true low code solution.

Looks amazing. Thanks for puting this accross. If you can add no code version.

Nice, Zapier is a pretty interesting solution but the pricing model is not.

This is fascinating. It checks a lot of my boxes. I was recently looking at ActionsFlow [0] which is similar but runs on GitHub Actions.

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] - https://docs.dagger.io/1215/what-is-cue/

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]: https://github.com/windmill-labs/windmill

Thanks for such an amazing reply, I'll do my best to answer everything. I am also on the Trigger.dev team btw.

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!

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

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.

Hey, Inngest looks impressive, congrats! We're tackling similar problems. Our actual inspiration to build this was Interval back in November. They make it easy to create internal dashboards inside your own codebase by using their SDK. We wanted to offer the same great developer experience but for creating workflows.

I would really love an easy way to cron job a collab worksheet.

I just want Yahoo Pipes back. Is that so much to ask?

I’ve been waiting for this for years. Love!

For people who are building durable workflows. You should definitely checkout temporal [1]. It is production ready, you can implement pretty much same using the original SDK of the underline services.

[1] https://temporal.io/

Their pricing model is much preferred: https://temporal.io/cloud

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.

Unfortunately there's currently a steep mandatory support charge of $200 a month, which makes it unviable for smaller operations. I think they're planning to offer the service without the support aspect, which would be fantastic and I'd be first in line for..

And if you don't store much inside the workflows themselves - it's quite cheap even if you have hundreds of thousands invocations.

1M invocations looks like $25, which is really cheap

I meant daily, but it's still cheap.

I was saying 1,000,000 requests, which is the same for any time period

Not sure why everyone says it's too complex, maybe people get scared by the word idempotence.

This is complicated with too many terminologies :(