AI Server docs / Licensing & activation

Licensing & activation

The one-sentence model: loopback is free; serving a network is paid — and the server enforces that itself, on every tier, in every deployment shape.

Tiers

• Free — a complete local AI server for your own machine. Every AI Suite app on that machine uses it without limits; generic OpenAI-compatible clients are rate-limited (see API & clients).
• Pro Personal — serve your own devices: network binds, run as an OS service, a handful of API keys, unlimited generic clients, a small gateway pool.
• Pro Commercial — serve other people: commercial use, unlimited API keys, full governance (rate limits, quotas, budgets, audit signing), and a production gateway farm with canary and DNS discovery.
• Enterprise — unlimited estates, organisation enrollment via AI Admin Console, air-gapped options, priority support. Talk to us.

Buy on the Microsoft Store (desktop) or use a license key anywhere — one key covers a whole fleet. Pricing: Licensing & Pricing.

Two gates, not one

A non-loopback bind refuses to start unless both are present: a paid entitlement and at least one API key. They are different things — the license says the server may serve a network; keys say who may call it. A network server with no keys would be an open inference endpoint, so it deliberately will not start.

Activating a desktop server

Subscribe in-app (Microsoft Store billing) or enter a license key in Settings → Subscription. The app licenses its managed daemon automatically; nothing else to do.

Activating a container / headless node

Supply the key one of three ways (argv wins over env):

• AISUITE_LICENSE_KEY_FILE=/path — production. A Docker secret or Kubernetes Secret volume. A trailing newline is tolerated.
• AISUITE_LICENSE_KEY=<key> — dev/Compose convenience. Beware: env vars are visible in docker inspect and kubectl describe.
• --license-key <key> — ad-hoc debugging.

kubectl -n aisuite create secret generic aisuite-license --from-literal=key=<your-key>

# pod spec
env:
  - { name: AISUITE_LICENSE_KEY_FILE, value: /etc/aisuite/license/key }
volumeMounts:
  - { name: license, mountPath: /etc/aisuite/license, readOnly: true }
volumes:
  - name: license
    secret: { secretName: aisuite-license, items: [{ key: key, path: key }] }

Optional: AISUITE_NODE_NAME gives the node a human-readable label in your fleet/activation view (defaults to the pod/host name). The logs show exactly one activation line at boot — license activated, license active from cached lease, or a stated failure. The key itself is never logged.

What the license actually is (and why you can trust it offline)

• Activation returns a cryptographically signed lease; the server verifies the signature against a public key compiled into the binary before trusting anything in it. A modified or self-hosted license endpoint cannot mint entitlements — it can only relay ones we signed.
• The lease is cached under the data directory. A restarted or rescheduled node with its volume mounted re-validates offline — no network call, no boot dependency on us.
• Failure handling is deliberately asymmetric: a bad key exits non-zero (you meant to serve; a silent downgrade would look like a broken image), but our outage does not stop a licensed fleet — a node with a valid cached entitlement starts and logs the failed re-check. One bad hour at our license service must never take your farm down.
• Seats are counted as live leases, so a pod rescheduled fifty times a day occupies one seat, and nodes release their seat on shutdown. Activations are visible to us per key; limits are handled at renewal, not by cutting your service off.

Air-gapped & offline operation

• Day-to-day operation is offline by design — inference, keys, governance and the dashboard never call out; only activation and periodic lease renewal talk to the license service.
• A node keeps serving through the full lease + grace window with no connectivity at all.
• For fully disconnected (air-gapped) estates with extended lease terms, contact us — that's an Enterprise arrangement.

Next: Gateway & operations · API & clients