Hanzo Auto
Workflow automation in one binary
Draw a workflow, connect the apps it touches, and fire it from a webhook or a schedule. The whole thing is one Go process: the editor, the connector catalog, the database and the durable executor are compiled in. There is no Node at runtime, no reverse proxy to configure, and no Postgres to run beside it. One image, one port, one thing to restart.
A run that survives the restart
Most of what makes automation hard is what happens on step seven of nine when the process dies.
Durable execution
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.
The catalog is in the binary
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.
Triggers
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.
Watch it live
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.
Draft, then publish
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.
Connections, not pasted keys
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.
Some of what it connects
Up to 5% of compute goes back to open source
Every deployment is SBOM-verified. Contributors to ActivePieces earn a share of compute revenue — transparent, on-chain, and customizable by the community.
Or run it yourself
One container, one port, a SQLite file for state. Nothing else to stand up first.