Guide PHP & Development

How to use Composer on shared hosting

Composer runs fine on shared hosting over SSH — here is how to install it, run it, and keep dependencies out of the public folder.

iFastHosting Support Team Updated 26 August 2026 7 min read Intermediate

Composer is a command-line tool, and shared hosting has no desktop or GUI to run one from — but that does not rule it out. Composer runs perfectly well over SSH on shared hosting, provided your plan includes SSH access. What shared hosting does not give you is root access, so the method below installs Composer into your own account rather than system-wide, which is exactly how it is meant to work for a single hosting account anyway.

Check SSH is available on your plan first

Not every hosting tier includes SSH access. If yours does not, setting up SSH keys is the natural first step, or you may need to run Composer locally on your own computer and upload the resulting vendor folder — slower, but it works when SSH genuinely is not on offer.

Installing Composer into your account

Connect over SSH and run the official installer, which downloads a composer.phar file into your current directory:

php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php composer-setup.php
php -r "unlink('composer-setup.php');"

This gives you a composer.phar file you run with php composer.phar .... If you would rather type just composer, move it somewhere on your account's path and rename it:

mv composer.phar ~/bin/composer
chmod +x ~/bin/composer

Confirm it works and check which version you installed:

composer --version

Installing a project's dependencies

Move into the project directory that contains a composer.json file and run:

composer install

This reads composer.lock if one exists and installs exactly those pinned versions, which is what you want on a live site — reproducible, not whatever the newest matching version happens to be that day. If there is no lock file yet, Composer resolves versions from composer.json and creates one, which you should then commit or otherwise keep alongside the project.

Keep the vendor folder out of reach of direct requests

Everything Composer installs goes into a vendor folder, and that folder should never be inside a publicly accessible document root on its own. If your hosting structure only gives you one public folder, structure the application so PHP includes files from vendor internally while nothing outside the application can request a file from it directly by URL — a .htaccess deny rule on the folder is a reasonable extra layer, but it should not be the only one. Frameworks like Laravel solve this by pointing the web server at a separate public folder that sits alongside, not inside, vendor — see deploying a Laravel application.

Memory during install

Composer can use a meaningful amount of memory resolving a large dependency tree, and on tight shared hosting limits an install can fail part-way through with a memory error. Composer has its own environment variable to raise the ceiling just for itself, without needing to touch PHP's own memory_limit setting for the whole account:

COMPOSER_MEMORY_LIMIT=-1 composer install

The -1 removes the limit for that one command only.

Updating dependencies safely

Do not run composer update directly on a live site. It re-resolves every dependency against your version constraints and can pull in changes you have not tested, unlike composer install, which only ever installs what the lock file already pins. The safer order:

Run composer update on a copy of the site
Ideally a staging environment, so a dependency that breaks something is caught there.
Test thoroughly
Load the parts of the site that depend most on third-party packages, and check the error log for anything new.
Copy the updated composer.lock to the live site and run composer install there
This applies the exact tested versions rather than letting the live site resolve its own set independently.

When the SSH shell uses a different PHP version to the website

Shared hosting accounts sometimes run a different PHP version in the interactive shell than the one serving web requests, since the two can be configured separately. If composer install succeeds but the site then errors, or a package refuses to install complaining about the wrong PHP version, check both — see checking your PHP version — and run Composer explicitly with the correct binary if your account provides more than one:

/usr/bin/php8.2 composer.phar install

The exact path varies by hosting platform; your control panel or support team can confirm what is available on your account.

Deploying after a Composer install

If you deploy with Git, decide deliberately whether vendor is committed to the repository or installed on the server after each deploy — both are common, but mixing approaches between environments is how a live site ends up running different dependency versions to the one that was tested. Our guides to Git deployment and deploying with rsync both cover where a Composer install step fits into a repeatable deployment process.