Editions and license¶

kubelatch has two editions. Free is the whole product with some limits; Pro lifts them with a license key that kubelatch verifies on its own, with no call to any service. This page says what each edition includes, how to install a key and what happens when it expires.

What each edition includes¶

Every enabled person counts, administrators and break-glass accounts included; bots never do. Disabling someone frees their place. A cluster is any registered cluster, whatever its status; deleting one frees its place. Pro is priced per person: see kubelatch.com/pricing, which also offers a 30-day trial with no card.

The edition in force shows beside the name at the top of the sidebar, for everyone. An administrator can click it to open Edition, which the account menu at the bottom of the sidebar also has.

What a limit does¶

A limit only stops a new registration. These answer 422 edition.limit:

• Inviting the 6th person, or re-enabling one when 5 are enabled.
• Registering the 3rd cluster.
• Creating or editing a custom role.

kubelatch-server user create refuses the 6th person with a message that points to this page. The interface says so where it happens and in Edition. Nothing that exists is ever cut: the proxy, permissions, credentials, clusters and people keep working.

In Free, Audit shows the last 24 hours. An instance that never had a key keeps the audit at most 24 hours (a longer KUBELATCH_AUDIT_RETENTION is capped at 24 hours, and 0 becomes 24 hours too); one that has or had a key (a lapsed key counts too, and so does a key that does not verify for as long as it stays configured) keeps its configured retention and only stops serving what is older than 24 hours until a key is installed.

The Edition page¶

Edition opens with one sentence that says where the instance stands, with dates relative to today:

• Free · 2 of 2 clusters · 4 of 5 people · audit 24 h
• Pro · 20 seats · expires in 365 d (Oct 9, 2027), or Pro trial · ends in 12 d (Oct 22)
• Pro expired · grace until Nov 8 (in 12 d): then Free limits for new registrations
• Pro lapsed · Free limits for new registrations since Nov 8

Under a paid key, a timeline gives its three milestones: Pro until …, Grace until … and Free limits from …, with the current one in bold. A trial has none: it has no grace.

Usage and limits counts people, clusters and custom roles against their caps. Each label links to its list (Users, Clusters, Roles), and a row at its cap says what frees a place: At the limit: disabling someone frees a seat. or At the limit: deleting a cluster frees one. A cap of zero reads Pro only (3 kept · Pro only when a lapsed key left custom roles). Audit retention gives the value in force (24 h, 90 d or Kept forever) and, on a Free instance whose configured retention is longer, the last 24 h are shown.

Status lists, besides the sentence, the Key source (No key, KUBELATCH_LICENSE or Pasted here), the Customer, the License id in a field to copy, Grace until (only in grace), Over the seats since (only while over) and Problem with the key (when it doesn't verify). The Version row says which kubelatch runs and what the daily check found: 0.30.0 · 0.31.0 is out with How to upgrade, 0.30.0 · the latest (checked 3 h ago), 0.30.0 · not checked yet or 0.30.0 · update check off. While the check is on, Check now checks at once (Upgrades).

Installation health lists the settings that protect the instance, each with its state: Pod Security Admission, two-factor authentication in the GitHub organization, the GitHub sync and its member_removed webhook (these three only with the GitHub App), the clusters' reconciliation, the license key (only with a paid key or a trial) and the version. A check that fails says what it means and links to where it is fixed; one without data yet says so. On Home, an administrator sees one line at the foot, Installation status: 2 recommendations pending, that leads here; with every check passing, the line isn't shown.

In Free, Free and Pro sets the two side by side in four rows: clusters, people, custom roles and visible audit. At the foot, one line repeats what we commit to and links to it.

Install a key¶

The key arrives by email after a purchase or a trial. Three ways to install it:

1. Edition (the edition beside the name at the top of the sidebar, or Edition in the account menu): paste the key into License key and click Install the key. It is stored encrypted and checked again every hour.
2. The variable KUBELATCH_LICENSE (see Configuration). While it is set, a key already pasted in Edition is ignored and the interface cannot install or remove a key.
3. In Kubernetes, the same variable in the kubelatch-secrets Secret, with secrets.env (only with secrets.create) or your own Secret (secrets.existingSecret).

kubelatch-server license show prints the edition in force and kubelatch-server license verify <file> checks a key file before installing it (Server CLI). Each key names its customer and seats; the renewal key arrives yearly and replaces the current one. A renewal pasted in Edition applies at once; one set through the variable or the chart's Secret is read at startup, so restart kubelatch (Upgrades and backups says what restarts the pods).

Lost the key? Ask for it again at kubelatch.com/pro/key with the e-mail address used at purchase: every active subscription's key is sent again. Seats, invoices and cancellation are managed from the customer portal linked in that e-mail.

Expiry, grace and seats¶

• From 30 days before the key expires, administrators see a notice in the bell and in Edition.
• After it expires, Pro continues for 30 days of grace.
• A trial key is Pro for 30 days, with no limit on people and no grace afterwards.
• After the grace (or at the end of a trial), the key is lapsed: the Free limits apply to new registrations, existing custom roles keep working and can only be deleted, and the audit is served 24 hours back. Nothing is deleted: the configured retention stays, and installing a key again shows everything kept.
• Seats: when more people are enabled than the key's seats, administrators are warned; after 30 days, no more people can be added until the seats are extended or people are disabled. Installing another key never restarts those 30 days; they start over only after people fit the seats again or a paid key with no seat limit is installed. Extend the seats from the subscription portal; the new key arrives by email in minutes.

What we commit to¶

• What is in Free stays in Free; its limits only ever loosen.
• No telemetry: the key is verified offline. The only call kubelatch makes to Picaporte Labs is the daily version check (a GET of a small JSON document that carries no identifier and no version; what administrators see), and KUBELATCH_UPDATE_CHECK=false turns it off. Air-gapped installations work.
• A limit only stops a new registration. Nothing that exists is cut: access through the proxy, grants, credentials, clusters, people and the custom roles already materialized keep working. If a key was ever installed, audit older than 24 hours is kept, not served, until a key is installed.
• On request, the code can be reviewed under NDA, and we commit to publishing the summary of an external penetration test on kubelatch.com/security.