When a Magento Open Source store needs a Page Builder implementation
Merchandising teams usually reach this point when every landing page, seasonal banner or category introduction waits in a developer queue. Page Builder, the content editor that ships with Magento Open Source since 2.4.3, covers CMS pages, blocks and category content, so a store that only needs its marketers to assemble and publish these pages may not need a build project at all. Staging and personalization are not part of the open source edition; they are Adobe Commerce features. Decide early which of those two capabilities the business actually depends on, because that answer determines whether the project is a configuration exercise or a platform decision.
Configuration alone is usually enough when the store's content needs fit the built-in content types and the existing theme already provides the layout, typography and spacing the brand expects. In that case the work is mostly role setup, a short list of approved row and column patterns, widget and banner conventions, and a publishing checklist that merchandisers follow. Confirm with your own team which admin roles will create and approve content, and whether anyone outside the merchandising group needs edit rights. Those decisions cost little to make and avoid rework once many pages exist.
A partner becomes useful when the theme or the content model has to change. Typical triggers include custom content types for product comparisons, store-specific promotional modules, or a block structure that must match a design system used across other channels. Each custom content type is a module with its own admin form, rendering template, styling and tests, and it must survive future Magento patch upgrades. Ask any partner to show how the content type is registered, how its data is stored, and how it behaves when the theme changes. Check the theme's compatibility with the Page Builder version your release line ships before estimating the work.
Governance is the other reason to bring in outside help, and it is often underestimated. Without rules, a store accumulates dozens of one-off page layouts, inconsistent markup, and content that breaks on mobile. A practical governance set includes a naming convention for blocks, a library of approved templates, a review step before publishing, and a named owner for the theme's Page Builder styles. Where the store also handles payments, review the Content Security Policy settings alongside any custom scripts that a content type loads, since embedded third-party code changes the scope of your security review.
Before you request a quote, write down three things: which pages must be built without a developer, which layouts need code, and who owns each decision after launch. Ask the partner to state in writing what is included in the Page Builder work, what is excluded, and what you must provide, such as design files, a staging environment, and test content. The written scope is also where you confirm which Magento Open Source release line the store runs on, since support dates and compatibility differ across 2.4.x releases. Confirm those dates on Adobe's lifecycle page before you commit to a plan.
What Page Builder does in Magento Open Source
Page Builder in Magento Open Source gives teams a visual way to author CMS pages, static blocks and category content. The cards below cover what it handles, what to verify in your own admin, and where the open source edition stops compared with Adobe Commerce.
CMS page content authoring
Editors can build and update CMS pages in the Magento admin with Page Builder's visual stage, so many layout changes do not need a code deployment. The planning decisions are who receives edit rights and which existing pages move to Page Builder first. In your own admin, create a test page, save it, preview it and publish it. Confirm that pages built before you enable Page Builder still render correctly.
Reusable static block content
Static blocks let teams place shared banners, promotions and footer content on several pages from one source. Set a naming convention and an owner for each block before editing starts, because a change to a shared block appears everywhere it is placed. In your admin, add one block to two CMS pages, edit it once and confirm both pages update after the cache refreshes. Check the cache behavior in your own environment.
Category description content
Page Builder can also author category content, such as introductory text and merchandising sections on category pages. Decide which categories need rich layouts and which keep plain descriptions, because mixed structures make review harder. Open the category edit form in your admin, then view the storefront at desktop and mobile widths. Confirm that category content fits your theme's layout and that product listings and navigation still display correctly.
Content element list by release
The content elements available in Page Builder depend on your release line, and the set can change between versions, so do not assume the list from a previous project. Open the Page Builder section of Adobe's documentation for the Magento Open Source version you run, such as 2.4.9 or 2.4.8, and compare it with the elements in your admin. Record any element your editors need that is missing, and resolve that gap before design sign-off.
Features outside the open source edition
The open source edition does not include the staging and personalization capabilities that Adobe Commerce adds. If your campaigns depend on scheduled content sets or audience-based content, that requirement needs a different design or an edition decision before the build starts. List every content rule your marketing team expects, then check each one against Adobe's edition documentation. Confirm current feature availability with Adobe, since product scope can change between releases.
Where Page Builder content lives in CMS pages, blocks and categories
The first decision for a Page Builder implementation is which content surface holds each piece of storefront copy, because each one is stored, rendered and edited differently. Page Builder in Magento Open Source writes to three places: CMS pages, which hold landing pages, policy pages and home content; static blocks, which are reusable fragments that can be placed into pages, categories or layout XML; and category descriptions, which carry the content shown on category listing pages. Each surface is saved as HTML generated by the Page Builder editor, and the active theme decides how that HTML is wrapped, styled and displayed. Before the build starts, map every planned content item to one of these surfaces so the team knows where copy, images and promotional modules will live.
Ownership is the decision that most often goes unassigned. For each surface, the team should agree who creates content, who approves it, who can publish it and who maintains the reusable blocks that appear across many pages. A static block referenced from ten CMS pages changes ten storefront pages when edited, so it needs a named owner and a change process. Category descriptions tie content to the catalog structure, which means merchandising staff may need edit rights in the category tree but not in the theme or layout files. Write these assignments down against the admin roles you plan to create, and confirm that the roles you configure can reach each surface without granting broader rights than needed.
The editor output is the part that interacts with the theme and with security controls, and it deserves its own test cycle. Page Builder generates markup, inline styles and class names that must match the theme's CSS and must not conflict with the theme's layout containers. It can also produce inline style attributes and script-related output depending on the content types used. Content Security Policy is enabled in Magento Open Source from 2.3.5, and Adobe's documentation states that from 2.4.7 CSP runs in restrict mode by default on storefront and admin payment pages. Inline styles produced by the editor may therefore be blocked or flagged, so confirm current behavior in the exact release you run, including how CSP policies apply to Page Builder output, before promising a design that depends on inline styling.
Plan verification around the three surfaces separately. For CMS pages, check that the rendered page matches the editor preview at desktop and mobile widths, and that the browser console shows no blocked resources. For static blocks, test each placement, since a block inserted in a header, footer or category template can inherit different container widths. For category descriptions, confirm rendering on layered navigation and paginated listings. Record which release, theme version and CSP settings were used for each test, because a later patch or a theme change can alter how the same stored HTML renders.
Page Builder in Magento Open Source is the basic edition. Adobe Commerce adds staging and personalization, so content that needs scheduled changes or audience-specific variants should be identified early and either handled through a manual publish process or scoped as a commercial edition decision. Custom content types built for the theme extend what editors can place on these surfaces, and they should be planned together with the three surface decisions so that new components do not create a fourth, unowned content path. Confirm with your Adobe documentation and your theme vendor which extension points your release supports.
Which content approach fits each storefront need
This table compares four ways to manage storefront content in Magento Open Source: standard Page Builder elements, reusable static blocks, custom content types built for the theme, and a headless or external CMS. Read each row as a decision the team should settle before build starts, since the choice sets who edits content and how much maintenance follows. The main takeaway is that most stores need a mix, and the mix should be agreed in writing with the scope.
| Approach | When it fits | Maintenance it creates | Who edits it |
|---|---|---|---|
| Standard Page Builder elements | Landing pages, CMS pages and category content that use the built-in row, column, text, image, button and HTML elements | Low. Upgrades carry the elements forward, but layouts and stored markup need review after each patch cycle | Merchandisers and marketing staff in the admin, without developer help |
| Reusable static blocks | Promotional banners, footers, shipping notices and other content repeated across several pages | Low to moderate. Each block needs an owner and a naming rule, or duplicates pile up | Content editors, with approval from the marketing owner for shared blocks |
| Custom content types built for the theme | Repeated structured content such as brand panels, size guides or feature grids that need fixed fields and theme styling | Moderate to high. Developers maintain the module, templates and CSS, and retest them on every upgrade | Editors fill defined fields; developers change the structure |
| Headless or external CMS | Content shared with apps or other channels, or teams that already run a CMS and need one content source | High. Adds a second platform, an API contract, sync or caching logic and its own upgrade path | Content team in the external CMS; developers own the integration |
| Decision to confirm before build | Which pages and blocks each team owns, and whether any content must be approved before publishing | Confirm the approval workflow and the editing roles in the scope document | Agree the owner for each content type with the client team |
Building custom content types for a Magento theme
A custom Page Builder content type is built by extending Magento Open Source through its component model, so the work starts with how the platform is extended. Adobe's developer documentation describes modules, themes and language packages as the component types used to extend Magento Open Source and Adobe Commerce. Modules follow a PSR-4 compliant structure, which maps namespaces to directories and keeps autoloaded code predictable for reviewers and for your team during later upgrades. The first decision is where each part of the content type belongs. Logic, field definitions and registration generally belong in a module, while presentation belongs in the theme. Placing behavior in a module lets it survive a theme change, and it can be tested as code.
The build pattern has three parts. A module registers the content type with Page Builder so editors can add it from the stage. A theme supplies the template that renders it on the storefront, including its styles and any JavaScript the output needs. The third part is a set of storefront tests that confirm the rendered output matches what the editor configured. Keep the boundary between these parts strict. The module defines the fields, defaults and validation, and the theme decides how those values appear. Because Page Builder in Magento Open Source is the basic edition, confirm that every hook your content type depends on is available in that edition. Do not assume that staging or personalization extension points exist unless the developer documentation for your release says so.
Illustrative example only: a team wants a promotional banner content type for CMS pages and category descriptions. The module would declare fields for a headline, an image, a call-to-action link and a display variant, and would validate the link before saving. The theme template would render the banner using the store's existing design tokens, so the banner matches the rest of the storefront. Editors would then see the banner in the stage on a CMS page and in a category description. Before writing code, confirm the exact registration files, configuration locations and JavaScript component wiring for your chosen release in Adobe's developer docs. These conventions have changed between 2.4.x lines, and a file path that works on one line may not work on another.
Testing should cover the places where editors will use the content type, not only the template in isolation. Check the banner on desktop and mobile widths, inside a CMS page, a block and a category description, and after a full cache flush. If the content type loads inline scripts or styles, review your Content Security Policy configuration. Adobe documents CSP headers as supported from 2.3.5 and, from 2.4.7, restrict mode as the default on storefront and admin payment pages, so confirm how your release applies CSP before you rely on inline output. Custom content types are customizations, and Adobe names customizations as a driver of upgrade effort, so run these tests again on each patch cycle. Ask any implementation partner to list content types, fields, templates and test cases in the written scope.
How a Page Builder rollout runs from theme audit to launch
This sequence moves Page Builder from an inventory of existing content and theme constraints to a governed, tested and handed-over setup that can be rolled back if launch goes wrong. Each step ends with a written artifact the store owner keeps, whether an internal team or a partner runs the work.
Inventory content and audit the theme
Start by listing every CMS page, block and category description that holds content, along with the theme templates, layout XML and styles that render them. Note which content uses Page Builder today, which uses raw HTML or WYSIWYG, and which templates override core output. Record the theme's inheritance chain and any existing content types or extensions that touch the same markup. The output is a written inventory and theme audit that names every content location, the template that renders it and the risks found, such as overrides that will break when the theme changes. Confirm the Magento Open Source version and the Page Builder release bundled with it before the audit starts, because the feature set is tied to that version.
Define the content model and governance rules
Decide which content types editors may use, which rows, stages and sliders are permitted, and where custom HTML is allowed. Set rules for naming, media sizes, accessibility checks, approval steps and who may publish category or landing content. Map each rule to a role in the admin so access control matches the approval process. The output is a content model document and governance policy signed off by the store owner and the merchandising lead. It should state what is out of bounds, for example scripts or third-party embeds that need security review before they reach a live page.
Design custom content types where needed
If the standard Page Builder elements do not cover a recurring layout, design a custom content type for it. Define the data fields, the editor form, the storefront template and the CSS scope, and follow the module structure and PSR-4 conventions Adobe documents for Magento components. Keep the markup it emits predictable so that it works with the content security policy you plan to enforce. The output is a design record listing each custom type, its fields, its owning module and the templates it uses. Skip this step if the standard elements meet every requirement in the content model.
Build and integrate with the theme
Implement the custom types, the theme styles and any template changes in a development environment under version control. Keep overrides to the minimum, prefer child theme or module-based changes over edits to vendor code, and review each change against the audit list from step one. Test each element in desktop and mobile layouts and confirm that the theme's existing components render correctly within Page Builder content. The output is a tagged build with a change log that maps every customization to the audit finding or content-model requirement it addresses.
Run CSP and cache checks on staging
Deploy the build to staging, which should match production in platform versions, web server and cache layer. Verify that inline styles, scripts and external resources used by Page Builder content comply with the content security policy in effect, and that any policy changes are documented and reviewed. Check that full-page cache behaves correctly for Page Builder blocks, including pages that show per-customer or per-session content, and confirm the cache invalidation triggered by content saves. If your environment uses Varnish, confirm the configuration against the version of Varnish your Adobe release lists. The output is a signed test record with each CSP violation and cache issue found, its fix and the retest result.
Train editors and hand over the setup
Run hands-on sessions with the people who will create and approve content, using the content model and governance rules as the training material. Cover creating pages, using the approved elements, previewing on mobile, submitting for approval and recovering from mistakes. Hand over the build repository, the runbook for deploying Page Builder changes, the list of custom types and the escalation path for theme or extension updates. The output is a handover pack and a record of which editors completed training and passed a practical exercise.
Launch with a documented rollback plan
Before the production deployment, write the launch checklist, the database and media backup steps, the order of deployment and the criteria that trigger a rollback. Schedule the release during a window the store owner agrees, freeze content edits during the cutover, and verify key pages, category content and checkout after release. Keep the previous code release and database snapshot available until the store owner confirms that launch is stable. The output is a completed launch record with the verification results and a rollback runbook that has been tested in staging. The same sequence applies whether your internal team or a partner runs it, and each output is kept as a written artifact that you own.
How Page Builder connects to the theme, cache, security and other modules
Page Builder output passes through the theme, the page cache, the browser security policy, search and any catalog module that places content on category pages. A change in one layer can appear as a fault in another, so plan these connections before the content model is built. Confirm each combination against Adobe's documentation for your exact release.
Theme rendering and CSS
Page Builder content renders through the active theme, so the theme controls how rows, columns and content types look and how their CSS loads. If you build custom content types, decide early which styles belong in the theme and which belong to the content type, then test each supported breakpoint. Check that a theme upgrade leaves the spacing and layout of existing pages unchanged. Ask your partner to document which templates and stylesheets each custom content type depends on.
Full-page cache with Varnish
For self-managed installations, Adobe documents Varnish as the full-page cache accelerator. Page Builder content is served from cached pages, so an edit may not appear on the storefront until the affected pages are invalidated or refreshed. Adobe's 2.4.8-p5 system requirements list Varnish 8, so confirm the Varnish version your release supports before you set the cache policy. Test a published page edit, a block edit and a category edit to confirm invalidation behaves as your editors expect.
Content Security Policy headers
Adobe's developer documentation states that Magento Open Source supports Content Security Policy headers from 2.3.5. From 2.4.7, CSP runs in restrict mode by default on storefront and admin payment pages. Page Builder content that loads inline scripts, styles or third-party embeds can be blocked under a restrictive policy. Before launch, review the browser console on pages that use custom HTML or video embeds, and add only the approved sources your business needs to the policy.
Search and OpenSearch
Site search and layered navigation depend on the search engine, and Adobe's system requirements for 2.4.9 and 2.4.8-p5 list OpenSearch 3. Confirm whether your search configuration indexes the text of CMS pages and blocks, because editors often assume that landing page copy is searchable when it is not. Plan a reindex after content migrations, and test that new landing pages return in site search. Repeat these tests after any search engine change.
Category pages and catalog modules
Page Builder can place content in category descriptions and related blocks, and catalog or custom modules may also write content into category layouts. When two modules write to the same category area, the output order and the cached result can differ from what either module shows alone. Map every module that adds content to category pages, the layout handle it uses and the cache tags it relies on. Test each category template after a catalog or extension change.
Confirm supported combinations
Adobe supports only the combinations listed in its system requirements for each release, so the PHP, database, search, cache and Redis or Valkey versions in your stack must match a listed set. Request the requirements for your exact release, such as 2.4.9 or 2.4.8-p5, and record each version in the build document. Confirm with Adobe or your partner whether a given Varnish, CSP or search pairing is supported before it reaches production. A written compatibility list keeps security and upgrade work tied to the same versions.
What drives Page Builder implementation effort and how to keep it down
This table lists the factors that most change the work of a Page Builder build on Magento Open Source, with the lever that keeps each one under control. Read each row as a question to answer during scoping, since the driver shows where effort grows and the lever shows where a team can cut it. The main takeaway is that reusing standard Page Builder elements and limiting custom content types usually does more to control effort than any single technical shortcut.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of custom content types | Each custom content type needs its own data model, admin form, render template and front-end styling, and each must be tested in the editor and on the storefront. | Start from standard Page Builder elements such as row, text, image, banner and HTML code, and add a custom type only when an editor cannot achieve the layout another way. |
| Theme customization depth | Heavy overrides of Page Builder templates or layout XML tie the build to the theme version and make later upgrades slower to test. | Extend through the theme's own templates and CSS variables where possible, and keep overrides small and documented so they are easy to rebase. |
| Existing custom CSS and inline scripts | Legacy stylesheets and inline scripts in old CMS content can conflict with Page Builder markup and need review block by block during migration. | Audit existing CMS blocks and pages first, move reusable styles into the theme, and remove inline scripts before content is converted to Page Builder. |
| Number of editors and approval steps | More editors, roles and approval stages mean more permission rules to design, more workflow testing and more training material to write. | Group editors into a small number of roles, keep approval to one clear step where the business allows, and reuse one set of templates for common page types. |
| Cache and content security policy configuration | Full-page cache rules for Varnish and Content Security Policy headers both affect how dynamic and inline content renders, so each new element type may need cache or policy adjustments. | Decide the cache behavior and CSP allowlist for each content type during design, and test them together on a staging environment that matches production. |
| Extension count | Adobe names extension count as a driver of upgrade effort, and each Page Builder add-on can carry its own compatibility and update cycle. | Keep third-party Page Builder add-ons to the minimum needed, confirm each one's compatibility with your target 2.4.x release, and record the upgrade owner for each. |
| Testing and content migration volume | The number of page templates, existing CMS pages and device breakpoints multiplies the test cases that must be run before launch. | Limit the template set to the page types that matter, convert high-traffic pages first, and confirm the test scope in writing with the implementation partner. |
Keeping Page Builder content working through Magento Open Source upgrades
Adobe's upgrade guide recommends upgrading every patch cycle to stay secure and PCI compliant, so Page Builder content will be exposed to upgrades far more often than most teams plan for. The work to plan is not the Page Builder content itself, which lives in the database as CMS pages, blocks and category descriptions, but the code around it. Custom content types, the theme's Page Builder stage and style rules, and any custom JavaScript or knockout templates that render content are the parts most likely to break when the platform moves underneath them.
The release line you are on determines how long you have before the next forced move. Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability, with end of regular support on August 11, 2026 for 2.4.6, May 31, 2027 for 2.4.7, May 31, 2028 for 2.4.8 and May 31, 2029 for 2.4.9. Confirm the current date against Adobe's lifecycle policy before you set a plan, because a store still on 2.4.6 is already at the end of its standard support window. Adobe's release schedule also says a full patch for the 2.4.x LTS line ships annually in May, so your upgrade calendar should expect at least one larger move each year, in addition to the security patches.
Every upgrade, including a patch within the same release line, should run a regression suite that covers Page Builder pages. Build the suite from real content types in use: a homepage with banners and sliders, a landing page with row and column structures, a category page with the category Page Builder content, a CMS page with embedded widgets and a page with your custom content type. For each page, check the admin edit experience (the stage loads, every custom field saves and reloads), the storefront render at desktop and mobile widths, and the cache behavior after a full page cache flush. Record the expected output so a reviewer can see what changed. Keep the suite in version control with the theme so that it is rerun whenever the theme or the platform changes.
Before you start an upgrade, run Adobe's Upgrade Compatibility Tool and review every custom module and theme against the target release. Confirm that the target PHP, database, search, cache and message queue versions in Adobe's system requirements for that release are supported together, because Adobe supports only the listed combinations. Check that your Content Security Policy configuration still allows the scripts and styles your Page Builder content loads, since CSP behavior has changed across recent releases. Ask your developers which custom content types extend core classes and which depend on private markup, since those are the ones an upgrade is most likely to disturb.
Community distributions such as Mage-OS are another option some teams evaluate. Mage-OS is a community-owned distribution built on Magento Open Source, run by the Mage-OS Association, and its site describes it as upstream compatible with Magento 2 extensions. If you consider it, treat it as a separate platform decision: confirm which release of Magento Open Source each distribution release is based on, how security patches are delivered, and whether your custom Page Builder content types and theme code pass the same regression suite on that distribution before you commit. This is an evaluation step, not a recommendation to switch.
Questions buyers ask before hiring a Page Builder partner
How much does a Magento Open Source Page Builder implementation cost?
The cost comes from the written scope. Magento Open Source is free to download under the Open Software License 3.0, so the spend is labor, hosting, monitoring and any paid extensions. The main cost drivers are the number of page templates and custom content types, how many existing CMS pages and blocks must be migrated or rebuilt, theme complexity, integrations with product information or digital asset systems, and the number of editor roles and approval steps to configure. Design, build and training are one-time costs. Hosting, patching and support recur. DeployOpen does not publish a price list, so ask for a quote broken into phases, with the tasks each party performs, the content volume assumed, and a clear list of exclusions, such as staging or personalization, which the open source edition does not include.
How long does a Page Builder build take from kickoff to launch?
Duration is set by scope and by how quickly the client can make decisions. A small set of templates on an existing theme moves faster than a full content model with custom content types, a large page migration and several approval workflows. Content readiness is often the slowest input, because copy, images and sign-off arrive late. Version choice also matters. Adobe lists end of regular support for 2.4.7 on May 31, 2027, and for 2.4.9 on May 31, 2029, so a build on a supported release line avoids an early upgrade. Ask for a written plan with milestones, the client dependencies behind each milestone, and the test and approval windows before launch. No duration should be accepted until the scope is fixed in writing.
What does a Page Builder project need from our team?
Plan on providing a content inventory, access to the theme and staging code, named editors and approvers, and a decision owner who can settle design and content questions. The content inventory lists existing CMS pages, blocks and category content, with owners, update frequency and any pages that must stay unchanged. Theme access means a repository or package the build team can branch, plus the current design files. Editors should be identified early so they can test templates before launch and be trained on the Page Builder interface. Approvals need a defined path, such as who signs off design, copy and legal text. Also confirm access to a non-production environment, admin accounts with appropriate roles, and the hosting details that the build must fit.
Can our in-house team build Page Builder content types without a partner?
Yes, if the team has PHP and Magento development experience and can work with the component structure. Adobe's developer documentation describes modules, themes and language packages as the components used to extend Magento Open Source, and modules follow a PSR-4 compliant structure. Custom content types usually combine module code, theme templates and configuration, so the team needs to handle all three. Before deciding, check whether your engineers have shipped Magento modules and theme changes, whether they can write automated tests, and whether they can support the code through each patch cycle. Also weigh the cost of recruiting or training against the schedule. A partner is most useful when the team lacks capacity, needs a fixed-scope delivery or wants an independent review of the build.
Can staging or personalization be added to Magento Open Source Page Builder?
The basic Page Builder that ships with Magento Open Source does not include staging or personalization. Those are features that Adobe Commerce adds, so buyers who need scheduled content campaigns or audience-based content should confirm the requirement before the build starts. Options to evaluate include a separate environment and release process for content changes, a Git-based review workflow for template changes, or a third-party extension. Any extension must be checked for compatibility with the Magento Open Source version you plan to run, for its maintenance history and for its effect on upgrades. Ask any partner to state in writing which capabilities are delivered, which are not, and which would need an extension or a licensed edition, so the gap is not discovered after launch.
How do Magento upgrades affect custom Page Builder content types?
Custom content types are customizations, so they are part of the upgrade effort. Adobe's upgrade guide names customizations, extension count, third-party integrations and coding practices as the main drivers of effort, and it recommends upgrading every patch cycle to stay secure and PCI compliant. Keep custom content types in their own module, with clear dependencies and no edits to core files, so they can be tested and moved independently. Run the Upgrade Compatibility Tool referenced in Adobe's guide, then regression-test the editor workflows, not only the storefront. Ask the build team to document each content type, its templates and its test cases, and to include upgrade testing in the support scope. Plan for upgrades to be a recurring cost.
Which Magento Open Source version should a new Page Builder build target?
Target a release line that Adobe still supports for the full life of the project. Magento Open Source 2.4.9 was released in May 2026, and Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability. The listed end-of-support dates include May 31, 2027 for 2.4.7, May 31, 2028 for 2.4.8 and May 31, 2029 for 2.4.9. Adobe's system requirements for 2.4.9 list specific PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, Composer and nginx versions, and Adobe supports only the listed combinations. Confirm the hosting platform fits those requirements before the build starts, and confirm that any extensions you need support the chosen version.
How DeployOpen scopes and delivers Page Builder work
DeployOpen plans, builds, documents and supports Magento Open Source Page Builder work inside your own infrastructure. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer.
How we scope
- The written scope lists which CMS pages, blocks and category content areas Page Builder will cover.
- We record which Page Builder features are in scope and which Adobe Commerce features, such as staging or personalization, are excluded.
- The scope names the custom content types, if any, and the theme files each one touches.
How we build
- Custom content types are built as modules that follow the PSR-4 structure Adobe documents for Magento Open Source.
- We test content rendering on the PHP, MySQL or MariaDB, OpenSearch and Varnish versions listed for your chosen release.
- Content Security Policy headers are checked against the storefront and admin pages where Page Builder output appears.
How we hand over
- Handover includes a written record of the content types, templates, configuration settings and their owners.
- Editors receive a short guide covering how to build pages and blocks with the features in scope.
- Deployment steps, rollback notes and the test cases used for Page Builder pages are delivered to your team.
How we support
- Ongoing support, patch application and upgrade work can be covered by a retainer after handover.
- Custom content types are reviewed when Adobe releases patches or moves to a newer 2.4.x line.
- Ask the partner to confirm how support requests, response expectations and upgrade effort are defined in the written agreement.
