Hyve
Describe a cluster in YAML and Hyve creates, updates, and deletes it to match. How a cluster gets built is up to a module — Cluster API, Terraform, Crossplane, or a provider’s own CLI.
go install github.com/cbridges1/hyve@latestRun it where you need it
The same YAML and the same reconcile engine everywhere.
Locally
hyve reconcile against a directory on your machine. Git-backed if you want history and review; a plain folder if you don’t.
In pipelines
Run the same command from CI — create clusters for a test run and tear them down after.
In Kubernetes
Deploy Hyve as a controller with an API and web console for your team. Reconcile on the cluster it runs on, or point each organization at a separate reconciling cluster to keep the app apart from the work.
Clusters as code
A cluster is one YAML file. Create it and the cluster is created, edit it and it’s updated, mark it delete: true and it’s deleted. Locally it’s a file; in Kubernetes it’s a custom resource — the same shape either way.
apiVersion: hyve.io/v1alpha1kind: ClusterDefinitionmetadata: name: webspec: driver: source: github.com/cbridges1/hyve-capi-module version: v0.2.0 mgmtCluster: capi-mgmt params: cluster_class: aws-small kubernetes_version: v1.34.8 worker_count: "3"Templates stamp out clusters to a pattern, lifecycle hooks run workflows before and after each change, and hyve cluster auth hands you a working kubeconfig.
Bring your own provisioner
A module is a small, versioned set of scripts — create, status, scale, auth, delete — so anything you can script can provision a cluster: Terraform, Crossplane, Cluster API, or a provider’s CLI. Hyve embeds no cloud SDKs; credentials stay where your tools already keep them.
Cluster API, first-class
hyve-capi-module builds clusters from any ClusterClass on any provider Cluster API supports. Use a management cluster you already run, or let it start a kind cluster for local runs and pipelines.
Write your own
hyve module init scaffolds a module. Wrap whatever your team already uses.