Skip to main content
For teams switching from Portkey

Moving OpenAI-compatible traffic from Portkey to DVARA.
What transfers, what does not, and how to check.

DVARA is an AI governance platform you run yourself. For a plain OpenAI-SDK path the client change is a base URL and a key — but your Portkey configuration does not come with it, and streaming, tool calls, structured outputs and error handling all need testing. This page is that sequence, and what waits on the other side.

How does DVARA compare with Portkey?

Five things that matter when you swap your AI gateway. Every Portkey claim below is sourced from portkey.ai/pricing and portkey.ai/docs. We update this page when Portkey's pricing or feature set changes.

DVARAPortkey
Where it runsSoftware you deploy and operate yourself — the gateway and console run in your own environment, against your own database.A hosted service, with a self-hosted option on their enterprise plan, per Portkey documentation.

For the full feature-by-feature head-to-head, see our DVARA vs Portkey comparison.

How do you migrate from Portkey?

For a plain OpenAI-SDK path the client change is small. The work is standing up the gateway you are pointing at, and then proving the paths your application actually uses still behave the same.

  1. 1

    Inventory what you rely on today

    Which endpoints, models and providers you call; whether you stream; whether you use tools or structured outputs; which headers you send; and which Portkey-specific features are in the path. None of that configuration transfers, so the list is what tells you how big the migration actually is.

    Capture a set of representative requests and their responses now. They are what you will compare against.

  2. 2

    Run a DVARA deployment to test against

    DVARA is software you operate — the gateway and console run in your environment, against your own database. The public images boot with no licence key, which is enough to exercise the compatibility surface; the governance engines need a licence.

  3. 3

    Add provider credentials, then repoint the SDK

    Register your provider keys in the console, then change the base URL and key in your client. Keep both in configuration rather than hardcoded — it is what makes step five reversible.

    Before — Portkey
    from openai import OpenAI
    
    client = OpenAI(
        base_url=os.environ["LLM_BASE_URL"],
        api_key=os.environ["LLM_API_KEY"],
    )
    After — your DVARA gateway
    # LLM_BASE_URL=http://localhost:8080/v1
    # LLM_API_KEY=gw_...
    #
    # Same code. Only the two environment
    # variables change — which is also how
    # you change them back.

    localhost:8080 is the gateway's documented port; substitute whatever host you deployed it to.

  4. 4

    Replay your representative requests and compare

    Response shape, status codes, token counts, and the behaviour of the paths that are easiest to get wrong: streaming, tool calls, structured outputs, an unknown model, a missing key, and whatever your retry logic does when a provider errors.

    Differences are not necessarily faults — a provider that cannot honour strict structured output is reported rather than hidden, for instance. Decide which differences you accept.

  5. 5

    Move a slice, then the rest — and keep the way back

    Cut over one workload before all of them. Rollback is setting the two environment variables back to what they were, which is only true while they stay configuration.

    Turn on the governance you actually need once traffic is steady. Doing it in the same change as the cutover means a policy denial and a compatibility problem look identical.

Running agents? The MCP Gateway is a separate plane.

Tool calls are governed by the DVARA MCP Gateway — a governance plane inside the gateway you already run, not a separate service to deploy. A licence activates it; without one the paths are simply not registered. It is the same governance model applied to tool calls rather than model calls. What it adds: policy on the tool call and its arguments, approval gates, loop detection, a session kill switch, and tool calls correlated with the model turns above them.

How MCP governance works

Common questions about migrating from Portkey

Is a code change required?

For a plain OpenAI-SDK path, the change is the base URL and the key. That is the starting point, not the finish line: headers you were sending to Portkey, provider-specific parameters, model aliases, retry and fallback behaviour, error codes, and anything using a Portkey-specific feature all need checking against your own tests. Treat a successful first request as a hypothesis to verify, not as proof the migration is done.

Which API surfaces does DVARA expose?

The OpenAI shapes: chat completions, embeddings, models, the Responses API, and the Batch API with files. Streaming works over SSE, and structured outputs are translated to whatever each provider natively implements — with a header telling you when a provider could not do strict mode. Test the paths your application actually uses rather than assuming parity across all of them.

Where do I point the SDK?

At your own deployment. DVARA is software you run: the gateway listens on port 8080 and the console on 8090, in whatever environment you deploy them to. There is no DVARA-hosted endpoint to migrate to — if you are moving off a hosted service, that is the substantive difference, and it means the migration includes standing up and operating the gateway.

What happens to my Portkey configuration?

It does not transfer. Routing rules, guardrail configuration, prompt templates, virtual keys and observability settings are Portkey concepts with their own shapes; the equivalent DVARA configuration is authored separately. Inventory what you rely on there before you start, because a base-URL change carries none of it across.

Can I keep using my own provider keys?

Yes — you bring your own keys and they stay in your deployment. Credentials resolve per workspace first, then a platform default, then a vault, then the environment, and strict BYOK refuses the platform fallback so a workspace can only spend its own key.

How do I roll back?

Point the base URL and key back at what you were using before. Because the change is client-side configuration, rollback is the same operation in reverse — which is a good reason to make the switch through configuration rather than by hardcoding a URL.

What governance do I get once traffic routes through it?

On the paths you configure: policy evaluation, PII detection, guardrails, budgets and a signed audit record. All of it runs without a licence key — what a licence adds is governance for MCP tool calls and A2A agent hops. The catch is not the licence but the configuration: each engine has a default, and the defaults are permissive — PII and guardrails log rather than block, and budgets do nothing until you set a cap.

How does the pricing compare with Portkey?

Portkey publishes a subscription starting at $49 per month plus per-request overage above the included quota, sourced from portkey.ai/pricing. DVARA does not publish a figure: a licence is sized by request volume, going over that volume does not stop your traffic, and the number comes from a conversation. Compare them on your own volumes rather than on the headline.

Can I evaluate it before buying?

Two ways. The gateway and console run from public images with no licence key and no account, which covers the compatibility surface — the paths this page tells you to test. A 30-day trial licence unlocks every feature for evaluation, and you request it by booking a slot or emailing support — see the licensing docs for what it covers.

Test one path before you move the rest.

A base-URL change is a hypothesis. Replay your own requests against a deployment you control, compare what comes back, and move the rest once the differences are ones you accept.

Last updated