Move from Portkey Cloud to the open-source Portkey Gateway

The largest cost is the work of moving, not the software, because the Portkey AI Gateway is MIT licensed and carries no license fee to run. Expect one-time costs for planning, translating routing configs and virtual keys into your own setup, testing fallbacks and cutting over applications. Recurring costs include compute for gateway replicas in your VPC or cluster, any shared store you add for state or caching, the logging and tracing backend you choose, and staff time for upgrades and on-call. Costs rise with the number of applications, providers and enterprise features you must replace. In any quote, ask for a written list of components, who pays for each, and how long Portkey Cloud stays active during cutover.

No duration is fixed by the open-source project, so the timeline depends on your scope and should be stated in a written plan. The main drivers are how many applications call Portkey, how many routing configs, fallbacks and virtual keys need mapping, which enterprise features you must replace, where logs must land, and how much testing your change and security processes require. Teams that already run containers and have a logging backend usually move faster than teams building both at once. A staged cutover runs the self-hosted gateway beside Portkey, sends a small share of traffic through it, compares results, then moves the rest. Keep Portkey Cloud active until replacement logging and access controls are verified.

The team needs someone who can deploy a containerized service with Docker or on Kubernetes, manage provider API keys in a secret manager, configure network egress and ingress, and connect metrics, traces and logs to your existing stack. Application engineers must update base URLs, headers and model names, then test fallback behavior by forcing failures on purpose. Security must review where keys, prompts and logs are stored and who can read them. Assign a named owner for upgrades, since you now carry that work, and another for the enterprise features you replace, such as prompt versions and caching, which now live in your systems. Without clear owners, the gateway tends to drift from the configuration that Portkey used to hold.

A small gateway with few routes is often within reach of an experienced platform team, but the answer depends on your skills and how much of the replacement is custom. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask any provider to split the work into gateway setup, feature replacement, logging, key migration, testing and documentation, so you can see which parts your team keeps.

The open-source gateway keeps the core routing layer, so most of the work is replacing the enterprise features that sit outside it. Portkey's repository lists prompt management, semantic caching, advanced logging and tracing, access control and PII redaction as enterprise features. The core routing features in this migration path are fallbacks, retries, load balancing and simple caching, which you should confirm against the Portkey AI Gateway repository for your version. Prompt management moves to a versioned store you control, and semantic caching needs its own store and threshold tuning. Logging moves to your tracing stack, while access control and PII redaction need your own identity and filtering controls. Check guardrails feature by feature, because Portkey's guardrail tiers depend on plan.

It depends on the deployment model you leave behind. In Portkey's hybrid model, the gateway runs in your VPC while the control plane stays in Portkey's VPC, and the gateway calls out over HTTPS to control.portkey.ai, as described in the hybrid deployment documentation. Running only the open-source gateway means you define configuration, keys and logs yourself, so routing no longer depends on a Portkey control plane. Confirm this in your environment rather than relying on the description alone. Block egress to control.portkey.ai in a test environment, replay your full set of request types, and check that nothing fails or sends data out. Also review any SDK, header or client setting that still points at Portkey.

Yes. The gateway holds provider API keys, sees prompts and responses, and writes logs, so your review must cover where each of these lives, who can read them and how keys rotate. Store provider keys in a secret manager, restrict network paths to model providers, and protect logs at rest and in transit. Your current Portkey vendor assessment covered a third party that handled routing data, so the new review shifts that scope to your own controls and operating procedures. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments, so ask them early which evidence they will expect.