License and Release Management

brad-headless is the authoritative license issuer for deployed CMS installations. Use Licensing → Licenses to inspect the key, linked client and service, status, validity, bindings, reissue information, and check history.

Resolve a license problem

Confirm the linked service and invoice status before editing license state. Check the requested domain, observed source IP, directory, and check result. A change to the server's outbound NAT address can differ from the public website address.

For a planned move, prefer the supported reissue operation rather than inventing a new key or disabling verification. Customer reissues require an active license and remaining allowance; staff should investigate the binding and account history when help is needed.

A license status edit and a service billing adjustment are separate actions. Keep the financial record and entitlement consistent rather than using an Active status to conceal an unresolved renewal issue.

Publish a release

1. Obtain a complete production archive built for the intended CMS version.
2. Confirm its included modules and runtime requirements.
3. Open Licensing → Releases at /office/downloads.
4. Select the matching license product and enter the version and useful release notes.
5. Upload the ZIP and choose the applicable latest, prerelease, and license-access flags.
6. Review the recorded size and SHA-256 checksum.
7. Confirm an entitled customer can retrieve and verify the archive.
8. For managed hosting, test that the deployment pipeline can find and upload it.

The platform stores uploaded releases under storage/downloads, outside the public static directory. Preserve that directory across platform deployments and include it in backups.

The current release screen does not edit an uploaded record in place. To correct its notes or flags, re-upload the archive with the same product and version and the desired values; that operation replaces the record. Retain the original artifact and review the resulting metadata before directing customers to it.

Latest and prerelease selection

Setting a release as latest clears the previous latest flag for the same product. Review the product association before changing the flag: the CMS version check and managed deployment resolve releases by the license product.

The current managed deployment pipeline prefers the product's latest-marked release and otherwise uses its most recently created release. Do not rely on the prerelease label alone to prevent deployment selection. Review the actual latest flag and available records before publishing a test build to a production product.

Keep prior compatible archives for recovery and make the release notes explain required runtime, schema, or extension changes.

Keep the licensing contract stable

Production CMS clients contact https://www.brad.software and verify signed responses with their baked-in Ed25519 public key. The legacy field named md5hash carries the base64 Ed25519 signature, not an MD5 digest or shared-secret HMAC.

Do not rename or change response fields or signature canonicalization without the matching CMS compatibility work. Signing-key rotation requires shipping the corresponding client public key. Private keys never belong in customer configuration.

The separate download signing secret protects expiring download links. Those URLs can be reissued when they expire; they are not permanent public release URLs.

Verify after publishing

Check the portal download list and a CMS update check, then compare the displayed version, release notes, and checksum. If a download is missing, inspect product linkage, release visibility/access flags, license state, and on-disk file availability.

An update check supplies information and a download link. CMS updates remain a deliberate manual operation; publishing a release must not be described as automatically replacing customer application files.