Skip to main content

Activate a deployment license

Two operations use the word license, and this guide covers both in the order you meet them: activating the deployment with the platform license CLIKA issued for it, and issuing runtime credentials to the ClikaRT runtimes your projects ship. Runtime licenses explains why they are separate artifacts.

Activate the deployment​

A fresh deployment refuses ordinary API requests and shows an activation screen instead of the dashboard. Activating it takes the CLIKA1-... platform license key CLIKA issued for that specific deployment.

Check the current state first. This route is public, so it answers before activation and from any client:

curl https://platform.clika.io/api/license/state

Then paste the key into the activation screen, or submit it directly:

curl -X POST https://platform.clika.io/api/license/activate \
  -H "Content-Type: application/json" \
  -d '{"license_key": "CLIKA1-..."}'

The platform verifies the whole artifact before it stores anything: the signature over the exact bundle bytes against the CLIKA root certificate, the certificate chain inside it, the key material, the entitlement grant, and the signed policy that binds this deployment, its expiry and its entitlement ceiling. A key issued for a different deployment, or for a different product, is refused, and nothing is written. Activation is rate limited, so a paste error costs you a moment rather than a lockout.

Restart when the response asks for it​

If the deployment issues device certificates, the response reports that a restart is required. Restart every replica before issuing or renewing device credentials. The certificate authority the platform serves from is the one activation replaced, and a running process is still holding the previous one.

After a restart the platform verifies the stored license again on startup and loads its key material from it. A deployment that cannot verify its own stored license refuses to start rather than falling back to unrelated key material, which is the behavior you want: an activated deployment issues credentials under exactly one authority.

Keep it renewed​

A connected deployment reports to the CLIKA License Portal on its own schedule and receives a signed verdict in return. An extension bought or granted in the Portal reaches the deployment through that channel, so a renewal needs no re-activation and no downtime: the deployment picks up the new expiry on its next report.

An expired license moves the deployment into a grace state rather than switching it off at the instant it expires. Treat the grace window as the time to fix the renewal, not as extra runway.

An air-gapped deployment reports to nothing, so renewing it means receiving a reissued bundle and activating it exactly as you activated the first one.

Issue a runtime credential​

A ClikaRT runtime proves it may run by presenting a credential your platform issued for the project it belongs to. Open Licenses in the project. The banner shows the platform's own state (active, the device count, the expiry), the Licenses tab lists the credentials issued for this project, and Issue License mints one.

Choose the kind by how the runtime authenticates.

KindChoose it whenNotes
OnlineThe runtime can reach the platformAn opaque clika_rk_... key presented on each call. Revocation takes effect on the next call. A project can hold as many as it has runtimes.
OfflineThe runtime cannot reach anythingA signed CLIKA1-... bundle the runtime verifies locally. One active bundle per project.

The list gives each credential a name, kind, status, issue and expiry dates, a key prefix, and when it was last seen, which is the fastest way to find a credential nothing is using any more.

Prefer Online unless the runtime genuinely cannot reach the platform. The intuition that an offline bundle is the safer artifact is backwards: a runtime holding one keeps verifying it successfully until it expires, because there is no channel to tell it the credential was revoked. If revocation has to actually stop a running runtime, it has to be Online.

Two behaviors follow from an offline bundle being signed material, and both are refusals rather than gaps:

  • A second active offline bundle is refused. Rotate the existing one instead, which replaces it atomically so the project is never without one.
  • An offline bundle's entitlements cannot be edited. They are inside the signature. Rotating re-signs, which is the only honest way to change them. The name is editable precisely because it is not signed.

Rotate replaces a credential, Revoke ends it, and the Profiles tab holds reusable entitlement templates so a team issuing many credentials does not re-enter the same grant each time.

Troubleshooting​

The API answers with a licensing refusal after activation. Restart the replicas if the activation response asked for it, then re-check GET /api/license/state.

Activation is refused with a signature or policy error. The key does not belong to this deployment. Platform licenses are issued per deployment, so a key from another environment cannot be made to work here.

A runtime is refused after a credential was revoked, and another is not. Revocation is immediate for Online credentials and only reaches an offline runtime when its bundle expires. See the Online and Offline table above.