Upgrade DVARA to 1.8

DVARA 1.8 changes how several governance decisions are enforced. Before you replace an image or JAR, inventory scoped API keys, decide whether existing PII settings should redact or tokenize, and update monitoring and rate-limit configuration. Then roll one version across the fleet and verify the governed result, not only process health.

This page covers an upgrade from 1.7. If you run 1.6 or earlier, complete the 1.7 preparation first.

Already on 1.8? Read Moving to 1.9.0 before you upgrade.

What changes in 1.8?

DVARA remains an AI governance platform, but 1.8 introduces a separate Open Source distribution alongside the Enterprise platform. This is a distribution boundary, not an in-place edition switch.

Area	1.8 change	Who must act
API keys	Nonempty scopes are enforced on LLM, MCP, and A2A operations. Omitted scopes now create an unrestricted key.	Any deployment with existing scoped keys
PII	REDACT is irreversible. TOKENIZE is the reversible action and requires the Enterprise token store.	Any deployment that used the old reversible meaning of REDACT
Streaming	A control that can withhold content buffers the complete response before one decision.	Latency-sensitive streaming clients and memory planners
Rate limiting	Shared-cache settings move from rate-limit.resp.* to rate-limit.shared-cache.*.	Deployments using an external rate-limit cache
Licence monitoring	Posture and licence fields move from /actuator/gateway-status to Enterprise /actuator/license.	Monitoring, expiry automation, and dashboards
Limits and guardrails	Several defaults and previously inert settings now take effect.	Deployments with custom limits, classifiers, patterns, or metadata
Java embedding API	Permission, BuiltInRole.permissions() and hasPermission() were removed; BuiltInRole moved to a different published artifact.	Applications embedding an Open Source starter and importing those symbols
MCP and A2A credentials	A workspace-owned credentialRef resolves only a credential stored in that same workspace.	Operators whose references name vault paths, platform secrets, or another workspace

The Open Source distribution includes the LLM Gateway, file configuration, and local audit. It does not include Flightdeck, the MCP Gateway, the A2A Gateway, Enterprise tokenization, or fleet operations. Do not replace an Enterprise image with the Open Source distribution as an upgrade shortcut. See Capability availability.

What should you back up?

Before the maintenance window:

1. Pin the currently running image, chart, or JAR version so rollback does not depend on a moving tag.
2. Back up the Enterprise PostgreSQL database with your normal tested procedure.
3. Export a fleet configuration from Flightdeck's GitOps page and store it with the release record. The export redacts secrets; keep the secret-store backup separately.
4. Record the current responses from /actuator/health/readiness, /actuator/info, and /actuator/gateway-status. On the Enterprise platform, also record the current licence state.
5. Save representative LLM, streaming, MCP, and A2A requests with their expected responses and audit evidence.

The Open Source distribution has no database migration. Back up gateway.yaml, the audit file, and every external secret it references.

Before upgrading, export MCP servers and A2A agents and inspect every credentialRef. Replace any vault path, platform secret name, or cross-workspace reference with the name of a credential stored in the owning workspace. An unresolved reference no longer sends a credential after the upgrade.

Which 1.8 operational changes need preparation?

Change	What moves	What to do before rollout
Telemetry retention	Flightdeck schedules a 90-day retention sweep by default. Its first run permanently deletes older evaluation, prompt-experiment, shadow-policy, and shadow-routing events.	Export records you must retain, then set each dvara.persistence.telemetry-retention.*-days value deliberately; 0 or less keeps that table, and cron - disables the sweep.
Workspace PII settings	Older Flightdeck edits could erase the stored PII posture while saving unrelated fields.	Recheck every workspace's PII action after upgrading from 1.7.
Shared cluster counters	The chart now configures pod discovery. A fleet that previously admitted the limit once per replica now admits the configured limit across the fleet.	Verify gateway_hazelcast_cluster_members equals the replica count on every pod.
Audit HMAC secret	DVARA no longer generates or stores a new signing secret. Every production gateway and Flightdeck process must receive the same DVARA_AUDIT_HMAC_SECRET. A production-class Spring profile refuses to boot when DVARA_AUDIT_HMAC_SECRET is unset, and the refusal message includes the SQL that reads the previously stored value out of audit_hmac_secret; the stored value is read automatically on a dev/test/ci/local/default profile only.	Move any legacy stored value into your secret manager and inject it everywhere. An older encrypted row still needs the matching DVARA_ENCRYPTION_MASTER_PASSWORD during migration. dvara.audit.encrypt-stored-hmac-secret is inert in the final 1.8 build.
Killed sessions	Session deny-list keys now include the workspace: workspace-id/session-id.	Avoid a mixed-version window for session-kill enforcement; each version treats the other's key shape as unknown.

How do you prepare existing API keys?

In 1.7, a stored scope could behave like a label. In 1.8, a nonempty scope list is an authorization boundary. An empty list remains unrestricted.

Scope	Operations it permits
completions:write	Chat Completions, legacy Completions, Responses, and Enterprise budget estimation
embeddings:write	Embeddings
batches:write	Files and batches
models:read	Model discovery
mcp:read / mcp:call	Read MCP capabilities / invoke MCP tools
a2a:read / a2a:send	Read A2A task state / send messages and perform A2A actions

Review every key before rollout. In the Open Source distribution, inspect scopes below api_keys[] in gateway.yaml. In the Enterprise platform, use the API-key list in Flightdeck.

For each workload, compare its actual calls with the table. Update the Open Source file or issue a replacement Enterprise key with the required scopes, deploy the new secret, and verify it before revoking the old key. Do not clear scopes merely to make a failing client work; that widens the key to every available plane.

A valid key used outside its scopes receives 403. The LLM error code is api_key_scope; MCP and A2A return their plane-specific scope-denied code. A wrong, revoked, or expired key receives 401, even when the LLM Gateway permits missing keys for development.

See Authenticate gateway calls for the complete map and rotation flow.

How does 1.8 migrate API-key attribution?

In 1.8, usage, cost, audit, access logs, analytics, exports, and per-key budgets all use the key's opaque ID. Earlier records could contain only a public prefix, which did not reliably match a per-key budget.

During an Enterprise upgrade, DVARA converts an existing prefix when exactly one key in that workspace owns it. An unowned or ambiguous prefix remains unchanged and does not count toward an ID-scoped budget. If an older batch record contains a complete credential, DVARA replaces it with the matching opaque ID; an unresolvable value becomes anonymous, so the credential does not remain in stored telemetry.

Per-key spend counters restart their 1.8 identity

The shared in-memory spend counter discards older prefix-keyed per-key cells and starts ID-keyed cells at zero. During a rolling upgrade, a per-key cap therefore counts only spend written by upgraded gateway replicas. Workspace-wide and global counters are unaffected, and the persisted usage and cost history remains normalized and complete.

Upgrade the control plane first, finish the gateway rollout promptly, and treat the rest of the current budget period as a possible one-period discount for per-key caps. Before 1.8 those caps could not reliably match prefix-attributed spend, so this is the transition into working per-key enforcement rather than a loss of previously enforced spend.

Rate limits use the opaque key ID after repository resolution, so two keys keep separate buckets and a replacement key starts a new one. An embedding application with no key repository uses a SHA-256 fingerprint of the bearer value for its bucket; it does not retain the plaintext credential.

The bucket-name change resets each key's request and token counters once at upgrade. Limits do not change, but a caller can briefly receive a fresh allowance; no operator action is required.

Built-in phone, card, SSN, and IPv4 detectors now require standalone values. Long numeric identifiers and four-part version strings that produced false matches in earlier releases can now pass unchanged.

How do you choose the intended PII behavior?

Before 1.8, REDACT described reversible substitution. In 1.8 the two outcomes have separate names:

Action	Result	Requirement
REDACT	Replace detected data with an irreversible type placeholder and store no original value	No token store or key material required
TOKENIZE	Replace provider-bound input with a reversible token	Enterprise token store and usable key material

The Enterprise database migration changes stored workspace actions from REDACT to TOKENIZE so those workspaces keep their old reversible behavior. The global dvara.llm-gateway.pii.default-action is process configuration and cannot be migrated automatically.

Before rollout, decide deliberately:

• Keep or set REDACT when the original value must not be recoverable.
• Set TOKENIZE when the old reversible behavior is required, and verify the Enterprise token store before sending traffic.
• If the global default is currently REDACT and you need the old behavior, change it to TOKENIZE before rollout.

Newly detected PII in model, MCP, or A2A output is removed irreversibly under both actions. TOKENIZE does not give the caller a recovery token for new response data. Optional automatic detokenization restores only tokens minted from the incoming request on the supported non-streaming round trip, and it is off by default.

If DVARA cannot perform configured tokenization, it refuses safely or applies the explicitly configured degraded action. The legacy PII_REDACT_DEGRADED event and PII_REDACT_UNAVAILABLE error keep their names for compatibility; read attempted_action=TOKENIZE instead of inferring the action from the old identifier.

See PII governance before approving this part of the migration.

How does streaming behavior change?

Streaming delivery now depends on whether an active control can withhold text:

Mode	Active controls	1.8 delivery behavior
Immediate	Observational actions such as PII LOG or guardrail LOG/FLAG	Deliver events as they arrive and scan for evidence.
Deferred	PII BLOCK, REDACT, or TOKENIZE; guardrail or grounding BLOCK	Hold the complete response, make one decision, then release governed content or refuse it.

There is no compatibility switch for the old incremental withholding behavior. The old scan-window and overlap properties remain accepted but do not control the whole-response decision.

Load-test the largest expected response and client timeout before rollout. Deferred streams need more memory and do not deliver the first content token until governance completes. A Deferred response beyond its bound is refused; an Immediate response beyond its observation bound continues and records incomplete scanning.

Review the configured held-content bounds and the complete SSE lifetime. The global streaming-timeout-ms now bounds the response lifetime and releases a stalled upstream connection. It is not an idle timeout. A provider-specific override bounds only the wait to open that provider stream. Failover is possible only before reading starts; DVARA cannot fail over or resume midstream.

Update clients that expect a final usage event. DVARA does not add usage to the public SSE response. It stores terminal provider usage when available and otherwise estimates from the request and delivered content. Cohere and Ollama streams use estimates. Before 1.8.4 Anthropic and Gemini streams did too; from 1.8.4 they report exact usage. After headers are committed, a Responses API failure arrives as response.failed; an unhandled Chat Completions transport failure closes the stream. Client cancellation releases the upstream transport and finalizes partial Immediate-mode evidence on a best-effort, five-second path.

Which configuration and monitoring contracts move?

Update these before changing the running version:

1.7 contract	1.8 contract or behavior
dvara.llm-gateway.data-plane.require-api-key / DVARA_LLM_GATEWAY_REQUIRE_API_KEY	Removed. Every /v1 request requires a key. Remove the setting; a false value refuses startup, while true is tolerated only as dead migration configuration.
dvara.llm-gateway.rate-limit.resp.url	dvara.llm-gateway.rate-limit.shared-cache.url
dvara.llm-gateway.rate-limit.resp.failure-mode	dvara.llm-gateway.rate-limit.shared-cache.failure-mode; default OPEN
Licence fields under /actuator/gateway-status	GET /actuator/license with DVARA_ACTUATOR_API_KEY; Enterprise platform only
Flightdeck health detail llm-gateway-server	enterprise-gateway-server; image name and Helm llmGatewayServer values stay unchanged
gateway_schema_retries_total	Removed; output-schema validation does not retry
Streaming scan-window and overlap settings	Accepted for compatibility but ignored by whole-response enforcement
Semantic-cache threshold read on every request	Cached for 60 seconds by default; set dvara.llm-gateway.cache.semantic.config-cache-ttl-seconds=0 for an uncached read

The old rate-limit.resp.* keys are ignored. If they remain, each replica can silently use its local limiter instead of the intended shared backend. Merely deploying Valkey or Redis does not select it; set the new shared-cache URL. The connection opens on the first governed request, and an unreachable backend then follows failure-mode.

Keep DVARA_ACTUATOR_API_KEY and DVARA_ACTUATOR_METRICS_API_KEY separate. The Open Source distribution does not expose /actuator/license.

Which behavior changes should you test?

These corrections can change a response without requiring a configuration rename:

Area	What to test before rollout
Required API keys	Every /v1 request now requires a workspace key. Mint and deploy keys before rollout; verify that a missing key returns 401 api_key_required and an unknown key returns 401 invalid_api_key.
Embeddings	dimensions is forwarded. encoding_format: base64 now returns 400 UNSUPPORTED_CAPABILITY instead of being ignored; float remains the default.
Input size	dvara.llm-gateway.guardrail.max-input-tokens now defaults to 0, so the provider's declared context window governs. Set 32000 to preserve the previous fixed cap.
Context windows	Small-window providers can refuse requests earlier; large-window providers can accept requests that the old fixed assumption rejected.
Token accounting	Chat admission reserves an estimate and settles the difference instead of charging estimate plus actual. A binding token limit can therefore allow roughly twice the previous useful throughput.
Workspace metadata booleans	Values such as yes, on, and 1 now enable a control. An unreadable protection setting inherits its global value instead of silently becoming false.
Content-category actions	A deliberately looser category action now takes effect. The strictest action across all detections in the same request still wins.
Classifier actions	Classifier-only detections default to FLAG. Set INHERIT to keep the earlier general guardrail action when you supply a classifier.
Custom injection patterns	Stored workspace patterns now run on the request path. Test existing expressions for intended matches.
Output schemas	An edited schema takes effect without a process restart. Retired retry and correction fields remain ignored in gateway.yaml.
Date-range reports	A bare end date now includes that complete day. The same report period can therefore be larger than its pre-1.8 result.
SMTP	transport=smtp without spring.mail.host now refuses startup instead of silently falling back. Configure the host or choose resend or log deliberately.

How do you roll out 1.8?

Use the same final version for the Enterprise Gateway, Flightdeck, and Helm chart. Do not use latest, mix 1.7 and 1.8 longer than the rolling window, or assume a minor version is automatically drop-in.

For Docker Compose, change every DVARA image tag to the same final version:

docker compose pull
docker compose up -d
docker compose ps

For Helm, save your current values and inspect them for retired keys before the upgrade:

helm get values dvara --namespace dvara -o yaml > dvara-values-before-1.8.yaml

helm upgrade dvara oci://ghcr.io/dvarahq/charts/dvara \
  --version 1.9.0 \
  --namespace dvara \
  --values dvara-values-1.8.yaml

kubectl -n dvara rollout status deploy --timeout=300s

Flightdeck applies database migrations at startup. From 1.8.2 it is the only process that connects to PostgreSQL or migrates it, and DVARA_DB_MIGRATE is no longer read. Before 1.8.2, Gateway pods also applied migrations when DVARA_DB_MIGRATE=true, which was the default. If your organization runs migrations separately, apply the migration set with the approved release artifact before starting Flightdeck.

Moving to 1.8.2 or later: the Gateway has no database

From 1.8.2 a Gateway pod has no database. It enrols with Flightdeck, reads its configuration from the signed bundle Flightdeck publishes, and spools its audit and usage records to its own volume before shipping them to Flightdeck. Before you upgrade from 1.8.1 or earlier:

1. Remove SPRING_DATASOURCE_* and any bootstrap file from the Gateway. A Gateway given a database refuses to start, and helm upgrade refuses a values file that gives it one through llmGatewayServer.extraEnv. Move a bootstrap file to Flightdeck.
2. Remove dataPlane.serveFromBundle and dataPlane.dbMigrate from your Helm values. Both were removed, and helm upgrade fails while either is set.
3. Give the Gateway Flightdeck's /internal address, the enrolment secret, and a volume for its spool. The Compose example and the Helm chart set these; with secrets.existingSecret, add the key enrolment-shared-secret.

See what moves on upgrade for the full list.

Moving to 1.8.4

1.8.4 fixes governance gaps and adds provider and MCP features. Most of it needs no action. Check these before you upgrade:

Area	What changes in 1.8.4	What to do
A2A delegation chain	Gateways sign a new chain format. A 1.8.3 pod refuses it as a2a_delegation_chain_invalid. A 1.8.4 pod still accepts chains signed before the upgrade until they expire (15 minutes).	Upgrade every Gateway pod in one rollout, and don't run 1.8.3 and 1.8.4 Gateways side by side longer than that.
Delegation signing secret	The key comes from DVARA_A2A_DELEGATION_SIGNING_SECRET, or from DVARA_AUDIT_HMAC_SECRET when that is unset. A secret shorter than 32 bytes, or a placeholder DVARA publishes, now gives no key. A Gateway on a production profile refuses to start; a dev profile logs a warning and runs the guard as off.	Check the secret before rollout. Generate one with openssl rand -base64 32 and set the same value on every Gateway pod.
A2A caller identity	An API key not bound to an agent is no longer named as the last agent of a delegation chain it presents. Policy source: rules then match the key's name, not that agent.	Bind each agent's key to its agent with Acts as agent before you rely on agent identity in A2A policy.
Duplicate routes	Flightdeck refuses a second route for a model pattern. At upgrade it keeps routes that already share a pattern, marks all but the oldest in each group, and lists each group as a warning in the Flightdeck log.	Read the startup log. Give each extra route its own pattern, or delete it.
Agent key bindings	Deleting an API key now deletes its Acts as agent binding. At upgrade Flightdeck deletes the bindings deleted keys had left.	None.
Grounding	An embedding failure now makes the check ungrounded. Under BLOCK the response is refused; LOG and FLAG deliver it and record it.	If your embedding service fails often, expect more refusals under BLOCK. Alert on gateway_grounding_embedding_failures_total.
MCP metrics	mcp_errors_total labels its error_code in lower case (mcp_server_not_found, not MCP_SERVER_NOT_FOUND), and mcp_requests_total gains an error_code label (none when the request was not refused). Refusals from the MCP error handlers are now counted too.	Update MCP dashboards and alerts that match an upper-case code.
MCP errors	An MCP server's own JSON-RPC error is returned as 400 mcp_upstream_rejected or 502 mcp_upstream_error, not 502 mcp_server_unavailable. An unreachable approval store gives 403 mcp_approval_unavailable, not 502.	Update clients that retry on these codes.
Token counts and cost	Anthropic and Bedrock input counts now include cache reads and writes, and Gemini thinking tokens count as output. These calls record more tokens, which is what the provider bills.	Expect higher token counts for those calls. Existing prices cost the same until you set the new rates. Add cached-input, cache-write and reasoning rates on the Pricing page to price them; an empty rate keeps the plain input or output price.
Helm	The chart gives Flightdeck DVARA_ENCRYPTION_MASTER_PASSWORD from the same Secret key as the Gateway, and adds secrets.piiTokenEncryptionMasterPassword for Flightdeck.	Set the PII token password if any workspace uses TOKENIZE. See Kubernetes.

Flightdeck applies the 1.8.4 database migrations at startup. They add the new token and price fields; older usage and cost rows read as zero cached, cache-write and reasoning tokens.

Moving to 1.8.5

1.8.5 lets Claude Code and the Anthropic SDKs call DVARA at /v1/messages, routes A2A push notifications through the Gateway, and makes a session kill stop a session on every plane. Most of it needs no action. Check these before you upgrade:

Area	What changes in 1.8.5	What to do
A2A push notifications	A peer now posts a task's push notification to the Gateway, which checks, scans and audits it before it reaches the workspace's webhook. The Gateway needs its own public URL for this. Until it has one, every push config is refused with 503 a2a_push_not_available, except in a workspace that set a2a.push.delivery=direct.	Set A2A_PUSH_CALLBACK_BASE_URL on the Gateway to the URL peers reach it on. In the Helm chart set llmGatewayServer.a2a.pushCallbackBaseUrl; it is empty by default. See Receive push notifications through DVARA.
A2A peers over http://	A2A peers must be https://. The Flightdeck, the Flightdeck and a GitOps import refuse an active agent whose endpoint is not https://. The Gateway refuses to send a hop, open a stream or fetch an Agent Card for one, with 502 a2a_endpoint_not_https. An agent saved over http:// before 1.8.5 stays as it is: Flightdeck names each active one in a warning at startup, and the agent lists mark it Not HTTPS. A push webhook must be https:// too.	Before you upgrade, move each http:// agent to https://, or disable it. Hops to it fail until you do. DVARA_A2A_ALLOW_PLAINTEXT_ENDPOINTS=true allows http:// on a development profile only, for local stub peers; the production profile ignores it.
Database schema	Flightdeck applies the 1.8.5 database changes at startup. They store the "would refuse" reason on each A2A hop and the may start chains flag on agent keys.	None. Back up the database first, as for any upgrade.
Hardened A2A delegation preset	A workspace, or the fleet with a2a.delegation.preset, can choose the new hardened preset. It requires a chain from agent keys, treats any repeat of an agent as a cycle, and turns on a limit of 200 hops per session. An agent key can be marked may start chains.	None: it is opt-in, and the defaults do not change. To try it, set the delegation mode to observe first and read the "would refuse" marks. See A2A delegation guard.
Parallel A2A calls	Five or more calls from one chain to the same agent and skill are no longer killed as a loop. A session past 60 hops a minute is refused with 429 a2a_session_rate_limited and is not killed.	Update clients that treat a2a_loop_detected as the only 429. During a rolling upgrade, loop checks fall back to each Gateway's own history; finish the upgrade before you rely on them.
Session kills	A kill now stops the session on every plane (model calls, tool calls and A2A hops) and lasts 24 hours, not 75 minutes. A killed session's model calls get 403 session_killed. dvara.internal.deny-list.session-kill-retention replaces session-retention-margin-minutes. Gateways poll the revocation list every 5 seconds on their own key, dvara.data-plane.control-plane.deny-list-poll-interval-ms.	Remove session-retention-margin-minutes. An install that set poll-interval-ms keeps that value for the list until it sets the new key. Where multicast is blocked, list the Gateways in dvara.cluster.members so they share kills at once. See Agentic governance.
MCP tool-call size	A tool call whose arguments are larger than 1 MiB is refused with 413 mcp_arguments_too_large, where it used to be forwarded. Tool results over 4 MiB, or 16 MiB streamed, are refused with 502 mcp_response_too_large.	If a tool needs more, raise dvara.mcp-gateway.limits.max-arguments-bytes or the response limits, for the fleet or for one workspace in the Flightdeck's Size limits section.
Response size limits	A provider response over 64 MiB, or 128 MiB streamed, is refused with 502 provider_response_too_large. An A2A answer over 16 MiB, or 64 MiB streamed, is refused with 502 a2a_response_too_large.	None for normal traffic. Raise a limit only if a real response needs it.
Legacy MCP transport	MCP servers on the legacy HTTP+SSE transport keep working until 2027-07-28 by default. Each use is logged and audited at most once a day per server. From that date a call is refused with 410 mcp_transport_sunset and tool sync fails.	Plan to move those servers to Streamable HTTP. dvara.mcp-gateway.legacy-sse-sunset moves the date.
Usage exports	The monthly usage export and the chargeback CSV add cached-input, cache-write and reasoning token columns at the end. No total changes.	None for readers keyed on column position.
Context window	A known issue limits large gpt-4.1 and Claude Sonnet 5.5 and Opus 5.5 requests.	See Known issues in 1.8.5.

Known issues in 1.8.5

Large requests to gpt-4.1 and Claude Sonnet 5.5 and Opus 5.5 can be refused or trimmed below the model's real window. The context window check uses one limit per provider, 128,000 tokens for OpenAI and 200,000 for Anthropic, not the model's own window. gpt-4.1's window is about 1,047,576 tokens; Claude Sonnet 5.5 and Opus 5.5 have 1,000,000. With the default hard threshold of 90%, a request over about 115,200 estimated tokens to gpt-4.1, or about 180,000 to Claude, is refused with 400 context_window_exceeded. If the workspace sets a pruning strategy, the request is trimmed instead.

Partial workaround, confirmed on 1.8.5-rc1: set the workspace's context Hard Threshold to 100% in the Flightdeck's workspace guardrail settings. That serves requests up to the provider's whole figure, 128,000 or 200,000 tokens. Nothing lifts the limit above it. 1.8.6 fixes this. See Govern the provider context window.

Moving to 1.8.6

1.8.6 changes several user-facing Flightdeck and governance workflows. Review the affected roles and runbooks together rather than treating it as only a Gateway patch.

Area	What changes	What to do
Flightdeck navigation	Platform and workspace roles use one task-oriented application with canonical paths under Access, Traffic, Governance, Cost, Prompts, MCP, Agents, and Operations. Former Flightdeck links redirect.	Update internal runbooks and bookmarks to the canonical paths. Train each role from the navigation it can actually see.
Sensitive governance actions	Policy activation, material budget changes and deletion, audit export, PII detokenization, and PII-token purge use a two-person approval lane. The requester signs in within the previous 10 minutes, another authorized person approves, and the requester executes within 15 minutes.	Assign at least two authorized people before production use. Update emergency and evidence-export runbooks. See Govern sensitive changes with approvals.
Provider credentials	Draft and stored credentials can be tested. Stored tests persist safe health history and audit evidence.	Test important credentials after upgrade and after every rotation. Treat HEALTHY as proof of the probe, not every model or quota.
Workspace deletion	A workspace administrator can schedule deletion. Flightdeck suspends the workspace immediately, shows impact counts and purge date, and allows recovery before purge.	Export configuration and approved audit evidence first. Record the displayed purge date. See Delete and recover a workspace.
Reports	Chargeback and compliance artifacts show Completed for 30 days, then Expired; an expired download returns 410 Gone.	Download within 30 days or regenerate the same reporting window. Do not treat the report row as indefinite artifact storage.
MCP request size	Native POST /mcp has a 4 MiB default whole-body limit. A larger declared or chunked body receives a bare 413 before JSON-RPC processing. Authentication still runs first, and server-scoped REST routes are unchanged.	Raise DVARA_MCP_GATEWAY_LIMITS_MAX_REQUEST_BYTES only for a verified need. Raise it too when a workspace argument limit above 4 MiB must take effect on /mcp; 0 or less disables the protection.
Licensed governed-call reporting	A valid or expired Enterprise licence no longer makes governed-call counting disappear. Flightdeck and the monthly usage report count LLM calls, MCP tool calls, and A2A hops without enforcing a product cap.	Include the report in capacity and commercial reviews. No usage data leaves the installation.

Moving to 1.9.0

1.9.0 is the first release since 1.8.6. It governs coding agents, serves the newest MCP and A2A protocol versions, and signs agent delegation. Most of it needs no action. Check these four things before you upgrade:

Area	What changes in 1.9.0	What to do
A2A refusals	A refused JSON-RPC call to /a2a/* now answers HTTP 200, with the error in the JSON-RPC body, so the official A2A SDKs can read it. A missing, expired or revoked key still gets 401.	Update clients, monitors and alerts that read the HTTP status of an A2A refusal. Read error.code and error.data instead. To keep the old status codes, set a2a.protocol.json-rpc-error-status=refusal. See The HTTP status of a refusal.
Caller tokens sent upstream	Sending a caller's own token on to an MCP server or A2A agent is now a choice you make, and each such call is recorded as pass-through. A DELEGATED server or agent must use token exchange or pass-through. The migration switches existing DELEGATED servers and agents to pass-through, so they keep working.	Review each DELEGATED server and agent. Move it to token exchange where its authorization server supports it. See Exchange a caller's token.
Provider-run tools	Built-in tools that run at the provider, such as web search and code interpreter, are refused on /v1/responses and on the Gemini API at /v1/gemini. DVARA cannot check what they do.	Turn them off in each coding agent. The setup pages show how, for example Codex CLI and Gemini CLI.
Workspace IP rules	A workspace's IP allow and deny lists apply only when IP access is on at the Gateway, with DVARA_LLM_GATEWAY_IP_ACCESS_ENABLED=true. Flightdeck now warns when a workspace saves rules that are not enforced.	If you rely on workspace IP rules, set the variable on every Gateway pod, then check that a blocked address is refused. See Enterprise Gateway settings.

Flightdeck applies database migrations V61 to V81 when it starts. Back up the database first, as for any upgrade.

Use the same version everywhere: the images ghcr.io/dvarahq/dvara-gateway:1.9.0 and ghcr.io/dvarahq/dvara-flightdeck:1.9.0, and the Helm chart oci://ghcr.io/dvarahq/charts/dvara at --version 1.9.0. The Open Source distribution is 1.9.0 too: the image ghcr.io/dvarahq/dvara-gateway-oss:1.9.0, and the jar and Spring Boot starters on Maven Central.

Known limit. Cursor support is a preview. It is tested against the request shapes Cursor publishes, not yet in a live Cursor session. See Cursor (preview).

For the Open Source distribution, replace the runtime artifact with the final version, retain the reviewed gateway.yaml, restart, and inspect the startup validation before admitting traffic. File configuration is read at startup; changing it does not hot-reload.

How do you verify the upgrade?

Run these checks in order:

1. Confirm /actuator/health/readiness is UP and /actuator/info reports the intended 1.8 build on every instance.
2. Call /actuator/gateway-status with the operator key and verify providers, routes, rate limits, region, and configuration state. Do not expect licence fields there.
3. On the Enterprise platform, call /actuator/license and verify the intended posture. Test one MCP and one A2A operation. From 1.8.2 both planes serve with or without a licence.
4. Send one LLM request per scope family with a correctly scoped key. Confirm a deliberately out-of-scope request returns 403.
5. Send the representative PII request and verify whether the provider-bound value is redacted or tokenized exactly as approved. Check the response and the resulting audit evidence.
6. Run an Immediate stream and a Deferred stream. Confirm first-content latency, completion, timeout, and overflow behavior fit the client contract.
7. Verify shared rate limiting from more than one replica. A healthy cache pod alone does not prove the gateway selected it.
8. Check dashboards and alerts for the new licence endpoint, health-detail key, streaming metrics, and removal of gateway_schema_retries_total. Exercise one bounded response and confirm the Prometheus output uses gateway_streaming_enforcement_buffer_utilization_ratio_*. Test alerts for Deferred overflow, Immediate overflow, and incomplete cancellation finalization before accepting production traffic.

Do not approve the rollout from health checks alone. A successful governed call must produce the expected response, audit evidence, and metrics.

What happens when an Enterprise licence expires?

From 1.8.2 an expired licence refuses no traffic. /v1/**, /mcp/** and /a2a/** keep serving after the grace period. Existing workspaces are kept, and a new workspace above 3 is refused. Flightdeck shows the expiry and sends expiry emails. Before 1.8.2, the MCP and A2A planes returned 402 LICENSE_EXPIRED after the grace period.

From 1.8.2 the licence is stored in Flightdeck. On upgrade, Flightdeck copies DVARA_LICENSE_KEY into its store once, when none is stored, and Gateway pods ignore the variable. See Get and apply a license.

Update alerts and runbooks that expect traffic to stop. Read posture and expiry from /actuator/license, not /actuator/gateway-status.

How do you roll back?

Stop the rollout if an authentication, PII, streaming, or configuration check fails. Keep the new version out of service while you decide whether the failure is a configuration migration or an application regression.

For Compose, restore the previous pinned tags and start the stack again. For Helm, use the recorded revision:

helm history dvara --namespace dvara
helm rollback dvara <previous-revision> --namespace dvara
kubectl -n dvara rollout status deploy --timeout=300s

Application rollback does not undo forward database migrations. Rolling back from 1.8.2 or later to 1.8.1 or earlier also means giving Gateway pods their database settings again. Roll back only to a version verified against the migrated schema. Restore the pre-upgrade database backup for a complete data rollback, following your normal recovery procedure.

After rollback, repeat the governed-call checks. A process returning UP is not proof that the previous policy, PII, streaming, and rate-limit behavior has been restored.

What if you run 1.6 or earlier?

Complete the 1.7 migration before applying the 1.8 changes above. The important 1.7 actions remain:

1. Rotate workspace keys that were used before 1.7 and remove old plaintext key values from historical usage and cost records with an approved data maintenance procedure.
2. Re-run audit-chain verification. An older verification failure on an event containing nested structured data can be the corrected canonicalization bug, not proof of tampering; investigate the affected segment.
3. Reset prompt experiments that span the upgrade because their earlier latency, cost, and streaming observations are not comparable.
4. Remove retired standalone MCP and A2A services and send those protocols to the unified Gateway on port 8080.
5. Replace removed administrative CRUD automation with the Flightdeck, Flightdeck, or Flightdeck GitOps export/import. The owner-only signing-public-key endpoint remains.
6. Update integrations from the old tenant naming to workspace naming and account for typed workspace settings taking precedence over legacy metadata.

See Operate DVARA with Flightdeck, GitOps export and import, and Deployment for the current 1.8 operating model.