What Composer needs from a shared plan
Composer is a dependency manager for PHP. It reads composer.json, resolves versions, and writes a vendor folder your application loads. On shared hosting it runs as a single PHAR file, not as a system package.
- PHP 7.2.5 or newer for Composer 2.x. PHP 8.1 to 8.3 is the practical range on current cPanel builds.
- A shell: cPanel Terminal, or SSH if the plan enables it.
- Outbound HTTPS to packagist.org and the package hosts, because downloads happen at install time.
- 512 MB of memory for a normal project, and disk space for vendor plus the Composer cache.
You do not need root, and you should not expect a global composer command. A local PHAR inside the project is the supported pattern on a shared account.
Install Composer inside the project folder
Work in the directory that holds composer.json, usually public_html or one level above it. The installer is a PHP script, so it runs with the same binary your site uses.
- Open cPanel, then Terminal. On plans without it, connect over SSH with the account username and the server hostname.
- Change into the project:
cd ~/public_html. - Fetch the installer:
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');". - Run it:
php composer-setup.php --install-dir=. --filename=composer.phar. - Remove the installer:
php -r "unlink('composer-setup.php');". - Check it:
./composer.phar --version. You know it worked when it prints Composer version 2.x and a PHP version line.
Use php -v first if the account runs more than one PHP version. The CLI default is not always the version the domain uses.
Run install and update for your project
With composer.phar in place, the two commands you need are install and update. Install reads composer.lock and reproduces it; update resolves new versions and rewrites the lock.
- Production install:
php composer.phar install --no-dev --optimize-autoloader. This skips test packages and builds a faster autoloader. - Add a package:
php composer.phar require vendor/package, then commit both composer.json and composer.lock. - Update deliberately:
php composer.phar update vendor/package. Update everything only in development. - Verify: the vendor folder exists, and the site loads without a missing class error.
If the plan has no shell at all, run Composer on your own machine and upload the vendor folder with the lock file. That is slower to iterate, but it is the same output.
Make composer callable without the path
Typing php composer.phar every time is noise. Pick one of two shortcuts, and remember that neither applies inside cron.
- Alias: add
alias composer='php ~/composer.phar'to ~/.bashrc, then runsource ~/.bashrc. Aliases are per shell session. - Wrapper: create ~/bin/composer containing the php call,
chmod +xit, and add ~/bin to PATH. This works in scripts and cron.
Keep the PHAR outside public_html if you can. A downloadable composer.phar in the web root is a file you did not mean to publish.
Match Composer's PHP version to the site
The most common shared-hosting Composer failure is a platform mismatch: Composer resolves packages for the CLI PHP version while the site runs another. The install succeeds and the site throws a fatal error.
- In cPanel open MultiPHP Manager and note the PHP version assigned to the domain.
- In Terminal run
php -vand compare. If they differ, either switch the CLI or pin the platform. - Pin it in composer.json with
php composer.phar config platform.php 8.1.29, using the version the site runs. - Re-run
php composer.phar update --lockso the lock file matches the pinned platform.
Avoid --ignore-platform-reqs to get past a failing extension. It hides the missing extension until the site calls it in production.
Common Composer failures and fixes
These six cover almost every shared-hosting install that stalls.
| Symptom | Cause | Fix |
|---|---|---|
| composer: command not found | There is no global binary on a shared plan | Call php composer.phar, or add the alias or wrapper |
| ext-zip or ext-json missing | The PHP build lacks an extension Composer needs | Enable it under Select PHP Version, then re-run the install |
| Allowed memory size exhausted | Dependency resolution needs more than the CLI limit | Prefix the command with COMPOSER_MEMORY_LIMIT=-1 |
| Could not resolve host: repo.packagist.org | Outbound HTTPS or DNS is blocked from the account | Ask the host to allow it, or build vendor locally and upload it |
| Your requirements could not be resolved | The lock file or platform.php does not match the installed PHP | Set platform.php to the site version, then update the lock |
| Permission denied writing vendor | Files were created by another user, often root | Delete vendor, re-run as the account user, never as root |
When to build dependencies elsewhere
Shared hosting is fine for installing a small dependency tree. It is the wrong place to resolve a 200-package Laravel application that needs 1 GB of memory and ten minutes of CPU.
In that case build on your laptop or CI, commit the lock file and upload vendor, or move the application to a VPS where you control the PHP binary and the memory limit. cPanel hosting remains the right home for the site itself, and shared plans include Terminal on WebJi® accounts so the local PHAR method works out of the box.
Frequently Asked Questions
Can I install Composer globally on shared hosting?
Usually not. A global binary needs write access to a system path. Install composer.phar in your project or home directory and call it with php, or add a wrapper in ~/bin.
Do I need SSH to install Composer?
You need a shell. cPanel Terminal is enough on plans that include it. Without any shell, run Composer locally and upload vendor together with composer.lock.
Which PHP version does Composer 2 need?
PHP 7.2.5 or newer. On current cPanel builds the practical choice is 8.1 to 8.3, matched to the version the domain runs so the resolved packages work in the browser too.
Why does composer install fail with a memory error?
Dependency resolution can exceed the CLI memory limit on a big tree. Run COMPOSER_MEMORY_LIMIT=-1 php composer.phar install, or raise memory_limit for the CLI PHP version.
Is it safe to upload the vendor folder instead?
Yes, if you also upload composer.lock and build with the same PHP version and platform settings. The vendor folder is plain files, and no Composer run is needed on the server.
Where should composer.phar live?
In your home directory or the project root, not inside a public web folder. A PHAR reachable by URL is an unnecessary download and a small information leak.