Terraform, alongside the rest
The Hyperfluid provider describes your resources in the same modules as the rest of your infrastructure, service links included
One Terraform plan
GitOps, CLI and Terraform
Your platform in YAML, in Terraform, or in one command.
Three ways to drive the platform, one declared state
Describe your resources in YAML: a native Kubernetes operator reconciles your Git manifests into the cluster, with the GitOps tooling already in place. Describe them in Terraform with the Hyperfluid provider, alongside the rest of your infrastructure. Or drive them from the terminal with hfctl, without opening the console.
Specifications
- Operator
- Single, Kubernetes native
- CRDs
- 39 custom resources
- Terraform provider
- hyperfluid, resources and data sources
- CLI
- hfctl, from terminal to platform
- GitOps tools
- Argo CD, Flux, kubectl
- Drift
- Drifted phase, detailed columns
Use cases
Everything from the terminal
hfctl creates a pipeline and follows its run, manages agents, declares service links and queries your data, without opening the console
One command instead of one screen
Multi-environment deployment
The same manifests travel through dev, staging and production, only the values change
One repository, several environments
Infrastructure as Code
The Git history carries the who, the what and the when of every resource change
Every change is a Git commit
Rebuilding from Git
Whatever is declared is reapplied through resynchronization, without redoing the steps by hand
Declarative infrastructure, reconstructible
In action
The platform described in Git
A platform team wants the state of its internal cloud to live in a Git repository, not in a history of clicks
- Declare resources as Kubernetes CRDs: SQL engine catalogs, Iceberg schemas and tables, container apps, managed databases
- Apply the manifests with the tool already in place: Argo CD, Flux or kubectl
- The Hyperfluid operator reconciles each CRD into the matching Kubernetes resources
- The console reads the CRD status and shows each resource phase: Ready, Pending, Drifted or Failed
The state of the platform is described in Git, the console provides the read view
Rolling back is a commit
An operations team needs to undo a configuration change that reached production
- Identify the commit that modified the manifest in question
- Run a git revert on that commit and push it to the tracked branch
- The GitOps reconciler resyncs the resources back to the previous state
- The operator brings the infrastructure back to the declared state, the console shows the reconciliation phase
Rolling back goes through Git, with no manual action on the cluster
Every table shows where it came from
A BI analyst opens the catalog and needs to tell what is declared from what was created by hand
- In the console SQL engine, every Iceberg schema and table carries an origin badge
- The badge distinguishes a resource declared outside the console, created in the console, produced by a pipeline, or ad hoc with no matching CRD
- If the actual table diverges from its declaration, the phase turns to Drifted and the console details the missing or extra columns
- The fix happens in the versioned manifest, the operator reconciles
The gap between the declared catalog and the actual catalog is visible in the console
Declarative infrastructure
Operator
Kubernetes native
A single operator and custom resources in the hyperfluid.nudibranches.tech API group, applied like the rest of your cluster.
Manifests
Git holds the reference
Catalogs, Iceberg schemas and tables, container apps, managed databases: every resource is a versioned manifest.
Tooling
Argo CD, Flux, kubectl
CRDs apply with the tool already in place. Imperative fields, such as restartedAt on a ContainerApp, are documented for your diff-ignore rules.
Drift
Reported, never destructive
The operator continuously reconciles toward the declared state. On an Iceberg table the gap moves to the Drifted phase: adding the missing columns is opt-in, no column is ever dropped automatically.
Key benefits
- Platform resources are described in versioned manifests, not in a history of clicks
- The operator continuously reconciles resources toward the declared state
- The gap between declared and actual is visible in the console, down to the columns involved
- Rolling back is a git revert, with no manual handling of the cluster
- CRDs apply with the GitOps tooling already in place, Argo CD, Flux or kubectl
Ready to automate your deployments?
Discover how GitOps can transform your infrastructure workflow.