A run kept as a recordstep 2 / 5 · GitHub
A run held in a goroutinestep 2 / 5 · GitHub
draft
triggerGitHubPostgresSlackpublished
triggerGitHubPostgresReact Flow · SSEpublished
record
- trigger
- GitHub
- Postgres
- Slack
- done
goroutine
- trigger
- GitHub
- Postgres
- Slack
- done
pod rescheduled
- GoOne process
- SQLitePer replica
- /v1Flows and runs
- ApacheSelf-hosted
GET /v1/pieces
- Slack
- GitHub
- Notion
- Gmail
- Stripe
- HubSpot
- Jira
- Linear
- Discord
- Airtable
- Google Sheets
- Postgres
connection
Hanzo IAMHanzo KMSSome of what it connects
GET /v1/pieces
A run that survives the restart
A run is a record, not a goroutine. Step state is written down as it goes, so a crash, a deploy or a rescheduled pod resumes where it stopped rather than starting over or losing the run.
GET /v1/pieces lists the connectors this build has. No plugin registry to reach at boot, so the version you deployed is the version that runs, offline and forever.
POST to a trigger and a run starts. Or start one by hand against /v1/runs. Either way it is the same run object with the same history.
The editor is React Flow, embedded in the binary, and it follows a run over a server-sent event stream — so the canvas you drew is the canvas you watch execute.
Edit a flow freely; nothing changes for callers until you publish. What triggers fire is a published version, so editing in the afternoon does not change what runs overnight.
A connection is a named credential the flow refers to. It is encrypted at rest through Hanzo KMS, and who may touch it is Hanzo IAM's answer, not a second login here.
Or run it yourself
One container, one port, a SQLite file for state. Nothing else to stand up first.
Paste and ship
Paste this into any agent. It reads the skill manifest and calls Auto from there.
Read https://hanzo.ai/skill.md and use Hanzo Auto in my project. Start with: hanzo auto flows listGet Auto
Workflow automations