Если речь о взятом на Upwork проекте, да.
Если после удачного сотрудничества, никто не мешает продолжить и вне площадки...

Потому, что для организации работы над небольшими проектами есть много других площадок, например upwork, который для этого подходит куда лучше, в частности из-за наличия инструментов для проведения сделок.

Нет, вы ошибаетесь, это не будет работать при таком сообщении. В обоих случаях, и при memory_limit и при таймауте выполнения, была бы внятная ошибка со стороны php, точно указывающая на причину проблемы.

Ошибка "Killed", как тут, это либо вручную снят процесс, либо OOM killer при критичной нехватке памяти( ну а точнее SIGKILL или SIGTERM отправленные процессу извне, если быть точным). И именно в данном случае, это наверняка OOM Killer.

Там было бы не killed, а ошибка php в стиле "memory limit exceed".
Тут не хватает именно выделения на стороне ОС, и срабатывает OOM killer.

Правильно - надо делать update на dev, а на prod делать install, как правильно выше написано.
Второй вариант - свап или доп. память.

Второй композер конечно менее прожорлив, но не так уж и лёгок в update. Первый конечно мог и пару гигов целиком сожрать. Но и второй несколько сот мегов может.

Чтобы отображались только сегодняшние, например ноды, это имелось в виду?

Вообще-то я и написал выше всё что нужно сделать, по крайне мере то, что можно было написать при ваших вводных данных.

И изучать docker всяко полезнее чем разные docksal/ddev и.т.п., об этом именно было написано. Потому, что именно это тот инструмент которым вы пользуетесь. А изучать обёртки над ним это путь в никуда - время тоже будет потрачено, но при любой проблеме придётся тупо гуглить в надежде, что на грабли кто-то уже наступил, вместо понимания того, где проблема.

Ну и для поднятия продакшен окружения, ни d4d, ни docksal не годятся совсем, так на всякий случай.

И не заработает, т.к. на сервере уже есть кому слушать 80/443. Или придётся как для d4d писать конфиг nginx.
Лучше изучить docker и свои делать наборы контейнеров, понимая, что делаешь, чем лезть в эти чёрные ящики, к тому же применяя их не по прямому назначению...

В веб сервере, который запущен на удалённом сервере. Надо написать конфиг для этого сайта.

Этот набор заточен для локальной разработки, так что "как есть" использовать его не получится в таком сценарии.

Тут есть две вещи, которые нужно сделать по меньшей мере:
Чтобы резольвился правильно testdocker.local в браузере, надо добавить в hosts на локальной машине:
testdocker.local ip_удалённого_сервера

1. И закономерно. Такое не меняется в рамках одной версии операционки.
2. В debian вообще с webp всё не просто, вероятно из-за лицензионных каких-нибудь заморочек.
3. И зря в общем-то.

Если у тебя там старый debian или ubuntu 18.04, то придётся пересобирать php или устанавливать его из сторонних репозиториев.
Ну или на imagick перейти.

Это не выделенный сервер, это VPS, поверх которого поставлена какая-нибудь кривая панелька(потому что нормальная денег стоит), и дана техподдержка, которая, обычно, у хостеров ничего не умеет толком, кроме самых базовых вещей.
Такое называется managed VPS. И часто, лучше уж шаред хостинг, потому, что квалификации админов и поддержки на него нужно меньше, т.к. всё одинаковое.

Вообще, это не правильный конфиг для Drupal. Не будут, например работать стили изображений.
Т.е. в этом случае должен быть какой-нибудь шаблон конфига Nginx для Drupal специальный, как и для многих других приложений, если не дают доступа к редактированию конфига. Во многих панельках для хостинга так и сделано.

Если такого нет, ваши хостеры явно придумали фигню. В мире шаред хостинга так бывает не редко...

Выделенный сервер, это когда есть доступ ко всему серверу, и надо самому всё настраивать, в частности конфиг nginx. А когда всё спрятано за панелькой, это скорее всего всё же шаред хостинг.

Если используется nginx + php-fpm, то зависит от того, как написан конфиг nginx.
Если apache + php-fpm, от того как настроен apache, и если включена обработка .htaccess, от того что в нём.

У php-fpm нет каких-то специфичных настроек для разных приложений, только runtime настройки php и кол-во порождаемых процессов, если упростить.

Это не всегда так, но на уровне 1,5с, это конечно очень небольшое время, даже на 2GHz проце.

Php-fpm сам не обладает каким-либо функционалом фильтрации запросов. Что-то можно делать либо слоем выше, в настройках веб сервера - это значительно эффективнее, потому что запрос не будет доходить до обработчика php вовсе, либо слоем ниже, в настройках приложения, что создаст дополнительную нагрузку.

Да.

Что возвращает nslookup legalcompany.com.ua у этого клиента?
Где находится клиент?
Остальные сайты не в tld ua?

По whois:
domain: legalcompany.com.ua
dom-public: NO
mnt-by: ua.ukrnames
nserver: dns1.vps-private.net
nserver: dns2.vps-private.net
status: ok
created: 2015-12-14 16:31:34+02
modified: 2022-09-29 15:05:29+03
expires: 2022-12-14 16:31:34+02
source: UAEPP

А как выглядит "не работает у проблемный клиентов"? Какая у них ошибка?

Чаще всего, никакой настройки не нужно. А если она нужна в сети определённого провайдера, то не будет работать ни один сайт. И на своей стороне это никак не исправить.

Первый же комент под видео хорошо объясняет его ошибочность. KDE это сложная многокомпонентная система. Если сравнивать какой-нибудь KWin с XFCE, это одно, а весь запущенный в итоге KDE набор софта будет заметно толще, но и функциональнее, с другой стороны.

Производительность будет выше, и относительно WSL(заметно) и относительно нативного php(не очень на много), и быстрее разработки на виртуалке с linux(вообще не слишком заметно, но распределение ресурсов будет удобнее).
И в целом, 8ГБ памяти может быть достаточно, если базы не очень большие. А вот 2,5ГГц проц это так себе.

1. Точно.
2. Да, там много лишней работы, даже в WSL2, да и нативно, что php, что mysql работают печальнее под WIN.
3. Уф. Кажется, конечно. KDE один из самых прожорливых, XFCE наборот.