Composer install slow with no dependency cache in CI

By Daniel Zoghalchali·Latchkey

Without a persisted Composer cache, every CI run downloads all dist archives again from Packagist and GitHub. This wastes minutes and adds API pressure that can trigger rate-limit 403s. Caching the Composer cache directory on the composer.lock hash makes repeat installs fast.

What this error means

composer install takes minutes each run downloading the same archives, and occasionally hits GitHub rate limits, because no cache is restored between jobs.

  - Downloading (100%)
  - Installing symfony/console (v7.0.0): Downloading (100%)
  - Installing guzzlehttp/guzzle (7.8.1): Downloading (100%)
  ... every package downloaded again on the next run

Common causes

No cache step persists the Composer directory

The job downloads every dist archive fresh because nothing restores ~/.cache/composer between runs.

The cache key is not tied to the lock

A key that ignores composer.lock either never hits or serves a stale cache, so downloads repeat.

How to fix it

Cache the Composer directory on the lock hash

1. Add actions/cache for ~/.cache/composer keyed on the composer.lock hash.
2. Include a restore-key so partial hits still help.
3. Run composer install --prefer-dist so cached archives are reused.

- uses: actions/cache@v4
  with:
    path: ~/.cache/composer
    key: composer-${{ hashFiles('composer.lock') }}
    restore-keys: composer-

Or use the ramsey/composer-install action

This action installs dependencies and manages the Composer cache in one step.

- uses: ramsey/composer-install@v3

How to prevent it

• Cache ~/.cache/composer keyed on the composer.lock hash.
• Install with --prefer-dist so cached archives are reused.
• Authenticate with COMPOSER_AUTH so fewer requests hit rate limits.

Frequently asked questions

Related guides

References

• Composer documentation
• GitHub Actions documentation