How licensing works

Every KubeMQ server checks its own license, on Docker and Kubernetes. Without a valid license it does not start, and when a license ends it stops. Your data is never deleted. A license belongs to its installation: the Kubernetes cluster, or on Docker the data volume, so keep the volume.

Online and offline licenses

If both are set, the file wins (Core & Licensing).

When the server cannot reach KubeMQ

A server with an online license keeps running while it cannot reach KubeMQ, until the time kmq license shows under run_until. Restore the connection before then.

Meanwhile the server logs a warning (Troubleshooting). The kmq license record shows the renewal result under last_refresh and may add an entry to warnings. An online license's first start must reach KubeMQ.

When a license ends

An online license stops renewing at the contract or trial end, and the server stops at run_until. An evaluation ends 14 days after it started.

An offline license file stops the server on its end date. Renew it first: Install air-gapped.

At a stop the server refuses new connections, lets current work finish (5 minutes by default, Core & Licensing) and exits with code 3. Cluster servers stop at different times. Restarts fail the same way until the license is fixed (CrashLoopBackOff on Kubernetes).

Messages, accounts and settings stay on the volume. Add a trial key or license key with your install page's Add your license step and the server starts on the same data; a new evaluation cannot.

Buying before a trial key ends converts the same key; running servers pick up the new plan without a restart.

Revocation

KubeMQ revokes a license only by deliberate action. Missed payments, network silence and extra installations never revoke one. Offline license files cannot be revoked. Notice periods are in the licensing policy (Plans compared). A cluster larger than its license stops by itself (Troubleshooting).

Check license status

kmq license reads the JSON license record from the signed-in server. Troubleshooting shows how to sign in on each platform. kmq license --detail full prints the same record with all available fields for support. Neither command includes the license key or offline license contents.

The relevant fields have this shape:

{
  "server_version": "...",
  "adoption": {
    "configured_input_sha256": "...",
    "accepted_input_sha256": "...",
    "state": "accepted",
    "durable": true
  },
  "plan": "trial",
  "mode": "online",
  "source": "key",
  "license_expires_at": "...",
  "lease_expires_at": "...",
  "run_until": "...",
  "max_instances": 1,
  "instances": 1,
  "last_refresh": { "outcome": "..." },
  "over_cap": false,
  "warnings": [],
  "stop_cause": null
}

The server version identifies the running release. The adoption object confirms that the configured license input was accepted and saved on persistent storage; its two hashes must match. The plan, mode, source, expiry, and instance values describe the entitlement and current use. The latest refresh result and warnings show renewal problems. A healthy licensed server has no stop cause, is not over capacity, and has applicable expiry times in the future. Restore online connectivity before run_until when the refresh result or warnings report a renewal problem.

The command exits with code 0 when the server returns a record. Authentication, connection, timeout, and other command failures use the kmq CLI exit codes. Monitoring must inspect the JSON fields as well as the command exit code, because a returned record can contain warnings or a pending stop.

Related

• Plans compared
• Data sent to KubeMQ
• Troubleshooting