Kallisto

PrototypeAGPLv3Rust 2024

Secret delivery for the request path.

Naughtian Kallisto is a high-performance cache for secrets, sitting between your workloads and your root of trust.

The dataplane runs on every node and answers secret reads locally, so your API gateway, worker nodes and CI runners can fetch secrets per request instead of once at boot.

The controlplane runs the fleet — pushing invalidations, warming caches before a rollout, and reporting how much plaintext is resident across every node.

The point is availability, not throughput

Kallisto is easy to mistake for a performance optimisation. The sharper reason to run it is that your request path survives Vault being unavailable.

Vault starts sealed after every restart. Raft failover means a leader election. An upgrade means a careful step-down. Each of those is a window in which everything that depends on Vault is stalled — and unlike a slow query, a failed secret read usually means a process cannot start at all.

With reads terminating on the local node, that window stops being an outage. A hard dependency on a quorum-bound system becomes a soft one.

The throughput argument is real as well — no stampede against the root of trust when five hundred pods start at once — but it is the smaller half. See the day-2 problem for the full reasoning.

Adoption is one line

Kallisto is compatible with the Vault KV-v2 API:

VAULT_ADDR=https://vault.internal:8200
VAULT_ADDR=https://localhost:8200

Removing it is the same line. That symmetry is deliberate — nothing here should be hard to back out of.

Prototype. Do not run this where it matters.

Working today: the KV-v2 read/write path, the cuckoo cache, CLOCK eviction.

Not built yet: authentication on the data port, TLS, the encryption barrier, and the entire controlplane.

See project status before going near a production system.

It sits in front of a root of trust, not instead of one

Kallisto is designed to integrate with existing secret management systems — HashiCorp Vault, OpenBao, Infisical, Conjur. This is an intentional design decision that avoids taking on the security responsibilities of being a root of trust.

Do not use Kallisto as a drop-in replacement for your Vault or OpenBao infrastructure. It offers a similar API surface and contract, but it cannot and should not serve as your upstream secret management platform.

Use cases

Cache layer for a root of trust

Serve secrets from an upstream system quickly and at scale, right at the node, without your own infrastructure DDoS-ing your Vault at every rollout.

Secure secret storage

In standalone mode, store key/value pairs encrypted before they hit persistent storage — so your workloads can use secrets without .env files lying around on disk.

Secure edge config server

Provide shared TLS certificates and API keys to an API gateway or load balancer fleet at the edge.

Start here

Run Kallisto with DockerGet a server answering KV-v2 requests in a couple of minutes.

Build from sourceCore CLI build, server build, and the local development setup.

Run the benchmarksk6 and wrk2 harnesses for validating throughput and latency.

Project statusWhat works, what does not, and the versioning warnings that come with it.

A note on this documentation

Kallisto maintains its own documentation site in its repository under docs/, built with Hugo and already organised along Diátaxis lines. The pages here cover the essentials; the deeper material — ADRs, benchmark archives, internals, telemetry — has not yet been migrated into this site. See documentation status for what lives where.