base

Overview ¶

Package base embeds the Hanzo Base app engine in-process in the unified cloud binary (the HIP-0106 base fold) and mounts the viral waitlist plugin on the shared zip.App. It is the in-binary replacement for the standalone `ghcr.io/hanzoai/superbase` pod, whose whole job was `base.New()` + serve: cloud already links hanzoai/base, so it runs the SAME base app in-process.

ONE WRITER, DURABLE. The base app opens a SQLite store under {deps.DataDir}/base — the cloud deployment is single-replica, strategy Recreate, backed by the RWO cloud-api-data PVC, so the embedded store is single-writer + single-open + durable across restarts, exactly the property the standalone base pod had with its own PVC.

LAUNCH SURFACE. The waitlist plugin binds /v1/waitlist/* (join, status, boost, neighborhood, list, activity, track-share, invite, award, export) on the base router; that router's mux is mounted here so cloud serves the waitlist directly. console reads it via WAITLIST_URL=http://cloud.hanzo.svc. All waitlist knobs resolve from the environment at boot (see the plugin's Config.resolve): TURNSTILE_SECRET_KEY, WAITLIST_ADMIN_SECRET, WAITLIST_AWARD_SECRET, WAITLIST_DEFAULT_SLUGS, WAITLIST_ACCESS_CAPACITY, WAITLIST_OPEN — secrets injected from KMS, never in code.

FAIL-CLOSED + STAGED. Like the ingress edge fold, the embed only activates when CLOUD_BASE_EMBED is truthy. Absent it, Mount is a no-op (the generic GET /v1/base/health liveness route still answers) so linking this subsystem into every cloud variant changes nothing until a single-writer deployment opts in. Activation is one CR env, ONE place.