Skip to content
Docs
Worker bees in hard hats assembling the Hyve logo block by block Worker bees in hard hats assembling the Hyve logo block by block

Hyve

A Git-based tool, purpose-built for Kubernetes clusters — state in your repo, lifecycle in one CLI.

Define clusters as YAML, commit to Git, and reconcile — Hyve handles the full lifecycle across any cloud provider, and slots into the Terraform, Helm, or CI you already run.

Terminal window
go install github.com/cbridges1/hyve@latest
CivoAWS EKSGCP GKEAzure AKS+ community modules

Clusters as code

Terraform-style declarative provisioning, with the Git repository as the state backend. A cluster is one YAML file: commit it and the cluster is created, edit it and the cluster is updated, remove it and the cluster is deleted.

# clusters/my-cluster.yaml — committed to your Git state repo
apiVersion: v1
kind: Cluster
metadata:
name: my-cluster
region: us-east-1
spec:
driver:
source: github.com/hyve-modules/eks
version: v1.0.0
params:
instance_type: t3.medium
node_count: "3"
workflows:
onCreate:
- deploy-monitoring
onDelete:
- drain-workloads

Then hyve reconcile makes reality match the repo — locally or from CI. Change history, reviews, and rollbacks are just Git.

How it works

From nothing to a running cluster in four commands.

Install a module

Modules are versioned, self-contained packages that implement cluster operations — create, delete, status, auth. Each operation is invoked as a shell entry point, but can call out to any language or tool internally — only the output contract matters. No cloud SDKs embedded in Hyve.

Terminal window
hyve module add github.com/hyve-modules/civo@v1.0.0

Create a template

Templates capture your cluster shape, driver, region, and params. One template, infinite clusters.

Terminal window
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

Create a cluster from the template

Create a cluster from the template to generate a cluster YAML and commit it to your Git state repository.

Terminal window
hyve cluster create my-cluster --template my-civo-template

Reconcile

Reconcile reads Git, calls the module, and provisions the cluster. The same command works locally or from a CI/CD pipeline.

Terminal window
hyve reconcile

Features

Everything needed to run cluster fleets from a Git repo — nothing you have to operate on the side.

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 are bundled into Hyve itself.

Lifecycle Hooks

beforeCreate, onCreate, afterCreate, onDelete, afterDelete — run arbitrary workflows at each stage of a cluster’s lifecycle, automatically, every time.

Cluster Templates

Define the shape of a cluster once. Execute the template by name to stamp out clusters consistently across environments.

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.

Variable Injection

Module params are injected as HYVE_PARAM_* environment variables. Workflow outputs flow back as HYVE_KEY=value lines and are persisted for the next reconcile.

Why Hyve?

Think of it as a Git-based Terraform built specifically for clusters — and designed to work alongside the IaC you already have.

Keep your existing Terraform — Hyve drives the cluster, your IaC drives the rest

Hyve doesn’t replace Terraform for VPCs, IAM roles, or databases — it’s purpose-built for the cluster lifecycle and runs alongside general-purpose IaC. A beforeCreate workflow can run terraform init && terraform apply to provision supporting infrastructure before the cluster comes up, and afterDelete can tear it down. See Why Hyve for the full comparison.

Git is your state backend — no S3, no Terraform Cloud

Terraform requires a remote state backend with locking, versioning, and access control. Hyve’s state is the Git repository your team already uses. Full change history, pull request reviews, and rollbacks are inherent in Git — no extra backend to operate or pay for.

Continuous reconciliation — no plan files or approval gates

Commit a cluster YAML and it is created. Remove it and the cluster is deleted. Update a field and Hyve reconciles the difference. The same hyve reconcile command handles all three cases without separate plan/apply cycles.

Lifecycle hooks — no extra orchestration

After a cluster becomes active, you typically need to install controllers, run smoke tests, or notify a team channel. In Hyve, onCreate and onDelete hooks run automatically as part of the same reconcile cycle — define once, run every time.

Modules, not embedded SDKs

Old-style GitOps tools embed cloud SDKs. If your provider isn’t supported, you’re stuck. Hyve modules are external packages that shell out to any CLI tool you already have configured. Your credentials, your tools, your control.

Automatic kubeconfig management

Run hyve cluster auth my-cluster to merge any cluster’s kubeconfig into ~/.kube/config. The module handles the authentication call; Hyve manages the merge.

Native cluster templates — no Terragrunt required

For teams provisioning clusters to the same pattern, Hyve has native templates: define the shape once, instantiate by name. The resulting cluster YAML is committed, reconciled, and onCreate workflows run — all in one step.

Get started

Pick your entry point — the quickstart takes about five minutes.