License & Operations

Runs unlicensed

Available with no license, in the Development posture. A license adds the MCP and A2A planes, production rights and support — not this feature.

This page covers operational surfaces in the DVARA Flightdeck: personal access tokens, guardrail plugin management, license monitoring, and health probes.

The Provider Status page has been retired

/providers is now a 302 redirect to /credentials. Provider activation is visible directly in the credentials list — every entry shows which provider it serves and which scope (platform-default or workspace-scoped) it covers, and the resolution source (database / vault / environment) is documented in Credentials & BYOK. The previous per-provider resolution-source view has been removed.

---

Personal access tokens

Open the user menu (top-right corner) and select Access Tokens to manage personal access tokens (PATs) for API automation.

PATs use the dvara_pat_ prefix followed by a random identifier. The raw token is displayed exactly once at creation — copy it immediately, as it cannot be retrieved again. Only a SHA-256 hash is stored.

Creating a token

Click Create Token, provide a name and optional expiry date. Scopes are set automatically from your current roles. The new token appears in a one-time alert with a Copy button.

Token table

Column	Description
Name	Human-readable label
Prefix	First 20 characters of the token (dvara_pat_ab...)
Created	Creation timestamp
Last Used	Last authentication timestamp, or "Never"
Expires	Expiry date, or "Never"
Status	Active, Expired, or Revoked

Revoking a token

Click Revoke next to any active token. Revocation is permanent — revoked tokens cannot be reactivated. You can only see and revoke your own tokens.

Usage

A PAT authenticates a script to the DVARA Flightdeck as the user who minted it, carrying that user's roles. It is not valid on the data plane — that uses a workspace gw_ API key.

There is no admin REST API to point a token at

There is no administrative REST API to point a PAT at: /v1/admin/** was removed in 1.7.0. See Administering DVARA for what replaced it.

PATs work for both the platform Console and the workspace portal. Every create and revoke emits a PAT_CREATED / PAT_REVOKED audit event.

Figure 1. Creating a PAT. The plaintext token is shown ONCE at create-time inside a one-time-reveal panel — copy it immediately. The list below shows the prefix + creation date for already-issued tokens; the full secret is never recoverable through the UI.

---

Guardrail plugin management

Navigate to /guardrail-plugins in your browser. This page manages external guardrail plugin definitions — the webhook endpoints that run alongside built-in detectors in the composite guardrail chain.

RBAC: Requires owner or policy-admin role. Secret rotation requires owner.

Plugin list

The table shows all platform-global and workspace-scoped plugins with:

Column	Description
Name	Plugin identifier
Scope	Platform badge (global) or workspace ID
URL	Webhook endpoint
Timeout	HTTP timeout in milliseconds
Fail Mode	OPEN (return empty on failure) or CLOSED (throw exception on failure)
Status	Enabled or Disabled
Updated	Last modification timestamp

The table auto-refreshes every 10 seconds. Use the Workspace dropdown to filter by scope.

Figure 2. Guardrail plugins list — every plugin definition (platform-global and workspace-scoped) appears here with its scope, target URL, timeout, fail mode (OPEN / CLOSED), and enabled status. Secret rotation is owner-only; the secret itself is never shown — only the encrypted blob is stored, AES-256-GCM-decrypted in-process on every call.

Creating a plugin

Click New Plugin and provide:

• Name — unique identifier
• URL — webhook endpoint
• HMAC Secret — signing secret for request authentication (encrypted with AES-256-GCM before storage)
• Timeout (ms) — HTTP call timeout (default 5000)
• Fail Mode — OPEN or CLOSED
• Workspace — leave blank for platform-global, or select a workspace for workspace-scoped

Requires the encryption master password

DVARA_ENCRYPTION_MASTER_PASSWORD must be set for secret encryption. The form shows an error if it is not configured.

Rotating a secret

Click Rotate to replace the HMAC signing secret. The old secret is permanently replaced and the change takes effect across all pods on their next config-version poll (a few seconds).

Audit events

Every mutation emits a GUARDRAIL_PLUGIN_CREATED, GUARDRAIL_PLUGIN_UPDATED, GUARDRAIL_PLUGIN_ROTATED, or GUARDRAIL_PLUGIN_DELETED audit event.

For how administration works now that the Admin API is gone, see Administering DVARA. For guardrail plugin concepts, see ML & Plugin Guardrails.

---

License status

This is the runtime view. To request, apply, or renew a license, see Get and apply a license.

Open the user menu in the top-right and click License to open the license-status page (also reachable directly at /license).

Shows license details and runtime status:

• Licensee — name of the license holder
• License type — TRIAL or PRODUCTION
• Expiry date — license expiration with days remaining
• Runtime status badge — color-coded:
  • VALID (green) — more than 30 days remaining
  • EXPIRING_SOON (yellow) — ≤ 30 days remaining
  • GRACE_PERIOD (orange) — expired, within 14-day grace period
  • DEGRADED (red) — expired beyond the 14-day grace period
• Renewal instructions — displayed when the license is expiring or expired

Figure 3. License status page with licensee details and runtime status badge

Data is read from the gateway's /actuator/gateway-status endpoint, which requires Authorization: Bearer $DVARA_ACTUATOR_API_KEY. Set the same secret on the DVARA Flightdeck (via DVARA_ACTUATOR_API_KEY) and on the gateway so the Flightdeck's License page can authenticate.

What DEGRADED actually blocks: /mcp/** and /a2a/**, with HTTP 402 / code: LICENSE_EXPIRED. /v1/** keeps serving — an expired licence does not stop your LLM traffic, because the LLM plane runs unlicensed anyway. The 402 body says so: "License expired. The MCP and A2A planes require a valid license; the LLM plane continues to serve unlicensed." Admin reads (GET /v1/admin/**) and the actuator probes stay open too, so you can diagnose and renew. The Flightdeck stays up throughout.

posture and license.status are different fields, and mid-incident is the wrong time to conflate them

posture is decided at boot from whether a licence was present, and does not move afterwards. license.status is the runtime state and does. So an instance whose licence has expired beyond grace reports posture: PRODUCTION and license.status: DEGRADED at the same time — that pair is not a contradiction, it is the normal reading for exactly the situation you are looking at. A restart with no valid licence is what changes posture to DEVELOPMENT.

Health probes

The DVARA Flightdeck exposes health endpoints designed for Kubernetes probes:

Endpoint	Purpose
GET /actuator/health/liveness	Kubernetes liveness probe
GET /actuator/health/readiness	Kubernetes readiness probe (includes a controlPlane health check)

The readiness probe checks database connectivity and the LLM Gateway connection. The DVARA Flightdeck operates independently of the LLM Gateway — admin operations continue even if the LLM Gateway is down, but readiness returns OUT_OF_SERVICE until both come back.

The Helm chart wires these up automatically:

livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: http
readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: http
startupProbe:
  httpGet:
    path: /actuator/health/liveness
    port: http

Audit event stream

The sidebar's Governance → Audit page (documented in more detail under Governance) is the third operational surface. It exposes every append-only event written to the audit chain — policy decisions, authentication events, config imports, license transitions, and more — with a live-polling table (3-second refresh), click-to-expand event detail, and CSV / JSON exports (/audit/export, CSV by default and JSON with ?format=json).

Figure 4. Audit events table with filters and live polling refresh