Quick update on 2.65: the release itself is ready, but we’re going to hold it for another week.
2.65 raises the system requirements, which means some hardware won’t be able to run Roon natively anymore. For those users, Docker is the path forward - and while the image works, it’s new, and we want it to get more reliable before we ship 2.65.
Docker can run across a huge range of systems, OS versions, and configurations - far more permutations than we can exercise in-house. We’ve written up install steps for the environments we know about in our KB article, and we need the community’s help to validate them on real hardware before 2.65 ships.
If Docker is going to be your path moving forward, here’s how you can help:
Follow the steps in the KB article for your setup and let us know if they worked
If something didn’t work and you figured out a fix, share what you did - screenshots are especially helpful, and we can fold them back into the article
Include your hardware, OS, and any relevant version/firmware details
We’ll iterate quickly on the image and the KB based on what comes in, with the goal of making the Docker path land cleanly when 2.65 goes out.
One note on branches: if you don’t set ROON_INSTALL_BRANCH, it will install production (v2.64), not early access. That’s fine - what we’re testing here is the Docker image, not the release itself.
“TrueNAS SCALE” is an obsolete name. TrueNAS rebranded Scale → TrueNAS Community Edition. You are referring to SCALE in both the documentation and the Configuration Generator.
You can fix this by changing Scale → Community Edition but I wonder why you’re specifying Scale at all. TrueNAS used to have Linux and FreeBSD versions. Now they only have Linux versions. I think you’d be fine just saying “TrueNAS”.
In the documentation, you have a link to "Installing Custom Apps (via YAML). Your link points to a google search, which I don’t think is intended. It’s:
This, again, uses the obsolete TrueNAS product name. It’s also true for all of the NAS and Linux platforms, so personally I’d consider just dropping it.
The documentation is oversimplified. It misses the key steps of preparing the directories necessary for the installation. You need to do this so that the necessary Roon directory is available but also so that Synology has a place to store the compose file. When you paste a compose file into the Project creation wizard, it persists it on disk.
More complete documentation would explain that the user needs to create a Folder (or a Shared Folder) to point the wizard at. One best practice is to create a “Shared Folder” called “Docker” and then create subfolders for each actual docker project. So the user would create a Shared Folder called Docker, a folder inside of that called Roon and would then point the wizard at the Roon folder.
You also need to click past the Web portal settings without enabling it.
The elgeeko roon config dir is of no use for the official container - so started completely fresh there and restored from backup. After signing in to Roon AND Tidal again, I was back up and running. Process took about 10 minutes.
It’s worth noting I went with different paths to what’s recommended because I want any visible paths in my containers to represent actual paths on the host.
All good so far. I’ll let you know if I run into any issues.
If I’ve been running Roon on a Debian LXC happily for about a year, should I try Roon on docker on a Debian LXC? Aside from the usual parochial debates about whether one should run docker on an LXC (container on container) — which I do all the time… is there any reason to believe memory management or other aspects will be better on docker than on “bare metal container”? It’s very easy for me to spin up another container and experiment, but I’m not going to do it unless there’s some theoretical improvement at hand.
It’s a free world. If you want to run a container in a container (or a container in a container in a container in a container in a container), you should do so. Same with shoes. If you want to wear a shoe on a shoe (or a shoe on a shoe on a shoe on a shoe), you should do so.
The model is pretty simple. If you want the lowest memory consumption and best performance, and there are no complicating factors, the strategy is:
Docker Container > LXC > VM
Docker and LXC are pretty close for key operations. Both run on the host’s kernel and should be neck and neck for most operations including file system and network access.
Docker wins for simplicity and memory because it isn’t a “full OS”. The reason most people have to go from Docker → LXC is because a container isn’t available but a Linux binary is. So you spin up an LXC and run it in there.
If you want to run in an LXC, then just run in an LXC. That’s a fine way to do it.
If you want a container, then don’t put it into an LXC because that will undo any advantages (memory or perf) you would get from switching to a container.
I will say, though, that if you’re standing up an LXC for each of your containers, that’s like being a size 10 running shoe and then wearing a size 10 and then wearing a size 14 over your size 10. And then trying to run. I’m sure you’ll be able to run but you might be better off just in the size 10.
I’m not trying to debate. And I know you have tons of hardware and tons of resources, so that’s not the issue. I’m just trying to help answer the question of whether there’s an advantage to a container in an LXC vs. just an LXC and I think the answer is no.
Hi. Yes, I’m all into the multiple shoe path - when it makes it easier for me to maintain. I totally get stacked is silly, wasteful, etc. But for me (emphasis here), the “single service or service cluster per LXC” makes most sense. And after that, “the easiest way to get a well-maintained service” wins. If the author makes maximum effort on the docker container, but not so much on the binary, I go with docker. I guess I was asking - “do we expect Roon to be doing extra special good things with Docker / prefer folks to go on it vs. bare metal” in which case I’d get started even if it was less goodness from a resource perspective. But I don’t think we can know that yet.
I agree. The only thing we know right now is that the current container isn’t doing anything “special”. It’s just downloading and running Roon.
Edit: Just want to add that I don’t mean to undersell it. It’s a really robust, well-designed, and well implemented container. The configuration tool is also great. There was prior art in the form of community-built containers but this “official” version takes it to the next level. I’m very impressed with the work @Stephen did.
I’m not sure we know what the future landscape will look like with the docker image yet. I know I plan on leveraging it for some internal testing/automation/etc efforts. Granted, the one big win/”special” thing so far is the isolation from the host’s libraries/dependencies/etc.
If anyone has recommendations or general feedback please let me know.
I can attest the Docker instructions work great. I recently migrated my Server from the native QNAP application to Docker (Container Station) and can confirm the instructions worked like a charm.
My move was driven by my QNAP running glibc 2.21, which fell below the minimum requirement (2.27) introduced in 2.65. Since glibc can’t be upgraded and I wasn’t about to buy a new NAS, just for Roon, the native app was no longer a path forward. Nonetheless, the Docker deployment resolved that by providing me an easy runtime environment independent of the NAS OS.
Older DSM versions like 7.1 need better and clear setup instructions, I required chat GPT help to install the oficial version on DSM 7.1.1, to get to the early access is not as easy on older DSM, and adding the image to install do not work with the link provided, there is a need to ssh on to DSM, is not as clear and well explained on the instructions.
Now I finely on early access again on synology, but required some digging and help from chat gpt.
As it is a multi step process should be more clear the needed steps for older Synology NAS with dsm below 7.2.
It working great now as faster than I have ever experienced Roon on NAS.
I Am on 7.1.1 because most Synology 2015 models can’t get updated to 7.2. My unit is a DS3615xs.
As me many other users will face this.
I know is an 11 year old model, but is powerful enough and working as a champ, sounds great, and the price of upgrading it is prohibitive at the moment, even If I know is a little old NAS an equivalent one costs more than 3000 euros at the moment and unreachable at this time.
I also have a Mac mini for Roon, but the NAS is more practical always on and forget. Also accepts normal and better power cables.
After the initial quirks with installation of docker on DSM 7.1.1, it is running now very well and a lot faster than the native installation of Roon On Nas, the DS3615xs is a powerful NAS but was not as fast as the Mac mini m4, now with the docker image is a lot, and I mean a lot faster than before.
Thank you to the roon team and those who tested early here. I have been running roon server on nixos and had a very smooth migration to docker. I’m really impressed by the polish of this release, documentation, tooling to customize the docker config, and the fact that the backup had all the data needed to restore everything (qobuz auth, automatically picked up my local files when I mapped to a new path with correct import dates, network device names, etc).
Docker support is a great step for roon server. On nixos specifically, this makes it possible for me to use automatic upgrades because the native nixos package doesn’t support it.
