Can a self-hosted LiteLLM gateway stay on the MIT edition?
If you run one shared LiteLLM gateway for a team or an organization, the first question is whether the MIT edition is enough or whether you need an Enterprise license key. For many small deployments, the answer is that the open source AI Gateway already covers the core controls: virtual keys, budgets, rate limits, spend tracking, the admin UI, load balancing and custom guardrails. Single sign-on for the admin UI is also free for up to 5 users. The license applies only to content under the enterprise/ directory, so the rest of the gateway stays under MIT. Enterprise is not a separate product: it is a license key, set with the LITELLM_LICENSE environment variable, on the same self-hosted Gateway image.
Enterprise becomes necessary when specific requirements appear. The first is headcount: SSO beyond 5 users requires a license. The others are audit logs with retention policies, organization and team RBAC, IP allowlisting, JWT authentication with identity provider tokens, SCIM, and secret manager integrations for AWS, Azure, Google, HashiCorp Vault and CyberArk. Presidio PII masking is open source, but the llmguard, llamaguard, hide_secrets, OpenAI moderation, Google text moderation, Lakera and Aporia integrations need a license. Tag-based and per-key model budgets, team-based logging and log export to GCS or Azure Blob are also Enterprise features. Check each of these against your control requirements before you assume the MIT edition is sufficient.
Before you decide, confirm the current terms with LiteLLM, since the Enterprise docs describe a free 30-day trial and pricing on request. Ask whether the license key covers your deployment size and whether any feature you need is still gated. Your team should also test the open source build in a staging environment with the PostgreSQL database that virtual keys require and, once more than one proxy instance runs, Redis. Those components are yours to operate in either edition. Document which controls are met by the open source gateway and which need a license, so auditors and security reviewers see the reasoning rather than a bare yes or no. The LiteLLM Enterprise documentation is the natural starting point for that check.
Which LiteLLM features are free and which need a license key
This table sorts the LiteLLM controls most teams ask about into open source and Enterprise columns, based on the LiteLLM Enterprise docs. Read each row as a question about your own deployment: if the feature is on your requirements list, the right column tells you whether the MIT edition is enough or a license key is needed, and the final column shows what to confirm before you commit.
| Capability | Open source (MIT) | Enterprise (license key) |
|---|---|---|
| Virtual keys, budgets and rate limits | Included, per the LiteLLM Enterprise docs. Virtual keys need PostgreSQL. | Same features on the same image, with tag-based and model-specific budgets added |
| SSO for the admin UI | Free for up to 5 users from v1.76.0, per the LiteLLM SSO docs | Required beyond 5 users, along with SCIM provisioning |
| JWT authentication with identity provider tokens | Not listed as open source in the Enterprise docs. Confirm with LiteLLM. | Included with the license key |
| Audit logs with retention policies | Listed as an enterprise feature in the LiteLLM docs | Included with the license key |
| Organization and team RBAC | Not listed as open source. Confirm before relying on it. | Included with the license key |
| IP allowlists | Not listed as open source. Confirm with LiteLLM. | Included with the license key |
| Secret manager integrations (AWS, Azure, Google, HashiCorp Vault, CyberArk) | Not listed as open source. Keep LITELLM_MASTER_KEY in a secret manager regardless. | Included with the license key |
| Guardrails: custom guardrails and Presidio PII masking | Included in the open source guardrail framework | Included, plus named third-party integrations |
| Third-party guardrail integrations (llmguard, Lakera, Aporia and others) | Not included | Require an Enterprise license |
| Per-team logging, opt-out and log export to GCS or Azure Blob | Not listed as open source | Included with the license key. Confirm export targets for your cloud. |
When the MIT edition is enough and when Enterprise is worth it
If your gateway serves a small group of engineers, SSO for the admin UI is not a reason to buy a license on its own. LiteLLM's documentation says SSO is free for up to 5 users from v1.76.0, and an Enterprise license is needed beyond that. The open source edition still gives you virtual keys with budgets, rate limits, spend tracking, the admin UI and load balancing, which covers most of what a small group needs at the start.
- Virtual keys and budgets: Issue a key per user, team or project, with per-key, per-user and per-team budgets and TPM and RPM limits, backed by PostgreSQL.
- Admin UI SSO: Google, Microsoft Entra ID, Okta and generic OIDC providers work within the five-user limit.
- Guardrails you can write: Custom guardrails and Presidio PII masking are part of the open source framework.
- Redis once you scale out: Running more than one proxy instance requires Redis 7.0 or newer, regardless of edition.
Check how the current LiteLLM documentation counts SSO users in your identity provider before you assume the free tier applies, since that count is what triggers the license.
LiteLLM's Enterprise documentation names teams with 100 or more users, or 10 or more production AI use cases, as the intended fit for the paid edition. Below that range, the threshold reflects where support and governance tend to pay back, and it is not a technical limit on the open source gateway. Above it, the question is whether your team is running many keys, budget owners and workloads that need central oversight.
- Shared budget ownership: Tag-based budgets and model-specific budgets per virtual key are Enterprise features, and they matter when many teams draw on shared spend.
- Budget response: Soft budget email alerts and temporary budget increases let finance and platform owners respond without rotating keys.
- Support model: Enterprise includes a dedicated Slack or Teams channel and optional 24/7 SLAs, so confirm the exact response terms in the order form.
- Open source capacity: Load balancing, fallbacks and retries are in the MIT edition, and both editions receive support for the four most recent stable minor versions.
Ask LiteLLM for a quote based on your user count, production use cases and deployment size, since pricing is set on request and sold through AWS Marketplace, Azure Marketplace or invoice.
A regulated organization usually needs to show who changed a gateway setting, who used which key and how access was granted. The LiteLLM documentation lists audit logs and SSO/SAML among enterprise features, and the license key enables audit logs with retention policies, organization and team RBAC, IP allowlists, virtual key rotation and JWT authentication. These controls are the strongest reasons to evaluate Enterprise in a regulated setting.
- Audit logs with retention: Retention policies are configured in your deployment, so confirm they match your record-keeping period before go-live.
- Organization and team RBAC: Separates the people who administer the gateway from those who can only view spend or usage.
- IP allowlists and key rotation: Restricts administrative access by network and supports rotating virtual keys on a schedule you define.
- Secret managers: AWS, Azure, Google, HashiCorp Vault and CyberArk integrations keep provider credentials out of configuration files.
- Vendor reports: LiteLLM's Enterprise page lists SOC 2 Type 2 and ISO 27001, which are the vendor's to show, while DeployOpen prepares your controls and evidence for an auditor who issues any report.
Before buying, map each control to your own framework and ask LiteLLM which report, scope and period they can share.
A platform team serving several product groups often needs different logging rules for each group, along with guardrails beyond custom rules and PII masking. Team-based logging, per-team logging opt-out and log export to GCS or Azure Blob are Enterprise features. If your policy centers on PII and internal rules, the open source guardrail framework may already cover you.
- Team-based logging: Logs can be governed per team, which matters when one product handles data another team must not log.
- Log export: Export to GCS or Azure Blob is an Enterprise option, so confirm that the destination meets your retention and data residency rules.
- Licensed moderation and injection checks: The llmguard, llamaguard, OpenAI moderation, Google text moderation, Lakera and Aporia integrations require an Enterprise license.
- Secret detection: The hide_secrets integration is also Enterprise-licensed.
- Open source baseline: Custom guardrails and Presidio PII masking remain in the MIT edition and can be tested in your pipeline before you license anything.
Test the integrations you need against representative traffic, and confirm the licensing terms for each third-party service with LiteLLM before you commit.
How licensing, support and updates differ between the two editions
The two editions share one self-hosted gateway image, so the differences sit in license terms, the support you buy, and how long each version line is maintained. Read each card as a question to settle with LiteLLM and your own security team before you choose a path.
MIT license outside enterprise/
Everything outside the enterprise/ directory in the BerriAI/litellm repository is MIT licensed, so an open source deployment can run inside your infrastructure without a license key. Confirm with your legal team that the code you deploy comes only from outside that directory, and that any build pipeline you use does not pull in enterprise-licensed files by accident.
Enterprise directory license terms
Content under enterprise/ uses the license in enterprise/LICENSE, which is separate from the MIT terms. Enterprise features run from that code path and are enabled with a license key on the same image, so the license question is not only about what you download but about which features you switch on. Ask LiteLLM to confirm in writing which terms apply to your deployment, including any use restrictions and redistribution limits.
Four-minor-version support window
LiteLLM states it maintains support for the four most recent stable minor versions for both open source and Enterprise deployments. Your upgrade cadence has to stay inside that window, so plan a recurring upgrade test against each new minor release. Confirm with LiteLLM what counts as a stable minor version and how security fixes reach older lines.
Enterprise support channel and SLAs
Enterprise includes a dedicated Slack or Teams channel, and optional 24/7 SLAs can be added. The published targets are 1 hour for severity 0 issues and 72 hours for security patches. These are contract terms, so ask for the exact definitions of severity 0, the support hours, and the remedies if a target is missed.
Open source has no vendor SLA
The open source edition comes with no vendor SLA, no contracted response time and no dedicated support channel. Community issues and releases are the only public signals. If your service must meet a defined response commitment, the gap has to be covered by your own on-call process, an internal runbook, or an implementation partner's retainer under a written scope.
Free 30-day trial and pricing on request
LiteLLM offers Enterprise with a free 30-day trial, which is the cheapest way to test the license key on your own gateway before committing. Pricing is set by usage and deployment size on request and can be bought through AWS Marketplace, Azure Marketplace or invoice. Ask for a quote that lists the license term, renewal terms, and whether the trial converts automatically.
What changes when you add LITELLM_LICENSE to the same image
Enterprise is not a separate product you migrate onto. According to the LiteLLM Enterprise docs, it is a license key set with the LITELLM_LICENSE environment variable on the same self-hosted Gateway image, with nothing to migrate. That makes the edition decision reversible in configuration terms: you can start on the open source build, add the key later, or remove it, without rebuilding your deployment. Confirm with LiteLLM exactly what happens to features, configuration and stored data when the key is removed, because the docs describe the setup path more clearly than the exit path. Ask whether any Enterprise-only setting, such as SSO, audit logs or team logging, leaves residue in the database that you must clean up.
Several production prerequisites apply to both editions, so they do not change your decision. LiteLLM's production guide names PostgreSQL as the primary supported database, and virtual keys, budgets and spend tracking all depend on it. Once more than one proxy instance runs, Redis 7.0 or newer is required 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 for sizing. Plan the PostgreSQL and Redis footprint before you choose an edition, since both are your infrastructure to run and back up whichever way you go.
Before you rely on the open source build or add the key, confirm any change in behavior with LiteLLM: how the admin UI, virtual key handling and guardrail checks behave after the key is set, which upgrades need a fresh key, and how the four most recent stable minor versions policy applies to your pinned image. Ask for the change in writing, then test it in a non-production environment that mirrors your PostgreSQL and Redis setup. Record the results so the edition decision is based on observed behavior in your own environment.
What you pay for in each edition and what drives the cost
This table breaks down who gets paid for what when you run LiteLLM open source or LiteLLM Enterprise in your own infrastructure. Read it as a checklist for a quote: the license line is the only one that changes between editions, while platform and integration work apply to both.
| Cost component | Who is paid | One-time or recurring | What drives it |
|---|---|---|---|
| Enterprise software license | LiteLLM, sold by usage and deployment size on request, through AWS Marketplace, Azure Marketplace or invoice | Recurring under the agreed term; no Enterprise price is published | Usage and deployment size; ask how the quote scales with users and production use cases |
| Open source software | No license fee; MIT license covers the code outside the enterprise/ directory | None for the software itself | Free to run, but you own upgrades, patching and the support model |
| Internal platform engineering time | Your own platform or SRE staff | Mostly one-time for setup, then recurring for upgrades and on-call | Number of providers, teams, and whether the gateway is shared across business units |
| PostgreSQL and Redis hosting | Your cloud account or data center vendor | Recurring infrastructure | Redis is required once more than one proxy instance runs; PostgreSQL is needed for virtual keys in both editions |
| SSO, secret manager and audit export configuration | Your identity, security or platform team, or a services partner under a written scope | One-time build, then recurring review when identity or secrets change | Number of identity providers, secret manager choice, and log destination (such as GCS or Azure Blob on Enterprise) |
| Enterprise support and SLAs | LiteLLM, if the optional 24/7 SLA tier is selected | Recurring if selected | Optional tier; confirm response times, channel and coverage in the written order form |
| Migration between editions | Usually minimal, as the docs describe the same self-hosted image with a license key | One-time if the key is added later | Confirm with LiteLLM that no configuration changes are needed before you assume it is a key-only step |
Moving from the open source edition to Enterprise, and back
This sequence takes a self-hosted LiteLLM gateway from the MIT edition to Enterprise on the same image, then shows how to step back and what to re-verify. Each step ends with a check you can record before moving on.
Confirm user count and feature need
Start by counting the people who will sign in to the admin UI and listing the features you need beyond the open source edition, such as SSO beyond five users, audit logs, organization and team RBAC, secret manager integration or team-level logging. LiteLLM's Enterprise docs aim the product at teams with 100 or more users or 10 or more production AI use cases, so compare your own numbers against that description. The owner is usually the platform lead with the security team. Done means a written list of required features and the user count, signed off before anyone contacts the vendor.
Request a quote and start the trial
Ask LiteLLM for an Enterprise quote based on your usage and deployment size, since pricing is provided on request and sold through AWS Marketplace, Azure Marketplace or invoice. Ask whether the free 30-day trial applies to your deployment and which support terms are included, including any 24/7 SLA options and their stated response times. Confirm in writing what is recurring (license term and support) and what is one-time. Done means a signed quote and a trial key with a known expiry date.
Set the license key on the existing gateway
Add the key to the environment of the running gateway as LITELLM_LICENSE. The Enterprise docs describe this as the same self-hosted Gateway image with nothing to migrate, so you do not rebuild images or move the PostgreSQL database. Restart or roll the pods using your normal deployment process, one at a time if you run several replicas. Done means the proxy starts cleanly, the admin UI loads, and the Enterprise-only settings appear in the admin UI.
Verify SSO and secret manager integration
Configure SSO for the admin UI with your identity provider (Okta, Microsoft Entra ID, Google Workspace or a generic OIDC or SAML provider) and sign in with test accounts from each group that needs access. Then connect the secret manager you chose, such as AWS, Azure, Google, HashiCorp Vault or CyberArk, and confirm the gateway reads its secrets from it. Your identity team and the platform team should both sign off. Done means a successful test login per role and a documented secret read in the gateway logs.
Move the master key into a secret manager
LiteLLM recommends keeping LITELLM_MASTER_KEY in a secret manager, and the key must start with sk-. Create the key in your chosen secret manager, reference it from the deployment instead of a plain environment value, and rotate away from any copy that lived in a config file or chart value. Restrict who can read the secret and record the change. Done means the master key is only read from the secret manager, and a test admin API call succeeds with the new reference.
Enable audit logs and RBAC
Turn on audit logs and set their retention policy to match your records requirement, then define organization and team RBAC roles that map to the groups from your identity provider. Enable team-based logging and any per-team logging opt-out you need, and decide where log export goes (GCS or Azure Blob are the documented targets). Your compliance lead should confirm the retention period against internal policy. Done means a test action appears in the audit log and a user without admin rights cannot change team or key settings.
Test the full path and document the baseline
Run a test plan that covers virtual key creation and rotation, budgets and rate limits, model restrictions, guardrail behavior on a sample prompt, and failover between two providers. Repeat the SSO sign-in and secret read after the restart. Record the configuration, the license key reference and the test results as the baseline for your change record. Done means every test has a pass result on file and the team agrees the gateway is ready for production traffic.
Remove the key to return to open source
To move back, remove LITELLM_LICENSE and restart the gateway on the same image. Open source keeps the features it documents, including virtual keys, budgets, spend tracking, the admin UI, load balancing, guardrails and the MCP gateway, but the Enterprise-only features stop working, including SSO beyond five users, SCIM, JWT authentication, audit logs, RBAC, IP allowlists, secret manager integrations and team-level logging. Re-check SSO for the admin UI, logging configuration and any secret reference, because the docs describe no data migration and you should confirm each setting still behaves as expected. Done means a documented re-test on the open source edition with a written list of features that changed.
Questions teams ask before buying LiteLLM Enterprise
Does SSO for LiteLLM really cost money after five users?
Yes, beyond the free limit. LiteLLM's Enterprise docs say SSO for the admin UI is free for up to 5 users, and from v1.76.0 an Enterprise license is required beyond that. Confirm the current threshold and how LiteLLM counts users, since the count determines when the license applies. Open source already supports SSO with Google, Microsoft Entra ID, Okta and generic OIDC providers for small admin groups, so the question is really how many people will sign in to the admin UI. Ask the vendor to confirm the user definition in writing before you size the license.
What does LiteLLM Enterprise cost, and what drives the price?
LiteLLM does not publish a price. It prices Enterprise by usage and deployment size on request, and sells it through AWS Marketplace, Azure Marketplace or invoice. The LiteLLM Enterprise docs describe a free 30-day trial and aim the offer at teams with 100 or more users or 10 or more production AI use cases. Drivers include user count, number of production use cases, deployment footprint, and whether you need support terms. Ask for a quote that lists the license metric, whether it recurs annually, any trial conversion terms, the marketplace billing path, and what support tier is bundled. Your own engineering time to operate the gateway is a separate cost and is not in the license.
How long does an Enterprise rollout take, and what does it need from the team?
The duration depends on your identity setup, secret manager and logging targets, and no supplied fact gives a timeline. Enterprise keeps the same self-hosted Gateway image and is set with the LITELLM_LICENSE environment variable, with nothing to migrate, so the license step itself is small. The real work is wiring SSO or JWT authentication to your identity provider, organization and team RBAC, secret manager integrations, audit log retention and any guardrail or log export targets. Plan for an identity owner, a platform engineer who runs the PostgreSQL and Redis tiers, and a security reviewer. Ask any implementation partner for a written scope and timeline before work starts.
Can an internal team run LiteLLM Enterprise without outside help?
Often yes, if the team already runs PostgreSQL, Redis and Kubernetes and has an identity owner. 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 recommends one Uvicorn worker per pod with horizontal scaling. The license does not change that operating model. External help is most useful for the first deployment, for hardening the master key and secret handling, and for building audit evidence. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms in your own infrastructure under fixed-scope agreements, and ongoing support is available as a retainer. Decide which parts your team owns before you request a quote.
Which guardrails need an Enterprise license?
The open source framework includes custom guardrails and Presidio PII masking. The llmguard, llamaguard, hide_secrets, OpenAI moderation, Google text moderation, Lakera and Aporia prompt injection integrations require an Enterprise license, according to the LiteLLM Enterprise docs. Check which of these providers you actually need, since each one may also carry its own vendor account, terms and cost outside LiteLLM. Confirm with LiteLLM whether team-level guardrails are included in your quote, because the docs list team-level guardrails and logging among Enterprise features. Verify each integration against your data handling requirements before you route regulated prompts through it.
How do upgrades and support windows affect Enterprise planning?
LiteLLM maintains support for the four most recent stable minor versions for both open source and Enterprise deployments, according to its enterprise documentation. The latest GitHub release at the time of writing is v1.105.1, published October 14, 2026, so plan upgrades against that cadence rather than against a fixed calendar. Enterprise adds optional 24/7 SLAs with 1 hour response for severity 0 issues and 72 hours for security patches, and a dedicated Slack or Teams channel, according to the docs. Ask the vendor which SLA tier is included in your quote, what the response clock starts from, and how upgrade testing windows are handled in your environment.
Does an Enterprise license change where my data lives?
No. The LiteLLM Enterprise page describes deployment as self-hosted in your infrastructure or air-gapped, with a multi-region control plane, so prompts and keys stay in environments you control. Your PostgreSQL, Redis and log destinations remain your responsibility. Ask the vendor to confirm in writing which components, if any, send telemetry or metadata outside your network, and which certifications it holds, including the SOC 2 Type 2 and ISO 27001 items listed on its page. Those are vendor claims that you should verify through their documentation, not assumptions for your own compliance file.
What a self-hosted LiteLLM rollout needs from your team
Whichever edition you run, the gateway depends on the same supporting infrastructure, and that work falls on your team. LiteLLM's production guide names PostgreSQL as the primary supported database, and virtual keys need PostgreSQL to store keys, per-key, per-user and per-team budgets and spend. Plan a database with backups, restore testing and a clear owner before the first virtual key is issued. Once more than one proxy instance runs, the guide calls for Redis 7.0 or newer, because shared rate limits, router state and cache depend on it. Platform engineers should size both services and confirm failover behavior for each, since a single proxy instance can be a shared point of failure for every application that calls a model.
On Kubernetes, LiteLLM recommends one Uvicorn worker per pod and horizontal scaling, with the guide suggesting 1 vCPU and 4 GiB of memory per worker as a starting point. Batching spend updates to the database every 60 seconds at scale is the documented behavior you should expect to see in spend reports, so confirm that finance and chargeback reports tolerate that delay. The master key, which must start with sk-, belongs in a secret manager, and security engineers should decide who may read it, how it rotates and how it stays out of container images, manifests and CI logs. Enterprise adds managed secret manager integrations and key rotation, but the open source edition still needs a documented process for the master key itself.
Ask your vendor, or confirm yourself, which items your own environment already covers: database and cache operations, the secret manager you will use, the identity provider that signs in administrators, and how upgrades will follow the four most recent stable minor versions that LiteLLM maintains. Those answers decide whether the work stays with your staff or goes to an implementation partner under a written, fixed scope. DeployOpen can plan, implement, harden and document this stack inside your own infrastructure, but the cost is driven by your existing platform skills and the number of teams onboarding, so request a quote against a written scope rather than estimating effort from this page.
How DeployOpen scopes and delivers a LiteLLM edition decision
Choosing between the MIT edition and an Enterprise license is a scoping decision before it is a purchase decision. DeployOpen works through the cards below with your team so the edition, the deployment and the support model are written down before any work starts.
Edition decision as the first deliverable
Before any build, DeployOpen maps your required controls against what the open source gateway already covers and what the Enterprise license key unlocks. The output is a written decision record naming each feature you need, the edition that provides it and the owner who accepts the trade-off. Ask for this record in every scope, whichever edition you choose.
Self-hosted deployment in your infrastructure
DeployOpen plans and implements the LiteLLM Proxy inside your own cloud accounts, data centers or air-gapped network, covering either edition. Scope should name the database, the Redis instance for multi-instance setups, the secret store and the network path to each model provider. Confirm which of these you already operate and which the engagement must build.
Identity and admin access setup
SSO for the admin UI is free for up to 5 users, and an Enterprise license is required beyond that. DeployOpen can configure Okta, Microsoft Entra ID, Google or a generic OIDC provider in the open source build, or the SSO, SAML, JWT and RBAC features in Enterprise. Confirm your user count and identity provider before the scope is written.
Guardrail and logging controls
Custom guardrails and Presidio PII masking run on the open source build, while several prompt injection and secret-hiding integrations need a license. DeployOpen can implement the controls you need, document which ones depend on the license key and test them against your policy. Ask for a list of each guardrail and the edition it requires.
Secrets, audit evidence and key rotation
Audit log retention, virtual key rotation and secret manager integrations for AWS, Azure, Google, HashiCorp Vault and CyberArk are Enterprise features. DeployOpen can prepare the configuration, the rotation runbook and the evidence your auditors will request, and it does not issue attestations. Confirm which audit controls your assessor expects and who holds the evidence.
Backup, upgrades and ongoing support
Engagements can include backups of the PostgreSQL database, documented upgrade paths across minor versions and runbooks for the operating team. Ongoing support, upgrades and continuous testing are available as retainers after the initial build. Ask for the upgrade window, rollback steps and the support hours written into the scope.
Fixed scope, written quotes and boundaries
Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, and a quote follows from the written scope. DeployOpen is not a LiteLLM partner or reseller, does not issue compliance attestations, and Enterprise licenses are bought from LiteLLM, through AWS Marketplace, Azure Marketplace or invoice.
