Heym: a self-hosted canvas for agent workflows, with execution traces and cost tracking built in

The gap Heym targets: automation tools that treat AI as a bolt-on

Most workflow automation tools began as trigger-action engines. A webhook fires, a filter runs, a record updates. When LLM steps arrived, they were added as another node type inside a model that already assumed deterministic, cheap, fast steps. Heym's README draws that line explicitly: "Unlike platforms that started as classic trigger-action automation and layered AI on later, in Heym AI is the execution model." Whether that claim survives contact with a real workflow is something you can only check by running one, but it names the design intent.

The audience is narrower than the topic list suggests. The repository is tagged no-code and no-code-automation, and the README leads with drag-and-drop and natural-language workflow generation. But the deployment story is Docker on your own infrastructure, the backend is Python 3.11+ with FastAPI, the frontend is Vue 3 with TypeScript in strict mode, and the toolchain expects Bun. Someone who wants a hosted SaaS with a support contract is not the target. The target is a team that already runs its own services, has opinions about where prompt text and customer data live, and wants the automation layer inside that boundary.

What actually runs when you press execute

The README describes the build surface as a visual canvas plus natural language, voice, templates and agent skills. The run surface is where the architecture becomes visible. A workflow is a graph, and the canvas is a view onto it. Nodes cover agents, vector stores, web scrapers, HTTP calls and message queues, which means retrieval and external I/O are first-class steps rather than something you bolt on with a code node.

The orchestration pattern the demos push is orchestrator plus subagents. The README's example is a request that combines two unrelated questions, a route from Berlin to Frankfurt and a food recommendation, and it argues that parallel subagents finish faster than either two separate LLM calls or a sequential chain merged at the end. The stated reasons are context economy and turn focus: each subagent sees only its part of the problem, and no single model turn has to produce two large unrelated answers. That is a real trade-off, not a slogan. Parallel subagents add orchestration overhead and a merge step, and for a single-part request they are the wrong shape.

Inspection is treated as part of the runtime. The README lists run history, LLM traces, evals, logs, OpenTelemetry export and cost tracking in USD. Cost in USD rather than tokens is the detail worth noting, because it implies a model price table maintained inside the product. That table will drift as providers change prices, and nothing in the supplied material says how it is updated.

Getting it running: clone, run.sh, Docker, and the four ways to call a workflow

The README gives a single local command: git clone https://github.com/heymrun/heym.git, then cd heym, then ./run.sh. Deployment is described as instant via Docker, and the repository ships a publish-release-image.yml workflow, so a release image exists. The README does not reproduce the docker run invocation or list the environment variables for model providers, database and object storage in the portion available here. Treat that as the first thing to check in the repo rather than something this article can tell you.

Invocation is the part with the most concrete detail. The README says the same workflow can be called from the canvas, from REST execution endpoints, from SSE streaming, from MCP clients, or from a public Portal chat UI. Those are four integration surfaces with different failure characteristics. REST suits a backend job. SSE suits a UI that needs to show progress. MCP suits an existing agent client that wants the workflow as a tool. The Portal is a chat interface you expose to people outside the builder.

Authentication is mentioned in the feature list as OIDC SSO. The README does not describe role granularity, so if you need per-workflow permissions you will have to read SECURITY.md and the code. The repository also links a SECURITY.md policy, which is a reasonable signal that the maintainers expect self-hosters to think about the deployment boundary.

The licence is the first thing to resolve, not the last

This is the sharpest issue in the material. The README carries a green badge reading "License: MIT" pointing at LICENSE, and directly below it an orange badge reading "Condition: Commons Clause" pointing at COMMONS-CLAUSE.md. The GitHub API reports the licence as NOASSERTION, which means the platform could not classify it as a standard identifier. Three signals, two of which conflict on their face.

The Commons Clause is a rider that is typically attached to a permissive licence to restrict selling the software. If that is how it is used here, then Heym is source-available with commercial resale limits rather than plain MIT. The README's own framing supports that reading: it says the enterprise offering covers "commercial licensing, deployment help, dedicated support, and additional security layers." Commercial licensing as a paid product only makes sense if the free licence has a boundary.

I am not giving legal advice and neither is this article. The concrete step is to open both LICENSE and COMMONS-CLAUSE.md before you deploy Heym inside a revenue-generating product, and to decide whether hosting it for internal use, offering it to clients, or reselling it as part of a service falls inside or outside that boundary. If your legal team cannot answer from those two files, that is itself the finding.

Where Heym is the wrong tool

Version numbers tell you something. The three most recent releases in the supplied data are v0.0.107 on 2026-09-08, v0.0.106 on 2026-09-05 and v0.0.105 on 2026-09-03. That is three releases in five days on a 0.0.x line. Fast iteration on a pre-1.0 project usually means the API surface, the node schema and the storage format are still moving. If you need a workflow engine whose exported definitions will still import two years from now, this is not that yet. Pin a release tag and read the changelog between versions before you upgrade.

The second limitation is scope. Heym is AI-native by design, and that cuts both ways. If your actual problem is a deterministic nightly ETL job with no model in the loop, you are paying for an agent runtime, a canvas, a trace store and a cost tracker to move rows between two systems. A scheduler plus a script is smaller, cheaper to operate and easier to reason about.

The third is operational surface. A self-hosted deployment means you own the database, the queue, the object storage for run artefacts, the model provider keys and the upgrade path. The README leans hard on the absence of "weird production run limits," and that promise is real only as long as you keep the stack healthy. Nothing in the supplied material describes backup, migration between versions, or what happens to in-flight runs during an upgrade.

Against n8n and similar trigger-action platforms

The repository tags itself n8n-alternative, so the comparison is invited. The difference in approach is where the intelligence sits. n8n is a node-based automation tool with a large integration catalogue, and AI steps are nodes within that catalogue. Heym inverts the centre of gravity: agents, orchestrator and subagent patterns, RAG pipelines and MCP support are the primary constructs, and the HTTP and queue nodes exist to feed them.

That inversion has consequences you can predict without running either tool. A mature integration-first platform will usually have more ready-made connectors for third-party SaaS, because that is what its community builds. Heym's canvas is described as covering vector stores, scrapers, HTTP and queues, which is a smaller, more AI-shaped set. If your workflow is mostly "when X happens in SaaS tool A, update record in SaaS tool B," the trigger-action model fits better and Heym adds ceremony.

Conversely, if your workflow is "take a request, decompose it, retrieve context, run several agents in parallel, merge, and show me what each step cost," the trigger-action model makes you assemble that from primitives. Heym makes it the default shape. The honest framing is that these are different centres of gravity, not one being strictly better.

What the free tier actually includes, and what that costs you later

Heym's most specific claim is about packaging. The README lists global variables, execution history and search, insights, AI Builder capabilities, observability, audit-style logs, team controls, scaling and customer-facing portals, and says these ship in the free self-hostable product rather than as upgrade pressure. It then says the enterprise offering covers commercial licensing, deployment help, dedicated support and additional security layers.

That is a coherent position and it is easy to verify: clone the repo, run ./run.sh, and see whether the features you care about are present without a licence key. What it does not tell you is the ongoing cost. Every release on the 0.0.x line is a potential migration, and the README does not describe a migration tool or a schema version policy. The maintenance burden for a self-hoster is therefore upgrade testing, not subscription fees.

One more thing the material supports: the project takes security seriously enough to ship a SECURITY.md and to describe the enterprise tier as adding "additional security layers," which implies the free deployment has a baseline the maintainers consider sufficient but not maximal. If you are putting a Portal chat UI in front of untrusted users, that distinction matters more than any feature comparison.

Editorial conclusion

Adopt Heym if you want agent orchestration and execution inspection on infrastructure you control, and you accept that the licence is not plain MIT: the repository carries a COMMONS-CLAUSE.md alongside the MIT badge, and the GitHub API reports NOASSERTION, so read both files before you build a commercial product on it. Skip it if you need a stable API surface, because v0.0.107 shipped on 2026-09-08 and the 0.0.x line signals pre-1.0 churn. Verify three things first: that ./run.sh completes on your machine, that the LLM and vector-store nodes you need exist on the canvas, and that your MCP client can list the workflow as a tool.

Official sources

1. heymrun/heym on GitHub
2. Issues
3. Project website
4. README
5. Releases