Attestkeep docs

Licensing

One activation key per plan. Each key binds to as many clusters as the plan allows, and you can move a slot yourself.

Plans

Every capability is on in every plan. Scanning, signature verification, admission enforcement and evidence packages are complete in Community. What grows is the counts.

PlanPer yearClustersFrameworksImage names / month
Communityfree11, your choice15
Team$4,8001150
Business$14,40033200
Enterprisefrom $30,000unlimitedunlimitedset in your agreement

Single sign-on and strict admission (failurePolicy: Fail, deny until scanned) are the two capabilities that are paid-only. Everything else is in Community.

The metered unit is the image name

The quota counts distinct image names: registry and repository, with the tag and digest stripped.

ghcr.io/acme/api:1.24.3     ─┐
ghcr.io/acme/api:1.24.4      ├─ one image against the quota
ghcr.io/acme/api@sha256:...  ─┘

docker.io/library/postgres:15  ─┐
docker.io/library/postgres:16  ─┴─ one image against the quota

Counting digests instead would punish exactly the deployment frequency this product wants to encourage: three deploys a day across five services is around 450 digests a month while running five things. So the meter counts repositories.

Everything running in the cluster counts, third-party images included — postgres, nginx, your ingress controller, your monitoring stack. Those are where most CVEs actually come from, so scanning them is the value rather than an overhead.

At the limit

When the quota is exhausted, only new image names are denied at admission. Every image already counted this period keeps being scanned and keeps being enforced.

The product never holds a running workload hostage over a billing threshold. A security tool that takes production down for that reason gets uninstalled, and deservedly.

Activation

Activation happens once per cluster and spends one slot. On the first run the operator generates a keypair inside the cluster, keeps the private half in a Secret, and sends only the public half with the activation request. The activation key itself travels exactly once.

What is sent:

What comes back is a signed certificate valid for at most thirty days. It is verified inside the cluster against a public key built into the operator, so enforcement never waits on a network call.

The daily check

Once a day the operator sends three values — licence id, cluster fingerprint, operator version — signed with the keypair from activation. The answer is a status, and a fresh certificate only when something changed or the current one is running out.

Nothing about your images, your workloads, your policies or your findings is sent. There is no telemetry channel and no setting that would add one.

Being unreachable is not being denied

If the licence service cannot be reached, the installation keeps running on the certificate it already holds, for that certificate's remaining term. Only a cluster with permanently no route at all cannot hold a paid licence.

A revoked or released answer applies at the next check. There is no offline licence format and no setting that turns the check off — that is a deliberate limit, and the only thing in the product that needs a route out.

Cluster slots

Each activation holds a slot until it is released. You release one yourself, from your licences page — deleting a cluster should not mean opening a support ticket to reuse the slot you paid for.

A released slot is free immediately, and the installation that was holding it drops out at its next daily check.

Reinstalling into the same cluster does not spend a second slot: the fingerprint is the same, so the existing slot is handed back. If you have run out, the error names the clusters that are holding your slots and when each one activated, so you can decide which to release rather than guess.

What the key does not do

The activation key is not a password and it does not authenticate a person. It does mean that anyone holding it can spend one of your cluster slots, so treat it the way you would treat a registry pull secret.