Hi @Helge_Gudmundsen,
Thank you for the logs and especially for the RSS sampling CSV, that combination let us pin this down precisely, and the diagnostics arrived in exactly the state we needed.
The growth is entirely in the .NET managed heap. At the point your logs end, RoonServer reports 17.1 GB physical, of which 16.5 GB is live managed objects, native memory, handles and steady-state thread count are all flat for four days. Your library (17,057 tracks) and Roon’s internal caches are completely static over the whole capture, so nothing on the library or search side is involved.
The driver is your Roon Server’s cloud push connection. Across the full ten days of logs there are 8,729 push connection sessions, and not one of them survived past 125 seconds. The median lifetime is exactly 120.0 seconds, and 71% are exactly 120.0 seconds to the second. Normally that connection stays up for hours or days.
Every time it drops, Roon treats it as a network change and re-initializes its entire cloud layer: a full re-login to your Roon account, TIDAL and KKBOX token refreshes, a discovery re-registration, a device-map re-registration, an ARC port check, and a re-publish of Roon’s services across every network interface on the machine. That is happening roughly 840 times a day.
Measuring the memory samples against those events, each cycle allocates a burst of ~23 MB and briefly spawns ~95 extra threads, then releases most but not all of it, a net ~7 MB retained per cycle. At 30 cycles an hour that is ~200 MB/hour, which matches your curve almost exactly, and the same figures reproduce across all three RoonServer runs in your logs.
Two things are going on:
The retention itself is on us. Even on a genuinely unstable connection, Roon should not hold onto memory across a reconnect, and we’re filing that internally with your logs attached.
But the reason it’s reconnecting every two minutes is local to your setup, and fixing that will stop the bleeding immediately. Your Roon Server is advertising 29 local IP addresses, roughly 28 Docker bridge networks plus a Tailscale interface. A hard, unvarying 120-second ceiling on an outbound connection almost always means something in the path is expiring the flow: routing or source-address selection across that many interfaces, or NAT idle timeout on the Vodafone router Roon detected via UPnP.
One test we’d like you to run:
Temporarily stop Docker and Tailscale, restart RoonServer, and let it sit for an hour:
sudo systemctl stop docker docker.socket
sudo tailscale down
sudo systemctl restart roonserver
Then check whether the push connection holds past two minutes:
grep -c "push2] connected" ~/.roon/RoonServer/Logs/RoonServer_log.txt
If that count stays low (a handful per hour instead of ~30) and your RSS curve flattens, we’ve confirmed it. Please keep your 16-minute sampling running through the test so we can compare the two curves directly.
Let us know how the test goes. 
