How to Install PHP Composer on Debian 13 (Step-by-Step)

Install PHP Composer on Debian 13 with a verified installer, then use it to add a PHP package and test the generated autoloader. A fresh VPS should be ready for a small project in about ten minutes.

Prerequisites

• A 64-bit Debian GNU/Linux 13 (Trixie) VPS with the standard Debian repositories enabled.
• SSH access as root, or a normal account with sudo privileges and a writable home directory.
• At least 1 GB of RAM and 2 GB of free disk space for PHP, Composer’s cache, and the sample dependency.
• Outbound HTTPS access to getcomposer.org and Packagist. This guide does not need a domain or an inbound application port.
• A VPSLake Linux VPS if you need a Debian server with root access.

The commands use sudo for a normal SSH account. If you are already root, omit sudo where it appears and create the demo project as a non-root deployment user.

Step 1: Confirm Debian 13 and install PHP prerequisites

Confirm the release before installing packages so an old repository or a different PHP version does not get mixed into the setup. Debian 13 ships PHP 8.4, and php-cli supplies the interpreter Composer runs.

grep -E '^(PRETTY_NAME|VERSION_CODENAME)=' /etc/os-release
dpkg --print-architecture
sudo apt update
sudo apt install -y ca-certificates curl php-cli php-curl php-mbstring php-zip unzip git
php --version

The release check should identify Trixie, and the architecture should normally be amd64 or arm64:

PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
VERSION_CODENAME=trixie
amd64
PHP 8.4.x (cli) (built: ...)

curl and ca-certificates provide a trusted HTTPS download path. php-curl, php-zip, and unzip help Composer fetch and unpack packages; php-mbstring covers a common requirement for PHP applications.

Step 2: Download and verify the Composer installer

Check the installer’s SHA-384 checksum before executing it. This catches an incomplete or altered download while the file is still only a PHP script in your home directory.

cd ~
curl -fsSLo composer-setup.php https://getcomposer.org/installer
curl -fsSLo composer-setup.sig https://composer.github.io/installer.sig
EXPECTED_CHECKSUM="$(cat composer-setup.sig)"
ACTUAL_CHECKSUM="$(php -r "echo hash_file('sha384', 'composer-setup.php');")"
if [ "$EXPECTED_CHECKSUM" != "$ACTUAL_CHECKSUM" ]; then echo 'ERROR: Invalid Composer installer checksum'; rm -f composer-setup.php composer-setup.sig; exit 1; fi
echo 'Installer checksum verified'

A successful comparison prints:

Installer checksum verified

The checksum changes when Composer publishes a new installer, so retrieve it alongside the installer every time. If the comparison fails, do not continue; remove the files and troubleshoot HTTPS or DNS first.

Step 3: Install Composer globally

Install the verified binary in /usr/local/bin, which is on the normal system PATH, so every local user can run composer without maintaining a separate copy.

sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer
sudo chmod 0755 /usr/local/bin/composer
rm -f composer-setup.php composer-setup.sig
composer --version
composer diagnose

The installer reports the exact current release, so the version and date will change over time:

Composer (version 2.x.y) successfully installed to: /usr/local/bin/composer
Composer version 2.x.y YYYY-MM-DD HH:MM:SS

Composer’s official installation guide explains the PHP requirements and local versus global placement. composer diagnose checks the PHP runtime, connectivity, and common configuration problems; review any warning before using the server for deployment.

Step 4: Create a project as a non-root user

Composer can run package scripts, so let the account that owns the application install dependencies instead of making the project tree root-owned.

If your SSH session is root, switch to an existing deployment account. Skip this command if you are already logged in as that account:

sudo -iu YOUR_DEPLOY_USER

Replace YOUR_DEPLOY_USER with the Linux username that should own the application. In that user’s shell, create a clean project and require Monolog 3, a PHP logging library compatible with Debian 13’s PHP 8.4:

mkdir -p ~/composer-trixie-demo
cd ~/composer-trixie-demo
composer require monolog/monolog:^3.0

Composer writes the manifest, resolves compatible versions, records the result in composer.lock, and places package code below vendor/. The final lines should mention autoload generation:

Writing ./composer.json
Installing dependencies from lock file
Generating autoload files

The Composer basic usage guide describes why the lock file belongs with an application and why vendor/ is normally rebuilt rather than committed.

Step 5: Test the generated autoloader

Requiring vendor/autoload.php lets PHP locate Monolog without hard-coded paths to individual package files. Create a small script in the demo project:

cd ~/composer-trixie-demo
cat > demo.php <<'PHP'
<?php

require __DIR__ . '/vendor/autoload.php';

use Monolog\Handler\StreamHandler;
use Monolog\Logger;

$logger = new Logger('composer-demo');
$logger->pushHandler(new StreamHandler('php://stdout', Logger::INFO));
$logger->info('Composer autoloading works on Debian 13.');
PHP
php demo.php

The timestamp is expected to differ, but the message proves that PHP loaded both the Composer autoloader and the installed package:

[2026-10-08T12:00:00.000000+00:00] composer-demo.INFO: Composer autoloading works on Debian 13. [] []

Verify Composer on Debian 13

Run the checks from the project directory. They validate the executable, the JSON manifest, the lock file, the PHP extensions required by the resolved packages, and the sample script.

cd ~/composer-trixie-demo
command -v composer
composer --version
composer validate --strict
composer check-platform-reqs
php demo.php

You should see /usr/local/bin/composer, a Composer 2 version, a valid composer.json, successful platform requirements, and the Monolog message. Composer only needs outbound HTTPS for this example, so do not open an inbound web port or weaken the server firewall.

Troubleshooting

Invalid Composer installer checksum

The two downloads do not belong to the same installer, or a proxy returned altered content. Delete both files, confirm that the VPS resolves the official HTTPS endpoints, and download them again:

rm -f ~/composer-setup.php ~/composer-setup.sig
curl -I https://getcomposer.org/installer
curl -I https://composer.github.io/installer.sig

Do not execute an installer that fails the checksum comparison. If outbound requests are blocked, correct the network or proxy policy instead of bypassing TLS verification.

curl: (60) SSL certificate problem

The local CA bundle is missing or stale, so PHP and curl cannot validate the HTTPS certificate. Refresh Debian’s package metadata and install the trust store:

sudo apt update
sudo apt install -y ca-certificates
sudo update-ca-certificates

Avoid curl -k or other certificate-bypass flags; they remove the protection the installer check is meant to provide.

Do not run Composer as root/super user

This warning appears when dependency installation is launched by root, because package scripts would receive full system permissions. Switch to the application owner and run Composer there rather than setting COMPOSER_ALLOW_SUPERUSER=1:

sudo -iu YOUR_DEPLOY_USER
cd /PATH/TO/YOUR_PROJECT
composer install

Replace the uppercase placeholders with an existing account and project path. sudo is appropriate for placing the global binary in /usr/local/bin, not for routine project dependency commands.

Your requirements could not be resolved or missing ext-*

Composer is enforcing a package’s PHP or extension requirement. See the exact requirement in the error, inspect the active runtime, and install the matching Debian extension instead of using --ignore-platform-reqs:

php --version
php -m | sort
sudo apt install -y php-curl php-mbstring php-zip
composer check-platform-reqs

If a package requires a PHP release newer than 8.4, choose a compatible package constraint or a supported runtime plan; do not pretend the requirement is satisfied.

Hardening

• Keep composer.lock in application version control and use composer install on deployments so every server receives the reviewed dependency versions.
• For a production build, use composer install --no-dev --prefer-dist --optimize-autoloader after reviewing the lock file.
• Run composer audit before releasing, and update dependencies deliberately with composer update PACKAGE_NAME rather than changing the whole dependency graph during a deployment.
• Keep Debian, PHP, and Composer updated through a maintenance process; do not expose Composer’s project directory or .env files through a web server.

FAQ

Does Debian 13 include a PHP version that can run Composer?

Yes. Debian 13’s standard PHP line is 8.4, which is above Composer’s current minimum PHP requirement. A particular library can still require a different PHP version or extension, so Composer checks the project’s platform requirements separately.

Should Composer be installed globally or inside each project?

The global /usr/local/bin/composer installation in this guide is convenient for a VPS administrator and makes the command available to multiple local users. A project-local PHAR can be preferable when a build must pin Composer itself to one exact version.

What is the difference between composer install and composer update?

composer install uses the versions recorded in composer.lock, making it the normal choice for deployments and fresh checkouts. composer update resolves newer versions allowed by composer.json and rewrites the lock file, so use it intentionally during dependency maintenance.

Do I need a domain or web server for Composer?

No. Composer is a command-line dependency manager and only needs outbound HTTPS access to download packages. A domain, web server, and TLS certificate become relevant when the PHP application itself is ready to serve visitors.