The problem containers solve

"It works on my machine" is a real problem with a real cost. Your laptop has PHP 8.2 and a particular set of extensions. The server has 8.1 and is missing one. The new developer has 8.3 and a different database version. Every difference is a bug that appears only somewhere else.

A container packages the application together with everything it needs to run: the runtime, the libraries, the configuration. That package runs identically on your laptop, on a colleague's, on staging and in production, because it is the same package.

A container is not a virtual machine. A virtual machine carries an entire operating system and boots in a minute. A container shares the host's kernel and starts in under a second, using a fraction of the memory. That is why you can run ten containers on a laptop and not ten virtual machines.

Two words to keep straight. An image is the package, built once and stored. A container is a running instance of an image. One image, many containers, the same way one class gives many objects.

Containers are disposable by design. Anything written inside a container disappears when it is removed. That sounds like a limitation and is the point: it forces you to keep data outside the container, in a volume or a database, which is where it should have been anyway.

For a developer the immediate benefit is onboarding. A new person runs one command and has the entire environment, instead of two days of installation.