Magento / Adobe Commerce Answers
Real Magento 2 and Adobe Commerce questions from merchants and developers, answered by Stagebit engineers who build and maintain these stores. Rohit Kundale holds Adobe Certified Professional (Commerce Developer) and Adobe Certified Expert (Commerce Front-End Developer) credentials, both verifiable on Credly. This library covers edition and licensing decisions, upgrade planning, Hyvä and frontend work, performance and Core Web Vitals, B2B configuration, and the production errors that come up most often. Where another platform would serve a store better, we say so.
Magento editions and platform choice
- Magento Open Source and Adobe Commerce run on the same core codebase, but Open Source is free and self-hosted while Adobe Commerce is a paid license starting at roughly $22,000 a year that scales with your store’s gross merchandise volume. Adobe Commerce adds native B2B tools, Page Builder, customer segmentation, content staging, advanced reporting, and direct Adobe support on top of everything in Open Source. Choose Open Source if you have development resources and want full control without a license fee. Choose Adobe Commerce if you need built-in B2B functionality, managed cloud hosting, and vendor support at scale.
- Magento Open Source is missing native B2B account and quoting tools, customer segmentation, content staging and preview, Adobe Sensei AI product recommendations, reward points and store credit, native RMA (returns) management, and Visual Merchandiser. All of these ship built in with Adobe Commerce. Most stores can replicate some of these gaps with third-party extensions, but B2B workflows, staging, and Sensei AI have no true native equivalent on Open Source.
- Adobe Commerce licensing is not a flat fee. It is a custom quote based mainly on your store’s trailing 12-month Gross Merchandise Value (GMV), with Average Order Value (AOV) and deployment model as secondary factors. On-premises licenses typically start around $22,000/year for stores under $1M GMV and scale past $125,000/year at higher volumes, while Adobe Commerce on Cloud (which bundles managed hosting) starts around $40,000/year and can exceed $190,000/year. The license itself is usually only 20 to 40 percent of total annual spend once hosting, development, extensions, and maintenance are added.
- Adobe Commerce and Adobe Commerce on Cloud Infrastructure run the exact same Magento core codebase and extension system. The difference is infrastructure ownership: on-premises, the merchant sources, configures, and patches the servers, database, cache, and search themselves, while Cloud Infrastructure gives them a pre-provisioned, Adobe-managed AWS or Azure environment with Fastly, New Relic, and Git-based deployment already built in. The merchant’s dev team still owns Magento upgrades and custom code either way. Most teams choose Cloud unless they have a specific reason to keep infrastructure in-house, such as existing hosting investment or a compliance requirement.
- Yes. Magento Open Source is still actively developed, using the same 2.4.x codebase as Adobe Commerce, with Adobe shipping new releases like 2.4.9 in May 2026. Each 2.4.x version gets three years of full security support from its release date, but Open Source loses access to the extended patches Adobe Commerce customers get once that window closes. Mage-OS, a community-governed fork, also maintains compatible releases for merchants who want a support path independent of Adobe.
- The current supported version is Adobe Commerce 2.4.9 (Magento Open Source 2.4.9), released May 2026. If your extensions aren’t confirmed compatible yet, run 2.4.8-p5 in the meantime. Versions 2.4.5 and 2.4.6 lost Adobe’s standard support on August 11, 2026, and are now in a one-time, security-only transitional period Adobe itself calls migration time, not a support tier. If you’re on 2.4.5, 2.4.6, or anything older, start planning your upgrade to 2.4.8 or 2.4.9 now.
- As of September 2026, Adobe Commerce 2.4.7, 2.4.8, and 2.4.9 receive full security and quality patches under standard support. Version 2.4.6 is in a one-year extended support window through August 2027, and 2.4.4/2.4.5 are in a security-only phase ending May 2027, for Adobe Commerce customers only. Magento Open Source, the free self-hosted edition, gets none of these extensions, so Open Source stores on 2.4.6 or earlier receive nothing further. A critical vulnerability (APSB26-146) patched September 8, 2026 hit every supported version, including 2.4.9, so a supported version number alone doesn’t confirm a store is current.
- Magento 2.4.4 and 2.4.5 run on PHP 8.1, 2.4.6 supports 8.1 and 8.2, 2.4.7 supports 8.2 and 8.3, 2.4.8 supports 8.3 and 8.4, and 2.4.9 requires PHP 8.5 only. Adobe Commerce and Magento Open Source share the same PHP requirements at each line. As of 2026, only 2.4.7, 2.4.8, and 2.4.9 are still receiving security patches.
- Magento 1 reached official end of life on June 30, 2020. Adobe stopped shipping security patches, quality fixes, and extension updates for the platform on that date, and pulled Magento 1 extensions from its Marketplace within weeks. A store still running Magento 1 today gets no vendor support at all, and carries rising security and PCI DSS compliance exposure the longer it stays unpatched. Migrating to Magento 2 or another supported platform is the only way to close that gap.
- Magento Open Source has no native B2B module. Adobe Commerce B2B is built in: company accounts, shared catalogs, negotiable quotes, and purchase order approvals. A simple B2B setup, net pricing, invoice terms, no internal approval chain, can run fine on Open Source with the right extension. Once buyers need shared logins or a quote has to move through approval before it becomes an order, Adobe Commerce is the more direct route.
- Adobe Commerce Optimizer is a SaaS overlay from Adobe that adds a faster, AI driven storefront, catalog management, and merchandising tools on top of your existing commerce backend. It does not replace your platform: it ingests catalog data from Adobe Commerce, a PIM, or an ERP, then serves search, recommendations, and product pages through its own storefront. It fits merchants who want to keep their current backend, cart, and checkout while modernizing the customer facing experience, including Adobe Experience Manager (AEM) customers who need an easier way to manage a catalog from a third-party commerce engine.
- Adobe Commerce Storefront, built on Edge Delivery Services, serves pages from Adobe’s edge network and uses drop-in components for cart, checkout, and product pages. It replaces your current theme, whether that’s Luma, Hyvä, or a custom build. Commerce Admin and your order data stay on Adobe Commerce. You can move the whole storefront at once or migrate part of the funnel first.
- Adobe Commerce as a Cloud Service (ACCS) is Adobe’s multi-tenant SaaS edition of Adobe Commerce, and Adobe upgrades it automatically with no version numbers. Adobe Commerce on Cloud infrastructure is the single-tenant PaaS edition: Adobe hosts the stack, while your team owns the codebase along with every patch and upgrade. ACCS only accepts out-of-process extensions built on APIs, events, and App Builder, so PHP modules from Magento Marketplace do not run on it.
- A production Magento 2 store needs a Linux server running a stack matched to its exact version. For 2.4.9 on-premises, Adobe tests PHP 8.5, MySQL 8.4 or MariaDB 12.3, OpenSearch 3, Valkey 9, Varnish 8, and RabbitMQ 4.3. Hardware follows traffic and catalog size rather than a fixed spec: plan about one CPU core per two concurrent uncached requests plus one per cron process, a 2 GB PHP memory limit on a single server, and database RAM close to half your data size.
- Keep three capabilities in-house: admin operations, merchandising, and marketing. Backend PHP development, frontend theming, server management, and security patching are specialist skills. Hire for them only when custom development is continuous. Until then, an agency or retained Magento developer covers them at lower risk than a single generalist hire.
- Move off Magento if your catalog and checkout are standard, nobody on your team knows Magento, and upgrades keep delaying revenue work. Stay if you sell B2B, run several storefronts, or depend on ERP or PIM integrations. For those stores, an audit of extensions and hosting is the better first step.
Servers and environment
- For Magento 2.4.9 with Nginx on Ubuntu, start from Ubuntu 26.04 LTS, which ships PHP 8.5 and MySQL 8.4. As of October 2026, those match Adobe’s tested versions for Magento 2.4.9, alongside OpenSearch 3, Composer 2.10 and nginx 1.30. Create a MySQL database, download Magento Open Source with your Marketplace access keys, and run bin/magento setup:install.
- Run composer create-project –repository-url=https://repo.magento.com/ magento/project-community-edition=2.4.9 and authenticate with your Commerce Marketplace access keys (public key as username, private key as password). Then set file permissions and run bin/magento setup:install with your database credentials and OpenSearch host. After that, patches and extensions become a composer update instead of a manual file overwrite.
- To run Magento 2 on your machine with Docker, allocate at least 6GB of RAM to Docker Desktop or WSL2. Get your Adobe Commerce Marketplace keys. Then run the onelinesetup script from Mark Shust’s docker-magento with a hostname, edition, and version, such as magento.test community 2.4.9. The script installs that Magento version, pins matching PHP, OpenSearch, and database images, and serves the store at https://magento.test.
- Magento 2 runs on Nginx through the nginx.conf.sample file it ships with. Define an upstream named fastcgi_backend that points at your PHP-FPM socket, set $MAGE_ROOT to the project root, and include the sample file. Keep HTTPS and custom rules in your own server block so upgrades keep the sample’s security rules. Adobe lists Nginx 1.30 for Magento 2.4.9.
- Magento 2 does not need 777 permissions on any directory. Add your SSH user to the web server group and chown the Magento root to that group. Grant group write only to var, generated, pub/static, pub/media, and app/etc, with setgid on their directories. From a 755/644 baseline, that gives 2775 directories and 664 files. For production, remove group write from app/code, lib, app/etc, pub/static, and generated code, and close app/etc/env.php to other users.
- To use Varnish as Magento 2’s full page cache, first install a version Adobe supports for your release. Varnish 8 is listed for 2.4.9, 2.4.8-p5 and 2.4.7-p10 on-premises. Next, place Varnish between your TLS terminator and the web server, and set Caching Application to Varnish Caching under Stores > Configuration > Advanced > System > Full Page Cache. Finally, generate the VCL with bin/magento varnish:vcl:generate and register Varnish as a purge target with –http-cache-hosts.
- Keep Magento’s full page cache, ideally Varnish, in charge of HTML and let Cloudflare cache only static and media files, which it does by default. Set SSL/TLS to Full (strict), restore the real visitor IP at the origin, keep purge traffic pointed at Varnish, and turn off Rocket Loader. Avoid a site-wide Cache Everything rule, because stock Magento’s purges never reach Cloudflare and shoppers end up seeing stale prices.
Upgrades and patches
- The latest Magento 2 release is 2.4.9, generally available since May 12, 2026. To upgrade safely, move your server to Adobe’s tested stack first. That means PHP 8.5, MySQL 8.4 or MariaDB 12.3, OpenSearch 3 and Composer 2.10. Next, confirm every extension supports 2.4.9 and run the Composer upgrade on a staging copy. Go live only after test orders pass with every payment method you offer. Keep a database backup ready to restore.
- To plan a Magento 2 upgrade with many third-party extensions, start with a full extension inventory from Composer and app/code. Mark each module as keep, replace, or remove before touching core. Get a compatible release from every vendor for your target Magento and PHP version. Then run the upgrade on a staging copy with production data and test checkout end to end before going live. On Adobe Commerce, Adobe’s Upgrade Compatibility Tool flags custom code issues; Magento Open Source stores rely on vendor changelogs and static analysis instead.
- Before a Magento 2 upgrade, list your modules with composer show –direct, plus anything in app/code. Confirm vendor support for your target Magento and PHP versions, then run
composer why-not magento/product-community-edition 2.4.9and a dry run for conflicts. On Adobe Commerce, Adobe’s Upgrade Compatibility Tool also flags custom code that breaks on your target release. Finish with a staging upgrade, since Composer only proves the packages install. - Adobe supports PHP 8.5 on Magento 2.4.9, PHP 8.3 or 8.4 on 2.4.8, 8.2 or 8.3 on 2.4.7, and 8.1 or 8.2 on 2.4.6. Run composer why-not php with your target version, such as 8.3, to find blocking extensions. Then install the new PHP version inside that range on staging and rerun setup:di:compile. Switch production only after test orders and cron pass, and keep the old PHP installed for rollback.
- You can patch Magento without moving to a new minor version in two ways. If your store is behind on its release line, update with Composer to the latest security-only release, for example 2.4.7-p10. If you are already on that latest -p version, apply Adobe’s monthly isolated patch files in release order, using patch -p1 on-premises or the m2-hotfixes folder on Cloud. Test on staging first, then confirm coverage with Adobe’s Commerce Version Tool.
- The Upgrade Compatibility Tool (bin/uct) runs on Adobe Commerce on-premises and on cloud infrastructure; Magento Open Source is excluded. Install it with composer create-project magento/upgrade-compatibility-tool uct –repository https://repo.magento.com (Adobe Commerce access keys required). Then run bin/uct upgrade:check -c to flag custom code as critical, error, or warning for that release. Reports export as JSON or HTML.
- Successful rollback requires a consistent pre-upgrade recovery point containing the application code and database, plus media backups when needed. Restore the matching versions, validate checkout and integrations, and reopen the store only after testing.