When a headless Magento Open Source store is worth the extra build
Headless Magento Open Source through its GraphQL API fits a team that wants its own storefront, or several sales channels, running on one product catalog, one set of prices and one checkout backend. It replaces the traditional model in which Magento renders the pages with its own theme. In that model, the storefront, templates and most caching live inside the Magento codebase. In a headless build, Magento keeps the catalog, cart, customer, order and promotion logic and exposes them as GraphQL queries and mutations, while a separate application draws the pages. If your main goal is a single website with standard theme work, the extra build is usually hard to justify. The harder part is that the front end becomes a separate product with its own release cycle, test suite, hosting and on-call duties. Magento no longer renders pages, so the team must own work that the theme used to handle: rendering and hydration strategy, route and URL handling, metadata and structured data for search engines, redirects, and the Content Security Policy headers that restrict which scripts can run on payment pages. Caching also moves. Varnish full-page caching no longer covers the same responses, so the team must decide which GraphQL responses are cached at the edge, how cart and customer data stay out of shared caches, and how invalidation works after catalog changes. Checkout deserves particular attention. Standard Magento checkout behavior, including payment method handling and address validation, has to be reproduced or reworked in the new front end, and each payment integration must still meet the scope and script controls your payment provider and assessor expect. Ask your team to list every checkout step and mark which ones the front end owns and which the Magento backend owns before any design work starts. The backend does not get simpler. The Magento Open Source 2.4.9 requirements still apply, including PHP 8.5, MySQL 8.4 or MariaDB 12.3 or 11.8, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3, Composer 2.10 and nginx 1.30 on Linux x86-64, and Adobe supports only the listed combinations. Patch cycles, the 2.4.9 support window that runs to May 31, 2029, and the annual full patch in May still govern the Magento side. Confirm with your hosting team that the GraphQL endpoint, the front end's servers and the caching layer can be upgraded on the same schedule as the backend, because a headless store that falls behind on patches carries the same risk as a traditional one. Before committing, ask for a written scope that separates backend changes, front end build, caching design, SEO migration, CSP policy and checkout testing, and states who owns each. If the business case rests on a single storefront with limited customization, a standard theme on a supported 2.4.x release is often the lower-risk path.
Which Magento GraphQL pieces the front end depends on
A headless storefront reads from Magento through a small set of GraphQL operations, and each one depends on backend data that someone must configure, index and keep current. The cards below cover the endpoint, the customer and cart operations, the catalog, price and stock data, the clearCart mutation, and the extension points used when the front end needs more than the core schema provides.
The GraphQL endpoint and schema
Every storefront request goes through the GraphQL endpoint that Magento Open Source exposes, and the front end can only call the queries and mutations that schema defines. Confirm the endpoint path, the store view codes and the schema version your front end was built against. Check that caching, rate limits and access rules at the web server or CDN layer do not block the POST requests your storefront sends.
Customer and account operations
Login, registration, address book, order history and password reset all run through customer operations that need a valid customer token. Token lifetime, token revocation and how the front end stores tokens determine how safe the account pages are. Ask the team to list each account screen and map it to the operation it calls before deciding whether any custom code is needed.
Cart and checkout mutations
Cart creation, item updates, shipping and payment method selection, and order placement are the mutations that carry revenue, so they need the most testing. Guest carts and logged-in carts behave differently and merge rules can surprise shoppers. Note that the clearCart mutation, previously available only in Adobe Commerce, is included in Magento Open Source 2.4.9, so confirm the version your team runs before relying on it.
Catalog, price and stock data
Product lists, category trees, product detail pages and search results depend on indexed catalog data, and a stale index shows shoppers wrong prices or stock levels. Price rules, catalog price rules and stock status are read through the same queries, so the front end inherits any delay in indexers or cron. Ask the team which indexers must run in real time for its use case and who monitors them.
Custom fields and mutations through modules
When the core schema lacks a field or operation the front end needs, the usual route is a custom module that extends the GraphQL schema. Magento modules follow a PSR-4 compliant structure and are registered as components, and the GraphQL schema is extended through configuration in that module. Keep these extensions in version control with their own tests, because each one must be re-checked on every patch and minor upgrade.
Operations to confirm before custom code
Before any custom code is written, the team should list every GraphQL operation the chosen front end calls and compare that list with what the installed Magento version provides. Missing operations are often solved by configuration or a small module, while others point to a different front end approach. Record the list as an agreed artifact, because it becomes the scope baseline for testing and for later upgrades.
Headless storefront or a traditional theme: the trade-offs
This table compares three ways to build the storefront on Magento Open Source: a traditional theme, a custom front end that calls the GraphQL API, and a community or third-party front end starter. Read each row as a decision the team has to make, and check the running cost rows before committing, because most of the ongoing effort in a headless build sits outside Magento itself.
| Decision | Traditional Magento theme | Custom front end on GraphQL | Community or third-party starter |
|---|---|---|---|
| Team skills | PHP, Magento templates, LESS and layout XML developers | JavaScript or TypeScript front end engineers who can also read the GraphQL schema | Front end developers who can adopt and extend the starter's framework and conventions |
| SEO and rendering needs | Server-rendered pages from Magento with mature SEO features, including Magento's own URL rewrites | Server-side rendering, static generation and metadata must be built and tested by the team | Rendering model is set by the starter, so confirm SEO output and meta handling before choosing it |
| Number of sales channels | Best suited to one web storefront that shares Magento's own templates | Suits several channels (web, app, kiosk) that consume the same catalog and cart data | Suits one or two channels where the starter already covers the main pages |
| Existing theme investment | Existing custom theme can be extended in place without a second code base | Existing theme work is rewritten, so budget for a new design implementation | Existing theme work is rewritten, and the starter's components may only partly match the current design |
| Front end hosting | Served from the same Magento web nodes, with no separate deployment | Separate hosting, build pipeline, CDN and release process for the front end | Separate hosting and build pipeline, often with a vendor-specific deployment target to confirm |
| Pricing and promotion logic | Calculated once by Magento in the request that renders the page | Cart, price and promotion rules must be queried through GraphQL, and any client-side logic duplicates Magento's rules | Duplicated logic depends on how much of the starter's cart code is kept as is |
| Caching | Varnish full-page cache handles most of the storefront load | Varnish caches GraphQL responses only where the query and headers allow it, so cache rules need design | Cache behavior depends on the starter's data calls, so test cache hit rates under load |
| Who maintains the integration after launch | Magento team, with theme changes covered by upgrade work | Front end and Magento teams share ownership of the GraphQL contract and every schema change | Starter maintainers and the client team share updates, so track starter releases and their breaking changes |
| Upgrade effort | Theme and template changes are checked during each Magento patch cycle | Schema changes and deprecations are checked on each Magento release, and front end code is upgraded separately | Starter version and Magento version must both remain compatible, so confirm this before each upgrade |
How caching changes when Magento stops rendering the storefront
In a headless build, the page speed a shopper sees depends mostly on how the front end renders pages and how responses are cached in front of it, not on the Varnish full-page cache that Adobe documents for self-managed Magento installations. Varnish is designed to accelerate pages that Magento itself renders. When the storefront is a separate application that calls the Magento GraphQL API, Magento still serves the data, but the cache layers that matter most move to the front end framework, the CDN and any caching proxy placed in front of the GraphQL endpoint. Planning starts by deciding where each cache sits and who owns its rules.
Confirm three things for your Magento version and chosen front end before you design the cache. First, confirm whether the GraphQL responses your storefront needs can be cached at all, and at which layer. Second, confirm whether the queries you rely on are sent with GET requests, since many shared caches only store GET responses and a POST-only design can make CDN caching hard to apply. Third, confirm how your front end framework and any caching proxy handle the query string and headers that vary responses. Ask the front end vendor or partner for this in writing, and test it against the exact Magento version in your environment rather than relying on general guidance.
Some data must never be cached in a shared layer. Customer details, the cart, and any price or availability shown to a logged-in customer are specific to one person or one session. Caching them in a CDN or a shared proxy can expose one shopper's data to another, which is a privacy and PCI DSS concern for stores that take payments. Map each GraphQL query and mutation to one of three classes: cacheable for everyone, cacheable per customer group or store view, and never cacheable. Put the never-cacheable class in writing, and check that the front end sends private responses with headers that prevent shared caching.
Cache invalidation is the hardest part to get right. Catalog and price changes reach Magento through indexers, cron jobs and, in some integrations, message queues. The storefront only sees those changes when its cached responses expire or are purged. Decide which events should trigger a purge, such as a product update, a price change or a completed reindex, and whether purges are time based, event based or both. Confirm how your chosen caching layer supports purge by tag or by URL, and test a price change end to end so that a shopper never sees a stale price at checkout. Stale prices at checkout create disputes that cost more to fix than the cache saved.
Assign ownership before go-live. The team that runs Magento needs to know which indexers and cron tasks trigger invalidation, the front end team needs to know which responses are cacheable and for how long, and the operations team needs to know how to purge a cache during an incident. Ask any implementation partner to document cache keys, time-to-live values, purge paths and the never-cacheable list as part of the deliverables, and to show a test of an unexpected purge. These records also support later upgrades, because a change in Magento's GraphQL schema or a new front end release can alter which responses are safe to cache.
Building a headless Magento Open Source storefront step by step
This sequence takes a team from a confirmed Magento Open Source 2.4.9 stack to a headless storefront that reads and writes through GraphQL, with checks at each stage so the build can be verified before it reaches customers.
Confirm the target stack against requirements
Before any installation, the platform team checks the Magento Open Source 2.4.9 system requirements and fixes the stack: PHP 8.5, MySQL 8.4 or MariaDB 12.3 (recommended) or 11.8, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3, Composer 2.10 and nginx 1.30 on Linux x86-64. Adobe supports only the listed combinations, so any substitution, such as a different PHP or database version, must be confirmed in writing before build work starts. The step closes when a signed-off version matrix exists and every server in the staging environment reports the expected versions.
Install and index a test catalog
DeployOpen or the internal team installs Magento Open Source in the client's own environment, connects OpenSearch, Redis or Valkey, RabbitMQ and cron, and loads a representative sample catalog with categories, configurable products, prices and stock. Indexers are run and their status checked, because the GraphQL catalog queries depend on search and index data. The step closes when the admin shows all indexers as ready and a catalog query for a known product returns the expected name, SKU, price and stock status.
Define and test the GraphQL queries and mutations
The front end team lists the screens it needs, such as category listing, product detail, search, cart and account pages, and maps each to a GraphQL query or mutation in the Magento schema. Each operation is tested in GraphiQL or an API client against the staging store, including guest and logged-in tokens, and errors such as out-of-stock items are confirmed to return readable messages. Where the storefront needs cart clearing, the team checks the clearCart mutation, which the 2.4.9 release notes list as now available in Open Source. The step closes when every planned operation has a recorded test response and a documented input and output.
Build customer, cart and checkout flows
The front end implements account registration and sign-in, cart updates, address and shipping selection, and checkout through the GraphQL mutations tested earlier. The payment hand-off is built with the payment provider's approved method, so card data is collected by the provider and not passed through the Magento backend, and the decision is recorded for the PCI DSS scoping review. Tax, shipping rules and order confirmation emails are verified in the staging store. The step closes when a test order placed from the storefront appears in the Magento admin with the correct items, totals, customer and payment status.
Set security headers and CSP for rendered pages
The team sets response headers such as HTTP Strict Transport Security, frame restrictions and referrer policy on the front end server, and defines a Content Security Policy for every page the front end renders itself. Magento's CSP support from version 2.3.5 applies to Magento-rendered pages, so the team confirms which script and frame sources must be allowed, especially the payment provider's, and tests the policy in report-only mode before enforcing it. The step closes when a browser test of each rendered page shows no blocked resources that break checkout and the header scan returns the agreed values.
Add caching and CDN rules
The team separates cacheable responses, such as public category and product queries, from personalized responses like cart, account and checkout, and sets cache headers and CDN rules that respect that split. For self-managed installations, Adobe documents Varnish as the full-page cache accelerator, so the team confirms whether Varnish or another caching layer will sit in front of the GraphQL endpoint and how it is purged after catalog updates. The step closes when a repeated public query is served from cache, a cart query is confirmed to bypass it, and a test price change appears on the storefront after the purge.
Run a staging load test
Before launch, the team runs a load test against the staging environment that mirrors the production layout, including the web tier, database, search, cache and queue services. The test scenario should combine catalog browsing, search, cart updates and checkout at a volume agreed with the business, and it should watch error rates, response times and queue backlog. Results are compared with the performance targets written into the scope, and bottlenecks are fixed and retested. The step closes when a load report is signed off, checkout completes under the agreed load, and no unresolved errors remain in the logs.
Testing the GraphQL layer, checkout and failure paths before launch
Before a headless Magento Open Source storefront goes live, the team needs proof that the GraphQL layer, the checkout and the failure behavior work together against a backend that matches production. Start with a staging Magento instance built on the same PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ and nginx versions as production, since Adobe's system requirements list supported combinations and tests against an unsupported mix will not tell you much. Confirm the exact versions for your release line in Adobe's requirements page before you freeze the environment. Schema and query tests come first. Keep a versioned set of queries and mutations for every storefront call: product listing, product detail, category navigation, cart creation, cart item updates, address and shipping methods, payment method selection, and order placement. Run them against staging and assert on field names, types, nullability and error shapes, not only on HTTP status. Your front end should fail its build when a query no longer matches the schema. Run the same suite against any custom GraphQL resolver, schema extension or module you have added, because a change to one field can break a storefront component that reads it. Checkout tests must use the payment method you have actually chosen, in a sandbox or test mode supplied by that provider, with the same tokenization and redirect flow used in production. Cover guest and logged-in checkout, coupons, multiple shipping methods, failed authorizations, declined cards, abandoned payments and a retry after a timeout. Then check cart and price consistency: compare the price, tax, discount and stock shown in the front end against the totals Magento returns at each step, and against the order record after placement. Any gap is a defect, since a customer who sees one price and pays another will raise a dispute. Failure paths deserve equal attention. Simulate Magento being slow or unreachable, search being down, and the cache layer serving stale data. Confirm that the front end shows a clear, safe error instead of a stale price, a cached stock level or a half-created order. Ask your team to define in writing what happens to a cart when a mutation times out and whether a customer can retry without creating a duplicate order. Check that the front end does not cache checkout responses and that payment page scripts are governed by the Content Security Policy you have configured. Finally, plan retests. Repeat the full suite after each patch release, since Adobe's release schedule ships security patches at least annually and recommends applying patches every cycle, and after any custom GraphQL change, even a small one. Record the results, the versions tested and who approved them. Ask your implementation partner to include this regression run in the written scope and tell you how long it takes to repeat.
What drives headless build effort and how to keep each part down
This table lists the main factors that change the effort of a headless Magento Open Source build, with a way to reduce each one. Read each row as a lever you control during scoping, and check that the written scope fixes the choices in the right-hand column before work starts.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Custom GraphQL operations | Each query or mutation the front end needs that the standard schema lacks must be built, tested and maintained across upgrades. | Map every screen to standard operations first, then approve only the custom queries that the design cannot avoid. |
| Custom fields and mutations in modules | Schema extensions and resolvers in custom modules add code that every Magento upgrade must be checked against. | Limit custom mutations, prefer existing cart and customer flows, and document each schema change in the scope. |
| Pricing and promotion rules | Catalog, cart and promotion logic exposed through GraphQL must match what the theme version and the back end actually calculate. | Keep pricing logic in Magento, agree which rule types the front end must display, and freeze the rule set before build. |
| Number of storefronts | Each storefront adds a front end deployment, its own content, navigation and test matrix. | Start with one storefront that serves several store views, and add separate front ends only where the business needs them. |
| Number of locales and currencies | Translations, currency formatting, tax display and locale-specific content multiply testing and content work. | Confirm the launch locales in writing and add others in a later phase with a defined translation workflow. |
| Search integration | Product search and autocomplete are usually a separate service that the front end must query alongside GraphQL. | Use the standard OpenSearch-backed search where it fits and confirm any extra search features before scoping them. |
| Reviews, payments and other third-party services | Each external service adds an API contract, credentials, error handling and a test path through the headless front end. | Choose services with documented APIs, limit the number of providers, and confirm which items the vendor supports headlessly. |
| ERP and order integration | Product, stock, price and order sync must be reflected in the headless storefront, and sync failures must be handled. | Define the data flows and failure handling in writing and keep the storefront reading from Magento rather than the ERP directly. |
| SEO requirements | Server rendering, meta data, structured data and redirects are not provided by a client-side front end by default. | Agree the rendering approach, URL structure and redirect map early, and confirm which SEO tasks the front end framework handles. |
| Number of environments | Each environment needs its own Magento instance, front end deployment, data and integration settings, all kept in step. | Keep the environment count small, automate deployments, and agree in writing which environments the fixed scope covers. |
Securing the GraphQL endpoint, customer tokens and the front end
A headless build exposes the Magento backend through a public GraphQL endpoint and moves customer sessions into the browser, so the attack surface changes. The controls below cover what the endpoint accepts, how tokens are handled, how the front end and payment scripts may run, and how the backend stays protected and patched. Confirm each control against your Magento version and verify it in your own environment.
Limit exposed GraphQL operations
The Magento GraphQL schema includes many queries and mutations, but a headless storefront usually needs only the catalog, cart, checkout and customer operations its front end sends. Maintain an explicit allowlist of operations and confirm which mechanism your version supports, such as persisted queries or a gateway rule. Review the schema on every upgrade, because new mutations appear in releases. For example, Magento Open Source 2.4.9 makes the clearCart mutation available, which was previously limited to Adobe Commerce. Check that unlisted operations are refused in your own environment.
Disable introspection in production
Introspection returns the full schema to any caller, which makes endpoint probing easier. Keep it enabled in development and staging if front-end teams need it, and confirm how your Magento version and any gateway let you turn it off in production. Build the front end from a pinned schema file so builds do not depend on a live introspection query. Disabling introspection reduces discovery but does not replace authorization checks on each resolver, so test those separately.
Rate limiting and bot control
A GraphQL endpoint is usually one URL, so path-based rules at the edge do not separate cheap queries from expensive ones. Limit requests by client address and session, and decide whether to cap query depth or complexity in your stack. Watch for scripted cart and checkout abuse and for repeated login attempts through customer authentication mutations. Confirm which limits your CDN or web application firewall provides and which must be configured in nginx or Magento. Verify the thresholds with a load test in your own environment.
Customer tokens in the browser
Logged-in customers hold tokens that the front end sends with each request. Storing them in browser storage makes them readable by any script that runs on the page, including injected third-party code. Where your architecture allows, prefer httpOnly cookies set through a same-site backend proxy. Set token lifetimes deliberately, clear tokens on logout, and confirm how your version handles token revocation after a password change. Check that tokens never appear in URLs, query strings or application logs.
CSP for the front end and payment scripts
Magento Open Source supports Content Security Policy headers from version 2.3.5, and from 2.4.7 CSP runs in restrict mode by default on storefront and admin payment pages. Your front end framework, analytics tags and payment provider scripts each need explicit source allowances. Start in report-only mode, list every script origin the checkout loads, and test each payment method before enforcing the policy. Confirm the default directives in your version, because a misconfigured policy can block checkout entirely.
Admin URL, 2FA and backend patching
The headless front end does not change how the Magento admin is protected. Move the default admin path, enforce two-factor authentication for every admin account, and restrict admin access by network where your hosting allows. Keep the backend patched, because Adobe recommends upgrading every patch cycle to stay secure and PCI compliant. Under Adobe's lifecycle policy, 2.4.7 reaches end of regular support on May 31, 2027, so plan upgrades against that date. Confirm each setting against your version.
What to monitor, patch and document after a headless launch
After launch, the team running a headless Magento Open Source store watches the layers between the browser and the backend. That means GraphQL response times and error rates broken down by operation, cache hit rates at the Varnish full-page cache and at any cache in the front end, checkout success measured as completed orders against started checkouts, and the health of indexers and cron jobs that keep catalog data current for the API. Set alert thresholds from your own baseline in the first weeks, since no universal figure applies to every catalog. Front end deployments belong on the same dashboard, because a release that changes the queries a page sends can raise GraphQL errors without any backend change.
Patching becomes a recurring duty rather than a one-time project. Adobe's upgrade guidance recommends upgrading every patch cycle to stay secure and PCI compliant, so the operations team should plan for each cycle before it arrives. Adobe's release schedule says a full patch for the 2.4.x LTS line ships annually in May, and security patches are released at least annually for every supported release line. Confirm which release line you run and its end of regular support date in Adobe's lifecycle policy. For example, 2.4.6 reaches end of regular support on August 11, 2026, so a store still on that line needs a dated migration plan. Each backend patch must be tested against the GraphQL operations the front end uses, since a core change can alter a schema field, a mutation response or a cache header.
The handover documents should let a new engineer work out what calls the API, what breaks if a field changes and who to call at 2 a.m. The GraphQL operations inventory lists each query and mutation, the front end route or component that uses it, and its caching rule. The custom module list records each module's owner, version, dependencies and whether it follows the PSR-4 structure Adobe describes for modules. The CSP policy lists every script source, connect source and image host the storefront needs, and it should reflect that Adobe's CSP runs in restrict mode by default on storefront and admin payment pages from 2.4.7. The environment map shows web, database, OpenSearch, Redis or Valkey, RabbitMQ, Varnish and front end hosts. Runbooks cover indexer reset, cache flush, cron failure and rollback of a front end deployment.
The upgrade plan must cover the front end and the backend together, because a Magento upgrade can change the GraphQL behavior the storefront depends on. Adobe names customizations, extension count, third-party integrations and coding practices as the main drivers of upgrade effort, and it references the Upgrade Compatibility Tool for checking code. Confirm the service versions the target release supports before scheduling work. Adobe's 2.4.9 requirements list PHP 8.5, OpenSearch 3, Redis or Valkey 9 and RabbitMQ 4.3, and Adobe supports only the listed combinations. Plan a staging run where the backend release and the matching front end build are tested together against the operations inventory, and agree in writing who approves each production step.
Questions buyers ask before building a headless Magento store
What drives the cost of a headless Magento Open Source build?
Cost is driven by how much custom work the storefront needs, how much the catalog and data model differ from the defaults, and how many systems the store must talk to. The main components are discovery and architecture, the GraphQL integration layer, the front end application, extension and ERP or payment connectors, testing, and hosting for both the Magento backend and the front end. Most of this is one-time work, while hosting, patching, extension maintenance and support recur. A fixed-scope quote should list each deliverable, the systems in scope, the environments provided, the testing approach, who performs each task, what the client must supply, and what is excluded. Ask for the recurring costs separately so the first-year and ongoing numbers can be compared.
How long does a headless Magento store take to build?
Duration depends on the number of storefront templates, the depth of custom catalog and checkout logic, the count of integrations, and how quickly the client makes decisions and returns test feedback. Teams that already run Magento and have a settled data model usually move faster than teams that are still defining products, pricing and promotions. Confirm the timeline against the written scope, which should name phases, milestones and the client reviews each phase depends on. Ask what happens if integration partners or sandbox access arrive late, since those delays are a common reason headless projects slip.
What does our internal team need to provide before the build starts?
The team should expect to provide clean catalog data, including attributes, categories, product relationships and media, along with sample data that reflects real edge cases. Payment and ERP work requires sandbox credentials, API documentation, test accounts and a named contact for each system. Decision owners must approve design, checkout rules, pricing logic and cutover criteria in a timely way. Test resources matter too: staging environments that match production versions, test payment methods and a set of testers from merchandising, customer service and finance. Put these dependencies in the scope so that delays are visible and assigned.
Can our team build a headless Magento store without outside help?
A team with strong PHP, Magento module and front end skills can build parts of a headless store in house, especially when the storefront is simple. Outside help is most often needed for GraphQL schema and query design, performance and caching under load, Content Security Policy and payment page scripts, ERP and payment integration, and security testing before launch. Many teams also bring in help for the upgrade path, since Adobe's upgrade guidance names customizations, extension count, third-party integrations and coding practices as the drivers of upgrade effort. Assess your team against each of these areas, not just general development capacity.
Does Mage-OS change how we should build the headless front end?
Mage-OS is a community-owned distribution built on Magento Open Source, and its site describes it as upstream compatible with Magento 2 extensions. For a headless build, that compatibility question matters mainly for the backend: you still need to confirm that each extension you rely on exposes the GraphQL types and mutations your front end uses. The choice of front end approach, such as a JavaScript framework consuming GraphQL, does not change because of the distribution. Before deciding, check which release line you would run, how security patches are delivered, and whether your required extensions are tested against it. Confirm these points with the Mage-OS project and your own extension vendors.
Which Magento Open Source version should a new headless store target?
Target a release line that is still in standard support for the full life of the project, plus the upgrade time after launch. Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability, and it lists end of regular support dates for each line. Magento Open Source 2.4.9 was released in May 2026 and its system requirements list PHP 8.5, MySQL 8.4 or MariaDB, OpenSearch 3, Redis or Valkey 9 and RabbitMQ 4.3. Confirm the exact combination against Adobe's requirements page, because Adobe supports only the listed combinations.
How should we check security for a headless GraphQL storefront?
Security checks should cover the GraphQL endpoint itself, including authentication, authorization on customer and order queries, query depth and rate limits, and error messages that do not leak data. The front end needs its own review for Content Security Policy, dependency vetting and handling of tokens. Adobe documents Content Security Policy support from version 2.3.5, and from 2.4.7 the policy runs in restrict mode by default on storefront and admin payment pages, so test payment flows early. DeployOpen runs application, API and infrastructure security testing, and it prepares evidence for compliance assessments, but it does not issue audit reports or certifications. Ask for the testing scope in writing before work begins.
How DeployOpen scopes, builds and hands over headless Magento work
DeployOpen plans, implements, customizes, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and headless Magento Open Source work follows the same path. The GraphQL storefront, the Magento backend and the supporting services are agreed in writing before build starts, so the client knows what is delivered and what is tested.
How we scope
- Engagements are fixed-scope, with the headless storefront, GraphQL endpoints and Magento modules agreed in writing before work starts.
- The written scope names the front end approach, the GraphQL queries and mutations the storefront needs, and which customizations are in or out.
- Scope also records the hosting target, the supported PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey and RabbitMQ versions, and the caching layer.
How we build
- Custom functionality is built as Magento modules that follow the PSR-4 structure, so upgrades touch fewer parts of the codebase.
- The front end is built against the GraphQL API, with caching, Content Security Policy headers and payment page scripts configured and tested together.
- Builds run in the client's own environments, with staging checks against the agreed GraphQL schema and catalog data before release.
How we hand over
- Handover includes source code, configuration, deployment steps and documentation for the GraphQL endpoints and the caching setup.
- Test results cover the agreed queries, mutations, checkout flows and cache behavior, so the client's team can repeat them after changes.
- Clients receive a written record of the supported software versions and the patch steps their own team will own after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed-scope build.
- Support can cover patch cycles for the 2.4.x line, extension compatibility checks and GraphQL schema changes before they reach production.
- Confirm with DeployOpen during scoping which upgrade and monitoring tasks a retainer covers and which remain with the client's team.
