Hyve

A GitOps-first Kubernetes cluster management CLI. Define clusters as YAML, commit the change, and Hyve reconciles the desired state — locally or through a CI/CD pipeline. Cloud operations are delegated to modules: versioned, self-contained packages that implement cluster operations via shell scripts or workflow YAMLs. No cloud SDKs are embedded in Hyve itself.

• GitOps Native — All cluster state lives in Git. Every change is version-controlled, reviewed through pull requests, and rolled back with a revert commit.
• Module System — Modules are versioned packages for any cloud provider. Install once, reference from any template. No cloud SDKs bundled.
• Lifecycle Hooks — beforeCreate, onCreate, afterCreate, onDelete, afterDelete — run arbitrary workflows at each stage of a cluster's lifecycle, automatically.
• Cluster Templates — Define the shape of a cluster once; execute the template by name to stamp out clusters consistently.
• Variable Injection — Module params are injected as HYVE_PARAM_* env vars. Workflow outputs flow back as HYVE_KEY=value lines and are persisted for the next reconcile.
• Any Provider — First-party modules for Civo, AWS EKS, GCP GKE, and Azure AKS. Community modules for anything else. Your credentials stay in your environment.

Git is the state backend. No S3 bucket, no Terraform Cloud, no extra credentials — the full history of every cluster change is already in the repository.

Continuous reconciliation, not plan-and-apply. Commit to create, delete the file to destroy, update a field to reconcile the difference. The same hyve reconcile command handles all three cases.

Lifecycle hooks are built in. Five hook points cover the full cluster lifecycle:

Modules, not embedded SDKs. Old-style GitOps tools embed cloud SDKs. If your provider isn't supported, you're stuck. Hyve modules shell out to any CLI tool you already have configured — your credentials, your tools, your control.

Full documentation at cbridges1.github.io/hyve-website — CLI reference, module authoring guide, and provider-specific walkthroughs.

Homebrew (macOS/Linux):

brew install cbridges1/tap/hyve

Binary download:

Prebuilt binaries for macOS, Linux, and Windows (amd64/arm64) are attached to every GitHub Release.

curl -sL https://github.com/cbridges1/hyve/releases/latest/download/hyve_$(uname -s | tr '[:upper:]' '[:lower:]')_$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/').tar.gz | tar xz
sudo mv hyve /usr/local/bin/

Docker:

docker pull ghcr.io/cbridges1/hyve:latest
docker run --rm -v "$(pwd)":/repo ghcr.io/cbridges1/hyve:latest reconcile --path .

Requires Go 1.21+ and the system git binary in PATH for the options below.

Using go install:

go install github.com/cbridges1/hyve@latest

From source (install to $GOPATH/bin):

git clone https://github.com/cbridges1/hyve.git
cd hyve
go install .

Ensure $(go env GOPATH)/bin is in your PATH. This builds and installs the binary in one step with no manual copy required.

From source (local binary):

git clone https://github.com/cbridges1/hyve.git
cd hyve
go build -o hyve .
sudo mv hyve /usr/local/bin/

# 1. Add a module
hyve module add github.com/hyve-modules/civo@v1.0.0

# 2. Point Hyve at a Git repository for state
hyve git add production --repo-url https://github.com/company/hyve-state.git

# 3. Create a template
hyve template create my-civo-template \
  --driver github.com/hyve-modules/civo \
  --driver-version v1.0.0 \
  --region PHX1 \
  --set node_size=g4s.kube.medium \
  --set node_count=3

# 4. Create a cluster from the template — generates a cluster YAML and commits it
hyve cluster create my-cluster --template my-civo-template

# 5. Reconcile — provisions the cluster and runs any lifecycle hooks
hyve reconcile

# 6. Configure kubectl
hyve cluster auth my-cluster
kubectl get nodes

The resulting cluster YAML committed to your state repository:

apiVersion: v1
kind: Cluster
metadata:
  name: my-cluster
  region: PHX1
spec:
  driver:
    source: github.com/hyve-modules/civo
    version: v1.0.0
  params:
    node_size: g4s.kube.medium
    node_count: "3"
  workflows:
    onCreate:
      - deploy-monitoring
    onDelete:
      - drain-workloads

Cloud credentials are read directly from your environment — the same way the underlying CLI tools (civo, aws, gcloud, az) read them. Hyve never stores credentials.

Modules are directories containing operation files that Hyve executes during reconciliation:

Operations emit outputs by printing HYVE_KEY=value lines to stdout. Hyve captures these and writes them back to spec.driverOutputs in the cluster YAML, making them available on every subsequent reconcile.

# Validate all modules in use are locked and cached
hyve module validate

# List installed modules
hyve module list

# Scaffold a new module
hyve module init my-provider

Task is used to simplify common operations:

See CONTRIBUTING.md for the full development guide.