Migrate from Portkey to Kong AI Gateway

Migrate from Portkey to Kong AI Gateway: what the move involves

Moving from Portkey to Kong AI Gateway is a platform decision that a platform or API team can carry out with a security reviewer, provided the team treats it as three pieces of work: gateway configuration, application cutover and rebuilding logging. Many teams look at this move because they already run Kong Gateway for APIs and want model routing governed by the same tooling, policies and operating model. The effort depends less on the number of applications than on how many Portkey features the current setup relies on, especially virtual keys, fallbacks, load balancing and hosted logs. Confirm the scope of each of those with your own inventory before estimating anything.

Gateway configuration is where the mapping happens. Portkey configs, virtual keys and fallback rules have to be translated into Kong services, routes and plugin settings, and the AI Proxy plugin must be configured for each provider your applications call. Check the plugin's supported providers and request types against your model list early, because some features depend on specific Kong Gateway versions, which the AI Proxy plugin documentation sets out. Load balancing across models and semantic routing sit in AI Proxy Advanced, which the documentation places in the Enterprise offering, so decide whether that tier is required before you design the routing rules. Note that the provider credentials will move from Portkey to your own secret store.

Application cutover and logging come last, and they carry the most operational risk. Applications that call Portkey's endpoint need their base URL and keys changed in a controlled sequence, with a rollback path kept until the new routes have handled production traffic. Hosted Portkey logs do not move automatically, so the team must decide where request logs, cost data and traces will live after the switch and confirm that each destination meets the data handling rules that applied to Portkey. Reviewers should also confirm the network path: Portkey's hybrid model keeps its control plane at control.portkey.ai and the gateway calls out to it over HTTPS, so many teams review this move specifically to confirm that the new gateway and its logs stay inside their own network boundary.

Which Portkey features map to Kong, and which need rework

This table maps Portkey gateway capabilities to Kong Gateway equivalents and marks each as clean, needs rework, or gap. Read the migration note alongside the tier: the Apache-2.0 gateway covers basic AI Proxy routing, while multi-model load balancing and semantic routing require Kong AI Gateway Enterprise. Confirm the exact plugin behavior for your Kong release before you commit to a cutover plan.

Portkey capability	Kong equivalent	Migration note
Provider routing to OpenAI, Azure OpenAI, Amazon Bedrock, Anthropic and Gemini	AI Proxy plugin in Kong Gateway (open source)	Clean. Each provider is set up as a route or plugin config with its own credentials, so confirm model names and auth per provider.
Provider routing to Vertex AI, Cohere, Mistral, Hugging Face, Ollama and vLLM	AI Proxy plugin in Kong Gateway (open source)	Clean for listed providers. Check the current provider list in the AI Proxy docs before cutover, since coverage changes between releases.
Request types: chat, completions, embeddings, files, batches	AI Proxy request type handling	Clean for chat and embeddings. Test batches and files against your own traffic, because your applications may depend on Portkey-specific paths.
Assistants, responses, audio, image and video generation	AI Proxy request type handling	Needs rework. Confirm each request type your apps use is supported in your Kong version (some features need 3.10 or 3.11).
Virtual keys and per-team access	Kong consumers, key-auth or other auth plugins, route-level rules	Needs rework. Portkey virtual keys hide provider credentials. In Kong you map each key to a consumer and move provider secrets into plugin config.
Fallbacks and retries	AI Proxy with route-level configuration; advanced priority routing in AI Proxy Advanced	Needs rework. Basic failover patterns must be rebuilt as Kong config and tested for each provider.
Load balancing across models	AI Proxy Advanced (round-robin, least-connections, lowest-latency, priority and others)	Gap in the open-source tier. AI Proxy Advanced is documented for Kong AI Gateway Enterprise, so budget for that license or keep Portkey for this feature.
Semantic routing of prompts to models	AI Proxy Advanced semantic balancing	Gap in the open-source tier. Requires Kong AI Gateway Enterprise, so confirm licensing before you plan around it.
Prompt management and versioned templates	No equivalent in Kong Gateway	Gap. Use a separate prompt tool such as Langfuse alongside the gateway, and move templates out of Portkey before cutover.
Semantic caching	No built-in equivalent in the open-source gateway	Gap. Portkey lists semantic caching as an enterprise feature. Plan a separate cache layer or confirm Kong options with the vendor.
PII redaction and guardrails	Kong plugins for request checks; PII handling depends on your chosen tooling	Needs rework. Portkey guardrails and PII redaction need separate open-source checks run beside Kong, and their behavior must be tested.

Which Kong tier replaces which Portkey feature

The Apache-2.0 Kong Gateway is the starting point for most teams that want to run LLM routing in their own infrastructure without an enterprise contract. Its AI Proxy plugin covers the core request path: a single gateway route can send chat completions, embeddings and other request types to supported providers, including OpenAI, Azure OpenAI, Amazon Bedrock, Anthropic, Gemini, Vertex AI, Cohere, Mistral, Hugging Face, Ollama and vLLM. Kong Gateway 3.6 or later is required for the plugin, and some features need 3.10 or 3.11.

Provider routing: Map each Portkey virtual key to a Kong route and a plugin configuration that holds the provider credentials, so applications keep calling one endpoint.
Request types: Confirm that the request types you use, such as embeddings, files or audio, are supported on the plugin version you deploy.
Deployment modes: Kong can run DB-less, in hybrid mode with separate control and data planes, or backed by PostgreSQL, so the gateway can stay entirely inside your network.
Not included: Multi-model load balancing and semantic routing are documented as Enterprise features in AI Proxy Advanced, so Portkey's advanced fallback and routing logic needs a different design here.
Logging and enterprise features: Plan your own logging pipeline and access controls, since Portkey's hosted logs and enterprise governance features do not carry over automatically.

Before planning, confirm with Kong which plugin features and entitlements apply to the open-source edition you intend to run, and check the release notes for the version you select.

What data and integrations move, and what you rebuild

Moving from Portkey to Kong AI Gateway is less a data copy than a rebuild of routing, credentials and observability on Kong's model. The cards below separate what you port by hand, what you pull out of Portkey before cutover, and what the open-source edition does not provide, so you can scope the work before anyone changes a production base URL.

Portkey configs rebuilt as Kong config

Portkey routes, virtual keys and fallback chains do not import into Kong as-is. You rebuild them as Kong routes and services, with the AI Proxy plugin attached to each route to define the target provider and model. Fallback behavior in the open-source plugin is limited, so map each Portkey fallback to a documented Kong pattern and test it with a forced provider failure. Ask Kong and your team to confirm which fallback behaviors AI Proxy supports in your chosen release line.

Provider credentials moved to a secrets store

Provider API keys held in Portkey's virtual key vault must be re-issued from each provider and stored in your own secrets manager. Kong references these credentials from plugin configuration, so the Kong side should pull them from a store your security team already audits rather than from a config file in source control. Record which key belongs to which route and which environment, because a mismatched key is the most common cause of failed cutovers.

Historical logs exported before cutover

Portkey's own log export is a separate step from the gateway change, and this page does not confirm its formats, field selection or volume limits. Before cutover, ask Portkey which export options your plan includes and what retention applies to your account. Store the exported history in your own archive so audits and cost reviews can still reach it after the Portkey subscription ends.

Application base URL and key changes

Each application that calls Portkey must change its base URL to the Kong proxy address and switch to a key Kong accepts. If applications send Portkey-specific headers for routing or metadata, those headers have no effect in Kong and must be replaced with route matching or plugin settings. Inventory every service that uses the Portkey SDK, including batch jobs and internal tools, because these are the calls most often missed.

Logging and metrics destinations rebuilt

Portkey's hosted logs and dashboards do not carry over, so Kong's logging and metrics outputs must be configured to feed your own observability stack. Decide where prompts, token counts and provider errors should land, and confirm whether prompt content is stored at all before you enable any logging plugin. Set retention and access rules in the destination store, not in Kong, since the gateway does not manage them for you.

Identity and SSO are not in the open-source edition

Portkey's access controls and team permissions must be replaced, and the open-source Kong Gateway does not provide the enterprise access controls that govern who can change AI routes. Plan for admin access to Kong through your existing identity provider and infrastructure controls, and confirm with Kong which enterprise features, including role-based administration, would be required for your governance model. Treat this as a scoping decision before cutover.

Migration sequence from inventory to decommission

This sequence moves LLM traffic from Portkey to Kong AI Gateway one application at a time, with evidence at each stage so the team can prove parity, roll back safely and retire Portkey without losing its log history.

Inventory Portkey configs, keys and consuming apps
The platform team exports every Portkey config, virtual key, provider connection, fallback and retry rule, and lists each application and service that sends requests through the gateway. Application owners confirm which models, request types and streaming behavior they rely on. The output is a mapping sheet that pairs each Portkey config element with its planned Kong equivalent, such as a route, a consumer, an AI Proxy plugin setting or a fallback definition, and marks anything with no equivalent for a decision. The step is done when every consuming application has an owner and a mapped route.
Pilot a Kong data plane on one non-critical app
The team deploys a Kong Gateway data plane in its own environment, with the AI Proxy plugin configured for the providers in the mapping sheet. Pick a non-critical application to route first and confirm the Kong release line and deployment mode against the official releases and plugin documentation before you commit. Test chat completions, streaming, embeddings and the fallback path by forcing a provider error. The output is a tested AI Proxy route and a written record of how fallback behaves, including any request type or option that the open-source plugin does not cover.
Run Portkey and Kong in parallel
Keep Portkey serving production while Kong receives mirrored or split traffic for the same applications. Compare response latency, error rates and token-level cost estimates from both paths over a window the team sets with its application owners. Check that responses are equivalent for the prompts that matter, and record every case where Kong returns a different error or fails over to a different model. The output is a comparison report with latency, error and cost data for each route, signed off by the application owner. Do not cut over any application until its report shows no unexplained differences.
Cut over by application with a rollback path
Move applications to Kong one at a time, starting with the lowest-risk, and change only the endpoint and key they use. Keep the Portkey route and its keys active until the cutover is confirmed, so the team can switch back by restoring the previous endpoint. Document the change window, the owner, the rollback steps and the checks that confirm success. The output is a signed-off change record for each application, stored with the mapping sheet and the parallel-run report. Applications that depend on Portkey-only features stay on Portkey or move to a replacement decision recorded in the sheet.
Archive logs and decommission Portkey
Before turning off Portkey, export the logs and configuration records your audit and incident processes need, and confirm that the archive is readable and stored under your retention rules. Check your Portkey plan for the export options it provides, and confirm what history is available with Portkey. Once every application is on Kong and the archive is verified, revoke Portkey keys, disconnect the hybrid data plane if you ran one, and close the account according to your contract. The output is retained evidence: the archived logs, the mapping sheet, the comparison reports, the signed change records and the decommission confirmation.

What drives cost and duration in this migration

This table lists the factors that move the cost and timing of moving LLM traffic from Portkey to Kong AI Gateway, and how to keep each one under control. Read it as a checklist for scoping: the first column names the driver, the second explains why it changes effort, and the third gives the practical lever. The main takeaway is that the Kong open-source gateway carries little license cost, so most of the effort sits in application cutover, logging and reviews.

Driver	Why it moves cost or time	How to keep it down
Number of applications calling Portkey	Each application that embeds a Portkey base URL, headers or SDK call needs a change and a test pass, so the count sets most of the cutover work.	Inventory every caller first, then move them in groups. Where possible, keep an OpenAI-compatible request shape so applications change only the base URL.
Number of providers and virtual keys	Each provider credential, Portkey virtual key and its budget or access rule must map to a Kong route, plugin configuration and consumer or secret. Many keys mean more mapping and more checks.	Export the Portkey config inventory, consolidate duplicate keys, and decide early which keys become Kong consumers and which move to a secrets store.
Whether Kong already runs for APIs	If Kong already fronts your APIs, the gateway, admin process, plugin standards and on-call runbooks exist, so the new work is limited to AI routes. A new Kong estate adds installation, hardening and operating setup.	Ask the team to confirm current Kong version, deployment mode (DB-less, hybrid or PostgreSQL-backed) and whom they already run it for before estimating scope.
AI Proxy Advanced or other Enterprise features	AI Proxy Advanced, which adds multi-model load balancing and semantic routing, is documented as Kong AI Gateway Enterprise only. Requiring it moves the work from open-source configuration to a license purchase and its review.	List which Portkey fallbacks, load balancing and guardrails are in use. Confirm which can be met with basic AI Proxy routing and fallback logic before requesting an Enterprise quote.
Logging and observability rebuild	Portkey hosted logs and dashboards do not carry over. Teams must choose a destination, add tracing or metrics, rebuild cost and usage views, and set retention. This is often the largest unplanned item.	Decide the log destination before cutover. Use the observability stack already approved in your environment, and ask the vendor or integrator to confirm which fields Kong's logging plugins emit.
Data residency and hybrid-to-self-hosted reviews	Moving from Portkey's hybrid model, where the control plane sits at control.portkey.ai, to a gateway you run fully yourself changes the data flow. Security, privacy and architecture reviews must re-approve where prompts, logs and keys live.	Prepare a data flow diagram and a list of data categories before the review. Ask your reviewers which evidence they expect and map each Kong component to it.
Operating work of patching and upgrading Kong	Kong open-source releases follow the 3.9 line, with 3.9.4 published on October 12, 2026 per the Kong GitHub releases page. Each upgrade, plugin change and certificate rotation is recurring work your team or integrator performs.	Set a patch cadence, pin versions, test plugin compatibility in staging, and ask any integrator for a written scope covering upgrades, backups and support hours.
One-time versus recurring cost	One-time items include discovery, configuration mapping, cutover testing and logging setup. Recurring items include infrastructure, Kong upgrades, log storage and any Kong Enterprise subscription.	When requesting a quote, ask for one-time and recurring costs as separate lines, and state which features are assumed to be open-source only or Enterprise.

What usually goes wrong in a Portkey to Kong move

Most failed gateway migrations do not fail on the first request. They fail when a feature that was quietly working in Portkey turns out to be absent, licensed differently or unmonitored in Kong. The cards below cover the risks we see most often and a concrete check for each before traffic moves.

Assuming open-source includes advanced routing

Teams often expect the Apache-2.0 gateway to balance load across models or route prompts by meaning. The basic AI Proxy plugin does not do this. Multi-model load balancing and semantic routing sit in AI Proxy Advanced, which is documented as Kong AI Gateway Enterprise and needs Kong Gateway 3.8 or later. Before design sign-off, list every Portkey routing rule and mark each one as open-source or Enterprise.

Losing fallback behavior at cutover

Portkey fallback rules often live in a config object that applications never see. When that logic is rebuilt as Kong routes, a provider outage can return errors where Portkey used to retry on a second model. Run a scripted test that disables the primary provider key in staging and confirm the request reaches the secondary model with the same response shape.

Missing keys and budgets applications relied on

Portkey virtual keys and per-key budgets can stop a runaway team before the invoice arrives. Those limits do not carry over automatically. Inventory every virtual key, its owning team and its budget, then decide which Kong consumer, rate limit or upstream quota replaces each one. Applications that send traffic through a key with no replacement will fail or, worse, run without any cap.

Logs going dark after Portkey is removed

Portkey records requests, tokens and costs in its own console, so turning off the account removes the history the security and finance teams use. Kong's open-source logging is separate from Portkey's dashboards and must be wired to a destination you run. Before decommissioning, export the Portkey history you need, then confirm that a test request appears in your chosen log store with token counts and the consumer name.

Provider credential sprawl

During migration, provider API keys often get copied into Kong plugin configuration, application environment files and CI variables at the same time. The result is several live copies of each OpenAI or Anthropic secret, each rotated differently. Pick one secret store as the source, reference credentials from it, and record which systems hold each provider key so a rotation does not miss one.

Version drift between Kong releases

Kong's open-source line moves through minor releases, and AI plugin features depend on specific minimum versions, such as 3.6 for AI Proxy and 3.10 or 3.11 for some features. A cluster upgraded in one data plane but not another can route the same request differently. Pin one Kong version across all data planes, check the release notes against each AI plugin feature you use, and test the upgrade path in staging first.

How the move differs by starting point

If your organization already operates Kong Gateway for APIs, most of the platform work is already done. You can add AI Proxy routes to the data plane you run today, reuse your existing authentication plugins, and keep the same operating model for upgrades and certificates. The work shifts to LLM-specific configuration: provider credentials, model routing, and how applications address each route.

Reuse the data plane: Add AI Proxy routes to existing Kong services instead of standing up a new gateway tier.
Reuse access controls: Check whether the consumer and key authentication you already enforce on APIs can front LLM routes, then map Portkey virtual keys onto it.
Reconcile versions: Confirm your running Kong version meets the AI Proxy minimum of 3.6, and that any feature you need is available in your release line.
Plan the Enterprise decision: Multi-model load balancing and semantic routing in AI Proxy Advanced need Kong AI Gateway Enterprise, so decide early whether you need them.
Extend your observability: Route LLM logs into the telemetry pipeline you already run rather than building a second one.

Before cutover, confirm with Kong which AI Proxy features your installed version supports and that your existing gateway change process covers LLM routes.

Questions buyers ask before moving from Portkey to Kong

What does a migration from Portkey to Kong AI Gateway cost?

The cost has two parts: software licensing and the labor to implement, and the split depends on which Kong tier you need. The open-source Kong Gateway is Apache-2.0 licensed, so its software carries no license fee, but multi-model load balancing and semantic routing sit in AI Proxy Advanced, which is documented as available only in Kong's AI Gateway Enterprise offering. One-time costs include mapping Portkey configs, building routes and testing fallbacks. Recurring costs include compute, PostgreSQL or a DB-less deployment, log storage, and upgrades. Ask any quote to separate the one-time work from the recurring operating costs, and to state which AI Proxy features are assumed to need an Enterprise subscription.

How long does a Portkey to Kong migration take?

Duration depends on how many applications call Portkey, how many virtual keys, budgets and fallback chains exist, and whether Kong already runs in your estate. Teams that already operate Kong for APIs usually have the platform skills in place, which shortens the work. Teams starting from zero need time for hosting, networking, secrets and observability. Scope the work by counting applications, providers, routing rules and logging destinations, then ask for a timeline tied to a written scope. DeployOpen agrees scope, deliverables and timelines in writing before work starts.

Does the open-source Kong gateway cover what Portkey does?

Partly. The Apache-2.0 Kong Gateway covers proxying, routing, load balancing and health checking, and the AI Proxy plugin handles chat completions, embeddings, files, batches and other request types across providers such as OpenAI, Azure OpenAI, Amazon Bedrock, Anthropic, Gemini, Ollama and vLLM. AI Proxy requires Kong Gateway 3.6 or later, with some features needing 3.10 or 3.11. The gaps to check are:

Multi-model load balancing and semantic routing, which sit in AI Proxy Advanced under Enterprise.
Portkey's hosted logs, prompt management and access controls, which need a separate logging and key design.
Any Portkey feature your team uses that is not in the list above.

Map each Portkey feature you rely on against these tiers before you commit.

What does the migration need from our engineering team?

Your team provides knowledge of the applications calling Portkey, access to the Portkey configs and virtual keys, owners who approve cutover, and an environment where Kong can run, whether DB-less, in hybrid mode or backed by PostgreSQL. Security and platform staff need to approve where the gateway runs, how provider credentials are stored, and how traffic is logged. Plan for named reviewers during testing, since each application must switch its endpoint and be checked against fallback behavior. Ask the provider to list these inputs in the written scope so gaps are visible before work starts.

Can our team migrate to Kong without outside help?

Yes, if your team already runs Kong or has engineers comfortable with declarative configuration, PostgreSQL or Kubernetes, and can own the work after cutover. The Kong Gateway source is publicly available and the Kubernetes Ingress Controller is an option, so an in-house build is realistic for a small estate. Teams without those skills, or with many applications and strict compliance evidence needs, often bring in an implementation partner for scoping, hardening, documentation and cutover testing. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms inside your own infrastructure under a fixed scope.

What happens to our historical Portkey logs after the switch?

Portkey logs stay in Portkey unless you export them, and new traffic going through Kong is logged wherever you configure Kong to send it. Plan the export before cutover, because Portkey's log export is an Enterprise feature with job limits, so confirm the current limits with Portkey. Decide whether you need historical logs for audit, cost review or incident work, then set retention in your own store. Ask the provider to specify the log destination, retention period and access controls in writing.

How DeployOpen scopes and runs the Portkey to Kong migration

DeployOpen, a Chainscore Labs company, plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For this migration, we start from a written scope that maps your current Portkey configs, virtual keys and fallbacks to Kong routes and AI Proxy, then build and hand over the result in your environment.

How we scope

We inventory Portkey configs, virtual keys, fallbacks and the applications that call the gateway today.
We confirm which Portkey features your teams use and which need Kong Enterprise or another replacement.
We agree deliverables, timelines and responsibilities in writing before any migration work begins.

How we build

We deploy Kong Gateway in your environment, set up routes and AI Proxy configuration, and keep provider credentials in your secret store.
We test each application's cutover path, including fallback behavior, error handling and streaming responses, before traffic moves.
We wire request logging to your chosen observability stack and confirm the fields you need are captured after the switch.

How we hand over

We document the route mapping, key handling, configuration and runbooks so your platform team can operate the gateway.
We provide a cutover checklist and a rollback plan for each application, agreed with your owners.
We walk your engineers through the deployed setup and the feature gaps that remain between Portkey and the open-source tier.

How we support

Ongoing support, upgrades and continuous testing of the gateway are available as a retainer.
A retainer can cover Kong version upgrades, plugin configuration changes and periodic security testing of the AI endpoints.
Quotes follow from the written scope, so ask us to confirm which support tasks are included.

Migrate from Portkey to Kong AI Gateway