What's new
kishansavaliyakb@gmail.com
Chat on WhatsApp
Toggle Nav
My Cart
Magento glossary

What is Composer for Magento ?

Composer is the PHP dependency manager Magento 2 has used since 2.0 — it replaced modman and git-only installs. Magento ships as a metapackage (magento/product-community-edition for Open Source, magento/product-enterprise-edition for Adobe Commerce) pulled from the authenticated repo.magento.com Composer repo. You authenticate via auth.json with a Marketplace public+private key pair, install with composer require, then wire the new code into Magento with bin/magento setup:upgrade. Magento also ships two custom Composer plugins: composer-root-update-plugin (metapackage upgrades) and cweagans/composer-patches (vendor patches).

Need Composer setup help? How it works

Written by Kishan Savaliya — Adobe Certified Magento & Hyvä developer, 8 years on platform

How it works

Five steps from auth.json to a deployed module

Composer is not magic — it’s an authenticated HTTP client, a constraint solver, a downloader, and an autoloader generator wrapped in one CLI. Here is what each command actually does to your Magento install.

  1. 01

    Authenticate against repo.magento.com

    Sign in to marketplace.magento.com, open the My Profile → Access Keys screen, and generate a key pair — the public key becomes the Composer username and the private key becomes the password. Write them into auth.json at the project root (mode 0600, gitignored) or into ~/.composer/auth.json on the dev / CI box. The block looks like {"http-basic":{"repo.magento.com":{"username":"PUBLIC","password":"PRIVATE"}}}. Without it every composer require hits a 401 on the Magento repo.

  2. 02

    Install the project — create-project for greenfield, install for clones

    Greenfield: composer create-project --repository=https://repo.magento.com/ magento/project-community-edition=2.4.7 <dir> pulls the metapackage, resolves the dependency tree, and lays down the standard Magento directory structure. Cloned repo: composer install reads the committed composer.lock and recreates an identical vendor/ tree on disk — not composer update, which would rewrite the lockfile across every dependency. The metapackage is just a manifest; the real code arrives under vendor/magento/*.

  3. 03

    Add a third-party module with composer require

    composer require vendor/module-name:^1.2 — Composer resolves the version constraint against the package’s own composer.json, downloads the source into vendor/vendor/module-name/, regenerates vendor/composer/autoload_*.php, and updates composer.lock with the resolved exact version. Magento doesn’t know about the new module yet — that’s the next step. Always pin with ^ (compatible) or ~ (patch-only) constraints; never use * in production unless you enjoy debugging surprise breaking changes at 2am.

  4. 04

    Run bin/magento setup:upgrade to wire the module into Magento

    Magento bootstraps the new module by reading vendor/.../registration.php, adds an entry to app/etc/config.php (the module enable / disable manifest), then applies every unrun Setup/Patch/Data/*.php and Setup/Patch/Schema/*.php patch and records them in the patch_list table. The setup_module table tracks installed versions. If you skip setup:upgrade, the module’s code is on disk but the database is unaware — observers and plugins won’t fire, admin menus won’t appear, and the storefront will throw "Area code not set" or class-not-found errors.

  5. 05

    Production mode: di:compile, static-content:deploy, cache:flush

    Production deploys layer three more commands on top of setup:upgrade. bin/magento setup:di:compile rebuilds generated/code/ (compiled proxies, factories, interceptors) so every class is resolved at boot time instead of on-demand. bin/magento setup:static-content:deploy -f en_US rebuilds pub/static/ with merged + minified CSS / JS / images per locale. bin/magento cache:flush dumps Redis / Varnish so the new code is actually served. Skip any of these and you’ll see the new module on dev but the old behaviour on production.

When to use

Four scenarios where Composer is the only correct answer

Composer is not optional for Magento 2 — it’s the install path, the upgrade path, and the extension path. These four scenarios are the ones where developers most often try to short-circuit it and pay the price.

  • Greenfield Magento install — bootstrap with create-project

    For any new Magento store, bootstrap with composer create-project against repo.magento.com rather than git-cloning someone else’s working copy. The Composer-bootstrapped tree gets you the canonical directory layout, a clean composer.json root that pins exactly the Magento version you asked for, an auto-generated composer.lock that locks the entire dependency tree, and a fresh auth.json stub. Cloning someone’s tree inherits their vendor/, their lockfile drift, and any patches they applied locally that aren’t in source control — a recipe for "works on my machine" deployments.

  • Adding a Marketplace or third-party extension

    Always composer require vendor/module:^x.y rather than uploading a zip into app/code/. Composer-installed modules sit under vendor/, auto-load through PSR-4, and are pinned in composer.lock so the next developer / CI / production box gets the exact same code. Manual app/code/ drops bypass dependency resolution — you discover incompatible php-amqplib versions or duplicate guzzlehttp/guzzle at runtime instead of at install time — and they never get patched because no one remembers what version is in there.

  • Upgrading Magento itself (2.4.x → 2.4.y)

    Magento minor / patch upgrades go through Composer: composer require magento/product-community-edition=2.4.7 --no-update, then composer update. The magento/composer-root-update-plugin handles the metapackage diff — it diffs your project root composer.json against the new metapackage’s base composer.json and merges in new required packages, removed packages, and updated version constraints without clobbering your custom require entries. Without that plugin you lose every third-party module you added on top of the base install.

  • CI / CD pipelines — install --no-dev --optimize-autoloader

    Every staging / production deploy in CI should run composer install --no-dev --optimize-autoloader --no-interaction. --no-dev drops PHPUnit, MFTF, phpstan, and the other dev-only dependencies that have no business being on a production box. --optimize-autoloader generates a classmap so PHP doesn’t scan the filesystem for every class load — measurable response-time win at scale. --no-interaction avoids the build hanging on a prompt when you forgot to pre-seed auth.json on a fresh runner.

Common mistakes

Three Composer mistakes that wreck Magento deployments

Every emergency Composer call I get from a Magento team comes down to one of these three. Audit your repo and your deploy script before the next release.

  • Committing auth.json — leaking the Marketplace private key

    The single most common Magento Composer mistake: developers add auth.json to git "just for this one commit" and forget to remove it. The private key is now in the git history forever — even if you git rm the file later, anyone with repo access can git log -p auth.json and pull the credentials. Always .gitignore auth.json from day one, load credentials via environment variables (COMPOSER_AUTH) or CI secrets in pipelines (GitHub Actions / GitLab CI), and rotate the Marketplace keys immediately if you ever do leak them via the My Profile → Access Keys screen.

  • Running composer update in production instead of composer require

    In production, composer update is almost always wrong. update recalculates every package in the tree against the constraints in composer.json and rewrites composer.lock — meaning a one-line "bump module X to 1.3" turns into a 200-line lockfile diff that touches Magento core, every third-party module, and every transitive dependency. The safe pattern: composer require vendor/pkg:^1.3 --update-with-dependencies — this updates only the named package and its dependency closure, leaving the rest of the lockfile alone. Use composer update only on a dedicated upgrade branch where you can review the whole diff.

  • Forgetting --no-dev --optimize-autoloader on production

    Run composer install without flags on a production box and you get the dev dependencies (PHPUnit, MFTF, phpstan, php-cs-fixer, ~150MB of test framework) and the slower unoptimised autoloader that walks the filesystem on every class load. The dev tooling alone isn’t a security risk per se, but it bloats the deploy artefact, slows up rsync, and the unoptimised autoloader costs a measurable 3-8% on TTFB at scale. The fix is one flag pair: --no-dev --optimize-autoloader — should be in every deploy script and every Dockerfile RUN composer install step.

Related concepts

Five neighbour concepts most readers want to look at next. Click through for the full deep-dive.

FAQ

Composer for Magento — frequently asked questions

  • Composer vs git for Magento — when do I use which?
    Use Composer for everything that can be a dependency — Magento core, third-party Marketplace modules, vendor libraries, and any module published to Packagist or a private Composer repo. Use git for your project root (the <code>composer.json</code>, <code>composer.lock</code>, <code>app/code/</code> custom modules, <code>app/design/</code> themes, <code>app/etc/config.php</code>, and configuration) but never for <code>vendor/</code> itself — <code>vendor/</code> belongs in <code>.gitignore</code> and is rebuilt by <code>composer install</code> on every deploy. The one exception: tiny project-specific theme tweaks or fixes you haven’t had time to package can live under <code>app/code/</code> as git-tracked code. Anything you’d reuse across projects should be a real Composer package.
  • Why is composer require so slow on Magento, and how do I speed it up?
    Magento’s dependency tree is enormous — roughly 200+ packages on a vanilla install — and <code>repo.magento.com</code> can be slow to respond to the metadata API, especially during release windows. Speed-ups: (1) commit <code>composer.lock</code> and use <code>composer install</code> in CI rather than <code>composer require</code> — <code>install</code> reads the lockfile and skips constraint resolution; (2) use <code>--prefer-dist</code> to pull zipped releases instead of <code>git clone</code>ing every package; (3) run <code>composer install --no-dev</code> on production to drop ~30+ dev-only packages; (4) on Composer 1.x, install the now-archived <code>hirak/prestissimo</code> parallel downloader — on Composer 2.x parallel downloads are built-in and prestissimo is no longer needed. (5) Cache the <code>~/.composer/cache</code> directory in CI between builds.
  • What is magento/composer-root-update-plugin and do I need it?
    Yes, you need it on every Magento install you ever plan to upgrade. The plugin patches Composer’s upgrade behaviour so that <code>composer require magento/product-community-edition=2.4.y</code> doesn’t silently overwrite your project root <code>composer.json</code>. Without the plugin, upgrading the metapackage clobbers any custom <code>require</code> lines you added (third-party modules, your own packages, patch declarations) because Composer sees them as conflicts against the new base. The plugin runs a three-way merge between (a) your current project root, (b) the previous metapackage version’s base, and (c) the new metapackage’s base — preserving your additions while applying core changes. It ships in the Magento metapackage from 2.3.3 onward; verify it’s in your <code>composer.json</code> require-list before doing any version bump.
  • How do I apply a vendor patch with cweagans/composer-patches?
    Install the plugin: <code>composer require cweagans/composer-patches</code>. Then in your project root <code>composer.json</code>, add an <code>extra.patches</code> map keyed by package name with the patch description and file path: <code>"extra":{"patches":{"magento/module-catalog":{"Fix indexer race condition":"patches/MAGECLOUD-1234.patch"}}}</code>. Patches are unified diffs — generate them with <code>git diff > patches/MAGECLOUD-1234.patch</code> against the original vendor file. Commit the patch file to your repo. On the next <code>composer install</code> / <code>composer update</code>, the plugin applies the patch automatically after the package is extracted. The patches re-apply on every install, so you never lose them on a fresh deploy. This is the correct pattern for any one-off vendor fix you can’t wait for upstream to ship.
  • Can I install Magento without Composer?
    Technically yes — you can git-clone the Magento source and run with a manually-wired autoloader — but you’ll lose Marketplace access (no <code>composer require</code> for paid extensions), dependency resolution (no automated conflict detection between modules), the optimised classmap autoloader (slower TTFB), and the supported upgrade path (no <code>composer-root-update-plugin</code> to handle metapackage diffs). In practice no real production Magento store runs without Composer in 2026 — it’s the official, documented, supported install path since Magento 2.0 launched in 2015. The "git-only" install was deprecated almost immediately. If you find documentation that says otherwise it’s pre-2016 and should be ignored.
  • Why does Composer ask for repo.magento.com credentials on every command?
    Either <code>auth.json</code> is missing from the project root, the global <code>~/.composer/auth.json</code> doesn’t have the credentials, or the file exists but the running user can’t read it (wrong owner / wrong mode). Fixes in order: (1) create <code>auth.json</code> in the project root with the Marketplace public + private keys under <code>http-basic.repo.magento.com</code>; (2) <code>chmod 600 auth.json</code> and <code>chown</code> it to the user running Composer (often <code>www-data</code> on shared hosts, the developer’s own UID on local); (3) verify by running <code>composer config --global http-basic.repo.magento.com</code> — should print the username / password without prompting. (4) On CI, inject credentials via <code>COMPOSER_AUTH</code> environment variable as a JSON-encoded string. Never commit <code>auth.json</code> to git.
Composer audit

Want a Composer + dependency audit on your Magento store?

Send your storefront URL — I will check your composer.json, lockfile drift, third-party module pinning, auth.json hygiene, root-update-plugin presence, deploy-script flags, and patch-file workflow, then reply with a written tuning plan, fixed-price quote, and earliest start date. 24-business-hour turnaround.

Get a Composer audit Hire me directly