Skip to content

The stack

The three tools operate at different layers and do not depend on each other. You can adopt any one of them alone. They are designed to compose, not to require each other.

Helvilette’s design document describes the layering that the whole ecosystem inherits — the observation that the most useful place to stand is underneath the thing everyone else is automating.

Layer 4: ┌─ Kubernetes ───────────────────────────┐
│ Pods, Deployments, Services │
│ ← Kuberina plans what goes where, │
│ before any of this runs │
Layer 3: ├─ Container runtime (containerd) ───────┤
│ ← Kallisto sidecar answers secret │
│ reads on loopback, per request │
Layer 2: ├─ systemd ──────────────────────────────┤
│ kubelet.service, containerd.service │
│ etcd.service, kube-apiserver.service │
│ ← Helvilette Agent lives here, and │
│ can perform surgery on all of it │
Layer 1: ├─ OS (Linux) ───────────────────────────┤
└────────────────────────────────────────┘

Helvilette’s position at Layer 2 gives it a capability the layers above cannot have: managing the managers. Kubernetes cannot rolling-update its own kubelet or restart its own kube-apiserver, because it cannot operate on its own brain. A systemd-level agent can.

The layer map is spatial. The other useful view is temporal — when each tool acts relative to a deployment.

BEFORE DURING CONTINUOUSLY
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Kuberina │ │ Kallisto │ │ Helvilette │
│ │ │ │ │ │
│ Solve placement │ ───► │ Serve secrets │ ◄──► │ Detect drift │
│ Emit blueprint │ │ on every read │ │ Re-converge │
│ Review it │ │ Poll one sealed │ │ Report state │
│ kubectl apply │ │ file, read-only │ │ Heal Layer 2 │
└─────────────────┘ └─────────────────┘ └─────────────────┘
Runs offline, Runs on the hot Runs forever,
zero cluster path, loopback only pull-based, no
interference inbound SSH

Kuberina is a planner: it runs once, produces an artifact, and exits. Kallisto is a resolver: it runs beside each application, pulls one sealed file, and answers reads. Helvilette is a control loop: it never stops.

Nothing forces you to use all three, but here is what the seam looks like when you do.

  1. Helvilette brings a fleet of bare-metal nodes to a known state — kernel tuning, container runtime, kubelet, node labels. This is the one place Ansible still runs, and after the initial bootstrap it runs pull-based with no inbound SSH.
  2. Kuberina reads the resulting cluster topology and your workload manifests, solves the packing problem offline, and emits blueprint.yaml. Your team reviews it the way they review code, iterates, and applies the version they agreed on.
  3. Kallisto runs as a sidecar beside the workloads Kuberina placed. An operator seals their operational secrets into one file on a bucket, and each resolver polls it. The workloads fetch secrets from 127.0.0.1 per request, so neither a rollout nor a sealed Vault reaches the request path.

The seams are deliberately loose. Kuberina emits YAML that any Kubernetes accepts. Helvilette runs playbooks that work fine without it. Kallisto speaks an API that Vault already speaks.

If your problem is…Reach for
Expensive GPU nodes sitting at 30% utilisation while pods go unschedulableKuberina
Config drift across VMs, and SSH keys concentrated on one laptop or CI serverHelvilette
Your services stalling every time Vault is sealed, failing over or upgradingKallisto
Services re-reading the same secrets on every request, or .env files lying around on diskKallisto
Nobody owning the question of who operates Vault and Consul themselvesThe day-2 problem first
Needing to justify a placement decision to someone who will challenge itKuberina plus the paper