hanzo

Overview ¶

Command hanzo is the unified Hanzo Go binary, dispatched by subcommand.

hanzo                 list subcommands
hanzo --help          list subcommands
hanzo <svc> [flags]   serve exactly one subsystem (iam, kms, commerce,
                      gateway, ai, base, vfs, o11y, …)
hanzo cloud [flags]   serve the full unified surface (all enabled
                      subsystems mounted into one zip.App / one listener)

One binary. Many subsystems. The subcommand selects WHICH subsystem(s) serve this process; the same artifact is every standalone service AND the fused cloud control plane.

Design — one mechanism, not many. The subsystem set is the explicit list apps.Wire() returns — []cloud.MountSpec in mount order (kms first-tier, iam 50, commerce 100, …, ai last), no init()-registry. A subcommand is just a *selection* over that slice:

• `hanzo <svc>` ⇒ cloud.Serve(specs, []string{svc}); MountAll mounts only it.
• `hanzo cloud` ⇒ cloud.Serve(specs, nil); cfg.Enable per --enable (empty = all).

Both paths run the identical compose root (BuildDeps → zip.App → health contract → MountAll → graceful Listen) — that body lives once in cloud.Serve and is shared with cmd/cloud. No subcommand duplicates boot logic.

Identity is served on the CLEAN github.com/hanzoai/iam (the Casdoor/Beego fork github.com/hanzoai/iam-v1 is RETIRED, GONE from this binary's graph): the in-process fold clients/iam (order 50) embeds the clean iam-v2 zip-natively under /v1/iam/* (+ /login/oauth/*) via iamserver.Mount(app, db) for the fused surface; the FULL standalone identity provider is the clean iam's own binary. The legacy `hanzo iam` subcommand (which launched the Casdoor daemon via iamserver.Run) is gone — nothing here links the dead Beego module, so there is no beego process-global to collide at package load.