github.com has no runner for hanzo-build-linux-amd64, so a caller under
.github/workflows is a gate that can never be scheduled. This is the ~7-line
caller on the plane that can (git.hanzo.ai git-runner fleet), pinned @v1.
Co-authored-by: Hanzo Dev <[email protected]>
Generalize the manifest loader to io/fs so services can be baked into a
static binary via embed.FS or read from disk via os.DirFS — LoadFS is the
one path; LoadDir is os.DirFS sugar. This is what lets hanzoai/cloud mount
embedded polyglot services into the single unified binary.
One Module/Engine interface with a JSON-in/JSON-out calling convention runs
four pure-Go engines behind a Pool that makes single-threaded interpreters
serve requests as parallel goroutines:
native plain Go handlers, zero overhead
goja + esbuild JavaScript and TypeScript (TS transpiled to ES2020)
gpython Python, no cgo and no GIL -> true goroutine parallelism
wazero Rust/WASM via a trivial string ABI
Services mount from a manifest (lang + source + routes), so any Go, Python,
Rust or JS backend collapses into a single static CGO_ENABLED=0 binary served
on the zip/gofiber app. A Go-backed json stdlib shim lets Python backends keep
importing the real module names while running at Go speed.
Examples and tests cover every engine; the Rust guest is a real wasm32 fixture
exercised end to end.
zeekayandHanzo Dev