# Portkey self-hosted alternative: AI and MCP gateways on your infrastructure

> Compare Portkey self-hosted, hybrid and legacy air-gapped options with Tyk AI Studio and Tyk Gateway for LLM and MCP traffic on your own infrastructure.

Portkey can still be self-hosted as an open-source gateway or run as a hybrid deployment, but its documentation states that Portkey "no longer provisions new fully air-gapped deployments"; existing air-gapped deployments remain supported. Portkey was acquired by Palo Alto Networks in May 2026 and is now branded Prisma AIRS AI Gateway. [Open-source gateway](https://github.com/Portkey-AI/gateway) · [Deployment comparison](https://portkey.ai/docs/product/product-feature-comparison) · [Acquisition](https://www.paloaltonetworks.com/company/press/2026/palo-alto-networks-completes-acquisition-of-portkey-to-secure-ai-agents).

For a fully self-managed alternative, Tyk AI Studio provides self-managed LLM management and Tyk Gateway proxies and governs remote MCP servers. [AI Studio installation](https://tyk.io/docs/ai-management/ai-studio/installation/overview) · [MCP Gateway overview](https://tyk.io/docs/ai-management/mcp-gateway/overview). For background, see [what an LLM gateway is](https://tyk.io/learning-center/what-is-an-llm-gateway/?aeo_mode=preview) and [open-source AI gateways compared](https://tyk.io/learning-center/open-source-ai-gateways/).

Last updated: 30 October 2026

For a strict air-gap requirement, there is a qualification: Tyk documents air-gapped installation for its API-management stack, but a complete AI Studio offline deployment and offline Enterprise licence lifecycle are not documented in the sources reviewed. Treat that as a requirement to resolve before selecting the architecture. [Tyk air-gapped installation](https://tyk.io/docs/api-management/air-gapped-deployment) · [AI Studio installation](https://tyk.io/docs/ai-management/ai-studio/installation/overview) · [AI Studio editions](https://tyk.io/docs/ai-management/ai-studio/overview#licensing-and-editions).

How we compared: Tyk publishes this comparison and is one of the options discussed. We compared public documentation, licences, repositories, release notes and deployment options as of 30 October 2026; we did not run benchmarks or hands-on tests. Each option lists strengths and limitations, including Tyk's.

Related comparisons: [enterprise MCP gateway providers compared](https://tyk.io/learning-center/best-enterprise-mcp-gateways/) and [LiteLLM alternatives for self-hosted LLM gateways](https://tyk.io/learning-center/litellm-alternatives/).

## Quick comparison: what can you operate yourself?

Start with the deployment boundary. A locally operated gateway, a locally operated management system and a fully disconnected installation are different requirements.

| Option | Licence or edition | What you operate | Documented role | Air-gap boundary |
|---|---|---|---|---|
| Portkey OSS gateway | [MIT](https://github.com/Portkey-AI/gateway/blob/main/LICENSE) | Local gateway and console. [Repository](https://github.com/Portkey-AI/gateway) | LLM access, fallback, retries, load balancing and guardrail configuration. [Docs](https://portkey.ai/docs/product/open-source) · [README](https://github.com/Portkey-AI/gateway/blob/main/README.md) | Local operation is documented; full commercial-platform parity is not established for every OSS build. [README](https://github.com/Portkey-AI/gateway/blob/main/README.md) |
| Portkey hybrid | Enterprise deployment. [Docs](https://portkey.ai/docs/product/product-feature-comparison) | Data plane in your environment; Portkey operates the control plane. [Architecture](https://portkey.ai/docs/self-hosting/hybrid-deployments/architecture) | Managed administration with a local gateway. [Architecture](https://portkey.ai/docs/self-hosting/hybrid-deployments/architecture) | Requires outbound HTTPS to control-plane endpoints. [Architecture](https://portkey.ai/docs/self-hosting/hybrid-deployments/architecture) |
| Portkey legacy air-gapped offering | Existing deployments remain supported. [Status](https://portkey.ai/docs/product/product-feature-comparison) | Previously offered with all components in the customer environment. [Docs](https://portkey.ai/docs/product/product-feature-comparison) | Existing-deployment reference, rather than a new deployment option. [Status](https://portkey.ai/docs/product/product-feature-comparison) | New fully air-gapped deployments are no longer provisioned. [Status](https://portkey.ai/docs/product/product-feature-comparison) |
| Tyk AI Studio Community | [AGPL-3.0](https://github.com/TykTechnologies/ai-studio/blob/main/LICENSE.md) | Self-managed installation. [Install](https://tyk.io/docs/ai-management/ai-studio/installation/overview) | LLM proxying, LLM management and its own tools over MCP. [Proxy](https://tyk.io/docs/ai-management/ai-studio/proxy) · [Tools](https://tyk.io/docs/ai-management/ai-studio/tools) | Complete offline lifecycle: not documented in the reviewed installation guide. [Install](https://tyk.io/docs/ai-management/ai-studio/installation/overview) |
| Tyk AI Studio Enterprise | Commercial licence key. [Editions](https://tyk.io/docs/ai-management/ai-studio/overview#licensing-and-editions) | Self-managed installation. [Install](https://tyk.io/docs/ai-management/ai-studio/installation/overview) | Adds enforced budgets, Model Router and filter execution. [Budgets](https://tyk.io/docs/ai-management/ai-studio/budgeting) · [Router](https://tyk.io/docs/ai-management/ai-studio/model-router) · [Filters](https://tyk.io/docs/ai-management/ai-studio/filters) | Offline Enterprise licence handling: not documented in the reviewed edition/installation instructions. [Editions](https://tyk.io/docs/ai-management/ai-studio/overview#licensing-and-editions) |
| Tyk Gateway MCP | Core Gateway: [MPL-2.0](https://tyk.io/docs/tyk-oss-gateway); remote MCP proxies available across licences. [Overview](https://tyk.io/docs/ai-management/mcp-gateway/overview) | Gateway; Dashboard management is separately licensed. [Repository](https://tyk.io/docs/tyk-oss-gateway) | Remote MCP proxying and primitive-level policies. [Policies](https://tyk.io/docs/ai-management/mcp-gateway/policies) | API-management installation has an artifact-mirroring procedure. [Air-gap guide](https://tyk.io/docs/api-management/air-gapped-deployment) |

“Not documented” identifies an evidence gap. It does not mean a feature is absent, and it should not be converted into a positive procurement assumption.

## Define what must stay on your infrastructure

Write the ownership requirement before choosing a gateway. “Self-hosted” is too broad to decide whether a deployment meets your needs. Specify whether you need to own request processing, policy administration, logs, identity services, or the complete operational lifecycle.

Use a boundary statement that an engineer can test. For example: “Administrators must create a key, change a policy, inspect a rejected request and restart the service without any connection outside the approved network.” This is an example acceptance requirement, not a reported capability of either vendor.

| Boundary | Question to answer |
|---|---|
| Model and tool traffic | Which endpoints receive prompts, responses, tool arguments and results? |
| Administration | Where do administrators create keys, edit policies and manage users? |
| Configuration | Which service supplies routing rules, credentials and authorization settings? |
| Observability | Where are logs stored, and what happens when someone views or exports them? |
| Identity and secrets | Can authentication, token renewal and credential rotation stay inside the boundary? |
| Operations | How will installation, upgrades, backup restoration and licence changes work without internet access? |

Distinguish ownership from temporary resilience. Continuing to serve an already configured request during a disconnection does not demonstrate that a team can onboard a new application or rebuild a failed installation offline. Decide which of those operations is essential, then make it part of the evaluation.

### Example: two teams with different ownership requirements

Consider two hypothetical teams. The first permits requests to approved external model providers but requires credentials, policies and administrative records to be managed internally. Its acceptance test should allow the approved model destination while blocking vendor administration services. The team then tries creating a new application, changing its access policy and inspecting its logs. The question is whether those administrative operations remain within the approved boundary.

The second team prohibits all external connections. Its test must include the model service and identity system as well as the gateway. Preparing installation packages is only the beginning: the team must also demonstrate recovery from a failed host, credential renewal and configuration changes using the resources available inside that environment.

These teams should not use the same checkmark for “self-hosted.” The first is testing ownership of administration with controlled external inference. The second is testing a complete disconnected system. A deployment may satisfy one requirement and fail the other without either result contradicting the product’s documentation.

Write the required boundary into the evaluation record before the demonstration. If a connection is necessary, record its destination, purpose, data and failure behavior. That makes an exception visible and reviewable instead of leaving it hidden behind a deployment label.

## Can you self-host Portkey?

Portkey remains a self-hosting option for a local gateway; its current commercial deployment boundary needs separate evaluation. Its documentation now uses the name Portkey / Prisma AIRS AI Gateway. The terminology below follows the existing Portkey documentation and repository. [Portkey documentation](https://portkey.ai/docs/product/open-source).

### The open-source AI gateway can run locally

The Portkey AI Gateway repository is MIT licensed. Its documentation describes a unified LLM interface with fallbacks, load balancing and retries; the README also documents input/output guardrails, a local Gateway Console and local logs. [Licence](https://github.com/Portkey-AI/gateway/blob/main/LICENSE) · [Open-source capabilities](https://portkey.ai/docs/product/open-source) · [Gateway README](https://github.com/Portkey-AI/gateway/blob/main/README.md).

That makes the OSS gateway a real option when your requirement is local LLM routing. [Open-source capabilities](https://portkey.ai/docs/product/open-source). Evaluate it before assuming that a change of vendor is necessary. A team that already meets its requirements with this distribution needs a concrete migration benefit, such as a missing operational control, to justify replacing it.

Keep the release boundary explicit. The default README separately advertises Gateway 2.0 as a pre-release. A link from that README to platform documentation does not establish that every platform capability ships with every open-source build. Record the exact release or commit being evaluated. [Gateway README](https://github.com/Portkey-AI/gateway/blob/main/README.md).

- **Strengths:** MIT; runs locally with fallbacks, load balancing, retries, guardrails, a local console and local logs. [Licence](https://github.com/Portkey-AI/gateway/blob/main/LICENSE) · [README](https://github.com/Portkey-AI/gateway/blob/main/README.md)
- **Limitations:** Gateway 2.0 is still a pre-release; platform features linked from the README are not established as part of every open-source build. [README](https://github.com/Portkey-AI/gateway/blob/main/README.md)

### Hybrid retains a hosted control plane

Portkey hybrid combines a local data plane with hosted administration and requires outbound HTTPS. [Hybrid architecture](https://portkey.ai/docs/self-hosting/hybrid-deployments/architecture). Evaluate it when retaining hosted administration is acceptable.

### Fully air-gapped enterprise deployments are a legacy option

Portkey states that it no longer provisions new fully air-gapped deployments and continues supporting existing ones. Retained air-gap instructions therefore describe an existing-deployment path, not an offer to provision a new installation. [Feature comparison](https://portkey.ai/docs/product/product-feature-comparison).

For an existing deployment, assess the documented support position and your own agreement before deciding to migrate. For a new project, do not build a plan around a deployment option the vendor says it no longer provisions.

- **Strengths:** the data plane runs in your environment, logs can stay local, and cached configuration avoids a control-plane lookup on every request. [Hybrid architecture](https://portkey.ai/docs/self-hosting/hybrid-deployments/architecture)
- **Limitations:** administration stays on Portkey's hosted control plane over outbound HTTPS; uncached configuration is fetched from it; new fully air-gapped deployments are no longer provisioned. [Cache behavior](https://portkey.ai/docs/self-hosting/cache-behavior) · [Feature comparison](https://portkey.ai/docs/product/product-feature-comparison)

## Is Portkey hybrid air-gapped?

A local cache reduces control-plane lookups; it does not establish complete control-plane independence. Portkey documents lazy loading of configuration objects. Objects that have not been requested are absent from the cache, and invalidated, expired or evicted objects are fetched again when needed. [Cache behavior](https://portkey.ai/docs/self-hosting/cache-behavior).

This distinction changes the test plan. Test a warm request separately from a new key, a changed configuration and a restart with an empty cache. Record which operations succeed, which fail and whether the failure matches your requirement. A demonstration using only already cached configuration cannot answer all four questions.

Log storage also needs its own review. Portkey documents local log storage and an optional Portkey-hosted store. With local storage, viewing logs in the hosted dashboard involves the control plane requesting them from the gateway. [Hybrid architecture](https://portkey.ai/docs/self-hosting/hybrid-deployments/architecture).

Ask separately where logs rest and which systems can retrieve them. If the requirement excludes external administration of request records, include dashboard viewing and export in the boundary assessment. Do not substitute “stored locally” for a description of the complete access path.

## Portkey MCP Gateway: documented controls and a permission caveat

Portkey MCP Gateway is a relevant platform option for authentication, tool-call observability and scoped rate limits. Its overview documents tool-call logs containing user, parameters and response. [MCP Gateway](https://portkey.ai/docs/product/mcp-gateway).

The detailed provisioning page documents enabling or disabling tools, resources and prompts at organization and workspace levels. Disabled capabilities are hidden and direct calls are rejected. The authorization page separately documents server-level checks against JWT claims. [Tool provisioning](https://portkey.ai/docs/product/mcp-gateway/tool-provisioning) · [Authorization](https://portkey.ai/docs/product/mcp-gateway/authorization).

The overview describes per-user tool provisioning, while the detailed guides describe organization/workspace provisioning and reserve tool-level claim-based authorization for a future release. These can be different mechanisms; the pages do not establish how every per-user rule is implemented. Verify the specific rule you need. [Overview](https://portkey.ai/docs/product/mcp-gateway) · [Tool provisioning](https://portkey.ai/docs/product/mcp-gateway/tool-provisioning) · [Authorization](https://portkey.ai/docs/product/mcp-gateway/authorization).

Portkey documents MCP rate limits using key, server, tool and metadata conditions, requiring Gateway v2.18.0+ and Backend v1.24.0+. API-key conditions are unavailable for OAuth-authenticated MCP requests; server, tool or metadata conditions apply instead. [MCP rate limits](https://portkey.ai/docs/product/mcp-gateway/rate-limits).

Test permissions with two identities and both discovery and direct invocation. A tool hidden from a list and a tool that cannot be invoked are separate observations worth recording.

- **Strengths:** tool-call logs with user, parameters and response; tools, resources and prompts can be disabled, with direct calls rejected; rate limits by key, server, tool and metadata. [Tool provisioning](https://portkey.ai/docs/product/mcp-gateway/tool-provisioning) · [Rate limits](https://portkey.ai/docs/product/mcp-gateway/rate-limits)
- **Limitations:** tool-level claim-based authorization is reserved for a future release; MCP rate limits need Gateway v2.18.0+ and Backend v1.24.0+, and API-key conditions do not apply to OAuth-authenticated requests. [Authorization](https://portkey.ai/docs/product/mcp-gateway/authorization) · [Rate limits](https://portkey.ai/docs/product/mcp-gateway/rate-limits)

## Tyk AI Studio for self-managed LLM traffic

AI Studio is the Tyk component to evaluate for LLM proxying and model administration. Its installation documentation covers Community and Enterprise self-managed deployments using Docker, Kubernetes or Linux packages. LLM management is available in both editions. [Installation](https://tyk.io/docs/ai-management/ai-studio/installation/overview) · [LLM management](https://tyk.io/docs/ai-management/ai-studio/llm-management).

Community is open source under AGPL-3.0 and does not require a commercial licence key. Review that licence against your distribution and service model before choosing it. [AI Studio repository](https://github.com/TykTechnologies/ai-studio) · [Editions](https://tyk.io/docs/ai-management/ai-studio/overview#licensing-and-editions).

For a paid deployment, connect each entitlement to the behavior you need:

- Budget enforcement and team budgets: Enterprise. Community records budget information for reporting but does not block requests when limits are exceeded. [Budget control](https://tyk.io/docs/ai-management/ai-studio/budgeting).
- Model Router and Semantic Router: Enterprise. Semantic Router runs on Edge Gateways rather than the embedded gateway. [Model Router](https://tyk.io/docs/ai-management/ai-studio/model-router) · [Semantic Router](https://tyk.io/docs/ai-management/ai-studio/semantic-router).
- Filter and guardrail execution: Enterprise. Community can create and attach filters, but they pass content through unchanged. A saved configuration is therefore not evidence of enforcement. [Filters](https://tyk.io/docs/ai-management/ai-studio/filters).

During evaluation, use an intentionally over-budget request and a request that should trigger a filter. Confirm the response and upstream effect. Keep reporting, configuration and enforcement as distinct acceptance checks.

- **Strengths:** self-managed on Docker, Kubernetes or Linux packages; Community is open source and needs no licence key; LLM management in both editions. [Installation](https://tyk.io/docs/ai-management/ai-studio/installation/overview) · [Editions](https://tyk.io/docs/ai-management/ai-studio/overview#licensing-and-editions)
- **Limitations:** budget enforcement, Model and Semantic Router and filter execution need Enterprise (Community filters pass content through unchanged); Community's [AGPL-3.0](https://github.com/TykTechnologies/ai-studio/blob/main/LICENSE.md) licence needs review; complete offline operation and an offline Enterprise licence lifecycle are not documented. [Budgets](https://tyk.io/docs/ai-management/ai-studio/budgeting) · [Filters](https://tyk.io/docs/ai-management/ai-studio/filters) · [Air-gapped guide](https://tyk.io/docs/api-management/air-gapped-deployment)

## Tyk Gateway for remote MCP servers

Tyk Gateway provides the separate remote-MCP-proxy path. Pass-through MCP proxies are available from Gateway 5.13 across licences, including the open-source Gateway. [MCP overview](https://tyk.io/docs/ai-management/mcp-gateway/overview).

Its policies can restrict JSON-RPC methods and individual tools, resources and prompts. Four rate-limit levels are documented within a policy entry: policy-wide, per proxy, per method and per primitive. Discovery filtering removes capabilities a consumer cannot call. [MCP policies](https://tyk.io/docs/ai-management/mcp-gateway/policies).

Gateway 5.14 added per-primitive OAuth2 scope enforcement and discovery filtering; its MCP functionality also includes Protected Resource Metadata handling and upstream MCP OAuth proxying. Gateway 5.16 adds MCP 2026-07-28 support, Origin validation and an MCP OAuth broker. These core MCP proxy capabilities are available in open source. Generic upstream OAuth, RFC 8693 token exchange and the Client IdP registry are separate Enterprise features. [Gateway release notes](https://tyk.io/docs/developer-support/release-notes/gateway) · [MCP licensing](https://tyk.io/docs/ai-management/mcp-gateway/overview).

For observability, Tyk documents MCP-specific access-log fields, OpenTelemetry metrics and tracing. Its licensed Dashboard includes an MCP proxy list and analytics views. [Observability](https://tyk.io/docs/ai-management/mcp-gateway/mcp-observability) · [Managing proxies](https://tyk.io/docs/ai-management/mcp-gateway/managing-proxies) · [Gateway and platform licensing](https://tyk.io/docs/tyk-oss-gateway).

If you manage the deployment through Kubernetes resources, MCP proxy support begins with Tyk Operator v1.4.0 and the TykMcpProxyDefinition resource. Operator itself requires a licence. [Operator MCP proxy documentation](https://tyk.io/docs/product-stack/tyk-operator/mcp-proxy) · [Gateway repository](https://tyk.io/docs/tyk-oss-gateway).

Choose a supported version for the protocol and controls your clients need, then verify those controls against representative requests.

- **Strengths:** MCP proxies on all licences from 5.13, including open source; per-tool, resource, prompt and method policies with four rate-limit levels and discovery filtering; 5.16 adds MCP 2026-07-28, Origin validation and an MCP OAuth broker. [MCP overview](https://tyk.io/docs/ai-management/mcp-gateway/overview) · [Policies](https://tyk.io/docs/ai-management/mcp-gateway/policies) · [Release notes](https://tyk.io/docs/developer-support/release-notes/gateway)
- **Limitations:** worth checking: MCP proxying targets Streamable HTTP, so stdio or legacy HTTP+SSE servers need a bridge; some features need an Enterprise or commercial licence (upstream OAuth, token exchange, REST-to-MCP, Dashboard, Operator). [Transport](https://tyk.io/docs/ai-management/mcp-gateway/core-concepts) · [Dashboard](https://tyk.io/docs/ai-management/mcp-gateway/managing-proxies) · [Operator](https://tyk.io/docs/product-stack/tyk-operator/mcp-proxy) · [REST-to-MCP](https://tyk.io/docs/ai-management/mcps/api-to-mcp)

## Two different ways to expose APIs as MCP tools

AI Studio tools over MCP and Gateway REST-to-MCP are different features with different entitlements. You do not automatically need both products for every MCP workload.

AI Studio can expose its OpenAPI-derived tools at /tools/{slug}/mcp in Community and Enterprise. From v2.2.0, a newly created tool is chat-only until its required access method is enabled. Its separate Tyk Dashboard MCP integration is Enterprise. [AI Studio tools](https://tyk.io/docs/ai-management/ai-studio/tools) · [Dashboard integration](https://tyk.io/docs/ai-management/ai-studio/tyk-mcp-integration).

Gateway’s REST-to-MCP feature instead generates an MCP proxy from a Tyk OAS API already onboarded to Tyk. It requires Gateway 5.15 or later and Enterprise. Do not extend the Community entitlement of AI Studio tools to this Gateway feature. [REST API to MCP](https://tyk.io/docs/ai-management/mcps/api-to-mcp).

Choose the path by the system you are managing. For a tool defined inside AI Studio, evaluate that tool’s MCP endpoint and access methods. For a remote MCP server, evaluate Gateway’s proxy controls. For an existing Tyk OAS API, assess Gateway’s conversion workflow and paid entitlement. Those are separate evaluation paths documented by Tyk. [Tools](https://tyk.io/docs/ai-management/ai-studio/tools) · [MCP overview](https://tyk.io/docs/ai-management/mcp-gateway/overview) · [REST API to MCP](https://tyk.io/docs/ai-management/mcps/api-to-mcp).

## What Tyk documents about air-gapped installation

Tyk has a documented procedure for preparing API-management installation artifacts for a restricted network. The guide covers mirroring container images, packaging Helm charts and creating a local PackageCloud package mirror. [Air-gapped deployment](https://tyk.io/docs/api-management/air-gapped-deployment).

That addresses a concrete installation problem: obtaining approved software when the target environment cannot fetch public artifacts. It should become part of a reproducible release process, with pinned versions, an inventory of dependencies and an approved transfer route.

The guide does not name AI Studio. AI Studio is separately documented as self-managed, but its complete offline operation and offline Enterprise licence lifecycle remain not documented in the reviewed sources. Community’s lack of a commercial licence-key requirement does not answer the dependency question for every configuration. [AI Studio installation](https://tyk.io/docs/ai-management/ai-studio/installation/overview) · [Editions](https://tyk.io/docs/ai-management/ai-studio/overview#licensing-and-editions).

For a disconnected deployment, obtain a component-specific dependency list and test installation, restart, restoration, policy administration and credential renewal under the intended network restrictions. Include the model endpoints, MCP servers, identity services and log destination in that test boundary. Approve the whole working configuration, not only the gateway container.

## When Tyk is not the right choice

Tyk is a poor fit when its licence, transport or documented deployment boundary conflicts with a hard requirement. Establish that before investing in migration.

### You need a permissively licensed LLM gateway

Portkey’s gateway uses MIT, while AI Studio Community uses AGPL-3.0. If MIT is a firm selection requirement, keep Portkey OSS on the shortlist and review its exact feature set. [Portkey licence](https://github.com/Portkey-AI/gateway/blob/main/LICENSE) · [AI Studio licence](https://github.com/TykTechnologies/ai-studio/blob/main/LICENSE.md).

### You need enforced budgets and guardrails without an Enterprise licence

AI Studio Community does not enforce spending limits or execute filters. Its Enterprise edition is required for those controls. A configuration screen or a reporting counter is not a substitute for request blocking. [Budgeting](https://tyk.io/docs/ai-management/ai-studio/budgeting) · [Filters](https://tyk.io/docs/ai-management/ai-studio/filters).

### You need documented end-to-end offline AI Studio operation now

That complete lifecycle is not documented in the reviewed sources. If formal documentation is an immediate procurement gate, the current material does not satisfy it. Resolve the requirement before committing. [Installation](https://tyk.io/docs/ai-management/ai-studio/installation/overview) · [Editions](https://tyk.io/docs/ai-management/ai-studio/overview#licensing-and-editions).

### Your MCP servers require unsupported transports

Tyk Gateway supports Streamable HTTP, not direct stdio or the older separate HTTP+SSE transport. SSE responses within Streamable HTTP are a different mechanism and are supported. Gateway 5.16 documents support for MCP 2025-11-25 and 2026-07-28. [Core concepts](https://tyk.io/docs/ai-management/mcp-gateway/core-concepts) · [Protocol versions](https://tyk.io/docs/ai-management/mcp-gateway/protocol-versions).

### You need Gateway conversion outside its documented scope

Gateway REST-to-MCP requires an onboarded Tyk OAS API and Enterprise. If your proposed conversion depends on another API-definition format or an unlicensed installation, that feature does not meet the stated requirement. [API to MCP](https://tyk.io/docs/ai-management/mcps/api-to-mcp).

Finally, migration needs a reason beyond the availability of another gateway. If your current deployment passes the ownership and behavior checks that matter, changing products may add work without resolving a concrete problem.

## How to choose: build a short acceptance record

Choose the option that passes your mandatory requirements in the intended edition and deployment. A feature-count comparison cannot settle control-plane ownership or disconnected operations.

Create one record for each requirement with five fields: required behavior, exact component/version, required edition, primary-source link and observed result. Mark unresolved items explicitly instead of converting them into a checkmark.

Use requirements such as these:

| Requirement | Evidence to collect |
|---|---|
| Administration remains internal | Create a user, issue a credential and change a policy while recording attempted network connections. |
| Tool access is enforced | Show that an unauthorized identity cannot discover or directly invoke a restricted tool. |
| Spending is controlled | Show the expected refusal at the configured boundary and verify that the model provider was not called. |
| Logs meet the ownership requirement | Trace storage, dashboard retrieval, export and deletion through the intended systems. |
| Offline operation is sustainable | Rebuild or restore the deployment and renew required credentials under the approved connectivity rules. |

Keep unknowns separate from failed tests. An undocumented requirement needs evidence; a failed test needs a different configuration, a product change or another candidate. This distinction gives engineering and procurement a shared basis for deciding what remains unresolved.

## Migration and acceptance checklist

Migrate one defined workload at a time, with a rollback path. The objective is to preserve required behavior while changing the deployment boundary. The following is a proposed evaluation workflow, not a claim that a migration has been tested.

- Inventory what the application actually uses. Record client libraries, request formats, model identifiers, credentials, streaming behavior, retries, fallbacks, prompt assets, tool servers and log consumers. Include failure paths. Separate essential behavior from features that happen to be configured but are unused.
- Write expected outcomes before configuring the replacement. Define which identity may call which model or tool, what happens when a budget is exhausted and which events must be recorded. Make rejection cases explicit. A successful request alone does not demonstrate that an authorization rule works.
- Map each requirement to a component and edition. Distinguish LLM spending limits from MCP request limits. Identify where administration runs and which product owns each credential. Put the supporting documentation next to the mapping so reviewers can see both the capability and its entitlement.
- Prepare a reproducible staging installation. Pin images, charts, packages and configuration. Apply the same network restrictions intended for production. Record every external destination attempted during installation and normal use, then decide whether each one is permitted.
- Exercise both allowed and refused requests. Test normal responses, streaming, provider errors, unavailable upstreams, unauthorized identities, denied tools and exhausted limits. Compare response bodies, status codes and upstream effects with the written expectations. Capture enough evidence to explain a mismatch.
- Test changes and recovery. Add a new key, edit a policy, rotate a credential, restart the deployment and restore from backup. For disconnected requirements, repeat the relevant checks without outbound access. Include log viewing and export, not just log creation.
- Cut over gradually and retain rollback. Start with one application and, if needed, one MCP service. Observe the agreed acceptance conditions before expanding. Keep the old route and its configuration available until the replacement is accepted by the people responsible for the workload.

The useful deliverable is an evidence-backed decision: what the chosen deployment does, which licence it needs, which connections remain and which requirements are still unresolved.

## FAQ

### Can Portkey be self-hosted?

Yes. Portkey’s MIT gateway can run locally. Its commercial hybrid offering retains hosted administration. New fully air-gapped enterprise deployments are no longer provisioned; existing ones remain supported. [Repository](https://github.com/Portkey-AI/gateway) · [Deployment status](https://portkey.ai/docs/product/product-feature-comparison).

### Is Portkey hybrid fully air-gapped?

No. Hybrid retains a Portkey-hosted control plane. Caching does not make administration local or eliminate lookups for missing configuration. [Cache behavior](https://portkey.ai/docs/self-hosting/cache-behavior).

### Is Tyk an open-source Portkey alternative?

Tyk provides open-source components: AI Studio Community is AGPL-3.0 and the core Gateway is MPL-2.0. AI Studio budget enforcement and filter execution require Enterprise, as does Gateway REST-to-MCP. [AI Studio](https://github.com/TykTechnologies/ai-studio) · [Gateway](https://tyk.io/docs/tyk-oss-gateway) · [Budgets](https://tyk.io/docs/ai-management/ai-studio/budgeting) · [Filters](https://tyk.io/docs/ai-management/ai-studio/filters) · [REST-to-MCP](https://tyk.io/docs/ai-management/mcps/api-to-mcp).

### Do I need both AI Studio and Tyk Gateway?

No. Evaluate AI Studio for LLM proxying and its own tools over MCP; evaluate Gateway for proxying remote MCP servers. Select the components your workload requires. [LLM proxy](https://tyk.io/docs/ai-management/ai-studio/proxy) · [AI Studio tools](https://tyk.io/docs/ai-management/ai-studio/tools) · [Gateway overview](https://tyk.io/docs/ai-management/mcp-gateway/overview).

### Are Tyk’s newer MCP security features Enterprise-only?

No. Per-primitive scopes, discovery filtering, PRM mirroring, Origin validation and the MCP OAuth broker are open-source Gateway features. Generic upstream OAuth, RFC 8693 token exchange and the Client IdP registry require Enterprise. [Release notes](https://tyk.io/docs/developer-support/release-notes/gateway) · [Licensing scope](https://tyk.io/docs/ai-management/mcp-gateway/overview).

### Is AI Studio verified for a completely disconnected deployment?

A complete offline AI Studio deployment and offline Enterprise licence lifecycle are not documented in the sources reviewed. Tyk’s API-management air-gap installation guide should not be treated as an AI Studio-specific guarantee. [Air-gap guide](https://tyk.io/docs/api-management/air-gapped-deployment) · [AI Studio installation](https://tyk.io/docs/ai-management/ai-studio/installation/overview) · [Editions](https://tyk.io/docs/ai-management/ai-studio/overview#licensing-and-editions).

### Does self-hosting guarantee that all AI data stays on premises?

No. Hosting the gateway locally does not determine the location of model endpoints, identity services or log viewers. Review every connection and test the complete deployment against the intended boundary. Include administrative and recovery operations in the assessment.

## Sources

### Portkey
- [Open-source gateway documentation](https://portkey.ai/docs/product/open-source)
- [Gateway repository](https://github.com/Portkey-AI/gateway) and [MIT licence](https://github.com/Portkey-AI/gateway/blob/main/LICENSE)
- [Hybrid deployment architecture](https://portkey.ai/docs/self-hosting/hybrid-deployments/architecture) and [cache behavior](https://portkey.ai/docs/self-hosting/cache-behavior)
- [Product feature comparison and air-gapped status](https://portkey.ai/docs/product/product-feature-comparison)
- [MCP Gateway](https://portkey.ai/docs/product/mcp-gateway), [authorization](https://portkey.ai/docs/product/mcp-gateway/authorization), [tool provisioning](https://portkey.ai/docs/product/mcp-gateway/tool-provisioning) and [rate limits](https://portkey.ai/docs/product/mcp-gateway/rate-limits)

### Tyk
- [AI Studio installation](https://tyk.io/docs/ai-management/ai-studio/installation/overview), [repository and licence](https://github.com/TykTechnologies/ai-studio), and [editions](https://tyk.io/docs/ai-management/ai-studio/overview#licensing-and-editions)
- [LLM proxy](https://tyk.io/docs/ai-management/ai-studio/proxy) and [LLM management](https://tyk.io/docs/ai-management/ai-studio/llm-management)
- [Budgeting](https://tyk.io/docs/ai-management/ai-studio/budgeting), [Model Router](https://tyk.io/docs/ai-management/ai-studio/model-router), [Semantic Router](https://tyk.io/docs/ai-management/ai-studio/semantic-router) and [filters](https://tyk.io/docs/ai-management/ai-studio/filters)
- [MCP Gateway overview](https://tyk.io/docs/ai-management/mcp-gateway/overview), [policies](https://tyk.io/docs/ai-management/mcp-gateway/policies) and [observability](https://tyk.io/docs/ai-management/mcp-gateway/mcp-observability)
- [API to MCP](https://tyk.io/docs/ai-management/mcps/api-to-mcp), [protocol versions](https://tyk.io/docs/ai-management/mcp-gateway/protocol-versions) and [core concepts](https://tyk.io/docs/ai-management/mcp-gateway/core-concepts)
- [Managing MCP proxies](https://tyk.io/docs/ai-management/mcp-gateway/managing-proxies) and [Operator MCP proxies](https://tyk.io/docs/product-stack/tyk-operator/mcp-proxy)
- [AI Studio tools](https://tyk.io/docs/ai-management/ai-studio/tools) and [Dashboard MCP integration](https://tyk.io/docs/ai-management/ai-studio/tyk-mcp-integration)
- [Air-gapped deployment](https://tyk.io/docs/api-management/air-gapped-deployment), [Gateway repository and licence](https://tyk.io/docs/tyk-oss-gateway), and [Gateway release notes](https://tyk.io/docs/developer-support/release-notes/gateway)