License rotation
Apply a renewed license without downtime.
Before your license expires, your Scrydon account team sends a renewed license file: the same JSON shape as the original, { "jwt": "…", "publicKey": "…" }. This runbook applies it. For what the license contains and how its status changes over time, see Licensing.
No restart, no Helm change. The license is stored in the platform database, not in a Kubernetes Secret. Replacing it in the UI takes effect on the next request.
Before you start
- The renewed license file.
- A platform super-administrator account on the running platform.
- Optionally, check the file first in the in-browser License Checker. It decodes the JWT locally and shows the tier, entitlements, customer ID and expiry.
Apply the renewed license
- Sign in as a platform super-administrator and open Settings → Organization → License.
- Choose Update license.
- Drop the JSON file onto the upload area, or paste its contents.
- Check the claims shown: tier, CPU / RAM / VRAM and expiry. A bare
.jwtfile or an already-expired license is refused at this point. - Choose Save. The server verifies the JWT against the Scrydon signing keys built into the release before storing it. A license it refuses (
License is not signed by a trusted Scrydon key) leaves the current one in place.
The JWT is replaced, the platform drops its cached license so the next request reads the new one, and the replacement is recorded in the audit log as license.updated with the new and previous license IDs.
A renewal never needs a platform upgrade. Only a new Scrydon signing key does: Scrydon ships that key in a release first, and issues licenses under it only once that release is available to you.
Check that it is in effect
The License page reloads with the new claims. Confirm that the expiry matches the renewed file and that the status is valid. If saving is refused, the JWT is not signed by a key this release trusts: paste the whole file again, or ask for a fresh one. The error names the key ID when the license was signed under a newer Scrydon key, in which case upgrade the platform first.
From the API, with an admin session cookie:
curl -fsS -X POST https://<your-host>/api/auth/license/get-claims \
-H "Content-Type: application/json" \
-H "Cookie: <session-cookie>" \
-d '{"organizationId":"<org-id>"}' | jq '{status, expiresAt: .license.expiresAt}'If a renewal is late
- For 30 days after
expthe status isexpired_in_grace. The platform keeps working and organization admins see a banner. - After that the status is
expired, and the banner stays until a renewed license is applied. - A license problem never stops pods from starting or running, and the License page stays reachable so that you can apply the renewal the moment it arrives.
The full status timeline is in Licensing.
New installations
On a fresh install the license goes into the first step of the setup wizard, or is pre-seeded with auth.secrets.LICENSE. See Pre-seeding the license. Once the platform has copied it into its database, the database copy wins: renew through the UI, not by changing that secret.
Related
- Licensing — the license model, modes and status timeline.
- License capacity reporting — how deployed capacity is compared with your entitlements.