Composer is a command-line tool, so you run it over SSH rather than through the portal. Before writing any deploy scripts around it, confirm it's actually on the server: connect over SSH and run composer --version. If you get a version string back, you're set. If you get "command not found," Composer isn't installed for your account, and you should open a ticket asking support to enable it rather than trying to install your own copy into a shared environment.
Checking availability
SSH in the same way you would to run any other command-line tool. Once connected, run:
composer --version
This tells you two things: that the binary exists, and which major version you're on (Composer 2.x is what you want; 1.x is long past end of life and some newer packages refuse to install under it). If Composer resolves but reports a 1.x version, ask support whether a 2.x binary is available under a different alias, for example composer2.
Don't assume Composer ships by default on every account. Shared environments vary in what's pre-wired per user, and the safe move is always to check first and describe what you actually need if it's missing.
Installing dependencies per application
On shared hosting you're typically working inside your own account, not a container you control system-wide, so the normal workflow is to cd into your application's directory and run Composer scoped to that project:
cd ~/public_html/your-app composer install --no-dev --optimize-autoloader
--no-dev skips development-only packages (test frameworks, debug tools) you don't need in production. --optimize-autoloader builds a classmap instead of relying on PSR-4 lookups at runtime, which matters more on shared CPU allocations than it does on a beefy dedicated box.
If you're managing multiple applications under one hosting account, each with its own composer.json, run composer install separately inside each app's folder. There's no single global vendor directory shared across apps, each app keeps and resolves its own dependency tree.
Once your code and composer.json are in place, this is the same per-app file layout used for Laravel and other framework deployments: the app lives in its own directory with its dependencies beside it.js apps and generally in our runtime coverage, the app lives in your account's file structure and you install into it directly.
Version pinning
Pin dependency versions in composer.json rather than letting every install pull the latest minor release. A tilde or caret constraint like "vendor/package": "^2.4" allows patch and minor updates but blocks a surprise major version bump from breaking your app on the next deploy. For anything you can't afford to have shift under you, pin the exact version: "vendor/package": "2.4.1". Commit your composer.lock file alongside composer.json and run composer install (not composer update) on the server, install respects the lock file exactly; update re-resolves everything against your version constraints, which is not what you want during a routine deploy.
Memory limit tricks
Composer's dependency resolver can be memory-hungry, especially on a project with a large or tangled dependency tree, and shared hosting PHP memory limits are conservative by design. If a composer install or composer update dies partway through with an out-of-memory error, you have a few options before escalating:
- Run with an explicit memory override for just that command:
php -d memory_limit=-1 $(which composer) install. This removes the memory cap for the Composer process itself without touching your account's general PHP memory limit. - Use
composer updateas narrowly as possible: update one package at a time (composer update vendor/package) instead of the whole tree. Resolving one package's constraints takes far less memory than resolving everything at once. - Clear Composer's cache if it's grown large:
composer clear-cache. A bloated cache directory doesn't cause the memory error directly, but a fresh cache combined with a narrower update sometimes gets a stuck resolution unstuck.
If none of that resolves it, the account-level PHP memory limit set from the PHP tile in the portal may be the actual ceiling. You can raise it there for your domain if your plan allows, but treat the memory_limit=-1 override as the first thing to try since it's scoped to a single command rather than a standing account change.
When to contact support
If composer --version comes back empty, or a memory override still isn't enough to get a large install through, that's a job for support rather than more workarounds on your end. Open a ticket from Support → New ticket in the portal with the exact command and error output, our team can confirm whether Composer is enabled for your account, install it if it isn't, or point you at the right PHP memory setting for your plan.