This is rebuilt from a handful of videos I recorded between 2020 and 2023, walking through Magento installs across versions from 2.4.1 up to 2.4.6. Rewritten here as one evergreen guide, because the version numbers move but the place people get stuck never does. I am not going to hand you a copy-paste command for a specific version that will be wrong in six months. I am going to tell you the four things that actually catch people, because after enough installs they are always the same four things.

Install with Composer, not the archive

Adobe killed the setup wizard years ago, so there is no friendly web installer waiting for you. You install from the command line with Composer, pulling the project straight from Magento's repository. I have always done it this way rather than a Git clone, and I would tell any developer to do the same. It gets you into the habit of using Composer for the thing you will use it for constantly afterwards: module installs, patches, upgrades. Learn it here and the rest of the platform stops feeling like a fight.

The access keys nobody can find

The first wall is authentication. Pulling from Magento's repo needs a key pair, a public key as the username and a private key as the password. They live in your Magento Marketplace account under Access Keys, and I cannot count the number of times a developer has sat staring at a Composer auth prompt because they forgot where those keys are. The Marketplace login is not the same screen as your main account login, which is half the problem. Generate the pair once, let Composer save them to your global auth.json, and you never think about it again. If you are doing this for the first time, that is the one thing to sort out before you start, not halfway through.

The memory error that looks like a broken machine

The classic. You run the Composer create-project command and it dies partway through, usually on a Mac, looking like something is badly wrong. It almost never is. It is PHP's memory limit, and Composer is a PHP process even though it does not feel like one. The fix is to run Composer through PHP directly with a raised limit, rather than editing your php.ini and causing yourself other problems later. Find Composer with which composer, then call it through php with a memory_limit flag pointed at the composer.phar it gives you. Give it a couple of gig. I deliberately do not set it to unlimited, because if something really is wrong I want the machine to stop, not chew through everything trying.

Composer will not install into a dirty folder

This one has bitten me more than once. If a previous attempt failed and left files behind, the next run refuses, because Composer wants an empty target directory. So you fix the memory issue, press up to rerun the command, and it fails again for a completely different reason and you think you have made it worse. You have not. Clear the folder, including the half-written files, and run it clean. The same rule applies when you pull a project from Bitbucket or GitHub: the vendor folder should be empty in the repo, and Composer fills it from the lock file so you end up with the same dependency tree as everyone else on the team. That is the whole point of doing it this way.

The services Magento assumes you already have

Before the install command will run, you need the supporting cast in place. A search engine is mandatory now, Elasticsearch or OpenSearch depending on the version, and the install refuses without it. You need MySQL, version 8 for anything recent, with an empty database created up front, exactly like dropping a blank database in front of a WordPress install. And you need the right PHP version with Magento's required extensions. The minimum has crept from 7.4 up through 8.1 and beyond across these releases, so check what your target version wants rather than trusting an old tutorial. If you are missing a PHP extension, the Composer step usually names it, so install them one at a time as it complains rather than guessing the full list in advance.

A local environment that does not fight you

On a Mac I have used MAMP Pro for years and it is worth the licence, mostly for SSL out of the box and easy PHP version switching. On Linux I run Valet Linux Plus for the same reasons. Use whatever you like, but you want two things from it: the ability to flip PHP versions per site without ceremony, and local SSL, because Magento is unhappy without it. One more thing that changed along the way: Composer 1 is no longer compatible, so make sure you are on Composer 2. A quick composer self-update saves you a confusing failure.

The actual install is the easy part

Once the folder is populated and the services are up, the setup install command itself is long but boring. Base URL, database credentials, admin user, the search engine host. It runs, it builds, and you have a vanilla store sitting in the vendor folder. The reason installs feel hard is never that command. It is the four things above, and they are the same four things every time.

Why I do not do many of these any more

Honest postscript: I install Magento far less than I used to, because I moved my own work off it. The weight of the platform, the services it drags along, the version dance, all of it pushed me toward headless and a lighter stack. If you want that side of the story rather than the install, I wrote it up in why I moved from Magento to headless. But if Magento is the job in front of you, get the four gotchas right and the rest genuinely is straightforward.