On-premises install

Run SuperDRM inside your own network and keep issuing licences whatever happens to superdrm.com. An on-prem install is the same four services and database described in Deployment overview, with SUPERDRM_MODE=onprem, your own key vault and your own (or SuperDRM-provisioned) partner credentials.

#What you need

• A Linux host with Docker (2 vCPU, 4 GB, 20 GB) or a Kubernetes cluster; arm64 or amd64.
• A domain (or internal hostnames) for api., docs., live. and, optionally, console..
• Outbound HTTPS to license.widevine.com (or license.uat.widevine.com for staging) for Widevine. Clear Key and FairPlay need no outbound connection at all.
• A key vault: the generated software KEK for evaluation; a PKCS#11 HSM or your KMS for production (Hardware key vault).
• DRM partner credentials: your own Widevine agreement (provider name + signing key) and Apple FPS package, or credentials SuperDRM provisions into your install as sealed partner_creds. The Licensing checklist covers the paperwork.

#Install in ten minutes

git clone https://github.com/shanesupers/superdrm && cd superdrm/deploy/compose
DOMAIN=drm.internal.example SUPERDRM_MODE=onprem ./install.sh
# → prints the API/docs/live URLs, writes .env, secrets/kek.hex, secrets/docs.password, secrets/demo-tenant.json

Then, with the values SuperDRM sent you, add to .env and run docker compose up -d api:

SUPERDRM_LICENSE_KEY=sdrmi1.…        # your signed install licence
SUPERDRM_INSTALL_PUBKEY=…            # SuperDRM's install-signing public key
SUPERDRM_REPORT_URL=https://api.superdrm.com
SUPERDRM_REPORT_KEY=…                # only if usage reporting is part of your agreement

Check it:

curl -s https://api.drm.internal.example/health | jq .install

Point your packager at https://api.<domain>/v1/cpix and your players (or your licence proxy) at https://api.<domain>/v1/<tenant>/license/<system> exactly as in the DRM quick start. Nothing in the licence path ever calls superdrm.com.

#Sign in to the consoles

An on-prem install has three places to sign in, and none of them shares a credential with superdrm.com:

The operator token itself (SUPERDRM_ADMIN_TOKEN) is written into .env by the installer, is read by the CLI, and is never sent to a browser.

#The install licence key

SUPERDRM_LICENSE_KEY is a compact signed document (Ed25519, verified against SUPERDRM_INSTALL_PUBKEY) carrying your install id, organisation, tenant cap, feature list and expiry. GET /health shows what the api sees:

"install": { "mode": "licensed", "id": "…", "org": "Acme", "tenant_cap": 10, "tenants": 3, "features": ["widevine","fairplay","clearkey","reporting"], "expires": "2027-09-11T…" }

Without a key, or with an expired one, the install runs in community mode: everything works, licences keep being issued, but only one tenant can exist. A licence key never gates licence issuance; it gates tenants, features and support. Renewals are a new key; nothing restarts.

#Usage reporting

If your agreement is usage-based, the api sends an hourly signed report to SUPERDRM_REPORT_URL containing: install id, version, tenant count, key count and the last seven days of daily totals (licences per day per DRM system, ok / refused). It contains no keys, content ids, user identifiers or IP addresses. A failed report is logged and retried next hour; it never affects licences. Air-gapped installs simply leave SUPERDRM_REPORT_URL empty.

#Air-gapped and restricted networks

#Migrating between hosts

superdrm export / superdrm import move everything; the KEK travels with the bundle (or is re-sealed to a new vault). See Operations & migration.

#Support

GET /health and the live console are the first look. superdrm audit, superdrm licences and the meter give the trail. Send us the install id from /health with any ticket — see Support.

Updated September 2026