Mage-OS Hosting Requirements: Choosing the Right Server and Stack

Mage-OS publishes its own system requirements page, which on our check described Mage-OS 3.5.0. Mage-OS 3.5.0 was released on 8 September 2026 on top of Magento Open Source 2.4.9, so Adobe's on-premises system requirements for 2.4.9 describe the stack that the underlying code is tested on. The table puts both side by side. If you are new to the project, start with our explainer What is Mage-OS?

Most of the sizing decisions come down to one question: how many requests reach PHP? Nginx handles the secure connection. Varnish sits behind it as the full-page cache and answers repeat views of catalogue, product and content pages from memory. Anything Varnish cannot answer goes to PHP-FPM, where the Mage-OS application runs.

A store with a high cache hit rate can serve a lot of browsing with modest PHP capacity. What it cannot avoid is the traffic that bypasses the cache: baskets, checkout, customer accounts, the admin and anything that posts a form. Those requests run PHP every time, which is why a busy sale stresses PHP workers and the database more than the homepage. Our guide to checkout speed at peak covers that side in more detail, and our Varnish cache guide explains the cache itself.

Behind the application sit the services it depends on, and each one needs memory of its own. Valkey (or Redis) holds the application cache and, usually in a separate instance, customer sessions. The database is the source of truth for products, customers and orders. OpenSearch answers catalogue searches and the filters on category pages, and Mage-OS's requirements page says a search engine is required.

Cron is not optional. Indexing, emails, sitemaps, scheduled price changes and queue consumers all run from cron. A store without a working cron looks fine for a while, then shows stale prices, stock and search results. Mage-OS lists RabbitMQ as optional; without it, queues run through the database.

For more on the cache and search layer, see our pages on Valkey for Magento and OpenSearch for Magento.

Mage-OS publishes a starting point. Treat it as a floor, not a recommendation for your store.

• Access to the Mage-OS package repository. Mage-OS installs from repo.mage-os.org with Composer and needs no Adobe account. If your store uses Adobe Marketplace extensions, Composer also needs Adobe's repository and your Marketplace keys.
• Deployment permissions. Composer and bin/magento should run as the user that owns the store files, never as root, with the web server able to read what it serves and write only where it must. A separate user per environment keeps staging and production apart.
• TLS. A valid certificate on every storefront and admin hostname, renewed automatically, terminated in front of Varnish as shown above.
• Backups you have restored. Database, media and the exact composer.json and composer.lock. A backup on the same server is not enough on its own, and a backup you have never restored is a hope rather than a plan.
• Monitoring. Uptime checks, disk and memory alerts, and checks that cron, the queue consumers, OpenSearch and Valkey are running, not just the web server.
• Staging. A copy of the store on the same versions as production, so updates, extensions and Mage-OS releases can be tested before they go live.

On Magento Open Source, some security fixes arrive as isolated patches you apply to your current version. Mage-OS ports Adobe's fixes into a new Mage-OS release, so you get them by updating with Composer. Mage-OS 3.5.0, for example, was an emergency release carrying Adobe's hotfix for the StyleSmuggler vulnerability. Mage-OS's releases page says it fixes only the latest release branch, and that its updates typically follow Adobe's within days.

For hosting, that means two things. Plan for regular Composer updates tested on staging, and make sure whoever looks after the store watches Mage-OS's releases, not only Adobe's bulletins, because Mage-OS version numbers do not match Adobe's. Our article on StyleSmuggler covers that vulnerability.

These two jobs are often mixed up, and they need different people.

• Moving host copies an existing store, Magento or Mage-OS, to a new server built to the right versions. The code does not change. It is a hosting job: build the stack, copy files and database to staging, test, then cut over.
• Converting to Mage-OS swaps the Composer packages a Magento store is built from. Mage-OS's migration script expects Magento Open Source 2.4.9 and developer mode, and its authors warn against running it on production. It is application work for your developer or agency, and should be done and tested on staging first.

If your store is on an older Magento release, conversion starts with an upgrade to 2.4.9. Our guide to the Magento 2.4.7 to 2.4.9 upgrade covers the order to do that in.

There is no single best host for every Mage-OS store. These are the questions that separate a suitable one from an unsuitable one:

1. Will they build the exact versions in the table above, and change them when your release needs it?
2. Do you get guaranteed CPU and memory, and can they explain how they sized it from your traffic rather than your page views?
3. Is there a staging environment on the same versions as production?
4. Who applies Mage-OS updates and server patches, how quickly, and who tests them first?
5. Do they watch Mage-OS's own security releases, not only Adobe's bulletins?
6. Where are the backups held, how long are they kept, and when were they last restored?
7. What does monitoring cover beyond "the site is up": cron, queues, search and cache?
8. Where is the data centre, if UK data location matters to you, and what happens when you want to leave?

Mage-OS's requirements page itself recommends managed Magento hosting for production stores. Our Magento 2 prerequisites checklist goes into each part of the stack in more depth.

We host Mage-OS. It needs the same server stack as Magento 2.4.9, and our servers are set up with those prerequisites: PHP 8.5, MySQL 8.4 or MariaDB 12.3, OpenSearch 3, Valkey, Varnish and nginx, on our standard nginx stack in a UK data centre. Mage-OS runs on our current Managed VPS, dedicated server and High Availability plans; which one suits your store depends on your traffic, catalogue and imports. Every server is built to order, a staging environment is included on every plan, and RabbitMQ can be installed on request.

Moving an existing Mage-OS store to EveryHost is covered by our free managed migration, carried out with minimum downtime. Converting a Magento store to Mage-OS is application work for your developer or agency; we prepare the stack and a staging copy and work alongside them. Mage-OS updates are applied by your developer, or by us at additional cost. Sentinel, our server-side security monitoring, watches the server's logs and files for attacks and malware.

If you are weighing up where a Mage-OS store should live, compare our managed Magento VPS hosting, dedicated Magento servers and plans and prices, or ask us to look at your store first.