Migrate from Portkey to DVARA.
Move the controls, not just the traffic.

Move one workload in six steps

Pick a workload that represents production: include its real model, streaming mode, tools, structured output and failure cases.

1. 1

   Write down the current contract

   Record the endpoints, models, Portkey-specific headers, API and virtual keys, Config IDs, routing rules, limits, guardrails and metadata in use. Save representative successful and failed responses for comparison.

2. 2

   Choose the DVARA operating model

   DVARA Open Source provides a file-configured LLM data plane. The Enterprise platform adds Flightdeck, central persistence, workspaces and managed governance workflows. Deploy the shape you intend to operate after the test.

3. 3

   Rebuild controls and replace credentials

   Add provider credentials, create new DVARA keys, preserve only the public model names clients need, and rebuild routes, limits and governance controls. In a multi-workspace deployment, set DVARA_LLM_GATEWAY_REQUIRE_API_KEY=true; it is false by default.

4. 4

   Send one complete governed request

   A Portkey call can carry provider credentials plus Portkey headers for the account and Gateway Config. The DVARA call uses the DVARA host and bearer key; do not forward those old headers.

   Before — Portkey

   curl https://api.portkey.ai/v1/chat/completions \
     -H 'Authorization: Bearer <provider-api-key>' \
     -H 'x-portkey-api-key: <portkey-api-key>' \
     -H 'x-portkey-config: <portkey-config-id>' \
     -H 'Content-Type: application/json' \
     -d '{
       "model": "gpt-4o-mini",
       "messages": [{
         "role": "user",
         "content": "Summarize the refund policy."
       }],
       "temperature": 0
     }'

   After — DVARA

   curl https://<your-dvara-host>/v1/chat/completions \
     -H 'Authorization: Bearer <your-dvara-key>' \
     -H 'Content-Type: application/json' \
     -d '{
       "model": "gpt-4o-mini",
       "messages": [{
         "role": "user",
         "content": "Summarize the refund policy."
       }],
       "temperature": 0
     }'

   A representative successful response looks like this:

   {
     "id": "chatcmpl-01JQ4P8F6A2M9K7W3T5Y",
     "object": "chat.completion",
     "model": "gpt-4o-mini",
     "choices": [{
       "index": 0,
       "message": {
         "role": "assistant",
         "content": "Refunds are available within 30 days."
       },
       "finish_reason": "stop"
     }],
     "usage": {
       "prompt_tokens": 16,
       "completion_tokens": 9,
       "total_tokens": 25
     }
   }

   In the Enterprise platform, confirm the request under the expected workspace in Flightdeck. In Open Source, confirm it in the audit sink you configured. Check the provider, policy outcome, status and token usage.

5. 5

   Test the paths that expose differences

   Test non-streaming and streaming calls, tool use, structured output, bad keys, unknown models, limit boundaries, policy denials, provider errors and failover. Compare response shape, status, token accounting, latency and the evidence recorded.

6. 6

   Cut over in stages

   Put the Portkey and DVARA URL/key pairs behind runtime configuration. Move one workload, watch the agreed error, latency, cost and denial thresholds, then expand. Keep Portkey available until the acceptance window is complete.