Licensing: the key, and the deployment it runs

Nyxus runs against an activation key. The key is what your registry credential is minted from, what the portal shows a subscription by, and what says when the term ends. It is signed by Nyxus and checked by your receiver, so most of what it says is readable without asking anybody.

One thing it cannot answer on its own: whether somebody else is also running it. That is what the registry is for, and from 0.2.0 a key runs one deployment at a time.

This page covers what the key states, how a deployment takes and gives up its claim on a key, and what to do when you see it held somewhere you did not expect.

What the key states

System health > Subscription, as an owner - the organisation card at the top of the sidebar opens it, and so does typing "System health" into Go to. The card shows the organisation, your reference, the plan, when it expires, the device limit if the key states one, how many deployments it covers, the registry it works against, and a fingerprint. The key itself is never shown again after it is entered - it is a credential, and the fingerprint is what identifies it.

Deployments says how many installations may run the key at once. Unless your key says otherwise it is one. A key that covers more states the number, and the portal shows it; nothing is enforced against you that your key does not say.

One key, one deployment

Each installation generates a random identity for itself the first time it runs, and sends it with the subscription check it already makes. The first deployment to ask holds the key. Another installation asking with the same key is told it is held elsewhere.

That identity lives in the receiver's state directory, which has two consequences worth knowing before they surprise you:

• Restoring a backup keeps the claim. The identity is in the state directory, so a restore - onto new hardware, into a new cluster - is the same deployment as far as the registry is concerned. Nothing to release, nothing to ask for.

• Rebuilding from nothing asks as a stranger. A new install with no restored state generates a new identity, and the old one is still holding the key.

Moving a key to another deployment

Reclaim key, on that same Subscription card, as an owner. It releases the claim at the registry and then forgets the key here, in that order. Use it before you decommission a deployment, and the key is free to enter on the new one straight away.

It is one control rather than two on purpose. Releasing the claim without forgetting the key undoes itself - this deployment re-checks within six hours and takes the key back. Forgetting the key without releasing the claim leaves the claim held by a deployment that no longer knows the key.

If you have already rebuilt without reclaiming, you do not need to call anybody. A claim is only defended while the deployment holding it is still checking in. Fourteen days after the old one goes quiet the new deployment takes the key at its next check, on its own. If you need it sooner than that, ask Nyxus to release it.

What you see while a key is held elsewhere

Nothing stops at once. The deployment that cannot claim the key keeps working and says so on the Subscription card, on System health:

This key is in use on another deployment. New findings and enrolments
continue for another 13 days; after that this deployment stops taking new
work until the key is released.

At the end of that fortnight it stops accepting new findings and enrolments. What is already stored stays readable, and the portal keeps working. It is the same grace a deployment gets when it cannot reach the registry at all, for the same reason: a licence question should never take an estate offline before somebody has had a chance to answer it.

The fortnight is also exactly how long the registry defends the other claim. If the deployment holding the key has genuinely gone - the usual case, a cluster rebuilt without reclaiming - both clocks run out together and this deployment takes the key. If the other one is still running, it keeps the key, and this one is the copy.

What the registry is told

The subscription check sends your reference, a fingerprint of the key, this deployment's random identity, and a number used once. It carries no estate data: no devices, no findings, no people, no tool names. The answer is signed and bound to that number, so an endpoint pretending to be the registry cannot say a key is active.

Older keys

A key issued before 0.2.0 states no deployment limit. It is treated as one, which is what the registry enforces for it, so the two agree. Your portal shows One at a time for it.

Enforcement only reaches a deployment once it upgrades. A deployment left on an earlier release never claims a key and is never told one is held.