> Also, memory nowadays is cheap, CPU power isn't.

Unless you're running your deployment on a 512Mb or 1G VM. I've had composer max out swap on those too. Even with 2G RAM it's not been happy sometimes, so be interesting to see what difference this patch makes.

You shouldn't be running composer update on your deployment, just composer install which doesn't take as much memory since it doesn't have to resolve dependencies.

> Unless you're running your deployment on a 512Mb or 1G VM.

Question - why not run Composer locally, as part of deployment?

Yeah, i have had to move to more expensive ec2 instance on account of this very issue..

IMO you should commit your composer.lock file up to your repository and then use composer.phar install --no-dev --optimize-autoloader on any production instance. Install is much faster and uses hardly any memory compared to the update command.

To add/update any dependencies for your project run the composer.phar update on your development environment or somewhere it can use a ton of memory and cpu without issue. Then just commit and push up your composer.lock changes. Been doing it this way for over a year and had no issues deploying changes in ec2.