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