Licensing (Cloud & Offline)

:::info Quick Reference A license is a cryptographically signed token the vendor issues for one install. It lists which modules that install may use and when it expires. It can be renewed two ways — online (the install auto-renews over the internet) or offline (a signed request/response you hand-carry). For the day-to-day admin screen, see Administration → Licensing. :::

What a license is

OpSee is licensed per install (one OpSee deployment). The license is a signed token — a small, tamper-proof credential the vendor generates and gives you. Your install checks the token on every start and continuously while running.

The token is protected by public-key cryptography, which matters for self-hosted deployments:

• The vendor holds a secret private key and is the only party that can create a valid token. That key never leaves the vendor.
• Your install carries only the matching public key, which can verify a token but can never create or alter one.

So even though you have full access to your own server and database, a license can't be forged or edited locally — any change breaks the signature and the token is rejected. This is what lets OpSee run entirely on-premise, even fully offline, without a license being trivially bypassable.

What the token grants

Each token carries the entitlements the install paid for, in three groups:

Group	Scope	Examples
Foundation	Whole install, included with any paid license	Historian & data, AI chatbot, API, Personnel, Material, Kaizen & Gantt
Feature slots	Per equipment — Pro (all feature modules) or Starter (pick one)	KPI & OEE, Production Execution, Workflow & Forms, Batch, Quality, Alerts, ML
Add-ons	Whole install, with a quantity limit	HMI screens, Integrations Hub connectors

You assign equipment to the Pro/Starter slots yourself on the License Overview screen — the token sets the limits, you decide the placement. See Administration → Licensing for the screen and slot management.

Install identity (and moving installs)

Every install establishes its identity the first time it starts, in two parts:

• A unique install ID, stored in its database.
• A private identity keypair, generated on the server itself and stored only in a local data folder (/var/lib/opsee) — never in the database. The Licensing screen shows its public fingerprint as the Identity entry.

A token is bound to exactly one install. Depending on how it was issued, it binds to the install ID, or — for newer tokens — to the keypair: the install must prove it holds the private key for the token to verify. Keypair binding is the stronger model, because a copied database alone can never satisfy it, and renewal requests are additionally signed with the same key so your vendor can verify they genuinely come from your install.

This matters when you move an install to a new machine, container, or cloud:

• Migrating the install means copying its database volume and the /var/lib/opsee data volume (which carries the identity key). With both, the license keeps working — no action needed. (A hardware fingerprint is recorded for reference, but it never blocks a move.)
• Standing up a fresh install (or restoring a database without the identity key) creates a new identity, so a keypair-bound token won't verify — you request a new token bound to the new identity (see renewal below). The grace window means this never has to interrupt production.

:::note The identity key is deliberately not in your backups Database backups intentionally exclude the identity key — a restored backup should not silently become a second licensed install. A full disaster recovery therefore ends with one re-activation step: export a renewal request from the restored install and your vendor issues a token for its new identity. :::

License lifecycle

A license moves through these states; the install reports the current one on the Licensing screen:

• Valid — everything works.
• Expiring soon — within the warning window before expiry; start renewing.
• Grace — the token has expired but a grace window (typically 30 days) keeps the install fully working, so a late renewal never interrupts production.
• Expired — past the grace window; licensed features stop until a valid token is installed (the Licensing screen itself stays reachable so an admin can always renew).

Renewal can happen at any point and simply returns the install to Valid with a later expiry.

Renewal — two channels

A renewal is just a newer token. There are two ways to get one. Which applies depends on whether the install can reach the internet; it's controlled by an install setting (air-gapped on/off).

Offline / air-gapped (challenge–response)

For installs with no outbound internet, renewal is a manual, signed two-step exchange — nothing but the license request leaves the building.

1. On the Licensing screen, click Export renewal request. This produces a signed text blob containing the install identity and current usage counts — no production data.
2. Send it to your vendor (email, USB, however your site allows).
3. The vendor returns a renewed token.
4. Paste it into the token field on the Licensing screen. The install verifies the signature and binding, then activates it.

Online / cloud (automatic renewal)

For connected installs, renewal happens on its own. The install makes outbound HTTPS calls to the vendor's licensing service — there is no inbound port to open and no VPN required.

• The install checks in on a schedule (about once a day). Around 45 days before expiry the service starts preparing the renewal.
• When the renewed token is ready, the install picks it up on its next check-in and installs it automatically — the admin does nothing.
• The grace window covers any gap, so even a slow renewal never interrupts production.
• The vendor's cloud service only relays tokens; the signing key is never on it, so the same "can't be forged" guarantee holds end-to-end.

:::note First activation A brand-new install gets its first license the same two ways: an activation code entered once (online), or a genesis request exported and signed by the vendor (offline). After that, the renewal channels above keep it current. :::

Choosing a channel

	Offline / air-gapped	Online / cloud
Internet required	No	Outbound HTTPS only
Inbound ports / VPN	None	None
Admin effort per renewal	Export → send → paste	None (automatic)
Best for	Isolated / secure networks	Connected sites, fleets

Both channels produce the same kind of signed token and enforce the same install binding — the only difference is how the request and the token travel.

Privacy & security notes

• The renewal request contains the install identity (ID and public key), a hardware fingerprint, a request counter, and usage counts — never machine/process data, recipes, or production records. It is signed with the install's own identity key, so the vendor can verify it came from your install and detect a cloned deployment (two copies would diverge their request counters).
• The signing key never leaves the vendor; online or offline, your install and the cloud relay only ever hold the public (verify-only) key.
• A leaked or misissued token can't be silently reused elsewhere — the install binding ties it to one deployment, and the vendor rotates the key as the ultimate safeguard.

See also

• Administration → Licensing — the License Overview screen: viewing your license, assigning slots, installing/renewing tokens, and resolving frozen slots.