Which fits your team: OpenRouter or a self-hosted Portkey gateway?
If a renewal, a platform fee or a data control requirement is pushing you off OpenRouter, the question is whether your team wants a hosted router or a gateway it runs itself. OpenRouter fits teams that want one hosted API across many models and providers, have no appetite to run infrastructure, and accept that prompts and routing pass through a third-party service. It also suits teams that prefer to let someone else carry the uptime, upgrades and provider account administration. Choose it when the platform fee is an acceptable price for that simplicity and when your data rules allow a hosted intermediary.
A self-hosted Portkey gateway fits teams whose routing must stay inside their own VPC or cluster. Portkey's MIT-licensed gateway can run with npx, Docker, Node.js, Cloudflare Workers or Kubernetes, and it provides automatic retries, fallbacks, load balancing and conditional routing through JSON configs attached to the client. Confirm with Portkey which of these deployment paths your security team accepts. Note that Portkey's hybrid deployment, which keeps the gateway in your VPC while the control plane stays with Portkey, still sends calls to control.portkey.ai over HTTPS, so it is a different control posture from a fully local gateway.
The decision turns on three things. First, where logs and keys must live: the open-source gateway leaves logging, dashboards and access control to you, and features such as advanced logging and tracing, PII redaction, semantic caching and role-based key management are listed by Portkey as enterprise features outside the open-source gateway. Second, who runs the service: someone must own upgrades, scaling and incident response, and that person's time is the largest recurring cost. Third, which Portkey features you need. If your team depends on those enterprise capabilities, price them in writing before you assume the self-hosted route is cheaper, and ask Portkey directly what its Gateway 2.0 pre-release will change for open-source users.
Which option fits which scenario
This table compares OpenRouter with Portkey's open-source gateway across common team situations, naming the better fit and the condition that would change the answer. Read each row against your own staffing, data rules and provider contracts before deciding.
| Scenario | Better fit and reason | When the preferred option stops fitting |
|---|---|---|
| Small team with no platform staff | OpenRouter, because it is a hosted service with no gateway to run, patch or scale. Portkey's open-source gateway can start locally with npx on port 8787, but you would still own its hosting and logging. | When usage or compliance needs grow and someone must run the gateway, its logs and its keys as a service. Then confirm who on staff will own that work. |
| Regulated team that must keep prompts inside its VPC | Portkey's open-source gateway, deployed in your own infrastructure with Docker or Kubernetes. OpenRouter routes prompts through its hosted service, which is outside your network boundary. | If you adopt Portkey hybrid deployment, the gateway stays in your VPC but calls control.portkey.ai over HTTPS, so confirm that the control plane traffic meets your data rules. |
| Team needing semantic caching or enterprise access control | Portkey's enterprise deployment, because the open-source gateway does not include semantic caching, PII redaction, or role-based key management. Those features are listed as enterprise features outside the open-source gateway. | If your needs stop at simple routing and retries, the open-source gateway covers them. Ask Portkey which features are included in your plan before signing. |
| Team needing many provider accounts under its own contracts | Portkey's open-source gateway, because you configure your own provider keys and route requests through JSON configs. OpenRouter holds the provider relationship for you and bills through its platform. | When you need a central record of spend per team, key or budget. The open-source gateway does not provide that by itself, so you must add a spend store and reporting. |
| Team already on LiteLLM | Stay on LiteLLM unless you have a specific need Portkey covers. LiteLLM already provides virtual keys, budgets, fallbacks and Prometheus logging, and Portkey publishes a migration skill if you decide to switch. | If LiteLLM's operational load on PostgreSQL and Redis becomes too heavy for your team, or you need the routing and guardrail features Portkey adds. Then evaluate a migration with the published skill. |
| Team needing observability for LLM calls | Neither gateway covers full tracing by default. Pair either gateway with a dedicated tracing platform such as Langfuse or Opik, and confirm the integration you need before choosing. | When trace retention, evaluation or prompt versioning becomes the main requirement. Then the tracing platform, not the gateway, should drive the decision. |
How the Portkey gateway runs in your infrastructure
The open-source gateway runs entirely in your own environment, and the choice of runtime is the first decision. For a quick local test, npx @portkey-ai/gateway starts the gateway on port 8787 with a Gateway Console that shows local logs. For anything that serves real traffic, the README points to deployment guides for the portkeyai/gateway Docker image, Docker Compose, a plain Node.js server and Cloudflare Workers, and the gateway can also be placed on Kubernetes. Each option gives you a different place to put secrets, TLS termination and log collection, so pick the runtime that matches your existing platform team's operating model before writing application code against it.
Routing behavior is not set in the gateway's environment variables. Retries, fallbacks, load balancing and conditional routing are expressed as JSON configs that you attach to the client, so the same gateway can serve different applications with different rules. Confirm in the current deployment guide how config is versioned, stored and reviewed, because a config change is effectively a routing change and should go through the same change control as code. Test each fallback path against your real provider keys in a non-production environment, since a fallback you have never triggered is a fallback you cannot rely on.
Before production use, check the release status. The latest tagged release is v1.15.2, published on January 12, 2026, while the README announces a Gateway 2.0 pre-release on a 2.0.0 branch, into which Portkey's core enterprise gateway is merging into open source. Pin a specific tagged version, read the gateway releases page for changes since then, and decide whether your organization will track the pre-release or wait for it to stabilize. If you use the hybrid option, where the gateway sits in your VPC and the control plane stays with Portkey, the gateway makes outbound HTTPS calls to control.portkey.ai. Ask Portkey to document exactly what data crosses that connection and whether your network team can allow it through egress controls.
Where prompts, keys and logs sit under each model
Each model places prompts, provider keys, logs and access controls in a different spot, and those spots decide who can read or retain your data. The cards below follow one request through OpenRouter's hosted router and through a gateway you run yourself. DeployOpen prepares controls and evidence for assessments, but independent auditors and certification bodies issue any audit reports or certifications.
Prompt and response transit
With OpenRouter, every prompt and response passes through OpenRouter's hosted router before it reaches the model provider. With the open-source Portkey gateway, the same traffic travels from your application to a gateway process you deploy in your own cluster, VM or edge runtime, and then directly to the provider. Map each hop in your architecture diagram and confirm which network segments carry plaintext prompts.
Provider key custody
Bring-your-own-key setups move provider credentials to the party that holds the gateway configuration. With a self-hosted gateway, your provider keys sit in your secret store and are loaded at runtime, so rotation and revocation stay under your control. Confirm who can read the gateway configuration, where keys are cached in memory or on disk, and how a leaked key is revoked at each provider.
Where logs live
The open-source gateway does not store a full request history for you. Its local Gateway Console is useful for development, but production logs need a destination you choose, such as your SIEM, an observability stack or a database. Decide which fields are logged, whether prompts are stored at all, and how long retention applies, because logged prompts often contain personal or confidential data.
What the hybrid control plane receives
Portkey's hybrid deployment keeps the data plane, the gateway, in your VPC while the control plane runs in Portkey's VPC, and the gateway calls out over HTTPS to control.portkey.ai. Ask Portkey in writing which configuration, metadata and telemetry leave your network, which fields are included, and where they are stored. This is the boundary most often missed in data protection reviews.
Identity and access control gaps
The open-source gateway ships without a full admin identity layer, so role-based access, SSO and per-team separation are gaps you must fill. Portkey lists secure key management with role-based access control and PII redaction among enterprise features outside the open-source gateway. Plan how operators authenticate, which teams can change routing or keys, and where audit trails of those changes are kept.
Compliance evidence you produce
Assessors will ask for evidence that each control operates, including access reviews, change records for gateway configuration, key rotation logs and data flow diagrams. The open-source gateway will not generate this evidence for you, so your team must collect it from your own systems. Agree the control list and evidence format with your assessor early, and confirm which controls DeployOpen can prepare as part of a fixed-scope engagement.
What you must build yourself with the open-source gateway
The open-source Portkey gateway routes requests, retries, falls back and balances load, but it does not give you a logging and tracing backend, shared state, key issuance, budget policy, SSO or an operating model. Those are the pieces a team has to choose and run before the gateway can replace a hosted router for more than one application. The first decision is observability. The gateway's local Gateway Console is useful for development, but production traces usually go to a self-hosted backend such as Langfuse, which needs PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, or to OpenTelemetry collectors feeding your existing stack. Confirm with Portkey which logging and tracing features sit in the open-source gateway and which belong to its enterprise deployment before you design this layer.
Shared state is the second decision. If you run more than one gateway instance, rate limits, cache and routing state must live in a shared store. Teams usually provision a PostgreSQL database for configuration and spend records and a Redis-compatible store for shared state. Keys and budgets are the third. The open-source gateway does not issue per-team or per-application keys with spend limits, so you need to define who receives a key, how budgets are set, who approves increases and how a revoked key is handled. Store provider credentials in a secrets manager and keep the gateway's own admin credentials out of configuration files. Your effort here grows with the number of teams and applications that share the gateway.
SSO, role design, backups and upgrades complete the list. Decide which identity provider controls access to gateway configuration and logs, which roles can change routing or provider keys, and how audit trails are retained. Plan regular backups of the database and object storage, test restores, and set a schedule for tracking Portkey gateway releases, including the Gateway 2.0 pre-release, before you adopt them. How strict your audit requirement is determines how much of this must be documented and evidenced. Ask your auditor or compliance lead which records they will request, and confirm those records can be produced from your own stack.
Cost components on each side and what drives them
Moving from OpenRouter to a self-hosted Portkey gateway shifts spend from a platform fee to direct provider billing plus the infrastructure and people that run the gateway. Each component below is marked as one-time or recurring, with the drivers that move it up or down.
OpenRouter platform fee
OpenRouter charges a platform fee on credit purchases and a separate fee on bring-your-own-key usage above a monthly allowance. This fee recurs with spend and scales with request volume, so it is the line most teams are trying to remove. Check the current fee terms on OpenRouter's pricing page at the time of your comparison, because fee structures change and any figure in an internal business case should cite that page directly.
Direct provider billing
With a self-hosted gateway, your organization holds accounts and contracts with each model provider and pays them directly for tokens. This is recurring and usually the largest line, so the gateway itself rarely drives total cost. Ask each provider about committed-use discounts, rate limits and data terms, since these change the effective price per request more than the gateway does.
Gateway compute and hosting
Portkey's gateway is MIT licensed, so the software line is zero, but the compute to run it is not. Recurring costs come from the containers or Kubernetes nodes that serve traffic, and they grow with the number of proxy instances and peak concurrency. Confirm the sizing guidance with Portkey for your traffic profile and load test before you commit to a node count.
Database and cache
Portkey's open-source gateway is configured through client-side JSON, so its own state needs are small, but the logging, keys and budgets you add yourself will need a database and a shared cache. These are recurring and grow with retention and the number of teams. If you pair the gateway with LiteLLM for virtual keys, budget tracking and rate limits, PostgreSQL and Redis become required rather than optional.
Observability and log storage
Logging, tracing and dashboards are not included in the open-source gateway's core feature set, so you must select and run a tool such as Langfuse, Opik or an OpenTelemetry stack. Storage is recurring and driven by retention period and prompt size. Decide how long you keep request bodies, because PII in logs creates a separate compliance cost in redaction and access control.
Engineering time and upgrades
Your team pays for the people who deploy, patch, monitor and upgrade the gateway, and for building the keys, budgets and access rules that the hosted product supplies. This is recurring, and it rises with the number of teams and environments. Portkey's enterprise features, such as role-based key management, PII redaction and caching, sit outside the open-source gateway, so price them as either paid Portkey plans or internal build time.
External services and support
Costs for DNS, certificates, identity provider licenses, secret management and any paid Portkey plan or external support contract sit outside the gateway but still count toward total cost. Some of these are recurring per seat or per request, and others are one-time setup work. Ask Portkey which enterprise features require a paid plan and which are available in the open-source release.
What a move from OpenRouter to a self-hosted gateway involves
The sequence moves model access from one hosted router to provider accounts you hold and a gateway you run, with each step ending in a check you can verify before the next one starts.
Inventory models, providers and routing rules
Your platform team lists every model slug, provider route, fallback order and provider preference that applications use through OpenRouter, along with the owners of each application. Finance and security should confirm which teams hold OpenRouter credits and which data classes each application sends. The output is a spreadsheet that maps each application to its models and providers, and it is done when every production call path appears in it.
Open direct provider accounts under your contracts
Your procurement and legal teams open accounts directly with each provider in the inventory, under agreements your company negotiates and holds. Confirm each provider's data retention terms, regional endpoints and rate limits in writing, since those terms will no longer come through OpenRouter. The step is done when each provider key is stored in your secret manager and a test call succeeds from a non-production host.
Deploy the gateway in a test environment
Your platform engineers run the Portkey gateway in a non-production environment using one of the documented options, such as Docker, Node.js or Kubernetes, and connect it to a database and secret store appropriate to your standards. Note that the gateway's JSON configs and the Gateway Console serve local work, so decide early where logs and keys will live. The step is done when a test request routes through the gateway to a direct provider account and the response is logged where your team expects.
Translate model names and routing into gateway configs
Engineers convert each OpenRouter model slug into the provider and model identifier the gateway expects, then write the fallback, retry and load-balancing rules as gateway configs attached to client requests. Where your team uses LiteLLM today, Portkey publishes a migrate-litellm-to-portkey skill that maps its completion calls, router, fallbacks and retries. Other teams should confirm the provider setup path for their own deployment, because the skill's checklist starts with a Portkey API key and providers configured in Portkey's Model Catalog, a Portkey-hosted step. The output is a versioned config file, reviewed by the owners of each application.
Move a pilot application to the gateway
Pick one lower-risk application and point its base URL at the gateway while keeping the OpenRouter key as a fallback path. Compare response quality, latency, error rates and token counts against the OpenRouter baseline for the same prompts over an agreed observation window. The step is done when the pilot owners sign off that behavior matches expectations and any differences have a recorded cause.
Issue keys and set budgets
Security and platform teams create gateway-level credentials for each application or team, scope them to approved models, and set spend and rate limits. Confirm which key, budget and audit features your chosen deployment provides without a paid plan, since some access control and logging features are listed as enterprise features outside the open-source gateway. The step is done when each application uses its own credential, and a test shows that an out-of-scope model request is refused.
Cut over application base URLs
Teams change the base URL and credentials for each remaining application in planned batches, starting with the lowest-impact services and watching error and latency dashboards after each batch. Keep the OpenRouter route available until every batch has run without open issues. The step is done when all production traffic reaches the gateway and no application still calls OpenRouter.
Retire the OpenRouter key and close the account
After a stable period agreed by the platform and finance owners, revoke the OpenRouter API key, confirm no scheduled jobs or secrets still reference it, and settle any remaining credit balance under OpenRouter's terms. Record the final configuration, owners and provider contracts in your runbook. The step is done when the key shows as revoked, a scan of your repositories and secret stores finds no remaining references, and the runbook is signed off.
Questions teams ask before switching from OpenRouter to Portkey's gateway
How much effort does a self-hosted Portkey gateway take to run?
The gateway itself is light: Portkey's README describes a footprint of 122 kb and under 1 ms of added latency, and it can run through npx, Docker, Node.js, Cloudflare Workers or Kubernetes. The effort sits around it. You operate the deployment, its scaling, upgrades and the logging, key and budget tooling that the open-source gateway does not provide. Ask Portkey and your own platform team which parts of the enterprise deployment you would run yourself, and estimate operating effort from those answers rather than from the gateway's size alone.
What does a migration from OpenRouter need from the team?
A migration needs owners for four things: provider accounts, routing configuration, application changes and operations. You need direct accounts with each model provider you use, because the gateway forwards calls to providers rather than reselling them. Routing lives in JSON configs attached to the client, so someone must translate OpenRouter model names and fallback rules into those configs. Application teams must point their base URLs at the gateway and test each path. Portkey publishes a migrate-litellm-to-portkey skill for teams coming from LiteLLM, but no equivalent migration tooling for OpenRouter is in our sources, so confirm what Portkey offers for your starting point.
Can one engineer run the gateway without outside help?
One engineer can often run a small gateway, but the answer depends on how much you need beyond routing. Basic routing, retries and fallbacks are configuration work that a platform engineer can handle. Logging to your own stack, centralized key management, budgets and access control need design decisions and ongoing ownership, and those are where teams usually need a second person or outside help. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your environment under a written, fixed scope, and offers retainers for ongoing support. Compare the work against your on-call and staffing capacity.
How long does the work take, and what drives the timeline?
No duration is supplied for this migration, so treat any figure you hear as unverified until it is written into a scope. The main drivers are the number of providers and models in use, how many OpenRouter-dependent applications need changes, how complex your fallback and load-balancing rules are, whether you already run a secret manager, identity provider and observability stack the gateway can connect to, and how many approval and security review steps your organization requires. Ask for a phased plan that separates a pilot on one application from the full cutover.
Which Portkey features still require a paid plan?
Portkey's repository lists prompt management, semantic caching, advanced logging and tracing, access control and PII redaction as enterprise features outside the open-source gateway. The enterprise deployment described in Portkey's guide adds secure key management with role-based access control, simple and semantic caching, IP and geo inbound rules, PII redaction and professional support. Portkey's Gateway 2.0 pre-release states that the core enterprise gateway is merging into open source, but that work is on a branch, so confirm with Portkey which features ship in the open-source release you deploy and which remain paid before you rely on them.
Do our provider contracts have to move when we leave OpenRouter?
Yes, in practice you need your own provider relationships for the gateway to call them. OpenRouter holds the provider keys and bills you through its platform, while a self-hosted gateway calls providers with keys you control and pays them directly. Review each provider's terms, data processing agreement, regional endpoints and rate limits before cutover. Confirm with each provider whether your existing usage commitments or credits transfer to a direct account, since those details are not covered by the supplied sources.
How are logging and key management handled once we self-host?
The open-source gateway does not supply the enterprise logging and key management layer, so you must choose and run those parts. Portkey's hybrid deployment keeps the data plane in your VPC while the control plane stays with Portkey, and the gateway calls control.portkey.ai over HTTPS, so confirm what telemetry and configuration leave your network. For keys, store provider credentials in a secret manager and restrict who can change configs. Ask Portkey which logging and key controls are in the open-source release versus its enterprise deployment, and document where each log and key lives for your auditors.
How DeployOpen helps evaluate and implement a self-hosted gateway
DeployOpen plans, implements, hardens, backs up and documents a self-hosted gateway inside your own cloud account, data center or air-gapped network. For a team weighing OpenRouter against Portkey's MIT-licensed gateway, the first useful engagement is an evaluation that answers the open questions in this comparison in your environment: which providers you hold direct accounts with, where the gateway will run, whether it needs the npx local setup or a containerized deployment behind your ingress, and which logging, key and budget functions you will build or buy alongside it. The output is a written decision record rather than a demo, so the choice between the open-source gateway and a Portkey hybrid or enterprise plan can be tied to your data flows and existing tooling.
Implementation covers the gateway deployment itself, the JSON configs that define retries, fallbacks, load balancing and conditional routing, provider credentials stored in your secret manager, and the logging and tracing pipeline you choose to pair with it. Security testing is scoped to the gateway and its keys: how client credentials are issued and revoked, whether provider keys are exposed to applications, how request logs handle prompts that contain personal data, and whether the gateway's network access matches what you have approved. Hardening and backup procedures are documented so your operations team can run them after handover. DeployOpen does not hold provider contracts, and it is not a Portkey partner or reseller.
Engagements are fixed-scope: scope, deliverables and timelines are agreed in writing before work starts, and ongoing support, upgrades and continuous testing are available as a retainer once the gateway is live. DeployOpen does not publish a price list, so cost depends on the scope you agree, including the number of environments, providers and any integrations with your identity and logging systems. To request a quote, send a written description of your current OpenRouter usage, the applications and teams that call it, your data residency and key management requirements, and the Portkey features you need to replace. A quote then follows from that written scope.
