<p>Yes, sure. As long as your resources are enough (i.e., you're not running out of RAM, HDD, CPU, networking), and as long as you are fine with one gigantic single point of failure, there is no reason whatsoever to not run many docker containers on one machine.</p>

<p>Keep in mind that the overhead of docker is really small - it's all just namespacing on the host kernel, it's not like you're spawning copious amounts of VMs or anything like that.</p>

CC BY-SA 4.0
2018-11-29T19:17:17.130Z
2018-11-29T19:17:17.130Z
AnoE
<p>I hope you don't. </p>

<p>Let's assume that cost is paramount. There is no money for a second server. Then the question doesn't apply as you cannot use more than one server. So the cost of a second server must be okay.  </p>

<p>Then why wouldn't you take the opportunity to automate the setting up and administration of more than one machine? Then use the development environment with multiple machines as a test place to practice high availability, DR and how to run systems spanning multiple machines.</p>

<p>Are you intending to run more than one server in production with automatic failover when machines die but are not going to set that up in development? How do you know that automation will every work in production if you haven't practised in development? </p>

<p>With devops having development, or test, not behave like production always leads to problems. Nothing quite work first time in production so isn't automated, and production is never "fixed" as we don't feel the pain in development, so we just release less often to space out the pain, which isn't at all the spirit of devops.</p>

<p>Have the ambition to learn everything that you will do in production by practising making development like production, feel the pain of that, and change production until there is no pain doing the same things in development. You don't have to have the entire scale of production in development as that would be expensive, but at a minimum two servers that you can easily shift things between, or run a service across as highly available, is a huge leap over having a single server. </p>

CC BY-SA 4.0
2018-11-29T21:53:29.357Z
2018-11-29T21:53:29.357Z
simbo1905
<p>Best practice? No, it's better to have a bunch of smaller nodes so you can make your services better distributed for availability reasons. But will it be any <em>worse</em> than what you have currently? No.</p>

CC BY-SA 4.0
2018-12-18T07:39:37.477Z
2018-12-18T07:39:37.477Z
Xiong Chiamiov
<p>I have a server,32Gb ram, i7 processor and 2TB hard disk, with Docker engine running in it. I have like 100 development application to be migrated to this docker server. </p>

<p>So is it a good practice to run all your application in Docker in a single server?</p>

CC BY-SA 4.0
2018-11-29T11:21:19.970Z
This is opinionated. It depends! How *heavy* are the apps? But you write that the server will be used only for development purposes so I'd say its ok to run hundreds of apps or *serverless* like apps (one time jobs kind). There is not a good practise; better question would be *how can I maintain / orchestrate* hundreds of apps. One thing I see is that you will have accessing the apps (web apps I assume) but you can use https://github.com/jwilder/nginx-proxy for that.
Kyslik
CC BY-SA 4.0
2018-11-29T12:22:03.820Z
Hey mate, yeah I am using the Nginx proxy for now. Thanks for the reply. I have multiple projects of  Django, PHP, node, angular to be migrated to the server and yeah, it's only for development purposes.
Shibily
<docker><docker-compose>
Should I run several applications in Docker in a single server?
Shibily
# Should I run several applications in Docker in a single server?

(Asked by: username_0 on 2018-11-29)

I have a server,32Gb ram, i7 processor and 2TB hard disk, with Docker engine running in it. I have like 100 development application to be migrated to this docker server.

So is it a good practice to run all your application in Docker in a single server?

**Tags:** docker, docker-compose

> **Comments:**
> **username_1**: This is opinionated. It depends! How *heavy* are the apps? But you write that the server will be used only for development purposes so I'd say its ok to run hundreds of apps or *serverless* like apps (one time jobs kind). There is not a good practise; better question would be *how can I maintain / orchestrate* hundreds of apps. One thing I see is that you will have accessing the apps (web apps I assume) but you can use https://github.com/jwilder/nginx-proxy for that.  
> **username_0**: Hey mate, yeah I am using the Nginx proxy for now. Thanks for the reply. I have multiple projects of  Django, PHP, node, angular to be migrated to the server and yeah, it's only for development purposes.  

---

## 3 answers

### Answer by username_2 on 2018-11-29. Score: 0 | Accepted answer

Yes, sure. As long as your resources are enough (i.e., you're not running out of RAM, HDD, CPU, networking), and as long as you are fine with one gigantic single point of failure, there is no reason whatsoever to not run many docker containers on one machine.

Keep in mind that the overhead of docker is really small - it's all just namespacing on the host kernel, it's not like you're spawning copious amounts of VMs or anything like that.


---

### Answer by username_3 on 2018-11-29. Score: 0

I hope you don't.

Let's assume that cost is paramount. There is no money for a second server. Then the question doesn't apply as you cannot use more than one server. So the cost of a second server must be okay.

Then why wouldn't you take the opportunity to automate the setting up and administration of more than one machine? Then use the development environment with multiple machines as a test place to practice high availability, DR and how to run systems spanning multiple machines.

Are you intending to run more than one server in production with automatic failover when machines die but are not going to set that up in development? How do you know that automation will every work in production if you haven't practised in development?

With devops having development, or test, not behave like production always leads to problems. Nothing quite work first time in production so isn't automated, and production is never "fixed" as we don't feel the pain in development, so we just release less often to space out the pain, which isn't at all the spirit of devops.

Have the ambition to learn everything that you will do in production by practising making development like production, feel the pain of that, and change production until there is no pain doing the same things in development. You don't have to have the entire scale of production in development as that would be expensive, but at a minimum two servers that you can easily shift things between, or run a service across as highly available, is a huge leap over having a single server.


---

### Answer by username_4 on 2018-12-18. Score: 0

Best practice? No, it's better to have a bunch of smaller nodes so you can make your services better distributed for availability reasons. But will it be any *worse* than what you have currently? No.


---

