Hanzo Operator
One binary that runs the stack on Kubernetes
Declare a Service, a Datastore, a Gateway or an Ingress. The Deployment, StatefulSet, PVC, autoscaler, disruption budget, network policy and KMS-synced secret behind it get created — and stay that way, because one loop keeps checking.
Declare the thing, not the thirty objects
One reconcile loop, an API group you choose at install, and Kinds that already know what a service in this stack needs.
Kinds that know the stack
Service covers most workloads. Datastore covers the stateful ones and dispatches on its type, with SQL, KV, DocDB and S3 as thin facades over it. Gateway, Ingress, DNS, Base, IAM, KMS and MPC are their own Kinds, because each one wires up differently.
Secrets come from KMS
A KMSSecret is materialized beside the workload and synced from kms.hanzo.ai. What lives in git is the path to a secret, never the secret.
Drift is reverted, and said out loud
Every sweep reads each object before it applies, then logs what it did to it: created, reverted, or already in sync. The resync interval is per-resource and clamped into a safe band, so a bad number can't turn the loop into a hot loop.
Git is a source, and it never deletes
Point it at a repo and it applies what's there, on a tight poll a push webhook can interrupt for an instant sweep. A file removed from git is left alone — the plan type has no delete case, so pruning isn't something a bug can cause.
Every write is attributable
Server-side apply under its own field manager, so a git-driven apply never fights a per-Kind reconcile. Turn on autoscaling and the Deployment ships with no replica count at all — the autoscaler owns that field, alone.
Install is one command
operator install lays down the CRDs, namespace, RBAC and Deployment. operator up does that and applies your resources behind it. Both are server-side apply, so running either again changes nothing.