Releases & Upgrading
DVARA ships as a set of components that are versioned and released together — the LLM Gateway, Flightdeck, the MCP Proxy, the A2A Proxy, 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/dvara-{llm-gateway,flightdeck,mcp-gateway,a2a-gateway}:<version> - Helm chart —
oci://ghcr.io/dvarahq/charts/dvara --version <version>(itsappVersionmatches the image tag) - Release notes — every release is written up on GitHub Releases; the notes name the images, the chart, and the changes.
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 version | Highlights |
|---|---|
| 1.3.x | The 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.x | Agent-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-tenant spend pre-aggregation. |
| 1.1.x | Native MCP protocol support, Keycloak/Auth0 SSO presets, verified GKE and DOKS Kubernetes recipes. |
| 1.0.x | First GA — the LLM Gateway, governance core, MCP Proxy, 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 runs Flyway on startup, so schema migrations for the new version apply automatically 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 (1.3.0+)
The A2A plane is opt-in and off by default, so existing three-plane deployments are unaffected by upgrading to 1.3.x. To run it:
- Compose — add the
dvara-a2a-gatewayservice (port8075) to your stack. It shares the same license, datasource, and platform secrets as the other services. See Docker → Full stack. - Helm — set
a2aProxyServer.enabled: true.
The a2a_* tables are created by the same Flyway run as the rest, whether or not the A2A proxy is running, so enabling the plane later needs no separate migration.
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
- Deployment overview and Configuration reference
- GitHub Releases for the per-version detail