Я всегда обновляю вручную.

Сайты на семерке тоже обновляю на сервере. Сайты на восьмерке обновляю локально, а потом GitLab CI деплоит

Был такой случай.
На сайте на семёрке был установлен модуль Display Suite. Причем, каждый раз глядя на него, я недоумевал - зачем он здесь, мы же используем панели, а формы не темизируем. Ну да ладно, работает - не трогай.
После очередного обновления безопасности DS, отвалились иконки цветов у атрибутов товара.

Дело в том, что цветов было гораздо больше 7, использовались комбинации этих цветов, и на странице каталога выводилось больше сотни таких иконок (30 карточек товара х 4-8 вариантов цвета в каждом).
Поэтому, генерить изображения для каждого цвета, поддерживать их в актуальном состоянии при редактировании атрибута, и тянуть на фронт 100+ иконок при каждой загрузке страницы каталога было совсем не вариант, цвета сделали инлайн-стилями: style="background-color: <?php print $color; ?>"
В общем-то, для такой задачи, я считаю, инлайн-стили - вполне приемлемое решение.

Обновление безопасности DS заключалось именно в том, чтобы вырезать недопустимые атрибуты тегов, в число которых попал и style. Тогда-то я и вспомнил, зачем нам DS на сайте. Фактически, все это время мы эксплуатировали незакрытую "дыру" (раз это было обновление безопасности) в коде модуля.

Отсюда мораль: никаких обновлений на проде. Сначала обновляем локально, смотрим дифф, чтобы понять в каких местах тестировать в первую очередь (вряд ли функционал ваших сайтов на 100% покрыт тестами), затем тестируем, и только после этого - выкатываем на прод.

Во-первых, надо ставить уже второй композер. Он жрёт ресурсов в разы меньше. Это прямо очень заметно.
Во-вторых, чтобы не держать всё локально, можно посмотреть в сторону CI или даже просто Github actions. Нужно создать два экшена с мануальным триггером. Один будет выполнять в своей виртуалке composer update и в случае отсутствия ошибок делать коммит. А второй будет деплоить коммит на сервер. Можно конечно и в один экшн это засунуть. А ещё в экшн можно прописать, чтобы он сходил на продакшн, слил оттуда базу и накатил в тестовой среде drush updb.

Ну сказать по правде, это всё теория)) Максимум, что я делал - писал экшены, которые автоматом деплоят коммиты на продакшн - типа сделал git push с локалки и всё готово.

Composer же прежде всего - для сохранения стейта и возможности делать деплой.

Для задачи вашего плана я бы рассмаотрел написать следующий скриптик:
- поднимаем контейнеры для теста
- скачиваем туда сайт с прода в докер
- запускаем composer update, drush updatedb/etc
- если без ошибок - загружаем назад и делаем composer install. (этот пункт имхо удобнее через что-то типа gitlabci коммитом, получаем запуск воркеров и наглядную инфу всё ли нормально прошло + удобный лог).

В целом автоматизируется и 99% кейсов может проходить без ручного внимания.