That doesn’t mean all of the dependencies and not to mention RoonServer itself can run under emulation.
Just to update on my fork, it is properly rebuilding on the first of the month with the latest Photon release and dependencies, FFMPEG etc so it’s pretty set and forget. I see no reason to touch it unless something breaks with the FFMPEG static builds from here: John Van Sickle - FFmpeg Static Builds
Thanks @David_Ferreira for the dockerfile! My repo is here: GitHub - mackid1993/docker-roonserver
Dockerhub is here: https://hub.docker.com/r/mackid1993/docker-roonserver/tags
It’s set to prune old tags and only keep the last 3 months, but latest will always be updated on the 1st of the month around 12 AM EST or 1 AM EDT.
1 Like
Thanks for sharing this. I’ve been running Roon in Docker for years. I switched to a Photon based container when @David_Ferreira suggested it in January. Photon uses about 2GB less memory than other Ubuntu-based images for my install. I have historic memory graphs that illustrate this.
@David_Ferreira and @mackid1993 have both provided great options for Docker. Thank you guys.
Also, @mackid1993 - I just want to say that it was very impressive watching you learn Docker so quckly and go from little or no experience to creating your own image, built on github, with regular updates. Really nicely done!!
2 Likes
Thanks so much. It’s amazing how fast one can learn something with a little bit of knowledge and vibe coding/prompt engineering until everything works. @David_Ferreira is more than welcome to use my github actions setup with his container as I’m sure he is more experienced with Docker if something needs to be tweaked down the line. Otherwise his repo will be the first place I look for changes if something needs to be tweaked. Unfortunately Github actions won’t execute on a timer in a forked repo from what I learned so I was forced to use his Dockerfile in my own repo and give credit to him everywhere I could.
1 Like
Just figured I’d mention if anyone is interested. I got my fork of the Photon container published on Unraid’s Community Applications. Now it’s super easy to install for any Unraid user. Also, since it’s very similar to Steef’s container, it will just replace the existing one if you select the template, and use the same paths for your music and backup.
1 Like
Thanks @mackid1993 , very much appreciate this as today I was noticing that my previous roon container was using about 1.8gb of ram and 2% cpu even when idle. With your new unraid appliance, its now around the 1% cpu mark and 512mb of ram both when idle and when streaming music, nice improvement! I guess theres no way to really have it at 0% when idle due to how roon server works.
2 Likes
Please don’t give me credit. @David_Ferreira is 100% responsible for making this container. I only automated monthly builds and got it published on Unraid Community Applications. I also intend to do my best to maintain it if something needs to be fixed down the line. The lower usage is totally due to him. I made sure to credit him on Github, Docker Hub and the Unraid forums. I even credited him in the CA listing.
2 Likes
Thanks @David_Ferreira !
1 Like
I’ve tested Roon containers built on a variety of Linux variants. Until @David_Ferreira mentioned Photon, I hadn’t tried it. I can pretty definitively say now that it’s Photon that the memory reduction can be attributed to. I’ve done side by side comparisons of various Ubuntu, Debian, and Photon flavors (including debian-slim which is what Steef’s container is based on) and Photon very clearly uses significantly less memory.
In my opinion, anyone getting started with Roon in a Docker container should be using one of the Photon-based containers that are now available thanks for the work these guys here did.
For what it’s worth, I run (and test) on rack-mount Synology. My measurements are done with a Glances, InfluxDB, Grafana stack and I have time-based measurements that now go back into last year.
I have switched my container to use FFmpeg from GitHub - BtbN/FFmpeg-Builds rather than from John Van Sickle - FFmpeg Static Builds as the latter hasn’t pushed an update since mid 2024. I’ve pushed an update to the container utilizing a much newer version of FFmpeg. Please share here if any issues arise. Everything seems good to me though. Now it is officially much more different than @David_Ferreira original container. Hopefully the current updates help maintain security especially since many use Roon ARC and will have a port forwarded.
I realize that this may be a dumb question but my knowledge of UnRaid is very limited so here goes:
I am currently running Roon in a Docker container ( steefdebruijn/docker-roonserver) on an UnRaid server.
So to switch to RoonServer mackid1993 (which is now showing up on UnRaid’s “Apps” page) all I would have to do is install the mackid1993 Docker image/container. Seems simple but then all these nagging questions keep popping up in my head:
What do I have to do to remove the no longer needed steefedbruijn Roon container?
Will I be able to keep my current, heavily editied Roon database? If I would need to use Roon backups to restore the Roon database, well then thanks but no thanks since I’ve already been burned several times dealing with Roon’s rather unreliable backups.
Will future Roon updates go as smoothly as the Roon updates did with the steefedbruijn Roon container?
I’m sure that are many other issues and steps that I’ve left out and I would greatly appreciate any help from you and other knowledgeable Roon Community members.
Thanks!
Just install the new container if you so choose, mappings are the same. Nothing with Roon changes, just the base os and dependencies.
Thank you for the prompt reply. I will work up some courage and give it a try.
No worries, it seems that you are rather cautious about things. If that is the case, running Roon on Docker probably isn’t the best move, as Roon Labs will not provide support if something goes wrong. It may be best to use a Windows PC, a Mac (such as a Mac Mini), or to build a ROCK server.
My container is going to be a bit more bleeding-edge in terms of OS and dependencies than Steef’s, which also hasn’t had a patch in 2 years, leaving security vulnerabilities in my opinion. There is a possibility that when it builds on the first of the month, something could break, and I’ll have to solve the issue. I think it’s unlikely but possible that an issue could arise. My container prioritizes the latest updates and patches for the actual container (i.e., OS and various libraries Roon depends on, Roon updates separately) over Steef’s, which is infrequently updated. I’ve personally had transcoding issues pop up within ARC with Steef’s container, likely due to FFmpeg being older.
It is a drop-in replacement for Steef’s container. If you want to switch, you can simply go into your template and change the Docker to mackid1993/docker-roonserver. Then, you won’t have to touch anything else. If you want my template with easy access to my support thread on the Unraid forums, delete the Docker (appdata won’t be deleted), set up my container, and point /music and /backups as needed. Nothing else will change regarding Roon.
Oh you noticed 
Here’s a little history that will help to explain my cautiousness.
I’ve been using Roon since 2018 (I think) and before that I was using Logitech Media Server (starting in 2006) so I’ve been streaming music for close to twenty years. Over that time I’ve managed to amass a massive music library (well over a million tracks, with about 80% local files and 20% Tidal/Qobuz). I’ve also used several different Windows PCs and to be frank, Roon running on Windows just can’t handle large music libraries - slow and lots of crashes. At the beginning of this year I switched everything to an UnRaid server and I love it. Roon is now rock solid and runs very smoothly except of the very necessary weekly restarts. I believe that restarts are required due Roon not being optimized for large libraries. But frequent restarts keep everything running smoothly.
Now when I switched over the UnRaid server Roon’s (worthless) backups failed and I am still editing my Roon database. A huge pain in the butt and Roon support, while responsive and concerned, did not solve the issues I had with restoring the backup. In other words, I had do to clean install of Roon and start over.
My server only runs Roon and Plex and has plenty of RAM and a powerful Intel® Core™ i9-9900X CPU @ 3.50GHz CPU. At present using the steefdebruijn container Roon is using about 29GB of the 64 GB of RAM available and usually has less than 10% CPU load.
I plan to give your Roon container a try. Here are the steps I plan to follow, please let me know if there is something else I need to do:
Stop the steefdebruijn Roon container
Install your Roon container and hope for the best.
I will report back once everything is up and running.
Again thanks for all your help.
That will work, you can even leave them both side by side if you wanted. They will use the same Roon install and database as Roon is installed outside of the container, passed through to the container through /app which will be in /mnt/user/appdata/roonserver/app and your database /data is in /mnt/user/appdata/roonserver/data. Both containers look in the same places and are interchangeable. The only thing changing is the environment Roon is being executed in. You will probably see much lower memory usage and I’d be curious if you still need to restart.
If you don’t trust Roon backups use CA Appdata Backup to backup instead.
Well I worked up the courage and the deed is now done! Everything went pretty smoothly, except for one little hiccup - Roon failed to “find” all local music files, which I was quickly able to resolve using Roon’s Setting → Storage and resetting the folder location.
So far I am not experiencing that much of a decrease in the memory load, which is now around 23.5GB (it was around 29GB) but the CPU load is now under 2% while streaming. I will see how Roon behaves after running for a few days and after I do some library maintenance (identifying, merging, and grouping albums, etc). And then there’s what I like to call “the weekly Thursday and Friday Roon slowdown”, which I believe occurs due to Roon’s master database (you know the big one up in the cloud, not my local Roon database) ingesting all the new Tidal and Qobuz releases. By the way, has anyone else noticed this weekly behavior?
So all in all, a big Thank You to everyone for your help and support!
That’s actually a pretty decent decrease in memory and pretty consistent with what we’ve all been seeing. You just have a ridiculously huge library. It also sounds like when you set up the new container, you might not have pointed /music to the exact same place.
I was about to edit my previous post when I saw your response.
I’m not sure whether or not I pointed /music to the right but was able to easily and quickly fix things, so no big deal.
I guess that the decrease in memory usage is very decent at around 20%.
I did want to add that i can never get Roon ARC to work when not on my home network (where of course ARC is not needed) so I will give Roon ARC a try once I’m away from home and using a 5G cellular network.
Almost forgot to mention that the improvement in the sound quality with the new container is just unbelievable! Veils lifted, windows opened, soundstage widened, etc. (Gotta keep the audiophile myths going!)