Magento Open Source hosting and infrastructure guide

Why Magento Open Source hosting decisions start with the version matrix

The hosting decision for a self-hosted Magento Open Source store starts with a supported version combination for one release line, not with a server size or a cloud provider. Before anyone provisions a virtual machine or picks a database engine, the team should fix one Adobe release, such as 2.4.9 or 2.4.8-p5, and then take every runtime component from that release's requirements list. Adobe supports only the listed combinations, so a stack assembled from whatever versions the operating system packages offer is outside what the vendor will support.

The two current lines do not share the same list. The requirements Adobe publishes for 2.4.9 name 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. The list for 2.4.8-p5 allows PHP 8.4 or 8.3, MySQL 8.4 or MariaDB 11.4 or 11.8, Redis or Valkey 8.1, and it adds Varnish 8. A team that copies one list onto the other release will build an unsupported stack. Confirm each line item against the Adobe system requirements page for the exact release you intend to run.

Each 2.4.x release receives three years of standard support from general availability. Per Adobe's lifecycle policy, regular support for 2.4.6 ends on August 11, 2026, for 2.4.7 on May 31, 2027, for 2.4.8 on May 31, 2028 and for 2.4.9 on May 31, 2029. The end date belongs in the hosting plan from day one, because it sets when the platform, and often the PHP and database versions under it, must move. Adobe's release schedule says a full patch for the 2.4.x LTS line ships annually in May, and security patches arrive at least annually for every supported line, so patching is a recurring duty with a fixed rhythm.

The difficulty is coupling. PHP, the database, OpenSearch, Redis or Valkey, RabbitMQ, Composer and nginx each have their own version constraints, and a change to one can invalidate the combination. Moving PHP to a newer minor version may require a new Magento patch, and a new database engine may need a different search or cache version. Plan a staging environment that mirrors production versions exactly, and record the matrix as a controlled document that is reviewed at every patch cycle. The Adobe requirements pages are the controlling source for this decision. Community distributions such as Mage-OS build on the same codebase, so the team should also confirm which versions and patch levels its chosen distribution documents before relying on them.

Which components the stack must include and what each one does

A self-hosted Magento Open Source store runs as a set of cooperating services, and each one must match a supported version for the release you choose. The cards below list the versions Adobe names for 2.4.9 and, where relevant, 2.4.8-p5, and explain the role each component plays so you can confirm the full stack before you size or price the environment.

PHP runtime version

PHP runs the Magento application code for storefront, admin, API and cron work. Adobe's requirements for 2.4.9 list PHP 8.5, while 2.4.8-p5 lists PHP 8.4 or 8.3. Check the PHP version your extensions and custom modules support before you choose a release, because a runtime that is too old or too new for a single extension can block the whole upgrade.

MySQL or MariaDB database

The database holds the catalog, customers, carts, orders and admin configuration, so its version drives data integrity and backup design. For 2.4.9, Adobe lists MySQL 8.4 or MariaDB 12.3 (recommended) or 11.8. For 2.4.8-p5, the list is MySQL 8.4 or MariaDB 11.4 or 11.8. Confirm which engine your team can patch and back up, and test restores on the chosen version.

OpenSearch for catalog search

OpenSearch serves catalog search and layered navigation queries on the storefront, so a search outage leaves shoppers unable to find products even when the database is healthy. Adobe lists OpenSearch 3 for both 2.4.9 and 2.4.8-p5. Plan a dedicated node or cluster sizing review with your search configuration, and confirm that the version you deploy matches the Adobe list exactly.

Redis or Valkey for cache and sessions

Redis or Valkey holds the application cache and customer and admin sessions, which keeps repeated reads off the database. Adobe lists Redis or Valkey 9 for 2.4.9 and Redis or Valkey 8.1 for 2.4.8-p5. Decide whether cache and sessions share one instance, and confirm eviction and persistence settings with your hosting team before go-live.

RabbitMQ for asynchronous work

RabbitMQ carries queued jobs such as asynchronous bulk operations and integration messages, so work does not block the shopper's request. Adobe lists RabbitMQ 4.3 for both 2.4.9 and 2.4.8-p5. If you plan an ERP or other middleware integration, identify which queues your modules and connectors use and who monitors consumer health.

Composer dependency manager

Composer installs Magento and its dependencies, and it is the path for applying most upgrades and extension installs. Adobe lists Composer 2.10 for both 2.4.9 and 2.4.8-p5. Keep the Composer version fixed in your build pipeline and review dependency changes in every patch release, since they can change extension compatibility.

nginx web server

nginx accepts HTTPS traffic and passes requests to PHP-FPM for the storefront and admin. Adobe lists nginx 1.30 for both 2.4.9 and 2.4.8-p5. Your configuration also controls static file handling, security headers and any Content Security Policy you enable, so include it in your change control and test it after each upgrade.

Linux x86-64 host

Adobe's system requirements for 2.4.9 name Linux x86-64 as the supported platform, and Adobe supports only the listed combinations of components. Confirm the operating system distribution and release with the vendor documentation, and decide whether the host runs on a cloud virtual machine or on-premises hardware. Your build, patch and monitoring tooling must work on that same platform.

Which release line, database and hosting model fit your store

This table compares the supported Magento Open Source release lines, database, cache, full-page cache and hosting options side by side. Read each row against your patch cadence, team skills and upgrade timeline. The main takeaway is that 2.4.9 gives the longest support runway, while every option carries recurring patch and version-matching duties.

Decision	Option	When it fits	Operational cost
Release line	2.4.9	New builds, or stores ready to run PHP 8.5 and Symfony 7.4 LTS	Support runs to May 31, 2029. Confirm every extension supports PHP 8.5 before go-live.
Release line	2.4.8-p5	Stores whose extensions are not yet verified on 2.4.9	Support runs to May 31, 2028. Lists PHP 8.4 or 8.3, so plan a move to a later line before then.
Database	MySQL 8.4 or MariaDB 12.3 or 11.8	MySQL 8.4 if your team runs MySQL. MariaDB if your standard is MariaDB. Adobe lists 12.3 as recommended for 2.4.9.	Engine patches follow their own cadence. Adobe supports only the listed combinations, so test each change.
Cache layer	Redis or Valkey 9 (2.4.9) or Valkey 8.1 (2.4.8-p5)	Pick the cache engine and version that match your release line	Track version pairs on each line. Mismatched versions fall outside the supported combinations.
Full-page cache	Self-managed Varnish 8 (listed for 2.4.8-p5)	Storefront traffic high enough to justify a cache tier your team runs	Someone must own cache rules, purge logic, tuning and Varnish patching on every release.
Full-page cache	No Varnish layer	Low traffic, or a line where Varnish is not listed in the requirements you confirm	Fewer components to run, but web nodes carry more load. Confirm the 2.4.9 requirements with Adobe first.
Hosting model	On-premises hardware	Data residency rules or existing data center capacity you already operate	Your team owns hardware refresh, OS patching, backups, failover design and capacity planning.
Hosting model	Cloud virtual machines	Teams that want control of the OS and stack without owning hardware	Your team patches the OS and services, resizes instances, and manages snapshots and backups.
Hosting model	Managed container platform the team operates	Teams with container and orchestration skills running several environments	Image rebuilds each patch cycle, cluster upgrades, and separate handling for stateful database and cache services.

How to build the Magento Open Source hosting stack step by step

This sequence takes an empty Linux x86-64 host to a Magento Open Source stack where every component matches the requirement list for one chosen release line. Each step closes with a check, so the build ends with a pinned, verified record that your team or a partner can reproduce.

Confirm the release line and support end date
Choose the 2.4.x release line before any server is provisioned, then confirm its general availability and end of regular support dates on Adobe's lifecycle policy page. Check the release notes for the patch level you will install, because a line that ends within your planned operating period will need an upgrade plan from day one. Your team or your partner records the chosen release, patch level and end-of-support date in writing. The step is done when that record is approved by the business owner and the security lead.
Match PHP and Composer to the requirement list
Take the PHP and Composer versions from Adobe's system requirements for your exact release and patch level, not from a generic distribution default. For 2.4.9, the listed PHP version is 8.5 and the listed Composer version is 2.10, while the 2.4.8-p5 requirements list different PHP options, so confirm the row for your target. Install the matching PHP extensions and Composer on the build host. The check is a version command output for both tools matched line by line against the requirement table.
Select a compatible MySQL or MariaDB version
Pick one database engine from the options listed for your release. For 2.4.9 the list includes MySQL 8.4, MariaDB 12.3 (recommended) and MariaDB 11.8. Confirm the chosen version against the requirement table, then install it on a dedicated database host or a dedicated instance in your environment. Set the server to the character set and collation your installer documentation requires. The check is a server version query whose output matches the requirement entry you selected, and a successful login from the web tier using the application account.
Install OpenSearch and Redis or Valkey
Install OpenSearch at the major version listed for your release, which is OpenSearch 3 for 2.4.9 and 2.4.8-p5, and install Redis or Valkey at the listed major version, which is 9 for 2.4.9 and 8.1 for 2.4.8-p5. Keep both services on private addresses, reachable only from the application tier. Confirm the cluster reports a healthy status and that the cache server answers a ping. The check is a cluster health response that is not red and a cache server reply of PONG from each application node.
Install RabbitMQ and nginx on Linux x86-64
Install RabbitMQ at the listed version, which is 4.3 for both 2.4.9 and 2.4.8-p5, and install nginx at the listed version, which is 1.30 for both lines. Use a Linux x86-64 host, because Adobe supports only the listed platform and combinations. Enable the RabbitMQ management plugin only if your monitoring needs it, and restrict its access. The checks are a RabbitMQ diagnostics ping that returns success, and an nginx configuration test that reports the configuration is syntactically valid, followed by a version output for each binary.
Configure Varnish if the release requires it
Adobe documents Varnish as the full-page cache for self-managed installations, and the 2.4.8-p5 requirements list Varnish 8. Confirm in the requirement table for your exact release whether Varnish is listed before installing it, and if it is, use the listed version. Point Varnish at the web tier and set the backend and cache rules as your installation guide describes. The check is a Varnish version output that matches the requirement entry, and a repeat request to a cacheable storefront page that returns a cache hit in the response headers.
Run a clean Composer dependency install
Start from an empty project directory, install the Magento Open Source package for your chosen release through Composer, and use the committed lock file so every dependency resolves to a recorded version. Run the installation on a build host that matches the production PHP and extension set. A dependency tree that installs with no unresolved packages and no version conflicts is the first gate. The check is a completed composer install with no errors, followed by a successful command-line version query from the application binary.
Record pinned versions in a build manifest
Write a build manifest that lists the release and patch level, PHP, Composer, the database engine, OpenSearch, Redis or Valkey, RabbitMQ, nginx, Varnish if used, and the operating system kernel and distribution. Store the manifest in version control next to the lock file and the infrastructure code. Compare each entry against the requirement table one more time, and confirm each value against the output captured in the earlier steps. The step is done when the manifest is signed off by the team that will operate the stack and it can be used to rebuild the same environment.

How hosting on-premises, cloud VMs or air-gapped networks changes the stack

On your own hardware, the team controls every layer, which also means it owns every layer. Operating system packages, PHP extensions, database and search binaries usually come from internal mirrors or a controlled proxy rather than public repositories, so the mirror must track the exact versions in Adobe's requirements for your target 2.4.x release. Varnish is installed on hosts you manage, typically in front of nginx, and it must be sized and monitored by your own staff. Patching cadence, backup verification and hardware replacement all sit with your infrastructure team.

Points to plan for:

Package sourcing: Mirror the OS, PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ and nginx packages, and pin versions to the combinations Adobe supports.
Composer: Host an internal Composer mirror or private repository so builds do not depend on public registries at deploy time.
Patching: Your team applies operating system and service patches, and schedules them around Adobe's patch releases.
Full-page cache: Self-managed Varnish runs on your hosts, so you own its configuration, purge logic and failover.
Evidence: Keep change records, patch logs, hardware inventory and backup restore tests that show who did what and when.

Confirm with your hardware vendor and infrastructure team which OS versions they support for the PHP and database versions in your chosen release.

What drives the effort and cost of a Magento Open Source hosting build

This table lists the decisions that most change how much a self-hosted Magento Open Source build costs to set up and run, with one practical way to keep each one under control. Read each row as a question to answer before requesting a quote, since the answers determine how many servers, services and test cycles the work needs. The main takeaway is that fewer version exceptions and fewer custom pins usually reduce both build time and every later patch cycle.

Driver	Why it changes effort or cost	How to keep it down
Number of environments	Production, staging and development each need their own servers, data copies, deployment steps and monitoring. Every additional environment adds setup work and recurring hosting.	Keep staging on the same PHP, database, search and cache versions as production, and keep development small and disposable.
Number of web nodes	Each web node needs its own configuration, shared session and cache handling, load balancer health checks and patch rollouts. Node count also drives Varnish and Redis or Valkey sizing.	Start with the node count your traffic forecast supports and confirm the scale-out path, rather than building capacity for peak events you have not yet measured.
Integrations that depend on specific services	ERP, payment, tax or shipping connectors may require particular PHP extensions, message queue settings or database versions. Each dependency adds testing and can block a version upgrade.	Ask each integration vendor for its supported platform matrix in writing and reject connectors that need unsupported versions of core services.
Extensions that restrict PHP or service versions	Some third-party extensions only support older PHP, OpenSearch or RabbitMQ releases. Pinning the whole stack to one of them forces a delayed upgrade path for the entire store.	Run an extension audit before the build, favor extensions that declare support for the current release line, and replace abandoned packages early.
Customization that requires older components	Custom modules or theme code written against deprecated APIs, or front end tooling tied to old Node versions, need extra compatibility work and separate build pipelines.	Require customizations to follow the module and theme structure in Adobe's developer documentation and keep build tooling version-locked in the repository.
Compliance evidence needs	Payment-related controls, patch records, access logs, backup tests and change approvals must be collected from every environment. Missing evidence usually means rework near assessment time.	Define the evidence list during planning, automate log retention and patch records from the start, and confirm the required scope with your assessor or acquirer.
Operating system and package sourcing model	Using a distribution-supported Linux release with packages from its repositories is generally simpler than mixing vendor repositories, source builds and hand-installed libraries. Mixed sourcing increases patching and debugging time.	Standardize on one supported Linux x86-64 release, install PHP and services from a single controlled source, and fix one release line for the project.

How to lay out development, staging and production so versions stay matched

The practical goal of an environment layout is simple: the same PHP, database, OpenSearch, Redis or Valkey, RabbitMQ, Composer and nginx versions should run in development, staging and production, and any difference should be deliberate and written down. Adobe publishes a system requirements matrix for each 2.4.x release and states that only the listed combinations are supported. For 2.4.9, that matrix names 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. Treat that list as the baseline for every environment, and confirm it against the release you are actually deploying before each change.

A mismatch found after go-live is expensive because it usually surfaces under production load, in checkout or indexing, where the fix has to be made live and tested at the same time. A staging server running a different PHP minor version or an older search engine can pass every test and still fail on the first real order. Ask your team to record the exact versions of each component per environment in a single inventory that is reviewed at every release, and to treat a drift in that inventory as a defect. Also confirm where varnish and the cache layer sit in the design, since Adobe documents Varnish as the full-page cache for self-managed installations and it needs the same configuration in staging as in production to make tests meaningful.

Build deployment artifacts once, in a controlled build environment, and promote that same artifact through staging to production. Rebuilding the code separately in each environment reintroduces drift, because package downloads and installed dependencies can differ between runs. The composer.lock file is the control point for PHP dependencies: it records the exact versions resolved for the project, so every build that installs from it gets identical packages. Commit the lock file, avoid running dependency updates on a server, and check that any change to composer.json comes with a regenerated lock file. Custom modules and themes should be versioned in the same repository so that their code and the locked dependencies move together.

A patch release should move through the same path as any other change: built once, deployed to staging, tested against the same services and configuration as production, then promoted. Adobe publishes security patches at least annually for supported lines and recommends applying patches every cycle, so a repeatable promotion path matters more than a fast one. Agree with your engineering team which checks run in staging before promotion, who approves the release, how the production database is backed up before the change, and how a rollback is performed if a patch fails. Confirm the exact promotion approach, the tooling your team uses and the window in which changes are allowed. This project does not prescribe a specific tool for it.

Before you commit to an environment layout, ask your engineers for three items in writing: the version inventory for each environment, the process that produces the deployable artifact, and the promotion and rollback steps for a patch release. If any environment cannot run the same PHP and service versions as production, record the reason, the owner and the date it will be closed. A layout that keeps these three items current will tell you early when a platform upgrade or patch is about to create a mismatch, which is the cheapest moment to fix it.

Securing the Magento Open Source hosts and service endpoints

A self-hosted Magento Open Source store runs several network-facing components: the web tier, admin path, search, cache, queue and credentials. The cards below cover the controls that reduce exposure of each one and the checks to confirm they stay in place after the store goes live.

Separate service endpoints from the public internet

Only the storefront entry point and, where the business requires it, the admin entry point should accept traffic from the internet. Database, search, cache and queue services should sit on private addresses with no public route. Ask the implementation team to document every listening port per host, and confirm with a scan from outside the network that nothing else responds.

Restrict the admin path at nginx

The Magento admin is a high-value target, so limit which source addresses can reach its path at the nginx layer, before requests reach PHP. Typical choices include allow lists for office or VPN ranges and rate limits on login requests. Confirm the rules in the nginx configuration itself, and test them from an address that is not on the list.

Limit OpenSearch, Redis or Valkey and RabbitMQ to the application network

OpenSearch, Redis or Valkey, and RabbitMQ are often installed with default ports and weak or no authentication in early builds. Bind each service to a private interface, require authentication where the product supports it, and allow connections only from the web and worker hosts. Verify the bindings after each service upgrade, since default listen addresses can change between versions.

Handle service credentials through a secrets store

Database passwords, search and cache credentials, queue users and payment or ERP API keys should not live in env.php or other files committed to the repository. Store them in a dedicated secrets manager, inject them at deployment, and rotate them on a set schedule. Ask for a list of every credential, where it is stored and who can read it.

Keep operating system and service packages on a patch schedule

The Linux host, PHP, nginx, the database, OpenSearch, Redis or Valkey, RabbitMQ and Composer each receive security updates on their own cycle. Agree a patch calendar that covers all of them, test in a staging environment that matches the production version set, and record each change. Check the Adobe system requirements for the target Magento release before changing any runtime version.

Content Security Policy headers

Magento Open Source supports Content Security Policy headers from version 2.3.5, and from 2.4.7 the policy runs in restrict mode by default on storefront and admin payment pages. Confirm that your release is at or above these versions and that the header is present on pages that load third-party scripts. The detailed policy controls are covered in the security hardening topic.

What to monitor, back up and document after the stack is live

Once the stack is live, the store stays safe and supportable only if a named owner tracks a short list of dates, versions and recovery points. The first item is the end of regular support date for the 2.4.x line you chose. Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability, and the policy lists the end dates for each line, including 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. Record the date for your line, the date of the next planned upgrade window, and the owner who signs off on that window. Confirm the dates against the lifecycle page when you set the reminder, because the policy is the source of truth.

The second duty is patch tracking. Adobe's release schedule says a full patch for the 2.4.x LTS line ships annually in May, and security patches ship at least annually for every supported release line. Those are minimum cadences, not promises of quiet months, so the team should watch the released versions page and the security bulletins rather than waiting for the annual release. Keep a short log of each patch received, the date it was applied to staging and production, and whether the extensions you depend on were retested. Mage-OS, if you use it, may publish its own release timing, so record which upstream patch each distribution release ports.

The third duty is component version drift. Adobe's system requirements list the supported combinations of PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, Composer and nginx for each release, and Adobe supports only the listed combinations. Keep a copy of the requirement list for your release next to your inventory, and compare it against every host after each change. A PHP minor version bump on one web node, or a MariaDB upgrade made outside the change process, is a common way to end up outside supported combinations without anyone noticing. Varnish, where you run it, needs the same check, because its version is listed on the requirements for some patch releases.

The fourth duty is backup and restore. Back up the database, the media directory, and the configuration, including environment files and the secrets they reference. Schedule each backup at an interval the business can accept if data is lost, and test a restore on a separate host on a regular cadence, because an unrestored backup is only a hope. Assign one owner for backups and one for restore tests, and write down who can authorize a restore during a live incident. Ask your hosting partner or internal team to confirm whether search indexes and cache must be rebuilt after a restore, since that affects recovery time.

The fifth duty is the inventory. Maintain one record of every host, its role (web, database, search, cache, queue, admin or worker), its operating system, and each pinned version of PHP, the database, OpenSearch, Redis or Valkey, RabbitMQ, Composer, nginx and any extension with a locked version. Include the account or data center that owns each host and the person accountable for patching it. Review the inventory before each patch window and after any change. Engineering leads usually own the inventory, the security lead approves changes to pinned security settings, and the store operations lead owns the restore runbook and the upgrade calendar.

Questions teams ask before hosting a Magento Open Source store

How much does a self-hosted Magento Open Source build cost?

The cost depends mostly on how much infrastructure the store needs and who builds and runs it. The main drivers are the number of web nodes, the database, search, cache and queue services, the number of environments (development, staging, production), and whether you use cloud virtual machines or your own data center hardware. Labor is the largest variable: someone must install and harden the stack, configure it, load test it and keep it patched. Ask each bidder to split the quote into one-time items (design of the environment, build, hardening, testing, handover) and recurring items (hosting, licenses if any, monitoring, patching and support). Ask which costs are fixed and which are estimated, and what triggers a change order. Any figure should come from your written scope, not from a general rate.

How long does it take to set up a hosted Magento Open Source store?

The timeline is set by the scope you agree, not by the software itself. The work that most often extends it is hardware or cloud account approval, network and DNS changes, certificate issuance, identity provider integration, load testing, and any compliance evidence you need to collect before launch. The size of the stack and the number of environments also matter, as does the number of custom modules and extensions that must be installed and tested on the chosen versions. DeployOpen plans and delivers most engagements as fixed-scope work, so the duration and milestones are written into the agreement before work starts. Ask any provider to show the phases, dependencies and the client tasks that sit on the critical path.

What does our team need to provide for a hosting build?

Your team typically provides access and decisions, not labor on the stack itself. You will need a named technical owner, cloud account or data center access with the right permissions, network and firewall change approval, DNS control for the store domains, and a process for issuing and renewing TLS certificates. Identity provider details are needed if admins will sign in through single sign-on. You also need to confirm payment gateway access, the backup retention policy, the maintenance window for patches, and who approves production changes. Ask the provider for a written requirement list before the build starts, and check it against your change management and security policies so approvals are scheduled early.

Can an internal team host Magento Open Source without an outside partner?

Yes, an internal team can host the store, provided it has the skills and time to run the whole stack. The stack spans PHP, Linux administration, the database, OpenSearch, Redis or Valkey, RabbitMQ, nginx, and Varnish for self-managed full-page caching. Someone must also manage cron and indexers, back up and test restores, monitor performance and apply patches on each cycle. Before deciding, count the people who already run these services in production and ask whether they can cover on-call duties and an upgrade project in the same year. Many teams split the work: an internal team runs daily operations while an outside partner handles the initial build, hardening, or the upgrade. DeployOpen offers implementation, hardening, documentation and ongoing support as separate, written scopes.

Which PHP and database versions should a new Magento Open Source store use?

Choose a release line first, then use the exact combination listed for that release in Adobe's system requirements. Adobe supports only the listed combinations. For Magento Open Source 2.4.9, the listed PHP version is 8.5, with MySQL 8.4 or MariaDB 12.3 (recommended) or MariaDB 11.8. For 2.4.8-p5, the listed PHP versions are 8.4 or 8.3, with MySQL 8.4 or MariaDB 11.4 or 11.8. Both lines also list OpenSearch 3, Redis or Valkey, RabbitMQ 4.3, Composer 2.10 and nginx. For a new store, check the lifecycle dates so you launch on a line that will still receive support for your planned life. Confirm the requirement list for your chosen release before you order servers or images.

Are on-premises servers or cloud virtual machines better for a regulated store?

Neither model removes your compliance duties, and the better choice depends on what you must control and evidence. Cloud virtual machines shift part of the physical and platform responsibility to the provider, so you should review the provider's shared responsibility terms, the regions available to you, and the attestations they publish. On-premises hosting gives you direct control of physical access and network placement, but you carry the cost and staff for hardware, facilities and replacement. For payment-related requirements under PCI DSS, the deciding factor is usually how payment pages and scripts are built and which systems touch cardholder data, not the hosting model alone. Confirm the exact scope and evidence with your assessor or qualified security assessor. DeployOpen prepares systems and evidence for assessments but does not issue audit reports or attestations.

What happens when my Magento Open Source release reaches end of support?

After end of regular support, your release stops receiving standard fixes, so you must move to a supported line. Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability. The published end of regular support dates are 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. Adobe releases a full patch for the 2.4.x LTS line each May and security patches at least once a year for supported lines. Plan the upgrade early, because effort depends on customizations, extension count, third-party integrations and coding practices. Use the Upgrade Compatibility Tool and check the lifecycle policy and release schedule pages before setting your date.

How DeployOpen scopes, builds and hands over Magento Open Source hosting

DeployOpen plans, builds and documents self-hosted Magento Open Source infrastructure inside your own cloud accounts, data centers or air-gapped networks. We fix the component versions against Adobe's published requirements first, then build, test and hand over the environment in a form your own team can run.

How we scope

Engagements are fixed-scope, with the environment layout, components and deliverables agreed in writing before work starts.
We check the chosen PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ and nginx versions against the exact combination Adobe lists for your target 2.4.x release.
The written scope names which environments (production, staging, development) and which hosting model (on-premises or cloud virtual machines) it covers.

How we build

We build the web, database, search, cache and queue components in your environment, with Varnish configured as the full-page cache for self-managed installs.
We set up Content Security Policy headers and confirm storefront and admin payment pages behave as expected under the restrict mode used from 2.4.7.
We run functional and load checks on the built environment, then record the results against the agreed scope before anything goes live.

How we hand over

You receive architecture diagrams, component version records, configuration files and runbooks for deploying, patching and restoring the stack.
We document the backup and restore procedure and the steps your team takes for each patch cycle and each annual full patch release.
Handover includes a walkthrough with your engineers so they can operate the environment without depending on us for routine changes.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial build.
Retainer work can cover applying security patches, moving to a newer supported 2.4.x line and checking service version changes before they reach production.
Confirm with us during scoping which support levels, response expectations and evidence packs your retainer will include, since these are set in writing.