4 ms·

Show HN: Graph Compose – Temporal workflows with visual builder, SDK, and AI

13 points by jalapenobasil 6mo ago

Hey HN. Graph Compose is a hosted platform for orchestrating API workflows on Temporal. You define workflows as graphs of nodes (HTTP calls, AI agents, iterators, error boundaries) and everything runs as a durable Temporal workflow under the hood. Three ways to build the same graph: a React Flow visual builder, a typed TypeScript SDK (@graph-compose/client), and an AI assistant that turns plain English into a graph. Open-core: the execution foundations and integrations service are AGPL-3.0. The platform orchestrator, visual builder, and AI assistant are proprietary. Longer backstory on why I built this in the first comment. Would love feedback, especially from anyone who's dealt with the "services work fine, the glue between them doesn't" problem. Docs: https://graphcompose.io/docs https://graphcompose.io/docs

jalapenobasil 6mo ago
A LITTLE BACKROUND: I spent 6 years as the founding engineer at a programmatic video generation company. This was before AI video. We were doing conventional compositing at scale, at a price point that's still below what AI-generated video costs today. The hardest part was never the video rendering. It was the orchestration. Every video job was a dynamic workflow. Different assets, different templates, different downstream services, all changing constantly. And none of the services involved should've needed to understand the bigger picture. A rendering service should just render. A transcoding service should just transcode. Each one operating in isolation, focused on its core intent, with no knowledge of the ecosystem around it. The real problem was bringing them together. How do you compose independent services into workflows that change as fast as the business needs them to, without redeploying anything? I never solved that problem the way I wanted to. Tools like Zapier and Make existed, but they weren't built for developers. They were built for non-technical users connecting apps through a UI. You couldn't version control a workflow, you couldn't programmatically create one, and the execution model was "hope the server stays up." n8n was closer to developer-friendly, but still no real durability, no SDK, and no way to treat workflows as code alongside everything else in your stack. The founder and I had a falling out after 6 years and I left the company. But the problem stuck with me. I'd spent years watching the same pattern: services that worked perfectly in isolation, but the glue between them was fragile, tightly coupled, and required a deploy every time the workflow changed. --- WHY NOW! With serverless architecture, the pieces finally exist to do this right. You can deploy services rapidly (Cloud Run, MCPs, whatever) and they just work as HTTP endpoints. The missing piece was always the orchestration layer. Something that could compose these services dynamically, with real durability, without deploying new code every time a workflow changes. --- WHY NOT N8N! I know people will ask "why not n8n?" Honestly, I didn't come at this from the no-code automation world. I came at it from Temporal. The starting point was durable execution, not connecting apps. The visual builder came later because I realized not everything needs to be code. But the foundation is Temporal's execution model, not a traditional automation tool with reliability bolted on after the fact. They overlap on the surface (both have a canvas, both wire up API calls) but they're built from opposite ends. So I built it. Being a bit of a completionist (and admittedly a weirdo), I figured I'd see this model all the way through. --- TEMPORAL.IO Why Temporal matters here. The core insight is that workflows need to survive failures. Not "retry from the beginning," but actually pick up where they left off. Temporal gives you event-sourced execution, replay on crash, and per-item isolation. In practice that means forEach batches run each item as its own Temporal child workflow, item 500 fails and the other 9,999 keep going, retry just that one. AI agents (ADK agent nodes) run as durable Temporal workflows, so state persists across turns and you can do human-in-the-loop approval before the agent does anything dangerous. And if you already run Temporal Cloud, you can plug in your own namespace and Graph Compose uses it (BYOK). --- OPEN SOURCE What's open source. Open-core. Core types, schemas, graph validation, and a runtime that executes HTTP DAG workflows on your own Temporal (the @graph-compose/runtime package) are AGPL-3.0. The integrations service is open too (graph-compose/nodes). You can read exactly how the execution model works, run basic workflows on your own infrastructure, and contribute integrations. The kernel is designed to be extensible beyond HTTP, the node execution contract is generic, so adding new invocation types (gRPC, message queues, custom protocols) is a matter of implementing a handler, not rearchitecting the engine. The platform orchestrator (error boundaries, forEach child workflows, ADK agents, streaming execution), the visual builder, the API layer, and the AI assistant are proprietary. I'm bootstrapping this, and giving away the entire product to compete on hosting margins isn't viable. I'd rather be upfront about that boundary than pretend everything is open and surprise people later. --- CURRENT LIMITS What it doesn't do yet. The integration catalog is smaller than n8n's 400+ connectors, but the nodes service is open source and structured so anyone can add one, standardized REST endpoint with Zod validation and auto-generated OpenAPI specs, PRs welcome. The open-source runtime is deliberately limited: HTTP-only DAGs, no persistence, no agents. It's the real execution model, not a demo, but the advanced orchestration features are platform-only. And the visual builder is functional, not beautiful, I don't have a design team. The stack. Next.js (App Router) for UI and API routes, Supabase for auth/data, Temporal for orchestration, Cloud Run for workers (TypeScript and Python for ADK agents), GCP Secret Manager, Stripe for billing. Deployed on Vercel, Cloud Run, and Cloudflare. --- QUESTIONS Two honest questions for the HN crowd. 1) The workflow orchestration space is crowded, n8n, Make, Zapier, Windmill, Inngest, Trigger.dev, Step Functions. My bet is that Temporal changes the conversation: the execution model is fundamentally better for anything where reliability matters, and most of these tools don't have it. Is that a strong enough differentiator to build a business on, or am I underestimating how little most users care about durability? 2) I'm thinking about how to grow this into a viable long-term platform without classic VC scaling. Referral-based equity for people who drive real adoption, contributor equity pools, revenue share for community members who build integrations. If you've scaled a developer tools company, experimented with non-traditional growth models, or have opinions on open-core go-to-market, I'd love to hear it.
xcution 6mo ago
Ohhh this looks promising. Gonna play with it this weekend
- jalapenobasil 6mo ago
  Yeah if you're interested and find anything that you have questions about there's a Discord open for comms :)
nreedparsons 6mo ago
[dead]
tacoloco 6mo ago
Question on the batch handling, when a workflow fails in a batch, what's the debugging experience like? Is it easy to spot where it failed?
- jalapenobasil 6mo ago
  Yeah actually, when a workflow fails, you have a couple of options: a) Continue on Error - Where a parent workflow continues despite a child failing b) You can re-run the child workflow - this allows you to essentially repair the state of the entire workflow orchestration in the case something fails. Other than that, a batch would be essentially defined as a bunch of JSON Directed Acyclic Graphs - so you could just re-run them all or a portion as required
- jalapenobasil 6mo ago
  I also realize I may not have answered this clearly: - Workflow Visibility: This is built on Temporal, so you receive the same dashboard that Temporal.io valued at $2.5B offers for it's customers. This means you see every node being executed in live time For those not familiar with temporal, this means you can see each node's failure state, alongside the reason, and so you can debug accordingly. You can query this via API as well in the case you are fully programmatic, and don't want visuals - but everyone loves visuals
jedberg 6mo ago
Have you looked at DBOS for the durable execution layer? Much easier to integrate and not nearly as heavyweight for you/your customers.
- jalapenobasil 6mo ago
  Hmmm, interested to know what you mean by easier to integrate Being easier to integrate would certainly be helpful. Temporal seems to be being adopted fairly heavily right now, and this just provides a layer on top of Temporal, without actually augmenting any of the Temporal underlayers. Hypothetically the same concept could be built for DBOS though this is tightly coupled to Temporal atm. The main benefits being that you receive raw Temporal behavior out of the box - including their Cloud offering, etc
- jalapenobasil 6mo ago
  Also @jedberg, I see your experience from previous... Do you have any thoughts and guidance on a product like this when it comes to user adoption? It's a crowded space, and I figure you might have some insight for a solo founder. Best, Jason
najan1 6mo ago
Docs look promising :eyes:. I'll give it a shot over the weekend.
- jalapenobasil 6mo ago
  Yes! Let me know if you find anything that raises any questions, or hesitations!
arham099 6mo ago
This looks great, judging from the docs it should be pretty straightforward too. I'll have to try and build an AI agent with this.
- jalapenobasil 6mo ago
  Yeah, definitely feel free to dig in. The docs should be fairly straightforward, and when you sign up you’ll automatically be placed on the free tier, which should be enough to build and test something meaningful. There’s also a Discord community if you run into anything or want to ask questions, I’m around there as well if you need help.
wideeyedyoungun 6mo ago
[dead]
neuraldarkfor 6mo ago
This is looking great! Would definitely give this a proper try.
rhowell 6mo ago
This is so cool! I have an idea of where I could use this, looking forward to putting together a PoC with it.
- jalapenobasil 6mo ago
  Yeah for sure, I'm trying to figure out the angle for it right now... I'm thinking where it really shines is with vibe coding. So maybe something along the lines of `Vibe-code your workflows. Run them like infrastructure.`
abroniewski 6mo ago
[dead]
abroniewski 6mo ago
The docs show Graph Compose has DAG execution, conditions, polling, timeouts, retries, and error boundaries. That is exciting for enterprise action workflows, but we would want Konekti to remain the semantic brain: process definitions, business rules, evidence, health, and process correctness should live there. Where do you draw the product boundary? What kinds of logic should absolutely stay outside Graph Compose, especially when the upstream system is a semantic process platform like Konekti rather than just a simple API?
- jalapenobasil 6mo ago
  [dead]
abroniewski 6mo ago
Graph Compose already has visual authoring, SDK/API authoring, Al-generated workflows, confirmation nodes, run dashboards, node-level execution details, and webhooks. If Konekti starts feeding Graph Compose high-value operational signals, such as "this case needs escalation" or "this supplier pattern requires review," how do you prevent enterprise automation from becoming ungoverned chaos? What governance exists around workflow ownership, versioning, approval, change control, audit history, environment promotion, rollback, and disabling risky workflows?
- jalapenobasil 6mo ago
  [dead]
abroniewski 6mo ago
What makes GC different from n8n or something like ActivePieces (open source project on GitHub)? I want to understand when it would be the right solution, and when a different tool is better suited.

13 points by jalapenobasil 6mo ago

jalapenobasil 6mo ago

A LITTLE BACKROUND: I spent 6 years as the founding engineer at a programmatic video generation company. This was before AI video. We were doing conventional compositing at scale, at a price point that's still below what AI-generated video costs today. The hardest part was never the video rendering. It was the orchestration. Every video job was a dynamic workflow. Different assets, different templates, different downstream services, all changing constantly. And none of the services involved should've needed to understand the bigger picture. A rendering service should just render. A transcoding service should just transcode. Each one operating in isolation, focused on its core intent, with no knowledge of the ecosystem around it. The real problem was bringing them together. How do you compose independent services into workflows that change as fast as the business needs them to, without redeploying anything? I never solved that problem the way I wanted to. Tools like Zapier and Make existed, but they weren't built for developers. They were built for non-technical users connecting apps through a UI. You couldn't version control a workflow, you couldn't programmatically create one, and the execution model was "hope the server stays up." n8n was closer to developer-friendly, but still no real durability, no SDK, and no way to treat workflows as code alongside everything else in your stack. The founder and I had a falling out after 6 years and I left the company. But the problem stuck with me. I'd spent years watching the same pattern: services that worked perfectly in isolation, but the glue between them was fragile, tightly coupled, and required a deploy every time the workflow changed. --- WHY NOW! With serverless architecture, the pieces finally exist to do this right. You can deploy services rapidly (Cloud Run, MCPs, whatever) and they just work as HTTP endpoints. The missing piece was always the orchestration layer. Something that could compose these services dynamically, with real durability, without deploying new code every time a workflow changes. --- WHY NOT N8N! I know people will ask "why not n8n?" Honestly, I didn't come at this from the no-code automation world. I came at it from Temporal. The starting point was durable execution, not connecting apps. The visual builder came later because I realized not everything needs to be code. But the foundation is Temporal's execution model, not a traditional automation tool with reliability bolted on after the fact. They overlap on the surface (both have a canvas, both wire up API calls) but they're built from opposite ends. So I built it. Being a bit of a completionist (and admittedly a weirdo), I figured I'd see this model all the way through. --- TEMPORAL.IO Why Temporal matters here. The core insight is that workflows need to survive failures. Not "retry from the beginning," but actually pick up where they left off. Temporal gives you event-sourced execution, replay on crash, and per-item isolation. In practice that means forEach batches run each item as its own Temporal child workflow, item 500 fails and the other 9,999 keep going, retry just that one. AI agents (ADK agent nodes) run as durable Temporal workflows, so state persists across turns and you can do human-in-the-loop approval before the agent does anything dangerous. And if you already run Temporal Cloud, you can plug in your own namespace and Graph Compose uses it (BYOK). --- OPEN SOURCE What's open source. Open-core. Core types, schemas, graph validation, and a runtime that executes HTTP DAG workflows on your own Temporal (the @graph-compose/runtime package) are AGPL-3.0. The integrations service is open too (graph-compose/nodes). You can read exactly how the execution model works, run basic workflows on your own infrastructure, and contribute integrations. The kernel is designed to be extensible beyond HTTP, the node execution contract is generic, so adding new invocation types (gRPC, message queues, custom protocols) is a matter of implementing a handler, not rearchitecting the engine. The platform orchestrator (error boundaries, forEach child workflows, ADK agents, streaming execution), the visual builder, the API layer, and the AI assistant are proprietary. I'm bootstrapping this, and giving away the entire product to compete on hosting margins isn't viable. I'd rather be upfront about that boundary than pretend everything is open and surprise people later. --- CURRENT LIMITS What it doesn't do yet. The integration catalog is smaller than n8n's 400+ connectors, but the nodes service is open source and structured so anyone can add one, standardized REST endpoint with Zod validation and auto-generated OpenAPI specs, PRs welcome. The open-source runtime is deliberately limited: HTTP-only DAGs, no persistence, no agents. It's the real execution model, not a demo, but the advanced orchestration features are platform-only. And the visual builder is functional, not beautiful, I don't have a design team. The stack. Next.js (App Router) for UI and API routes, Supabase for auth/data, Temporal for orchestration, Cloud Run for workers (TypeScript and Python for ADK agents), GCP Secret Manager, Stripe for billing. Deployed on Vercel, Cloud Run, and Cloudflare. --- QUESTIONS Two honest questions for the HN crowd. 1) The workflow orchestration space is crowded, n8n, Make, Zapier, Windmill, Inngest, Trigger.dev, Step Functions. My bet is that Temporal changes the conversation: the execution model is fundamentally better for anything where reliability matters, and most of these tools don't have it. Is that a strong enough differentiator to build a business on, or am I underestimating how little most users care about durability? 2) I'm thinking about how to grow this into a viable long-term platform without classic VC scaling. Referral-based equity for people who drive real adoption, contributor equity pools, revenue share for community members who build integrations. If you've scaled a developer tools company, experimented with non-traditional growth models, or have opinions on open-core go-to-market, I'd love to hear it.

xcution 6mo ago

Ohhh this looks promising. Gonna play with it this weekend

jalapenobasil 6mo ago
Yeah if you're interested and find anything that you have questions about there's a Discord open for comms :)

nreedparsons 6mo ago

[dead]

tacoloco 6mo ago

Question on the batch handling, when a workflow fails in a batch, what's the debugging experience like? Is it easy to spot where it failed?

jalapenobasil 6mo ago
Yeah actually, when a workflow fails, you have a couple of options: a) Continue on Error - Where a parent workflow continues despite a child failing b) You can re-run the child workflow - this allows you to essentially repair the state of the entire workflow orchestration in the case something fails. Other than that, a batch would be essentially defined as a bunch of JSON Directed Acyclic Graphs - so you could just re-run them all or a portion as required
jalapenobasil 6mo ago
I also realize I may not have answered this clearly: - Workflow Visibility: This is built on Temporal, so you receive the same dashboard that Temporal.io valued at $2.5B offers for it's customers. This means you see every node being executed in live time For those not familiar with temporal, this means you can see each node's failure state, alongside the reason, and so you can debug accordingly. You can query this via API as well in the case you are fully programmatic, and don't want visuals - but everyone loves visuals

jedberg 6mo ago

Have you looked at DBOS for the durable execution layer? Much easier to integrate and not nearly as heavyweight for you/your customers.

jalapenobasil 6mo ago
Hmmm, interested to know what you mean by easier to integrate Being easier to integrate would certainly be helpful. Temporal seems to be being adopted fairly heavily right now, and this just provides a layer on top of Temporal, without actually augmenting any of the Temporal underlayers. Hypothetically the same concept could be built for DBOS though this is tightly coupled to Temporal atm. The main benefits being that you receive raw Temporal behavior out of the box - including their Cloud offering, etc
jalapenobasil 6mo ago
Also @jedberg, I see your experience from previous... Do you have any thoughts and guidance on a product like this when it comes to user adoption? It's a crowded space, and I figure you might have some insight for a solo founder. Best, Jason

najan1 6mo ago

Docs look promising :eyes:. I'll give it a shot over the weekend.

jalapenobasil 6mo ago
Yes! Let me know if you find anything that raises any questions, or hesitations!

arham099 6mo ago

This looks great, judging from the docs it should be pretty straightforward too. I'll have to try and build an AI agent with this.

jalapenobasil 6mo ago
Yeah, definitely feel free to dig in. The docs should be fairly straightforward, and when you sign up you’ll automatically be placed on the free tier, which should be enough to build and test something meaningful. There’s also a Discord community if you run into anything or want to ask questions, I’m around there as well if you need help.

wideeyedyoungun 6mo ago

[dead]

neuraldarkfor 6mo ago

This is looking great! Would definitely give this a proper try.

rhowell 6mo ago

This is so cool! I have an idea of where I could use this, looking forward to putting together a PoC with it.

jalapenobasil 6mo ago
Yeah for sure, I'm trying to figure out the angle for it right now... I'm thinking where it really shines is with vibe coding. So maybe something along the lines of `Vibe-code your workflows. Run them like infrastructure.`

abroniewski 6mo ago

[dead]

abroniewski 6mo ago

The docs show Graph Compose has DAG execution, conditions, polling, timeouts, retries, and error boundaries. That is exciting for enterprise action workflows, but we would want Konekti to remain the semantic brain: process definitions, business rules, evidence, health, and process correctness should live there. Where do you draw the product boundary? What kinds of logic should absolutely stay outside Graph Compose, especially when the upstream system is a semantic process platform like Konekti rather than just a simple API?

jalapenobasil 6mo ago
[dead]

abroniewski 6mo ago

Graph Compose already has visual authoring, SDK/API authoring, Al-generated workflows, confirmation nodes, run dashboards, node-level execution details, and webhooks. If Konekti starts feeding Graph Compose high-value operational signals, such as "this case needs escalation" or "this supplier pattern requires review," how do you prevent enterprise automation from becoming ungoverned chaos? What governance exists around workflow ownership, versioning, approval, change control, audit history, environment promotion, rollback, and disabling risky workflows?

jalapenobasil 6mo ago
[dead]

abroniewski 6mo ago

What makes GC different from n8n or something like ActivePieces (open source project on GitHub)? I want to understand when it would be the right solution, and when a different tool is better suited.