composer is "killed" automatically from SSH

Probably is a problem related to the PHP CLI memory limit configuration. You can diagnose the memory allocation to the CLI PHP with the command:

php -i | grep memory

And View which php.ini is for the CLI version with the command:

php -i | grep 'php.ini'

BTW I would suggest the correct workflow of develop with the composer dependency as follow:

but just so you know, you typically should run update on your machine, then commit/deploy the composer.lock file and only run install on your server to sync up the dependencies with the lock file, to make sure you only get stuff you tested properly. That way you can also run a server with low memory without any problems.

Hope this help

Thank you @Matteo,

Is it possible that the problem is the remaining amount of RAM available on the server?

I've verified the amount memory limit but do not think this is the problem.

php-cli -i | grep memory

However, I've solved my problem. In fact there are three ways to fix it:

1. Install a bundle without Composer

This is not a recommended solution , but usually is very useful know how to do it, especially in projects that are very outdated and you're worried about the problems that can be generated by the command composer update

This guide assumes you have no memory limit problems on your local server and therefore all commands work fine with composer .

First, you have to install the bundle in your local machine, e.g:

composer require jms/serializer-bundle

After you have installed the package, you just need to add the bundle to your AppKernel.php file:

// in AppKernel::registerBundles()
  $bundles = array(
  // ...
  new JMS\SerializerBundle\JMSSerializerBundle(),
  // ...
);

Second, open composer.json from your bundle directory, e.g.

// \vendor\jms\serializer-bundle\JMS\SerializerBundle\composer.json
"require": {
    "php": ">=5.4.0",
    "jms/serializer": "^1.0.0",
    "phpoption/phpoption": "^1.1.0",
    "symfony/framework-bundle": "~2.3|~3.0"
},

For each bundle in the "require section", open the corresponding composer.json to identify all the required bundles .

The aim is to copy the directories of all these bundles and upload them to the remote server in the "vendor " directory ( taking care to maintain the same large hierarchy of directories)

e.g:

if you open composer.json from jms/serializer bundle you can see:

// vendor/jms/serializer/composer.json
"require": {
    "php": ">=5.4.0",
    "jms/metadata": "~1.1",
    "jms/parser-lib": "1.*",
    "phpcollection/phpcollection": "~0.1",
    "doctrine/annotations": "1.*",
    "doctrine/instantiator": "~1.0.3"
},

Now, you should open composer.json from jms/metadata, jms/parser-lib and phpcollection/phpcollection to identify the others bundles that you have to upload to the remote server.

The goal is that no dependencies are missing.

finally, open /vendor/composer/autoload_namespaces.php from remote server and add all namespaces of your bundle dependencies. You should compare this file with you locally "autoload_namespaces.php".

2. Adding Swap Space

You have three options: create a new swap partition, create a new swap file, or extend swap on an existing LVM2 logical volume. It is recommended that you extend an existing logical volume.

3. update composer in local to only install in remote

This is the recommended option to make a good programming practice . When composer update is done on a third project , We don't know what can be happen wrong but when you have enough time for development and the project will be yours from now, you should have the project fully upgraded. First update on your local server with composer update and resolve all conflicts that arise . Finally, with the composer.json and composer.lock updated on the server, from now and forever only need to run a composer install to install and update all dependencies for the new bundles.

Matteo's explanation is correct, the composer update command occupies much more memory than composer install.

But just so you know, you typically should run update on your machine, then commit/deploy the composer.lock file and only run install on your server to sync up the dependencies with the lock file, to make sure you only get stuff you tested properly. That way you can also run a server with low memory without any problems.

upload composer.lock file from local device to server and run composer install