Note: this question is not strictly PHP-oriented, since both Docker and Composer can be easily used outside of the PHP ecosystem (although such cases would be rather rare IMO).

In one of the projects I work for, the production environment is set up in a way that uses an image with Composer only (i.e. https://docs.docker.com/samples/library/composer/) to get all the dependencies, and later copies them to actual PHP/FPM container (a so-called multistage build). I couldn't figure any real sense in doing it vs simply apk adding composer to the main container, running composer install on the main container, and then removing Composer from it during the build (note that this affects neither the image size nor layer count; the Composer binary could've been either added to the single RUN layer of all the other apps of the PHP/FPM source image or just apk added later during the build, and all the immediate files are removed eventually).

My current thoughts on separating Composer are:


  • if Composer breaks something, it doesn't propagate out of the container


  • the build process is slower due to the need to handle an additional image and container
  • the build process gets more complicated due to the need to handle additional container and file copying
  • the Composer is not run on the actual development machine, so all ext- checks ain't exectued and have to be forcibly disabled while installing dependencies, at the same time preventing you from verifying the completeness of the needed extensions
  • it makes little logical sense by itself - Dockers are intended to separate services to make it easier to handle them; Composer is IMVHO not a service, but a part of the build pipeline itself.

Am I missing something?

BTW, this question is not about scenarios like https://medium.com/@othillo/adding-composer-to-php-docker-images-using-multi-stage-builds-2a10967ae6c1 (i.e. just adding the Composer binary from an image) or https://laravel-news.com/multi-stage-docker-builds-for-laravel (where multistage build could be arguably useful to handle Webpack, Node, JS, CSS etc.); some people that actually propose the solution with separate Composer image (https://chrisguitarguy.com/2017/12/16/multi-stage-docker-php/) provide no real rationale on the possible benefit vs the alternative solution, i.e. removing the Composer after installing dependencies.

  • Good question, I’ve not managed to find an answer yet myself. Have you discovered anything since this post?
    – 0w3n86
    Apr 24, 2020 at 8:53

1 Answer 1


This is called a multi-stage build. It’s used to keep both the final image size and numbers of layers to a minimum. This results in less network traffic and a faster spin up time on machines where the image hasn’t been downloaded yet.

  • 1
    And allow you to don't install any sort of dev dependencies in images supposed to be deployed in production. The contrary is commonly seen as a vulnerability.
    – Laiv
    Nov 2, 2018 at 11:53
  • 2
    @Laiv you skip dev dependencies by --no-dev. I don't see how multi-stage helps with that any more.
    – user88637
    Nov 3, 2018 at 14:42
  • 1
    @vaxquis, that depends on the language. For many languages (C#, Go lang, C++), the dev environment can be hundreds of megabytes that are only needed for a short period of time. The deployed software doesn't need any of that to run. Without the compiler as part of the deployment, it also makes it harder to compile new malware if your container gets compromised (i.e. limit the blast radius). Dec 20, 2019 at 17:34
  • @BerinLoritsch this question is specifically about Docker + Composer and, AFAIK, this directly implies PHP development (which was also extensively mentioned in the question). Also, I explicitly asked about scenarios without any other languages involved. As such, I don't see how "that depends on the language". If I weren't aware of the usefulness of multi-stage builds in other environments, I wouldn't mention all the links relevant to it.
    – user88637
    Dec 20, 2019 at 17:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.