Root user inside Composer container

Using root inside the container is okay, because the container has a lot of dropped privileges. It can't access hardware or mount paths. It's essentially a non-privileged user.

Installing the application should definitely be done inside the container. The Dockerfile that builds the image has to install the application to begin with, and that occurs inside the container. If you're using a container to run a custom application (e.g. php7) that gets built with node and such, a build container that performs the installation is the correct way to isolate the application's update and install behavior from the host system.

Essentially nothing should run outside of a container when deploying an application with Docker. Any cron scripts should run a docker exec container script.sh or similar to run periodic jobs inside the container, for example.

Generally, if the application requires root privileges to do something like update modules based on a configuration, I use docker-compose to establish a build container which does all of that as root and then exits. I use a cap-drop section for the actual application container to remove as many capabilities as possible.

Many applications require setuid or setgid to drop privileges—e.g. nginx requires these so it can change from root to www-data:www-data. nginx will fail if it comes up as user www-data. The application should drop those capabilities after making the change itself.

A docker container should probably only be used to run an application. Anything that installs the application should be done outside the container.

You usually provide a configuration that points the container to production files stored somewhere. That would be the entry point for anything that got installed by Composer as well. The container itself should have no write permissions anywhere, with the exception of any cache directory.