[mattaitken]

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!

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

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.