How it works
Preflight to kubeconfig, one command at a time
Six steps from an empty inventory to a cluster your team can rely on — no hand-edited YAML, no tribal knowledge.
Preflight the environment
Validate Ansible, Python modules, SSH keys, and node connectivity before any playbook touches a host.
Render the inventory
cluster.conf generates hosts.yaml and group_vars from CONTROL_PLANE_IPS and WORKER_IPS — no hand-edited inventory files.
Deploy with pinned Kubespray
A pinned Kubespray Ansible checkout runs cluster.yml over SSH, standing up the control plane the same way every time.
Choose your networking and add-ons
Pick your CNI (the plugin that gives every pod its networking — Calico, Cilium, Flannel, and kube-ovn are four common choices), plus metrics-server, ingress-nginx, or dashboard, straight from config.
Scale and upgrade in place
scale.yml and upgrade_cluster.yml extend or update the same cluster without a rebuild.
Hand off kubeconfig
admin.conf is fetched to your laptop automatically, and forge-handoff emits a JSON payload the rest of the suite can import.
One config file drives the full lifecycle
hypercluster doesn't replace Kubernetes — it removes the manual, error-prone glue work of standing one up, using the same Kubespray automation already proven in production elsewhere.
# cluster.conf — the only file you edit CONTROL_PLANE_IPS=<ip>,<ip>,<ip> WORKER_IPS=<ip>,<ip> CNI=cilium # or kube-ovn, calico, flannel # hypercluster renders the inventory, then Kubespray runs: # hosts.yaml + group_vars generated, never hand-edited # cluster.yml deploy the control plane # scale.yml add workers # upgrade_cluster.yml rolling upgrade, one node at a time # kubeconfig lands on your laptop automatically admin.conf → ~/.kube/config # Hand the cluster to Zynera for Day-2 hypercluster forge-handoff --json
HyperCluster
Bare-metal Kubernetes lifecycle over SSH. Building a Kubernetes cluster by hand — one server, one command, one mistake at a time — is where a lot of outages start before a single workload ever runs on it. HyperCluster replaces that manual process with a standardized, repeatable one: the same bring-up, scaling, and upgrade steps every time, built on Kubespray (proven, widely-used Kubernetes automation), so the cluster underneath the rest of your infrastructure is never the thing that fails.
What you get
One CLI, the whole lifecycle
12 commands driven from a single cluster.conf file — preflight, deploy, scale, upgrade, destroy — with production and staging kept separate.
Networking that fits your environment
Choose from 4 CNI options — Cilium, kube-ovn, Calico, and Flannel — so the cluster matches your existing network model instead of forcing a new one.
Run VMs alongside containers, if you need to
Optional KubeVirt + CDI post-deploy hooks add virtual-machine support for Zeus OS, Veyron, and confidential workloads — skip them if you don’t need it.
Keep production and staging apart
Isolated inventories and kubeconfig outputs per environment, so a staging change can never touch production by accident.
Built for production
Cluster — the Kubernetes foundation the rest of the suite runs on.
Why teams choose us
- Stand up the Kubernetes layer once, then build on it with Zeus OS, PacketWolf, Zynera, and IronWolf — no re-bootstrapping for each product
- Fits directly into Transiva export-first migration programs, so cluster bring-up isn’t a separate project
- Destroy and rebuild on demand, so lab environments stay a true match for production instead of drifting apart
When to choose
- You want a Kubernetes cluster stood up the same repeatable way every time, before adopting KubeVirt or Cilium-based products
- You need multi-site coordination or confidential-computing (TEE) node prep — these are Enterprise deliverables
HyperCluster questions
How it works
- 1Preflight
- 2Deploy
- 3Scale
- 4Upgrade
hypercluster init --profile kubespray-haMigrate from the platforms you already run
- Enterprise Hypervisors
- HCI Platforms
- AWS
- Azure
- Google Cloud
- Windows Hypervisor
- Oracle Cloud
- Machina fleet cloud
- KubeVirt
- KVM
- KVM-based Platforms
Under the hood
One config file drives the full lifecycle
hypercluster doesn't replace Kubernetes — it removes the manual, error-prone glue work of standing one up, using the same Kubespray automation already proven in production elsewhere.
- cluster.conf
- hypercluster
- Kubespray (Ansible)
- nodes via SSH
- clones .kubespray/ at pinned version
- generates hosts.yaml + group_vars
- cluster.yml · scale.yml · upgrade_cluster.yml
- fetches kubeconfig to your laptop
Preflight checks
Validate Ansible, Python modules (jinja2, netaddr), SSH keys, and connectivity before any playbook runs.
Deploy & init
Clone Kubespray, render inventory from CONTROL_PLANE_IPS and WORKER_IPS, deploy the control plane, and pull admin.conf locally.
CNI & add-ons
Choose Calico, Cilium, Flannel, or kube-ovn; enable metrics-server, ingress-nginx, or dashboard from cluster.conf.
CIDR-safe planning
Documented pod and service subnet guidance — CIDR ranges, the blocks of IP addresses Kubernetes hands out internally — so node networks never overlap Kubernetes allocations.
macOS Desktop app
Hypercluster Desktop for Apple Silicon — 30-day free trial, download below. CLI deploy scripts also run from macOS and Linux laptops.
Suite foundation
Bootstrap the Kubernetes substrate for Zeus OS, Veyron, PacketWolf, Zynera, and IronWolf — export and convert first, cluster second.
Virtualization platform
The k3s path installs a turnkey KubeVirt stack
Set K8S_DISTRO=k3s and hypercluster deploy lays down the full stack for running virtual machines on Kubernetes in one run — no pile of individual Helm installs to babysit by hand.
Cilium, kube-proxy-free
This swaps in a different networking engine than a stock cluster ships with: Flannel, kube-proxy, Traefik, and servicelb are disabled, and Cilium takes over pod networking and load-balancing — with optional Hubble, BGP, Gateway API, and WireGuard encryption from cluster.conf.
MetalLB LoadBalancer
MetalLB (software that hands your bare-metal cluster real, routable IP addresses the way a cloud load balancer would) means Services of type LoadBalancer work without a cloud provider — IPs come from METALLB_IP_POOL instead.
cert-manager
cert-manager (the standard tool for automatically issuing and renewing TLS certificates inside a cluster) is installed and health-gated, so webhook certificates are ready before KubeVirt and CDI (Containerized Data Importer — pulls VM disk images into the cluster) land.
KubeVirt + CDI
Both install and reconcile automatically — run virtual machines as ordinary pods, with disk images imported and ready from day one.
CNAO, snapshot & CSI
Optional add-ons toggle on from cluster.conf: CNAO (Cluster Network Addons Operator, for VMs that need more than one network interface), snapshot-controller, and the KubeVirt CSI (Container Storage Interface — the standard way Kubernetes plugs in storage systems) driver for volume snapshots.
Single-node lab tuning
lab storage mounts a secondary disk into a StorageClass; lab tune scales HA replicas down (and --restore back) so the whole stack fits one box.
Distribution engines
One CLI, five Kubernetes distributions
The same cluster.conf and lifecycle commands drive whichever engine fits the site — Kubespray for production HA, k3s for KubeVirt labs, and three more — so switching distributions later doesn't mean relearning your tooling.
Kubespray (kubeadm)
The default: upstream Kubernetes via pinned Kubespray Ansible playbooks with generated inventory and group_vars.
k3s
Lightweight single-binary Kubernetes for KubeVirt labs and edge — bundled with the turnkey platform stack above.
RKE2
A hardened Kubernetes distribution across servers and agents, with the optional platform stack layered on after.
MicroK8s
Snap-based install and node join for quick Ubuntu clusters.
Talos
Immutable, API-managed OS path for locked-down nodes.
Same day-2, every engine
preflight, deploy, kubeconfig fetch, and destroy behave the same regardless of K8S_DISTRO.
Storage
Provision cluster storage without guessing which disk is safe
storage inventory, plan, apply, and teardown wrap local-path, lvm-raw, and rook-ceph behind one workflow that refuses to touch a disk holding data.
Inventory first
storage inventory enumerates block devices per node — read-only — and reports which are safe to use; unmounted Ceph OSDs, LVM PVs, and mdraid members are flagged ineligible.
Plan before touching anything
storage plan previews STORAGE_BACKEND and STORAGE_DEVICES against the inventory so you see the effect before running apply.
Apply with an explicit safety catch
storage apply provisions the planned backend and refuses any disk that is not eligible unless it is named exactly via --confirm-destroy.
Three backends
local-path for a fast default StorageClass, lvm-raw for a dedicated device, or rook-ceph for replicated block storage — set from cluster.conf.
Clean teardown
storage teardown unmounts, removes fstab entries, and (with --purge-disks) wipes signatures — including purging Rook if the backend was rook-ceph.
Pre-cluster probing
storage-probe inventories disks by IP and SSH creds directly, no cluster.conf required — what the desktop Studio wizard uses before a cluster exists.
Discover & hand off
Build the inventory, then hand the cluster to Zynera
Find nodes before you deploy, watch them after, and emit a structured payload the rest of the suite can import.
Infrastructure discovery
hypercluster discover enumerates candidate nodes from libvirt, KVM-based platforms, enterprise hypervisors, an SSH CIDR scan, or a CSV — with optional SSH validation and --json for tooling.
JSON-native day-2
status, health, vms, and workloads all speak --json; health --with-test runs the k3s platform smoke tests, and vms lists KubeVirt VMs plus the template catalog.
Zynera Day-2 handoff
forge-handoff --json emits cluster name, API endpoint, kubeconfig path, and detected stack components (Cilium, MetalLB, KubeVirt…) so Zynera can import the cluster for Day-2 operations.
Full discovery, health, and handoff CLI reference in the docs →
Desktop Cluster Studio
The same CLI, driven visually with live logs and an AI copilot
A native desktop app for macOS Apple Silicon wraps the identical hypercluster binary — nothing runs that the CLI can't also run on its own.
Cluster Creation Studio
Quick Deploy in 3 steps, or a full Intent → Nodes → Network → Platform → Validate flow that writes cluster.conf from a typed spec — pick Basic, Advanced, or Expert.
14-section cockpit
Per-cluster detail view — Overview, Nodes, Workloads, Networking, Storage, Platform, VMs, Templates, GPU, Security, Observability, Backups, Upgrades, Settings — backed by the same health/status/vms --json commands.
Live deploy console
Streams stdout/stderr with parsed deploy stages and native success/failure notifications; Cancel job sends SIGTERM to the running hypercluster subprocess.
Command palette & Monaco editor
A command palette runs any hypercluster action from the keyboard; a Monaco editor edits cluster.conf directly, with save-and-preflight built in.
Zyvor AI Copilot
Always-on offline fleet insights, plus optional LLM chat against OpenAI, Ollama, or Anthropic with cluster context auto-injected — answers come back as hypercluster commands, never raw kubectl.
30-day free trial
Full feature access during the trial, tracked in Keychain. Download below, or bring your own build via npm run desktop.
Download · Free trial
30-Day Free Trial — Apple Silicon
Hypercluster Desktop 0.1.0 for macOS 13 Ventura or later · Apple Silicon (M-series) · 6.9 MB
| macOS | 13 Ventura or later |
| Architecture | Apple Silicon (M-series) only |
| Package | Hypercluster-0.1.0.pkg · 6.9 MB |
| Install | Double-click Hypercluster-0.1.0.pkg. macOS Installer handles everything including the bundled CLI runtime. |
| Uninstall | Run Uninstall-Hypercluster.command (in the distribution folder) or drag Hypercluster.app to Trash. Trial record is kept in Keychain. |
| Trial | 30 days — all features unlocked: cluster deploy, scale, upgrade, preflight checks, AI insights, kubeconfig delivery. |
| After trial | Email [email protected] with your team size and use case. We send a licence key by return. Per-seat and team plans available. |
Download Hypercluster 0.1.0.pkg (6.9 MB)
macOS 13 Ventura or later · Apple Silicon only · No login required
Community Edition scope and proprietary licensing are documented under Product suite → Community Edition and Licensing overview. Enterprise programs add supported releases and SLAs — compare plans or book a demo.
Day-2 cluster operations
Scale out workers
Add IPs to cluster.conf and run scale — Kubespray only provisions new nodes.
Rolling upgrades
Cordoned, drained, one-node-at-a-time Kubernetes upgrades aligned with supported minor-version steps.
Confidential fabric prep
After Kubespray deploy, run bundled Kata/SPIRE install scripts to label TEE nodes for Ragnarok confidential workloads.
Optional KubeVirt + CDI
Post-deploy hooks for KubeVirt v1.3+ and CDI — foundation for Zeus OS, Veyron, and confidential workloads.
Multi-environment
Separate prod.conf / staging.conf files with isolated inventories and kubeconfig outputs — Cilium or kube-ovn CNI choices.
From laptop to Ready nodes
Preflight & deploy
- Verify Ansible, Python deps, and SSH to every node
- Generate Kubespray inventory from cluster.conf
- Fetch admin kubeconfig to your workstation
Runtime choices
- Podman, containerd, or Docker as container manager
- Calico, Cilium, Flannel, or kube-ovn CNI plugins
- Optional metrics-server, ingress-nginx, and dashboard add-ons
Signature deck
Download the h2kvm-format PDF or open the HTML preview for stakeholder reviews.
Free trial
30-day free trial — HyperCluster
Bare servers to a production-ready Kubernetes cluster, driven from one config file.
- Full feature access during the trial, tracked in Keychain
- Apple Silicon desktop download, or bring your own build via npm run desktop
- Email [email protected] with team size and use case for a licence key
After the trial window, it is completely up to you whether to continue. There is absolutely no pressure or obligation from our side.
HyperCluster · Cluster lifecycle
Ready to standardize cluster bring-up?
See how HyperCluster pairs with the migration and KubeVirt products in your hypervisor exit or private-cloud program.