Why Hyve?

Terraform and similar infrastructure-as-code tools are excellent at provisioning static, long-lived cloud resources — VPCs, IAM roles, databases, and networking. When the resource being managed is a Kubernetes cluster that a team creates, destroys, and recreates regularly, general-purpose IaC introduces friction that Hyve is designed to eliminate.

State Backend vs. Git

Terraform requires a remote state backend — S3, GCS, Azure Blob, or Terraform Cloud — with locking, versioning, access control, and its own operational overhead. Every team member needs the correct backend credentials, and the state file becomes a shared resource that can cause conflicts or corruption if mishandled.

Hyve’s state is the Git repository your team already uses. There is no separate backend to configure or pay for. The full history of every cluster change is inherent in Git: who changed what, when, and why, reviewed through pull requests like any other code.

Desired-State Reconciliation

Terraform models infrastructure changes as a plan-and-apply cycle. Destroying and recreating a cluster requires a destructive plan that demands careful human review. For environments where clusters are ephemeral — feature branches, load tests, short-lived demos — the plan/apply ceremony adds friction to every iteration.

Hyve treats the cluster definition as continuous desired state. Commit a new cluster YAML and it is created. Remove the file and the cluster is deleted. Update a field and Hyve reconciles the difference. The same hyve reconcile command, or a CI/CD pipeline step, handles all three cases without separate plan files or manual approval gates.

Post-Provision Automation

After a cluster becomes active you typically need to install controllers, apply manifests, run smoke tests, or notify a team channel. In Terraform this requires a separate orchestration layer: null_resource, CI pipeline steps, or an Ansible playbook wired in after apply.

In Hyve, onCreate and onDelete workflow hooks run automatically as part of the same reconcile cycle. Define the steps once in a workflow YAML file; they execute every time a cluster is created or destroyed with no additional wiring.

spec:
  workflows:
    onCreate:
      - install-controllers
      - run-smoke-tests
    onDelete:
      - drain-workloads
      - notify-team

Multi-Provider Without a Plugin Ecosystem

Adding a cloud provider in Terraform means finding or writing a provider plugin, pinning its version, running terraform init, and learning its resource schema. Provider APIs change and plugins lag behind. A GKE cluster in Terraform looks nothing like an EKS cluster; every attribute is provider-specific.

Hyve has first-party modules for Civo, AWS EKS, GCP GKE, and Azure AKS — and the module system means any other provider is supported by writing a module. The same cluster definition structure, the same CLI commands, and the same workflow hooks work across all providers.

# Civo — driver points to the Civo module
spec:
  driver:
    source: github.com/hyve-modules/civo
    version: v1.0.0
  params:
    node_size: g4s.kube.medium
    node_count: "3"

# EKS — same structure, different module
spec:
  driver:
    source: github.com/hyve-modules/eks
    version: v2.1.3
  params:
    instance_type: t3.medium
    node_count: "3"

Kubeconfig Management Is Solved

Terraform outputs a kubeconfig as a sensitive value you then have to route somewhere useful — write it to a file, push it to Secrets Manager, reference it in a downstream pipeline step. There is no standard answer.

Hyve’s module auth operation merges any cluster into your local ~/.kube/config with a single command:

hyve cluster auth my-cluster

When a cluster is removed — either manually or through reconciliation — Hyve removes the corresponding context from ~/.kube/config automatically.

Cluster Templates

For teams provisioning clusters repeatedly to the same pattern — a standard three-node staging environment, a spot-instance batch cluster, a prod cluster with specific node groups — Terraform requires copy-pasted modules or a wrapper tool like Terragrunt.

Hyve has native cluster templates: define the shape of a cluster once, including its provider, region, node groups, and workflows, then instantiate it by name:

hyve cluster create my-feature-cluster --template staging-standard

The resulting cluster YAML is committed to the state repository, reconciled, and the onCreate workflows run — all in one step.

The Summary

Git is the state backend

No S3 bucket, no Terraform Cloud, no locking. The repository is the state.

Continuous reconciliation

Commit to create, delete to destroy. No plan files or approval gates.

Built-in post-deploy hooks

onCreate and onDelete workflows run automatically — no extra orchestration.

Consistent multi-cloud interface

Civo, AWS, GCP, and Azure behind the same YAML schema and CLI commands.

Automatic kubeconfig access

hyve cluster auth merges a cluster’s context into ~/.kube/config directly via the module’s own auth operation, with hyve cluster deauth to clean up on deletion.

Native cluster templates

Reusable cluster patterns with workflows — no Terragrunt required.