LiteLLM vs Portkey: when each one is the right gateway
A platform team choosing a shared gateway for private models should start with governance. LiteLLM fits organizations that need virtual keys, per-team budgets and spend tracking kept in their own PostgreSQL database. Virtual keys can carry per-key, per-user and per-team budgets, TPM and RPM limits and model restrictions, which is the control set most finance and security reviewers ask about first. Portkey fits teams that mainly want a lightweight routing layer, with retries, fallbacks, load balancing and guardrail configs attached to the client through JSON configs. It is a narrower tool for routing and policy at the request level, and it does not center on per-team cost control in the way LiteLLM does.
The second question is how much infrastructure your team wants to run. LiteLLM's production guide names PostgreSQL as the primary supported database and requires Redis 7.0 or newer once more than one proxy instance runs, for shared rate limits, router state and cache. Plan for those two services, their backups and their upgrades as part of the platform. Portkey's local gateway runs with npx @portkey-ai/gateway on port 8787 and offers Docker and Docker Compose deployment, which lowers the starting cost, but a shared, multi-team deployment with budgets still needs a design for where state lives. Confirm with Portkey exactly which features in your target edition depend on its managed services before you commit.
The third question is how comfortable your organization is with Portkey's documented recommendation. The gateway README marks deployment to Portkey Cloud as recommended, and Palo Alto Networks announced on May 29, 2026 that it had closed its acquisition of Portkey and that Portkey would be the foundational AI Gateway for its Prisma AIRS platform. That announcement does not address the open-source gateway, so ask Portkey in writing how the MIT-licensed gateway and the 2.0 pre-release will be maintained and which enterprise features will stay available for self-hosting. If your data residency rules require every gateway to run in your own cloud accounts, that answer decides the choice.
Which gateway fits which scenario
This table maps common LiteLLM and Portkey scenarios to the better fit and the condition that drives the choice. Read each row as a starting point, then confirm the condition against your own controls, team size and data residency requirements.
| Scenario | Better fit | Reason and condition |
|---|---|---|
| Central AI gateway with budgets per team | LiteLLM | Virtual keys with per-key, per-user and per-team budgets and TPM or RPM limits need PostgreSQL, which you run in your own infrastructure. Matters if finance or platform owners need spend control per team. |
| Small app team needing fallbacks across providers | Portkey | The gateway runs locally through npx on port 8787 and uses JSON configs for retries, fallbacks and load balancing. Matters if the team wants a light, config-driven setup without a database. |
| Organization that must keep spend data in its own database | LiteLLM | LiteLLM's production guide names PostgreSQL as the primary supported database and spend tracking runs there. Confirm that your retention and access rules match how spend records are stored and batched. |
| Team already committed to Portkey's API | Portkey | Portkey's managed deployment and Model Catalog at app.portkey.ai fit a team that already uses Portkey keys and providers. Confirm data handling terms with Portkey, since the README recommends Portkey Cloud for production. |
| Need for key management, RBAC, IP rules and PII redaction | Portkey | Portkey's enterprise deployment adds secure key management with RBAC, IP and geo inbound rules and PII redaction. This matters only if you need those controls and are prepared to confirm the enterprise terms. |
| Need for SSO, audit logs and SCIM | LiteLLM | SSO is free for up to 5 users from v1.76.0, and SCIM, audit logs and organization RBAC sit in the Enterprise license. Confirm the license needed for your user count before choosing. |
| Existing LiteLLM codebase moving to a new gateway | Portkey | Portkey publishes a migrate-litellm-to-portkey skill that maps completion calls, Router, Proxy, fallbacks and caching to Portkey configs. Test the mapped behavior in your own environment before cutover. |
| Open-source-only strategy with source-level control of the gateway | Depends | Both repositories are MIT licensed. Portkey's 2.0 pre-release is merging enterprise gateway features into open source, so confirm which features your version includes before committing. |
How each gateway is built and what that means for operations
The two gateways keep state in different places, and that decides what your team runs, patches and backs up. LiteLLM centers on a stateful proxy with PostgreSQL and, at scale, Redis. Portkey's open-source gateway is a stateless routing layer whose behavior lives in configs attached to each client.
LiteLLM proxy and Python SDK
LiteLLM ships two modes: an SDK your applications import, and a proxy server that acts as a shared gateway with virtual keys, budgets and an admin UI. Choosing the proxy means your organization runs a service that every model call passes through, so it needs an owner, a deployment pipeline and capacity planning. Check whether each team can call models through the SDK directly or must route everything through the proxy, because that choice sets how much traffic the proxy carries.
PostgreSQL holds keys and spend
Virtual keys need a PostgreSQL database, and per-key, per-user and per-team budgets and spend records live there. Losing that database means losing issued keys, budget state and the spend history that finance and security teams may rely on. Your team must back it up, test restores and control access to it. Ask whether your backup schedule matches how much spend data you can afford to lose, since LiteLLM batches spend updates to the database every 60 seconds at scale.
Redis 7.0 for multiple proxies
Once more than one proxy instance runs, LiteLLM requires Redis 7.0 or newer for shared rate limits, router state and cache. A single-instance pilot can run without it, but a highly available deployment cannot treat Redis as optional. The operational consequence is a second stateful service to monitor, patch and fail over. Confirm how your team will handle Redis outages, since rate limits and router cooldowns depend on it.
Portkey gateway with JSON configs
Portkey's open-source gateway is a lightweight routing layer. Retries, fallbacks, load balancing, conditional routing and guardrails are described in JSON configs that your application attaches to each client request. Routing logic therefore lives in application code and config files, which your teams version and review alongside the apps. Check that every service sends the intended config, because a missing or outdated config changes failover behavior without any error on the proxy side.
Local Gateway Console
Running the gateway locally with npx on port 8787 starts a Gateway Console that shows local logs. This is useful for development and for verifying configs, but it is not a shared audit store or a production observability system. Before relying on it, ask Portkey which logs persist when the gateway restarts and where production request logs should go. Plan for a separate logging path if your auditors need request records.
Deployment options for the gateway
The gateway runs through Docker, a Node.js server, Cloudflare Workers and Docker Compose, among other platforms, and Portkey's managed API is the option its README marks as recommended. Self-hosting on Docker or Node.js keeps the gateway inside your network, but your team patches the container image and manages scaling. Cloudflare Workers places the gateway on an external edge platform, so confirm data residency and network controls before choosing it for regulated traffic.
Feature comparison: virtual keys, routing, identity and audit
This table compares how each MIT-licensed gateway handles access control, routing, identity and audit, using only documented features. Read the cells as a checklist: where a row says to confirm, the supplied documentation does not settle the point, so ask the vendor before you commit.
| Capability | LiteLLM (MIT proxy) | Portkey gateway (MIT) |
|---|---|---|
| Per-key, per-user and per-team budgets | Supported on virtual keys, which require a PostgreSQL database | Not covered in the gateway README; confirm budget controls and where they are stored |
| TPM and RPM limits | Supported on virtual keys | Rate limiting not covered in the supplied gateway facts; confirm with Portkey |
| Restricting keys to specific models | Supported on virtual keys | Achieved through config routing; confirm per-key model restrictions |
| Routing strategies | Simple-shuffle, usage-based, latency-based, least-busy and cost-based routing | Load balancing and conditional routing defined in JSON configs attached to the client |
| Retries, cooldowns and failover | Retries, cooldowns after repeated failures and priority ordering for failover | Automatic retries and fallbacks listed in the README; confirm cooldown behavior |
| Admin UI SSO | Google, Microsoft Entra ID, Okta and generic OIDC; free for up to 5 users from v1.76.0 | Gateway Console covers local logs; confirm SSO options for the self-hosted gateway |
| Enterprise identity and audit | SSO and SCIM beyond 5 users, JWT auth, audit logs and organization and team RBAC need an Enterprise license | RBAC key management, caching and PII redaction sit in the enterprise deployment; confirm audit log support |
| Guardrails and MCP | Team-level guardrails and logging are an Enterprise feature; licensed guardrail integrations apply | Guardrails and an MCP Gateway are listed in the README; confirm which guardrails run in the open-source build |
What is MIT, what is paid and what to confirm before you build
LiteLLM is dual licensed. Everything outside the enterprise/ directory is MIT, according to the LiteLLM LICENSE file, and content inside enterprise/ uses its own license. The open-source proxy covers virtual keys, per-key, per-user and per-team budgets, rate limits and routing, and it needs PostgreSQL for virtual keys.
- Open-source scope: Virtual keys, budgets, TPM and RPM limits, routing and retries sit in the MIT portion.
- Admin UI SSO: Free for up to 5 users from v1.76.0. Beyond that, an Enterprise license is needed.
- Enterprise-only features: SCIM, JWT authentication with identity provider tokens, audit logs, organization and team RBAC, IP allowlisting and secret manager integrations such as HashiCorp Vault.
- Per-team logging and guardrails: Team-level guardrails and logging are listed in the Enterprise documentation, so confirm which guardrail integrations are licensed.
- Support windows: LiteLLM maintains the four most recent stable minor versions for both open source and Enterprise deployments.
Before you build, confirm with LiteLLM whether your user count stays under the SSO limit, which Enterprise features your audit or access controls require and what the Enterprise contract covers for support.
The portkey-ai/gateway repository is MIT licensed, according to its LICENSE file. The open-source gateway handles routing, retries, fallbacks, load balancing, conditional routing and guardrails through JSON configs. Its README recommends Portkey Cloud as the deployment option, so self-hosting is a deliberate choice you should plan for.
- Open-source repository: MIT for the gateway code, with Docker, Node.js and Cloudflare Workers deployment guides.
- Enterprise deployment features: Secure key management with role-based access control, simple and semantic caching, IP and geo inbound rules, PII redaction and professional support are listed for the enterprise deployment, not the open-source gateway.
- Gateway 2.0 pre-release: A 2.0.0 branch is in progress, in which Portkey's core enterprise gateway is merging into open source. Treat this as a pre-release until a stable tag exists.
- Latest tagged release: v1.15.2, published January 12, 2026.
- Acquisition: Palo Alto Networks announced on May 29, 2026 that it had closed its acquisition of Portkey. The announcement does not address the open-source gateway.
Before you build, confirm which enterprise features will sit in the 2.0.0 open-source code, what the licensing terms are for each edition and how Portkey plans to maintain the open-source gateway after the acquisition.
Support windows and licensing terms change between editions, and the open-source license file does not settle what you may run in production under a paid contract. Compare the terms for each product and edition in writing, and ask for the answers in your procurement file.
- LiteLLM support window: Confirm the four-minor-version window applies to the release you plan to run and how it differs for Enterprise contracts.
- LiteLLM Enterprise scope: Ask which features are included in the Enterprise license, how the SSO user count is counted and whether guardrail integrations carry separate terms.
- Portkey enterprise terms: Ask whether the enterprise deployment features are offered as a license, a subscription or both, and what support is included.
- Gateway 2.0 timing: Ask Portkey for the planned stable date and whether the 2.0.0 branch keeps the MIT license for merged enterprise code.
- Acquisition effects: Ask Palo Alto Networks and Portkey how the open-source gateway, its roadmap and its license will be governed after the acquisition.
Document each answer with a date and the name of the person who gave it, because license terms and roadmaps can change between your evaluation and your deployment.
What the Palo Alto Networks acquisition of Portkey changes for self-hosting
Palo Alto Networks announced on May 29, 2026 that it had closed its acquisition of Portkey and that Portkey would become the foundational AI Gateway for its Prisma AIRS platform. The announcement does not address the open-source gateway, so for a self-hosted deployment the decision starts with a question to Portkey, not with the press release. Ask how the 2.0.0 branch of the portkey-ai/gateway repository, in which the enterprise gateway is being merged into open source, will ship, which features will remain under the MIT license, and whether the open-source roadmap will change after the acquisition. Get the answers in writing, with the version numbers and dates they commit to.
The README also marks Portkey Cloud as the recommended deployment, while the self-hosted options (Node.js, Docker, Docker Compose and Cloudflare Workers) are listed beside it. A platform team should confirm which of its planned configs, guardrails, caching and key management features run on its own infrastructure today and which depend on the managed service or the enterprise deployment. Document each answer against the workload it supports, so that a change in packaging or licensing shows up as a known gap rather than a surprise during an audit.
A team that relies on a self-hosted MIT gateway for a regulated workload should write its own exit criteria and test them before go-live. Useful criteria include a maximum acceptable delay for security fixes in the open-source code, a required commitment to keep the configuration format stable, and a tested path to move routing rules and provider credentials to another gateway. The LiteLLM migration skill that Portkey publishes maps LiteLLM concepts to Portkey configs, and the same mapping can be read in reverse as a rough exit plan. Run a rehearsal in a non-production environment, record the time and gaps it reveals, and repeat it after each major release.
How to move from LiteLLM to Portkey, or back, in the right order
This sequence turns an existing LiteLLM setup into a tested Portkey configuration without cutting over live traffic before you can compare the two. It also makes clear which parts of the setup carry over and which must be rebuilt by hand.
Inventory every LiteLLM call and config
Your platform or application team lists every place LiteLLM is used: direct completion calls in the Python SDK, Router definitions, Proxy configuration files, fallback chains, retry settings and any caching. Record which applications call each path and which model names they request. Done when each entry has an owner and a short note on what it does, and nothing is left that exists only in someone's memory or a deployment manifest.
Separate portable routing intent from LiteLLM state
Sort the inventory into two groups. The first holds routing intent that can be re-expressed elsewhere: model names, provider choice, fallback order, retry counts and cache settings. The second holds state that lives inside the LiteLLM Proxy: virtual keys, per-key, per-user and per-team budgets, rate limits, spend records in PostgreSQL, SSO configuration and team-level logging. Done when you have a written list of the second group, because that list defines the rebuild work and the export plan in later steps.
Map configs with the migration skill
Use Portkey's migrate-litellm-to-portkey skill to translate LiteLLM completion calls, Router settings, Proxy fallbacks, retries and caching into Portkey client configs. Review each generated config by hand, since the skill maps intent and does not prove that behavior matches. Done when every routing rule from the first group has a Portkey config equivalent, and the team has written down any LiteLLM behavior with no direct counterpart so it can be tested or dropped on purpose.
Create the Portkey key and Model Catalog providers
Your platform team creates a Portkey API key and connects each model provider in the Model Catalog at Portkey's app console, using the provider credentials your organization already manages. Keep provider keys in your secret manager and do not paste them into client code. Done when a test request routed through Portkey reaches each provider in the inventory and returns a response, and the team can see the request in Portkey's logs.
Rebuild access controls before any traffic moves
Recreate the access model that LiteLLM enforced, using the list from the second group. Map each virtual key's allowed models, each team's limits and each budget to Portkey's own controls, and confirm the features exist in your Portkey edition before you rely on them. Assign owners for SSO and audit requirements, since these may need separate configuration or licensing. Done when a reviewer can compare the LiteLLM and Portkey controls side by side and sign off that no team gains access it did not have before.
Run parallel traffic and compare results
Send a copy of selected non-production or low-risk requests through Portkey while LiteLLM keeps serving the live path. Compare responses, latency, retry and fallback behavior and error handling for the same inputs. Use a failed provider in a test window to confirm that fallbacks behave as the configs intend. Done when the team has a written comparison for each provider and each routing rule, with any gaps assigned to an owner and resolved or accepted.
Export spend history and cut over
Before cutover, export the spend history held in your PostgreSQL database, keeping the records your finance and audit teams need, and store the export under your retention policy. Then point applications at Portkey in stages, keeping LiteLLM available as a fallback until the stages are complete. Done when all applications use the Portkey endpoint, the PostgreSQL export is verified and stored, and an owner has confirmed that cost reporting for the new period has a clear source.
Plan the reverse move with the same rebuild cost
If you later move from Portkey back to LiteLLM, repeat the same process in reverse. Routing configs can be re-expressed, but virtual keys, budgets, team limits, SSO setup and spend history must be rebuilt in your own PostgreSQL and LiteLLM configuration, so the rebuild cost is the same. Ask the vendor or your implementation partner to confirm which Portkey features and data formats can be exported, and keep your own record of keys, budgets and spend from day one. Done when the export and rebuild list is documented and kept current with each configuration change.
What drives the running cost of each gateway
The running cost of a LiteLLM deployment is mostly infrastructure and people, not licenses. The proxy itself is MIT licensed, but LiteLLM's production guide names PostgreSQL as the primary supported database, requires Redis 7.0 or newer once more than one proxy instance runs, and suggests 1 vCPU and 4 GiB of memory per worker. Those components run in your cloud account or data center, so you pay for their compute, storage, backups and high availability, and someone on your team must operate them. Virtual keys, budgets and spend tracking all depend on PostgreSQL, so its sizing and recovery plan belong in the running cost from day one. Recurring costs are the infrastructure bill and the engineering time for upgrades. Upgrades matter because LiteLLM maintains support for the four most recent stable minor versions, which means you must plan to move forward on that cadence to stay supported.
Portkey's open-source gateway, under the MIT license, is lighter to host. The README describes a footprint of 122 kb and a Docker image, Docker Compose and Cloudflare Workers deployment paths, so the compute bill for a stateless gateway can be small. The cost shifts when you need what the README places outside the open-source path. Managed deployment on Portkey's API, Portkey Cloud, carries subscription fees that you must confirm for your volume and region. The enterprise deployment adds secure key management with role-based access control, PII redaction, caching and professional support, and its fees are set by contract. The Palo Alto Networks acquisition closed in May 2026, so ask the vendor how the open-source gateway roadmap, including the Gateway 2.0 pre-release, will affect your licensing tier before you commit.
Budget for the cost of switching later on both sides. A LiteLLM team that adopts the Portkey migration skill must remap completion calls, Router settings, fallbacks, retries and caching into Portkey client configs, and must recreate providers in Portkey's Model Catalog. Virtual keys and spend history held in your PostgreSQL do not move automatically, so plan how you will retain audit records. When requesting a written quote from any vendor or implementation partner, ask for: the exact support scope and response commitments, the deployment model (self-hosted, managed or enterprise), the licensing tier and what it includes, which upgrade and version-support windows apply, who operates PostgreSQL and Redis, the migration assistance included and the exit or data export terms. DeployOpen fixed-scope quotes follow the written scope, so state these items up front.
Where gateway projects usually run long
Most LLM gateway delays come from a few design decisions made late: how keys and budgets map to teams, how the proxy scales, how secrets and admin access are handled, and whether fallbacks were ever tested against real failures. Each card names the condition that turns the issue into a risk and what to confirm before committing to either platform.
Key and budget design across teams
LiteLLM virtual keys need a PostgreSQL database and support per-key, per-user and per-team budgets, TPM and RPM limits and model restrictions. The risk appears when several teams share one budget hierarchy and nobody has agreed who owns a budget increase or how spend rolls up. Before choosing, map your teams, projects and chargeback model to keys, and confirm how Portkey's configs and workspace setup would express the same limits if you compare it.
Redis sizing once proxies scale
LiteLLM's production guide requires Redis 7.0 or newer once more than one proxy instance runs, because rate limits, router state and cache are shared through it. Teams often deploy a second replica for availability and only then discover that Redis was never planned as a shared dependency. Confirm who operates Redis, how it is backed up and what happens to rate limits if it is unavailable.
Master key handling
LITELLM_MASTER_KEY must start with sk- and grants administrative control of the proxy, so it belongs in a secret manager rather than in a compose file or Helm values. The risk grows when the key is shared across environments or copied into CI variables with broad access. Decide which secret store holds it, who can rotate it, and whether your team needs the Enterprise secret manager integrations that LiteLLM lists for AWS, Azure, Google, HashiCorp Vault and CyberArk.
Spend batching at scale
LiteLLM recommends batching spend updates to the database every 60 seconds at scale. That means budget and spend figures visible in the admin view can lag real usage by up to that interval, which matters when a team is close to a hard limit or when finance reconciles against provider invoices. Ask for the spend data flow in writing, confirm how fallbacks and retries are counted, and test whether your reporting tolerates the delay.
Admin access and identity integration
The LiteLLM admin UI supports SSO with Google, Microsoft Entra ID, Okta and generic OIDC, and SSO is free for up to 5 users. Beyond that, SSO, SCIM, JWT authentication and audit logs sit in the Enterprise license. Teams that assume admin access will follow the corporate identity provider often find the license boundary late. Confirm the number of admins and users who need SSO, and whether Portkey's admin and enterprise controls meet the same requirement for your organization.
Fallback testing against real errors
Routing configs for retries, cooldowns and fallbacks look correct on paper, but provider errors such as rate limits, timeouts and malformed responses behave differently in production. The risk is a failover path that has never been exercised, so the first real outage becomes the test. Plan fault injection against a staging provider set, confirm which error classes trigger each fallback in LiteLLM's router or Portkey's configs, and record the results before routing live traffic.
Questions buyers ask before choosing or hiring help
How much effort does self-hosting LiteLLM take in production?
Most of the effort is database, cache and key operations, plus sizing and upgrades. LiteLLM names PostgreSQL as its primary supported database, and virtual keys need a PostgreSQL database. Once more than one proxy instance runs, its production guide requires Redis 7.0 or newer for shared rate limits, router state and cache. The same guide suggests 1 vCPU and 4 GiB of memory per worker as a starting point, recommends one Uvicorn worker per pod on Kubernetes with horizontal scaling, and suggests keeping LITELLM_MASTER_KEY in a secret manager. Effort rises with the number of providers, teams and budgets you manage, and with how many enterprise controls you need. Run a pilot against those sizing numbers, then confirm the upgrade cadence your team can sustain, since LiteLLM maintains support for the four most recent stable minor versions.
Can Portkey run fully on our own infrastructure?
The open-source Portkey gateway can run on your own infrastructure, but the boundary between open and hosted features needs checking. The gateway repository is MIT licensed, and the deployment guide lists local deployment through npm or Bun, a Node.js server, the portkeyai/gateway Docker image, Docker Compose and Cloudflare Workers, with the deployment guide as the reference. Locally, the gateway starts with npx @portkey-ai/gateway on port 8787 and includes a Gateway Console for local logs. The same README marks Portkey Cloud as recommended. The enterprise deployment adds secure key management with role-based access control, simple and semantic caching, IP and geo inbound rules, PII redaction and professional support. Confirm in writing which of those features you need will run without a Portkey-hosted service, and how provider keys are stored in your environment.
Do we need an enterprise license for SSO with LiteLLM?
Not for a small group, but the user count decides it. The LiteLLM admin UI supports SSO with Google, Microsoft Entra ID (Azure AD), Okta and generic OIDC providers. According to the admin UI SSO documentation, from v1.76.0 SSO is free for up to 5 users, and an Enterprise license is needed beyond that. Enterprise also adds SCIM, JWT authentication with identity provider tokens, audit logs, organization and team RBAC, IP allowlisting and secret manager integrations. Check three things: the number of people who will use the admin UI, which of the enterprise controls your auditors or security team require, and whether they expect audit logs at the gateway layer. Ask LiteLLM for current Enterprise terms in writing, and pin the release you test against so the user threshold applies to the version you run.
How long does a migration from LiteLLM to Portkey take?
No supplied source gives a duration, so the answer depends on what your team has built on LiteLLM. Portkey publishes a migrate-litellm-to-portkey skill that maps LiteLLM completion calls, Router, Proxy, fallbacks, retries and caching to Portkey client configs. Its skill documentation starts its checklist with a Portkey API key and providers set up in Portkey's Model Catalog at app.portkey.ai. The main drivers are the number of call sites in your applications, how much routing logic lives in LiteLLM Router configuration, how many virtual keys and budgets must be recreated, and whether you need to keep spend history from LiteLLM's PostgreSQL database. Ask both vendors and your own team for a written count of each driver, then run both gateways in parallel on a test workload before you set a cutover date.
Can our own engineers run a LiteLLM or Portkey gateway without outside help?
Often yes for one team with a short provider list, and less so once the gateway becomes shared infrastructure. Your engineers need to run PostgreSQL, add Redis 7.0 or newer when several proxy instances run, manage secrets, monitor the service and rehearse upgrades. On the Portkey side, routing configs, guardrails and key management need design and testing before rollout. Container platform, database and identity integration skills decide the outcome more than license terms do. A practical test is whether one person can restore the database, rotate the master key, add a new provider and roll back a bad config without outside help. If the answer is no, you have a skills gap to fill through training, staffing or an implementation partner, and that gap is worth costing before you choose a gateway.
What should an implementation partner cover in a gateway engagement?
A written scope that names each component, owner and acceptance test is the baseline. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a gateway engagement, the scope would normally include:
- Architecture for the gateway, database, cache and secret handling in your environment
- Provider, key, team and budget configuration, plus the routing and failover tests you agree on
- Identity integration and any licensed controls you decide to buy
- Backup, restore, upgrade and handover documentation for your own team
Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from that scope. DeployOpen is not an official partner of LiteLLM or Portkey, so confirm vendor-specific questions with the vendors directly.
What does Portkey's acquisition by Palo Alto Networks mean for the open-source gateway?
The acquisition changes the roadmap questions more than the license terms. Palo Alto Networks announced on May 29, 2026 that it had closed its acquisition of Portkey and that Portkey would be the foundational AI Gateway for its Prisma AIRS platform. The announcement does not address the open-source gateway. The gateway repository remains MIT licensed, and its README announces a Gateway 2.0 pre-release on a 2.0.0 branch, in which Portkey's core enterprise gateway is merging into open source. The latest tagged release is v1.15.2, published on January 12, 2026. Ask Portkey in writing which features will stay in the open-source edition, what support applies to the 1.x and 2.0 lines, and how the Prisma AIRS integration will affect self-hosted deployments.
What should engineers verify in LiteLLM before going live?
Verify the controls that limit spend and access, then test the failure paths. Virtual keys support per-key, per-user and per-team budgets, TPM and RPM limits, temporary budget increases and restriction to specific models, and they depend on PostgreSQL. The router offers simple-shuffle (recommended), usage-based, latency-based, least-busy and cost-based routing, with retries, cooldowns after repeated failures, priority ordering for failover and session affinity, as described in the LiteLLM routing documentation. Test each strategy against a provider outage, a budget breach and a key revocation. Confirm that the master key sits in a secret manager, that spend logs reach your monitoring system, and that the batched spend updates every 60 seconds at scale fit your reporting needs.
How DeployOpen helps you choose, implement or migrate
DeployOpen plans, implements, hardens and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For LiteLLM vs Portkey, we start from your deployment constraints, governance needs and existing gateway footprint, then build only the part of the gateway decision your organization needs to make.
How we scope
- Written scope agreed before work starts, covering which gateway, which providers and which teams are in the first phase.
- Review of whether your PostgreSQL, Redis and secret manager requirements can run fully inside your own infrastructure.
- Confirmation of which features your team needs, such as virtual keys, budgets, SSO or guardrails, and which edition each requires.
- Written checklist of licensing questions to confirm with each vendor before the platform choice is locked.
How we build
- Deployment of the chosen gateway in your environment with database, cache and identity integration configured to your standards.
- Configuration of routing, retries, fallbacks and per-team keys and budgets, tested against the model providers you actually use.
- If you migrate from LiteLLM to Portkey, mapping of existing completion calls, fallbacks and caching to the new client configs, with side-by-side testing.
- Hardening review covering access control, secret handling and logging, with the evidence an assessor would ask for.
How we hand over
- Runbooks for deployment, upgrades, key rotation and budget administration written for your platform and security teams.
- Documentation of the architecture, data flows and licensing position so procurement and compliance can review it directly.
- Knowledge transfer sessions with the engineers who will operate the gateway after the engagement ends.
- A clear record of what was built, what was tested and which open items remain with your organization.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Regular upgrade planning against the gateway's release cadence, with testing before each change reaches production.
- Periodic review of licensing and edition changes so that your team learns about affected features before renewal dates.
- Support scope is set in writing, so response expectations and included activities are clear before the retainer starts.
