Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 14:13:35 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #1440] [FEAT]: Per-workspace LLM credentials #921

New Issue
Closed
opened 2026-02-22 18:22:12 -05:00 by yindo · 4 comments
yindo commented 2026-02-22 18:22:12 -05:00
Owner
Copy Link
Copy Source

Originally created by @atljoseph on GitHub (May 17, 2024).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/1440

How are you running AnythingLLM?

Docker (local)

What happened?

Ollama is main configured provider.
I have a workspace with Anthropic configured.
When I initialized the connection it let me put in an api key.
Can’t edit it any more…
The workaround is to go edit the main app settings to point at the specific provider where the api key needs to be updated.
Then, update the api key and save.
Then, change the provider back to Ollama, or something else and save.
Finally, go back to the workspace and test.
That’s a lot of steps.
Seems like each provider should have sandboxed credential storage.
if I was able to add the api key in a workspace, I should be able to edit it there.

IMG_1789
IMG_1788

Are there known steps to reproduce?

See description

Originally created by @atljoseph on GitHub (May 17, 2024). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/1440 ### How are you running AnythingLLM? Docker (local) ### What happened? Ollama is main configured provider. I have a workspace with Anthropic configured. When I initialized the connection it let me put in an api key. Can’t edit it any more… The workaround is to go edit the main app settings to point at the specific provider where the api key needs to be updated. Then, update the api key and save. Then, change the provider back to Ollama, or something else and save. Finally, go back to the workspace and test. That’s a lot of steps. Seems like each provider should have sandboxed credential storage. if I was able to add the api key in a workspace, I should be able to edit it there. ![IMG_1789](https://github.com/Mintplex-Labs/anything-llm/assets/25017621/3d4fc7c9-1fbe-4096-a541-ad2e66736b27) ![IMG_1788](https://github.com/Mintplex-Labs/anything-llm/assets/25017621/7b72aafc-ef0b-4542-ad02-658d754e54b4) ### Are there known steps to reproduce? See description
yindo added the enhancement label 2026-02-22 18:22:12 -05:00
yindo commented 2026-02-22 18:22:13 -05:00
Author
Owner
Copy Link
Copy Source

@atljoseph commented on GitHub (May 19, 2024):

Yeah I now realize this can be hard to work into the usership model. The best approach to this would be to define a provider settings screen that could apply to both workspace and globally. An admin user would initialize the env and open up this screen to input the top level api keys for each LLM provider they use. It could be both OpenAI and anthropic, for example. The admin could even gate which providers show up in workspace dropdowns by checking boxes next to each provider. Then, anytime a workspace uses one of those providers, the corresponding key is used. At the workspace level, a non-admin user would just override/augment the admin settings by plugging a different API Key into this screen, if they wish. In cases where the admin api key might have issues, it might be valuable (or on the other hand potentially destructive) for a non-admin to go in and update the workspace key. Use case: customer facing chat bot out of tokens and admin not in town

@atljoseph commented on GitHub (May 19, 2024): Yeah I now realize this can be hard to work into the usership model. The best approach to this would be to define a provider settings screen that could apply to both workspace and globally. An admin user would initialize the env and open up this screen to input the top level api keys for each LLM provider they use. It could be both OpenAI and anthropic, for example. The admin could even gate which providers show up in workspace dropdowns by checking boxes next to each provider. Then, anytime a workspace uses one of those providers, the corresponding key is used. At the workspace level, a non-admin user would just override/augment the admin settings by plugging a different API Key into this screen, if they wish. In cases where the admin api key might have issues, it might be valuable (or on the other hand potentially destructive) for a non-admin to go in and update the workspace key. Use case: customer facing chat bot out of tokens and admin not in town
yindo commented 2026-02-22 18:22:13 -05:00
Author
Owner
Copy Link
Copy Source

@nr-plaxon commented on GitHub (Sep 27, 2025):

Having credentials per workspace would be a big improvement. We would love to use different Mistral accounts per workspace for example which is not possible right now.

@nr-plaxon commented on GitHub (Sep 27, 2025): Having credentials per workspace would be a big improvement. We would love to use different Mistral accounts per workspace for example which is not possible right now.
yindo changed title from [FEAT]: Per-workspace LLM credentials to [GH-ISSUE #1440] [FEAT]: Per-workspace LLM credentials 2026-06-05 14:37:57 -04:00
yindo closed this issue 2026-06-05 14:37:57 -04:00
yindo commented 2026-06-05 14:37:57 -04:00
Author
Owner
Copy Link
Copy Source

@breesait commented on GitHub (Jun 1, 2026):

Hello everyone, I've worked a PR to support this, I hope this is what you want(because I also want this feature )

<!-- gh-comment-id:4591488148 --> @breesait commented on GitHub (Jun 1, 2026): Hello everyone, I've worked a PR to support this, I hope this is what you want(because I also want this feature )
yindo commented 2026-06-05 14:37:58 -04:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Jun 1, 2026):

Moving to #4493 as this would fall under that as all providers would support this functionality and this would be solved by closing of that issue

<!-- gh-comment-id:4593622991 --> @timothycarambat commented on GitHub (Jun 1, 2026): Moving to #4493 as this would fall under that as all providers would support this functionality and this would be solved by closing of that issue
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#921
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?