[GH-ISSUE #4908] [Feature Request] Central store for managing connections

gitea-mirror commented

2026-05-05 14:28:29 -06:00

Owner

Copy link

Originally created by @narendrakumar-nj on GitHub (Aug 4, 2025).
Original GitHub issue: https://github.com/fatedier/frp/issues/4908

Describe the feature request

In the current architecture, the client is limited to connecting with only one instance of the server. Visualizing this setup within a Kubernetes-based multi-tenant architecture, where client pods may run on multiple disconnected Kubernetes nodes, it becomes challenging to scale server deployments due to this limitation.

To ensure seamless connectivity, the current setup requires matching the number of server deployments to client deployments and exposing unique public IPs for each server instance. This guarantees that every client connects to a unique server instance, providing failover capability if one server instance goes down. However, this approach significantly complicates the scalability and flexibility of server deployments.

Introducing a mechanism to manage connections using a distributed source would allow a single server replica to connect with multiple clients. It would also enable independent scaling of server replicas irrespective of the client replica counts, thereby simplifying deployment management and improving scalability.

Describe alternatives you've considered

One alternative we are considering is to create two separate deployments for the server and two separate deployments for the client, with each client deployment connected to a unique public IP instead of using replicas within the same deployment. However, this approach introduces challenges: scaling the server under increased load would require provisioning a new public IP address and creating corresponding client deployments across all edge Kubernetes nodes to connect to the new IP

Affected area

Docs
Installation
Performance and Scalability
Security
User Experience
Test and Release
Developer Infrastructure
Client Plugin
Server Plugin
Extensions
Others

Originally created by @narendrakumar-nj on GitHub (Aug 4, 2025). Original GitHub issue: https://github.com/fatedier/frp/issues/4908 ### Describe the feature request In the current architecture, the client is limited to connecting with only one instance of the server. Visualizing this setup within a Kubernetes-based multi-tenant architecture, where client pods may run on multiple disconnected Kubernetes nodes, it becomes challenging to scale server deployments due to this limitation. To ensure seamless connectivity, the current setup requires matching the number of server deployments to client deployments and exposing unique public IPs for each server instance. This guarantees that every client connects to a unique server instance, providing failover capability if one server instance goes down. However, this approach significantly complicates the scalability and flexibility of server deployments. Introducing a mechanism to manage connections using a distributed source would allow a single server replica to connect with multiple clients. It would also enable independent scaling of server replicas irrespective of the client replica counts, thereby simplifying deployment management and improving scalability. ### Describe alternatives you've considered One alternative we are considering is to create two separate deployments for the server and two separate deployments for the client, with each client deployment connected to a unique public IP instead of using replicas within the same deployment. However, this approach introduces challenges: scaling the server under increased load would require provisioning a new public IP address and creating corresponding client deployments across all edge Kubernetes nodes to connect to the new IP ### Affected area - [ ] Docs - [ ] Installation - [x] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 14:28:29 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 14:28:32 -06:00

Author

Owner

Copy link

@fatedier commented on GitHub (Aug 4, 2025):

I’m not entirely sure about your actual requirements, but functionalities like high availability and large-scale cluster deployment are not currently part of the project's plan. Perhaps in the future, when we have sufficient spare time and there is a broader demand, we will consider them further.

@fatedier commented on GitHub (Aug 4, 2025): I’m not entirely sure about your actual requirements, but functionalities like high availability and large-scale cluster deployment are not currently part of the project's plan. Perhaps in the future, when we have sufficient spare time and there is a broader demand, we will consider them further.

gitea-mirror commented

2026-05-05 14:28:33 -06:00

Author

Owner

Copy link

@narendrakumar-nj commented on GitHub (Aug 4, 2025):

Could you please provide recommendations on achieving horizontal scalability for the FRP server? We are looking to scale it as a Kubernetes deployment. Your guidance would be greatly appreciated

@narendrakumar-nj commented on GitHub (Aug 4, 2025): Could you please provide recommendations on achieving horizontal scalability for the FRP server? We are looking to scale it as a Kubernetes deployment. Your guidance would be greatly appreciated

gitea-mirror commented

2026-05-05 14:28:33 -06:00

Author

Owner

Copy link

@fatedier commented on GitHub (Aug 4, 2025):

This is not a simple feature and is difficult to summarize. It typically requires additional architecture and component design.

@fatedier commented on GitHub (Aug 4, 2025): This is not a simple feature and is difficult to summarize. It typically requires additional architecture and component design.

gitea-mirror commented

2026-05-05 14:28:34 -06:00

Author

Owner

Copy link

@rajivml commented on GitHub (Aug 4, 2025):

what we are trying to solve is load balance the tenants across multiple FRP servers,
one way to achieve is, have a domain abc.company.com targeting machine M1 for tenant T1 , similarly have an other domain xyz.company.com targeting machine M2 for tenant T2 and so on

But what we want to understand is there a better way to do that instead of creating multiple domains for each tenant and pinning each tenant to a specific VM i.e somehow load balance the traffic across multiple FRP servers such that we can horizontally scale

@rajivml commented on GitHub (Aug 4, 2025): what we are trying to solve is load balance the tenants across multiple FRP servers, one way to achieve is, have a domain abc.company.com targeting machine M1 for tenant T1 , similarly have an other domain xyz.company.com targeting machine M2 for tenant T2 and so on But what we want to understand is there a better way to do that instead of creating multiple domains for each tenant and pinning each tenant to a specific VM i.e somehow load balance the traffic across multiple FRP servers such that we can horizontally scale

gitea-mirror commented

2026-05-05 14:28:34 -06:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Aug 19, 2025):

Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.

@github-actions[bot] commented on GitHub (Aug 19, 2025): Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.

No Branch/Tag specified