Magento Open Source

Last reviewed Aug 26, 2026 · 901 words

Do not run Magento Open Source for a store with fewer than a few thousand products or without one person who will treat it as their job. The catalogue's 4 GB minimum is the floor, not the recommendation; a comfortable production box is 8 to 16 GB, and the application will not even install without a MySQL-compatible database, an OpenSearch or Elasticsearch instance, a working cron, Composer and a set of authentication keys from an Adobe account. It is rated Hard for good reason. The people it serves well have multiple storefronts, B2B price tiers, complex promotions and a development team, and for them nothing open source comes close. Everyone else should read the last section first.

Six services, three of them mandatory

A working stack is PHP-FPM with about 20 extensions, MySQL or MariaDB, and OpenSearch (Elasticsearch also works) for catalogue search and layered navigation; search has been a hard requirement since the 2.4 line, not an optional speed-up. On top of that, Redis for sessions and cache is optional in name only, Varnish for full-page cache is what makes category pages load in under a second, and RabbitMQ handles asynchronous jobs if you run bulk imports. Cron is not optional: indexers, email queues and scheduled imports all stop silently without it. Each of these is a container you patch, monitor and back up, which is the operational overhead the catalogue warns about.

The install starts with an Adobe account

There is no official Docker image. You get the code through Composer from Adobe's repository, which requires public and private keys generated from a Marketplace account:

composer create-project --repository-url=https://repo.magento.com/ \
  magento/project-community-edition store
cd store
bin/magento setup:install \
  --base-url=https://shop.example.com \
  --db-host=db --db-name=magento --db-user=magento --db-password=change-me \
  --search-engine=opensearch --opensearch-host=opensearch --opensearch-port=9200 \
  --admin-firstname=Ada --admin-lastname=Admin \
  [email protected] --admin-user=ada --admin-password=change-me-Long1
bin/magento cron:install
bin/magento deploy:mode:set production

The community-maintained markshust/docker-magento project wraps all of this in compose files and is the sane way to get a local environment; for production, most teams end up with their own compose or Kubernetes definitions. Every code change or extension install then runs setup:upgrade, setup:di:compile, setup:static-content:deploy and a cache flush, which on a small box takes 10 to 20 minutes and is why a staging environment is not a luxury.

Where the complexity pays for itself

One admin runs many websites, each with many stores and store views, so a company selling under 3 brands in 4 currencies with separate catalogues and shared inventory needs no second platform. Catalogue price rules and cart price rules stack promotions in ways WooCommerce plugins struggle to model. Customer groups drive tiered and B2B pricing, and the configurable, bundle and grouped product types cover catalogue shapes that flatter platforms fake with variants. The Adobe Commerce Marketplace holds thousands of extensions, most of them paid, typically $50 to $500 each, and a serious store budgets for several. There is also a community fork, Mage-OS, which tracks the same codebase with a more open governance model and is worth knowing about if you worry about Adobe's roadmap; the Open Software License 3.0 on the code lets that fork exist.

The security story is the reason to patch weekly

Magento stores hold checkout pages, and card-skimming attacks on unpatched instances were common enough that the attack category got named after the platform. Adobe publishes security patches on a regular schedule and each one is a same-week job, not a someday job. Restrict the admin path by IP or VPN, enforce 2FA for admin users (it is on by default in current versions), and audit installed extensions, because most compromises arrive through a third-party module rather than core. If nobody on your side will own that routine, this is the wrong platform regardless of how good the feature list looks.

Who should pick something else

A shop with a few hundred products and one owner belongs on WooCommerce, where the same store runs on a $10 VPS. Mid-sized catalogues that outgrow WordPress but do not need multi-website tend to be happier on PrestaShop, which is simpler to operate and cheaper to extend. Teams building a custom front end should look at the headless platforms in the e-commerce category instead of stripping Magento's theme layer. And a merchant who was on Shopify Plus and is weighing self-hosting should read the honest trade-off in the Shopify alternatives page before committing to any of them.

What I'd do

If the store genuinely needs multi-store, B2B pricing or a five-figure catalogue, run Magento Open Source on a dedicated 16 GB box (or two), with OpenSearch, Redis and Varnish as separate containers, a staging copy for every extension install, and a calendar entry for patches. Budget a day a month of a developer's time for upkeep. If reading that made you wince, that wince is the answer: WooCommerce or PrestaShop will sell the same products this week, and you can migrate up later, which is far easier than migrating down.