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!