Which fits: Portkey or Apache APISIX as your LLM gateway?
If your organization already runs Apache APISIX for its APIs and now needs LLM routing, token quotas and guardrails, APISIX fits when you want LLM traffic under the same gateway, policies and operating model as everything else. Its AI plugins, including ai-proxy-multi and ai-rate-limiting, let your platform team manage model traffic alongside existing routes, authentication and observability. Portkey fits teams that want an out-of-the-box LLM control surface with hosted logs, prompt management and model-specific features ready without building them. The choice turns on three questions: how much logging and prompt management you need from the gateway itself, where prompts, responses and logs are allowed to live, and who will operate the gateway day to day.
Start with the logging and prompt management requirement. APISIX's ai-proxy plugin can record token usage, model and time to first response, but it does not give you a hosted log explorer or a prompt library, so you would need to pair it with a trace store and a versioning process. Portkey's hosted logs and prompt management reduce that build work, but confirm with Portkey which of these features your plan includes, since its open-source gateway leaves prompt management and advanced logging outside the MIT-licensed code. Next, map data residency. Portkey's hybrid deployment keeps the gateway in your VPC but calls out over HTTPS to its control plane, so confirm whether that outbound path is acceptable. A self-hosted APISIX deployment in standalone mode keeps configuration in a local file and does not need a control plane outside your network.
Finally, decide who owns the gateway. APISIX runs in traditional, decoupled or standalone modes, and its Admin API and plugin configuration need the same change control your API team already applies. Teams that write custom plugins will need Lua or a supported plugin runner. If your platform team is already comfortable operating APISIX, the marginal work of adding LLM routing is usually smaller than adopting a second gateway, but a team without APISIX experience will carry a learning cost that a managed Portkey plan avoids. Ask both vendors for a written list of the features in your tier, the logs they store and where, and the support commitments you would rely on.
Which option suits which team situation
This table maps common team situations to the better fit between hosted Portkey and a self-hosted APISIX gateway with its AI plugins. Read each row against your own constraints, since the condition in the right-hand column usually decides the choice. APISIX is not cheaper in every case, because it moves the log store, plugin configuration and on-call work onto your team.
| Situation | Better fit | Condition that drives the choice |
|---|---|---|
| Existing APISIX estate for APIs | APISIX AI plugins | Your platform team already operates APISIX, its etcd cluster and its certificates, so LLM routes add to a known system instead of a second gateway. |
| No APISIX today and no gateway team | Portkey hosted or hybrid | Adopting APISIX for LLM traffic alone means learning its Admin API, plugin model and etcd operations before the first request is routed. |
| Need hosted logs without building a log store | Portkey hosted or hybrid | Portkey provides logging and tracing as part of its product, while APISIX ai-proxy logs token usage and latency that you must ship to your own store. |
| Per-consumer token quotas | APISIX ai-rate-limiting | You need token limits per consumer over a time window, which the ai-rate-limiting plugin supports when attached to consumers, and you can define the counted metric. |
| Prompt management across teams | Portkey or a separate prompt tool | Prompt management is an enterprise feature outside the open-source gateway, so APISIX covers templating through ai-prompt-template but not versioned prompt governance. |
| Air-gapped or disconnected networks | APISIX self-hosted | Hybrid Portkey calls out over HTTPS to its control plane, so only a gateway you run entirely inside the network fits, and you must confirm any plugin that calls external moderation services. |
| Teams without platform engineers | Portkey hosted or a managed APISIX vendor | Running APISIX in production requires patching, etcd backups and monitoring, and that operating work recurs whichever gateway you choose. |
Where logs, keys and traffic live under each option
Each option answers the same question differently: which systems see your prompts, provider keys and logs, and which of them sit outside your network. The cards below set out Portkey's hosted and hybrid split, APISIX's self-managed modes, and the identity and evidence work that stays with you.
Portkey hosted gateway
In the hosted model, requests pass through Portkey's infrastructure, so prompts, responses, virtual keys and logs are stored in Portkey's environment. This is the simplest route to logs and prompt management, but it puts every request outside your network. Ask Portkey to confirm where request bodies, logs and stored provider credentials are kept, how long they are retained, and which regions host them.
Portkey hybrid data plane
In hybrid deployment, the gateway (the data plane) runs in your VPC, so request traffic reaches the model providers from your network. The control plane stays in Portkey's VPC, and the gateway calls out over HTTPS to control.portkey.ai. Confirm exactly which configuration, metadata and log fields cross that channel, because residency reviews often turn on that boundary.
APISIX traditional mode
In traditional mode, the data plane and control plane run together on the same nodes, backed by etcd. Client traffic arrives on port 9080 and the Admin API listens on port 9180. Restrict the Admin API to an internal network or management subnet, since anyone who reaches it can change routes, plugins and provider keys.
APISIX decoupled and standalone modes
Decoupled mode separates the data plane from the control plane, which share one etcd cluster. Standalone mode drops etcd entirely and reads configuration from a YAML or JSON file or the API, reloading changes without a restart. Choose the mode by who must be able to change routes and keys, and document where the configuration file and etcd data live, since both hold provider credentials.
Fully self-hosted traffic and logs
When APISIX runs in your own cloud account or data center, prompts, responses, token counts and access logs stay inside your network unless you export them. Logging to your own SIEM or observability stack is the customer's decision. Check the logging plugins you enable, since the AI plugins can record model, token usage and latency, and those records are subject to your retention rules.
Identity through openid-connect
The openid-connect plugin lets APISIX validate tokens from identity providers such as Keycloak, Microsoft Entra ID, Okta and Auth0, using authorization code, client credentials, introspection and PKCE flows. Map which consumers and teams may call which models, and confirm the token lifetimes and claims your provider issues. Identity keeps user records outside the gateway, so review that split when you assess access control.
Compliance evidence stays with you
Neither Portkey nor APISIX produces the evidence an assessor needs for your environment. Your team must document data flows, key rotation, access reviews and log retention, then agree with your auditor which controls apply and what proof they accept. DeployOpen prepares systems and evidence for assessments, but independent auditors and certification bodies issue any opinion on them.
How APISIX sits in front of LLM providers
In an APISIX setup, applications keep calling one route on the gateway, and the AI plugins do the provider work behind it. The ai-proxy plugin takes a single provider configuration and converts the request into the format expected by OpenAI, Azure, Anthropic, Amazon Bedrock, Vertex AI and other OpenAI-compatible APIs. When you need several model instances, ai-proxy-multi sits on the same route and handles weighted round robin, priorities, retries and fallbacks triggered by HTTP status. The ai-rate-limiting plugin then enforces token quotas per LLM instance over a time window, and when attached to consumers it gives each team or application its own allowance. Confirm in your own test environment how a consumer identity is passed to the route, because the quota logic depends on it.
Token usage, model name and time to first response are logged by the ai-proxy plugin, but APISIX does not store or display them as a finished product. Plan a log pipeline into an observability stack you run yourself, such as the OpenTelemetry, Prometheus and Grafana tooling covered elsewhere in this hub, and decide who owns dashboards for cost per consumer. Portkey's hosted logs and prompt views have no direct equivalent here, so ask your team which of those views they actually use before you commit to building replacements.
Anything APISIX does not ship, such as prompt templating beyond the bundled plugins or custom request inspection, can be written as a custom plugin in Lua, or through plugin runners in Java, Go or Python, or as WebAssembly. These options are useful, but each one is an engineering cost: someone must write, test, version and upgrade the code against each APISIX release, and a bug in a plugin sits on the request path for every LLM call. Budget that work explicitly, and confirm which upgrade path your APISIX version and deployment mode support before you rely on a custom plugin in production.
What running each gateway costs over time
This table sets Portkey's subscription and enterprise contract against the infrastructure, etcd, observability and engineering work of a self-hosted APISIX gateway. Read each row for who is paid, whether the cost is one-time or recurring, and what moves it up or down. Use the quote checklist in the last row to get comparable numbers from every vendor.
| Cost component | Portkey (hosted or hybrid) | Apache APISIX (self-hosted) |
|---|---|---|
| Licence or subscription | Recurring plan or enterprise contract; features such as prompt management and semantic caching sit in enterprise tiers | No licence fee for the Apache-2.0 gateway; optional recurring API7 Enterprise subscription if you want commercial support |
| Logs and observability | Hosted logs and tracing are part of the subscription and scale with plan limits | Recurring cost of a self-chosen log, metrics and tracing backend; you size and pay for its storage |
| Gateway compute | Hybrid mode runs the data plane in your VPC, so you still pay for those nodes | Recurring cost of gateway nodes, sized by request volume, streaming connections and plugin load |
| Configuration store | Not applicable to you; Portkey operates the control plane | Recurring cost of etcd in traditional or decoupled mode; standalone mode removes it at the cost of file-based change handling |
| Engineering time | One-time setup of routes and virtual keys, then ongoing configuration changes | One-time build of routes, ai-proxy-multi and ai-rate-limiting configuration, then recurring upgrades and plugin maintenance |
| Main cost drivers | Request volume, log volume, number of enterprise features and seats | Node count, etcd high availability, log retention, and how many plugins and custom Lua or runner plugins you maintain |
| Quote questions to ask | Ask for the plan that includes hosted logs, the per-unit log or request basis, and which hybrid features need an enterprise contract | Ask API7 for support tiers and what they cover, and budget your own nodes, etcd, logging and engineering hours in one internal estimate |
How a move from Portkey to APISIX usually proceeds
The sequence turns Portkey's hosted gateway behavior into APISIX routes, plugins and a self-managed log pipeline, then moves application traffic over in a controlled way so both gateways can be compared before cutover.
Inventory Portkey configuration and dependencies
The platform owner exports or documents every Portkey config in use: routing targets, fallback chains, retry settings, guardrail checks, virtual keys and the teams or applications that hold them. Each application that calls the gateway is listed with its endpoint, model names and expected token volume. Confirm which features are on the account's current plan, since guardrails, logs and prompt management vary by tier. The step is done when every config has a documented owner and a purpose, and the list shows which items are gateway behavior and which are Portkey-specific features that APISIX will not reproduce.
Map configs to APISIX routes and plugins
The API platform team translates each Portkey config into APISIX routes, with the ai-proxy-multi plugin carrying provider instances, priorities, weights, retries and fallbacks triggered by HTTP status. Virtual keys and per-team limits map to APISIX consumers with ai-rate-limiting token quotas. Prompt guard and moderation plugins replace the guardrail checks where they meet the requirement, and any gap is written down. The step closes with a mapping sheet that shows each Portkey feature as covered, partly covered or missing, and the team confirms the behavior of each plugin version against the APISIX AI plugin documentation before testing.
Choose the APISIX deployment mode
The platform team selects traditional, decoupled or standalone mode based on how the existing APISIX estate runs. Traditional and decoupled modes depend on etcd, while standalone mode loads configuration from a YAML or JSON file or the Admin API. The team confirms the ports and network paths for client traffic and the Admin API, and decides who can change routes and consumers. The step is done when a written decision records the mode, the configuration source, change control and the place where gateway logs are sent.
Build a self-managed log and trace pipeline
Because Portkey's hosted logs will not follow the traffic, the observability team sets up the destination for token usage, model, latency and error records. APISIX's ai-proxy plugin can record token usage, model and time to first response, so the team confirms which fields it writes and where they are stored. Retention, access rules and any prompt or response content that must be redacted are decided before traffic flows. The step is complete when test requests appear in the chosen store with the expected fields and access is limited to approved roles.
Export history where the account allows it
If the account has access to Portkey's log export, the team requests the export and stores it under the same retention rules as the new pipeline. Export availability depends on the plan and the account, so the team confirms eligibility with Portkey before planning around it. Where export is not available, the team records the gap, decides which historical data is needed for cost reporting or audits, and keeps the Portkey account active for read access as long as the contract allows. The step closes when the archive has been checked for completeness and an owner has signed off on what was kept.
Run both gateways in parallel
Selected non-critical applications send the same requests to APISIX and to Portkey, or to APISIX with Portkey as a fallback target, so the team can compare responses, latency, token counts and error rates. Consumer quotas and fallback behavior are tested with forced provider errors and deliberate limit breaches. Differences are logged and each one is resolved or accepted by the application owner. The step is done when the test results show that APISIX returns the expected behavior for each mapped route and the open differences are documented.
Cut over applications by changing endpoints
Applications are moved in batches by changing their base URL and credentials to the APISIX route and consumer key. Each batch is watched through the new logs and rate-limit counters, and the previous Portkey path stays available until the batch passes its checks. The team keeps a rollback instruction for every application. The cutover is complete when all applications point to APISIX, Portkey traffic has stopped, and the team confirms that no application still uses a retired virtual key.
Questions buyers ask before choosing APISIX over Portkey
Can Apache APISIX replace Portkey's prompt management?
No, APISIX does not natively provide a prompt registry with versions, labels and a review workflow. Its AI plugins handle prompt handling at the gateway layer: ai-prompt-template and ai-prompt-decorator can shape requests, and ai-prompt-guard can screen them. Versioned prompt storage, approval and rollback need a separate system, such as a prompt management tool run beside the gateway, or a Git-based workflow where prompts ship through your normal release pipeline. Confirm the exact behavior of each plugin against the current APISIX plugin documentation before you design around it, and decide early where prompt ownership sits between application teams and the platform team.
How much effort does moving from Portkey to APISIX take, and what drives it?
The effort depends mostly on how many Portkey features your applications rely on and how much routing logic lives in Portkey configs. Teams that only send OpenAI-format requests through a few providers face a smaller change than teams using virtual keys, prompt templates and per-team budgets across many models. The main work items are: mapping provider credentials and model instances to ai-proxy or ai-proxy-multi, rebuilding fallback and retry rules, recreating per-consumer token quotas with ai-rate-limiting, rebuilding logging, and cutting over client endpoints. Ask any implementation partner for a written scope that lists these items individually, since no reliable figure can be given without that inventory.
Can our own team run this migration without outside help?
A team that already operates APISIX for its APIs can usually handle the core gateway configuration in-house, because the routing and plugin model is the same one it already uses. Outside help is more useful for the parts that fall outside APISIX's gateway role: prompt management design, evaluation and tracing decisions, and hardening for production. Whether internal capacity is enough depends on how many people have operated APISIX in production, whether they have run the etcd or standalone configuration in your environment, and whether anyone owns the AI-specific policies. An honest self-assessment against those points is more reliable than a general estimate.
What skills does an APISIX-based LLM gateway need?
The work needs three skill areas. Gateway operations covers deployment in traditional, decoupled or standalone mode, configuration management, upgrades and health checks. Plugin work matters only when you need behavior the built-in AI plugins do not provide, since APISIX supports custom plugins in Lua and, through plugin runners, in Java, Go and Python, as well as WebAssembly. Observability covers wiring token usage, model and latency data into your logging and metrics stack, which is where most gaps appear. Most teams need Lua work rarely, but they should confirm that someone can read and maintain any custom plugin before go-live.
Does APISIX provide Portkey-style logging, and where do I confirm it?
APISIX does not offer a hosted log dashboard like Portkey's. The ai-proxy plugin can log token usage, the model used and time to first response, and APISIX's observability plugins export data to external systems. You will need to choose and operate the destination yourself, such as an OpenTelemetry pipeline or a log store. Request and response payload capture, prompt-level search and per-request cost views need separate design. Confirm the exact fields and export options for your APISIX version in the ai-proxy documentation and in a test environment, because logging behavior is the most common source of surprise after cutover.
How does the Apache-2.0 license affect commercial use?
Apache APISIX is released under the Apache License 2.0, a permissive open-source license, so your organization can use, modify and run it commercially without paying a license fee to the Apache Software Foundation. The license does not cover support, hardening or operating the platform, and those remain your costs or a services contract. Enterprise distributions from third parties, such as API7 Enterprise, are separate products with their own terms, so check which one you would run. Have your legal team confirm obligations such as notice and attribution for the version you deploy.
What should we ask before choosing APISIX over Portkey?
Start with a written inventory of the Portkey features you use, then ask whether each one is covered by a built-in APISIX plugin, needs a custom build or needs a separate tool. Ask for the expected operating model, including who patches the gateway, who owns etcd or standalone configuration, and who responds to alerts. Ask which prompt management and logging approach will be used, and what it costs to run. For any figure you need for budgeting, ask for the basis in writing. DeployOpen provides a fixed-scope quote after that inventory, so the scope and deliverables are agreed before work begins.
What to confirm with your team and the vendors before deciding
Start with the logging fields and destinations your compliance team needs, because this is where APISIX and Portkey differ most. The APISIX ai-proxy plugin can log token usage, model and time to first response, but the rest of your audit trail, including prompt content, caller identity and retention, has to be designed around the gateway's access and error logs and whatever sink you attach. Portkey's hosted logs come with the product, but in its hybrid model the control plane sits at control.portkey.ai, so ask Portkey where each log field is stored and whether any of it leaves your VPC. Confirm also whether your reviewers need prompt versioning. Portkey's prompt management is an enterprise feature, and APISIX has no equivalent prompt registry, so a prompt versioning requirement moves the decision toward a separate tool.
Next, confirm provider coverage for the models you actually call. The APISIX ai-proxy documentation lists OpenAI, Azure, Anthropic, Gemini, Vertex AI, Amazon Bedrock and other OpenAI-compatible APIs, but check each model name, regional endpoint and streaming behavior against your own test traffic before you rely on a list. For identity, map every consumer type (internal services, partner applications, individual developers) to an APISIX consumer and an authentication flow. The openid-connect plugin supports flows such as authorization code, client credentials and token introspection with providers like Keycloak, Microsoft Entra ID and Okta, but your identity provider must issue tokens in the form your routes expect.
Finally, pin down your APISIX version and support path. The APISIX downloads page lists 3.19.0 as released on September 28, 2026, but it does not mark any release as long-term support, so ask your engineering team which version you will run and who patches it. Ask Apache APISIX's community and any commercial support vendor, such as API7.ai, which versions they support and for how long. Last, decide whether you need hosted or enterprise features at all. If the open-source plugins cover your quotas, fallbacks and guardrails, you avoid a Portkey plan. If you need a managed control plane or vendor support, get that scope and its price in writing from the vendor before the comparison closes.
How DeployOpen helps evaluate, implement or migrate
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Portkey versus Apache APISIX decision, we start from the routing, quota and logging requirements your teams already have, then agree the work in writing before anything changes.
How we scope
- Inventory which LLM providers, models and consumers would pass through APISIX and which Portkey features they rely on today.
- Map each Portkey capability to an APISIX plugin or a named gap, so the written scope lists what remains open.
- Agree deliverables, timelines and responsibilities in writing before work starts, since most engagements are fixed-scope.
- Confirm with the APISIX project and your own environment which plugin versions and deployment mode will be used.
How we build
- Configure ai-proxy-multi routes for weighted load balancing, retries and fallbacks, and test failover against your real provider accounts.
- Set ai-rate-limiting quotas per consumer and validate token counting for prompt, completion and total usage.
- Deploy the chosen APISIX mode in your own cloud account, data center or air-gapped network, with the Admin API restricted.
- Add prompt guard, moderation and identity controls through openid-connect where the written scope requires them, and test them as part of the build.
How we hand over
- Document route and plugin configuration, consumer quotas, and the logging destinations that replace Portkey hosted logs.
- Provide a gap register listing Portkey features such as prompt management and semantic caching that APISIX does not replace.
- Run a cutover checklist with application owners, covering endpoint changes, key reissue and rollback steps.
- Deliver operating runbooks for upgrades, certificate rotation and etcd backup, matched to the scope agreed at the start.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Retest AI routes and quota rules after each APISIX upgrade or provider change.
- Prepare evidence for compliance assessments on controls we built, while independent auditors issue any formal reports.
