Composer: Allowed Memory Size Exhausted During Install in CI

Composer's dependency solver can use a lot of memory on large or complex graphs. When PHP's memory_limit is too low, composer install/update dies with "Allowed memory size exhausted" partway through resolution.

What this error means

A composer install or update in CI fails with "Fatal error: Allowed memory size of N bytes exhausted" during resolution. It is intermittent or appears after the dependency graph grows.

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to
allocate 20480 bytes) in phar:///usr/bin/composer/src/Composer/DependencyResolver/...

Common causes

memory_limit too low for the solver

The runner php.ini sets a finite CLI memory_limit; a large dependency graph exceeds it during resolution.

A full update resolves the whole graph

composer update (no scope) explores far more of the graph than a scoped update or a lock-based install, peaking memory higher.

How to fix it

Raise the limit for Composer

Use COMPOSER_MEMORY_LIMIT (Composer-specific) or a -d override.

COMPOSER_MEMORY_LIMIT=-1 composer update --no-interaction
# or
php -d memory_limit=-1 /usr/bin/composer install --no-interaction

Install from the lock instead of updating

composer install against a committed lock resolves far less and uses less memory than a full update.

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

Scope updates and raise CLI default if needed

1. Prefer composer update vendor/pkg over a bare composer update.
2. Set a higher CLI memory_limit in the runner php.ini if many jobs need it.
3. Keep composer.lock committed so CI installs (not updates) by default.

How to prevent it

• Set COMPOSER_MEMORY_LIMIT=-1 for update jobs that touch large graphs.
• Commit composer.lock and use install in CI, reserving update for deliberate runs.
• Give the runner image a sensible CLI memory_limit.

Related guides