Setup & Login

This page walks through getting the DVARA Flightdeck running, creating the initial owner account, and picking an authentication mode for production.

Starting the DVARA Flightdeck

With Docker

The fastest way to get DVARA Flightdeck running locally is with the published images:

# Start the LLM Gateway (port 8080)
docker run -d --name dvara-llm-proxy \
  -p 8080:8080 \
  -e MOCK_PROVIDER_ENABLED=true \
  ghcr.io/dvarahq/dvara/dvara-llm-gateway:latest

# Start the DVARA Flightdeck (port 8090) — hosts the web UI + Automation API
docker run -d --name dvara-console \
  -p 8090:8090 \
  -e DVARA_FLIGHTDECK_GATEWAY_URL=http://host.docker.internal:8080 \
  ghcr.io/dvarahq/dvara/dvara-flightdeck:latest

# Open http://localhost:8090/

With Docker Compose

The quick-start stack in dvara-examples brings up the database, the LLM Gateway, and the DVARA Flightdeck together:

cd dvara-examples/docker-compose/quick-start
cp .env.example .env
# set DVARA_LICENSE_KEY and OPENAI_API_KEY
docker compose up -d

# UI at http://localhost:8090/
# Server at http://localhost:8080/

See Docker Compose Setup for the full set of topologies.

With Kubernetes / Helm

# values.yaml
gatewayUi:
  enabled: true
  replicaCount: 1
  image:
    repository: ghcr.io/dvarahq/dvara/dvara-flightdeck
  resources:
    requests:
      cpu: 100m
      memory: 256Mi
    limits:
      cpu: 1
      memory: 512Mi

Health probes are auto-configured by the chart — see Kubernetes / Helm for the full deployment guide.

First-run setup

On first boot with the built-in auth mode, the DVARA Flightdeck redirects any anonymous visitor to /setup so you can create the initial owner account. This one-time flow is disabled after the first user exists.

1. Open http://localhost:8090 — you'll be redirected to /setup
2. Enter email, name, and password
3. Sign in at /login with your new credentials

Figure 1. First-run setup screen

Figure 2. Login screen

The owner has full platform access — tenants, routes, policies, budgets, users, and all other configuration. Invite additional users later from the Users page.

Authentication modes

By default the DVARA Flightdeck uses built-in email/password authentication. For production, you have three choices:

Mode	When to use	Config required
Built-in (default)	Local dev, small teams, no existing IdP	None — works out of the box
OIDC	Existing Keycloak, Okta, or Azure AD	DVARA_FLIGHTDECK_OIDC_ISSUER_URI
SAML 2.0	Enterprise SSO (ADFS, Okta SAML, Azure AD)	DVARA_FLIGHTDECK_SAML_METADATA_URL

OIDC and SAML are mutually exclusive — configuring both causes startup to fail. The OIDC + SAML property reference lives in the configuration table below; per-IdP step-by-step guides are deferred to a future release.

Disabling authentication for local development

For purely local tinkering, you can turn off admin authentication entirely by setting:

  dvara-admin:
    environment:
      DVARA_FLIGHTDECK_SECURITY_ENABLED: "false"

Never use this in production. The data plane still requires API keys regardless of this setting.

Enabling OIDC

When dvara.flightdeck.security.oidc.issuer-uri is set, the DVARA Flightdeck redirects anonymous users to the external IdP for browser-based OAuth2 login. Automation tools obtain JWTs via the client credentials grant and pass them as Authorization: Bearer <token>.

  dvara-admin:
    environment:
      DVARA_FLIGHTDECK_SECURITY_ENABLED: "true"
      DVARA_FLIGHTDECK_OIDC_ISSUER_URI: https://keycloak.example.com/realms/dvara
      DVARA_FLIGHTDECK_OIDC_AUDIENCE: dvara-admin
      DVARA_FLIGHTDECK_OIDC_ROLE_CLAIM: realm_access.roles

Property	Env Var	Purpose
dvara.flightdeck.security.enabled	DVARA_FLIGHTDECK_SECURITY_ENABLED	Enable authentication (default: true)
dvara.flightdeck.security.oidc.issuer-uri	DVARA_FLIGHTDECK_OIDC_ISSUER_URI	OIDC discovery endpoint of your IdP
dvara.flightdeck.security.oidc.audience	DVARA_FLIGHTDECK_OIDC_AUDIENCE	Expected JWT audience claim
dvara.flightdeck.security.oidc.role-claim	DVARA_FLIGHTDECK_OIDC_ROLE_CLAIM	JWT claim containing user roles (default: roles)

RBAC roles

When security is on, RBAC is enabled by default (dvara.flightdeck.security.rbac.enabled=true). Six built-in roles split into three platform and three tenant scopes:

Role	Scope	Typical user
owner	Platform — full access to everything	Platform lead, CTO
policy-admin	Platform — policies, routes, guardrails, MCP servers, approval queue	Security engineer
billing-admin	Platform — pricing, costs, budgets, chargeback, compliance	Finance, FinOps
admin	Tenant — full access within own tenant + user management	Team lead
developer	Tenant — create API keys, view usage, dry-run policies	Application developer
viewer	Tenant — read-only access within own tenant	Auditor, observer

Roles are assigned in the Users page and mapped from JWT claims at login. The catch-all rule requires owner for any admin path not explicitly granted to another role, so new endpoints are locked down by default.

Setting dvara.flightdeck.security.rbac.enabled=false falls back to simple authenticated() checks — any valid JWT grants full access.

Tenant scoping

Most list pages (tenants, policies, routes, MCP servers, users, costs, budgets, sessions) include a Tenant dropdown filter. When RBAC is active, users can only see and modify resources that their assigned role permits. Tenant-scoped API calls accept a ?tenant_id= query parameter.

Figure 3. Policies list filtered by tenant via the tenant dropdown

Admin server configuration

Property	Env Var	Default	Description
dvara.flightdeck.gateway.url	DVARA_FLIGHTDECK_GATEWAY_URL	http://localhost:8080	LLM Gateway URL (for dashboard metrics + health check only)
dvara.actuator.api-key	DVARA_ACTUATOR_API_KEY	(empty)	Shared-secret Bearer used by the DVARA Flightdeck when it calls the LLM Gateway's /actuator/gateway-status endpoint. Set the same value on the gateway. Generate with openssl rand -base64 32. Must differ from DVARA_ACTUATOR_METRICS_API_KEY — principle of least privilege.
dvara.actuator.metrics-api-key	DVARA_ACTUATOR_METRICS_API_KEY	(empty)	Distinct shared-secret Bearer used by the DVARA Flightdeck when it scrapes the LLM Gateway's /actuator/prometheus endpoint. Must differ from DVARA_ACTUATOR_API_KEY — a leaked metrics-scrape token must not unlock the gateway-status surface. Generate independently with openssl rand -base64 32.

/actuator/gateway-status exposes metadata only

Even with DVARA_ACTUATOR_API_KEY, the gateway-status endpoint returns license metadata (licensee name, expiry, ID, runtime status) — never the raw DVARA_LICENSE_KEY envelope. Once validated at startup the envelope stays in process memory; no API surfaces it. Provider API keys, vault credentials, and the audit HMAC secret are likewise never returned — only operator-facing metadata. Same applies when the Flightdeck License page renders this data through the browser session.

| dvara.flightdeck.gateway.connect-timeout-ms | — | 5000 | Connection timeout (ms) | | dvara.flightdeck.gateway.read-timeout-ms | — | 10000 | Read timeout (ms) |

The earlier property family gateway.server.* / gateway.control-plane.* (and the matching GATEWAY_SERVER_* / GATEWAY_CONTROL_PLANE_* env vars) was removed in 1.0.0-GA per the env-var namespace rename. Use the dvara.flightdeck.gateway.* properties / DVARA_FLIGHTDECK_GATEWAY_* env vars above. A startup probe (LegacyEnvVarDeprecationProbe in enterprise-core) WARNs at boot whenever a legacy GATEWAY_* env var is still set so operators redeploying a stale .env see the migration hint loudly.

The DVARA Flightdeck and the LLM Gateway are decoupled — the DVARA Flightdeck only talks to the LLM Gateway for live dashboard metrics and provider health. All other admin operations read and write the DVARA control plane store directly.