Migrate from Huginn to Heym
Move Huginn scenarios to Heym. Paste an exported scenario, watch AI Convert rebuild each agent as a node on a live canvas, then run it on your own server.
Huginn describes itself as a system for building agents that perform automated tasks online, where agents create and consume events that propagate along a directed graph, on a server you run yourself.
When it is worth moving a workflow
Huginn already runs on your own server, so this move is not about hosting. It is about what the graph can contain. Event-passing agents handle monitoring and notification well; they were not built for a language model that chooses tools, retrieval over your own documents, or a reviewer who has to approve an action before it happens.
How the move works
- 1
Export from Huginn
Open the scenario in Huginn and export it as JSON, then paste the file contents. A description of what the agents do works too.
- 2
Paste it into AI Convert
A safety check runs, then each construct is mapped to the closest native Heym node and streamed onto a live canvas while you watch.
- 3
Review, download, and import
Read the rebuilt workflow, download or copy it, import it into your own instance, and attach your credentials.
What each Huginn concept becomes
A reviewer's guide to the rebuilt workflow. Constructs without an exact equivalent are mapped to the closest Heym primitive, which is why the result is worth reading before it handles real traffic.
| In Huginn | In Heym | What changes |
|---|---|---|
| Scenario | Workflow | A scenario is already a named group of connected agents, which maps almost directly onto one workflow. |
| Agent | Node | Each agent becomes the closest native node, or an HTTP node when nothing matches its job exactly. |
| Event propagation between agents | Canvas edges | Receivers and sources become wired edges, so the directed graph survives the move as a graph. |
| WebsiteAgent | Crawler node or HTTP node | Page scraping becomes a Crawler node; a plain fetch becomes an HTTP node. |
| RSS-style polling agents | Cron node plus HTTP or Crawler node | The schedule becomes an explicit trigger rather than a property of the agent. |
| TriggerAgent | Condition node | Rules that decide whether to emit an event become an explicit branch on the canvas. |
| EventFormattingAgent | Set node | Reshaping an event becomes field assignment with expressions. |
| PostAgent | HTTP node | Outbound posts carry over with the same methods, headers, and body templating. |
| Email and digest agents | Send Email node | Digest behavior becomes a scheduled workflow that collects and sends, which makes the batching window explicit. |
| JavaScript agent | Code node | Custom logic is rewritten into sandboxed Python running in a Docker sandbox. |
| Webhook agent | Workflow webhook trigger | The entry point becomes a property of the workflow, so the URL is new and callers need updating. |
| Agent schedule | Cron node | Each agent carried its own schedule; here the schedule sits at the front of the workflow it starts. |
| Liquid templating in agent options | Expression DSL, for example $nodeName.field | Template references are rewritten to name the upstream node, usable in any string field. |
Check these before it goes live
- Rethink per-agent schedules. One workflow has one entry point, so agents that each polled on their own timer may become several workflows.
- Read every converted JavaScript agent. It is Python now, and this is where behavior differences hide.
- Recreate credentials in the Credentials tab rather than in environment variables.
- Confirm digest and batching windows, since collecting events over time becomes an explicit scheduled step.
- Run one test execution and compare the output against what the scenario produced.
Huginn migration FAQ
Can AI Convert read a Huginn scenario export?
Yes. Paste the exported scenario JSON into AI Convert. Scenarios convert well because they are already a directed graph of connected agents rather than a linear script.
Each of my agents has its own schedule. How does that map?
A Heym workflow has one entry point, so a scenario where several agents polled independently usually becomes more than one workflow, each with its own Cron node. Agents that only reacted to events from another agent stay on the same canvas as downstream nodes.
Do my credentials come across?
No, and that is deliberate. Exported workflow files hold no API keys or secrets, so AI Convert rebuilds the structure only and you attach your own credentials in the Heym Credentials tab afterwards. Nothing copies a secret between two systems on your behalf.
Is the converted workflow ready to run?
Treat it as a reviewed starting point rather than a finished port. Open it on the canvas, attach credentials, run one test execution, and adjust any node that was mapped to the closest Heym primitive rather than an exact equivalent.
Can I run the result on my own infrastructure?
Yes. Heym is source-available under an MIT license with a Commons Clause and runs on your own servers with Docker or Kubernetes, so migrated workflows, their credentials, and their model calls stay inside your environment.
Moving from something else
AI Convert reads exports from 12 tools, and it also accepts a plain description of the automation when there is no file to export.