Docker for mac optimisations for php developpers

Because JETPULP is a web agency, developpers are used to work on multiple projets at the same time.

We have been using Docker for development purposes over the past two year now, and it’s an amazing tool. It allows developers to work on different projects with different technical stacks, and switch projects in a matter of seconds, as well as running two or more project at the same time.

It works very well on Linux, but we faced some big issues with Docker on Mac. As our company was staffing its employees with Apple laptops, we had to fix this. Here is the story of the different tips and tricks we used in order to work efficiently with Docker for Mac.


UX & Webdesign
Publié le 10/04/2018
Sylvain P.
Engineering manager
Sylvain P.
Partager l’article


At the beginning we were using dinghy with NFS file sharing . The performances weren’t very good and we weren’t achieving native linux perfs but it was quite acceptable.

Then Docker released Docker-For-Mac and we naively switched to the official Docker tool for the Mac OS. Unfortunately we faced a BIG issue with filesystem bind mount : As we mainly work with PHP projects, especially Symfony or Magento ones, with tens of thousands of PHP files, we were devastated because of the very poor performances …


Like many other PHP developers we found a workaround: Docker-sync. This tool synchronise your host workspace with a docker volume. It worked quite well, we reached native linux performances, but there were some drawbacks:

  • You need to remember to run docker-sync before running your app: We have a wrapping script in order to start docker-sync then the app
  • When you switch git branch, in most cases it would be wise to stop the app, use docker-sync clean and re-sync everything, otherwise you could face some problems…
  • Sometimes, docker-sync may freeze or stop. It can be very frustrating if you don’t figure it out quickly.
  • Because it’s a Mac workaround, it may be wise to have separate docker-compose-osx.yml and run docker compose with an -f flag keeping the original docker-compose.yml as clean as possible, especially if your team, like ours, works with both Mac and Linux.
  • Full re-sync can take more than 5 minutes on big PHP projects…

It wasn’t confortable for our developers, and even became more an more frustrating.

Finally Docker-for-mac released a new version with the :cached option on mounted volumes in order to adresse the issue #77. They also planned to release :delegated (see and . It was a really good update, but applications like Magento or Symfony are writing intensively in some directories (for cache or generated code…) and this wasn’t really efficient.

Thanks to we figured out the trick to mount docker volumes on the directories where the application is writing intensively. Docker volumes have native linux performances on writing which implies that our apps reached very good performances with this configuration.

We ended up with a docker-compose-osx.yml file written to override default config. Example for a Magento 2 :


Our developers are now happy again !


To be fair, not completely happy. Because they are annoyed by another famous “Docker for Mac” issue : The Docker VM image file ( ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.qcow2 ) grows continuously and can reach up to 60Gb of disk space !

When running out of disk space, because of the size of the Docker.qcow2 file, the only reliable solution is to delete this file and start with an empty VM image (stop Docker for Mac, delete the file, then restart Docker for Mac). The drawback is that you loose all your docker images (and your docker volumes), and have to download or create them again.

Docker for Mac released a new VM format : raw. Does it suffer from the same space problem ? We haven’t tested it entierly right now, and in its lastest version, Docker rolled back the raw format to qcow2 because of some instabilities…



According to this blog post :, there’s an other optimisation concerning “Full sync on flush issue”. You can read the post for explanations; in short it removes checks on database writes and speed up it greatly. It can be done on dev environnement ; to do so, run-in this gist We have experienced it without any problems.


In order to debug our applications with Xdebug inside our containers, we needed to include this bash file in the docker entrypoint of our php image (for more details, cf  Victor’s article) It will allow the IDE (here PHPStorm) to listen and remote debug the php app in the container.

All theses optimisations and configurations allow our developper team to use Docker For Mac efficiently.

This article has already been published on Medium.