Skip to main content
Version: 1.7.0

Releases & Upgrading

DVARA ships as a set of components that are versioned and released together — the gateway, Flightdeck, and the Helm chart all carry the same version for a given release. Run one version across the fleet; do not mix component versions.

  • Container images — ghcr.io/dvarahq/dvara-gateway:<version> and ghcr.io/dvarahq/dvara-flightdeck:<version>
  • Helm chart — oci://ghcr.io/dvarahq/charts/dvara --version <version> (its appVersion matches the image tag)
  • Shipped versions — every version that has shipped is listed, image by image, on the DVARA container packages page. Each release tags every component with the same version, so the tag list is the record of what exists.

Versions follow semantic versioning (MAJOR.MINOR.PATCH). Minor releases add capability and are drop-in over the previous minor; patch releases are drop-in fixes.

Compatibility at a glance​

DVARA versionHighlights
1.7.0The MCP and A2A planes moved into the gateway — one data-plane process, one port. The Automation API was removed; the Console and GitOps are the management surface. workspace became workspace across the data model. A data-plane pod can now run with no database at all, serving signed config bundles and spooling audit locally. See Upgrading to 1.7.0 — it carries actions, not just notes.
1.3.xThe A2A (agent-to-agent) governance plane — a separate, opt-in plane on port 8075 with its own policy/PII/approval/loop-detection engines and its own tamper-evident audit chain. Console review: server-side pagination, unified audit + approval viewers behind a plane selector, four-hour Console sessions.
1.2.xAgent-surface APIs (Responses, Batch), MCP depth (REST→MCP bridging, virtual MCP servers, delegated auth), OpenTelemetry GenAI semantic conventions, more guardrail connectors (Bedrock Guardrails, Aporia, in-process ONNX injection classifier), neural semantic cache (HNSW), India RBI/SEBI reports + Aadhaar/PAN detectors, per-provider upstream rate-limit tracking, per-workspace spend pre-aggregation.
1.1.xNative MCP protocol support, Keycloak/Auth0 SSO presets, verified GKE and DOKS Kubernetes recipes.
1.0.xFirst GA — the LLM Gateway, governance core, MCP Gateway, and Flightdeck.

Upgrading in place​

A minor or patch upgrade is a drop-in: keep your existing license, configuration, and database, and roll the new version.

Docker Compose​

# bump the image tags in your compose file to the new version, then:
docker compose pull
docker compose up -d
docker compose ps      # all services healthy on the new tag

Helm / Kubernetes​

helm upgrade dvara oci://ghcr.io/dvarahq/charts/dvara \
  --version <new-version> --namespace dvara --reuse-values
kubectl -n dvara rollout status deploy --timeout=300s

Database migrations​

DVARA applies its own schema migrations on startup, so the new version's schema is in place on first boot — no manual step. Migrations are additive and forward-only; take a database backup before a major upgrade as a matter of course.

Turning on the A2A plane​

Since 1.7.0 the A2A plane runs inside the gateway process. There is no service to add and no Helm flag to set: it activates when the gateway starts with a valid license, which is one of the two things a license gates. See Editions & images.

The license is read at startup, so applying one to a running unlicensed instance does not activate the plane until it restarts.

The A2A plane's storage is created by the same startup migration as everything else, whether or not the plane is active, so enabling it later needs no separate step.

Upgrading from 1.6.0 or earlier

Earlier releases ran A2A as a separate dvara-a2a-gateway service on port 8075, enabled with a2aProxyServer.enabled: true. That image is retired and the Helm key no longer exists. Drop the service, drop the key, and repoint anything addressing :8075 at the gateway on :8080.

Upgrading to 1.7.0​

1.7.0 is the largest release since 1.0. Most of it is drop-in, but three items need you to do something and several will be met as bugs if you have not read them.

Do these​

1. Rotate your API keys, then purge the old telemetry rows​

Until 1.7.0, the per-request usage and cost records stored the full plaintext API key, not a prefix. Current builds store only the prefix, but rows written by earlier versions still hold live keys — and those records are what an operator exports for billing and hands to finance.

Treat every key that was in use before the upgrade as disclosed:

-- 1. See the scope of it. A prefix is 11 characters (gw_ + 8); anything
--    longer is a live key.  Verified against ApiKeyGenerator.extractPrefix
--    and against live rows.
SELECT count(*) FROM dvara_main.token_usage_records WHERE length(api_key) > 11;
SELECT count(*) FROM dvara_main.cost_records        WHERE length(api_key) > 11;
  1. Rotate every affected key — Console → Workspaces → keys, or the Portal for a workspace's own. Revoke the old key once callers are moved.
  2. Then purge the stored values. Do it in that order — purging first destroys the record of which keys were exposed while those keys are still live.
-- 2. Reduce the stored value to a prefix, matching what current builds write.
UPDATE dvara_main.token_usage_records SET api_key = left(api_key, 11) WHERE length(api_key) > 11;
UPDATE dvara_main.cost_records        SET api_key = left(api_key, 11) WHERE length(api_key) > 11;

Attribution is unaffected — the prefix is what the Console and the reports group by.

2. Re-run audit-chain verification, and discount any earlier failure​

Chain verification failed for any event whose payload contained a nested map of two or more keys: nested values were signed as Java toString(), whose ordering is not stable. A verification run before 1.7.0 that reported tampering was giving you a real result about the wrong thing.

Re-run verification after upgrading. Events written by earlier builds keep the old signature, so a failure on a historical segment may be this and not tampering — check whether the payload is nested before treating it as an incident.

3. Reset prompt experiments that span the upgrade​

Latency and cost accumulated as literal zeros, and streaming traffic was assigned a variant but never recorded against it. An experiment running across the upgrade has averages that are not comparable to post-upgrade numbers, and no migration corrects it — the columns are already zero. Reset it from the Console (/experiments → Reset), or discount its averages until new traffic dominates.

Know these​

changewhat you will hit
The Automation API is goneEvery /v1/admin/** endpoint returns 404. Bulk provisioning is the Console's GitOps page — export → edit → import.
tenant_id → workspace_idAcross the data model and the public API. Scripts reading either will need the new name.
Typed workspace settings beat metadataOnce a workspace has a typed settings row, editing the matching metadata key has no effect and raises no error. Use the Console's Data Protection page.
Console RBAC narrowedA policy-admin who could open Users, or a billing-admin who could open Policies, now gets 403. The sidebar hides them, so pages disappear rather than break.
Config caching on by defaultA config edit lands within the poll interval (~3s) rather than instantly.
JSONB payloads are additive-onlyAdding a field is safe; renaming one is silent data loss. Rollback and mixed-version fleets depend on this.
Migration history squashedThe schema migration history is now a single baseline. If you carry local migrations, re-base them onto it — and never edit the baseline, because an install that has already applied it will refuse to start when its checksum changes.

The optional part: running a pod without a database​

A data-plane pod can serve with no datasource at all, reading configuration from a signed bundle and spooling audit locally. It is opt-in and off by default — nothing changes unless you turn it on. See Data-plane decoupling.

Rolling back​

If a check fails after an upgrade, roll back to the previous version:

# Compose: revert the image tags and re-up
docker compose up -d

# Helm: roll back to the previous revision
helm rollback dvara <PREVIOUS_REVISION> --namespace dvara

Because migrations are forward-only, roll back to a version whose schema your database still satisfies — in practice the immediately previous release. When in doubt, restore from the pre-upgrade backup.

Where to go next​

Last updated on