Building a Docker Media Server – Introduction

Over the last few years, we’ve featured a range of guides designed to help you build a kick-ass media server or home server (call it what you will). Whether you’re a Windows fan, a Mac guy, you prefer a Linux NAS system such as FreeNAS or commercial options from the likes of Synology or QNAP, there are ways and means to build the media server of your dreams!

But, it can be a long haul. Not only do you have to research and source appropriate hardware – balancing form factor, power consumption and raw performance – but there’s the matter of operating system selection and, importantly, application support. Go for a relatively “open” platform like Windows or Linux (Ubuntu, Debian and the like) and life is a little easier – you’ll find support for most of the major media server apps.

But what if you’re trying to consolidate everything on to a more “closed” platform, such as a NAS? Anyone that has used a popular NAS operating system will know that package support is limited. Many popular media server apps have been packaged by the community (or the original developers) so they can be run on NAS systems. But, in my experience, the execution can be hit and miss. Sometimes, packaged apps simply don’t work, or require a lot of work (and more than a little technical voodoo) get running. When they do run, they may not always work as intended. You’re also relying on those developers repackaging apps with each update, which doesn’t always happen. When the latest hot new media app hits the scene, sadly, you’re probably at the back of the queue for compatibility, too.

I’ve been there, trust me. You can spin up a decent media server on a NAS, but it takes a lot of work and it can be pretty fragile.

Virtualization to the Rescue?

Wind the clock back a couple of years and I was in exactly this situation. I was running multiple devices – Windows PCs and NAS systems – which together formed my media server “platform”. But it was a bit of a mess. Sure, I’d consolidated my media libraries on to a single storage device, but to support those libraries, I had different apps running on different systems, all talking to each other over my home network.

You know what? It worked, but it was pretty gloopy. I loved the simplicity and huge capacity of the NAS systems available at that time, but support for the apps I needed simply wasn’t there. So, I had to augment my media server with a dedicated Windows PC in support. Not ideal – certainly in terms of power consumption and overall complexity, but functional all the same.

As NAS systems became more powerful, options opened up for consolidation. QNAP led the way, offering virtualization support on many of their devices – the ability to run guest operating systems (virtual machines) in a hypervisor. So you’d have a Linux under the hood with the ability to run the Windows operating system (or an alternative Linux OS if desired) on top. On that guest OS, you could then run any applications that weren’t packaged natively for the NAS.


That one-box media server – a blend of low-power, high-capacity and ultimate flexibility became real at last. For a time, this became my media server setup. I ran a QNAP NAS with a Plex Media Server package alongside a Windows 8 (at the time) VM running those same supporting applications. I switched off that dedicated Windows PC I has running 24/7 and that was a good job done.

Or so I thought.

In fact, I grew frustrated with this configuration pretty quickly. The problem? Performance. As those of you that have dabbled with VMs will be aware, running guest operating systems can use up a lot of resources on the host. Add an increasing number of media apps to that guest OS and, before you know it, the host is going to struggle unless it’s equipped with some serious power.

One of the major benefits of running a Linux-based device is its low power requirement. Linux benefits from a small footprint, hence the plethora of cheap, low-power (performance as well as wattage) NAS devices available out there. For simple file serving duties, a humble engine is fine. But virtualization needs a lot more power. Combine that with heavier native workloads – like real-time media transcoding – and you can understand why QNAP introduced supporting powerhouse NAS systems with Intel Core i7 processors and 8 or 16 GB RAM!

Those systems, like the QNAP TVS-871 (which I still use today) or the newer TVS-x82 Series are really closer to small business servers than consumer NAS devices. Under load – which even these mighty systems are when combining media server and hypervisor duties – the question is whether you’re really reducing power consumption compared to a two-box solution?

A New Approach

It was time to consider a new approach. One that could deliver more of the features I really needed from a media server.

  1. Simplicity – a single-box system that’s easy to build, configure and manage without the need for a PhD.
  2. Compatibility – support for all of the major media server apps and services. Platform agnostic, ideally.
  3. Flexibility – as a serial twiddler, it should be easy to spin up and test new or emerging applications and services (and get rid of them quickly if they don’t work out).
  4. Reliability – at the core, the media server needs to be built on a strong, stable foundation that performs well and won’t fall over.
  5. Frugality – a compact system (both in physical footprint as well as resource consumption) that could draw on reserves when needed, but otherwise remained nimble with low running costs.

Reading around, it quickly became clear that containers could be the answer.

Introducing Docker and Docker Containers

In short, I was looking for a way to deliver the same flexibility that my existing QNAP solution delivered – so some degree of virtualization would be required – but with a much lower performance overhead. This is the major benefit of containers (also referred to as containerization or container-based virtualization).

Whereas “traditional” virtualization works at the operating system level (for example, running a full-blown instance of Windows 10 on that QNAP NAS I referred to earlier), containers work at the application level. They allow an application to run virtually without the need to launch a supporting guest operating system (and all of the bloat that goes with it).

Containers are isolated from the host operating system, (they actually run on a single, lightweight Linux engine) and include the files, environment variables and libraries required to run the application. However, they share other resources required from the host operating system – binaries, libraries as well as physical resources. That means a containerized app runs much more efficiently than if it was installed in a virtual machine, running on a host operating system.

Virtual Machines vs Containers

If the concepts of virtual machines and containers sound similar, well, they are. Both ultimately allow applications to run on platforms they weren’t developed for. But the efficiency of containers is the reason why they’ve become a big deal in computing. And a company called Docker is leading the charge.


The concept of software containers isn’t new. Indeed, you can go back over fifteen years and find them implemented in the FreeBSD operating system (where they’re known as “Jails”, a name familiar to FreeNAS users). While a host of tech luminaries, including Google, Red Hat, Parallels and Oracle, have worked on container technology over the last decade, it’s Docker’s open-source implementation that’s seeing mass adoption in Enterprise and beyond.

The company, based in San Francisco, works with a variety of organizations on the development of Docker. Supporting an in-house team are developers from Cisco, Google, Huawei, IBM, Microsoft, and Red Hat. As an open-source project (more specifically, its libcontainer component), Docker has driven standardization in container technology, which in turn, supports wider adoption.

It’s now reasonably easy for application developers to package their wares in a Docker container, allowing it to run on an ever-increasing number of host operating systems, or in the cloud. The Docker Engine can be installed on:






With such a wide array of host platforms and the inherent efficiency of software containers, building a media server using Docker Containers sounds like it could be the answer to my needs. Whether you decide to run your media server on a NAS, Windows, Mac or Linux PC we should be able to build to a low cost, low footprint, high performing system.

Welcome to Building a Docker Media Server

In this series of how to guides, we’ll walk through the steps required to build a Docker Media Server. We’ll talk in more detail about hardware specifications and operating system/device selection before delving into the media server applications and containers themselves. They’ll include popular choices such as:

  • Plex Media Server
  • Sonarr
  • Couch Potato
  • SABnzbd
  • Deluge
  • NZBGet
  • Muximux
  • Musicbrainz

…and a whole lot more. Not every application or feature will be suited to every user, but I’ll aim to cover a wide range of typical media server features that commonly found on many setups. For each application, we’ll discuss their features, container installation (on a number of popular platforms) configuration and day to day management.

Whether you’re building your first media server, experimenting with Docker or you’re an old hand with both, I hope you’ll join me on the journey and have some fun on the way!



      1. Either problem would be solved by routing WAN traffic through a VPN?
        The problem (that I’m struggling with) is that if you put the VPN client in a container, then you have to deal with network routing – How do you expose the web interface to those clients on your LAN while still routing WAN traffic through the VPN. My understanding so far is that you need to set up a reverse proxy container (or would it be a container for each service?) and bind the ‘local’ ports to the proxy container(s) and the ‘internet’ ports to the VPN container.

  1. When I run the VPN on the docker host itself, it confuses docker’s network routing table and I can’t figure out how do direct container-container network mapping.

  2. It would be interesting to know if iTunes can be implemented in a Docker Container. (iTunes Server does run on QNAP.) My functional goals are media library on a QNAP NAS, primarily using ALAC codec, robust metadata, graphical multiuser access from several PC’s or other streaming devices, and ability to sync with iDevices from those PC’s. I know that iTunes probably isn’t the most elegant solution, but it’s dead simple and likely to be around in 10 years. If there is a better Docker-based way to skin this particular cat, I would appreciate knowing about it.

    1. @chuck davis I have QNAP TS-451 and in Control Panel under Applicationsserver I have the option to start iTunes Server. Maybe you looked in the wrong place?

      1. iTunes Server is fine for playing music. For library maintenance (ripping, iTunes Store, downloads, etc.) iTunes is only single user, however. If two people open the .itl file there is a significant risk that the library will become corrupted. I switched to MediaMonkey because it uses a SQL database for its library, which is inherently multiuser. It’s a lightweight SQL database, but fine for my wife and me.

        As of now I’ll have to use an outboard PC to play/serve the music, but I’m hoping that will change by the time I finish ripping my library. I’m already using an outboard PC to backup the NAS with CrashPlan (

        In general there seem to be a lot of issues trying to run non-native applications in QNAP’s QPKG environment. (Especially those that aren’t supported directly by QNAP.) I’m hoping that Docker will attract enough interest to reduce or eliminate these issues. Hopefully this series of articles in We Got Served will help build that level of interest.

        1. Okey Chuck, I’m not using iTunes but as you pointed out if two people playing from iTunes server it might corrupt the files. Hope you can find a solution with Docker. It will be insteresting to follow how to use Docker on my QNAP or server I have but not using. Looking forward to hear from you in the future and how it goes with iTunes via Docker.

          1. iTunes Server can stream music to multiple clients simultaneously without any risk to the library database. It is iTunes itself, being used for library input and maintenance, that isn’t multiuser.

        2. @Chuck Davis – Have you looked into Plex? The server side runs fine in a docker container (many NAS’ actually have native Plex Media Server packages) and seems to hit all the bullet points you list:
          – ‘Standard’ metadata (plays, ratings, categories, album art, etc)
          – Plex clients available on many devices and support syncing for offline playback.
          – Plays a variety of audio formats
          – Can even share iTunes library, so you can use iTunes for maintenance and Play for playback.
          – Can share library with multiple users

          The only thing it doesn’t do is ripping/purchasing. If you’re using it to share your iTunes library, you can still do that with iTunes (though still with the single-user-at-a-time caveat).

          1. Hi Chris – I’ll probably use Plex (or Kodi+Plex) for video, and maybe photos. I’m still in test mode with MediaMonkey, but so far I’m very pleased. It does lossless rips (FLAC) and picks up metadata (including lyrics, when available) and stores the metadata in an industry standard format. It is a DLNA server, and can sync to both Android and iDevices. I’ve left iTunes installed on our (occasionally mobile) laptops, and use a QNAP utility to sync the iTunes libraries between the laptops and the NAS. MediaMonkey then automatically picks up any changes to the iTunes libraries and updates its own library. I can purchase/download music from any source, and MediaMonkey is integrated with several sources including HDTracks. MediaMonkey uses a SQL database (which I moved to the NAS, following their documentation) for its library, so multiuser is dirt simple. I have an inquiry into MediaMonkey asking if there are any plans to implement MediaMonkey in Docker. If not, I have enough old systems laying around that I can fire up a box to act as the 7×24 server while still doing rips, syncs and library maintenance from my laptop. The MediaMonkey license covers 3 systems (me, wife, server).

  3. I’m sure are interested in a Docker media server. I own QNAP Nas TS-451 right now using it with Kodi. Will it be any difference between Docker or the solution I have now?

  4. As a follow-up to my comment above, I gave up on iTunes (since there is no way to kluge a multiuser configuration) and switched to MediaMonkey. Since MediaMonkey doesn’t appear to be available in a Docker configuration, you might add them to the “Hey guys, why doesn’t somebody…….” list.

    1. I’ll probably use Plex (or Kodi+Plex) for my (small) video library. (After I recuperate from “ripper’s elbow”.) Still in test mode with MediaMonkey, however. As noted in another post, I like that MediaMonkey uses a multiuser SQL database.

  5. PLEASE tell that the line:

    Simplicity – a single-box system that’s easy to build, configure and manage with the need for a PhD.

    is a typo as I suspect that I’ll NEVER get my PhD…

Leave a Reply