Composer Error: Memory exhausted When Installing Packages – Real Fix

If you work with PHP projects long enough, you will eventually hit the dreaded Composer error: PHP Fatal error: Allowed memory size exhausted It usually happens during composer install or composer update when Composer tries to load large dependency trees or resolve versions. The good news is that this problem doesn’t mean your project is broken. It simply means PHP does not have enough memory for the process.

Let’s look at real, practical fixes that actually work.

1. Increase PHP Memory Limit Temporarily

The quickest and most commonly used solution is to give Composer extra memory only for that command.

Run:

php -d memory_limit=-1 composer install

-1 means unlimited. Use it only when needed because it disables the memory cap. You can replace install with update or any other Composer command.

Example:

php -d memory_limit=-1 composer update

2. Edit php.ini (Permanent and Safe)

A more sustainable approach is increasing the memory limit inside php.ini.

1. Find your php.ini file:
   • Linux: /etc/php/<version>/cli/php.ini
   • Windows WAMP/XAMPP: php/php.ini
2. Search for: memory_limit = 128M
3. Change it to something comfortable: memory_limit = 1G

Restart Apache or PHP-FPM if you’re modifying server PHP.

Tip: Composer often needs more than 512M on large projects, so 768M or 1G is safe.

3. Add Memory Limit Config For Local Development

If you don’t want to keep editing php.ini, you can export the environment variable:

Linux / Mac:

export COMPOSER_MEMORY_LIMIT=-1

Windows PowerShell:

setx COMPOSER_MEMORY_LIMIT -1

This applies to every future Composer command without changing system-wide PHP settings.

4. Disable Xdebug While Installing Packages

Xdebug makes Composer slower and heavier. If you don’t need debugging for the install, disable it.

Method A: Temporary flag

composer install --no-dev

Method B: Disable it in php.ini

Comment out:

zend_extension=xdebug.so

Restart PHP services if needed. You can always turn it back on later.

5. Update Composer

Older Composer versions were less optimized.

Upgrade:

composer self-update

For Composer 2 users, many performance improvements are already included, so updating can significantly reduce memory usage.

6. Use Composer’s Optimizations

If your vendor folder is large, optimization helps.

Production builds:

composer install --prefer-dist --no-dev --optimize-autoloader

Development builds:

composer update --prefer-dist --optimize-autoloader

--prefer-dist skips building packages from source.

7. Increase Swap Space (Linux Servers)

Cloud instances and VPS setups often have tiny RAM. Composer can crash even with correct memory limits. Create swap:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

This gives your system breathing room. Many hosting providers recommend at least 2 GB swap for PHP projects.

8. Don’t Use Unlimited Memory on Production Servers

Using -1 for production deployments is risky. If a process misbehaves, it can consume all available RAM and crash the server. Instead:

• Raise memory_limit gradually
• Use optimized Composer flags
• Use CI/CD containers designed for build tasks

Quick Checklist

If you still get errors, ask yourself:

• Am I running the CLI version of PHP, not web?
• Do I really need dev dependencies?
• Is Xdebug enabled?
• Am I using Composer v2 or older?
• Does the server have swap?

These five questions solve 90% of memory issues right away.

Final Thoughts

The memory exhausted error isn’t a Composer problem. It’s simply PHP hitting its limit. Increase the memory based on your environment, disable unnecessary extensions, and optimize how Composer resolves packages. Once you get these basics right, the process becomes much smoother and faster.