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.

Everything below compares Hyve’s local-directory CLI mode against Terraform — the comparison that matters most for how state and reconciliation work. Hyve can also run as a cluster-native controller + API for team/multi-tenant use, sharing the exact same reconcile engine and YAML; that mode doesn’t change any of the reasoning below, it just moves where hyve reconcile runs from.

A Directory as State, Not a Service

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 just a local directory — clusters/, templates/, workflows/, plain YAML files. There is no separate backend to configure or pay for, and no requirement that it be anything more than a folder on disk. Put it under git (which most teams will) and the full history of every cluster change — who changed what, when, and why — comes from git itself, reviewed through pull requests like any other code, with zero extra tooling. Skip git and hyve reconcile works exactly the same against the same directory; you just lose that history.

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. Add 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.

Any provider is supported by writing a module — a small git repository of scripts around the provider’s own CLI or API (see 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/your-org/hyve-civo-module
    version: v1.0.0
  params:
    node_size: g4s.kube.medium
    node_count: "3"

# EKS — same structure, different module
spec:
  driver:
    source: github.com/your-org/hyve-eks-module
    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 written to the environment directory, reconciled, and the onCreate workflows run — all in one step.

The Summary

A directory is the state backend

No S3 bucket, no Terraform Cloud, no locking. Add git for free history and review — or don’t.

Continuous reconciliation

Add 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

Any provider behind the same YAML schema and CLI commands — the module is the only thing that changes.

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.