Where Docker belongs on Proxmox: the placement decision and the compose trap

Proxmox is installed and you want to run containers. The question is not "how do I install it", it is where do I put it. And that is not a matter of taste, it is a matter of how many things break when one thing breaks.

Three placements

Directly on the host. The easiest, and precisely the one not to do. The host is the layer everything above it rests on. Anything you install there is now inside the blast radius of every virtual machine: a dependency clash, a filled disk or a bad update takes out not just your containers but all of it at once.

Inside a system container. Light and quick to set up. In return you are running containers inside a container, and that arrangement has its own sharp edges: the permission model, the filesystem layers, the shared kernel. Chosen deliberately it is reasonable; chosen because "it was easier" it produces surprises.

Inside a virtual machine. The heaviest on paper and the cleanest in practice. When the container setup falls over, what falls over is one virtual machine, not your server. And when you want to rebuild it, you rebuild one machine.

The single question that decides

"If this breaks, what happens to everything else?" On the host the answer is "all of it", inside a virtual machine the answer is "one of them". Resource usage, ease of installation, all of that is secondary next to that answer.

The second half: compose is a program

A compose file looks like configuration. It is not. Running it is running code, and it runs with your privileges. Two lines inside it can hand the container the whole machine.

When people copy a compose file from the internet they do not feel the unease they feel copying a command. The difference is not in the danger, it is in the appearance: a command looks like a command, while compose looks like a settings file. Looking like one does not make it safe.

Four lines to look at before running it

Does it mount the host's filesystem inside. Does it ask for privileged mode. Does it hand the container management's own socket inside. Does it use the host's network directly.

These four are the lines that pierce the container boundary: if one of them is there, that container is no longer a container, it is the host itself. Reading them takes ten seconds, and those ten seconds are worth more than everything else in this entry.

What Atlas does

Atlas scans compose files and install scripts before installing, and that scan sits on the server rather than in the interface. So whatever the interface sends, the check cannot be skipped.

Findings come in two levels. Red means something that takes the container outside the container boundary, that is, privilege equivalent to the host; in that case explicit approval is required. Yellow means something that can be done deliberately but that you have to be told about. On the application catalogue side, red is not accepted at all.

There is one more detail and it matters: the scanner does not offer opinions, it reports facts. It does not say "this is dangerous", it says "this line does that". The reader decides, because the same line can be acceptable in one setup and unacceptable in another.