What did your cluster look like at 3:47am?
A continuous recording of every resource in every cluster, including custom resources installed after it was deployed. Query any moment, diff any two, and see exactly which secret key rotated and when.
Questions that are hard today
Each of these is a query, not an investigation.
“What changed between Friday and Monday?”
A diff of two points in time across every resource kind, showing what was added, removed, and modified.
“What breaks if I delete this secret?”
Reverse dependency analysis over the observed reference graph, so you find the consumers before you find out the hard way.
“To recreate this, what must exist first?”
Restore ordering walked from the dependency graph as it actually was, not from a hand-maintained list of resource kinds.
“Which key of which secret changed, and when?”
A per-key change feed classifying every rotation, with no secret value stored anywhere you would run a query.
“Was this resource deleted, or did it never exist?”
Deletions are recorded as first-class tombstones, so "gone" and "never here" are different answers.
“What is running across all my clusters right now?”
One recording spanning clusters, accounts, and clouds, keyed so a fleet answers as one query.
A complete audit trail with nothing worth stealing in it
Secret auditing usually forces a bad trade: either you record enough to investigate an incident, or you avoid creating a database full of credentials. This does neither.
Every value is replaced by a hash of itself before the record is written. You can prove a key changed, see exactly which key it was, and order the timeline against everything else that happened in the cluster — from a query surface that contains no secret material at all. The full body goes to encrypted object storage separately, under your own key.
Every change is classified
- Secret created
- Key added
- Value changed
- Key removed
- Secret deleted
Built to leave the cluster
The change feed is shaped for export to your SIEM, so secret rotation becomes a signal your security team already knows how to consume rather than another console to check.
It records everything, and stays small
Total coverage is only useful if you can afford to keep it.
Zero-configuration coverage
Discovers every resource type the API server can list and watch, and registers new custom resource definitions as they appear. Install an operator tomorrow and it is recorded automatically.
Content-addressed storage
Bodies are stored once per unique content. An unchanged deployment observed ten thousand times costs one copy, so storage grows with change rather than with observation frequency.
Gap-proof by resync
A periodic reconciliation re-observes everything and emits synthetic deletions for resources that vanished, so a dropped watch connection cannot silently lose a deletion.
Deliberate exclusions
Ephemeral and controller-derived objects are skipped on purpose, because they are recreated by their owning controllers on restore. Fidelity is unaffected and the volume drops enormously.
Fleet-wide by design
Every record is keyed by cloud, account, and cluster, so multiple clusters across multiple clouds answer as a single history rather than as several.
Helm release history
Chart, values, and rendered manifests captured per revision, so a release rollback has the same evidence trail as everything else.
More in Cluster History
Recording everything is the foundation. These are what you do with it.
Dependency-ordered restore
Recreate a namespace, a workload, or a whole cluster as it was at a chosen moment, applied in an order derived from the observed dependency graph rather than a hardcoded kind list.
Command-line time travel
Query state, diff two moments, and walk secret history from your terminal, backed by the same queries the platform uses.
SIEM export for secret rotation
Stream the secret change feed into your existing security tooling as a first-class signal.
Pod-template reference extraction
Extend the dependency graph past ownership into the config maps, secrets, volumes, and service accounts a workload actually consumes, so blast-radius analysis reaches every consumer.
AWS and GCP object storage backends
Encrypted body storage on the cloud you already use. The storage layout is already namespaced by cloud so these slot in without a migration.
Frequently asked questions
- How is this different from Velero or a backup tool?
- A backup is a snapshot you took on a schedule. This is a continuous recording of every create, update, and delete, so you can query any moment rather than only the moments someone remembered to capture. It also answers questions a backup cannot: what changed between two times, what depends on this resource, and which key of which secret rotated last Tuesday.
- Does it capture custom resources?
- Yes, including ones installed after it was deployed. It discovers every resource type the API server can list and watch rather than working from a hardcoded list, and it watches for new custom resource definitions at runtime. Install a new operator tomorrow and its resources start being recorded with no code change, no config change, and no restart.
- Are my secrets stored in the database?
- No. Secret values never enter the queryable database. Each key is replaced by a hash of its value before the record is written, so you can see that a key changed and when, without the value being present anywhere you would run a query. The full body goes to encrypted object storage separately, under your own key.
- How does restore ordering work?
- Every observation records the references between resources, so the dependency graph is derived from what was actually in your cluster at that moment rather than from a hand-maintained list of resource kinds. Restore ordering walks that graph. When a new operator introduces new relationships, the ordering follows automatically.
- How much storage does continuous recording take?
- Less than you would expect. Resource bodies are content-addressed, so an unchanged deployment observed ten thousand times across resync cycles is stored once. Storage grows with actual change, not with observation frequency.
Stop reconstructing from memory
The next time someone asks what changed, the answer should take a query, not an afternoon.