Eximia Download

Eximia docs

Licensing

How license keys work in SLM Eximia. Read this before contacting sales or rolling out the binary in CI.

TL;DR

  • The public binary is fully functional for building hybrid apps with the device-info plugin. No license required.
  • Internal SLM plugins (biometric, camera, face-verify, wallet-provisioning, etc. — 26 in total) require a license.
  • A license is one opaque token you set as EXIMIA_LICENSE_KEY=<token> before running eximia build.
  • Tokens are verified online against https://slmeximia.site/license/verify on every build.
  • No JWT, no offline signatures, no embedded certs. The slmeximia.site server is the single source of truth; revocation is instant.

What's gated

Run eximia plugins list to see the full plugin catalogue. Each entry is one of:

  • public: usable without a license. Today: device-info.
  • internal (licensed): requires EXIMIA_LICENSE_KEY and the plugin must appear in your license's entitlements list.

eximia build refuses to proceed if your spec names any internal plugin you're not entitled to. The error message names the offending plugins and explains how to authorise.

Getting a license

Licenses are issued by SLM Sistemas. Email dev@slm.cloud with:

  • Customer name (your company / project name).
  • Plan you want: trial / pro / enterprise.
  • Plugin entitlements you need (a list of plugin short names, or all for the full bundle).

Reply latency: SLA depends on your support tier. SLM-internal apps get same-day turnaround.

Using the license

Set the token in the environment of any shell that runs eximia build:

export EXIMIA_LICENSE_KEY=019e3cf4-b48f-76c3-840a-d5e4d7577137
eximia build android

The token is opaque UUID-v7 (36 hyphenated chars). The binary validates its shape locally before sending — junk values are rejected without a network call.

Verifying your license

eximia license status hits the server and prints the resolved decision (customer, plan, entitlements). It never prints the token, so the output is safe to paste in support tickets or CI logs:

$ eximia license status
endpoint: https://slmeximia.site/license/verify
✓ SLM license active — customer=slm-internal plan=enterprise (1 plugins)

Entitlements (1):
  - all

If you see ○ Public mode (...) instead, the token is missing, malformed, expired, revoked, or the license server is unreachable — the parenthesised reason narrows it down.

In CI

Store EXIMIA_LICENSE_KEY as a masked secret in your CI provider. Most CIs (GitLab, GitHub, Forge) expose secrets to jobs as env vars; that's exactly what eximia reads.

# .gitlab-ci.yml
build:android:
  script:
    - eximia build android
  variables:
    EXIMIA_LICENSE_KEY: $EXIMIA_LICENSE_KEY  # set in project settings

Do not commit tokens to git, hardcode them in build scripts, or pass them on the command line (shell history). The env var pattern is the only one we support.

Security properties

The verification client is conservative by design. What it guarantees:

  • TLS only. Verifies with rustls + Mozilla webpki-roots — no trust in system CA bundles. TLS 1.2+. Cert validation always on, no escape hatch.
  • Hardcoded endpoint. The binary will only ever POST to https://slmeximia.site/license/verify. EXIMIA_LICENSE_URL is honoured only when EXIMIA_LICENSE_DEV=1 is also set, and even then only if the URL is https://.
  • 5-second timeout, no retries. A slow/hanging license server can't stall your build past ~10 seconds total.
  • 4 KiB response cap. Oversized server responses are rejected without parsing.
  • Fail closed. Any failure (network, TLS, parse, server) drops the build into public mode. The build will refuse internal plugins with a clear error rather than silently letting them through.
  • Token never logged. The binary's own logging never includes the token. Server-side logs record customer + plan + binary version — never the token.
  • In-process cache only. A given eximia build invocation verifies once; nothing persists across runs.

Revocation

If a token is compromised, contact dev@slm.cloud immediately. Revocation takes effect on the next eximia build invocation (no local cache to wait out). The server returns {"valid":false,"reason":"revoked"} and the build refuses.

You'll need a new token for the same entitlements.

Air-gapped environments

Online verification is a hard requirement — there is no offline mode by design. Air-gapped CI machines must either:

  1. Have outbound HTTPS to slmeximia.site whitelisted, or
  2. Use only the public plugin set (device-info) which needs no license.

If you have a hard air-gap requirement and need internal plugins, contact dev@slm.cloud. We don't currently offer an offline option but we want to hear the use case.

FAQ

Q: Can I share a token across multiple machines? Yes. Tokens are per-customer, not per-machine. We rate-limit at the server side; abusive patterns trigger revocation.

Q: Will my build break if slmeximia.site is down? For public-plugin-only builds, no — verification is skipped. For internal-plugin builds, yes: the binary falls back to public mode and refuses internal plugins. We monitor slmeximia.site uptime explicitly because of this.

Q: Can I see all licenses I've been issued? We don't ship a customer-facing portal yet. Email dev@slm.cloud for a list. The eximia license status command shows what the currently-set token authorises.

Q: What plugins are public? Run eximia plugins list for the live answer. Today: just device-info. The product strategy is intentional — we ship a working plugin as a worked example and a public-quality guide (Authoring an Eximia plugin) so anyone can write their own.

Q: Why not JWT / offline tokens? SLM's stance: when a key is compromised, instant revocation is non-negotiable. Offline-verified tokens can only be revoked by TTL expiry or by trusting clients to fetch a CRL — neither of which we want to bet on. Online verification has measurable latency cost (≤200 ms typical) which is a fair trade.