How to Install Magento 2.4 with Composer: A Step-by-Step Guide

To install Magento 2 today, prepare a server that meets Adobe's requirements for your chosen version, get Magento Marketplace authentication keys, create the project with Composer, set file permissions, and run the bin/magento setup:install command with your database and OpenSearch details. After installation, switch to production mode, install the cron jobs, configure caching and secure the admin. Adobe's documentation describes Composer as the method for installing Magento Open Source and Adobe Commerce, and it is also the method that makes later upgrades and extension management manageable. Older guides that suggest downloading archives or cloning the GitHub repository are fine for contributors, but not for production stores.

This guide refreshes our earlier installation article for the Magento 2.4 line. Commands follow Adobe's current documentation; always check the requirements for the exact version you install.

Step 1: prepare the server

Adobe lists the supported software for every release on its system requirements page. In October 2026, Magento 2.4.9 lists PHP 8.5, MySQL 8.4 or MariaDB 12.3, OpenSearch 3, Valkey 9, Varnish 8, RabbitMQ 4.3, nginx 1.30 and Composer 2.10 for on-premises installations. The 2.4.8 line supports PHP 8.4 and 8.3.

1. Web server: nginx with PHP-FPM, configured with the sample configuration that ships with Magento.
2. PHP: the supported version with the required extensions, such as bcmath, intl, soap, sodium, xsl, gd and zip, and a memory limit of at least 2 GB.
3. Database: an empty database and a user with full privileges on it.
4. Search: a running OpenSearch instance reachable from the web server.
5. Composer: the supported Composer version installed globally.
6. A file system user: a dedicated user that owns the Magento files and is in the web server's group.

Running the installer on a server that does not meet these requirements is the single most common cause of failed or unstable installations. Check the PHP version used by the command line as well as by the web server, because they are sometimes different on the same machine. Our guide to Magento hosting and server requirements explains sizing and hosting options.

Step 2: get authentication keys

Magento packages are downloaded from Adobe's Composer repository at repo.magento.com, which requires authentication keys. Create a pair of access keys in your Magento Marketplace account. When Composer asks for credentials, the public key is the username and the private key is the password.

Store the keys in an auth.json file for the project or in Composer's global configuration, and keep them out of version control. Each team member or deployment pipeline can use its own key pair, which makes revoking access easier. If a key is ever exposed, for example in a public repository, revoke it in the Marketplace account and create a new pair straight away.

Step 3: create the project with Composer

Adobe's Composer installation guide uses the create-project command. Run it as the file system owner, not as root, in the directory that will contain the store.

# Magento Open Source, a specific version
composer create-project --repository-url=https://repo.magento.com/ \
  magento/project-community-edition=2.4.9 my-store

# Adobe Commerce uses magento/project-enterprise-edition instead

The command downloads Magento and its dependencies into the vendor directory and creates the project files. It can take several minutes, and it needs enough memory for Composer; on small servers, temporarily raising the PHP memory limit for the command line helps.

Pinning the version makes installations repeatable and avoids surprises when a new release appears. If Composer reports that no matching package was found, check the version string and that your keys have access to the edition you requested.

Step 4: set ownership and permissions

Magento needs write access to a few directories and read access to the rest. Adobe's guide sets group-write permissions on the writable directories and makes the command-line tool executable.

cd /var/www/my-store
find var generated vendor pub/static pub/media app/etc -type f -exec chmod g+w {} +
find var generated vendor pub/static pub/media app/etc -type d -exec chmod g+ws {} +
chown -R :www-data .    # use your web server's group
chmod u+x bin/magento

• Never make the whole project world-writable; it is a serious security risk.
• Never run bin/magento as root, which leaves files the web server cannot read.
• Point the web server's document root at the pub directory where possible, so internal files are never served directly.

Step 5: run the installer

The setup:install command creates the database schema, writes the environment configuration and creates the first admin user. Include the search engine settings, because Magento 2.4 will not install without them.

bin/magento setup:install \
  --base-url=https://shop.example.com/ \
  --db-host=localhost --db-name=magento --db-user=magento --db-password='CHANGE-ME' \
  --admin-firstname=Store --admin-lastname=Admin \
  [email protected] --admin-user=store-admin --admin-password='CHANGE-ME-LONG' \
  --language=en_GB --currency=GBP --timezone=Europe/London \
  --use-rewrites=1 \
  --search-engine=opensearch --opensearch-host=localhost --opensearch-port=9200

• Use strong, unique passwords and avoid obvious admin usernames such as admin.
• Set language, currency and time zone for your main market; they can be changed later.
• Note the admin URL printed at the end; Magento generates a non-default path for security.
• Keep the command in a private script with placeholders, so the same settings can be reused on staging.

Step 6: make the store production-ready

A fresh installation runs in default mode, which is fine for a first look but not for real customers. A few steps turn it into a production-ready store.

1. Switch to production mode with bin/magento deploy:mode:set production, which compiles code and deploys static files.
2. Install cron with bin/magento cron:install, so indexing, emails and scheduled tasks run.
3. Configure the cache backend and sessions to use Valkey, following Adobe's cache configuration guide.
4. Set up Varnish as the full-page cache.
5. Configure two-factor authentication for the admin, which Magento 2.4 enables by default.
6. Set up backups and monitoring before any real orders arrive.

Our article on Valkey, Redis and Varnish explains how the cache layers fit together.

Installing extensions and setting up development copies

Most stores add extensions and a theme soon after installation. Install them through Composer too, so versions are recorded in composer.json and composer.lock and every environment gets exactly the same code.

composer require vendor/module-name:^2.1
bin/magento module:enable Vendor_ModuleName
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f

• Prefer extensions from reputable vendors that support your Magento and PHP versions.
• Test each new extension on staging, including checkout and admin tasks.
• Avoid copying extension files into app/code by hand when a Composer package exists.
• Keep the number of extensions as small as the business needs; each one adds upgrade and security work.

Our guide to speeding up a Magento store explains how unnecessary extensions slow stores down over time.

Local development installations

Developers usually install Magento several times: on their own machines, on staging and on production. Local environments should match production as closely as possible, otherwise problems appear only after deployment.

• Use containers such as Docker-based development environments that run the same PHP, database, OpenSearch and Valkey versions as production.
• Use developer mode locally, with bin/magento deploy:mode:set developer, for detailed errors and automatic static file generation.
• Keep configuration in code with app/etc/config.php committed and app/etc/env.php generated per environment.
• Load sample or anonymised data, never a raw copy of customer data from production.
• Script the install, so a fresh environment can be rebuilt in minutes rather than set up by hand.

A scripted, repeatable installation is also the best documentation. When a new developer joins, or a server needs rebuilding after a failure, the script shows exactly how the store is put together.

Troubleshooting common installation problems

After you install Magento 2: next steps

With the platform installed, the real work begins: theme, catalogue, payments, shipping, taxes and integrations. Keep the installation upgradeable by adding customisations as modules and themes rather than editing core files, and keep everything in version control except environment-specific configuration and credentials.

Document the installation as you go: versions, configuration choices, credentials stored in your password manager and anything that differs from Adobe's defaults. Whoever maintains the store in two years' time will rely on those notes, and so will you during the first upgrade.

Plan regular updates too. Adobe releases security patches several times a year, and staying on a supported version is essential for a store that takes payments. Our guide to Magento security patches covers the update cycle, and our launch checklist lists what to check before opening the store to customers.

Frequently asked questions

Want a Magento store installed and configured properly from day one? Talk to our team or see our Magento development services.