Architecture
How Hanzo Cloud is built today, and the plugin-platform direction it is evolving toward.
Architecture
This section explains how Hanzo Cloud is put together — what runs today, and where the platform is headed. We keep the two clearly separated: the product pages elsewhere in these docs describe shipped behavior, while the platform direction here is design work being ratified through the Hanzo Improvement Proposals (HIPs). For the principles behind it all, see Engineering Philosophy.
Today
Hanzo Cloud is one Go binary. A single API key at api.hanzo.ai reaches every capability — AI inference, identity, secrets, storage, commerce, and more — because those capabilities are native subsystems compiled into that one binary (cloud, CGO_ENABLED=0, static), each served under /v1/<capability> and mapped to hanzoai/openapi. Ingress and routing are native subsystems too, so the binary is its own front door rather than sitting behind a separate gateway or ingress tier. This single-binary consolidation is the unified cloud binary (HIP-0106), already substantially shipped — and it is the same binary that powers the network you can run yourself.
The 67 capabilities are grouped into the eight movements of the capability manifest:
Identity & Trust
Who you are, what you may touch, where secrets live.
Intelligence
Models, agents, evaluation — the mind of the cloud.
Data
The stores every capability writes to and reads from.
Streams
Messaging, durable tasks, async orchestration.
Observability
See everything — telemetry, analytics, usage.
Commerce
The economy — meter, price, bill, reward.
Platform
The cloud fabric — deploy, provision, route, host.
Applications
The user-facing surfaces built on all of the above.
A few products still run as standalone applications on their own domains — for example Sign (esign.hanzo.ai), Dataroom (dataroom.hanzo.ai), and Cap Table (captable.hanzo.ai) — authenticating through Hanzo IAM. These are the remaining standalone apps, being absorbed into the one runtime rather than the intended end state.
Direction
The platform is converging on one model for running these services: a consensus-backed plugin platform, where each service is a plugin registered into a single cloud runtime, and a small consensus control plane decides where each plugin's writers live. This is a design direction — specified as a draft proposal, not yet a shipped runtime.
Engineering Philosophy
The principles behind V8: one and one way, decomplect, the language seam is the wire not FFI.
The Network
The AI cloud you can run yourself — one binary, BYO GPU, the network is the cloud.
Consensus-Backed Plugin Platform
The HIP-0125 direction: plugins as the unit, consensus over placement, ZAP-native authoring.
ZAP Protocol
Zero-Copy App Proto — the high-performance transport plugins default to.
Hanzo Improvement Proposals
Where platform architecture is specified and ratified.
The plugin platform is described in HIP-0125 (Draft). It builds on a set of related proposals — the in-process extension runtime (HIP-0105), the unified cloud binary (HIP-0106), streaming replication (HIP-0107), and the ZAP transport (HIP-0114). Draft proposals may change; nothing on the plugin-platform page is a shipped user feature.
Engineering Philosophy
The Platform Algebra
Consensus-Backed Plugin Platform
How is this guide?
Last updated on