Using LibreChat in a corporate environment (Azure or self hosted)

[cbutler-captech]

Wanted to start a discussion around using LibreChat in a corporate environment and get some feedback around what others have done and what requests I am getting. Side note, after discussion, we are trying to avoid custom changes and would rather just find things we can add to the community. Forgive me if some of these are possible out of the box with just variables, here are some of the things that I am hearing:

Notes from sponsor:

• Ability to change the color scheme in a minor way, e.g. chaging primary/secondary color
• Ability to alter the wording on the new chat window (add corporate policies or links to them, what to do/not to do)
• Global Presets (perhaps a checkbox to make all admin presets show up) or a json file of global presets
• Global Prompt prefixes (ability to change all queries sent, perhaps add some notes on Tone and what to do if the info is not found)
• Limiting model choices to Roles in the AuthToken (I have this working locally into the API Layer), haven't surfaced the roles up to the Client)

My notes

• Azure Chat Completion Extensions (Ability to send a search endpoint, key and index and have the chat extension do the search serverside), negates the need to do a search beforehand. This returns citations. Would like to have a setting to enable by default in Azure without the user selecting a plugin, see Extensions at https://learn.microsoft.com/en-us/azure/ai-services/openai/reference

[danny-avila]

Thanks for starting this discussion, I think others might agree here and other points! This is a good reference for what can be worked on

Azure Chat Completion Extensions (Ability to send a search endpoint, key and index and have the chat extension do the search serverside), negates the need to do a search beforehand. This returns citations. Would like to have a setting to enable by default in Azure without the user selecting a plugin

Didn't know about this, that's a great feature on Azure!

[cbutler-captech]

Some other items I thought of...

Ability to disable some plugins (the goal in the corporate world is to keep data isolated, so shipping docs to plugins may not be allowed)

[itrase]

I agree that it would be very useful to disable some (most) plugins - it would also be nice to simply select a few plugins to be always-installed and have a setting to disable the plugin store entirely.

Another feature that would be useful is a .env flag to prevent server-side deletion of conversations. Right now, if a user deletes a conversation in the UI, all the messages within that conversation are actually deleted from the MongoDB database. Often in a corporate setting, the messages should be kept in some sort of trash bin or deleted files section, and just hidden from the user.

[cbutler-captech]

I think the “correct” way to do this is logging them via API Management. Here is a great video on how to do it in azure… https://youtu.be/j40RGK5SAeY?si=41s0UCD5xo-flfAu

[miraeder]

Agree on disabling plugins, would really be a welcome addition to be able to disable certain plugins.
Since this is not implemented yet, have you found a way in the backend to remove specific plugins, e.g. by commenting certain parts or deleting or moving files?

[danny-avila]

@miraeder remove them from here: https://github.com/danny-avila/LibreChat/blob/main/api/app/clients/tools/manifest.json

and here: https://github.com/danny-avila/LibreChat/blob/main/api/app/clients/tools/.well-known

[eburnette]

Interested in this too. I think it would need a set of feature flags that would be controlled by a config file so it wouldn't be necessary to fork the project to make customizations.

[danny-avila]

Relevant discussion, although less corporate focus and more general customization: #1291

[eburnette]

For corporate use, they're going to want branding. Logo somewhere (top left?), color scheme, maybe a background image, and control of the wording and href of all links.

[kaikreuzer]

Ability to change the color scheme in a minor way, e.g. chaging primary/secondary color

I'd be interested in this as well - just trying my first basic steps of customization and having issues with it. I'm ok with building my own image for now, but I am struggling figuring out, where I would change the primary/secondary color. Is there already any simple way to do so?

[ColinTitahi]

YES PLEASE - we are looking at this as great way to use OpenAI API / Azure OpenAi services across our organisation.
My Wish List:
Three levels of file and assistant visibility: Organisational, Team, Individual
A top level view of available assistants/prompts tagged by task type
User roles so prompt heros can modify assistants but others cannot
Choice of OpenAi or Local storage
Collaboration and taems is the next stage in all this

[prononext]

I think a lot of it is already implemented. Let's go forward from this:

• Color Scheme Customization:

  • Ability to change the primary and secondary colors to match corporate branding.
  • Option to add a background image, at least on the login page. 👍

• Branding and Customization:

  • Add corporate logos (e.g., top left corner, login, page, pwa-webmanifest)

• Partly Done Using icons for presets: LibreChat Model Specs

  • Control over the wording (index, pwa-webmanifest, general-ui).
  • href of all links.

Implemented:

• LibreChat Interface Privacy Policy

• LibreChat dotenv Help and FAQ Button

  • Ability to alter the wording on the new chat window to include corporate policies or links to them.
    Almost Done using: - Partly Implemented LibreChat Model Specs

• Global Presets and Prompt Prefixes:

  • Implement global presets that can be managed via a checkbox or a JSON file.
  • Ability to add global prompt prefixes to all queries, including notes on tone and instructions for handling missing information.

Implemented: LibreChat Model Specs

• Role-Based Model Choices:
  • Limit model choices based on roles defined in the AuthToken.
  • Ensure these roles are surfaced up to the client.

In the works: GitHub Issue #3137

• Azure Chat Completion Extensions:

  • Ability to send a search endpoint, key, and index to the chat extension for Azure integration.

• Plugin Management:

  • Option to disable specific plugins.

Implemented:

• LibreChat Filtered Tools

• LibreChat Included Tools

• Message Management:

  • Implement a trash bin or deleted files section in the MongoDB database to hide messages from users instead of permanently deleting them.

Will not be implemented as per @danny-avila, but you may create a MongoDB workflow to achieve something similar. GitHub Issue #3167 - maybe there could be a change if the API Keys are "not" user_provided.

• Logging via API Management:

  • Use API Management for logging, with a reference to a tutorial on how to do it in Azure.

• Cost and Quota Management:

  • Cost Management already planned. GitHub Issue #1215

I love LibreChat and hope there will be a great future for it. I tested lots of alternatives and never found one that is as good as LibreChat is. Thank you @danny-avila 🥇

[erickrf]

Are there any news on the features mentioned here? I am also very much interested in further customization of the UI.

[spenpal]

I'm also interested in custom branding as a feature.

[fabiancannaheim]

dito

[tatwong]

+1

[victorbjor]

Hi everyone,

I've been following the discussion about corporate Azure deployments and want to suggest an improvement to LibreChat’s integration with Azure OpenAI.

Proposal: App Principal Authentication with Entra ID

At the moment, LibreChat authenticates to Azure OpenAI using API keys. I’d like to add support for Entra ID (Azure AD) authentication using an app principal, which better fits many corporate environments.

Why This Matters:

• Reduced Key Management: No API keys to distribute, rotate, or risk exposing
• Integration with Corporate Identity: Uses existing Entra ID infrastructure
• Improved Compliance: Clearer audit trails and access controls
• Future-Proofing: Aligns with Azure’s recommended practices

Technical Approach:

• Add an environment variable (e.g., AZURE_OPENAI_USE_ENTRA_ID=true) to enable Entra ID mode
• Use the existing @azure/identity package
• Authenticate with DefaultAzureCredential, supporting managed identity and service principal flows
• Keep full backward compatibility with API key authentication

Scope of Change:

• Azure OpenAI client initialization
• Authentication logic in the OpenAI service layer
• Environment configuration options

Questions for the Community:

1. Would this feature be useful in your deployments?
2. Do you have preferred Entra ID authentication patterns?
3. Any concerns about the proposed approach?

I’m ready to implement this and open a PR once we agree on the direction.

Looking forward to your feedback!

[victorbjorkgren]

I was rather thinking of using the principal ID of the actual LibreChat service. So that would be even simpler, just using the
DefaultAzureCredential from @azure/identity. I would have to dig a bit to see exactly what is needed, but basically we would only need to track whether or not to use azure identity instead of api key and pass that along in the api call instead of the api key. I will actually need this feature regardless in my fork so I could test out an implementation and propose it?

[peeeteeer]

I would love to see the authentication to the Azure Open AI Backend working with EntraID credentials. I have been looking into this maybe 9 month ago... I barely remember but in the end it was something that there is also an OpenAI Client Lib from Azure which Librechat is not using so far. (I think) and this already comes with the entraid integration... So instead of using the same endpoint for OpenAI and Azure Open AI there would be two with the Azure specific lib...

[victorbjor]

In the current implementation it seems that we only need to change the api-key header to an Authentication header and attach the bearer token we get from Azure. Were you more interested in authentication by user to the LLM or by app principal?

[victorbjor]

I have prepared code for this now. The functionality is basically that, if the env var AZURE_OPENAI_USE_ENTRA_ID is true, we get the access token of the platform from entra id and attach it as an Authorization header. I will open an issue and PR for this feature and hope it gets attention as this feature will be a deal breaker for my team.

[peeeteeer]

I have prepared code for this now. The functionality is basically that, if the env var AZURE_OPENAI_USE_ENTRA_ID is true, we get the access token of the platform from entra id and attach it as an Authorization header. I will open an issue and PR for this feature and hope it gets attention as this feature will be a deal breaker for my team.

cool - thanks - will be very helpful for us as well