Composer на shared‑хостинге: кэш, prefer-dist и ускорение сборок без root

На виртуальном хостинге Composer легко превращается в «узкое место»: десятки зависимостей, медленный диск, лимиты памяти и CPU, а root‑прав нет. Хорошая новость — для быстрого и безопасного продакшн‑деплоя root не нужен. Достаточно правильно настроить кэш, предпочесть архивы вместо клонов, зафиксировать токены в auth.json и немного поджать автозагрузчик.

Где и как запускать Composer на виртуальном хостинге

Лучший вариант — SSH‑доступ и системный PHP интерпретатор пользователя. Если Composer предустановлен — используйте его. Если нет, храните composer.phar в домашнем каталоге и вызывайте через php composer.phar. В продакшне всегда выполняйте composer install (а не update) по уже зафиксированному composer.lock.

cd ~/www/project
composer --version
composer install --no-interaction --no-ansi

В условиях ограниченного окружения сразу отключайте лишнее: прогресс‑бар и лишнюю раскраску терминала. Это мелочь, но ощутимо экономит I/O в медленных консолях. Если вам требуется root или изоляция по ядру, рассчитайте миграцию на VDS.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Кэш Composer: где он живет и как его закрепить

С Composer 2 кэш по умолчанию хранится в домашнем каталоге пользователя (например, ~/.cache/composer). На виртуальном хостинге важно, чтобы этот путь был постоянным от деплоя к деплою — иначе каждый запуск будет заново скачивать архивы.

# Явно зададим каталог кэша переменной окружения
export COMPOSER_CACHE_DIR=$HOME/.cache/composer

# Зафиксируем в глобальной конфигурации (создаст ~/.composer/config.json)
composer config -g cache-dir "$COMPOSER_CACHE_DIR"

# Проверим состояние окружения
composer diagnose

# Очистка (по необходимости)
composer clear-cache

Дополнительно можно управлять TTL и максимальным размером кэша:

composer config -g cache-files-ttl 15552000
composer config -g cache-files-maxsize 2048MiB

Если у вас много проектов на одном аккаунте, общий кэш заметно ускорит все сборки. На деплое имеет смысл сделать «прогрев» кэша, запустив composer install один раз «тепло», до критического переключения релиза.

prefer-dist против prefer-source: почему архивы быстрее

--prefer-dist заставляет Composer брать готовые архивы (zip/tar) с хостингов VCS и зеркал вместо git clone. Это выгодно на shared‑хостинге: меньше системных вызовов, меньше файловых операций и быстрее распаковка по сравнению с полноценным репозиторием Git.

# Разово, через CLI
composer install --prefer-dist --no-interaction

# Постоянно, в composer.json
{
  "config": {
    "preferred-install": "dist"
  }
}

Если часть пакетов доступна только как исходники (VCS), Composer сам откатится к source. Для приватных репозиториев учитывайте авторизацию — см. раздел про auth.json.

auth.json: токены, приватные репозитории и безопасность

Токены и пароли никогда не храните в composer.json или в репозитории. Используйте auth.json на уровне пользователя или проекта. На shared‑хостинге это обычно ~/.composer/auth.json либо ./auth.json в корне проекта (в последнем случае не забудьте игнорировать файл в VCS).

{
  "github-oauth": {
    "github.com": "ghp_xxxxxxxxxxxxxxxxxxxxx"
  },
  "http-basic": {
    "repo.example.com": {
      "username": "deploy",
      "password": "token-or-password"
    }
  }
}

Зачем это нужно:

• Избежать ограничений по анонимным API‑запросам (rate limit) — токены GitHub/GitLab ускоряют скачивания.
• Дать Composer доступ к приватным пакетам по HTTPS Basic Auth.
• Делегировать доступ на уровень окружения, а не репозитория кода.

Выставьте права на файл с секретами:

chmod 600 ~/.composer/auth.json

При деплое из CI удобно передавать секреты через переменную окружения COMPOSER_AUTH (JSON строка). На shared‑хостинге используйте пер‑пользовательский auth.json и не коммитьте его в VCS.

Память и таймауты: как укладываться в лимиты без root

Две частые проблемы — Allowed memory size exhausted и Process timed out. Оба лечатся на уровне пользователя.

memory_limit для Composer

Composer уважает лимит PHP. Вы можете точечно снять ограничение для процесса Composer, не затрагивая остальной хостинг:

# Одноразово
php -d memory_limit=-1 composer.phar install --no-interaction

# Через алиас (добавьте в ~/.bashrc и перечитайте профиль)
echo "alias composer='php -d memory_limit=-1 ~/bin/composer.phar'" >> ~/.bashrc
. ~/.bashrc

Либо используйте переменную COMPOSER_MEMORY_LIMIT:

export COMPOSER_MEMORY_LIMIT=-1
composer install --no-interaction

process-timeout и сеть

Медленная сеть и диск на shared‑хостинге могут выбить стандартный таймаут (300 секунд). Настройте его под реальность:

# Глобально
composer config -g process-timeout 600

# Или разово
composer install --no-interaction --timeout=600

Избавьтесь от лишних шагов: отключите прогресс и ANSI, не ставьте dev‑зависимости в продакшне, не запускайте скрипты, если они не нужны для билда.

composer install --prefer-dist --no-dev --no-interaction --no-ansi --no-progress

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Оптимизация автозагрузчика: быстрее в рантайме и меньше I/O

После установки зависимостей оптимизируйте автозагрузчик. Это уменьшает количество файловых поисков и ускоряет загрузку классов на продакшене.

composer dump-autoload -o

Зафиксируйте параметры в composer.json для предсказуемых сборок:

{
  "config": {
    "optimize-autoloader": true,
    "classmap-authoritative": true
  }
}

classmap-authoritative отключает поиск классов за пределами сгенерированных карт. В продакшне это уместно и ускоряет рантайм. Убедитесь, что все классы попадают в карту (обычно это так для популярных фреймворков).

Отключение dev‑части и плагинов, опасных для продакшена

В продакшне не нужны тестовые инструменты, снифферы и статический анализ. Они тянут много зависимостей и времени. Ставьте без dev‑пакетов:

composer install --no-dev --prefer-dist --no-interaction

В Composer 2 используйте allow-plugins для явного контроля плагинов:

{
  "config": {
    "allow-plugins": {
      "composer/installers": true,
      "dealerdirect/phpcodesniffer-composer-installer": false
    }
  }
}

Так вы исключите «тяжелые» dev‑плагины из выполнения на продакшене и избежите лишних вызовов.

Фиксация prefer-dist на уровне проекта и выборочное переопределение

Чтобы навсегда перейти на архивные установки, пропишите настройку в composer.json. Для частных случаев, когда нужен source (например, для вашего собственного пакета), используйте карту:

{
  "config": {
    "preferred-install": {
      "*": "dist",
      "vendor/project-you-debug-often": "source"
    }
  }
}

Так вы сохраните скорость для большинства пакетов и гибкость там, где она действительно нужна.

Деплой на shared‑хостинге: быстрый сценарий без root

Идеальный продакшн‑цикл на виртуальном хостинге выглядит так:

1. Коммитите composer.lock в репозиторий.
2. Готовите окружение: настраиваете постоянный кэш, auth.json, таймауты и память.
3. Деплоите код, выполняете composer install с --prefer-dist, --no-dev, --no-plugins при необходимости, затем dump-autoload -o.
4. Запускаете миграции/прогрев (если они действительно нужны).
5. Атомарно переключаете релиз (симлинк или замена директории), чтобы фронт не видел полу‑собранное состояние.

Быстрее всего деплоится тот проект, у которого кэш и vendor «живут» вне релизной директории и переиспользуются между релизами.

На shared‑хостинге обычно недоступны системные менеджеры процессов, но этого и не требуется: весь Composer‑цикл укладывается в пользовательские права. Главное — не пытайтесь update в продакшне и не тяните dev‑хвост.

Репозитории и зеркала: как ускорить сеть

Если корпоративные или частные пакеты доступны через внутренний composer‑зеркало, пропишите его как repository — это сокращает сетевые хопы и ускоряет скачивания. Для публичных пакетов держите валидные токены в auth.json, чтобы не упираться в API rate limit.

{
  "repositories": [
    { "type": "composer", "url": "https://packages.example.com" }
  ]
}

Для приватных VCS‑зависимостей, если архивы недоступны, аккуратно используйте SSH‑доступ и убедитесь, что ключи развернуты у пользователя деплоя. При этом все равно держите preferred-install в dist — это ускорит публичную часть графа зависимостей.

Диагностика и типичные ошибки

• Память: используйте COMPOSER_MEMORY_LIMIT=-1 или php -d memory_limit только для Composer, не глобально.
• Таймауты сети/диска: увеличьте process-timeout, отключите прогресс/ANSI, используйте --prefer-dist.
• Медленный первый запуск: прогрейте кэш один раз заранее.
• Rate limit: добавьте токены в auth.json и установите права 600.
• Лишние скрипты: если не требуется их выполнение на продакшне — запускайте с --no-scripts и фиксируйте allow-plugins.
• «Не видит» архивы: проверьте, что репозиторий пакета публикует dist. Иначе для конкретного пакета переключитесь на source.

Готовые рецепты конфигурации

Глобальная настройка пользователя

# Кэш
composer config -g cache-dir "$HOME/.cache/composer"
composer config -g cache-files-ttl 15552000
composer config -g cache-files-maxsize 2048MiB

# Таймаут
composer config -g process-timeout 600

# Установка по умолчанию — архивы
composer config -g preferred-install dist

Фрагмент composer.json для продакшн‑проекта

{
  "config": {
    "preferred-install": {
      "*": "dist"
    },
    "optimize-autoloader": true,
    "classmap-authoritative": true,
    "allow-plugins": {
      "composer/installers": true
    }
  },
  "scripts": {
    "post-install-cmd": [
      "@php artisan package:discover --ansi=0"
    ]
  }
}

Команда продакшн‑установки

composer install --prefer-dist --no-dev --no-interaction --no-ansi --no-progress
composer dump-autoload -o

Чек‑лист для быстрых сборок на shared‑хостинге

• Кэш: постоянный COMPOSER_CACHE_DIR, TTL и maxsize настроены.
• Сеть: токены в auth.json, нет rate limit.
• Установка: --prefer-dist по умолчанию, install вместо update.
• Лишнее отключено: --no-dev, --no-progress, --no-ansi, при необходимости --no-scripts.
• Автозагрузчик: -o и classmap-authoritative включены.
• Лимиты: COMPOSER_MEMORY_LIMIT и process-timeout заданы.
• Деплой: кэш и vendor переиспользуются между релизами.

Итоги

Ускорение Composer на виртуальном хостинге — это набор маленьких, но точных настроек. Постоянный кэш, --prefer-dist, корректный auth.json с токенами, аккуратная работа с памятью и таймаутами, плюс оптимизация автозагрузчика — и сборка перестает упираться в ограничения shared‑платформы. Все делается на уровне прав пользователя, без root и сложной автоматизации, и заметно сокращает как время инсталляции, так и нагрузку на хостинг.