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

[GH-ISSUE #5488] [FEAT]: Allow Desktop to connect to existing self-hosted instance (remote mode) #5118

New Issue
Closed
opened 2026-06-05 14:52:06 -04:00 by yindo · 1 comment
yindo commented 2026-06-05 14:52:06 -04:00
Owner
Copy Link
Copy Source

Originally created by @p4tch98 on GitHub (Apr 22, 2026).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5488

What would you like to see?

Description

Currently, the Desktop application operates as a fully standalone instance of AnythingLLM, while self-hosted (Docker) deployments act as centralized server instances.

There is no documented or visible way to connect the Desktop app to an existing self-hosted instance.

Problem

This creates a fragmented workflow for advanced users:

  • Chat history and workspaces are not shared
  • Desktop-specific features cannot be used alongside a centralized backend
  • Users running self-hosted deployments must switch to the browser to access their actual data

Given that:

  • The backend already exposes APIs
  • CLI and Mobile support remote instances

…it appears the Desktop app is the only client that cannot connect to a remote backend.

Proposal (minimal scope)

Introduce an optional connection mode in Desktop:

  • Add a setting to define:
    • Server URL
    • API key / authentication token
  • When enabled:
    • Desktop uses the remote backend instead of local storage
    • Existing APIs are reused (no new backend required)

Important constraints

  • Default behavior remains unchanged (local-first)
  • Remote mode is opt-in only
  • No changes to permission system or auth model required

Expected benefits

  • Unified chat/workspace state across environments
  • Ability to use Desktop-only capabilities with centralized data
  • Improved usability for self-hosted users

Context

From the contributor guidelines:
Desktop is downstream of the core AnythingLLM project and wraps the core in Electron.

This suggests the feature could potentially be implemented at the interface layer without major backend changes.

Related but not identical to:

  • #2948 (workspace sync across devices)
  • #1748 (data syncing expectations across desktop installs)

This request is specifically about allowing the Desktop app to use an existing self-hosted instance as its backend, rather than local-only state.

Open questions

  • Is this intentionally unsupported by design?
  • Are there architectural constraints preventing Desktop from using remote APIs?
  • Would maintainers accept a scoped implementation of this behavior?

Happy to provide additional context, testing feedback, or help validate the workflow if this direction is aligned with the project vision.

Originally created by @p4tch98 on GitHub (Apr 22, 2026). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5488 ### What would you like to see? #### Description Currently, the Desktop application operates as a fully standalone instance of AnythingLLM, while self-hosted (Docker) deployments act as centralized server instances. There is no documented or visible way to connect the Desktop app to an existing self-hosted instance. #### Problem This creates a fragmented workflow for advanced users: - Chat history and workspaces are not shared - Desktop-specific features cannot be used alongside a centralized backend - Users running self-hosted deployments must switch to the browser to access their actual data Given that: - The backend already exposes APIs - CLI and Mobile support remote instances …it appears the Desktop app is the only client that cannot connect to a remote backend. #### Proposal (minimal scope) Introduce an optional connection mode in Desktop: - Add a setting to define: - Server URL - API key / authentication token - When enabled: - Desktop uses the remote backend instead of local storage - Existing APIs are reused (no new backend required) #### Important constraints - Default behavior remains unchanged (local-first) - Remote mode is opt-in only - No changes to permission system or auth model required #### Expected benefits - Unified chat/workspace state across environments - Ability to use Desktop-only capabilities with centralized data - Improved usability for self-hosted users #### Context From the contributor guidelines: Desktop is downstream of the core AnythingLLM project and wraps the core in Electron. This suggests the feature could potentially be implemented at the interface layer without major backend changes. Related but not identical to: - #2948 (workspace sync across devices) - #1748 (data syncing expectations across desktop installs) This request is specifically about allowing the Desktop app to use an existing self-hosted instance as its backend, rather than local-only state. #### Open questions - Is this intentionally unsupported by design? - Are there architectural constraints preventing Desktop from using remote APIs? - Would maintainers accept a scoped implementation of this behavior? Happy to provide additional context, testing feedback, or help validate the workflow if this direction is aligned with the project vision.
yindo added the enhancementfeature request labels 2026-06-05 14:52:06 -04:00
yindo closed this issue 2026-06-05 14:52:06 -04:00
yindo commented 2026-06-05 14:52:07 -04:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Apr 22, 2026):

Is this intentionally unsupported by design?

It is intentional insofar that it is something we are aware of - the issue mostly comes around permissioning since API keys are basically admin level.

Are there architectural constraints preventing Desktop from using remote APIs?

No, aside from the logical separation of how a local record and remote reference would work and also handling of connection drops, deauth, permissions, etc.

Would maintainers accept a scoped implementation of this behavior?

We would, but this is basically a core-team only issue since it would require a major lift on the desktop codebase outside of this repo.

<!-- gh-comment-id:4301561349 --> @timothycarambat commented on GitHub (Apr 22, 2026): > Is this intentionally unsupported by design? It is intentional insofar that it is something we are aware of - the issue mostly comes around permissioning since API keys are basically admin level. > Are there architectural constraints preventing Desktop from using remote APIs? No, aside from the logical separation of how a local record and remote reference would work and also handling of connection drops, deauth, permissions, etc. > Would maintainers accept a scoped implementation of this behavior? We would, but this is basically a core-team only issue since it would require a major lift on the desktop codebase outside of this repo.
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 feature request
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#5118
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?