Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Run routine Composer commands as the ordinary project or build user—not with sudo. Composer can run plugins and scripts supplied by dependencies, and that code receives the privileges of the account running Composer. Use elevated privileges only for a separate, narrowly scoped administrative task, such as updating a Composer executable installed system-wide.

Why running Composer as root is risky

Commands such as install, update, and exec can execute third-party code through Composer plugins and scripts. If Composer runs as root, that code runs with root privileges too. Composer’s guidance on installing untrusted packages therefore advises against running Composer as a superuser.

The risk is not limited to a package’s application code: Composer 2.7.0 included a security fix for code execution and possible privilege escalation involving compromised vendor-directory contents. The Composer project recorded the fix in its 2.7.0 release notes.

What Composer does when it detects a root run

Since Composer 2.4.2, Composer has a safeguard for root execution. When it detects a root run without conscious consent, it disables plugins automatically. In an interactive run, it asks for confirmation; in a non-interactive run, plugins are disabled unless COMPOSER_ALLOW_SUPERUSER=1 is set. See the Composer FAQ for the behavior.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The environment variable is an acknowledgement that you intend to run as root—not a security fix. It suppresses the warning and disables Composer’s automatic clearing of sudo sessions. Composer documents it for cases where root is deliberately the operating model, such as some container workflows; it does not make third-party code safe to run with root privileges. The CLI documentation explains the setting.

Use a non-root user for project dependencies

Run dependency resolution and installation under the account that owns or builds the project. This avoids giving Composer’s plugins and scripts more privileges than they need and helps prevent root-owned files from complicating later work by your normal user.

In CI or production deployments, keep Composer’s dependency work in a non-root build user when possible. If deployment needs elevated ownership or file placement, make that a separate, narrowly scoped step. The precise deployment layout depends on your environment; this separation follows from Composer’s documented privilege model rather than a single prescribed setup.

What to do in Docker and CI

Containers and CI jobs often run as root by default, which can trigger Composer’s safeguard. Prefer configuring the job or container to run Composer as a non-root user. If root is intentional in a controlled, disposable environment, setting COMPOSER_ALLOW_SUPERUSER=1 acknowledges that choice, but it does not reduce the privileges of enabled plugins or scripts.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

For untrusted dependencies, Composer documents disabling both plugins and scripts:

php composer.phar install --no-plugins --no-scripts

The corresponding update command is:

php composer.phar update --no-plugins --no-scripts

These flags reduce the third-party code that runs during the command. For untrusted dependency work, Composer also recommends using a container or equivalent sandbox. Review the safe-install guidance for details.

Allow only the Composer plugins you trust

Since Composer 2.2.0, the allow-plugins configuration lets a project explicitly permit plugins by package name or pattern. Its default empty object permits no plugins until they are allowed. Trust only the plugins the project needs; setting the option to true is documented as not recommended. See Composer’s allow-plugins configuration reference.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

When sudo does fit

A narrow exception is maintaining a Composer executable installed for system-wide use. Composer’s CLI documentation gives this example:

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
sudo -H composer self-update

This updates the shared Composer executable; it is not a reason to run a project’s install, update, or other dependency commands as root. Keep administrative maintenance separate from project dependency work. The example appears in the self-update command documentation.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.