в компоненте была настройка force url schema

так глянь настройки компоненты

Стандартная на мой взгляд схема деплоя:

current - symlink на текущую версию релиза
releases - развернутые релизы версий проекта, не менее 3х (1 актуальная, 2 предыдущие, обязательной каждый релиз разворачивается из композера с нуля)
shared/storage/app - Каталог который симлинком вводиться в релиз
shared/storage/cms - Каталог который симлинком вводиться в релиз
shared/storage/temp - Каталог который симлинком вводитсья в релиз
shared/storage/logs - Каталог который симлинком вводиться в релиз
shared/config/production - Каталог который симлинком вводиться в релиз
shared/.env - Конфигурация боевого окружения, симлинком вводиться в релиз.


Пример:
Создаем релиз: v2.0.0, ci автомтический пулит его в releases/v2.0.0. В таком случае примерная структура релиза в каталоге:
bootstrap
config
   config/production -> ../../shared/config/production
plugins
storage
   app -> ../../shared/storage/app
   cms -> ../../shared/storage/cms
   temp -> ../../shared/storage/temp
   logs -> ../../shared/storage/logs
themes/projectTheme
.env -> ../../shared/.env
artisan
index.php
server.php
composer.json

После того как релиз выгрузился из гита и данные конфигурации были слинкованы в релиз, запускаем composer install --no-dev --no-scripts, он в свою очередь подтягивает vendor, modules.
После успешной установки накатываем миграции и линкуем текущий релиз в current

current -> ./releases/v2.0.0
Делаем reload nginx и fpm, дополнительно вызываем artisan queue:restart если есть очереди.


Плюсы:
1. Общие структуры файлового древа статики и кеша между релизами одно
2. Конфигурация между релизами одна
3. Окружение между релизами одно
4. Откатиться на предыдущий релиз путем переключения каталога и вызова rollback миграций.

+ тебе плюсик за коммент про деплоймент

Оу. Я уже и забыл про этот коммент и что скелетон скидывал в этом чате )))

Спасибо за плюс)

Только не понимаю почему они выбрали апач а не nginx

красота какая