host

Overview ¶

Command host is the Hanzo Cloud router: one binary that serves the whole API by mounting every subsystem as its own process, started on the first request that reaches it.

It knows only where each app lives and what path it answers — never what the app does — so it links zip and the generated manifest and nothing else. That is the entire difference from cmd/cloud, which imports apps and therefore links all 103 subsystem graphs into one 3105-package binary that must be relinked whenever any of them changes. Here a subsystem changing rebuilds itself; the host is untouched.

Lazy is what makes 69 services affordable. Mounting them eagerly costs 69 processes, 69 resident sets and 69 startup times at boot for a set that is mostly idle. Mounted lazily, an app nobody calls costs a route entry and a struct; the cost moves to the first request that needs it. The subsystems that cannot wait for a request — the ones that own a listener or a background loop — say so in apps.go's `eager` map and start with the host.

The apps themselves are unchanged and unaware: each is the same cmd/<name> binary that already exists, serving the same routes through the same cloud.Serve middleware it would serve standalone. Identity, billing and telemetry run in the app's own process, where they already ran.

Deployment is one directory: the host plus its plugins, which is what the image already ships. Point CLOUD_<NAME>_ADDR at an instance running elsewhere, or CLOUD_<NAME>_BIN at a specific build, to override one of them.