I'm currently working on building an application which I want to deploy to Docker containers.

The containers will run on a server of mine. I want to have the ability to run other applications on the same server without bloating up the amount of Docker images that are ran.

The different parts / containers as of now are:

  • Nginx (Reverse proxy, static resources)
  • Node (App frontend)
  • Node (App backend / API)
  • Mongo (Database)


The general idea I have is that each distinct part should be ran as a container. My concern is that if I were to run another application on the same machine I will end up bloating it with an unhandable amount of linked images.

This could be solved by making one image for each application. So that the aforementioned services will be part of one image. Does this conflict with the overall security or purpose of Docker in the first place?


Does having multiple services in one Docker image conflict with the purpose of Docker?

Will the overall security benefits of containers be removed when running the services from one image?

  • 2
    Docker themselves make this clear: You're expected to run a single process per container. Nov 28, 2015 at 14:33
  • I see. What steps could I take to make the amount of images more manageable / easy to overview? Or should I just prefix them all and just deal with it?
    – Alex
    Nov 28, 2015 at 14:35
  • Docker pretty well falls down here. They have their own tools like docker-compose, but I personally would look at Google's Kubernetes. Nov 28, 2015 at 14:38
  • @MichaelHampton, after looking in to it the solution seems to fit my needs. If you write an answer I will accept it.
    – Alex
    Nov 28, 2015 at 17:39

2 Answers 2


Docker themselves make this clear: You're expected to run a single process per container.

But, their tools for dealing with linked containers leave much to be desired. They do offer docker-compose (which used to be known as fig) but my developers report that it is finicky and occasionally loses track of linked containers. It also doesn't scale well and is really only suitable for very small projects.

Right now I think the best available solution is Kubernetes, a Google project. Kubernetes is also the basis of the latest version of Openshift Origin, a PaaS platform, as well as Google Container Engine, and probably other things by now. If you're using Kubernetes you'll be able to deploy to such platforms easily.

  • 1
    Yeah, Docker does make that recommendation, but I think the answer is: it depends. Also, one process per container doesn't even make perfect logical sense: rhelblog.redhat.com/2016/03/16/… Jun 10, 2016 at 15:29

Docker does make it clear that they believe one process per container is the "right" way, but never really give justification. My answer is, it depends. In this particular case, I would break them up and manage with Kubernetes or OpenShift because it's trivial and it will give you the ability to scale each piece of your application independently.

I wouldn't say it's a rule that you HAVE to split your application up though. Running containers are essentially the clone() system call, cgroups and selinux, which means you can absolutely run more than one process per container. Docker, LXC, homegrown it really doesn't matter when they are running. LXC encourages multiple processes per containers, so I would argue "one process per container" is philosophy not engineering


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .