Skip to main content
Version: 1.7.0

Get and apply a license

DVARA runs with no license in the Development posture — pull the public images and go. Everything works there except the MCP and A2A planes, and a signed license key is what activates those two, alongside production rights and support. Nothing refuses to start without a license. This page covers the Enterprise license lifecycle: requesting a key, applying it, verifying it, renewing it, and exactly what the data plane does as a license approaches and passes expiry. (For which image to pull per edition, see Editions & container images.)

Request a license​

Both paths are fulfilled by an emailed DVARA--prefixed envelope, usually the same business day:

  • Trial — a 30-day license with every feature unlocked, for evaluation. Request one by booking a slot (mention you need a trial license for a self-hosted install), or — if a corporate proxy or air-gapped network blocks the form — email support@dvarahq.com with your name, work email, company, and use case.
  • Production — an annual license issued with your plan. Talk to us to start a production license or renew an existing one.

The license is install-wide: a single envelope activates all three planes (LLM Gateway, Flightdeck, MCP Gateway). There are no per-workspace or per-node keys to mint, and the envelope is not tied to a specific host — so staging, CI, and DR copies of the same install use the same key.

Apply the license​

Set the envelope on every DVARA app via the DVARA_LICENSE_KEY environment variable (or the dvara.license.key config property):

# .env — the same envelope on every plane
DVARA_LICENSE_KEY=DVARA-<your-license-envelope>

Each app validates the envelope at startup: it verifies the Ed25519 signature against the public key shipped in the image and checks the expiry date. A missing key simply boots the Development posture, while an invalid or tampered key blocks startup — the distinction is between no claim and a claim that failed to verify. There are no separate MCP or A2A processes with their own rule: all three planes run in the gateway. Either way there is no operator flag to bypass the check, by design (a governance layer that silently runs unlicensed would defeat the audit story).

  • Docker Compose — put DVARA_LICENSE_KEY in .env (see the Quickstart).
  • Kubernetes — store the envelope in a Secret and reference it on the Gateway, Flightdeck, and MCP Gateway pods (see Kubernetes).

Restart the apps after changing the key.

Verify the license​

Open License from the DVARA Flightdeck user menu (or go to /license). It shows the licensee, type (TRIAL / PRODUCTION), expiry date with days remaining, and a runtime status badge — see Operations → License status for the full page.

Programmatically, the Gateway's GET /actuator/gateway-status endpoint returns the license block; it requires Authorization: Bearer $DVARA_ACTUATOR_API_KEY.

What happens as a license expires​

The runtime tracks four states. The transition that matters operationally is into DEGRADED:

StatusWhenData-plane behavior
VALIDMore than 30 days remainingNormal.
EXPIRING_SOON30 days or fewer remainingStill serving. An X-License-Warning header is added to /v1/* responses; the License page shows a renewal notice.
GRACE_PERIODExpired, within the 14-day grace windowStill serving. X-License-Warning continues. Renew now.
DEGRADEDExpired beyond the 14-day grace/v1/* keeps serving. Only /mcp/* and /a2a/* are refused, with HTTP 402 (type: license_error, code: LICENSE_EXPIRED). The Flightdeck Console and existing audit records stay accessible so you can diagnose and renew.
An expired licence is never worse than no licence

Expiry falls back to the Development posture rather than to a refusal. An unlicensed install serves the full LLM plane, so an expired one must not serve less — otherwise the fastest remedy for an outage would be to delete your licence, which is plainly the wrong incentive. Expiry therefore stops only what the licence actually buys: the MCP and A2A planes.

This changed in 1.7.0. Earlier releases did 402 the whole of /v1/* when a licence lapsed beyond grace.

The X-License-Warning header appears throughout EXPIRING_SOON and GRACE_PERIOD — wire it into your SRE alerting so a renewal lapse never reaches DEGRADED. Status transitions also emit LICENSE_EXPIRY_WARNING, LICENSE_EXPIRED, and LICENSE_DEGRADED audit events.

Renew before the grace window ends

Once a license passes the 14-day grace into DEGRADED, the MCP and A2A planes stop serving — /mcp/* and /a2a/* answer HTTP 402 (see Error handling). /v1/* is not interrupted, because the LLM plane runs unlicensed anyway, and the Console stays up for renewal.

So the traffic at risk is agent traffic: tool calls and agent-to-agent hops stop, while completions carry on. If your agents are the production workload, that is the whole workload. Renew during the EXPIRING_SOON window rather than relying on the grace period.

Renew a license​

  1. Request the renewed envelope (production: through your account contact; trial → production: talk to us).
  2. Replace DVARA_LICENSE_KEY with the new value on every plane.
  3. Restart — a rolling restart keeps the fleet serving. The License page reflects the new expiry.

Renewing before expiry avoids the warning → grace → degraded cascade entirely. The same swap upgrades a trial to a production license.

Last updated on