Skip to main content
Version: 1.8.0

Deploy DVARA

A reliable DVARA deployment keeps governance on the request path without making its control plane a new source of outages. Start by choosing DVARA Open Source or the Enterprise platform; their dependencies and operating models are different.

This page covers self-managed deployments. For a dedicated environment operated by DVARA, see Choose a deployment.

Choose the topology that matches your distribution​

TopologyComponentsDatabaseBest fit
Open Source distributionOne DVARA LLM Gateway configured by gateway.yamlNoneA team that wants a small, self-managed LLM governance runtime
Enterprise platform with Docker ComposeDVARA Gateway, DVARA Flightdeck, and PostgreSQL on one hostBundled by the example stack, for Flightdeck onlyEvaluation, development, and non-HA environments
Enterprise platform on KubernetesReplicated Gateway and Flightdeck workloads with external PostgreSQLPostgreSQL 14+ for Flightdeck, that you operate or consume as a managed serviceProduction and horizontally scaled environments

The Open Source distribution has no Flightdeck, Enterprise persistence, MCP Gateway, or A2A Gateway. Its configuration is local and takes effect after restart.

The Enterprise platform centralizes configuration, evidence, cost, identity, and operations in Flightdeck.

Prepare an Open Source distribution deployment​

The standalone Open Source distribution needs Java 25, a gateway.yaml file, and network access to each model provider you configure. It does not need PostgreSQL or a licence.

Before you put it on a shared request path:

  1. Generate a DVARA API key and store only its SHA-256 fingerprint in the file.
  2. Set DVARA_CONFIG_FILE when the file is not in the process working directory.
  3. Set DVARA_AUDIT_FILE_PATH to a durable, writable path if you need audit evidence. When it is unset, audit events are dropped and startup logs a warning.
  4. Set a private DVARA_AUDIT_HMAC_SECRET. The public development placeholder must not protect production evidence.
  5. Terminate TLS before the Gateway and restrict operational endpoints at the network boundary.

Each replica reads its own startup file. Distribute the same reviewed file to every replica, restart them in a controlled rollout, and give each process its own audit file. The runtime does not coordinate configuration or local audit files across replicas.

Follow Run the Open Source distribution for the build, key-generation, request, and audit-verification workflow.

Prepare an Enterprise platform deployment​

The minimum Enterprise topology is the DVARA Gateway, DVARA Flightdeck, and PostgreSQL 14 or later. The Gateway serves all active planes on port 8080; Flightdeck serves the Flightdeck on port 8090.

From 1.8.2 only Flightdeck connects to PostgreSQL, and only Flightdeck runs its migrations. The Gateway has no database: it enrols with Flightdeck, reads its configuration from a signed bundle Flightdeck publishes over its /internal channel (port 8443), and spools audit, usage and cost records to its own volume before shipping them to Flightdeck. See How the gateway runs without a database.

Prepare these dependencies before installation:

RequirementWhy it is needed
PostgreSQL 14+Flightdeck's store for managed configuration, identity, cost, and audit evidence
Provider accessLets the Gateway reach at least one configured model provider
Database credentialsFor Flightdeck only. From 1.8.2 a Gateway given a database refuses to start
Enrolment shared secretLets each Gateway enrol with Flightdeck for its /internal certificate; the same value on both, at least 32 characters
A volume per GatewayHolds the Gateway's spool, bundle snapshot and certificate; it must survive a restart
Encryption master passwordProtects provider credentials stored in encrypted mode
Audit HMAC secretSigns the tamper-evident audit chain when you manage the key material
Actuator API keyProtects operational status endpoints
A distinct metrics API keyProtects metrics without granting broader operational access
DVARA licenceRequired for production rights and support; removes the 3-workspace and 100,000-call limits

The stock Enterprise Gateway image carries the in-process Defender prompt-injection classifier and, from 1.8.1, the optional Phileas scanner. Both are off until you turn them on. Presidio and the HTTP classifiers need services you run or subscribe to. Treat a setting as configuration rather than proof that a detector is present, and check the Gateway startup log for the ones that are actually active.

Do not reuse the actuator key as the metrics key. Both values must match between Flightdeck and the Gateway where the corresponding connection is used.

For a single-host evaluation, use the Docker Compose guide. For production, use the Kubernetes guide and keep secrets in your cluster's secret-management path rather than command history or a checked-in values file.

Design the production boundary​

Expose only the surfaces their users need:

  • Send application traffic to the Gateway. /v1/* is the LLM plane; /mcp/* and /a2a/* are the MCP and A2A planes, served with or without a licence.
  • Put Flightdeck on a separate administrative hostname and apply your normal identity and network-access controls.
  • Keep PostgreSQL private. Only Flightdeck connects to it; the Gateway, the browser and calling applications do not.
  • Keep Flightdeck's /internal port (8443) reachable from Gateway pods only. It is a pod-to-Flightdeck channel, not a public API.
  • Keep /actuator/health, /actuator/health/liveness, /actuator/health/readiness, and /actuator/info available to platform probes. Other operational endpoints require the appropriate bearer key.
  • Terminate TLS at the ingress or load balancer and encrypt database connections according to your infrastructure policy.

Use separate provider credentials and DVARA API keys for each environment. A workspace and key name should identify both the application and environment so audit and cost records remain understandable.

Set availability controls deliberately​

The Kubernetes chart starts with one Gateway replica, one Flightdeck replica, autoscaling disabled, and disruption budgets disabled. Those defaults make a small evaluation easy; they are not a high-availability claim.

For a production rollout:

  1. Run at least two Gateway replicas across failure domains.
  2. Set resource requests and limits from a load test that represents your streaming duration, concurrency, provider latency, and guardrail work.
  3. Enable autoscaling only after the chosen CPU, memory, or custom signal tracks saturation in that test.
  4. Add a disruption budget that matches the replica count and availability objective.
  5. Keep rolling updates at zero unavailable Gateway replicas unless your capacity plan permits an interruption.
  6. Back up PostgreSQL and test restore, not only backup creation.

The Gateway's startup and readiness probes use /actuator/health/readiness; its liveness probe uses /actuator/health/liveness. Do not replace readiness with a process-only check: a running process that cannot become ready should not receive new traffic.

Give each Gateway pod a volume, not a database credential​

From 1.8.2 Gateway pods hold no database credential. Each pod keeps serving from its last verified bundle during a Flightdeck or PostgreSQL outage, and its records wait in its spool until Flightdeck is back. Up to 1.8.1 Gateway pods connected to PostgreSQL by default; that option was removed.

What each pod needs instead:

  • Flightdeck's /internal address and the enrolment secret. The Compose example and the Helm chart set both.
  • A volume for its spool that survives a restart. The chart's default is an emptyDir; turn on llmGatewayServer.persistence.enabled for production.
  • A termination grace period long enough for the spool to flush on shutdown.

Alert on spool shedding and drain lag; the observability guide lists the shipped signals. A change made in Flightdeck reaches a Gateway in about 10 seconds at the default settings, and a Gateway's records reach Flightdeck in about 30 seconds. Follow How the gateway runs without a database for enrolment, certificates, and failure modes.

Verify the deployment from edge to evidence​

First, check the Gateway through the same load balancer or ingress applications will use:

curl --fail --silent https://<dvara-host>/actuator/health

The anonymous response reports the overall result without exposing component details:

{
  "status": "UP",
  "groups": ["liveness", "readiness"]
}

Next, sign in to Flightdeck and confirm its connection indicator is green. Create a workspace, provider credential, route, and DVARA API key, then send a request through the public Gateway address:

curl --fail --silent https://<dvara-host>/v1/chat/completions \
  --header 'Authorization: Bearer <your-dvara-key>' \
  --header 'Content-Type: application/json' \
  --data '{
    "model": "<configured-model>",
    "messages": [
      {"role": "user", "content": "Confirm the production route is governed."}
    ]
  }'

A successful response is only the first check. In Flightdeck, open Governance → Audit, select the workspace and GATEWAY_RESPONSE, then confirm the request's model, status, and latency. The record reaches Flightdeck when the Gateway's spool drains, so allow about 30 seconds. Finally, restart one Gateway replica and repeat the request while the rollout is in progress. That verifies the edge, request path, evidence path, and basic failover together.

Diagnose the first failure before adding complexity​

SymptomCheck first
Gateway is live but not readyReadiness response and Gateway logs; then enrolment with Flightdeck and the last verified bundle
Gateway refuses to start and names a settingA missing Flightdeck address or spool path, or a database setting left on the Gateway
Flightdeck shows disconnectedGateway URL and the matching actuator API key
Flightdeck metrics are emptyThe distinct metrics API key on both applications
Request returns 401Whether the supplied API key exists, is active, and belongs to the intended workspace
Request has no provider routeProvider credential, requested model, and route pattern
Audit row is absentWorkspace attribution, and whether the Gateway's spool has drained to Flightdeck (about 30 seconds by default)
Calls refused with 402 *_cap_exceeded and no licenceThe install passed 110,000 governed calls this month; add a licence or wait for the 1st

Keep the topology simple until the health check, one governed request, and its evidence all work. Add autoscaling, advanced routing, regional placement, and per-pod volumes one change at a time, with the same verification after each.

Continue with the focused guide​