Both Roon Server and Roon on Windows 10

On the same Windows 10 NUC, can I run both:

  • separate Roonserver.exe as headless core - for server stability and speed reasons serving several clients
  • separate Roon.exe instance as local output and control only - for local playback to DAC connected to NUC and to nicely show on large TV screen what is playing

Roonserver.exe is managing single database, and Roon.exe is just client without own database connected to the Roonserver.exe.


Yes, you can – just make sure ‘full Roon’ is configured as Remote.

Local playback can be managed by Core (Roonserver), if the endpoint is attached to the Core machine.

Is there any advantage to this over just running Roon.exe for both purposes?

Roonserver is more lightweight and efficient, since it does not have to carry the overhead of full Roon.

The main advantage is that you can close Roon if not in use while Roonserver keeps on running in the background. I can’t tell you if Roonserver + an always open Roon Remote is more efficient than running just Roon – maybe @danny has some insights on this?

@RBM nailed it. Running them both had the advantage you can close the ui. However, if you minimize the app, an internal shutdown of the gui occurs until the app is restored.

I’m running exactly this combo under Windows 10 on my NUC and it is definitely snappier than running Roon as all-in-one on that machine.

That’s a bit strange… the all-in-one uses shared memory communication, where as the split one uses localhost TCP based remoting. The all-in-one should be way snappier.

I’m not referring to using Roon on the NUC to access my library, I’m talking only about using it from other computers on the network. I.e.:

Roon remote on laptop -> RoonServer on NUC

is faster than

Roon remote on laptop -> Roon on NUC

I only use Roon on the NUC (talking internally to RoonServer on the selfsame NUC) exceptionally.

That makes no sense either… as Roon on NUC is basically Roon Server on NUC w/ remote running with shared memory IPC, instead of networking.

Now I’m confused. What’s the point of RoonServer then? And why was I recommended to use it instead of Roon on the NUC as I had performance problems? And why did it solve them?

I can just speak on my experience.
Most importantly - Roonserver is stable and doesn’t crash or become unresponsive as Roon regularly does.
In terms of speed I don’t see very much difference, Roonserver being still somewhat faster.


RoonServer is for when you don’t want a UI attached to your Roon Core. Why? Because you don’t use it that way, you don’t have a head on that machine, you lack the memory on that machine or run on an architecture like Windows 32bit that has limited memory access, or you just want segregation of functionality.

Some setups, like the one @Janis has, has issues with UI+Core in one. That points to the fact that the UI or the memory consumption of the two combined is impacting the setup badly.

As to your performance problems being solved, there are two answers to this:

  1. the split was a red herring and we fixed stuff at the same time to make things faster
  2. the added memory load in one process is impacting your system negatively

Thank you for doing headless RoonServer.
It it perfect solution for the Audio Server set-up - reliable, resource light, and fast!