Is your feature request related to a problem? Please describe.
Completely decoupling the server from the manager via an 'agent' daemon would make it easier to implement multi-server, as well as
running the control-plane on separate systems, by eliminating the concept of 'server' almost entirely; the only internal difference would be managed vs unmanaged peers.
Describe the solution you'd like
Split the interface management code off into a separate 'agent' binary, which can be deployed on several peers at once.
Describe alternatives you've considered
Only other 'real' option for multi-server is to make the daemon itself have an 'agent' mode on every server not hosting the webUI, or config deployment via SSH or similar.
Additional context
This is simply a possible implementation of a necessary part of multi-server support, and would also facilitate "managed" clients with truly automated config rollout possible.
Is your feature request related to a problem? Please describe. Completely decoupling the server from the manager via an 'agent' daemon would make it easier to implement multi-server, as well as running the control-plane on separate systems, by eliminating the concept of 'server' almost entirely; the only internal difference would be managed vs unmanaged peers.
Describe the solution you'd like Split the interface management code off into a separate 'agent' binary, which can be deployed on several peers at once.
Describe alternatives you've considered Only other 'real' option for multi-server is to make the daemon itself have an 'agent' mode on every server not hosting the webUI, or config deployment via SSH or similar.
Additional context This is simply a possible implementation of a necessary part of multi-server support, and would also facilitate "managed" clients with truly automated config rollout possible.