Open-source alternative to Portkey virtual keys and budgets

Open-source alternative to Portkey virtual keys and budgets: the short answer

A platform team has applications that call Portkey with virtual keys, and the security and finance leads want per-application spend limits and model access rules enforced inside their own network. The short answer is that LiteLLM virtual keys backed by PostgreSQL cover per-key, per-user and per-team budgets, TPM and RPM rate limits, temporary budget increases and restrictions to specific models. Because LiteLLM runs as a self-hosted proxy, the keys, budget counters and spend records stay in the database you operate, and applications keep calling one OpenAI-compatible endpoint.

The boundary to plan for is licensing. The virtual key controls described above sit in the MIT-licensed part of LiteLLM, but SSO beyond the free user limit, SCIM, audit logs, organization and team RBAC and IP allowlisting are part of LiteLLM Enterprise, which has its own license. The free SSO allowance is described in the LiteLLM admin UI SSO documentation, so confirm the current user limit with LiteLLM before you design your access model around it. Portkey's enterprise access control is a separate feature set, and LiteLLM does not reproduce it one-to-one, so map each Portkey control you rely on to a LiteLLM setting or a documented gap before you commit.

Start with an inventory: list every Portkey virtual key, its owning team, its monthly budget and the models it may call. Then decide which of those controls must be enforced at the gateway and which can stay as reporting. Ask your LiteLLM contact or confirm in the LiteLLM virtual keys documentation which limits apply per key versus per team in your version. Plan for PostgreSQL as the system of record and Redis once more than one proxy instance runs, since shared rate limits depend on it.

Which Portkey key and budget capabilities map to LiteLLM

This table maps Portkey's key, budget and access control capabilities to the LiteLLM features that replace them. Check the license tier column first, since virtual keys and budgets sit in the open-source tier while audit logs and organization-level RBAC need LiteLLM Enterprise. The last column lists what to confirm against Portkey's own feature list before you decide.

Capability	LiteLLM option	License tier	Confirm against Portkey
Virtual key issuance	Virtual keys issued through the proxy and stored in PostgreSQL	Open-source tier; virtual keys require PostgreSQL	Key scopes, rotation options and how keys are revoked
Per-key budgets	Spend limit set on each virtual key, enforced at request time	Open-source tier	Budget periods, reset cycles and what happens at the limit
Per-user and per-team budgets	Budgets attached to users and teams that own keys	Open-source tier per the virtual keys documentation	Whether budgets nest across organizations, workspaces or teams
TPM and RPM limits	Tokens-per-minute and requests-per-minute caps on keys, users or teams	Open-source tier	Whether token and request limits apply at the same scope
Temporary budget increases	Time-limited budget raise on a key, for launches or incidents	Open-source tier	Whether Portkey supports expiring raises or only manual edits
Model restrictions	Keys limited to named models, so unapproved providers cannot be called	Open-source tier	Whether model allowlists apply across all Portkey providers and configs
Spend tracking	Spend per key, user and team stored in PostgreSQL, with logs to Langfuse, Prometheus or OpenTelemetry	Open-source tier; LiteLLM's production guide suggests batching spend updates every 60 seconds at scale	Cost reporting granularity and export options for finance teams
SSO	Admin UI sign-in with Google, Microsoft Entra ID, Okta or generic OIDC	Free for up to 5 users from v1.76.0; Enterprise license beyond that	SSO and SCIM coverage on your Portkey plan
Audit logs and RBAC	Audit logs plus organization and team role-based access control	LiteLLM Enterprise	Portkey access control is an enterprise feature outside its open-source gateway, so compare role sets directly

Which open-source option fits which key and budget need

Portkey's virtual keys and budgets can be replaced by several open-source paths, and they differ in where enforcement happens and what it costs to run. The cards below set out when each option fits, the trade-off to weigh, and what to confirm before committing.

LiteLLM proxy with virtual keys

The closest functional match to Portkey's virtual keys. LiteLLM issues keys backed by PostgreSQL with per-key, per-user and per-team budgets, TPM and RPM limits, and model restrictions, all in the MIT-licensed core. The trade-off is operational: PostgreSQL is the primary supported database, and once more than one proxy instance runs, Redis 7.0 or newer is needed for shared rate limits and router state. Confirm how your team will rotate the master key and which limits you need before deployment.

LiteLLM Enterprise for SSO and audit

Needed when access control must follow your identity provider and auditors ask for change history. The Enterprise license adds SCIM, JWT authentication with identity provider tokens, audit logs, organization and team RBAC, and IP allowlisting. SSO for the admin UI is free for up to 5 users in v1.76.0 and later, so larger administrator groups should price the license early. Ask LiteLLM for the current terms, since the license is separate from the MIT core.

MIT-licensed Portkey gateway

Portkey's AI Gateway is MIT licensed and runs on Docker, Node.js, Cloudflare Workers or Kubernetes, so routing and fallbacks can stay in your infrastructure. Portkey lists access control as an enterprise feature outside the open-source gateway, so per-key budgets and team permissions are not part of this option. It fits teams that need routing only and will enforce spend limits in their identity layer or application code. Confirm which access controls you would have to build yourself.

Kong AI Gateway for token quotas

Fits teams that already run Kong for their APIs and want LLM traffic governed by the same control plane. Token-based limits sit in the gateway layer rather than in an LLM-specific key model, so budgets are tied to consumers defined in Kong. Multi-model load balancing and semantic routing in AI Proxy Advanced need Kong AI Gateway Enterprise, so check which tier covers the quota plugins you need. Expect the work to include API-layer consumer design alongside LLM provider configuration.

Apache APISIX for consumer quotas

A fit for teams running APISIX as their API gateway, using the Apache-2.0 AI plugins. The ai-rate-limiting plugin applies token quotas per consumer, and ai-proxy-multi handles weighted load balancing, retries and fallbacks. Budgets are expressed as gateway quotas, not as spend in currency, so finance reporting needs its own pipeline. Confirm that the plugin set you rely on is available in the open-source edition for your APISIX version before planning.

Choosing by key lifecycle needs

The deciding factor is often who issues and revokes keys. If applications need self-service keys with spend tracking per team, LiteLLM's key model fits most directly. If keys already belong to an API platform team, Kong or APISIX centralize revocation with existing consumer records. Whichever you pick, plan how keys are reissued to running applications without downtime, and test revocation before cutover.

Running LiteLLM keys next to Portkey and the rest of the stack

Some teams keep Portkey for logging and analytics while LiteLLM takes over key issuance and budget enforcement. In this split, a request passes through LiteLLM first, which checks the virtual key, applies the budget and rate limits, and then forwards the call. If Portkey remains in the request path as a logging destination, the spend record exists in two places, and the two numbers will not match unless you define which one is authoritative for chargeback.

Key check: LiteLLM validates the virtual key against its PostgreSQL database before any upstream call.
Spend record: LiteLLM tracks spend per key, user and team, while Portkey holds the logs it receives.
Control owner: Budgets and model restrictions belong to LiteLLM during the transition, not to Portkey.
Duplicate traffic: Confirm whether requests are sent to Portkey twice, once through the gateway and once as a logging call, since that doubles the logging volume and can skew token counts.
Retirement point: Define when Portkey stops receiving logs so finance has a single source for spend.

Before cutover, ask your team to confirm in writing which system produces the monthly spend figure that finance uses.

How to map Portkey keys and budgets into LiteLLM

This sequence turns Portkey's keys, budgets and model access rules into a LiteLLM setup backed by PostgreSQL, then moves applications to new keys in a way that lets both gateways run side by side until traffic has fully shifted.

Export and inventory every Portkey key and budget
Someone with Portkey admin access lists each virtual key, the team or application that uses it, its spend limit and reset period, and the models it can call. Include keys used by batch jobs, evaluation runs and internal tools, not only the production apps. Portkey's logs export is Enterprise-only, so if you need history, confirm your plan's export options with Portkey before you rely on them. The step is done when you have a spreadsheet where every Portkey key maps to one owner, one budget and an explicit model list.
Design the LiteLLM user, team and key hierarchy
Decide which Portkey keys become LiteLLM teams, which become users and which stay as individual keys. LiteLLM virtual keys support per-key, per-user and per-team budgets, TPM and RPM limits and restriction to specific models, so a team budget can sit above several application keys. Record the design in a table that names each LiteLLM object and the Portkey key it replaces. The step is done when every inventory row has a target object and no budget is left without an owner.
Provision PostgreSQL and Redis for the proxy
A platform engineer deploys PostgreSQL, which LiteLLM requires for virtual keys, and deploys the proxy into a staging environment in your own infrastructure. 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, because shared rate limits, router state and cache depend on it. Store LITELLM_MASTER_KEY, which must start with sk-, in a secret manager. The step is done when a test key can be created, used and listed from a second proxy instance, which shows the shared state works.
Mirror budgets, rate limits and model restrictions
Recreate each budget, TPM and RPM limit and allowed model list from the inventory on the matching LiteLLM team, user or key. Use temporary budget increases only for planned spikes, and write down which one-off increases you granted so they are not mistaken for the standing limit. Run a test request that should be refused, such as a call to a model outside the allowed list, and confirm LiteLLM blocks it. The step is done when each restricted case in the test plan returns a refusal and each permitted case succeeds.
Run both gateways in parallel during cutover
Keep Portkey serving production while LiteLLM handles a small set of low-risk applications, such as an internal tool or a batch job. Route those calls through the LiteLLM endpoint and compare spend, errors and latency in each system's logs. Note that LiteLLM spend is tracked on its own keys, so the two totals will not match until you reconcile them. The step is done when the parallel workloads show spend and error rates that your team has reviewed and accepted.
Reissue keys to applications in batches
Issue new LiteLLM keys to each application owner, store them in the application's secret store, and change the base URL and key in one release per application. Move the lowest-risk applications first and keep the Portkey key active until the application has run through a full normal cycle on LiteLLM. If a problem appears, the owner can switch back to the Portkey key without a code change. The step is done when every application in the inventory has a LiteLLM key in production and the owner has signed off.
Retire old Portkey keys after traffic moves
Once Portkey logs show no live traffic for a key over a period your team agreed in advance, disable that virtual key in Portkey, then remove it from application configuration. Keep a record of each retired key, its owner and the date it was disabled, which auditors will ask for when they review access changes. Confirm with Portkey how disabled keys and their historical logs are handled under your contract. The step is done when the inventory shows every Portkey key as disabled and every LiteLLM key as assigned to a named owner.

How to reissue keys to applications without downtime

Reissuing keys without downtime comes down to overlap: the new LiteLLM virtual key must work in production before the Portkey key stops working, and the old key must stay valid until traffic has actually moved. Start by generating the replacement keys in LiteLLM with the budgets, TPM and RPM limits and model restrictions you already mapped, then store each one in your secret manager under a new name. Keep LITELLM_MASTER_KEY in the secret manager as well, since it is the administrative credential that creates and rotates virtual keys, and it must start with sk-. Restrict who can read it to the platform team, and do not let it reach application configuration.

Deploy the new keys to one application or environment at a time. Each service should read its key from the secret manager at startup, so a rollout means updating the secret reference and restarting or reloading the workload, not editing code. Leave the Portkey key in place and valid during this window. While the two keys run side by side, watch spend per key, request rate, rejected requests and rate limit errors in LiteLLM's spend tracking and in your logging destination. A sudden rise in 429 responses or in budget rejections usually means a limit was set too low for the real workload, not that the migration failed.

Before you revoke the Portkey key, confirm that no traffic still arrives on it, using the logs from the cutover window. Keep a rollback path ready. If a new key hits its budget or limit during cutover, LiteLLM's temporary budget increase lets you raise the limit for a set period without reissuing the key, which keeps the application running while you correct the mapping. Confirm with your own change process how long old keys remain valid after the last cutover, and record each key change in your change log. Test this sequence in a non-production environment first, because the exact behavior of key expiry and budget resets depends on your LiteLLM version and database configuration, which you should confirm against the LiteLLM virtual keys documentation.

What teams ask before replacing Portkey keys and budgets

What drives the cost of replacing Portkey virtual keys with LiteLLM?

The cost comes from the components you run and the people who run them, not from a license fee for the open-source proxy itself. The main parts are compute for the LiteLLM proxy, a PostgreSQL database that stores keys, budgets and spend, a Redis instance once more than one proxy instance runs, an observability backend for logs, and the engineering time to configure, test and cut over applications. Recurring costs include infrastructure, upgrades and on-call work. Ask any partner or vendor for a written scope that lists each component, who operates it, and which items are one-time versus monthly. Ask whether SSO or audit logs need a LiteLLM Enterprise license, since that is the main license cost.

Can our team migrate Portkey keys and budgets without an outside partner?

Yes, if your team already runs PostgreSQL, Redis and Kubernetes and has someone comfortable with OpenAI-compatible APIs and secret handling. The migration is mostly configuration: creating virtual keys, setting per-key, per-user and per-team budgets, rate limits and model restrictions, then moving applications to the new endpoint. Teams without that operating experience often underestimate the production work, including database sizing, spend batching, secret rotation and failover testing. A fixed-scope engagement can cover only the parts you choose, such as the initial build or the cutover runbook, and you can keep the rest in-house.

What infrastructure does a LiteLLM virtual key setup require?

Virtual keys need a PostgreSQL database, because keys, budgets and spend records are stored there. LiteLLM's production guide names PostgreSQL as the primary supported database. Once more than one proxy instance runs, the guide requires Redis 7.0 or newer for shared rate limits, router state and cache. Keep the master key, which must start with sk-, in a secret manager rather than in configuration files. The guide suggests 1 vCPU and 4 GiB memory per worker as a starting point, and recommends one Uvicorn worker per pod on Kubernetes with horizontal scaling. Confirm sizing against your own traffic before you commit to a plan.

Which Portkey access controls need LiteLLM Enterprise?

Virtual keys, per-key, per-user and per-team budgets, TPM and RPM limits, temporary budget increases and model restrictions are part of the open-source LiteLLM proxy and are backed by PostgreSQL. The enterprise license covers more of the identity and governance layer. According to LiteLLM's documentation, the admin UI supports SSO with Google, Microsoft Entra ID, Okta and generic OIDC, and from v1.76.0 SSO is free for up to 5 users, with an Enterprise license needed beyond that. Enterprise also adds SCIM, JWT authentication with identity provider tokens, audit logs, organization and team RBAC, IP allowlisting, secret manager integrations and team-level guardrails. Check the current terms in the LiteLLM license and enterprise pages before you plan around them.

How long does cutover take when we move from Portkey keys?

Cutover length depends on scope: how many applications call Portkey, how many keys and teams you must map, whether identity integration is in scope, and how much of your history you need to keep. No duration is fixed by the product, and we do not publish timelines. A sound approach reissues new LiteLLM keys to each application while the old Portkey keys stay active, then switches traffic per application and removes old keys after monitoring confirms no traffic. Ask for a written plan with milestones, rollback steps and the acceptance tests for each application group before agreeing a schedule.

How do we reissue keys to applications without downtime?

Issue new virtual keys in LiteLLM with the same model access and budgets as the old Portkey keys, then deploy the new key to each application through your secret manager, one service at a time. Because LiteLLM exposes an OpenAI-compatible endpoint, most applications only change the base URL and key value. Keep the old Portkey key valid until the new path has served traffic successfully, and roll back by restoring the previous secret if errors appear. Test budget exhaustion and rate limit responses in staging so applications handle them gracefully before production traffic moves.

Does the migration change where our prompts and usage data are stored?

Yes. With Portkey's hosted or hybrid model, control plane data such as keys and configuration sits with Portkey, and hybrid deployments keep the gateway calling out over HTTPS to control.portkey.ai. With a self-hosted LiteLLM proxy, keys, budgets and spend records live in your PostgreSQL database inside your network, and logs go to destinations you configure. Confirm which logging callbacks you enable, because logs sent to Langfuse, Datadog or OpenTelemetry leave the proxy for those systems. Document where each data type lives before you sign off the design.

What the cost of self-hosted LiteLLM keys includes

The license line is the first thing to pin down. LiteLLM is MIT licensed outside its enterprise directory, and virtual keys, budgets, rate limits and model restrictions are part of the open code path, so a self-hosted key system does not require a license to function. The cost changes when you need SSO beyond five users, SCIM, audit logs or team-level RBAC. From v1.76.0, SSO is free for up to 5 users and an Enterprise license is needed beyond that, and audit logs sit in the Enterprise feature set. Ask the vendor for the current Enterprise price in writing, and list the exact user count and controls you need so the quote is comparable to the Portkey contract you are replacing.

The second cost group is infrastructure. PostgreSQL is the primary supported database and stores keys, budgets and spend, so it is a recurring cost to run with backups, failover and patching. Once more than one proxy instance runs, LiteLLM requires Redis 7.0 or newer for shared rate limits, router state and cache. Compute follows LiteLLM's production guidance of 1 vCPU and 4 GiB memory per worker, with one Uvicorn worker per Kubernetes pod and horizontal scaling. Your traffic volume, the number of replicas you need for availability, and whether you host these services yourself or buy managed equivalents drive this line up or down. Confirm the sizing against your own request volume with a load test before you commit to a figure.

The third group is people time, and it recurs. Someone owns key issuance, rotation of the LITELLM_MASTER_KEY held in a secret manager, budget reviews, temporary budget increases and the upgrade cycle, since LiteLLM supports the four most recent stable minor versions. Ask a quote to name each of these tasks, the frequency of budget reviews, and who carries the on-call duty for the proxy and database. A fixed-scope engagement can cover the initial build and handover, while a retainer covers continuing upgrades and support. Ask for both to be priced separately so you can see which costs are one-time and which recur.

How DeployOpen scopes and delivers a key and budget migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so LiteLLM virtual keys and budgets run in your cloud account, data center or air-gapped network. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory every Portkey virtual key, its owning application, team and model access today.
Confirm which budgets, TPM and RPM limits and model restrictions must map to LiteLLM keys, users and teams.
Decide in writing which controls need LiteLLM Enterprise, such as SSO beyond the free user limit, audit logs and SCIM.

How we build

Deploy the LiteLLM proxy with a PostgreSQL database and Redis in your environment, sized from the production guide.
Configure per-key, per-user and per-team budgets, rate limits and model allowlists to match the inventoried access model.
Store LITELLM_MASTER_KEY and provider credentials in your secret manager and test budget enforcement against non-production traffic.

How we hand over

Document the key issuance, rotation and reissue runbook, including the cutover sequence that avoids application downtime.
Deliver configuration as code, with a record of each key, budget and limit and the owner who approved it.
Walk your platform and security teams through operations, so they can issue, revoke and audit keys without DeployOpen.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Upgrades follow LiteLLM's supported minor versions, and we test key and budget behavior before each change.
Confirm with us in the written scope who owns Enterprise license purchases, since those are billed by the vendor.

Open-source alternative to Portkey virtual keys and budgets