Why a self-hosted Adobe Commerce alternative is a control decision, not only a cost decision
Adobe Commerce as a Cloud Service moves hosting location, update timing and patch application to Adobe, while self-hosted Magento Open Source or Mage-OS keeps those decisions with your organization. A renewal notice or a Cloud Service offer forces that choice into the open. Before you compare features or prices, decide which of these you must control: where customer and order data is hosted, when changes reach production, and how quickly security fixes land. Those answers often matter more to your risk and compliance team than any line item in a quote.
The Cloud Service is SaaS with a headless storefront, and it applies automatic updates after a 30-day sandbox window. It does not support the Luma storefront. For a team that wants Adobe to carry upgrades, this removes a large recurring workload. The trade-off is that your change calendar now sits partly in Adobe's hands. Ask Adobe in writing which regions host your data, how the sandbox window is used for testing your extensions and customizations, and how you can hold or defer an update that conflicts with a peak trading period. Also confirm how caching is handled, since self-managed installations use Varnish while cloud-hosted Adobe Commerce uses Fastly.
Self-hosting reverses that balance. You own the upgrade path, the hosting, the patch schedule and the evidence trail for auditors. Mage-OS shows what that ownership looks like in practice: its 3.6.0 security release, dated October 14, 2026, ported an Adobe isolated patch into a distribution you run yourself. Your team or your implementation partner must then test, deploy and verify that patch on your own schedule. Choose this path when hosting location, change control or patch timing is a binding constraint, and when you can staff that work. Choose the cloud path when those constraints are looser. The right answer depends on which constraint binds your organization, so start there before comparing feature lists.
What control over hosting and patch timing requires
Staying self-hosted gives you the hosting location, patch timing and server stack decisions that the cloud service makes for you. Each card below is a requirement you take on if you keep the store on your own infrastructure, and each one needs an owner and a check before you compare the options.
Where the store and its data run
Self-hosting places the store, its database, media files and customer records in infrastructure you choose, whether that is your cloud account, a data center or an air-gapped network. Adobe Commerce as a Cloud Service keeps hosting with Adobe's platform, so the location and access model are set by that contract. Confirm your data location obligations with legal and your auditor before you decide, because this page does not assess them. Ask the vendor where backups and logs are stored and who can reach them.
Who applies security patches and when
On a self-hosted store, your team or your partner decides when a patch is tested and deployed. Adobe's release schedule says security patches ship at least annually for all supported release lines, and a full patch for the 2.4.x LTS line ships each May. Before you commit, write down who watches the security bulletins, who approves a patch window, and how long a staging test takes for your extensions.
Supported PHP, database, search, cache and queue versions
Adobe supports only the combinations listed in its system requirements for each release. The 2.4.9 requirements list 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. A self-hosted store carries the upgrade work for every one of these components, and a mismatch falls outside vendor support.
Full-page cache and storefront security headers
Adobe documents Varnish as the full-page cache accelerator for self-managed installations, while the cloud-hosted edition uses Fastly instead. Your team must configure, tune and patch Varnish yourself, and its version must match the requirements for your release. Content Security Policy headers are supported from 2.3.5, and from 2.4.7 the policy runs in restrict mode by default on storefront and admin payment pages, so test your third-party scripts and payment widgets before upgrading.
Which path fits which situation
A team that wants Adobe to carry platform upgrades and plans a headless storefront usually fits the Cloud Service best. Adobe applies updates automatically after a 30-day sandbox window, and your team builds the storefront separately from the commerce back end. The Cloud Service does not support the Luma storefront, so any existing theme work has to move to a headless or custom frontend.
- Update ownership: Adobe controls when updates reach production, so your team's job shifts to testing your own code during the 30-day sandbox window.
- Frontend build: Your team owns the headless frontend, its hosting and its release process, and that work continues after launch.
- Luma exclusion: Any store that depends on Luma must be redesigned before the move, which is often the largest unplanned cost.
- Self-hosted alternative: Staying self-hosted means you apply patches yourself against the lifecycle dates in Adobe's lifecycle policy, such as 2.4.7 standard support ending May 31, 2027.
Confirm whether your team has frontend engineering capacity to own a headless storefront for the life of the store, not only at launch.
A team that must keep the store inside its own data center or cloud account needs to confirm where the Cloud Service runs before anything else. Self-hosted Magento Open Source or Mage-OS places the full stack, from the web tier to the search and cache services, under your control. That also means your team installs, scales and secures every component.
- Stack to run: Adobe's system requirements for 2.4.9 list 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 those combinations.
- Caching layer: Adobe documents Varnish as the full-page cache for self-managed installs, while cloud-hosted Adobe Commerce uses Fastly.
- Data location: Ask Adobe in writing which regions and facilities host the Cloud Service and whether that meets your residency rules.
- Operational staff: Self-hosting requires people who can run databases, queues, search and cache clusters, backups and failover.
Settle the residency and hosting questions with your compliance lead before you request a quote, because they can rule out one path on their own.
A store with extensive custom modules, third-party extensions or deep checkout logic should map each piece of code before choosing a path. Self-hosting keeps that code on your servers and under your release control. The Cloud Service may accept or restrict certain modules, so your team has to verify each one against Adobe's requirements rather than assume it will run.
- Inventory: List every custom module, extension and theme override, and mark which ones depend on a specific Magento version.
- Self-hosted compatibility: Mage-OS's migration guide says extensions and customizations should continue to work with little or no change, but it does not guarantee that, so test them on staging first.
- Patch porting: On a self-hosted distribution, your team must confirm that security fixes are applied, for example Mage-OS 3.6.0 ports Adobe's October isolated patch APSB26-153.
- Cloud restrictions: Ask Adobe which modules, integrations and server-side changes the Cloud Service allows, and get the answer in writing.
Confirm the custom code inventory and the staging test plan before you decide, because the number of modules that need rework usually drives the scope more than the platform choice.
Which self-hosted option meets the constraint, and at what trade-off
This table compares Adobe Commerce as a Cloud Service with self-hosted Magento Open Source and self-hosted Mage-OS across hosting, patching, licensing, governance and extension risk. Read each row as one decision factor, then check the trade-off row against your team's compliance evidence and staffing. The main takeaway is that self-hosting moves patch timing, hosting and extension testing onto your team in exchange for control over the platform.
| Criterion | Adobe Commerce as a Cloud Service | Self-hosted Magento Open Source | Self-hosted Mage-OS |
|---|---|---|---|
| Where the store runs and who controls it | Adobe operates the cloud platform, which uses Fastly for full-page caching | Your cloud account or data center, with Varnish as the full-page cache | Your infrastructure, running the Mage-OS distribution of the same Magento codebase |
| Who applies patches and on what cadence | Adobe deploys updates to the platform on the schedule set in your service terms | Your team applies Adobe's releases and security patches, which Adobe ships at least annually for supported lines | Your team applies Mage-OS releases, which port Adobe's fixes, such as 3.5.0 and 3.6.0 |
| Support window | Confirm the Cloud Service version and end dates in your agreement with Adobe | Magento Open Source 2.4.9 has regular support until May 31, 2029, per Adobe's lifecycle policy | Mage-OS 3.6.0 is based on Magento Open Source 2.4.9, so confirm Mage-OS's own release schedule |
| Licensing | Paid Adobe Commerce edition under Adobe's agreement | Open Software License 3.0 (OSL-3.0), with AFL 3.0 included in the distribution | OSL-3.0 repository, sold by no one, run by a nonprofit association |
| Governance | Adobe is the vendor and sets the product roadmap | Adobe develops the upstream code, and contributors sign Adobe's Contributor License Agreement | Mage-OS Association in Poznan, Poland, with no shareholders or investors; financial members vote through Open Collective |
| Security response | Adobe applies hotfixes to the platform, and you confirm the timing and any steps you must take | Your team deploys each Adobe hotfix and any remediation steps Adobe publishes | Mage-OS ported Adobe's hotfix for CVE-2026-75650 in its 3.5.0 emergency release, and 3.6.0 ports APSB26-153 |
| Extension and theme compatibility | Luma storefront is not supported, so confirm which extensions Adobe accepts on the platform | Your team tests each third-party module against every upstream release before deployment | Mage-OS does not guarantee extension compatibility, so test each module on staging first |
| Trade-off the team accepts | Less control over hosting, caching, release timing and installable modules | Your team owns hosting, patch timing, upgrades and extension testing in exchange for full control | Same ownership as self-hosted Magento, with community-led releases and support options you must confirm |
How the 2.4.x support dates shape the timing of the decision
The end-of-support dates set the clock for this decision. Adobe gives each 2.4.x release three years of standard support from general availability. Regular support ends 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. Identify the release your store runs today and mark its end date on the project calendar. Treat that date as the deadline your plan must meet, whether the answer is the Cloud Service, a self-hosted upgrade or a move to another distribution. Read the Adobe Commerce lifecycle policy before you commit to a target version.
Support windows are only part of the workload. Adobe ships a full patch for the 2.4.x LTS line annually in May and releases security patches at least once a year for every supported release line. On a self-hosted store, your team owns that calendar. Each cycle can also change the platform underneath the code. For example, the 2.4.9 system requirements list 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. Ask your internal team or implementation partner how many of those components you would need to upgrade in a single cycle, and who tests them against your extensions and theme.
The Mage-OS path adds a further constraint on timing. Mage-OS 3.6.0, a security release dated October 14, 2026, is based on Magento Open Source 2.4.9, and its migration script requires Magento 2.4.8 or later. The migration guide also recommends updating to the latest Magento Open Source release first. If your store runs an older 2.4 line, the platform upgrade comes before any change of distribution, and that upgrade has its own testing cycle. Confirm your current version and the latest Magento Open Source and Mage-OS releases on the day you plan, because the dates in this section reflect the published schedule and newer releases may have shipped since. The Mage-OS migration guide sets out the exact prerequisites.
How to run a self-hosted Magento store under this constraint
This sequence takes a Magento store from a data residency decision to a tested, documented self-hosted platform that the organization can patch, upgrade and roll back on its own terms.
Confirm hosting location and data obligations
The legal, privacy and security owners confirm where cardholder, customer and order data may be stored, which regions and facilities are acceptable, and who may administer the servers. The platform team records these answers in a written decision before any build starts. The step is done when the owners sign off on the hosting location, the data classes in scope and the named administrators, and that record is filed with the architecture documents. Ask your hosting provider to confirm in writing which regions and facilities it operates in, because the answer determines what your own infrastructure must cover.
Choose Magento Open Source or Mage-OS
The team decides between Magento Open Source, which Adobe develops under OSL-3.0, and Mage-OS, the community distribution maintained by the Mage-OS Association as a nonprofit. The choice depends on how much weight the organization places on Adobe-led release timing versus community-led security porting, and on which extensions the store depends on. Both paths share the same codebase lineage, so the same platform requirements apply. The step is done when the decision, the reasoning and the owner of future patch decisions are recorded in the project plan. Confirm the current support and patch commitments of each option directly with its maintainers before signing off.
Pin the supported system requirements
Engineers pin each runtime component to a combination listed in Adobe's system requirements for the chosen release, covering PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, Composer and nginx. Adobe supports only the listed combinations, so mixing versions outside the matrix creates support gaps. Composer must be at 2.10.2 or newer for the Mage-OS migration path, and the team should first update the current store to the latest Magento Open Source release. The step is done when a version manifest lists every pinned component, and a build from that manifest installs without errors in a clean environment.
Set up Varnish for full-page caching
Because self-managed installations run their own cache layer, the operations team installs and configures Varnish as the full-page cache accelerator, following Adobe's configuration guide. Cloud-hosted Adobe Commerce uses Fastly instead, so this is work the organization takes on once it leaves that environment. The team tests cache invalidation for products, prices and promotions, and confirms that logged-in customer and cart pages are not served from shared cache. The step is done when cache hit behavior and invalidation have been verified on staging and a runbook for purging the cache is in place.
Configure Content Security Policy headers
The security engineers define the Content Security Policy headers for storefront and admin pages, using Adobe's developer documentation as the baseline. Adobe Commerce and Magento Open Source support CSP headers from 2.3.5, and from 2.4.7 the policy runs in restrict mode by default on storefront and admin payment pages, so payment integrations must be checked against it. Each third-party script source used by payment, analytics or chat tools must be explicitly allowed. The step is done when the policy is applied on staging, the checkout and payment flows load without blocked resources and the policy is documented for the audit file.
Run the migration on staging
The team runs the migration in a local or staging environment first. For Mage-OS, a community script swaps the Magento product packages for Mage-OS packages, followed by setup:upgrade, compilation, static content deployment and reindexing. The migration script requires Magento 2.4.8 or later. The step is done when the staging store builds, reindexes and serves the storefront and admin without errors, and the build log and command sequence are saved to the runbook. Repeat the run until it completes cleanly from a fresh copy of production data, and confirm the production cutover window with the business owners.
Test extensions and themes on staging
QA and development teams test every third-party extension, theme and custom module against the new platform on staging. The Mage-OS guide says extensions and customizations should continue to work with little or no change, but it does not guarantee this, so each one needs a pass or a remediation ticket. Testing covers checkout, tax, shipping, promotions, customer accounts, B2B features if used, and integrations with the ERP and payment providers. The step is done when every extension has a recorded test result, every failure has an owner and a fix, and the business signs off on the critical purchase paths.
Document and rehearse the rollback
The operations team documents a rollback that restores the database and files from backup and points Composer back to the original Magento product package, as described in the Mage-OS migration guide. A backup must be verified before cutover, and the restore procedure must be rehearsed on a copy of the production environment. The rollback plan names the decision owner, the trigger conditions and the communication path to customers. The step is done when a timed restore rehearsal has completed successfully and the signed runbook is stored where the on-call team can reach it during the cutover.
What auditors and internal reviewers will ask to see
A self-hosted Magento Open Source or Mage-OS store puts the evidence burden on your team, not on a SaaS vendor. The six records below are the ones reviewers usually ask for, and each one should be kept current from the first day of operation. DeployOpen prepares these systems and records for a compliance assessment, but only independent auditors or certification bodies issue audit reports or certifications.
Hosting and data location record
Reviewers want a current map of where the store, its database, search index, media files and backups run, which cloud account or data center holds each one, and who holds administrative access to each layer. With Adobe Commerce as a Cloud Service, much of this sits with Adobe. On a self-hosted store, your team must produce it and keep it updated after every infrastructure change. Check that the record names every subprocessor, including any third-party cache, CDN or payment service that touches cardholder or customer data.
Security patch log
Keep a dated log showing when each Adobe security bulletin or Mage-OS security release was assessed and applied, who approved it, and which environment received it first. For example, a Mage-OS 3.5.0 emergency release dated September 8, 2026 should appear with its application date and any remediation steps that mage-os.org advised beyond the patch itself. A gap between release and production is the first thing an assessor will ask about.
Staging test records for extensions and themes
Mage-OS's migration guide says extensions and themes should keep working with little or no change, without guaranteeing it, and recommends testing third-party extensions on staging first. Keep signed test records for each extension and theme update: the version tested, the test cases run, defects found and their resolution, and the approver. Under Adobe Commerce as a Cloud Service, Adobe runs much of the platform regression testing. On your own store, these records are your proof that a change was tested before production.
Backup and tested rollback record
A backup that has never been restored is not evidence. Record each backup job, its retention period, its encryption status and where copies are stored, then keep the results of periodic restore tests that rebuild the database and files on a separate environment. The Mage-OS migration guide documents a rollback that restores the database and files from backup and points Composer back to the Magento product package, so your rollback procedure should be written, timed by your own team and rehearsed before any upgrade.
Header and CSP configuration
Adobe documents Content Security Policy headers from 2.3.5, and from 2.4.7 CSP runs in restrict mode by default on storefront and admin payment pages. Capture the active header configuration, the policy exceptions added for payment, analytics or chat scripts, and the reason each exception exists. Reviewers will compare these records against your payment page inventory. Confirm with your assessor how they expect policy exceptions to be justified and reviewed.
Version matrix and PCI DSS 4.0 scope
Keep a matrix of the PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, Composer, nginx and Varnish versions running in each environment, checked against the combinations Adobe supports for your Magento release. Mage-OS lists PCI DSS 4.0 compliance work among its additions over upstream, but that work does not replace your own assessment. Ask your assessor exactly what that work covers for your store, and which parts of your environment remain your responsibility.
Questions buyers ask before choosing a self-hosted Adobe Commerce alternative
How much effort does moving from Adobe Commerce as a Cloud Service to self-hosted Magento or Mage-OS take?
The effort depends mostly on what the store contains, not on the platform itself. The main drivers are the number of extensions, the amount of custom code, the data volume and the number of environments that must be rebuilt and tested. Each extension needs a compatibility check against the target version, and each custom module needs review because the Cloud Service stack (Fastly, managed infrastructure and Adobe's deployment pipeline) will no longer handle those layers for you. Stores that rely on Commerce-only modules need a step down to Magento Open Source first, which adds an audit and replacement phase. Ask any partner to split the estimate by extension, custom module, data migration, infrastructure build and testing, so you can see which line items move the total.
What recurring work does a self-hosted Magento store add after go-live?
Once you run the store yourself, the recurring work moves to your team or your provider. The main items are:
- Applying security patches as Adobe releases them, and porting them through Mage-OS when you use that distribution
- Upgrading PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, Composer and nginx within the combinations Adobe supports for your release
- Running and testing backups, plus monitoring for the cache, search and queue services
- Keeping extensions and themes compatible with each core upgrade
Adobe's lifecycle policy gives each 2.4.x release three years of standard support, so you should plan an upgrade cycle around those end-of-support dates. Ask for the recurring cost in writing, with the patch frequency and the on-call coverage it assumes.
Can our team run a self-hosted Magento store without outside help?
Yes, if your team already runs production PHP applications and has the skills to operate the supporting services. Your engineers will need working knowledge of Composer, Magento's CLI commands for setup, indexing and static content, Linux server administration, nginx, the cache and search services, and a tested backup and restore routine. Teams without that depth often pair internal staff with an implementation partner for the first migration and the first upgrade cycles, then keep the operating knowledge in-house. Assess your staff against that list before choosing between an internal build and a fixed-scope engagement.
What does a fixed-scope engagement cover, and what must we provide before work starts?
A fixed-scope engagement covers the work named in a written scope, such as planning, building the self-hosted environment, migrating code and data, integrating services, hardening, documenting the result and handing it over. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own cloud accounts, data centers or air-gapped networks. Before work starts, the organization usually needs to provide in writing: the list of extensions and customizations, read access to the current store and its environments, the target hosting account, named decision-makers, acceptance criteria and the test cases the store must pass. Scope, deliverables and timelines are agreed in writing before work begins. DeployOpen does not issue audit reports or certifications; those come from independent auditors and certification bodies.
Will our Magento extensions keep working on Mage-OS?
Mage-OS states that extensions, themes and customizations should continue to work with little or no change, but it does not guarantee that outcome. Its migration guide recommends testing every third-party extension on a staging environment before cutover. The migration script swaps Magento product packages for Mage-OS packages in a local or staging copy, followed by setup upgrade, compilation, static content deployment and reindexing. Confirm each extension vendor's stated support for Mage-OS, and keep the documented rollback ready, which restores the database and files from backup and points Composer back to the Magento product package. Modules that depend on Adobe Commerce-only features will not work on either distribution and must be replaced.
What should we ask for in a quote for a self-hosted Adobe Commerce alternative?
Ask for a quote that separates one-time work from recurring costs. The one-time items include the audit of extensions and custom code, replacement of Commerce-only features, environment build, data migration, testing, cutover and documentation. The recurring items include patching, upgrades, infrastructure and monitoring, backups and support hours. Ask which Magento or Mage-OS version the quote targets, which PHP and service versions are included, how extension compatibility is tested, and what the rollback plan covers. Request the assumptions in writing, including the number of environments, the data volume and the acceptance tests, because changes to these assumptions drive most cost changes. Your own cloud and licensing costs for hosting the store should appear as separate lines from the services fee.
How DeployOpen works on this
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source stores inside the client's own cloud accounts or data centers. For a store weighing Adobe Commerce as a Cloud Service against staying self-hosted, we start by putting the decision inputs in writing before any build work begins.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We inventory which Adobe Commerce features, extensions and integrations your store depends on today.
- The written scope names the target platform, hosting location and the Magento release line you will run.
- Ask any implementation partner to confirm which cloud-only services, such as Fastly caching, are replaced and by what.
How we build
- We stand up the self-hosted environment in your accounts, including PHP, database, search, cache and queue services.
- We test extensions, themes and custom code on a staging copy before any production cutover.
- Security testing of the storefront, admin and APIs is available as a separate fixed-scope engagement.
- Payment page and Content Security Policy settings are configured and checked against your own requirements.
How we hand over
- You receive documentation of the environment, deployment steps, patch procedure and rollback plan.
- Backup and restore runs are tested so recovery steps are proven before go-live, not assumed.
- Compliance readiness material, such as system configuration and evidence, is prepared for your own auditor to review.
- DeployOpen does not issue audit reports, attestations or certifications; independent assessors do.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover tracking vendor and community security releases and applying them to staging first.
- Your team keeps the decision rights on hosting, release timing and vendor choice.
- Ask for a written quote that separates one-time implementation from recurring retainer work.
