Heym
Self-hosted AI workflow automation with agents, RAG, and MCP
40 followers
Self-hosted AI workflow automation with agents, RAG, and MCP
40 followers
Build AI workflow automations visually, with no coding required. Heym supports multi-agent orchestration, RAG pipelines, and MCP, plus a powerful AI builder for faster creation. Heym is a source-available, self-hosted AI workflow automation platform. It offers a visual canvas, many node types, multi-agent orchestration, RAG capabilities, HITL approvals, an MCP server/client, full LLM traces, and a portal that turns any workflow into a public chat UI. Ready to setup with no vendor lock-in.
Heym
The human-in-the-loop checkpoints are what make this production-ready rather than just a demo tool , the most visual workflow builders skip that entirely. How does Heym handle a long-running agent that hits a review checkpoint at 2am -does it pause and wait, or time out?
Heym
@sailikhith It pauses and waits. Heym treats HITL as a persisted checkpoint, not an in-memory sleep: when the agent asks for review, the run is marked pending, a one-time /review/{token} link is created, and the full execution snapshot is stored.
So if it hits that checkpoint at 2 AM, the review branch can notify Slack/email/on-call immediately, while the normal path stays blocked. When someone reviews it later, they can accept, edit and continue, or refuse, then Heym resumes from the stored snapshot with the approved context.
There is a 168-hour TTL on the review link to avoid stale approvals, but it does not auto-approve or ship the output just because nobody woke up :)
Reference: https://github.com/heymrun/heym/blob/main/frontend/src/docs/content/reference/human-in-the-loop.md
OpenPlugin
the 'observability + execution traces in the same workflow' part is the unsung hero. most agent platforms treat traces as a debug afterthought, then your post-mortem on a failed run is just guessing. how granular are the events, every llm + tool call, or only at workflow boundaries?
Heym
@sebastian_sosa1 Great question — and yes, it's by design.
Heym traces at every individual LLM call, not at workflow boundaries. Each trace captures the exact node, full request/response payload, token counts, latency, and error. For agent nodes, every tool call in the chain is logged separately too.
So when a run fails, you open the trace viewer, find the exact node and the exact call — no guessing needed.
OpenPlugin
@ceren_kaya_akgun that's the right level. the next layer that surfaces once teams have call-level traces is correlating across runs, like 'this same agent call shape failed 8 times in the last week, here's the pattern.' how does heym handle aggregation/grouping over time? is there a recurring-trace-shape alert, or is it more on-demand investigation per-run?
Heym
@sebastian_sosa1 Yes , thank you & today Heym has two observability layers: call-level trace inspection and workflow-level analytics over time.
Every LLM/agent call is captured with request, response, tool calls, timing, token usage, workflow/node metadata, source, credential, model, and error state. The Analytics tab then aggregates execution count, success/error rate, latency, trends, and “most failed” workflows across windows like 24h, 7d, and 30d.
What we don’t ship yet is automatic recurring trace-shape clustering or a “this same agent-call shape failed 8 times this week” alert. Right now that part is more on-demand: use analytics to spot the workflow/node area, then filter/search traces and inspect representative runs.
That said, the raw ingredients are already there in the trace schema, so recurring-shape grouping is a natural next layer for us. I’d think of the current version as strong per-run debugging plus time-window workflow aggregation, with trace-shape alerts still ahead.
OpenPlugin
@ceren_kaya_akgun yeah, holding the alert until you have enough trace volume to tune clustering is the right call. the version that ships before it's ready ends up firing on every minor arg drift and people turn it off.
the self-hosted angle here is what makes it genuinely interesting — most workflow automation tools with RAG built in are SaaS-only and you just have to trust them with your data. being able to run this on your own infra changes who can actually use it, especially for teams in industries where data leaving the building is a non-starter. curious how the RAG setup works — do you bring your own vector DB or does it come bundled with one, and how much configuration does it need out of the box?
Heym
Thanks Priyanka, exactly. The self-hosted part is the main reason we built RAG this way.
Right now Heym is Qdrant-first: you point it at a Qdrant instance you control, either self-hosted or cloud, then Heym manages the collections, document uploads, chunking, embeddings, metadata filters, search, sharing, and optional Cohere reranking from the UI/workflow nodes.
Setup is pretty small: add a Qdrant credential with host, port, optional API key, and an OpenAI key for embeddings, create a vector store, upload PDFs/Markdown/TXT/CSV/JSON, then wire the RAG node into an LLM or Agent node.
We also have ready templates for both sides of the flow:
https://heym.run/templates/rag-document-ingest
https://heym.run/templates/rag-qa-agent
Really like the focus on solving actual workflow pain points instead of just adding AI features. Curious how Heym prevents context loss or agent drift during long-running multi-agent workflows?
Heym
@tejaswi_devalla Thanks Tejaswi, that is exactly the problem we are trying to design around. Heym does not treat long-running agent workflows as one giant prompt. The orchestrator delegates to named sub-agents with scoped prompts and explicit handoffs, so each agent only sees the context it needs.
For longer runs, Agent nodes automatically compress accumulated tool and message history when context usage approaches the model window, while preserving the system instructions, original task, and latest user intent. Agents can also use optional persistent memory, stored as a per-agent knowledge graph, and shared between agents when needed.
On the drift side, we keep the execution observable: tool calls, sub-agent outputs, timing, context compression events, traces, and HITL checkpoints are visible in the run history. So the pattern is: scoped delegation, explicit memory, automatic compression, and inspectable execution.
This template shows the orchestrator + sub-agent handoff pattern: https://heym.run/templates/research-writer-pipeline
Source is here too: https://github.com/heymrun/heym
Used to build a lot of workflows on n8n and after a point it started feeling like the workflows needed a number of extra systems around it just to make it reliable. Went through Heym’s docs and really liked the philosophy behind it. Agents, orchestration, traces, evals, RAG, HITL all being built into the workflow layer itself makes way more sense than bolting everything on separately later.
The orchestrator/sub-agent approach especially feels much cleaner for bigger workflows instead of endlessly stuffing context into one agent.
The Skills system is probably the part I’m most curious about. Reusable capability bundles across workflows/agents sounds incredibly powerful long term, but also feels like something where versioning could become important very quickly once multiple workflows depend on the same skill. Is there a versioning or rollback path for skills, or is managing that left to the developer?
Can already tell I’m going to build a lot with this!
Heym
Two weeks in : thank you, and here's what's new
325 GitHub stars in two weeks. We didn't expect that. Genuinely grateful to everyone who tried Heym, opened issues, patch security vulnerabilities , or just starred the repo.
Here's what we've been working on since launch:
We started publishing blog posts covering real workflow patterns and use cases
A template gallery is live so you can grab working workflows and customize from there.
And we added a video gallery for those who prefer to see things running before diving in.
If you haven't tried it yet, the repo is public and the setup is a single docker-compose up. We'd love feedback, bug reports, or just to hear what you're building.
heym.run · github.com/heymrun/heym