Concept · Licensing · 4 min read

Licences, devices, and entitlement

Kaptain's licensing has three separate objects, and most confusion comes from treating them as one: the licence (a plan on your account), the device certificate (this machine's identity), and the lease (fresh, signed proof the two belong together).

The three-link chain

A licence attaches to your CHYNJ account email and names a plan. A device certificate is a keypair minted on the machine at registration — sign in at setup, or kaptain device register plus one approval click. A lease is a short-lived signed statement — "this certificate is entitled to this plan" — that a release build verifies at every start and quietly renews in the background.

Why three links and not a licence key check

Because each link answers a different attack. The key alone proves you bought something, not that this machine may use it — that's the certificate. The certificate alone couldn't be revoked or expired without phoning home constantly — that's the lease. Only the hash of a device fingerprint ever leaves the machine, the approval code is never stored server-side, and your access code isn't either: Kaptain stores hashes, you keep the secret.

Offline behaviour

A brief outage is a non-event: the current lease keeps working until its expiry, and validation falls back to a signed local cache. You never re-enter anything after reconnecting. The design goal is that licensing is invisible on a healthy machine and diagnosable on an unhealthy one — kaptain device status and kaptain license status print exactly which link is broken.

How it fails, honestly

Every failure surfaces as HTTP 402 with the same meaning: no current signed lease. Never bound, revoked in the portal, expired after a long offline stretch, moved to new hardware, trial ended, clock skew — each has a one-step fix, tabled in Licences, devices & 402s. Pro allows five devices; freeing a slot is one click in the portal.

Agent-readable version: index.md