Skip to content

How It Works

CG Lounge License Server provides two verification modes, an offline-capable JWT token system, and tiered enforcement for studios of any size.

Verification Modes

Simple Mode: /verify

The lightest path. One request, no local state. The client sends a license key and product ID; the server returns valid or invalid with a reason code.

Client                          Server
  |                               |
  |-- POST /verify --------------->|
  |   { licenseKey, productId }   |
  |<-- { valid: true } -----------|

Use when: your tool can always reach the internet, and you don't need offline support.

Full Mode: /activate + /validate

Two-phase flow with a local JWT token. Activates once online, then validates offline using the cached token.

Phase 1: Activation (online)

Client                          Server
  |                               |
  |-- POST /activate ------------->|
  |   { licenseKey, productId,    |
  |     machineFingerprint,       |
  |     hostname }                |
  |<-- { token: <JWT> } ----------|
  |   (store token locally)       |

Phase 2: Validation (online or offline)

Client                          Server
  |                               |
  |-- POST /validate ------------->|  (online: server verifies + refreshes)
  |   { licenseKey,               |
  |     machineFingerprint,       |
  |     token }                   |
  |   OR                          |
  |   (verify JWT locally)        |  (offline: client verifies signature)

Use when: you need offline support, render farms, or machine-bound enforcement.

How Tokens Work

Tokens are RS256-signed JWTs stored locally on the machine. They carry all the information needed for offline validation.

Field Description
licenseKey The license key string
machineFingerprint Hardware fingerprint of the activated machine
productId Product this token is scoped to
iat Issue time (Unix timestamp)
exp Expiry (Unix timestamp, 30 days from issue by default)

Key properties:

  • Machine-bound: the machineFingerprint claim is verified server-side on every /validate call. Offline, the token cache file is obfuscated with the fingerprint as key, so it cannot be read on a different machine.
  • 30-day validity: tokens expire 30 days after issue.
  • Auto-refresh: when a token is within 7 days of expiry and the machine is online, /validate returns a fresh token automatically.
  • Offline-verifiable: the client SDK verifies the RS256 signature locally without a server round-trip.

Offline Flow

Day 0         Day 23        Day 30
  |             |             |
  [ACTIVATE]    [AUTO-REFRESH] [TOKEN EXPIRES]
  online        online         must go online
                (within 7d    (token invalid,
                 of expiry)    re-activate)
  1. Activate online on Day 0. Token stored locally (30-day validity).
  2. Work offline for up to 30 days. The SDK verifies the JWT signature locally.
  3. Auto-refresh: if the machine comes online within the last 7 days of token validity, a new 30-day token is issued transparently.
  4. Expiry: if the token expires without a refresh (no internet for 30+ days), the local token is no longer valid. The user must go online to re-activate.

Token validity by threat level

Token validity (30 days, 1 day, or 3 days) is determined by the license's threat level at activation time, not by a variant field. See License Types for the full offline behavior table.

By Studio Size

Solo / Indie (1-2 machines)

  • License type: per-machine
  • Flow: buy once, activate on your workstation and/or laptop
  • Offline: activate at home, work on the road for up to 30 days without internet
  • Admin burden: none
[Buy License] -> [Activate on Workstation] -> [Activate on Laptop]
                        |                              |
                   [Work offline]               [Work offline]
                    (30 days)                    (30 days)

Small Studio (3-10 machines)

  • License type: per-machine (seat count = machine limit)
  • Flow: admin activates seats from the studio dashboard; artists just open the tool
  • Offline: each activated machine carries its own 30-day token
  • Admin burden: low (activate once per machine)
[Admin Dashboard]
       |
  [Activate Seat 1] [Activate Seat 2] ... [Activate Seat N]
       |                  |                       |
  [Workstation 1]   [Workstation 2]         [Workstation N]
  (token stored)    (token stored)          (token stored)

Render Farm (10-50 nodes)

  • License type: floating
  • Flow: nodes activate at job start, deactivate at job end; heartbeat every 5-15 min keeps the session alive
  • Concurrency: limited to maxMachines simultaneous sessions
  • Auto-release: sessions idle for 15 minutes are released by periodic cleanup
[Render Manager]
       |
  [Node 1: POST /activate] -> [Token + session started]
  [Node 2: POST /activate] -> [Token + session started]
       |                              |
  [POST /heartbeat]            [POST /heartbeat]
  (keeps session alive)        (keeps session alive)
       |
  [Job done: POST /deactivate]

Render farm cleanup

Nodes should call /deactivate when the job completes. If a node crashes, the session is cleaned up by a periodic job after 15 minutes of missed heartbeats. The heartbeat endpoint itself does not enforce expiry inline.

Enterprise (50+ seats)

  • License type: site license
  • Flow: one license key covers unlimited machines at the licensed site
  • Geo enforcement: exempt from geo-spread detection (legitimate multi-site deployments)
  • Admin burden: minimal (activate once, distribute key)
[Site License Key]
       |
  [Any machine at the site] -> [POST /activate] -> [Token issued]
  (no seat limit)

Summary

Mode Online Required Local State Offline Support Best For
/verify Always None No Web tools, plugins that are always online
/activate + /validate Activation only JWT token Yes (30 days) Desktop apps, render farms
Floating (/activate + /heartbeat) Activation only JWT token Yes (token-based) Render farms, shared workstations