Does self-hosting LiteLLM cost less than Portkey's plans?
Self-hosting LiteLLM moves spend from a vendor subscription into infrastructure, database operations and engineering time, and it tends to pay off when log volume is high or when you need single sign-on without buying an enterprise contract. It does not pay off automatically. The answer depends on your traffic, your staffing and which controls you actually need. If a renewal, a per-log pricing change or an enterprise quote has forced this review, start by listing every cost line on both sides. This page does not state Portkey prices or DeployOpen prices. Obtain Portkey's current plan terms, log allowances and enterprise terms in writing before you compare, because those terms change and a quote is only valid for the scope it describes.
On the LiteLLM side, the core gateway is MIT licensed, and only content under its enterprise directory uses a separate license. Single sign-on in the admin UI is free for up to 5 users from v1.76.0, and an Enterprise license is needed beyond that, so a team of five or fewer can avoid that line item entirely. Larger teams should price the license against their user count and against the SCIM, audit log and team RBAC controls they need, which are listed under LiteLLM Enterprise. Compute is the next recurring cost. The production guide suggests 1 vCPU and 4 GiB memory per worker, and it requires Redis 7.0 or newer once more than one proxy instance runs, because shared rate limits, router state and cache depend on it. Your cost model should count every replica, the Redis service, the PostgreSQL database that virtual keys require, and the log backend you choose.
The largest hidden cost is operating work. You will patch the gateway, rotate LITELLM_MASTER_KEY, keep upgrades on a supported minor version, monitor spend updates and handle provider changes yourself. Ask any implementation partner, including DeployOpen, for a fixed-scope quote that lists who builds, who operates and who answers for incidents, and ask Portkey for the same clarity on its enterprise support terms. Model two scenarios with your own numbers, one at current volume and one at your projected peak, and include the people time for on-call and upgrades. If the self-hosted total stays lower under both scenarios and your compliance reviewers accept the control placement, the case is strong. If not, the subscription may be the cheaper choice.
Which cost components change when you self-host LiteLLM
This table sets each Portkey cost component beside its self-hosted LiteLLM equivalent and marks whether it is one-time or recurring. Use it to build your own comparison from your Portkey quote and your cloud bill, since no fixed figures are given here. The main takeaway is that self-hosting removes the vendor fee but moves compute, database, observability and operating work onto your team or a partner.
| Cost component | Commercial side (Portkey) | Self-hosted side (LiteLLM) | One-time or recurring |
|---|---|---|---|
| Subscription or per-log plan fees | Recurring plan fees tied to log volume and tier. Confirm the current rates in your Portkey quote. | No license fee for the open-source LiteLLM core (MIT, outside the enterprise directory). | Recurring on the Portkey side. Not applicable on the LiteLLM core. |
| Enterprise contract | Negotiated contract for enterprise features and support. Ask Portkey which features sit in its tiers. | Needed only if you require controls in LiteLLM Enterprise. Price comes from LiteLLM's quote. | Recurring on both sides where applicable. |
| LiteLLM Enterprise license (SSO, SCIM, audit logs) | Included in the enterprise contract, if you need it. | SSO is free for up to 5 users from v1.76.0. Beyond that, SSO, SCIM and audit logs need an Enterprise license. | Recurring, if required. Confirm the terms with LiteLLM. |
| Compute for gateway pods | Largely hidden in the hosted plan. Hybrid deployment places the data plane in your VPC. | Your cloud bill. LiteLLM suggests 1 vCPU and 4 GiB memory per worker, with one Uvicorn worker per pod and horizontal scaling. | Recurring. Grows with traffic and replica count. |
| PostgreSQL for virtual keys and spend | Included in the hosted control plane. | Required for virtual keys, budgets and spend tracking. Managed or self-run, sized by your key and log volume. | Recurring. Backups and failover add to the base cost. |
| Redis 7.0 or newer for shared state | Not visible to you in the hosted service. | Required once more than one proxy instance runs, for shared rate limits, router state and cache. | Recurring. Sized for your replica count. |
| Observability backend | Logs, traces and analytics are in Portkey's hosted tiers. Export options are plan-dependent. | Langfuse needs PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, or another OpenTelemetry destination. Langfuse documents minimum resources for each. | Recurring. ClickHouse and storage usually dominate, so size them first. |
| Implementation and migration | Mostly configuration inside the hosted console. | One-time work to deploy, map virtual keys and routes, and cut over applications. Scope it in writing before work starts. | One-time. Driven by number of applications, providers and routing rules. |
| Support, upgrades and internal skills | Covered by plan support and Portkey's release cycle. | Your team or a retainer covers patching, LiteLLM version upgrades, incident response and on-call. Ask who holds this work. | Recurring. Often the largest line item in a self-hosted gateway. |
What moves the comparison most
Six variables decide whether a self-hosted LiteLLM stack costs less than a Portkey plan or enterprise contract, and how much operating work it adds. Most of them scale the same parts of the stack, so check them together before you compare totals.
Request and log volume
Every request passes through the proxy, and spend and logging writes grow with traffic. More requests raise compute for the proxy, database write load for spend tracking, and storage for traces in your log backend. Ask Portkey for log volume figures under your plan, and measure your own request rate and average payload size before sizing the self-hosted stack. Logging is usually the cost that grows fastest.
Users and teams needing keys
Each team, user or application that needs its own key, budget or rate limit adds rows to the database and admin work to keep budgets current. LiteLLM virtual keys require PostgreSQL, so the more keys and budget scopes you issue, the more the database and its backups matter. Count the teams and keys you expect in the first year, and ask whether your Portkey plan prices seats, keys or logs.
SSO and audit log requirements
SSO for the admin UI is free for up to 5 users in LiteLLM from v1.76.0, and beyond that an Enterprise license is required. Audit logs, SCIM and organization and team RBAC also sit behind that license. If your identity policy requires SSO for more than a handful of administrators, or audit evidence for key changes, the license becomes a line item that a plain open-source deployment does not carry.
Availability and multi-instance design
A single proxy instance is simpler, but several instances need Redis 7.0 or newer for shared rate limits, router state and cache. Running more replicas adds Redis, load balancing and failure testing to the bill. Decide whether a short gateway outage is acceptable for your applications, since that answer sets how many instances, and how much Redis, you need from day one.
Data residency and air-gap rules
Portkey's hybrid model keeps the gateway in your VPC but calls its control plane over outbound HTTPS, so it does not fit a disconnected network. A self-hosted LiteLLM stack keeps keys, budgets and logs inside your boundary, but you then carry the cost of hosting every component in that boundary, including the log store. Confirm with your security and legal teams which data may leave the network and whether control-plane traffic is acceptable.
In-house platform skills
A production stack adds Kubernetes for the proxy, PostgreSQL for keys and spend, Redis for shared state and a log store such as Langfuse, which runs on PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage. Each component needs upgrades, backups and monitoring. If your platform team already runs Kubernetes, PostgreSQL and ClickHouse, the marginal effort is lower. If not, budget for training, managed services or an implementation partner, and ask any partner for named staff and an operating model in writing.
How to build the cost model with your own numbers
This sequence turns Portkey's invoice and your real traffic into a like-for-like monthly comparison with a self-hosted LiteLLM gateway, so the decision rests on your figures rather than list prices. Each step names what you collect, who collects it and what it produces.
Export current Portkey invoice lines and plan terms
Finance or procurement pulls the last several invoices and the signed order form or plan terms from Portkey. List each recurring line (plan fee, log volume allowance, overage, enterprise add-ons such as SSO or hybrid deployment) and note the contract start, renewal date and any notice period. Confirm with Portkey in writing which features each line unlocks, because some capabilities such as prompt management and semantic caching sit behind enterprise terms. The step is done when every Portkey cost line maps to a named feature and a billing period.
Count monthly logs and requests from your own data
Platform engineering counts requests, logged events and tokens per month from Portkey's dashboard or export, and from application telemetry if it is available. Separate production from development traffic, and record peak days as well as averages, since per-log pricing and worker sizing both follow volume. Ask Portkey to confirm how it counts a log so your figure matches its billing unit. The step is done when you have a monthly request count, a log count and a peak-hour rate for at least one full billing cycle.
Size LiteLLM workers from the production guide and a load test
The platform team starts from LiteLLM's production guidance, which suggests 1 vCPU and 4 GiB memory per worker and one Uvicorn worker per Kubernetes pod with horizontal scaling. Run a load test against a staging proxy using your own request mix, streaming share and provider latency, then record the pod count needed to hold your peak rate with headroom. Treat the baseline as a starting point, since the real figure depends on payload size and how many providers and fallbacks each request touches. The step is done when you have a tested pod count and a compute cost per month from your cloud price sheet.
Price PostgreSQL, Redis and the observability backend
The platform team prices the supporting services. LiteLLM needs PostgreSQL for virtual keys and spend tracking, and Redis 7.0 or newer once more than one proxy instance runs. If you log to Langfuse, its self-hosting documentation lists minimums of 2 CPU and 4 GiB for Langfuse Web, Worker and PostgreSQL, 1 CPU and 1.5 GiB for Redis or Valkey, and 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of ClickHouse memory for larger deployments. Use these as floors, scale ClickHouse storage to your log retention, and price each item from your provider's managed or self-run rates. The step is done when each service has a monthly compute and storage line, with the minimum tier named.
Add enterprise license needs and identity requirements
Security and compliance leads decide which controls must be present on day one. LiteLLM's admin UI SSO is free for up to 5 users from v1.76.0, and an Enterprise license is needed beyond that; Langfuse keeps features such as audit logs, data retention and SCIM behind a license key. Ask each vendor for the current license terms, the user count it is priced on and whether the license is annual, then add it as a recurring line only where a control is a requirement. The step is done when every required control is mapped to either the open-source tier or a named license line.
Add staff hours for upgrades and major migrations
The platform team estimates recurring operating effort, since this is often the largest line that is not on an invoice. LiteLLM maintains support for the four most recent stable minor versions, so plan regular minor upgrades within that window. Langfuse applies minor-version database migrations at startup, but its major upgrades, such as the v3 to v4 path that requires ClickHouse 25.12 or later and about 3x ClickHouse disk headroom for backfills, need a dedicated migration project. Record the expected hours per upgrade cycle, who performs them and the loaded internal rate or external support quote. The step is done when operating hours are a monthly figure with named owners.
Compare totals over the same period and separate one-time costs
Finance builds one spreadsheet that covers the same months for both options, with Portkey's contract total on one side and LiteLLM's compute, data services, licenses, operating hours and one-time setup on the other. Mark each item as one-time (design, load testing, migration, cutover) or recurring (infrastructure, licenses, upgrades, on-call), and show how each total moves when volume doubles. Include Portkey exit terms and any data export work. The step is done when a two-column model shows monthly and first-year totals with every assumption written beside its source, ready to take into a quote request.
What running a production gateway involves
The recurring cost of a self-hosted LiteLLM gateway is staff time, not licence fees, and most of that time goes to a short list of settings and routine tasks. LiteLLM's production guidance recommends running one Uvicorn worker per pod on Kubernetes and scaling horizontally, so your platform team owns the deployment manifests, autoscaling rules and capacity checks. Store LITELLM_MASTER_KEY, which must start with sk-, in a secret manager rather than in configuration files, and assign one named owner for rotating it. Ask your gateway team to confirm who holds the key, how it is audited, and what happens to applications if it is rotated. At scale, LiteLLM suggests batching spend updates to the database every 60 seconds, so finance reports will lag real usage by up to that interval. Decide who reconciles those reports against provider invoices.
Routing and cooldown settings are a continuing decision, not a one-time setup. The LiteLLM router offers simple-shuffle, usage-based, latency-based, least-busy and cost-based strategies, with retries, cooldowns after repeated failures and priority ordering for failover. Each choice changes which provider receives traffic during an outage and what it costs, so the security and product owners should sign off on them and review them after each provider incident. Shared rate limits, router state and cache also depend on Redis 7.0 or newer once more than one proxy instance runs, so Redis becomes another system to patch and monitor.
Upgrades belong on a fixed schedule, with the observability backend treated as part of the same release train. If you pair LiteLLM with self-hosted Langfuse, the v3 to v4 guide requires ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later, and it moves Langfuse to an observations-first ClickHouse data model. Langfuse also advises about 3x ClickHouse disk headroom when backfilling historic data, so plan storage before the upgrade rather than during it. Confirm these versions against the current guides, since they change between releases, and budget the time for migration testing in your own environment. Each of these tasks is recurring work for the platform or database team, and the quote you request should price it as an ongoing item.
How the license terms change the bill by scenario
On the hosted tier, the bill is the Portkey plan itself, and its main variable is log volume under the per-log pricing in your order form. Your team pays for gateway hosting, logging, and the features the plan includes, so the cost recurs for as long as the contract runs. The internal effort is mostly configuration, plus any work to keep prompts, keys and routing rules in Portkey's format.
- Recurring plan fee: Confirm the base fee, the included log allowance, and the overage rate for logs above it.
- Log retention: Ask how long logs are kept on each tier, since longer retention may need a higher plan.
- Enterprise features: Confirm which items, such as SSO, prompt management, semantic caching and PII redaction, are included in your plan and which are add-ons.
- Export terms: Ask whether exporting logs carries an extra charge or a volume limit, because this affects the cost of leaving later.
- Price change clause: Request the renewal uplift cap in writing.
Before renewal, ask Portkey to model your last twelve months of log volume against each tier so you can compare the projected bill with the self-hosted scenarios below.
In hybrid mode, the gateway (the data plane) runs in your VPC while the control plane stays in Portkey's VPC, and the gateway calls out over HTTPS to control.portkey.ai. The license still covers the control plane, so you pay for the hybrid contract and also for the compute and networking that run the gateway in your account. The compliance question shifts from where requests run to what configuration and metadata leave your network. Check the Portkey hybrid deployment documentation for the exact data flows.
- Two cost lines: The hybrid contract is recurring, and your cloud compute for the gateway is also recurring and scales with traffic.
- Outbound connectivity: Ask whether the hybrid price assumes the same log volume and what egress costs apply to your cloud account.
- Support scope: Confirm who patches the gateway image in your VPC and who responds to incidents on the control plane.
- Data location: Get written confirmation of which logs, keys and configuration are stored in the control plane.
- Exit path: Ask how configuration and logs can be exported if the hybrid contract ends.
Request a written data flow diagram from the vendor before signing, since it determines which reviews your security and compliance teams must complete.
LiteLLM's open-source components are MIT licensed outside its enterprise directory, so the software has no license fee. The bill becomes infrastructure and operating labor: proxy compute, a PostgreSQL database for virtual keys and spend, Redis 7.0 or newer once more than one proxy instance runs, and an observability backend such as self-hosted Langfuse. Infrastructure costs are recurring, while setup is largely one-time. The LiteLLM production guide gives baseline sizing to plan against.
- Compute: The guide suggests 1 vCPU and 4 GiB memory per worker, scaled horizontally across pods.
- Database and cache: PostgreSQL and Redis are recurring managed or self-run costs, and they grow with the number of instances and keys.
- Log store: Langfuse self-hosting needs PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible storage, so budget for the ClickHouse memory listed in its scaling guide.
- Operations: Patching, upgrades, backups and on-call are the largest hidden recurring cost.
- SSO limit: Admin UI SSO is free for up to 5 users from v1.76.0, so confirm your user count fits.
Ask your cloud provider and any managed database vendor to quote these components against your traffic, and confirm the free SSO limit still applies to the version you plan to run.
LiteLLM Enterprise is a separate license layered on the same infrastructure. You pay for it when you need SSO beyond the free user limit or the controls that sit in the enterprise directory, such as SCIM, audit logs, organization and team RBAC, and IP allowlisting. The license is typically recurring, and the infrastructure and operating costs from the open-source scenario still apply. The enterprise documentation lists which controls are included.
- License fee: Recurring, and priced by the vendor. Ask for the billing term, the user or seat basis, and whether it renews automatically.
- Feature scope: Confirm which SSO providers, SCIM, audit log retention and secret manager integrations are covered.
- Support terms: Ask what response times are included, since the enterprise docs describe version support for the four most recent stable minor versions.
- Upgrade cost: Ask whether upgrades between minor versions require internal testing work from your team.
- Secret managers: Confirm whether integrations with Vault, cloud secret stores or CyberArk are in the license or need separate engineering.
Compare the license fee with the cost of running your own identity integration and audit tooling, and request the quote as a written scope so both sides agree on what the license covers.
Questions buyers ask before comparing LiteLLM costs
How much operating effort does a production LiteLLM gateway take each month?
The effort depends mostly on how many proxy instances run, how many teams and keys are managed, and how often you upgrade. LiteLLM's production guide names PostgreSQL as the primary database and requires Redis 7.0 or newer once more than one proxy instance runs, because rate limits, router state and cache are shared. Each of these components needs patching, backups, monitoring and capacity checks. LiteLLM also maintains support for the four most recent stable minor versions, so upgrades follow a regular cycle. Ask any provider to estimate effort by listing the instances, databases, providers and upgrade cadence you expect, then to show what is included in ongoing support.
Does SSO really need a paid license for LiteLLM?
Not for small teams. From v1.76.0, LiteLLM's admin UI supports SSO with Google, Microsoft Entra ID, Okta and generic OIDC providers for up to 5 users at no charge. Beyond that limit, you need a LiteLLM Enterprise license. Enterprise also adds SCIM provisioning, JWT authentication, audit logs, organization and team RBAC, and secret manager integrations. Count the users who will sign in to the admin UI, not the total number of applications calling the gateway, because application traffic uses virtual keys. Confirm current limits on the LiteLLM admin UI SSO documentation before you budget.
Can our own team run a LiteLLM gateway without outside help?
A team with container, Kubernetes and database experience can run LiteLLM, but it must own several moving parts: the proxy, PostgreSQL, Redis, secret handling and the observability backend. The production guide recommends one Uvicorn worker per pod, scaling horizontally, and keeping the master key (which must start with sk-) in a secret manager. Routing, fallbacks and budget controls also need testing before production traffic depends on them. Decide whether your staff will carry that load on call and during upgrades, and whether an outside partner should cover the initial build, hardening or a retainer for ongoing support.
How long does a migration from Portkey to self-hosted LiteLLM take?
Duration depends on how many applications call the gateway, how many virtual keys, budgets and routing configs you must map, and whether logs need to move to a new store. Applications that already call an OpenAI-compatible endpoint are usually simpler to cut over, while configs that rely on Portkey-specific features need redesign. Before agreeing a timeline, inventory the applications, the Portkey features in use, the log retention you must keep, and the approval steps for each environment. Ask for a fixed-scope plan with written milestones so the timeline follows from those inputs.
What does Langfuse add to the infrastructure bill?
Langfuse adds a separate observability stack. A self-hosted deployment runs Langfuse Web and Langfuse Worker containers, plus PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. The scaling guide lists minimum resources of 2 CPU and 4 GiB for web, worker and PostgreSQL, 1 CPU and 1.5 GiB for Redis or Valkey, and 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of ClickHouse memory for larger deployments. Major upgrades also need ClickHouse 25.12 or later and about 3x ClickHouse disk headroom when backfilling history. Price these components in your own cloud or data center, not as an add-on to the gateway.
Does LiteLLM's Enterprise directory affect a MIT-licensed deployment?
Only if your deployment uses code from the enterprise directory. LiteLLM is MIT licensed everywhere except content under its enterprise directory, which has its own license in enterprise/LICENSE. A deployment that runs only the non-enterprise code stays under MIT, but features such as SSO beyond the free user limit, audit logs and SCIM sit in the enterprise license. Have your legal or procurement team review the LICENSE file against the features you plan to enable, and record which license covers each feature in your architecture document.
What should a DeployOpen quote include for a LiteLLM engagement?
A quote follows from a written scope, so ask for the scope first. It should list the deployment target (cloud account, data center or air-gapped network), the number of proxy instances, the database and Redis design, the observability backend and retention, the identity provider and SSO design, the migration inventory, testing and hardening work, backup and upgrade procedures, and documentation. Also ask whether ongoing support, upgrades and continuous testing are priced as a separate retainer, and what is excluded. Engagements are usually fixed-scope, so confirm deliverables and timelines in writing before work starts. DeployOpen does not publish a price list.
When self-hosting is the cheaper answer and when it is not
Self-hosting LiteLLM tends to be the cheaper answer in three situations: when request volume is high enough that per-log or per-request plan charges grow faster than the compute and database you would run yourself, when the main cost in an enterprise contract is the identity and governance features rather than the gateway itself, and when a residency or network rule requires the gateway to sit inside your own network. The LiteLLM proxy is MIT licensed outside its enterprise directory, so the core gateway, virtual keys, budgets and routing carry no license fee. Your recurring costs then become compute, a PostgreSQL database, Redis 7.0 or newer once you run more than one proxy instance, and the log backend. Ask Portkey for the full list of what its contract covers before you assume the saving, and price SSO separately, because LiteLLM only gives SSO free for up to 5 users from v1.76.0 onward.
Self-hosting tends to lose when the team cannot run the platform. A production LiteLLM deployment means Kubernetes operations, PostgreSQL backups and migrations, a shared Redis for rate limits and router state, secret handling for LITELLM_MASTER_KEY, and a log store such as Langfuse, which adds ClickHouse, Redis or Valkey and S3-compatible storage to the stack. If nobody on the team owns those components, or nobody can staff the upgrades that LiteLLM ships on a regular cadence, the labor cost can exceed the license savings. Budget that effort as a recurring cost, not a one-time setup, and check whether the work will come from your own staff or from a support retainer with a partner.
Portkey's placement of its control plane is a compliance question before it is a cost question. Under the hybrid model, the gateway runs in your VPC but calls out over HTTPS to control.portkey.ai, so configuration and some telemetry depend on that outbound path. If your residency, data flow or network policy does not allow that path, self-hosting the gateway is required regardless of price, and the cost comparison only decides which self-hosted stack to run. If the control plane placement is acceptable, compare the hybrid contract against the full cost of running LiteLLM yourself, and confirm with Portkey in writing which logs, configuration and metadata leave your network.
How DeployOpen scopes a fixed-price LiteLLM implementation
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Portkey cost comparison, we start from a written scope that sets out which gateway, database, log store and identity controls your team needs before any work begins.
How we scope
- Inventory current Portkey plan features, log volumes and the applications calling the gateway.
- Agree in writing which LiteLLM deployment, database, Redis and log destination are in scope.
- Decide with you whether SSO, SCIM and audit logs need a LiteLLM Enterprise license or stay out of scope.
How we build
- Deploy the LiteLLM proxy in your cloud account or data center, with PostgreSQL and Redis configured for multiple instances.
- Set up virtual keys, team budgets, rate limits and routing rules that match your current gateway configuration.
- Connect logging to your chosen backend, such as Langfuse or OpenTelemetry, and test failover before cutover.
How we hand over
- Document the architecture, resource sizing, key lifecycle and runbooks for patching and upgrades.
- Provide a cost model that separates one-time implementation fees from recurring compute, database and licensing costs.
- Walk your operations team through monitoring, backups and the steps for reissuing keys to applications.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, version upgrades and continuous testing are available as a retainer.
- Ask for the written scope to confirm what is covered after handover before you sign.
