Why Containers Are Designed for One Process Only

Why Containers Are Designed for One Process Only

Yes, you can run multiple processes inside a container.

You can even install systemd, use a supervisor, and make it behave like a small virtual machine.

But that’s not how containers are meant to be used, imagine these technical scenarios:

📌 A container running a MySQL database and a logging service together experiences high memory usage.

📌 Your Flask application running alongside a cron job in one container leads to overlapping log files.

📌 A Dockerized application running multiple tightly coupled processes can’t handle a clean shutdown, leaving orphaned child processes.

Running into these kinds of scenarios is not uncommon but should be avoided, for sure.

In this era, from legacy tech to modern solutions, you can containerize any application with ease, but the core idea behind containers is process isolation and composability.

Why Keep Only One Process in a Container?

1. Isolation Makes Troubleshooting Easier

When a container has only one process, logs, resource usage, and failures point directly to that application.

Example: If a Node.js server fails, you can find the cause immediately without sorting through logs from unrelated processes.

2. Scaling Becomes Flexible

Each container can scale based on its own needs without affecting others.

Example: If you need more load balancers, you scale just the Nginx containers without unnecessarily scaling a database that is bundled inside.

3. Smaller Failure Impact

A failure in one container affects only that part of the system.

Example: If a background job worker fails, it will not affect your main web application, because they are running separately.

What Problems Arise When Multiple Processes Run in One Container?

📌 Docker and container engines monitor only the main process (PID 1). Other processes may continue running even if the main process crashes, leading to orphaned or zombie processes.

📌 Multiple processes inside one container can fight for CPU, memory, and disk I/O, causing instability.

📌 Logs from different processes mix together, making it harder to identify where an issue started.

Sometimes, combining processes cannot be avoided. In those cases:

Use a lightweight process manager like tini or supervisord to properly manage child processes.

Ensure signals like SIGTERM and SIGKILL are correctly handled to shut down all processes cleanly.