Issue description
The current implementation of the FRP module only supports one instance at a time. Depending on the use case, it is often desirable to have more than one FRP instance. This is useful e.g. if you are reverse tunneling encrypted traffic between multiple servers to combine the traffic into one frontend, or if you need to chain multiple FRP client/FRP server together on one device, etc.
I therefore suggest implementing a multi-instance module, such as in the WordPress module. For convienence, the implementation for that can be found here.
On a side note (perhaps off-topic) it would probably also be wise to provide an override mechanism that lets you pass in an arbitrary config path instead of configuring with the services.frp.settings. This is useful for a number of reasons, one of which is that FRP currently offers no ability to separate secrets from config, which means the user has to use something like a sops-nix template if they want to avoid leaking the token into the Nix store. For precedence on this API, see e.g. services.caddy.configFile.
Relevant to: @zaldnoay
Issue description
The current implementation of the FRP module only supports one instance at a time. Depending on the use case, it is often desirable to have more than one FRP instance. This is useful e.g. if you are reverse tunneling encrypted traffic between multiple servers to combine the traffic into one frontend, or if you need to chain multiple FRP client/FRP server together on one device, etc.
I therefore suggest implementing a multi-instance module, such as in the WordPress module. For convienence, the implementation for that can be found here.
On a side note (perhaps off-topic) it would probably also be wise to provide an override mechanism that lets you pass in an arbitrary config path instead of configuring with the
services.frp.settings. This is useful for a number of reasons, one of which is that FRP currently offers no ability to separate secrets from config, which means the user has to use something like a sops-nix template if they want to avoid leaking the token into the Nix store. For precedence on this API, see e.g. services.caddy.configFile.Relevant to: @zaldnoay