PhpStorm can do more than just display code: start Docker Compose services, activate Xdebug in the container, run Magento CLI commands, and use the remote interpreter for autocompletion, once you know what really belongs together and what is better left in the terminal.
A bridge network ends at the boundary of a Docker host. As soon as a setup spans multiple physical or virtual machines, an overlay network takes over communication between containers, no matter which host they actually run on, encrypted and with built-in load balancing.
Magento 2 ships its own test infrastructure that differs substantially from a standard PHPUnit project. If you want to run integration tests directly from PHPStorm, see coverage reports in the IDE, and debug individual test methods with a single click, you need specific configuration, which this article covers in full.
Anyone who drops cronjobs and worker processes into an existing Docker container without a plan will sooner or later run into PID 1 zombies, lost signals and uncontrolled restarts. Dedicated containers, supervisor and clean signal handling replace fragile setups with predictable, production ready background processes.
Xdebug with Docker is not a one-click setup: host.docker.internal, port 9003, path mappings, the correct xdebug.mode, and PHPStorm server configuration all have to line up. This article systematically puts every piece into the right position, for stable breakpoints in Magento 2 and other PHP projects.
Multi-arch images solve the problem of a team developing on Apple Silicon laptops but deploying to amd64 servers, or the reverse case of using arm64 instances in production. Docker Buildx produces images for multiple architectures from a single build command and publishes them under one shared tag as a manifest list.
A slow, unstructured test suite is not a test suite, it is a drag on the team. This checklist surfaces every place where PHPUnit setups lose time, maintainability and developer trust, and gives a directly actionable step for each point.
Teams that only discover multi-store bugs in staging lose time and trust. A local multi-store development environment with its own domains, real store views and store-specific configuration values exposes bugs that a single-store instance would never surface.
A test matrix with Docker checks an application against several PHP or Node versions at the same time, instead of relying on a single local developer version. Containers make every combination reproducible, executable in parallel, and clearly separable in the results, without maintaining multiple physical test machines.
A plain docker login stores credentials by default in plaintext in ~/.docker/config.json, readable by any process with file access. Credential helpers solve this by delegating passwords to a secure keystore, both locally and in CI pipelines.