Magento 2.4.10 Alpha1: Everything You Need to Know

Magento 2.4.10 Alpha1 came out on October 13, 2026, and it brought some cool new payment features, updated what the platform needs to run, made things work better together, and fixed tons of bugs in both Magento Open Source and Adobe Commerce. This early version lets developers, store owners, and people who make add-ons try out the new changes and see if anything might not work right before the final version comes out.

The update has PayPal Fastlane and Braintree Insights through Braintree, the Swish payment option, newer frontend tools, and better checkout, APIs, caching and indexing. Adobe also fixed problems with managing products, GraphQL, handling orders, and the admin area. But here’s the thing Magento 2.4.10 Alpha1 is still being worked on. Things might change as they keep developing it, so if you run a real store, you should test it out instead of just upgrading like normal.

This guide explains what’s in the release, the big new stuff, what changed in the code, important fixes, and things to think about when you’re checking out Magento 2.4.10 Alpha1.

Magento 2.4.10 Alpha1 is an early build in the Magento 2.4.10 release line. Adobe publishes alpha releases to provide an opportunity for developers and other technical stakeholders to evaluate upcoming changes and report issues before general availability.

The release is relevant to Magento developers, extension vendors, technical teams maintaining existing stores and merchants planning future platform upgrades.

Magento 2.4.10 Alpha1 Release Date

Adobe published Magento 2.4.10 Alpha1 on 13 October 2026. The release notes for Magento Open Source and Adobe Commerce were updated on 13 October 2026. The release documentation provides details of new functionality, dependency changes, compatibility work and selected issues fixed in the core platform.

For the complete technical record, consult the official documentation:

• Magento Open Source 2.4.10 Alpha1 Release Notes
• Adobe Commerce 2.4.10 Alpha1 Release Notes

What Does Alpha1 Mean?

An alpha release is an early version of software that’s still being worked on. It’s mainly made for people to try out and test. It lets developers look at new features, check if things work together well, and find bugs before the software is ready for everyone to use. Alpha software isn’t the same as a finished, ready-to-use version. Things might change, there could still be problems, and what the software needs to run might be different later.

For people who work with Magento, alpha releases are helpful for testing their own add-ons, looking at changes to the main code, and getting ready to test everything. Store owners can look at this information to see what might be different in the next version without having to update their actual stores right away.

Magento Open Source vs Adobe Commerce 2.4.10 Alpha1

Magento Open Source and Adobe Commerce use a lot of the same basic platform, but their release notes are different from each other. Both versions come with the documented Braintree improvements, which include Fastlane, Braintree Insights, and Swish payment support. The Adobe Commerce release notes also talk about changes that are specific to its bigger platform features.

For example, Adobe Commerce 2.4.10 Alpha1 explains Varnish 9 compatibility and a new admin tool for managing country sub-regions, like states and provinces. When developers look at a feature or plan to upgrade, they should read the release notes for the exact version they work with. A change that is documented for Adobe Commerce should not be assumed to work the same way in Magento Open Source.

The main highlights of Magento 2.4.10 Alpha1 cover payment functionality, dependency updates, platform compatibility and improvements to existing workflows.

PayPal Fastlane for Guest Checkout

Magento 2.4.10 Alpha1 introduces support for PayPal Fastlane through the Braintree integration. Fastlane is designed to make guest checkout quicker by allowing eligible customers to retrieve saved payment and shipping information.

Returning Fastlane customers can authenticate using a one-time code and access their saved details. Customers can also add or update saved cards and shipping addresses during checkout.

The integration includes styling and configuration options to help stores incorporate the experience into their checkout flow.

For merchants, the main benefit is a checkout process designed to reduce the effort required from returning shoppers. Fewer manual steps can make purchasing more convenient, although the actual effect on conversion rates depends on implementation, customer eligibility and the wider checkout experience.

Store owners evaluating this functionality should test guest checkout, address selection, payment authorisation, order creation and error handling before enabling it on a live store.

Braintree Insights for Payment Reporting

Braintree Insights adds a new payment reporting tool right inside the Magento Admin dashboard. This reporting tool lets you see information about your transactions, money settlements, payments that didn’t go through, gateway rejections, and which payment methods customers used. Store owners can organize their reports by website and pick specific dates they want to look at, and they can view reports daily, weekly, or monthly.

You can also bring in up to 13 months of old transaction information. The release notes explain how the system keeps data for up to three years and automatically removes old information to keep things organized.

This makes it much easier for store owners to check on their payment activity without having to use other separate reporting systems. For online store teams, payment reporting can help spot patterns in declined payments, see which payment methods work best, and look at how transactions change over time. It works best when you use it along with, not instead of, checking your records with your payment company and your financial records.

Swish Payment Method

The Braintree Magento integration adds Swish as a local payment method for eligible Swedish merchants.

Swish is available only when the required merchant, country, currency and payment configuration conditions are met. Customers with qualifying Swedish billing or shipping details can use the method during checkout.

The integration also accounts for successful, cancelled and failed payment flows, allowing the checkout process to respond to different transaction outcomes.

This addition is particularly relevant to stores serving the Swedish market. Merchants considering Swish should confirm their eligibility, payment provider configuration and regional requirements before testing the method.

Frontend Library and Dependency Updates

Magento 2.4.10 Alpha1 includes updates to several frontend and development dependencies.

The Magento Open Source release notes document upgrades including:

• Underscore.js from version 1.13.7 to 1.13.8.
• Knockout.js from version 3.5.1 to 3.5.3.
• imagemin-svgo from version 9.0.0 to 12.0.0.
• glob from version 11.0.0 to 13.0.0.
• serve-static from version 1.16.2 to 2.2.1.

The release also includes changes to other NPM dependencies and the Redis client library predis/predis, which moves from the 2.x line to 3.x.

Dependency upgrades can bring upstream fixes, security improvements, and better compatibility with newer development tooling. However, major-version changes may also affect custom build scripts, integrations and development workflows.

Teams maintaining custom themes or frontend build pipelines should review dependency changes and test their compilation and deployment processes rather than assuming that every existing customisation will work without adjustment.

Platform Compatibility and Framework Improvements

The release includes compatibility work across several framework components. Some changes address deprecated PHP behaviour, while others improve installation reliability, caching and internal processing.

The release notes document PHP 8.5-related fixes for specific issues, including deprecation problems that affected customer login during guest checkout and certain administration screens.

These fixes are useful indicators of the compatibility work taking place, but individual PHP 8.5 fixes should not be interpreted as proof that every Magento installation, extension or deployment configuration is automatically compatible.

Adobe Commerce also documents Varnish 9 compatibility for the 2.4.10 release line. Developers should verify the requirements applicable to their edition and exact build before changing infrastructure components.

Alongside new functionality, Magento 2.4.10 Alpha1 addresses defects in core platform workflows. Adobe’s Magento Open Source release notes report 152 issues fixed in the core code for this alpha release.

The following examples illustrate the types of improvements included in the release. They are selected highlights rather than a complete list of fixes.

Catalogue, Indexing and Product Management

Catalogue indexing and product data consistency are important for stores with large product inventories and frequent updates.

The release includes a fix for an issue where catalogue search reindexing could halt during processing, as documented in the Adobe Commerce release notes. It also addresses a problem where activating catalogue price rules did not immediately update prices in Live Search until a later forced resynchronisation.

Other fixes cover product image labels, inventory status and product data returned through APIs.

For store owners, these changes matter because incorrect or delayed catalog information can affect product discovery, displayed prices and stock availability. Developers should verify product creation, updates, indexing schedules, search results and price-rule behaviour when testing the new build.

Cart, Checkout and Order Processing

Several fixes affect customer purchasing journeys.

Examples include improvements to configurable-product checkout performance, persistent shopping cart behaviour after natural session expiry and guest checkout retries after a failed order attempt.

The release also addresses an issue in which an order could be duplicated despite an error being triggered, as well as a problem affecting the visibility of new orders in the administration grid under asynchronous indexing conditions.

These fixes target different parts of the purchasing process, from cart calculations to order management.

Testing should cover the complete transaction lifecycle, including adding products to the cart, updating quantities, applying discounts, estimating shipping, submitting payment, handling failed transactions and checking the resulting order records.

GraphQL and REST API Improvements

Magento relies on REST and GraphQL APIs for integrations with external systems, mobile applications and headless storefronts.

The release includes fixes for API-related issues involving product attributes, order item options, wishlist data and GraphQL date formatting. It also addresses a customer authentication issue in which a token generated for one website could be incorrectly validated across another website under website-scoped customer configuration.

The latter is particularly relevant to multi-website installations, where customer data and authentication must respect the intended website boundaries.

Developers should retest custom API consumers, authentication flows, product synchronisation and order integrations after upgrading. Any integration that depends on specific response structures or behaviour should be checked against the updated implementation.

Caching and Performance

Magento 2.4.10 Alpha1 includes changes intended to address performance and resource-management problems in selected scenarios.

The release notes document improvements to layout cache storage for large catalogs using Valkey, where cache entries can be shared across products with matching product type, attribute set and store view. This is intended to reduce unnecessary cache growth.

The release also addresses an indexing configuration issue in which running bin/magento setup:upgrade could change an indexer’s mode from scheduled operation to save-on-update operation. Such behaviour can create unnecessary work and increase deployment or indexing overhead on large catalogues.

Other fixes address cache invalidation, database locking and redundant processing.

These changes should not be interpreted as a guarantee that every store will become faster after upgrading. Performance depends on catalogue size, server resources, database configuration, custom modules, caching strategy and traffic patterns.

A controlled performance test is the most reliable way to determine whether a particular store benefits from the changes.

Before testing Magento 2.4.10 Alpha1, developers should confirm the requirements for the exact release build and edition.

A version upgrade may affect PHP, Composer dependencies, database services, search infrastructure, caching systems and frontend tooling. Custom extensions and integrations introduce additional compatibility considerations.

PHP and Infrastructure Requirements

Do not select a PHP version or upgrade a server based solely on an individual compatibility fix in the release notes.

Instead, consult Adobe’s official system requirements and installation documentation for the specific alpha build. Check the supported versions of PHP, Composer, the database, the search engine, caching services and message queues.

Infrastructure compatibility should be checked across the complete application stack, including the operating system, web server, deployment tooling and any managed cloud services.

Alpha requirements may change before general availability, so the compatibility information should be reviewed again before planning a future production upgrade.

Composer Dependencies and Third-Party Extensions

Custom modules and third-party extensions can rely on specific library versions, framework interfaces and PHP behaviour.

Before installing the alpha build, review Composer dependency constraints and identify packages that may conflict with the new release. Check whether extension vendors have published compatibility information for Magento 2.4.10 Alpha1.

Pay particular attention to payment integrations, shipping modules, search extensions, customer account customisations and modules that modify cart or checkout behaviour.

A successful Composer installation does not necessarily mean that every extension functions correctly. Functional testing is still required.

Themes and Frontend Compatibility

Custom themes can be affected by changes to JavaScript libraries, CSS tooling and frontend build dependencies.

After installing the alpha release in a test environment, compile the frontend assets and check the storefront for JavaScript errors, layout problems and unexpected interactions.

Test responsive layouts, product galleries, configurable product selections, minicart behaviour, checkout forms and any custom widgets. If the store uses a custom or headless frontend, review its API dependencies separately.

A structured test plan helps developers identify problems before they affect customers.

1. Prepare a Separate Test Environment

Create an isolated staging or Magento development environment rather than upgrading the live store directly. Use a representative database copy where appropriate, with sensitive data handled according to your organisation’s policies.

Record the current Magento version, installed extensions, infrastructure versions and any local patches.

2. Review Dependencies Before Installation

Check the release requirements and resolve Composer conflicts before proceeding. Review third-party module compatibility, frontend dependencies and deployment scripts.

Keep the test environment reproducible so that issues can be investigated without affecting the production store.

3. Test Essential Storefront Workflows

Run functional tests for the parts of the store that directly affect customers:

• Customer registration, login and account management.
• Product listings, search, filters and product detail pages.
• Simple, configurable, grouped and bundle products where applicable.
• Cart updates, coupons, shipping calculations and tax.
• Guest checkout and registered customer checkout.
• Successful, declined, cancelled and interrupted payment flows.
• Order confirmation, emails, refunds and administration workflows.

The exact test plan should reflect the features and integrations used by the store.

4. Validate APIs and Scheduled Tasks

Check REST and GraphQL integrations, authentication, product updates and order synchronisation. Verify cron jobs, indexers, message queue consumers and any scheduled import or export processes.

For multi-website stores, test website-specific configuration and customer access boundaries.

5. Compare Performance and Review Logs

Compare representative page response times, checkout requests, indexing behaviour and resource consumption with the previous build.

Review application, PHP, web server and database logs for warnings and errors. Test the deployment and rollback process before considering a move to a stable release.

The answer depends on the purpose of the installation.

For developers and extension vendors, the alpha release can provide an early opportunity to test custom code, identify dependency conflicts and prepare compatibility fixes. Technical teams can also use it to assess changes that may affect future deployment plans.

For most merchants operating live ecommerce stores, however, an alpha build is not the appropriate choice for a routine production upgrade. An early release may contain unresolved defects, and its requirements or behaviour may change before the final version is available.

Existing stores should continue following Adobe’s guidance for supported releases and applicable security updates. A planned upgrade should be based on the final requirements, extension compatibility, business priorities and the results of staging tests.

Merchants who do not need to evaluate prerelease functionality can monitor the official release notes and begin preparing a compatibility checklist without installing the alpha build.

Magento 2.4.10 Alpha1 provides an early look at changes to payment functionality, platform dependencies and existing ecommerce workflows. Features such as Fastlane and Braintree Insights are particularly relevant to checkout and payment operations, while the broader set of fixes addresses issues across catalogue management, APIs, order processing and caching.

For developers, the release is an opportunity to evaluate compatibility and prepare testing plans. For merchants, the most useful next step is to understand the changes, review the requirements for their edition and monitor the release as it progresses.

As with any prerelease build, decisions should be based on the official documentation and testing results rather than assumptions about the final version. A careful compatibility review and a repeatable upgrade process remain essential to maintaining a reliable Magento store.