The main self-hosted LiteLLM alternatives are Tyk, Bifrost, Portkey, Kong, Agent Router and MLflow; OpenRouter is the hosted option. Choose by whether spending limits must block requests, whether every management service must stay inside your network, and whether the gateway must authorize individual MCP tools. LiteLLM's security record is also part of the evaluation: attackers published malicious LiteLLM releases twice in 2026, versions 1.82.7 and 1.82.8 to PyPI on 24 March and version 1.107.0 to PyPI and its Docker images on 21 October, and as of 30 October 2026 the BerriAI/litellm repository lists 18 published security advisories, 5 rated critical. March incident · PyPI incident report · October incident · Security advisories.
Last updated: 30 October 2026
Start with three questions: must spending limits block requests, must all management services stay inside your network, and must the gateway authorize individual MCP tools? Use those answers to narrow the table before comparing feature counts. For the basics, see what an LLM gateway is; for a wider self-hosted shortlist, see open-source AI gateways compared.
How we compared: Tyk publishes this comparison and is one of the options discussed. We compared public documentation, licences, repositories, release notes, security advisories 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 and Portkey self-hosted alternative.
Why switch from LiteLLM?
LiteLLM already documents model proxying, virtual keys, budgets, load balancing, an admin UI, guardrails and an MCP gateway. Its repository and edition matrix are the baseline to compare against. Its licence applies MIT outside the separately licensed enterprise/ directory.
Look elsewhere when a specific deployment, licence or operational requirement remains unmet. First verify the configuration: LiteLLM’s budget enforcement requires a database, and selected guardrail integrations require Enterprise. A missing dependency or edition entitlement is different from a missing product capability.
- Strengths: MIT core with model proxying, virtual keys, blocking budgets, an admin UI and an MCP gateway with tool permissions. Repository · Budgets · MCP
- Limitations: budgets are enforced only with a database; selected guardrail integrations need Enterprise; malicious releases were published in March and October 2026 (see the security track record below). Budgets · Editions · October incident
Which LiteLLM alternative can be self-hosted?
Self-hosted does not automatically mean fully disconnected. Also distinguish spend reporting from blocking budgets, and MCP registries from gateways that enforce tool permissions. “Not documented” below describes the reviewed first-party materials, not proof of absence.
Security track record
LiteLLM's own disclosures and public advisories show the following 2026 security events.
- 24 March 2026: malicious releases 1.82.7 and 1.82.8 were published to PyPI and were live for about 40 minutes before PyPI quarantined them. LiteLLM attributes the compromise to the compromised Trivy scanner used in its CI/CD workflow. The PyPI advisory is PYSEC-2026-2, and PyPI reports more than 119,000 downloads of the affected versions during the window. LiteLLM post · PyPI incident report
- 21 October 2026: LiteLLM's release pipeline was compromised and published 1.107.0 to PyPI for about 2 hours and to Docker Hub and GHCR images, with credential-stealing and remote-code-execution payloads. LiteLLM states that enterprise customers using its private enterprise release were not affected. LiteLLM post · Microsoft Security Blog analysis
- 2026 GitHub security advisories: 18 published as of 30 October 2026 (5 critical, 6 high, 5 medium, 2 low). These are disclosed vulnerabilities, not breaches. Security advisories
Teams self-hosting any AI gateway should pin exact package versions and container image digests rather than floating tags such as latest, and verify release provenance before upgrading.
Tyk AI Studio and Tyk Gateway
Evaluate Tyk when you want separate controls for model access and MCP tools, and can accept its edition boundaries. AI Studio provides the LLM proxy and model configuration; Gateway provides MCP proxy governance. AI Studio supports Docker, Kubernetes and Linux packages.
Community includes failover and cost tracking. Its budget records support reporting, while request-blocking enforcement needs Enterprise. The model router, semantic router and filter execution also need Enterprise. These distinctions appear in the edition comparison and budget guide.
Gateway’s remote MCP proxies are available on all licences from 5.13. Policies authorize tools, resources, prompts and JSON-RPC methods, with four policy rate-limit levels: global, proxy, method and primitive. MCP telemetry includes access logs, metrics and traces. See the MCP overview, policies and observability documentation.
For remote proxies, 5.14 adds per-primitive OAuth2 scopes, upstream Protected Resource Metadata mirroring and OAS-based discovery filtering; 5.16 adds Origin validation and an MCP OAuth broker. Tyk documents remote MCP proxies on all Gateway licences, and names individual features such as upstream OAuth and token exchange as Enterprise. Confirm the edition of each feature you depend on with Tyk. See the release notes and licensing requirements.
Gateway 5.16 documents MCP 2025-11-25 and 2026-07-28 support. Its transport is Streamable HTTP; stdio and legacy HTTP+SSE are unsupported. SSE responses within Streamable HTTP are a separate matter. See protocol versions and core concepts.
AI Studio can expose OpenAPI-derived tools over MCP in Community and Enterprise; from v2.2.0, new tools require MCP to be enabled. That differs from Gateway’s REST-to-MCP feature, which requires Tyk OAS APIs, Gateway 5.15+ and Enterprise. See Studio tools and API-to-MCP.
- Strengths: separate controls for model traffic (AI Studio) and MCP tools (Gateway); MCP proxies on all Gateway licences with per-tool, resource, prompt and method policies and rate limits; self-managed on Docker, Kubernetes or Linux packages. MCP overview · Policies · Installation
- Limitations: worth checking: budgets, model routing and guardrail filters need AI Studio Enterprise (Community is AGPL-3.0); Gateway MCP transport is Streamable HTTP only (no stdio or legacy HTTP+SSE), and sampling, elicitation and roots don't pass through the proxy; complete offline AI Studio operation is not documented. Budgets · Filters · Transport · Protocol versions · Air-gapped guide
Bifrost
Bifrost merits a shortlist when free virtual keys, budgets and MCP gateway functionality are priorities. Its repository documents local deployment, failover and load balancing. The MCP documentation describes the client and gateway, and the vendor’s MCP FAQ explicitly confirms open-source availability.
Check the deployment topology before relying on budget enforcement. Bifrost’s budget documentation says multiple OSS nodes with a shared Postgres backend are unsupported; distributed budget state belongs to Enterprise. Its example allows a request to cross a budget threshold, then blocks the next request. Guardrails are also Enterprise. Test the open-source configuration you intend to deploy.
- Strengths: Apache-2.0 open-source virtual keys, budgets and MCP gateway, plus failover and load balancing. Repository · MCP
- Limitations: multiple OSS nodes sharing Postgres are unsupported (distributed budget state is Enterprise); a request can cross the budget before the next one is blocked; guardrails are Enterprise. Budgets · Guardrails
Portkey
Portkey offers a permissively licensed local gateway, but its OSS release and hosted platform need separate evaluation. The open-source documentation covers retries, fallbacks and load balancing, while the README includes Config-based input/output guardrails.
Portkey’s Gateway 2.0 announcement announces budget limits for the expanded open-source gateway. However, its README still labels 2.0 pre-release. Confirm the branch, image and enforcement behavior before counting that feature as available in your chosen stable deployment.
Portkey also announces an open-source MCP gateway. Its hybrid architecture runs the data plane in your network while requiring outbound HTTPS to Portkey’s control plane. That requirement describes hybrid deployment; it should not be imposed on the standalone MIT gateway by implication.
- Strengths: MIT local gateway with retries, fallbacks, load balancing and Config guardrails. Open source · README
- Limitations: open-source budget limits come with Gateway 2.0, which the README still marks pre-release; hybrid needs outbound HTTPS to Portkey's control plane; no new fully air-gapped deployments. Hybrid architecture · Deployment status
Kong AI Gateway
Kong is worth evaluating when your AI traffic should use existing Kong operating practices. Its AI Gateway documentation covers LLM, MCP and A2A traffic, but the current 2.x architecture uses a Konnect-managed control plane. On-premises deployment instead uses Kong Gateway Services, Routes and AI plugins; do not assume every 2.x entity has an equivalent there.
The open-source plugin list includes AI Proxy, Prompt Guard, Prompt Decorator, Prompt Template and request/response transformers. AI Proxy Advanced, AI Rate Limiting Advanced and AI MCP Proxy require AI Gateway Enterprise. Confirm the licence and test that exact plugin combination.
- Strengths: Apache-2.0 core with open-source AI Proxy and Prompt Guard plugins; fits existing Kong operations. Licence · Plugin list
- Limitations: AI Proxy Advanced, AI Rate Limiting Advanced and AI MCP Proxy need AI Gateway Enterprise; the 2.x architecture uses a Konnect-managed control plane. AI MCP Proxy · Architecture
Agent Router, formerly Envoy AI Gateway
Agent Router fits teams that want Envoy-based LLM and MCP traffic controls. The project documentation confirms the rename and documents failover. Its getting-started guide offers both a standalone CLI and Kubernetes deployment, so Kubernetes is not mandatory for every use.
The project documents token quotas and MCP aggregation, OAuth and tool authorization. Do not label token quotas as dollar budgets. Built-in content guardrails remain not documented for the OSS project in the reviewed materials; Tetrate’s edition comparison lists runtime guardrails in its separate Enterprise offering.
Quota enforcement also needs Redis and a dedicated service that the Helm chart does not install. The default permits requests if that service is unavailable; a setting changes this to rejection. Include these dependencies and failure behavior in your test, following the quota-policy guide.
- Strengths: Apache-2.0 and Envoy-based; standalone CLI or Kubernetes; token quotas plus MCP aggregation, OAuth and tool authorization. Getting started · MCP
- Limitations: quotas count tokens, not dollars, and need Redis plus a service the Helm chart does not install, and they allow requests by default if that service is down; open-source content guardrails are not documented. Quota policy
MLflow AI Gateway
MLflow is worth evaluating if your team already operates MLflow and wants gateway administration alongside it. Its AI Gateway documents endpoint configuration, provider credentials, traffic splitting, fallbacks and usage tracking.
Check what key management means during migration. MLflow’s LLM connections store reusable upstream provider credentials. That page does not establish equivalent per-application virtual-key functionality; verify your client-identity requirements separately.
Its budget controls distinguish alerts from rejection. Rejection blocks subsequent requests after a threshold is crossed; shared enforcement across workers or replicas requires the Redis tracker. LLM-judge guardrails can block or sanitize content, but post-LLM checks do not run on streaming responses.
MLflow’s experimental MCP registry catalogs servers. Do not treat a registry entry as evidence of runtime per-tool authorization. Test those requirements separately if agents will call tools through your deployment.
- Strengths: Apache-2.0; fits teams already running MLflow; traffic splitting, fallbacks, alert-or-reject budgets and LLM-judge guardrails. AI Gateway · Budgets
- Limitations: per-application virtual keys are not documented; shared budget enforcement needs Redis; post-LLM guardrails do not run on streaming responses; the MCP registry is experimental. Guardrails · MCP registry
OpenRouter: the hosted alternative
OpenRouter is an alternative when you want a hosted model API rather than another gateway deployment to operate. Its quickstart documents the API; routing documentation explains provider selection using price, throughput, latency and reliability. Avoid describing this as a guarantee of the cheapest provider on every request.
Its guardrails include content controls and per-user/per-key budget restrictions. Its MCP server helps developer agents explore models, documentation and account information. That differs from a gateway enforcing policies on your own MCP servers; the latter is not documented there.
- Strengths: nothing to operate; provider routing; per-user and per-key budgets and content controls. Routing · Guardrails
- Limitations: hosted API only, not self-hosted; policy enforcement on your own MCP servers is not documented. Quickstart · MCP server
TensorZero: account for its archived status
Do not evaluate TensorZero as a maintained alternative without taking ownership of maintenance. Its website says it is no longer maintained, and its repository is archived. Historical features include routing, fallbacks, experimentation, cost tracking and rate limits.
Existing users can still inspect the archived code, but a new deployment needs an owner for fixes, provider changes and security updates. Assess that maintenance commitment before comparing its historical feature list with actively maintained options.
- Strengths: Apache-2.0 code with historical routing, fallbacks, cost tracking and rate limits. Repository
- Limitations: archived and no longer maintained, so you would own fixes and security updates. Website
When Tyk is not the right choice
Choose another option when Tyk’s paid controls, licence or transport restrictions conflict with your requirements. In particular:
- You require free blocking budgets or guardrail execution. AI Studio Community records spend, but enforcement and filter execution require Enterprise.
- You require a permissive licence for the Studio application. Community uses AGPL-3.0. Assess that licence before adopting it.
- Your MCP upstreams require stdio or legacy HTTP+SSE. Gateway’s documented transport support is Streamable HTTP.
- Your agents require stateful sampling, elicitation or roots. Tyk’s protocol guide says these features do not work through the proxy because client responses to server requests are rejected. Supported version numbers alone do not establish complete protocol coverage.
- You need a documented, completely disconnected AI Studio installation today. Tyk’s air-gapped guide covers the API management stack; it does not document end-to-end AI Studio operation or offline Enterprise licence handling. Confirm these requirements before selecting it.
Compare model traffic and tool traffic separately
A model proxy test does not establish that an agent’s tools are governed. Build separate acceptance tests for model requests and MCP operations. For models, exercise normal completions, streaming, provider errors and fallback behavior. For tools, test discovery and invocation with identities that have different permissions.
For example, give a test identity access to a read-only operation while withholding access to a write operation. Check both whether the write operation appears in discovery and whether a direct invocation is rejected. Repeat after changing the policy, reconnecting the client and restarting the gateway. This tests the behavior you need without relying on a feature checkbox.
Also decide what “guardrails” means for your application: a prompt allowlist, a PII filter, a model-based content check or permission to execute a tool. Specify the expected behavior on streaming responses and when a check cannot complete. Compare each candidate against that definition.
How to choose and migrate
Build a shortlist around enforceable requirements, then test a pinned release of each candidate. Treat migration as a change to policy behavior, not just a new API base URL.
Make a small decision record for each requirement: the source, edition, configuration, acceptance test and result. For deployment, draw the boundary around the data plane, management service, database, identity provider and licensing service. Mark every required outbound connection. This makes “self-hosted” a reviewable architecture instead of a label.
- Inventory the current contract: models, endpoints, streaming, tool calling, virtual keys, team budgets, retries, callbacks and logs.
- Record the edition and dependencies: databases, shared counters, control-plane connections and licences. Specify what happens if each dependency fails.
- Test budget semantics: alerts versus blocking, concurrent requests, restarts, multiple workers and requests that cross the threshold.
- Test MCP independently: discovery filtering, invocation permissions, upstream authentication and transport compatibility.
- Replay sanitized test cases: compare responses, errors, usage accounting and guardrail outcomes before sending production traffic.
- Move one application at a time: use controlled traffic splitting and a rollback path. Avoid duplicating tool calls that change external systems.
Stay with LiteLLM when its documented budgets, routing and MCP controls already meet the requirement. A migration should resolve a demonstrated gap.
FAQ
Is LiteLLM fully open source?
Its licence applies MIT to code outside enterprise/; that directory has separate terms. Check the edition matrix for your required features. An open-source core does not mean every integration and administrative control shares the same licence.
What is the best open-source LiteLLM alternative?
There is no universal winner. Shortlist Bifrost for keys and budgets, Portkey for an MIT local gateway, Agent Router for Envoy-based operations, or MLflow when it already fits your platform. Verify the exact release and edition against your mandatory controls.
Which alternatives include free blocking budgets?
Bifrost and MLflow document OSS budget enforcement with deployment qualifications. Portkey announces it for 2.0, but its README still marks 2.0 pre-release. AI Studio enforcement requires Enterprise.
Does LiteLLM enforce hard budget limits?
Yes, when it runs with a database. LiteLLM's proxy rejects requests once a virtual key, user, team or customer passes its max_budget, and by default reserves a request's estimated cost before sending it. Without a Postgres database no budget is enforced, and the global max_budget fails open. Per-model budgets on keys and users require a LiteLLM Enterprise licence, and fail_closed_budget_enforcement keeps budgets a hard ceiling while Redis is degraded. LiteLLM budgets and rate limits.
LiteLLM vs OpenRouter: which should I choose?
Choose by operational ownership: LiteLLM provides gateway software you can operate; OpenRouter provides a hosted API. Compare deployment requirements, provider access, credential management and enforcement behavior before changing clients.
Kong AI Gateway vs LiteLLM: what is the main difference?
Compare the actual deployment and edition. LiteLLM documents an OSS proxy with an Enterprise extension. Kong documents self-managed AI plugins and a separate Konnect-managed AI Gateway control plane. Your required plugins and management topology determine the fit.
Which alternatives support an air-gapped deployment?
Bifrost Enterprise explicitly documents air-gapped deployment. Tyk’s guide covers its API management stack, without establishing complete AI Studio offline support. Portkey says it no longer provisions new fully air-gapped deployments. Check installation, updates, licensing and all runtime dependencies.
Do I need a separate MCP gateway?
Only if your selected deployment cannot enforce the tool controls you need. LiteLLM, Bifrost and Agent Router document MCP gateway capabilities. Tyk’s remote MCP proxies are another option; evaluate permissions and transports rather than an undifferentiated “MCP: yes” label.