LiteLLM team based logging

How LiteLLM team based logging keeps one team's prompts out of another team's logs

A shared LiteLLM gateway can send each team's prompts to its own logging destination, or turn logging off for that team or for a single key. The team and key based logging feature attaches that setting to the team or virtual key, so every request made with that credential follows it without changes to the application. The LiteLLM docs give disabling logging for one team for GDPR compliance as an example, which is a common reason teams ask for it. Teams typically need this when business units operate under different data-sharing rules, when one team's prompts must stay in a tool or region the others cannot reach, or when a vendor agreement covers only some teams. The docs do not say that any specific regulation requires it, so confirm the obligation with your privacy or legal function before you design around it.

The docs list Langfuse, a GCS bucket, LangSmith and Arize among the logging integrations that team-based logging supports. The two main patterns are routing a team to its own Langfuse project, so its traces land in a separate workspace, or assigning custom callbacks that send a team's logs to another system. Confirm the integration list for the release you run, because support can differ by version. Then test each destination before you rely on it. Send a tagged request from team A and confirm it appears only in A's destination. Send one from team B and confirm it never reaches A's destination. Repeat the check for a key that has logging turned off to confirm that nothing is written at all.

Parts of this feature require an Enterprise license, so decide early which settings your gateway depends on. The LiteLLM Enterprise documentation lists team-level guardrails and logging among the Enterprise capabilities. The license split follows the repository layout: content under the enterprise/ directory uses the enterprise license, and the rest of the code is MIT licensed. Have your team read enterprise/LICENSE and the Enterprise documentation to confirm which team logging controls are covered before you purchase or write the design around them. If the setting is Enterprise only, the Enterprise license also brings a dedicated engineering support channel, and optional SLAs are described in the docs. Ask for those terms in writing if you need them.

Separation is only as strong as the destination that receives the logs. If each team logs to its own Langfuse project, check who can see that project. Project-level roles are an Enterprise feature of self-hosted Langfuse and need a Langfuse license key, while its core features are available in the MIT licensed open source version. Also decide whether teams can share infrastructure, such as one Langfuse instance, one ClickHouse cluster or one storage bucket. Shared infrastructure may be acceptable with logical separation, but it changes what you can say about isolation to an auditor or a data owner. Ask each destination vendor how project data is stored, who operates the platform and how deletion requests are handled.

Which logging configuration fits which team or key

This table compares five logging setups on a shared LiteLLM gateway: a team or key sent to its own Langfuse project, to a custom callback, to a GCS bucket or other listed destination, a shared default, and logging turned off for one team. Read each row for what is separated, what stays common across teams, and whether an Enterprise license may apply. Most mixed setups combine a shared default with one or two exceptions for teams with stricter requirements.

Option	What it separates and leaves shared	License note	When it fits
Team or key to its own Langfuse project	Separates that team's traces into a separate Langfuse project. The gateway, its database and routing stay shared.	Confirm with LiteLLM. Project-level RBAC in self-hosted Langfuse needs a Langfuse Enterprise license key.	Teams that need their own trace access boundary inside one Langfuse instance.
Team or key to a custom callback	Sends that team's logs to a callback you write or run. The gateway and other teams' logging stay shared.	Confirm with LiteLLM for each callback type. Your callback code and its data handling are yours to govern.	Destinations LiteLLM does not list, or logs that need transformation before storage.
Team or key to a GCS bucket or other listed destination	Stores that team's logs in a bucket you choose. Bucket permissions and retention are set in your cloud account.	Confirm with LiteLLM whether this path needs Enterprise. Bucket access controls are configured by you.	Teams that need object storage in a specific cloud account with their own access and retention rules.
Shared default destination	No separation. All teams' logs go to one destination, so access is controlled only at that destination.	Confirm with LiteLLM whether any default logging setting depends on license tier.	Teams with no differing logging or privacy requirement, and the baseline for everyone else.
Logging disabled for one team	Stops logging for that team's requests, separating them from every destination. The gateway still routes its traffic.	Confirm with LiteLLM whether this needs Enterprise. The docs cite GDPR compliance as an example use.	Teams whose prompts must not be stored, after you confirm which audit and spend records you still need.

How the gateway decides where a team's or key's logs go

Each request to a shared LiteLLM gateway is resolved to a key and a team, then matched to a logging setting. The cards follow that order, from identity to destination, and end with the fallback and precedence rules you must confirm for your release.

Identify the key and team first

Every request to the gateway arrives with a virtual key, and each key belongs to a team. That pairing is the input to every logging decision, so the resolution order starts here. Before you design destinations, list which keys exist, which team each one belongs to, and whether any key is shared between applications. A shared key cannot be split across two destinations, so it should be reissued per application.

Read the logging setting on the key or team

The gateway looks up the logging configuration attached to the matched key or team. This setting names the destination, such as a dedicated Langfuse project or a custom callback, and it is the only input the gateway needs to route the trace. Check how the setting is stored and who can edit it, because a change made in the admin UI or API affects every request that follows.

Route to a destination or drop the logs

If the setting names a destination, the traffic is sent there. If logging is off for that team, the request is still served, but its prompts and responses are not sent to any logging backend. The docs list Langfuse, GCS bucket, LangSmith and Arize among supported destinations. Test both paths with a sample request, then confirm in each destination that the trace appeared or stayed absent.

Handle keys without a team setting

Some keys have no team-level logging setting, for example keys created outside a team or teams that were never configured. The gateway still has to decide where that traffic goes. Confirm in the docs for your LiteLLM version whether such keys inherit gateway-wide callbacks, use a key-level setting, or log nowhere. Record the answer, because an unplanned default is a common path to logging that nobody intended.

Confirm key versus team precedence

When a key has its own logging setting and its team also has one, the gateway must pick a winner. The precedence rules are version specific, so read the team and key logging documentation for the release you will run, and do not rely on memory or a forum post. Build a test matrix that sets each combination of key and team settings, then check where each trace lands.

Map Enterprise features before design

Parts of team and key based logging require an Enterprise license. If your design depends on per-team controls, confirm with LiteLLM which features your edition includes before you commit to a destination model. Request the feature list in writing, and record which callbacks are open source and which are gated, so the design does not depend on a feature your license does not cover.

When separate logging destinations matter for compliance

A separate logging destination matters when a shared LiteLLM gateway carries prompts that may contain personal data for teams with different privacy obligations. Team and key based logging lets each team or key send its traffic to its own Langfuse project or custom callback, or turn logging off for that team. The LiteLLM documentation gives disabling logging for one team for GDPR compliance as an example. The separation is a control that supports a privacy or audit position. It does not settle that position by itself, and your legal or compliance function decides what is required for each team.

Data minimization asks whether a destination needs full prompts and responses at all. Purpose limitation asks whether the data in a destination is used only for the purpose it was collected for, such as debugging one application rather than general analytics across the company. A team that sends only low-sensitivity requests may need metadata and no content, while a team handling customer records may need no content logging at all. Decide per team or key which fields are stored, record the reason, and check that the logging configuration matches that decision. Masking at the gateway changes what reaches each destination, so review it alongside these choices.

Each destination has its own readership, and that determines who can see the prompts. In a self-hosted Langfuse deployment, project-level RBAC roles are a feature that needs an Enterprise license key, so confirm whether your setup can limit which people see which project before you depend on it. Consider the administrators of the logging platform, the cloud accounts that host its database and storage, and any vendor support staff with access. Residency works the same way: the region where the Langfuse data stores or the GCS bucket run determines where logged prompts physically sit. A team with an in-region requirement needs a destination in that region, and your infrastructure team should confirm the location.

Retention is often the strongest reason to split destinations. A team with a short retention requirement should not share a store with a team that needs a longer history. For self-hosted Langfuse, data retention policies are also an Enterprise license key feature, while a GCS bucket's retention is set through lifecycle rules in your cloud account. Ask each team owner for the period they need, write it down, and test that deletion actually runs. The gateway's own spend log retention is a separate setting covered in its own topic. For the wider data-flow picture, including what each component stores, read the LiteLLM compliance topic. DeployOpen can implement and document these controls, but it does not issue audit reports or certifications; independent auditors and certification bodies do that work.

What a self-hosted Langfuse destination needs before teams point at it

A self-hosted Langfuse is not a single container. It runs Langfuse Web for the UI and APIs, Langfuse Worker for asynchronous event processing, and four supporting stores: PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. Each component needs an owner and a size before a LiteLLM team sends its first trace.

Langfuse Web: serves the UI and APIs. The scaling guide lists a minimum of 2 CPU and 4 GiB.
Langfuse Worker: processes events asynchronously and scales on CPU load. The minimum is 2 CPU and 4 GiB.
PostgreSQL: holds application metadata. The minimum is 2 CPU and 4 GiB.
Redis or Valkey: the minimum is 1 CPU and 1.5 GiB.
ClickHouse: stores analytical trace data. The minimum is 2 CPU and 8 GiB, with at least 16 GiB of memory for larger deployments.

These figures are the scaling guide's minimums, not a sizing for your traffic. Ask your platform team to size each component against expected LiteLLM request volume, retention period and the number of teams that will share the instance.

How to set up team and key based logging on a self-hosted gateway

This sequence routes each team's or key's LLM traffic to its own logging destination, or turns logging off for a team, on a shared LiteLLM gateway. Each step closes with a check, so the finished configuration can be shown to be working and recorded as a change.

Confirm release line and license coverage
Your platform lead confirms which LiteLLM release line the gateway runs and checks that it is still within the supported window of the four most recent stable minor versions. Then the lead confirms, in writing with the vendor or against the enterprise documentation for that version, whether team-level logging is available under the open-source license or needs an Enterprise license. Some parts of this feature require Enterprise, so do not assume coverage from the feature list alone. The step is done when the release version and the licensing answer are recorded in the change file with the name of the person who confirmed them.
Confirm database and Redis prerequisites
The platform team confirms that the gateway uses PostgreSQL, because virtual keys need a PostgreSQL database. If more than one proxy instance runs, the team also confirms a Redis deployment on version 7.0 or newer, which the production guidance requires for shared rate limits, router state and cache. Engineers check that the proxies can reach both services from every instance and that the connection details are held in the secret manager, not in configuration files. The step is done when a test connection from each proxy instance succeeds and the Redis version reported by the server is recorded.
Deploy or confirm each team's logging destination
The platform team, with the owners of the logging system, deploys the destination that each team will use. If the destination is a self-hosted Langfuse instance, the usual pattern is one project per team, which needs the web and worker containers, PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage in place. Engineers create the project for each team, generate its public and secret API keys, and store them in the secret manager. Confirm which Langfuse features the chosen deployment needs, such as project-level roles or audit logs, because some require a Langfuse Enterprise license key. The step is done when each project loads in the browser and holds its own keys.
Create teams and virtual keys with ownership recorded
The gateway administrator creates one LiteLLM team for each group that needs separate logging, then issues the virtual keys that belong to those teams. Each key is recorded in an ownership register with its team, the person or service that holds it, the models it may call and its budget. Keys that serve a single application should be named after that application so later reviews can trace their traffic. The step is done when the administrator can list every key with its team and the register matches the gateway's own list exactly, with no key left unassigned.
Attach each destination or disable logging per team
For each team or key, the administrator either attaches the logging destination created in the earlier step or disables logging for that team. Disabling logging is the setting to use where a team's traffic must produce no records, for example where the topic's GDPR example applies. Each change is made through the team configuration and saved, and the administrator writes down which callback or destination each team now points to. The step is done when the saved configuration, read back from the gateway, matches the ownership register for every team, with no team pointing to a destination it should not use.
Send test requests and confirm destinations
An engineer sends one test request with a key from each team, using a clearly marked test prompt that contains no personal data. The engineer then checks the destination for each team and confirms the request appears only in the project that team was assigned, and in no other project. The result for each test is noted with the time, the key identifier used and the destination checked. The step is done when every team's test request shows in its own destination and in no other destination, and any mismatch has been traced to a configuration cause and corrected before continuing.
Confirm disabled teams produce no records
An engineer sends test requests with a key from each team that has logging turned off and checks every destination the gateway uses, including the gateway's own database logs where spend is recorded. The check is for the absence of records that contain the test prompt, which is the point of the control. The engineer also records what the gateway still stores for that team, such as spend totals, so the privacy owner can judge the residual data. The step is done when no test prompt from a disabled team appears in any logging destination, and the residual data is written down and reviewed by the privacy owner.
Record the configuration as a change
The platform lead records the finished configuration as a formal change in the change management system, including the release version and license answer, the database and Redis versions, the destination for each team, the list of disabled teams and the test results. The record links to the ownership register and to the saved configuration export. The lead asks the security or compliance owner to review and approve the change before it is treated as the baseline for audits or later upgrades. The step is done when the change is approved and the approval, the test evidence and the register are stored together where auditors can find them.

Security and operations risks of per-team logging

The most likely failure of per-team logging is a silent misconfiguration: one team's logging setting is missing or wrong, so its prompts and responses reach a destination nobody approved, such as a shared Langfuse project or a shared bucket. The gateway can look healthy while this happens, because the setting lives on the team or key rather than in a single global switch. Treat team logging configuration as security configuration. Review it when a team is created, after every change, and in a scheduled comparison between the live settings and your approved register of destinations. Ask the vendor to confirm what the gateway does when a team has no logging callback, and whether requests fall back to a global destination. Then test that behavior in your own environment before you rely on it.

Every destination needs credentials, such as Langfuse project keys, a Google Cloud Storage service account, or LangSmith and Arize keys. Those credentials are held in the gateway's configuration and database, so anyone who can edit a team's callback settings may be able to redirect traffic or read secrets. Decide who holds team administration rights, keep those rights separate from key administration where your staffing allows, and record who may change destination credentials. Confirm with the vendor how stored credentials are encrypted and where the encryption key is held. Rotate destination keys when someone leaves a team or when a destination project is handed over. Parts of this feature need an Enterprise license, so confirm which logging integrations your license covers before the design is final.

Logging changes are only useful in an investigation if they can be tied to a person. A shared administrator login makes every change to team logging unattributable. The LiteLLM admin UI supports SSO with Google, Microsoft Entra ID, Okta and generic OIDC providers. According to the LiteLLM documentation, SSO is free for up to 5 users from v1.76.0, and an Enterprise license is needed beyond that. Set up SSO before you configure team logging for production, and make sure administrators sign in with individual accounts. The audit trail itself is covered in the audit logs topic. Separately, LITELLM_MASTER_KEY, which must start with sk-, grants full administrative control over the gateway. Keep it in a secret manager rather than in container environment files or source control. Enterprise adds secret manager integrations for AWS, Azure, Google, HashiCorp Vault and CyberArk. Confirm which of these fits your existing estate.

If several teams send logs to one Langfuse instance, the separation between them depends on Langfuse as well as on the gateway. Langfuse's core features and APIs are available under the MIT license, but project-level RBAC roles, server-side data masking, audit logs and data retention policies require an Enterprise license key on a self-hosted deployment. Without project-level RBAC, a user with access to one project may be able to view data held in another, so decide the access model before traffic starts. Without server-side masking, personal data in prompts is stored as sent. Test masking with sample prompts that contain fabricated personal data (illustrative), and check the results in the stored traces. Confirm with Langfuse which of these controls your license key unlocks, and whether they meet the separation your data classification requires.

Turning logging off for a team, for example to support a GDPR-related decision as the LiteLLM documentation describes, is only a control if it survives normal operations. Upgrades, configuration redeploys and database restores can each change team settings. Build a check into your runbook. After every upgrade and every restore from a PostgreSQL backup, list each team's logging setting, confirm that the disabled teams are still disabled, and send a test request from each disabled team to confirm that nothing reaches a destination. Keep the results as evidence. Plan upgrades within the release window that LiteLLM says it supports, which covers its four most recent stable minor versions for open source and Enterprise deployments. Ask the vendor to confirm whether team logging settings are restored from the database or from configuration files, because that answer determines which backup you must verify.

What to confirm before relying on team based logging

Team and key based logging works as intended only when several settings line up: the LiteLLM version, the license, precedence rules, failure behavior and the destination's own release line. Verify each item in your environment before you tell an auditor or privacy team that a team's traffic is separated or excluded.

Integration support and license scope

LiteLLM documents Langfuse, GCS bucket, LangSmith and Arize as destinations for team-based logging, but support can differ by release, and parts of the feature require an Enterprise license. Check the exact release you run, confirm that each destination you need is listed for per-team or per-key routing, and confirm that your license covers those parts for every gateway instance and region. Do not assume that a documented feature is available to you without that check.

Precedence between team and key settings

A team may have one logging destination while one of its keys has another, or logging may be disabled for a key inside a team that logs. The winning setting depends on your LiteLLM version. Test the combinations you plan to use, including a team-level destination with a key-level override, a key with logging disabled and a key created without a team. Record the observed result in your configuration standard so that a later change to a team or key does not silently move traffic to another destination.

Behavior during outages and failed destinations

Find out what the gateway does when a logging destination is unreachable, slow or rejecting writes. Some configurations drop events, some queue them, and a failed callback must not block model calls for users. Confirm whether dropped events are recorded anywhere, how large a queue can grow, and what happens to pending events during a gateway restart or a failover to another region. Ask the platform owner to demonstrate the result with the destination stopped during live traffic.

Whether prompts and responses are logged

Team-based logging may send only metadata, or it may also send full prompts and responses, depending on the destination and callback settings. Confirm for each destination whether message content is included, whether content logging can be turned off per team, and whether masking applies before data leaves the gateway. Repeat the check for the spend log table, which is a separate store. Prompts that contain personal data need this answer before any team is routed to a destination.

Langfuse version and upgrade path

If Langfuse is the destination, identify the Langfuse version you run and its upgrade path before you add team routing. Langfuse's v3 to v4 upgrade guide requires ClickHouse 25.12 or later, with 26.4 recommended, PostgreSQL 15 or later and Redis 7.0 or later. The same guide advises about 3x ClickHouse disk headroom when backfilling historic data, so include that headroom in your storage plan. Rehearse the upgrade in staging against your exact versions before production.

Enterprise support SLA coverage

Confirm whether the LiteLLM Enterprise support SLA terms apply to your deployment. LiteLLM's Enterprise documentation describes a dedicated engineering channel and optional 24/7 SLAs, with a 1 hour response for critical issues and 72 hours for security patches. Check which tier, if any, your contract includes, and whether it covers logging faults that originate in LiteLLM itself or in a destination such as Langfuse.

Questions teams ask before they set up per-team logging

What drives the effort of per-team logging on LiteLLM?

The effort depends mostly on how many teams and destinations are in scope. The main drivers are:

The number of teams and keys that need their own logging destination or a logging-off setting
The number of destinations, such as Langfuse projects, a GCS bucket, LangSmith or Arize
Whether Langfuse is self-hosted, since its web, worker, PostgreSQL, ClickHouse, Redis or Valkey and blob storage each need sizing, access control and backup
The Enterprise license scope, because some team-level parts of the feature require a license
The compliance review, which adds documentation, evidence and sign-off work

What do we need to provide before a partner starts per-team logging?

You need named owners, a key-to-team map and access, and these must be settled before the build starts. Each team should have one named owner who approves its destination and retention period. Your engineers provide a map that lists which virtual keys belong to which team, plus admin access to the gateway and to each destination. You also decide how long each destination keeps prompts and responses, and who can read each Langfuse project or bucket. If these decisions are open, the build stalls at the point where access and retention must be configured. Confirm each item in the written scope before work begins.

Can our own team set up per-team logging on LiteLLM?

Yes, for a small set of teams with a tested runbook. Your team can configure one or two teams, confirm that traffic lands in the correct destination, and document each step. It gets harder once destinations multiply, because each one adds its own credentials, retention settings, access rules and failure cases to test. A mistake in the team mapping can send one team's prompts to another team's project, which is a privacy issue. Check your runbook against the LiteLLM team and key logging documentation, and decide who on your team will own changes after go-live.

How long does per-team LiteLLM logging setup take?

It depends on scope, and the written scope sets the timeline. The schedule follows from the number of teams, the number of destinations, whether Langfuse is deployed in your environment, the compliance review and the testing you require. Ask for the schedule as part of the written scope, with milestones for access, configuration, verification and handover. Ask what verification includes, such as test traffic for each team, and what is excluded, such as infrastructure work on Langfuse itself. Avoid any timeline that is not tied to a listed scope item.

Does Langfuse Enterprise add anything to per-team logging?

Langfuse Enterprise adds support and governance features on top of the open source version, and its pricing is custom. Langfuse states that core features and APIs are available in the MIT-licensed open source version without limits. Its self-hosted Enterprise plan is custom priced and adds a named support engineer, solutions architect access and a support SLA, according to Langfuse's self-hosted pricing page. Separately, features such as project-level RBAC, data retention policies, audit logs and server-side data masking need an Enterprise license key. Request a quote from the Enterprise plan for the features you need, and confirm that a Langfuse license does not cover LiteLLM.

Which parts of per-team logging need a LiteLLM Enterprise license?

Parts of LiteLLM's team-based logging require an Enterprise license, so confirm the exact scope with the vendor. The LiteLLM documentation lists Langfuse, GCS bucket, LangSmith and Arize among the supported logging integrations for team-based logging. LiteLLM Enterprise also adds team-level guardrails and logging, organization and team RBAC, and audit logs, according to its Enterprise documentation. List the team-logging behaviors your chosen destinations need, and map each one to a license tier before you commit. A license quote should follow the written scope, and it is a separate cost from the implementation work.

Which Langfuse features need a license key when each team has a project?

Project-level access and retention features are the ones to check first. Self-hosted Langfuse runs the same codebase as Langfuse Cloud, and its core features are available in the open source version. Features that need an Enterprise license key include project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, organization creators, and the organization management API with SCIM. If each team needs its own access rules, retention period or masking, include the license in the plan from the start. Confirm which of these features your compliance review requires.

What breaks first when a LiteLLM gateway sends logs to many destinations?

Multiple destinations usually break at credentials, access and retention rather than at the gateway itself. A misrouted key, an expired destination credential or a missing callback can send logs to the wrong place or nowhere at all. Each Langfuse project also has its own access rules and retention setting, so one error can expose a team's prompts to another team. Test each team with a known request, confirm that the destination shows only that team's traffic, and monitor for dropped events. Check the behavior of each chosen destination against the LiteLLM team logging documentation before rollout.

How DeployOpen scopes and delivers team based logging

DeployOpen treats team and key based logging as part of the gateway design from the start. Each engagement begins with a written map of which teams and keys send traffic, where their logs go, and which teams need logging turned off. Engagements are fixed-scope, with deliverables agreed in writing before work starts.

How we scope

A written map of each team and key, its logging destination, and any team with logging disabled
Confirmation of which logging backends your licensing supports, such as Langfuse, GCS, LangSmith or Arize, before design starts
Fixed-scope engagement terms, with deliverables and timelines agreed in writing before work starts

How we build

Per-key or per-team logging configuration for the LiteLLM proxy, with settings reviewed for each team before go-live
Langfuse self-hosted in your infrastructure, with web, worker, PostgreSQL, ClickHouse, Redis or Valkey and blob storage sized
Test runs with a key from each team, confirming traffic reaches only its own destination or none

How we hand over

Written configuration record listing each team, key, destination and logging setting, kept in your change system
Runbook for adding a team, rotating a destination credential and confirming logging is off for restricted teams
Notes on which Langfuse features need an Enterprise license key, so your team knows what it is running

How we support

Optional retainer for ongoing support, upgrades and continuous testing of team-level logging changes
Planned Langfuse major upgrades, since v3 to v4 requires ClickHouse 25.12 or later and disk headroom for backfills
Review of team logging settings whenever the LiteLLM gateway moves to a newer minor version

LiteLLM team and key based logging