Release notes

2.6.2

• Open a bound machine and see its fingerprint in full — every component at full length, which components the machine did not report, and when and how it bound.
• The Quick Start Guide’s three check policies are now written for the product’s licence type. The recommended one comes first, and the one that does not fit is marked as such: OFFLINE for an offline product, ADVISORY for online and hybrid.

2.6.1

• Fixed: on a licence bound to several machines, the link to its Machines card did nothing.

2.6.0

Archiving, seats, and an organisation’s own timezone. Two breaking changes — read both before upgrading.

• A licence can bind more than one machine. A product carries a default number of machines per licence, and each licence keeps the figure it was issued with. Online and hybrid licences hand out one seat per machine that checks in and refuse the machine that finds none free; an operator can free a single seat rather than all of them. Offline licences name every permitted machine inside the signature.
• Archiving a licence replaces deleting it. The record is filed rather than destroyed, so a licence id keeps its own history. Archived licences leave the list and are reachable under the Archived filter and by direct link.
• An organisation sets its own timezone, and every chart buckets by it. New Settings page, admin only. Existing organisations start on UTC, so no figure moves until somebody chooses.
• A licence page shows every machine it is bound to — components decoded, when each bound, released ones kept in place.
• Verify a licence works again — it had been unusable since a spelling change — and now says whether this issuer has a record of the licence, linking to it.
• A tester page at /integration-example: give it an address, an organisation and an API token, and it issues one licence of each type, verifies each in the browser, and calls the check endpoint for the two that check in.
• The Quick Start Guide’s agent brief follows the product’s licence type instead of a checkbox that could contradict the code samples above it.
• Fixed: the API could not start at all on 2.5.0 — see below.
• Fixed: the Python drop-in file reported malformed license for any machine-bound licence. The packaged SDK was never affected; if you ship dropin/dycrypt_license.py, take the 2.6.0 copy or later.

Breaking — DELETE /api/licenses/{lid} is gone. It answers 405. Use POST /api/licenses/{lid}/archive, which keeps the record, and POST /api/licenses/{lid}/restore to put it back. Archiving is refused unless the licence is REVOKED or EXPIRED.

Breaking — a multi-machine offline licence is schema v4. Its fp claim is a list of machines rather than one, and an SDK older than 2.6.0 refuses it. That is deliberate: reading a list it did not understand would honour the licence on every machine. Update your SDK before you issue one. Licences bound to a single machine are unchanged, still v3, and everything already in the field keeps verifying.

Upgrading: three per-organisation migrations run automatically at boot, and two of them drop columns — there is no way back to 2.5.0 or earlier once 2.6.0 has started, so take a database backup first.

2.5.0

The platform is now called Dycrypt Licence Manager, and the dali namespace is gone.

• Java packages renamed to dycrypt.*; the API jar is now dycrypt-licence-manager.
• PKCS#11 provider names lost their old prefix.
• The key-derivation salt moved. The signing service reads both the old and the new one and picks per row, so keys sealed before the rename keep opening with no migration and no operator action.

Do not deploy 2.5.0. Its API exits during startup — a 2.5.0 deployment has no console and cannot issue anything, while the other services look healthy. Fixed in 2.6.0; go there directly.

2.4.2

• The organisation API is described by an OpenAPI specification, published as the API reference. Two tests in the product fail its build if an endpoint exists and the specification does not describe it, so the reference cannot drift from the software.
• The licence check API is no longer documented as public: it is authenticated per product.

2.4.1

• A platform manager can read the roadmap.
• Fixed: a proxy’s own error page is no longer shown as though it were the platform’s error.

2.4.0

The roadmap and the changelog moved into the console.

• The roadmap lives at /platform/roadmap, and the changelog is its own document rather than the roadmap’s shipped section.
• Control-plane API tokens, and an MCP server so a coding agent can read and write the roadmap.
• Four roles in the control plane — superadmin, platform manager, product owner, coder — each with a ceiling on what it may delegate.
• A superadmin can upload ROADMAP.md and CHANGELOG.md back into the platform, which is the way back after a rebuild or a restore.

2.3.0

• A licence’s check-in health, and the sharing signal already in the table: how many times a licence has moved machine.
• Charts on the overview — what runs out, and new against renewed — drawn without a chart library.
• Named windows on the licences list: expiring, expired, never checked in, stopped checking in, and the rest. Every number on the overview links into one.
• One shape and one colour per licence type, defined once.

2.2.0

A UX audit, in four phases: correctness first, then one design system and one vocabulary, then scale and recovery in forms and lists, then the parts people remember. Enforcement came with it — a copy linter, a voice guide and a token budget run in the build, so the rules hold without review.

2.1.1

• A superseded term now says why it stopped being current, rather than only that it did.

2.1.0

• An application can fetch its renewed licence itself. When check() reports valid: false with an online status of ACTIVE, the licence has been renewed; fetchLatest() asks for the current signed string, presenting the licence it already holds as the credential. Opt-in per product.
• A licence’s own history, on its page — every issue, renewal, revocation and machine release, append-only.
• A renewal keeps the licence it replaced. The superseded term is filed rather than overwritten, so a customer’s record is one licence with a history rather than a pile of them.
• Typed confirmation for the most consequential administrative actions.

2.0.5

• Free now covers up to 250 active licences in production.
• Added Starter at $29 per month for 1,000 active licences.
• Business remains $99 per month for 4,000 active licences.
• Business Max is now $249 per month for 12,000 active licences.
• Added the Sovereign on-premises path from €25,000 per year.
• Published the active-licence definition and plan-limit behavior.

2.0.4

The check endpoint is now per product and authenticated, and every answer it returns is signed.

• Each product carries a check id and a check token, minted with the product and shown once. The endpoint is POST /o/{slug}/api/public/license/{checkId}/check with Authorization: Bearer dycc_….
• Every response includes a receipt: a signature by the product’s own key over the licence id, status, your nonce, the timestamps, and a digest of the fingerprint you sent. The SDKs verify it before recording a successful check, and treat an unverifiable answer as no answer.
• This closes a bypass. Previously, whoever controlled a machine could redirect the issuer hostname to a stub answering ACTIVE, resetting the offline window indefinitely and preventing one-machine binding. A stub cannot produce a receipt, so blocking the check is now the only option left, and blocked checks end in STALE.
• All three SDKs take the new credentials and verify receipts by default. Offline integrations are unaffected.

Upgrading an Online or Hybrid integration: mint the token on the product page, add the check id and token to your verifier, and ship the update. Existing licences keep working unchanged — nothing about the licence format changed.

2.0.3

• Documented Offline, Online, and Hybrid as released licence types.
• Added one-machine binding, fingerprint privacy, online and offline activation, signed check windows, and STALE behavior.
• Added the operator-controlled Release machine flow for replacement hardware.
• Expanded Java integration and added dedicated Node.js and Python SDK guides.
• Added SaaS plan limits and the Enterprise on-premises option.
• Refocused documentation on organisation users and application integration.

Application release notes and upgrade instructions should be added here alongside future tagged releases.