Repository navigation
Releases
LiteGate v2.18.0
Artifacts
| Artifact | Get it |
|---|---|
| Docker image | docker pull ghcr.io/brtydse100/litegate:2.18.0GHCR |
| Live demo | Current demo |
| Docs | Versioned documentation |
| Source | Source |
| License | MIT license |
What's Changed
- Add optional per-model key budgets and speed up policy editing by @brtydse100 in #47
- Discover Advanced policy settings and lazy-load organization branches by @brtydse100 in #48
Independent model budgets within a key allowance
Administrators can set a model-specific dollar amount and reset period on
selected existing keys, such as $25 for an Opus model alias every two hours.
Model spending also counts toward the key's overall budget; both limits apply
independently. Explicit replacement supports editing or clearing the complete
per-model mapping. Zero-dollar model limits are rejected because LiteLLM treats
zero as unlimited. Limits must be positive; use allowed-model restrictions to
deny access instead. LiteLLM performs accounting, resets and enforcement.
Per-model budgeting is off by default. Activate a valid LiteLLM Enterprise
license on the upstream proxy, then set LITELLM_ENTERPRISE_ENABLED=true in
LiteGate and restart it. Docker Compose YAML uses
litellm_enterprise_enabled: true; Helm uses
config.litellmEnterpriseEnabled=true. This is a manual feature switch, not
automatic license detection. Turning it off hides editing and rejects new
per-model API writes without removing existing upstream limits.
Keys with per-model budgets require administrator-assisted rotation in LiteLLM.
LiteGate rejects self-service regeneration before creating, renaming or revoking
keys, so replacement cannot silently drop limits or restart model usage windows.
This safeguard also applies when the feature switch is off. See
per-model budget configuration.
Advanced settings discovered from the installed LiteLLM
Key and team editors retain familiar controls and discover additional fields
under Advanced settings from the connected proxy's OpenAPI request schemas.
Supported newly advertised fields can appear without adding matching LiteGate
form definitions. Typed controls handle simple values; JSON inputs handle nested
settings. Only opted-in edits are sent, and changing targets discards drafts.
Missing schema discovery leaves familiar controls usable.
Discovery and writes remain administrator-only. Bounded caching, local-reference
resolution and server-side validation exclude credentials, identity/member
bindings, spend counters and dedicated workflows. Existing Enterprise and
organization-owned allowance protections still apply. Unknown schema constraints
are omitted safely. The approved jsonschema dependency is included in the image;
source installations should install the updated backend requirements. No new
service or persistent state is required.
The pinned LiteLLM 1.98 integration supports discovered MCP rate/permission
settings and team-member allowance defaults. It does not advertise per-model
team-member budgets; LiteGate does not invent unsupported features. An unrelated
Advanced MCP team update now preserves existing metadata and member-budget
associations instead of dropping the member allowance. License entitlement and
breaking upstream semantics can still require compatibility work. See
discovered policy settings.
Progressive organization navigation and responsive editing
The Organization page shows root-group metadata first. Selecting or expanding a
group requests its direct children and live team details; deeper branches load
as opened and revisits use cached results. Users and usage reports wait for an
explicit selection. Loading and failures are independent so an unresolved inner
team does not block navigation. Team spend is labelled separately from subtree
usage aggregates, and the legacy full-overview API remains compatible.
Key policies use the page scrollbar for key/model lists and cache selection
lookups, avoiding repeated full-selection searches while editing large key sets.
The synthetic public demo and operator/API guides cover the new workflows.
Upgrade and validation
Pin image 2.18.0 and restart the deployment. Existing settings remain valid;
the Enterprise switch defaults to false. Review the regeneration restriction
above if model budgets were previously configured directly in LiteLLM.
Validation included 696 backend tests, 115 frontend tests, 13 browser tests and
two demo tests, plus pinned live LiteLLM compatibility checks and a Docker build.
Local simulated Enterprise activation verified actual LiteLLM model-budget
enforcement and key/team MCP-setting persistence with PostgreSQL and synthetic
model responses. Genuine license verification and external MCP tool invocation
were not tested.
Full Changelog: v2.17.0...v2.18.0
Contributors
Thanks to @brtydse100 for the changes in this release.
LiteGate v2.17.0
Artifacts
| Artifact | Get it |
|---|---|
| Docker image | docker pull ghcr.io/brtydse100/litegate:2.17.0GHCR |
| Live demo | Current demo |
| Docs | Versioned documentation |
| Source | Source |
| License | MIT license |
What's Changed
- Customize portal messages, simplify key actions, and document Docker hierarchy by @brtydse100 in #46
- fix: correct the nightly E2E Node action pin by @brtydse100 in cf73f2d
Independent login and My key messages
Set login_text to replace the login subtitle and my_key_text to display
guidance below the My key action area, before and after key creation. The
messages are independent, support line breaks, and display HTML and Markdown
literally. Empty login text keeps the existing subtitle; empty My key text
hides the guidance. The existing logo_url now also supplies the login logo.
Docker uses these settings in its mounted config.yaml; environment equivalents
are LOGIN_TEXT, MY_KEY_TEXT, and LOGO_URL. Helm uses config.loginText,
config.myKeyText, and config.logoUrl. Environment values override YAML.
Restart the backend or recreate the container after changes; Helm deployments
also need a restart after upgrading the appearance values. No frontend rebuild
is needed for runtime text or image URLs. Bundling a new image asset still
requires a build or an explicit static-file mount.
Both configuration endpoints are public. Keep the messages and logo appropriate
for unauthenticated visitors. No authentication, key policy, or secret-storage
defaults change. See the configuration guide.
One key action after creation and regeneration
For one-time secrets, Hide API key replaces the regeneration action below
the information card while the new secret is visible. Hiding the secret restores
the regeneration action, subject to the existing cooldown. Copying, stored-key
reveal behavior, confirmation, and spend-preserving rotation remain supported.
Docker organization hierarchy documentation
The hierarchy guide now gives Docker/Compose YAML and JSON environment examples,
read-only file mounts, container paths, configuration precedence, and restart
instructions alongside Helm setup. It clarifies that spending allowances and
informational group totals are separate from RPM, TPM, and concurrency limits.
See Docker and Compose hierarchy setup.
Nightly E2E repair
The nightly workflow referenced a truncated, invalid actions/setup-node SHA,
so GitHub Actions stopped before installing dependencies or running tests.
It now uses the verified full SHA already used by CI. The nightly schedule,
Node version, browser suite, and permissions are unchanged.
Full Changelog: v2.16.0...v2.17.0
Contributors
Thanks to @brtydse100 for the changes in this release.
LiteGate v2.16.0
Artifacts
| Artifact | Get it |
|---|---|
| Docker image | docker pull ghcr.io/brtydse100/litegate:2.16.0GHCR |
| Live demo | Current demo |
| Docs | Versioned documentation |
| Source | Source |
| License | MIT license |
What's Changed
- Fix configured Model Hub URL being modified by @brtydse100 in #44
- Add configurable parallel request defaults for generated keys by @brtydse100 in #45
Model Hub link upgrade
litellm_ui_url is now used exactly as configured. LiteGate no longer appends
/ui/model_hub_table. If your configuration supplies only a base URL, update it
to the desired full destination, such as https://litellm.example.com/ui/model_hub.
An empty value still hides the button. Helm uses config.litellmUiUrl.
Optional key concurrency default
Set a positive integer with key_max_parallel_requests in YAML,
KEY_MAX_PARALLEL_REQUESTS in the environment, or config.keyMaxParallelRequests
in Helm. LiteGate forwards it to LiteLLM for newly created and regenerated keys,
including organization-managed keys. Omit it to preserve LiteLLM's default.
Existing keys are unchanged until regenerated; LiteLLM enforces the per-key limit.
No new dependencies, services, or persistent state are required.
Full Changelog: v2.15.4...v2.16.0
Contributors
Thanks to @brtydse100 for the changes in this release.
LiteGate v2.15.4
Artifacts
| Artifact | Get it |
|---|---|
| Docker image | docker pull ghcr.io/brtydse100/litegate:2.15.4GHCR |
| Live demo | Current demo |
| Docs | Versioned documentation |
| Source | Source |
| License | MIT license |
What's Changed
- Migrate existing hierarchy users at startup and preserve stored key lookup by @brtydse100 in #43
Stored keys and startup hierarchy
Owned-key lists retain their original identifiers when refreshed LiteLLM metadata
contains null, masked or replaced identifier fields. Existing stored secrets
remain available with the same SQLite volume and owner; ownership checks remain
unchanged. The personal page waits for configuration and key lookup results
before suggesting replacement. This reproduces an identifier-overwrite failure;
it does not establish the cause of a particular deployed incident.
Startup awaits its first hierarchy reconciliation attempt, then retries every
60 seconds. Exact-ID lookup takes precedence. Unresolved email selectors search
all relevant pages and require one normalized exact existing account, re-read by
actual ID before assignment. Missing users are skipped; no accounts or keys are
created, deleted or rotated by discovery. Keys retain secrets, aliases, models
and spend through existing policy migration.
Identity and operational limits
Remote-derived email assignments are operator policy, not SSO identity proof.
Every pass revalidates them; changed/ambiguous/incomplete results, local/admin
matches and path conflicts skip writes with errors. Verified accepted/rejected
claims, subject login, email verification and stored-secret ownership remain
unchanged. No new dependencies, services, tables or backend settings are required.
Keep the SQLite volume. Each scan allows 100 pages of 100 users and 60 seconds,
with five concurrent lookups. Per-user failures retry; initial completion does
not promise all remote writes succeeded. Helm allows 30 minutes for startup;
large installations may need longer.
Full Changelog: v2.15.3...v2.15.4
Contributors
Thanks to @brtydse100 for the changes in this release.
LiteGate v2.15.3
Artifacts
| Artifact | Get it |
|---|---|
| Docker image | docker pull ghcr.io/brtydse100/litegate:2.15.3GHCR |
| Live demo | Current demo |
| Docs | Versioned documentation |
| Source | Source |
| License | MIT license |
What's Changed
- Fix small spend charts and preserve counters during key regeneration by @brtydse100 in #42
Spend charts and current counters
Hierarchy spend charts retain up to six decimal places and use scientific
notation below a microdollar. Usage bars scale to the selected maximum, and
longer axis labels fit inside the chart.
The personal dashboard reads live owned-key counters rather than potentially
stale user-list spend. Regeneration verifies carried spend after budget-policy
updates and before deleting original keys. If the replacement cannot be
verified, it is revoked and the original alias restored. Counter decreases
require valid advancing reset timestamps; unavailable counters return an error
instead of becoming zero.
Upgrade and limits
No configuration changes or migration are required. Historical charts and
current budget counters can cover different periods. This release does not
reconstruct counters already reset to zero from historical usage, and cannot
serialize independent LiteLLM requests or spend flushes.
Full Changelog: v2.15.2...v2.15.3
Contributors
Thanks to @brtydse100 for the changes in this release.
LiteGate v2.15.2
Artifacts
| Artifact | Get it |
|---|---|
| Docker image | docker pull ghcr.io/brtydse100/litegate:2.15.2GHCR |
| Live demo | Current demo |
| Docs | Versioned documentation |
| Source | Source |
| License | MIT license |
What's Changed
- Add hierarchy JSON file input and Helm ConfigMap mounts by @brtydse100 in #41
Hierarchy JSON file input
Load the existing {"levels": [...]} hierarchy from a UTF-8 JSON file with
organization_hierarchy_file / ORGANIZATION_HIERARCHY_FILE. Relative paths
resolve against backend/. The file loads once at startup and uses the same
hierarchy validation, SSO email/ID/group matching, and inherited budgets as inline
configuration. Missing, unreadable, malformed, and invalid files fail startup.
Nonempty inline hierarchy levels cannot be combined with a file.
Helm's top-level organizationHierarchyFile selects an existing namespace
ConfigMap, with key: organization.json and
mountPath: /etc/litegate/organization.json defaults. It mounts the key read-only
with subPath and sets the file environment variable. Changing file options
triggers rollout; changing external ConfigMap contents requires an explicit
rollout restart. Docker Compose supports an optional read-only JSON mount.
Upgrade
The feature defaults off. Existing inline YAML and environment JSON remain
supported. This adds an input for the existing hierarchy; it does not restore
the removed standalone organization email-mapping schema or change authentication,
email verification, identity bindings, or budget policy. See
organization configuration for setup.
Full Changelog: v2.15.1...v2.15.2
Contributors
Thanks to @brtydse100 for the changes in this release.
LiteGate v2.15.1
Artifacts
| Artifact | Get it |
|---|---|
| Docker image | docker pull ghcr.io/brtydse100/litegate:2.15.1GHCR |
| Live demo | Current demo |
| Docs | Versioned documentation |
| Source | Source |
| License | MIT license |
What's Changed
- Fix SSO verification and unify email assignments in organization hierarchy by @brtydse100 in #40
Unified hierarchy assignments
SSO emails now belong in hierarchy members' userIds. Email, exact ID, and
SSO group matches resolve one compatible path with existing inherited
memberships and key allowances. Local users keep explicit ID assignments.
SSO email-verification fix
Fixes v2.15.0's hardcoded rejection of explicitly unverified emails matched by
the standalone email mapping. generic_require_verified_email (Helm
config.genericRequireVerifiedEmail) now governs generic SSO consistently:
true rejects an explicitly false email_verified claim, while false permits
it. Hierarchy email and SSO-group assignments do not override this choice.
Missing verification claims retain their existing behavior; OIDC token
verification and its existing email behavior are unchanged.
Upgrade
Important
This release removes the separate email-mapping configuration introduced in
v2.15.0. Nonempty old options fail startup with migration guidance; updating
the image alone is insufficient when those options are configured.
- Upgrade the Helm chart and application image together.
- Remove
organization_mapping,organization_mapping_file, their environment
equivalentsORGANIZATION_MAPPING/ORGANIZATION_MAPPING_FILE, Helm
config.organizationMapping/config.organizationMappingFile, and mounts
used only for the removed standalone JSON mapping. - Put individual emails in the existing
organizationHierarchy.levels[].groups[].members[].userIds. KeepssoGroups
alongsideuserIdson the same hierarchy member; existing exact user IDs,
parent inheritance, and budget policies remain supported.
For example, within an existing hierarchy's members list:
- name: Platform
userIds: [alice@example.com, employee-123]
ssoGroups: [platform]New users remain config-only until their first authenticated SSO login
provisions the actual subject without generating a key. No pre-login placeholder
account is created.
Preserve the SQLite volume. Existing 2.15.0 canonical provider/subject bindings
continue to work. Unbound reservations require durable ownership evidence;
pending email candidates require their authenticated existing subject. No new
reservations, user deletions, or key ownership transfers occur. Existing spend,
keys, and memberships are retained; revocation remains an operator decision.
Full Changelog: v2.15.0...v2.15.1
Contributors
Thanks to @brtydse100 for the changes in this release.
LiteGate v2.15.0
Artifacts
| Artifact | Get it |
|---|---|
| Docker image | docker pull ghcr.io/brtydse100/litegate:2.15.0GHCR |
| Live demo | Current demo |
| Docs | Versioned documentation |
| Source | Source |
| License | MIT license |
What's Changed
Warning
Upgrade to v2.15.1
for hierarchy-based individual email assignments. In v2.15.0, a user matched
by the standalone email mapping is rejected when SSO reports
email_verified: false, even if generic_require_verified_email / Helm
config.genericRequireVerifiedEmail is disabled.
The standalone organization_mapping / organization_mapping_file options
and Helm config.organizationMapping / config.organizationMappingFile are
removed in v2.15.1. Move individual emails into the existing
organizationHierarchy members' userIds, alongside ssoGroups, before
upgrading. Upgrade the chart and image together and preserve the SQLite
volume to retain existing account bindings and keys. The implementation
described below is historical behavior specific to v2.15.0.
- Add email-based organization mapping with inherited memberships by @brtydse100 in #38
Email organization mapping
Deployers can assign emails to groups when SSO group claims are outdated. The
same levels array with named groups works in inline Helm/Compose values or a
mounted JSON file. Each group's parent defines upward inheritance. The original
flat groups mapping remains supported; existing SSO group mappings and the
budget-managed organization hierarchy retain their policy precedence.
Startup can provision ordinary LiteLLM users and memberships without generating
keys. Durable bindings in the existing SQLite database connect them to their
authenticated provider identity at first login. Existing unproven email matches
remain pending until SSO confirms ownership; superseded reservations are retained
without deleting users or transferring keys. Membership changes are additive,
so removing configuration does not revoke existing memberships.
Upgrade
Upgrade the chart and application image together to use the new mapping options.
Preserve the SQLite data volume: identity tables initialize automatically and
existing users and keys require no manual migration. Referenced teams must
already exist. Use one inline or file source and restart after changing a JSON
file; inline Helm changes trigger a rollout. Review pending identities and
retained user records in LiteLLM, including their possible user-count impact.
Every PR now requires a verified preview image from its final commit; official
stable images continue to be published from validated commits on main.
Full Changelog: v2.14.0...v2.15.0
Contributors
Thanks to @brtydse100 for the changes in this release.
LiteGate v2.14.0
Artifacts
Prepared release: versioned artifacts become available after a validated commit
is merged to main, tagged v2.14.0, and the publication workflow succeeds.
| Artifact | Get it |
|---|---|
| Docker image | docker pull ghcr.io/brtydse100/litegate:2.14.0 (after publication)GHCR |
| Live demo | Current demo |
| Docs | Documentation after tagging |
| Source | Source after tagging |
| License | Current MIT license |
What's Changed
- docs: highlight Helm upgrade in v2.13.0 release notes by @brtydse100 in #31
- Show individual member usage in leaf organization groups by @brtydse100 in #32
- Prepare v2.14.0 with automatic key migration and stable rotation names by @brtydse100 in #33
Key migration and presentation
- Existing owned keys move in place into the primary mapped/default SSO team or
deepest configured organization team, including keys previously in other
teams. Secrets and spend remain intact. Old memberships and their spend
records are retained for administrator review. - Managed keys retain verified inherited allowances and ancestor-restriction
safeguards. Failed migrations can be retried and are bounded to 500 existing
keys per user. Existing policy-verification failures still require attention. - Personal spend uses six decimal places. Rotated keys use the normal
name's keyname; replacement temporarily frees a conflicting alias while
keeping the old credential live until generation succeeds. - Saved-key reveal behavior is unchanged.
Upgrade
Upgrade the Helm chart and application image together. Preserve the existing
SQLite volume and key-storage setting to retain saved secrets. Review team
mappings before rollout: login and reconciliation now move keys already assigned
to another team into the configured team without requiring manual migration.
Full Changelog: v2.13.0...v2.14.0 (available after tagging)
Contributors
Thanks to @brtydse100 for the changes in this release.
LiteGate v2.13.0
Artifacts
| Artifact | Get it |
|---|---|
| Docker image | docker pull ghcr.io/brtydse100/litegate:2.13.0GHCR |
| Live demo | Current demo |
| Docs | Documentation |
| Source | GitHub |
| License | MIT |
Warning
Helm upgrade required for organization hierarchy
Use the Helm chart from the LiteGate v2.13.0 source tag together with
application image 2.13.0. Changing only image.tag does not add the hierarchy
configuration or automatic rollout support. Hierarchy management remains
disabled by default.
What's Changed
-
Add organization hierarchy and lowest-team key allowances by @brtydse100 in #25
-
Show current policy values and safely migrate individual key budgets by @brtydse100 in #26
-
Cover concurrent key regeneration and preserved spending by @brtydse100 in #27
-
Unify personal API key display and show-hide controls by @brtydse100 in #28
-
Add isolated LiteLLM and OpenRouter budget testing helpers by @brtydse100 in #29
-
release: prepare v2.13.0 by @brtydse100 in #30
Organization budgets and upgrade notes
organizationHierarchy.levels: []keeps hierarchy management disabled by
default. Enable up to eight configured levels through Helm or Compose YAML.
Back up the existing LiteGate SQLite database and LiteLLM policies before
enabling reconciliation; update the application image and Helm chart together.- Each group owns a real LiteLLM team. A user's key belongs to the deepest
matching group. The compatibility-namedperUsersetting supplies the
inherited per-key allowance; it is not a second personal user budget. - Parent
groupTotalvalues are tracking targets only. Organization reports
sum native descendant team spend; ancestor targets do not block requests.
Native Teams spend remains attributed to the key's actual owning team. - Reconciliation verifies key ownership and allowances before removing duplicate
personal/member caps or obsolete shared caps. Unknown or unprotected
credentials keep their old caps. Conflicting memberships and policy-losing
migrations fail with a synchronization warning. - LiteLLM needs a database and its key/team management APIs. Daily analytics
also depend on the deployed LiteLLM version and license. Detailed reports
attribute historical usage using current membership.
See Organization hierarchy and
configuration for examples, inheritance and safeguards.
Policy editing and key safety
- Key and team editors show saved values and retain saved model names. Bulk key
edits submit only changed fields. Model checkboxes and numeric controls follow the
selected theme. Key settings appear after selection; managed teams are tagged. - An explicit administrator action can migrate an unmanaged owner's sole finite
key allowance away from duplicate personal and team-member caps. Shared team
budgets remain in force; unsupported verification returns an item-level error. - Regeneration retains recorded spend and a known finite unmanaged key budget
and reset interval. Migration, rotation and personal portal deletion share the owner lock.
An unverifiable replacement is revoked before the old key is deleted. - Created and revealed personal keys share a compact green panel, copy icon and
full-width Show/Hide control. Optional stored secrets still require authorized
reveal requests and stay in component memory in the browser. Secret storage
remains disabled by default. Sub-cent spend remains visible in reports.
Local testing
The testing guide includes isolated
LiteLLM/LiteGate startup, free OpenRouter model registration, and a request script.
Provider credentials are entered locally. High and cheap model prices are
artificial local accounting rates for budget tests, separate from provider cost.
Full Changelog: v2.12.2...v2.13.0
Contributors
Thanks to @brtydse100.