dlakazov

Композер - это менеджер зависимостей, которые устанавливаются на сайт. На этом его работа закончена. На нагрузку компа он никак не влияет, так как не запущен.
Разово запустить может только разработчик для установки либо обновления зависимостей.

Вам правильно написали, что по-хорошему, с Композером надо работать на локальной машине.

Но, если будете гонять его на боевой машине, обязательно учтите, что Composer использует совершенно непотребное количество оперативной памяти (и автор отвечает на вопросы об этом, по сути, издёвками).
К примеру, для установки Drupal 8 или обновления одного установленного модуля вам едва-едва хватит гигабайта. Что-то более серьёзное может потребовать больше.

Так что я бы закладывал потребление RAM примерно 1-1.5 ГБ в моменты, когда Композер работает. Нагрузка на процессор тоже будет не нулевой, но она всё-таки много более сносная.

Посмотреть на установленный пакет и прочитать инструкцию по установке к нему.
Обычно в инструкциях написано нечто вроде

php artisan vendor:publish --tag="bouncer.migrations"

или

php artisan vendor:publish --provider="Spatie\MediaLibrary\MediaLibraryServiceProvider" --tag="migrations"

Что скопирует необходимые вам миграции в нужную папку. Работать с папкой vendor напрямую может привести к неожиданным проблемам.

Запустите ваш index.js под админом
runas /user:username "node index.js"

Где username имя пользователя-администратора

Та бывает такое и на апворке. Люди частенько обращаются с такими задачами к просто "разработчику".
Такие штуки обычно сеошные конторы делают. Потому что сейчас для позиций сайта важно его быстродействие.
Кстати, мне как раз вчера именно такую задачу подкинули.

Есть такое да, если делаете паблишинг портов, то на голом докере по умолчанию это произойдет через docker-proxy у которого катастрофически низкая производительность + огромный аппетит к Cpu, выход крайне простой - при создании контейнеров, которые будут взаимодействовать с внешним миром используйте --net host. Например у вас есть php-fpm, nginx и любая бд, в таком случае делаете --net host для nginx, остальные могут оставаться в сети docker, конечно же вам понадобится icc(inter container communication) и для этого нужно создать так называемую user-defined network. Для упрощения жизни создавайте контейнеры через docker-compose.

Комменты правильные. Правда надо понимать что контейнеризацая в докере происходит за счёт cgroups и разделяемого ядра. Те в некоторых ситуациях докер будет давать лучшие результаты по сравнению с полной виртуализацией сервера, а есть когда обратно. Базовое правило такое - если мы cpu-intensive то мы можем жить в докере. Если это io bound (много срем в сеть/диск) - могут появляться "артефакты" (причём, как показывает опыт) диагностировать их приходится отладкой ядра. Но это при нагрузках 10к+ запросов в подсистемы ваода-вывода. Если у вас "полтора колеки" сидят на сайте - тогда это скорее всего проблема инфраструктуры