HIP-115: Hanzo Frontend Delivery. Status Active. Hanzo's own standard — read this before implementing against it.
This is the one and only way a frontend — a site, a docs surface, a dashboard — is organized, built, and shipped across Hanzo, Lux, and Zoo. Every frontend is one repo in its org's apps organization, is one application on the PaaS, builds the same way, and is served the same way. There is exactly one project per site; there are no second implementations and no second homes.
It is the frontend peer of HIP-0119. HIP-0119 governs backend services — they serve /v1/ and :9090 to machines, live in per-service repos, and are deployed by the operator. This HIP governs apps* — they serve / to humans, live in the per-org apps organization, and are deployed by the PaaS. The split is the decomplection: machine surface vs human surface, operator vs PaaS, never braided.
The key words MUST, MUST NOT, SHOULD, SHOULD NOT, MAY are per RFC 2119.
<org>-apps GitHub organization (hanzo-apps, lux-apps, zoo-apps), cloned locally to ~/work/<org>/apps/<name>.
implementations of the same site (e.g. docs, app-docs, platform-docs) MUST be collapsed to one; the others are retired (archived), not left to rot.
hanzoai, luxfi, zooai). Those orgs hold backend services and libraries. Static content and sites that currently sit there MUST be migrated into the apps org. One home.
PaaS application with an independent deploy. Sharing is by published package (the design system), never by workspace coupling.
A frontend MUST consume the design system as a dependency — @hanzo/ui, themed per brand to @luxfi/ui / @zooai/ui (HIP-0504: brand UIs are theme values, not forks). A frontend MUST NOT vendor or re-implement shared components. Brand differs in values (tokens, logo, domain); shape is identical.
Every app builds on the PaaS (platform.hanzo.ai). An app declares exactly one build target:
static — the default for sites and docs. The PaaS builds the app and publishes the static export (Next output: export, Vite dist, etc.) as an immutable artifact. This is the common case; prefer it.
container — only when the app genuinely needs a server at request time(SSR, server actions, auth callbacks that can't be edge/static). Runs as a PaaS container app.
An app MUST NOT be built or deployed by a hand-run pipeline, a bespoke per-repo GitHub Action that pushes to a host, or a second PaaS. One control plane.
static app's artifact MUST be published to hanzoai/s3 (the object store) and served by hanzoai/ingress + the static plugin. nginx, caddy, and per-site web servers MUST NOT be used (per the platform rule).
container app is served through hanzoai/ingress → the app, per HIP-0112.<site>.<brand-domain>.<org>-apps → register the PaaS app (static,host) → deploy. No cluster YAML hand-editing, no new web server.
hanzo-apps, lux-apps, and zoo-apps are the same organization in three brands. An app in any of them follows this HIP identically; only values differ — the org segment (<org>-apps), the brand domain, the theme package. LPs and ZIPs adopt this HIP by reference and MUST NOT restate or fork it.
hanzoai/s3 via ingress+static.<org>-apps; no alternate implementations.static (or container only if it must).static artifacts go to hanzoai/s3, served by ingress+static — no nginx.