Skip to main content
Version: Latest (1.8.x dev)

Run DVARA Open Source

Use DVARA Open Source when one team needs governance on LLM traffic without a database or control plane. You run one DVARA LLM Gateway process, describe its providers and routes in gateway.yaml, and restart it when that file changes. DVARA Open Source is licensed under Apache-2.0.

1.8 release preparation

The source repository is not public yet. These commands build the reviewed 1.8 development source and will become the public source quickstart when the repository and 1.8 artifacts are released. Until then, use the Enterprise platform quickstart for a publicly runnable release.

What do you need?​

  • JDK 25, which is the Java version selected by the 1.8 build.
  • Git and a checkout of the DVARA source repository.
  • Port 8080 available locally.

This first run uses DVARA's Mock provider, so it needs no model-provider credential. The Mock provider is for local evaluation and automated tests; do not enable it in a production deployment.

How do you build the runnable gateway?​

From the repository root, run:

./mvnw clean install -DskipTests

The runnable artifact ends in -app.jar. The plain JAR does not contain its runtime dependencies and does not start as a standalone process.

How do you configure the first route?​

Create gateway.yaml in the repository root:

providers:
  - type: mock

routes:
  - id: local-mock
    model: "mock*"
    provider: mock

The file is read once during startup. Editing it does not change a running process; restart the gateway after every configuration change.

How do you record local audit evidence?​

Create a directory for the append-only log and generate a local HMAC secret:

mkdir -p var
openssl rand -base64 32

Keep the generated value private, then start the gateway with it:

DVARA_AUDIT_FILE_PATH="$PWD/var/audit.jsonl" \
DVARA_AUDIT_HMAC_SECRET='<generated-hmac-secret>' \
java -jar dvara-gateway-server/target/dvara-gateway-server-1.8.0-SNAPSHOT-app.jar

The gateway listens on http://localhost:8080. Without DVARA_AUDIT_FILE_PATH, requests still run but audit events are dropped with a startup warning. The local log is HMAC-signed and hash-chained, which makes later edits, removals, and reordering detectable. A holder of the HMAC secret can rewrite the chain, so this is tamper-evident local evidence rather than independent third-party proof.

How do you make the first governed request?​

In a second terminal, send a Chat Completions request:

curl -s http://localhost:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "mock/gpt-4",
    "messages": [
      {"role": "user", "content": "Summarize why runtime governance matters."}
    ]
  }'

The identifiers and timestamp vary, but the response has this shape:

{
  "id": "mock-6d0d5f08d3dd4aa5b536ba765cb0be63",
  "object": "chat.completion",
  "created": 1789092000,
  "model": "mock/gpt-4",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "This is a mock response"
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 12,
    "completion_tokens": 5,
    "total_tokens": 17
  }
}

The call enters the same LLM request path used for real providers. Because API-key enforcement defaults to off, this keyless request is anonymous and has no workspace-specific policy, PII action, or rate-limit override. Require API keys before using the runtime beyond local evaluation.

How do you verify the recorded result?​

After the request completes, inspect the last audit line:

tail -n 1 var/audit.jsonl

It contains a GATEWAY_RESPONSE event with the model, provider, status, latency, sequence, previous hash, and HMAC. The event proves that the governed request path completed; it does not store the prompt or response text unless you separately configure such retention.

What does a routing failure look like?​

Send a model that no configured provider serves:

curl -s -w '\nHTTP %{http_code}\n' http://localhost:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"unconfigured/model","messages":[{"role":"user","content":"Hello"}]}'

The gateway refuses the request instead of silently changing providers:

{
  "error": {
    "message": "No provider configured for model: unconfigured/model",
    "type": "invalid_request_error",
    "code": "no_provider",
    "trace_id": "01K4V5R9X21MDN8W5A6E7ZQ3TC"
  }
}
HTTP 400

Add a matching provider and route to gateway.yaml, then restart the process.

What should you do next?​

  • Choose a deployment if you need Flightdeck, centralized configuration, durable evidence operations, MCP, or A2A.
  • Configure DVARA for provider credentials, API-key enforcement, policy, PII, and rate limits.
  • Use the Data Plane API for supported endpoints, authentication, and request contracts.
Last updated on